稳定性建设框架 | 京东物流技术团队

京东云开发者
• 阅读 185

一、为什么要做稳定性建设

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治理”的落地方案
  1. 定义慢SQL的标准,即执行时间超过多少ms算慢SQL
  2. 通过监控平台发现慢SQL
  3. 给研发负责人发治理工单
  4. 验收治理效果
  • “超时治理”的落地方案
  1. 为每个接口定义合适的超时时间
  2. 每周巡检一次接口,发现超时时间不合理的接口
  3. 修正超时时间

六、写在最后

稳定性治理是一个长期的过程,要把稳定性的工作融入到研发过程中,一方面要有意识尽量别埋坑,比如微服务强调中间件隔离,我们就不要混用中间件了,另一方面稳定性问题要一步到位,比如治理超时时间,要有个完整规范定义超时时间,并在研发过程中对新增接口、历史接口都配置合理,且能够动态更新。

作者:京东物流 郑传洲

来源:京东云开发者社区 自猿其说Tech 转载请注明来源

点赞
收藏
评论区
推荐文章
皕杰报表之UUID
​在我们用皕杰报表工具设计填报报表时,如何在新增行里自动增加id呢?能新增整数排序id吗?目前可以在新增行里自动增加id,但只能用uuid函数增加UUID编码,不能新增整数排序id。uuid函数说明:获取一个UUID,可以在填报表中用来创建数据ID语法:uuid()或uuid(sep)参数说明:sep布尔值,生成的uuid中是否包含分隔符'',缺省为
作业帮上万个 CronJob 和在线业务混部,如何解决弱隔离问题并进一步提升资源利用率?
作者吕亚霖,作业帮基础架构架构研发团队负责人。负责技术中台和基础架构工作。在作业帮期间主导了云原生架构演进、推动实施容器化改造、服务治理、GO微服务框架、DevOps的落地实践。别路,作业帮基础架构高级研发工程师,在作业帮期间,负责多云K8s集群建设、K8s组件研发、Linux内核优化调优相关工作。背景作业帮在云原生容器化改造的过程中,随着
Stella981 Stella981
2年前
B站微服务框架Kratos详细教程(2)
背景在像微服务这样的分布式架构中,经常会有一些需求需要你调用多个服务,但是还需要确保服务的安全性、统一化每次的请求日志或者追踪用户完整的行为等等。你可能需要一个框架来帮助你实现这些功能。比如说帮你在一些关键路径的请求上配置必要的鉴权或超时策略。那样服务间的调用会被多层中间件所过滤并检查,确保整体服务的稳定性。设计目标
Wesley13 Wesley13
2年前
mysql设置时区
mysql设置时区mysql\_query("SETtime\_zone'8:00'")ordie('时区设置失败,请联系管理员!');中国在东8区所以加8方法二:selectcount(user\_id)asdevice,CONVERT\_TZ(FROM\_UNIXTIME(reg\_time),'08:00','0
Wesley13 Wesley13
2年前
Java日期时间API系列36
  十二时辰,古代劳动人民把一昼夜划分成十二个时段,每一个时段叫一个时辰。二十四小时和十二时辰对照表:时辰时间24时制子时深夜11:00凌晨01:0023:0001:00丑时上午01:00上午03:0001:0003:00寅时上午03:00上午0
Wesley13 Wesley13
2年前
MySQL部分从库上面因为大量的临时表tmp_table造成慢查询
背景描述Time:20190124T00:08:14.70572408:00User@Host:@Id:Schema:sentrymetaLast_errno:0Killed:0Query_time:0.315758Lock_
京东云开发者 京东云开发者
2个月前
【稳定性】浅谈团队如何做好系统稳定性
背景稳定性建设需要一系列具体的建设活动推进和落地,这些建设活动涉及人员、机制和文化,全方位的建设活动才能更好地落实建设模式。一、稳定性保障机制稳定性涉及团队所有不同水平技术人员、所有系统、研发所有环节、线上时时刻刻,单个技术人员是无法保障好的,必须建立团队
京东云开发者 京东云开发者
10个月前
SpringCloud-Hystrix服务熔断与降级工作原理&源码 | 京东物流技术团队
在生活中,如果电路的负载过高,保险箱会自动跳闸,以保护家里的各种电器,这就是熔断器的一个活生生例子。在Hystrix中也存在这样一个熔断器,当所依赖的服务不稳定时,能够自动熔断,并提供有损服务,保护服务的稳定性。在运行过程中,Hystrix会根据接口的执行状态(成功、失败、超时和拒绝),收集并统计这些数据,根据这些信息来实时决策是否进行熔断。
京东云开发者 京东云开发者
8个月前
【稳定性】稳定性建设之弹性设计 | 京东物流技术团队
弹性设计为系统稳定性建设提供了一种新的视角和方法,它有助于提高系统的可用性、性能和安全性,同时也降低了维护和修复的成本和风险。
京东云开发者 京东云开发者
2个月前
稳定性方法论:可灰度 & 可监控 & 可回滚
业务系统核心目标是挣钱,系统稳定性建设核心是防止丢钱(丢钱逻辑如下图所示),站在公司的角度看,产品功能建设和系统稳定性是同等重要。前段时间写了《》,该文章在稳定性建设的理论和实践基础上,抽象出稳定性治理的框架,希望建立一个稳定性治理的标准动作、最佳实践。但