一、为什么要做稳定性建设
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 转载请注明起源