稳定性建设泛谈

稳定性建设

目前在公司听了两场关于稳定性的讨论，一场是内部周会上的，还有一场是会议上分享的，这边也说下自己认为的稳定性，供大家一起讨论。

首先稳定性这个东西就比较虚，怎么拆分细化，转变成比较实在的东西？
首先从技术角度来看，可以从质量，性能，可用性，健壮性四个维度来说。

1. 质量：简单的来说就是提高代码逻辑准确性，减少错误率和crash率，达到一个高质量标准。
2. 性能：在较少的时间内完成任务，可以分库分表，缓存，异步，算法优化，搜索引擎(Elasticsearch)
3. 可用性：几乎任何时刻服务都在可用状态
4. 健壮性：在遇到问题时依旧可以支撑服务，比如遇到某个系统故障，最少程度或者不影响其他系统的运行，前端可以展示友好的兜底页面来避免不友好的行为；比如高峰期，服务达到峰值，采用限流等；一般常用的预防灾备能力手段有服务集群，降级，限流，隔离等，对于客户端来说就是处理好异常(接口异常)情况下的逻辑，保证不crash，做好边界处理。当然还包含扩展性，为未来可能达到新的挑战时，有一定的扩展能力，正是所谓的未雨绸缪

说了以上4点，怎么进行实质的措施，简单来说监控。监控比较广，一个是接口监控，比如说可以通过网关日志来统计分析；一个是服务器的监控，当某个服务器快达到峰值时，自动扩容；一个是业务监控，有时候虽然接口数据都正常返回了，但是数据不准确；客户端前端日志数据监控，观察其稳定性和体验情况

最后一点就是事故的处理和报备。开发：快速定位解决问题 产品&运维：在完全修复问题之前的降级方案是否能达到产品的预期，运行状况是否可以接受，运营活动是否可以接受
大多数时候，业务组处理并决定方案即可；但是有些时候事故特别严重，有可能还要往上报备，可能需要公关处理，甚至惊动高管层。

大的如上，细的可能就需要落实到每一个点。一般问题反馈流程：问题池(客服，监控系统，用户等)->技术支持或者测试人员(定位问题)->相应人员解决
这也需要每个业务模块有相应的负责人，遇到问题相应负责人快速定位和解决问题