使用过，最多都是查看【错误查询】，看到问题的第一反应肯定是想知道为什么报错，只是通过信息定位问题不够快速。

1. 是否可以做到直接点击问题就跳转到指定代码上面去？类似于编辑器报错一样的效果，理论上代码肯定服务器上面是有的。（哪怕需要配置也可以）
2. 其他的模块肯定有用的，但是一眼看上去不知道如何使用是否可以添加符合业务的实战教程？

个人建议：

已有的常用模块可以提升便捷性，一些不被常用的功能可以做写教程引导更多人去使用。要不然做出来没有人用也等于浪费了产品和开发的时间。

首先肯定一点，这个功能在早前开发的时候帮助还是挺大的~

毕竟一开始开发不娴熟，会遇到各种问，所以使用频率还是很高的，但现在基本群里不报警就不看了。

======== 先说下好的地方 ========

1、报警群是真香的，有时候就是写码质量不行，特别是大项目上线，10w+访问量一上来，群里high个不停。。。=-=

比如：很多Object的key没有判断undefined，遇到一些后端坑爹的情况，就会各种报错，算是提升了开发人员书写代码的强壮性

2、性能监控这块还是不错的，简单好用，直观好上手

======== 懵逼的地方 ========



1、测速：结果有了，然后呢？开发人员改怎么做呢？

而且和前面的性能数据/性能监控等有点相似，无非是更加精细化，但实际操作成本也高，产品不会随便让开发加代码的，建议给你可以不用加代码的模板/demo，无脑先给用户用下（学习成本高）

2、报错有点懵逼，很多是源生基础库的BUG。。。但是也不做区分。。。比如PC客户端对一些canvas 图表属性的不支持。。。但是也在群里疯狂发报错信息，简单说就是问题定位不明确。

比如这些，其实现在线上的项目报错已经很少了，但是这里也不区分下 PC端和手机端，好比这个报错，一开始是很懵逼的

我们反复检查了，才发现是PC端2.95 对canvas一些属性支持不是很好，另外就是ES5压缩后，莫名其妙的PC端不兼容，在canvas webGl这块特别严重。

有些报错是有具体页面，有些没有具体页面，排查起来要人命啊。。。导致直接放弃。

建议 既然是报错提示，每个错误最好有具体页面path和 机器类型，比如Android的 P40。。。因为有的时候我们发现。。。是基础库的兼容性问题，但一开始是不确定的。

很多报错定位不明确，就是需要大量时间排查，但是测试机测下来，又觉得BUG用户是无感知的，所以就直接放弃了，导致开发对“运维中心”模块的需求变弱。久而久之就头铁了，群里不报警，就不排查~

开发运维中心对于有心精益求、打造更优质小程序的运营者开发者，是个利器。

一直在用，很香。

分模块细说一下。

一. 错误查询

基本上来说，能反映大部分线上小程序的问题。

然而依然问题不少:

譬如早期的时候，使用官方的navigation-bar自定义组件，刷屏的报错，getClientRect函数未定义，仔细检查代码，确保在调用前是使用了wx.canIUse函数。然而依然大量报错,百思不得其解。报错列表里，还充斥了很多由于基础库、机型不同的兼容错误，这些，无法知道机型、环境，导致很难处理。

评分：4分

建议：

1 . 在错误结果中加入更多的筛选，譬如机型（ios的话能否给出版本？android的话能否给出版本?)

2 . 列表方式可否优化一下？错误的详细stack信息，折叠或者索性提供个详情查看？列表不见得需要直接显示每一个错误的详情，我更需要的是一目了然的列表。

2.实时日志

实时日志，可以将问题发生的“经过”上传到后台并完整储存，不但能够搜索，还能将日志导出，非常方便开发者更加细致地去复盘之前出现的问题，找出问题发生的原因。

从功能性来讲，实时日志是对于错误报警的一个有机的补充。

错误报警其实包含了2方面的内容：a.小程序自身的问题、bug，譬如以上提到的客户端或者基础库在某些情况有bug；b、自身业务代码、业务逻辑的异常报错。

