一、线上稳定性
目标：及时响应，及时处理
实现：“监控体系”接入
排期：11月-12月
1.1 监控数据类型
基础数据监控：静态资源加载错误、JS错误、接口请求错误
业务监控：业务数据（登录成功率、跳出率、退出率、转化率等）
监控工具：Arms or 公司自研
1.2 告警管理
1.2.1 指标计算
| 告警指标 | 是否考虑 |
|---|---|
| 静态资源加载失败率 | 是 |
| JS错误率 | 是 |
| JS错误影响率 | 是 |
| 接口错误率 | 是 |
| 白屏率 | 是 |
1.2.2 告警规则
告警规则和告警阈值设定
1.3 日志
1.4 定位
二、交付稳定性
交付稳定性主要围绕工程建设，具体包括实验环境、自动化测试、CI/CD流程等工程化手段来提高研发效率和质量，进而保证项目交付稳定性。
1）明确环境配置
交付环境配置：目前项目对应的交付环境有 - 泳道、测试、生产，后续根据服务资源考虑是有允许提供“预生产”环境，如果没有预生产环境也可使用灰度代替。
浏览器配置：考虑兼容的浏览器类型（chorme、Firefox、Safari、IE）
2）测试交付
目标：提高上线前测试阶段稳定性
实现：建议确立一个提测阶段稳定性衡量参考指标
原因：测试阶段的稳定性一直以来被忽视的，原因有很多：开发周期紧张、自测时间不充分等。有时候开发人员自己都没有将流程走一遍就直接提测了，这样就会导致很多问题：
- 测试人员测试效率降低，测试时间拉长，迭代周期拉长；
- 开发人员在进行返修的时候并不能保证之前已经测过的功能不受影响，进而导致重复测试；
- 测试问题过多的时候就会掩盖掉一些边界问题的出现，进而影响线上稳定性。
因此，如果我们在测试阶段就能保证稳定性，那么就能加强线上稳定性。相反，如果测试bug过多，那么即使上线前都修复了，但是线上往往还会出现其他意想不到的问题。
注：这里不做强制，目的是为了树立团队成员的稳定性意识
3）产品验收交付
灰度发布
4）线上交付
三、开发稳定性
1）增强业务组件化开发
为了保证外包开发人员的代码质量，除了通过代码CodeReview && 测试把关之外，还需要在代码编写层做相应的限制。
对于业务中通用的功能模块进行复用，而这些复用的功能模块往往是稳定性比较高的，因此我们需要尽可能多的发现并封装通用模块（团队内通用模块或项目通用模块）来外包人员对这部分代码的编写量，从代码的编写方转化到组件的使用方，进而达到限制的目的。
2）增强配置化建设
低代码搭建：对于一些表单构建可以通过低代码搭建
数据配置化：对于搜索展示页面可以通过数据配置化来代替代码编写，降低bug率
3）历史代码重构
针对核心模块
针对历史代码影响业务迭代周期的模块进行重构
