预防
发布环境
云构建(jenkins/gitlab等)，发布环境要稳定统一，不能每个人本地发布
代码规范
eslint\eslint-plugin-html\eslint-plugin-vue\eslint-plugin-sonarjs\eslint-plugin-import。。。
再搭配些适合自己项目的特殊自定义eslint插件，并使用husky强制推送前执行eslint校验
这些可以避免一些基础的语法问题，比如计算属性不能返回promise（我们之前曾有人这么写过。。）并维持代码简洁等
typescript
代码静态检查，防止静态代码错误
代码必须通过merge的方式合入主分支，不能直接push
codeReview
每个迭代，每次提交都要过codeReview
日志/埋点上报
在代码中的核心流程、异常情况处都要上报埋点。或者日志量不大的情况下直接全量上报console等爆出的日志。这些日志要有地方查询
服务端接口日志
每个接口应返回唯一id值，并能根据这个id查询该请求的完整信息（包括接口失败原因）。这样当前端捕获到接口问题后，可以及时排查是前端传参问题还是后端出错
功能开关
上线的一些可能不稳定的功能应通过开关配置线上是否开启，关闭后线上该功能直接就下掉了
功能/应用降级
代码中可能不稳定的地方要有降级方案，比如核心图片如果加载失败怎么显示，代码中要处理好。所谓应用降级是指如果存在多个端的应用，如果一个端出问题，可以引导用户跳转到另外一段。比如app出问题了，我app给个降级页面，这个页面引导用户跳转到微信小程序等
感知
数据大盘 + 异常报警
建立一些数据大盘，除了能看到实时的pv、uv数据等，还能在数据异常时触发报警。 报警可以分级，最高级别直接打各个相关人员电话报警，最低可以发邮件/微信/短信等
微信用户反馈通知
微信有个用户反馈的模块，并可以通过服务端接口获取，因此可以自己在服务器上定时收集用户反馈并通知相关用户或群
微信/钉钉告警群
微信小程序可以把线上错误报警到微信群，支付宝小程序可以报警到钉钉群
产品或客服反馈群
当客服收到用户反馈的线上问题，应有渠道联系到开发人员
用户提示
当发生错误时，应用往往会弹出提示，这个提示应该要能简单的区分前后端错误，比如服务端提示可能是系统繁忙，请稍后重试等，那前端出错应做不同的提示，比如系统错误，请XXXX等。这样当用户截个图或者录屏说我怎么弹这个提示，你就可以明白这是哪端的问题
线上问题处理
定位
当收到告警或反馈问题时，应能通过日志查询问题
微信小程序后台有错误日志可供查询，我们自己也应该有些查询渠道，比如埋点日志等
处理
定位到问题后，根据问题来确定处理方式
- 问题功能是否可通过开关直接下掉
- 是否有降级手段
- 是否能回滚
- 增发
问题复盘
当出现线上问题后，要及时复盘并记录，看看造成问题的原因以及是否可以避免
流程/制度
灰度发布
发布时不能直接上线，应有灰度过程
值班制度
每天必有人值班去关注线上告警和他人反馈的线上问题，并记录处理结果
技术方案评审
每个需求制定的技术方案，应明确的指出其整个需求的逻辑，和是否有稳定性影响，如果有要明确其是否有对应的监控手段、功能开关、降级手段