从这两方面来看，实时日志更适用于业务侧的问题。那么问题就来了，对于业务侧的问题，仅仅是一个简单的接入实时日志打印一下是不够的。业务端的日志和统计，大家以前选择的方式无非是自行埋点统计，对于代码有自己的控制权，可以进行一些更详尽、和自身业务更贴近的统计分析处理。这样看来，实时日志的优势相对于自行埋点又在哪里呢？除了接入简单，似乎没有更多了。

评分：3

建议：提供开放api，供自身业务系统读取、统计分析。

3.性能监控

这个没得说，每次发版后的一周，基本是经常查阅的模块.

评分：5

建议：暂无

4.告警设置

聊胜于无，不过对于为什么这个功能是以扫码加到一个专属群里，表示百思不得其解。

评分：4

建议：可否作为功能模块并入小程序助手或者小程序数据工具？配合现在的长期订阅消息，以小程序下发消息的方式做报警提醒岂不是更自然的方式么?

5.小程序测速

小程序里面进行“测速”，之前无外乎几种办法：

1 - 小程序后台”开发“---“运维中心”---“性能监控”。这里能看到一些数据，包括首次打开、下载、渲染等等，但是不能定制，如果想看其他的一些“速度”，无能为力。

2 - 小程序后台“统计”---“自定义分析”中自己创建事件、完善事件字段，并通过api接口reportAnayasis上报分析数据。这种方式可以一用，然而自定义分析一般是用来进行用户行为分析或者结合api上报进行业务数据分析（包括后续的漏斗分析）。拿来做这样软件方面的基本分析似乎也不太合理和专业，查询的时候会麻烦死，而且对于“测速“而言，缺少了很多专业性的指标（譬如运营商-网络环境-等等，当然这些可以通过上报的自定义字段来处理，然而会增加不少小程序端的额外工作）。例如

3 - 自己做一套”测速“统计后台....这个就不说了，麻烦，没必要。

小程序测速，应该说是对于”性能监控”和“自定义上报”的一个强有力的补充，真正做到了”术业有专攻“。 首先是维度比性能监控丰富了许多，地域、运营商、操作系统、网络类型、机型等都纳入了关键维度，可以进行更细粒度的交叉分析。其次，使用上面，比”自定义分析“不知道简单了多少，你唯一需要做的就是：1.定义监控指标，获得监控ID；2. 小程序内接口调用上报时间；3. 后台查看数据。

评分：4

建议：

1 - 自定义维度功能。指南中的例子很简洁，可否更稍详细说明场景和用途，以及常见的一些自定义维度？

