业务系统最重要的是什么？
“稳定，稳定，还是tm的稳定”
什么样子的系统才算做稳定的系统？
假设一个场景A，你需要上线一个新的需求A，涉及功能B的改动，有依赖于B功能的服务C和D，你上线的时候不确定B的改动是否会影响C和D的业务，这种系统是稳定的系统吗？
再假设一个场景B，有用户反馈，有时候操作A功能的时候，响应比较慢，但是比例非常的小，上线为止收到过几起这样的反馈，那么这种情况下，系统是稳定的吗？
最后一个场景C，业务A上线之后，切流了一部分用户使用，目前没有相关使用不良的反馈，现在这个功能或者说这个系统能接入核心链路吗？
系统稳定的几个特征
可预测，可监测，可处理
可预测：
可预测包含正常流程处理(关联方影响范围预估)，异常链路处理，灰度流量切换数据影响等等；总结起来简单就是一句话，上线的业务需要清楚影响范围是什么。
可预测范围内的结果，不仅仅是在设计阶段的可预测，还需要能够进行预测结果的验证。进行线上故障的模拟包括(存储、应用、第三方资源的异常模拟)，用来确认预测结果的正确性，以及预案处理的正确性。
可监测：
这部分更多的是系统运行态的监测；更多的用来感知系统健康度的，也是实操性比较强的部分，就像医院有多种仪器来检测你的身体状态；监测指标有多项，主要包含 业务监控、系统应用监控；
业务监控：一般上线都需要对于核心业务进行大盘监控，来进行相关业务指标的监控，包含流量监控，异常监控等等
系统应用监控：这部分可能更关注于细节或者技术方面；
例如是java系统，机器/容器相关的指标需要进行监控，内存，负载，磁盘io，网络流量，gc情况；
外围接口的访问成功率，RT，流量 等指标也是需要关注的，包含环比和同比；
中间件相关的指标，MQ的堆积，SQL的执行频次及效率；
应用系统自身异常日志的打印，分布式应用集群的负载及整体健康状况。整体链路多阶段的任务巡检(例如核心流程较长，需要异步化处理导致可能部分数据假死情况，也需要巡检机制介入)。
可处理：
这部分的关注点是系统运存不符合预期后续的处理措施，需要是及时的，有预案的，简单可实操的；例如灰度过程中产生异常能够迅速的处理;上线功能A和B之间有关联影响，有兜底策略处理，有相关的止血方案；
系统的稳定一些实践：
1、架构设计阶段：
- 明确系统间交互的依赖关系，核心链路系统不依赖非核心系统，系统间要有合理的解耦方案；
- 异常流程有兜底处理，保证数据的完整性；
- 接口设计/调用 之间预估流量，做好系统的保护；
- 做好资源、服务相互之间的隔离性，对于中台化或者多租户的业务场景，需要尽可能的控制故障发生的爆炸半径，这个需要做到隔离性
2、编码阶段：
编码设计阶段，使用相关设计模式，遵守开闭原则，降低功能修改带来的业务不确定性；
统一的内部编码规范，模块之间相互独立，层于层之间有明确的界限；业务日志/系统日志打印的规范性，对于业务流程点做好相关埋点，为及时发现问题、定位问题、解决问题提供一手的现场；
3、上线运行阶段：
统一的上线流程规范，降低上线中的风险；
线上运行必须要相关的监控机制，谨慎对待线上的每个异常情况；
建立自动化的业务分析(之前的大盘等)，提供分析数据来源，建立数据化，可视化的系统概览；
系统依赖的基础设施，需要分析(大部分基础团队有相关分析，可以不用过度关注，但是对于影响业务场景的还是需要自己进行分析，例如慢sql和top sql之类的)；
4、其他：
- 稳定性定时演练(压测、故障演练等)；
- 变更流程化，配置变更/数据变更需要有审批或者双向校验的过程，降低人为变更带来的错误风险；
- 组件使用最佳实践沉淀，控制不当使用风险持续蔓延，信息交互，降低 重复问题产生风险及概率
- 意识大于一切，培养人员稳定性意识，面向失败设计、面向失败编码、线上问题的及时响应及关注是稳定性最重要的心智。
