共计 3134 个字符，预计需要花费 8 分钟才能阅读完成。
一、为什么要做稳定性建设
1、从熵增定律引出稳定性建设的必要性
物理学上，用“熵”来形容一个体系的凌乱水平。卡尔·弗里德曼提出 熵增定律，他认为在一个关闭的零碎内，如果没有外力的作用，所有物质都会从有序状态向无序状态倒退。
如果咱们不心愿零碎变凌乱，有什么方法呢？答案是反抗熵增定律，反抗熵增定律的办法是借助外力，让零碎从凌乱回归有序。举个例子：
下图中，咱们应用“熵”值来掂量“骰子零碎”的凌乱水平，1（最大值）示意“最凌乱”，意味着咱们不能管制“投骰子”的后果，每次投骰子的后果会在 1~6 随机呈现，零碎体现不稳固；1/6（最小值）示意“最有序”，意味着咱们可能管制“投骰子”的后果，零碎体现稳固，比方咱们心愿每次投筛子的后果都是 6，咱们能够引入舞弊伎俩（即借助外力），让每次投骰子后果都是 6。
熵增定律同样适宜软件系统，一个软件系统刚公布时是有序的，熵值趋于 1，随着一直迭代，缓缓变成凌乱的、软弱的，从而导致线上问题频发，熵值趋于 0，咱们须要借助外力，即稳定性治理伎俩，进步零碎熵值，让零碎复原稳固。
2、稳定性建设的意义
如下图剖析，零碎不稳固会产生真金白银的损失，因而，稳定性建设的意义是：不是让业务多挣钱，而是让业务不丢钱！
3、稳定性掂量公式
① 公式
通过如下公式掂量零碎稳定性：Availability = MTTF / (MTTF + MTTR) ②公式阐明
MTTF (Mean Time To Failure，均匀无故障工夫)，指零碎无故障运行的均匀工夫，取所有从零碎开始正
常运行到产生故障之间的时间段的平均值，即：MTTF =ΣT1/ N。
MTTR (Mean Time To Repair，均匀修复工夫)，指零碎从产生故障到培修完结之间的时间段的平均值，即：
MTTR =Σ(T2+T3)/ N。
③公式量化
通常是“SLA 是几个 9”去掂量，对应下表：
④常见问题
问题：SLA 应该依照哪个维度去定义？接口、利用、业务？
答：都能够，只有讲清楚是接口 SLA，还是利用 SLA，还是业务 SLA 就能够。但留神：提到利用 SLA，应该等于外围接口的最差 SLA；提到业务 SLA 应该等于黄金链路的最差 SLA。
问题：SLA 工夫计算周期应该多少？
答：都能够，次要讲清楚计算周期就能够，个别以年为单位更具代表性。
4、常见误区
①不要认为“分布式环境是稳固的”
认为：网络是牢靠的，带宽是有限的，网络的拓扑不会变，延时为 0，传输开销为 0
理论：网络会抖动，带宽有下限，存在 down 机导致的拓扑变动，存在响应超时的概率，等等。
②不要有“确定性思维”，要有“不确定思维”
认为：恪守教训法令，if x then y。举例：我见过天鹅是红色的，所以世界上所有天鹅都是红色的；这个零碎始终运行良好，所以将来也不会有问题。
应该：世界是不确定的，if x then maybe y。举例：天鹅还有彩色的。
③不要“甩锅”，要有“主人翁精力”
认为：故障是因为他们零碎挂了，咱们只须要打电话告诉一下，缓缓等着复原就行。
应该：提前思考依赖系统故障了，咱们如何让咱们用户尽可能的失常运行；故障呈现了，独特想方法解决问题。
二、业界现状
1、技术现状
互联网的倒退，带来越来越大的流量，为了撑持越来越大的流量，架构也始终在演进：单体利用架构 -> 垂直利用架构 -> 分布式架构 -\> SOA 架构 -> 微服务架构 -> 服务网格。以后风行的微服务架构中，在利用层面、基建层面上都会有一些保障稳定性的机制：
- 利用层面的稳定性保障机制
以 SpringCloud 全家桶为例，提供了很多组件，帮忙咱们保障系统稳定性，如下图：
- 基建层面的稳定性保障机制
基建层面上，也会有一些稳定性保障机制，如下表：
2、落地现状
依据所见所闻，以后技术团队做稳定性治理个别采纳如下 2 种办法：
- 静止式的搞一波稳定性建设
当线上故障频发，通常会搞个“稳定性治理专项”，定义一些治理点，并给出计划，而后静止式的搞一波。个别通过治理后，稳定性会明显好转，然而因为是静止式的搞，随着业务一直迭代，依据“熵增定律”，稳定性又变差。
毛病：不能闭环的搞，治理时稳定性恶化，不治理时稳定性变差，给人感觉技术团队始终出问题。
- 点状的搞，针对每个点专项闭环治理
比方搞个“慢 SQL 治理专项”，通过监控平台发现慢 SQL，给研发发工单，并考核时效；比方搞个“限流治理专项”，让所有接口配置限流参数，配置限流告警策略。
毛病：研发会感觉稳定性专项很多，也不分明价值，有时候会应酬了事，达不到稳定性治理的指标。
三、稳固系治理应该如何发展
将稳定性建设分为 3 个阶段：事先预防，事中止损，预先复盘，针对这 3 个阶段，建设思路别离是：
1、事先预防
稳定性建设实质上是反抗熵增原理的过程，具体是通过一些技术手段（比方超时治理、限流治理、降级治理、慢 SQL 等），提前对系统可能呈现的故障，建设应答措施，从而让零碎依照设计指标去运行。
留神：稳定性治理的伎俩很多，每落实一种治理伎俩，稳定性就能晋升一点，能够列出所有已知的治理伎俩，而后依照优先级一一治理。
2、事中止损
依照稳定性掂量公式（如下图），升高 T2 或 T3 能够晋升 SLA，因而，呈现故障后，应该尽可能的升高 T2 和 T3。升高 T2 的办法是尽快发现零碎呈现故障，须要依赖监控和告警能力；升高 T3 的办法是尽快解决问题，须要先止损后找起因，须要一套明确的 SOP 提高效率。
3、预先复盘
复盘的指标不是定责，而是为防止再犯，因而，在复盘过程中要追到间接起因和根本原因，这 2 者有很大区别：间接起因指的是因果关系，表白“因为干了什么，所以导致什么”；根本原因是流程标准、认知迭代层面的问题，比方“因为分支标准不是 master 上线，导致上丢代码，如果改用 gitflow 则可能可能完全避免上丢代码的问题”。
对于间接起因和根本原因的举例：陈胜吴广起义，间接起因是：下大雨，可能会早退，早退要杀头，所以造反了；根本原因是：秦朝严苛的制度，即便没有那场雨，即便没有陈胜吴广，也会有下一场雨，下一个张胜某广，因为别的起因进行起义。
四、稳固系治理框架
如上一章节所述，当咱们从“事先预防，事中止损，预先复盘”的角度去开掘稳定性治理伎俩，会发现有很多业界风行的伎俩，比方超时治理、限流治理、零碎隔离、常态化压测、慢 SQL 治理等等。
然而技术资源永远无限，可能拿出 15% 的比例做稳定性治理，曾经很不错了；另外，业务的不同倒退阶段须要的稳定性伎俩不一样，不同稳定性治理伎俩的 ROI 也不一样，因而，咱们须要答复一个问题：在无限的研发资源下，如何去循序渐进的去搞稳定性治理。
最佳实际是：搭建一个稳定性治理的框架，把稳定性治理伎俩填充进去，依据业务所处阶段，抉择适宜当下的稳定性治理伎俩，能够通过如下的表格进行治理：
备注：稳定性治理框架建起来后，治理伎俩 能够随时减少、缩小，框架的价值是给咱们一个全景图，让咱们晓得该干什么、在干什么，而不是瞎干。
五、具体治理计划
依据上一章节的稳定性治理框架，接下来要做的就是针对某个治理伎俩，出具体的治理计划，要求具体计划可能造成闭环，并融入到研发过程中去，比方：
- “慢 SQL 治理”的落地计划
- 定义慢 SQL 的规范，即执行工夫超过多少 ms 算慢 SQL
- 通过监控平台发现慢 SQL
- 给研发负责人发治理工单
- 验收治理成果
- “超时治理”的落地计划
- 为每个接口定义适合的超时工夫
- 每周巡检一次接口，发现超时工夫不合理的接口
- 修改超时工夫
六、写在最初
稳定性治理是一个长期的过程，要把稳定性的工作融入到研发过程中，一方面要无意识尽量别埋坑，比方微服务强调中间件隔离，咱们就不要混用中间件了，另一方面稳定性问题要一步到位，比方治理超时工夫，要有个残缺标准定义超时工夫，并在研发过程中对新增接口、历史接口都配置正当，且可能动静更新。
作者：京东物流 郑传洲
起源：京东云开发者社区 自猿其说 Tech 转载请注明起源