2 - net测速和render测速中的默认维度，可否考虑加入”机型“分组（此机型非render测速中的“中高低”档位）。既然用户画像中可以分析出用户的机型（iphone 6，7，8，max、华为mate10、小米等），这里可否按此维度划分机型？不求所有，哪怕访问我小程序的前十机型也可以(这个“高中低”戳中了我的笑点，多高算高？多低算低？这个标准很不严谨。还好没放个“老人机”上来）。

3 - net测速默认维度中是否可以加入地域维度？可以直观的看出server所在机房和不同区域人群速度的关系，便于优化。

4 - 最后，只有7天数据么？颗粒细度最大到60分钟，也就是一小时么？那如何进行直观的优化前后的周/月平均值的对比呢？小程序数据统计、性能监控里面，都有"最近7天、最近30天、自定义时间”这样的维度，以天、月为单位，查看方便，一目了然。

1.错误查询

这个功能还是很不错的，可以很直观的看到小程序线上版本的错误信息，并显示错误代码的具体位置，但是有的使用插件或者其它原因出现的错误提示会给新手造成困扰，不能一眼看出具体是哪里的错误导致的，还需要自己去排查。

2.实时日志

这块功能也很给力，可以快速定位指定排查的用户，并查看用户上报的内容，对于检查因参数错误导致的小程序功能异常解决是有很大帮助。

3.性能监控

个人用的比较多的还是这块，用来查看小程序启动的耗时，如果普遍耗时太多，就尽量想办法优化精简页面代码

4.告警设置

这个用的不多，因为没有做太多的小程序项目，但是前期的时候遇见过告警群内被莫名其妙加了陌生，并在群里发送广告，也无法删除，很长一段时间没有出现这种现象了。

5.小程序测速

这个功能内测的时候就第一时间进行了体验，这个功能给人的第一个感觉就是是不是可以当成访客信息统计来用？我个人是感觉完全没有问题的，因为这里包含了访客来源、运营商、用户系统信息。

但是有一点不方便的就是监控指标需要自己手动添加，在小程序端的配置还需要和后台的一致才可以，如果有多个小程序的话并不能灵活动态去配置这块功能。

总结：维护中心非常适合想要把小程序做精做细人去好好研究和使用，打造优质体验的小程序离不开每一个细节的优化。

刚好最近在做新的产品，其实开发的过程中也遇到一些问题，比如突然手机打开小程序，10s之后就会发烫，后来根据经验以及阅读了开放社区的一些问题答疑，确认了是批量倒计时的js处理不严谨导致的，果然关闭倒计时就解决了这个问题。但是其实在排查这个问题的时候，没有经验是无从下手的。只能根据关键词搜索「性能」「发烫」之类的搜索。。。

还有一次是小程序更新版本之后，首页加载耗时比较久，都是白屏，所以那几天比较关注启动耗时的监测。其实蛮建议小程序开发运维中心可以给个标准参考值，不要每个月才有一个检测结果，这个如果一旦小程序上线发布之后，还是希望周期性能看到小程序的性能报告的。[虽然一个月给一次的性能报告，已经很好了。]

最近每天会看「小程序助手」小程序里面的性能分析，至于PC端对于管理平台的「开发—运维中心」功能，我只是标记了几个重要接口的调用结果回调通知。不会频繁的在PC端观看。

最近也在尝试学习使用小程序的统计菜单栏的行为分析工具，来分析小程序的用户行为，但是目前产品处于冷启动期，现在考虑还有点早。看到楼上的大佬说，动不动10W+的访问量？那么提个小小的建议，小程序可以做压测吗？比方在上线之前，简单的压测一下？这样岂不美哉？

还有最近每天看一下页面内容接入这个功能，但是比较纳闷儿，也跟着文档操作了，就是看不到一些反馈数据，也尝试调用了主动推送搜索参数啊这些，还是没数据？所以这个功能官方有更新的讲解吗？已经根据过往的文档和视频实操了，然而没反馈，这是令人捉急的。

提几个小建议啦~（如果已经有了解决方案，也请大家指个路径哈~）：

1、对于首次使用小程序的一些开发者，其实我真的忍不住再推荐一次，官方的教程，真的很不错。适合初学者快速入门，链接我再放一下哈「https://developers.weixin.qq.com/community/develop/article/doc/0004a40449cdc83c98da481b351c13」

2、比方说在在开发运维管理中心这里，比如说如果遇到性能问题啊，错误啊，之类的，可不可以把相关的一些可能的解决方案附在左侧，点击链接直接跳转至解决方案，这样也可以提高整个小程序的开发氛围，毕竟一个人找解决方案的过程属实有点捉急。【其实我是推荐开放社区的内容，毕竟这里已经沉淀了很多解决方案，也可以让不知道开放社区的小程序开发者关注过来，一起内容共建，轻松开发。】

3、解决方案服务商「比如官方技术大佬可以远程指导解决之类的，但是这个就是不太好控制，可能造成过度人力资源损耗。」

4、小程序助手最好能够有一个报告订阅功能，我其实还是推荐订阅的，可以通过服务通知，每天看到一些关注的信息。在小程序助手上查看。

5、一些最新的接口文档更新，可以在小程序管理后台这里做文档更新通知，毕竟文档更新了，开发者查阅文档其实有的时候检索也需要时间。

6、总结下来，我其实是推荐微信开放社区+小程序管理后台一起使用的。

7、官方的开发者讨论群，这个就难说了，鱼龙混杂，不过还是希望可以链接到一些互帮互助的小程序员们。

七夕快乐~

嗨 只要我不看 那我的小程序就没有报错。。。 这是这么头铁

希望有个服务商的汇总统计的运维后台，一直很需要，一直一直很需要。目前服务商后台很简陋不足以满足运维需求，只是简单的查看统计数据。

1、功能建议：可以在小程序端使用运维相关功能，已经很久没在电脑上登录小程序后台了

2、类似下图的错误信息，完全看不懂是什么意思