这是阿里技术2022年的第17篇原创文章

（ 本文阅读时间：20分钟 ）

一个小小的故障就可能造成巨大的负面影响，因此稳定性工作复杂却又至关重要。本文将通过故障预防、修复、复盘来讲解该如何建设一个稳定性体系。

来到阿里后，我的工作内容一直都是商品中心的稳定性，这份工作对于我个人在技术和经验上的成长提升是无比巨大的。在我看来，稳定性是一个极为复杂的工作，对人的能力考验极大，本文希望和大家一起了解：

• 稳定性是做什么的？
  
  
• 稳定性到底怎么做？
  
  
• 做好稳定性，需要什么样的能力？
  
  
• 怎么从稳定性零散的事情中创造价值？
  

01

什么是稳定性

1.1 稳定性的定义

在我看来，稳定性工作是指日常保障系统安全生产的同时，利用技术手段以及规范开发流程，使系统在不断的业务迭代中熵增达到最小化的一种工作。作为一家互联网公司，稳定性工作本质上就是保障安全生产。一个故障，就可能会造成很大的负面影响，举例几个之前有过耳闻的故障：

• 某故障使下单阻塞，导致某线下业务受到很大影响；
  
  
• 很多年前春节时订正数据，由于脚本问题，导致部分订单被确认收货；
  
  
• 由于arguments版本不一致，同时进行了无灰度的操作，导致某业务大范围宕机；
  

由此可见，集团内部的故障，轻则影响用户体验、商家体验，重则对人民财产造成重大损失；因此，保障安全生产是企业发展的头等大事。

1.2 稳定性岗位的工作内容

稳定性的事情看上去可能比较散，但结合我自己的思考，我将稳定性的价值体系划分为几个方面：

✪ 1.2.1 日常稳定性

⍟ 业务保障

大促保障、业务日常的答疑等等，通过这些事情，稳定性同学会与业务同学配合，从底层性能、技术层面，更好地推动业务向前发展。日常的答疑工作是稳定性同学投入时间最多的内容之一，很多问题都会第一时间流入到稳定性同学手中：

• 技术问题：应用架构不了解，或由于系统稳定性问题导致上游出现限流、超时等；
  
  
• 大促问题：很多关于大促的问题，大促跨域合作的横向事宜等；
  
  
• 业务问题：日常碰到的影响业务体验的问题，比如某些业务出现了阻塞或者数据错误等。
  

对于体量较大、较为核心的团队，一天涌入的问题是很多的，我们的思考和处理方案如下：

• 技术支持：所有问题的入口，首先通过答疑群接触到的就是技术支持同学，这部分能cover大部分的问题；
  
  
• 每周答疑：技术支持并不深入了解底层业务和代码，对于他们无法处理的问题，会流转到每周答疑同学身上，由商品域的同学每周轮换，负责答疑和发布；
  

✪ 1.2.2 大促 & 活动保障

稳定性另一个核心就是负责大促和重保活动。每一次大促，上到业务，下到中台、基础设施，都需要抽出人力进行保障，每个域的稳定性同学则是其中的中坚力量。下面我着重从流程和内容上讲一下大促保障手段，可能不同同学面临的场景不同，但整个理论应该是相通的：

⍟ 保障流程

• 大促准备：活动开始前开始进行一系列准备工作，如入口流量、各应用容量的评估，预案、规则的梳理，建站压测等。
  
  
• 全链路加固：这个阶段会根据正式期的流量模型进行频繁的压测来找出系统问题，建立相关的监控防线，压测会一直持续到正式期开始。
  
  
• 作战保障：从压测期间发现的具体问题出发，逐个解决，并制定相关的作战手册等，完善大促保障机制。
  
  
• 大促预热：这个阶段一般在大促正式期前几天开始，一般会执行一些清理和重启的任务，混部扩容以及一些提前执行的预案、预热任务等也会启动。
  
  
• 大促保障：正式进入保障期，核心作战时间保障活动，盯盘，发现问题及时播报；峰值结束后，需要关注相关预案及资源是否下线。
  

⍟ 工作内容

大促稳定性保障的工作比较复杂，在这里先放一张图，让没有参与过大促的同学来点体感：

虽然看起来简单，但真实的保障过程远比这些事情更多，面临的压力也比想象的大很多，即使在大促日渐常态化的今天，参与大促保障、经历阿里千万级复杂流量模型洗礼仍然是提高个人能力的最佳方式。

✪ 1.2.3 优化专项 & 链路治理

保障业务不断发展时，由于系统不断的迭代，必然会导致熵增，原来可能较为稳定的链路，会因为迭代而不断腐化。同时，如618、双11等大型活动，也不断挑战系统的极限。一句话来总结：业务发展（系统变更）不断的挑战着我们系统的稳定性，我们需要持续不断的进行性能优化，保障系统的高可用，来适应越来越庞大的业务。不同的优化专项，在不同的场景下做法可能也不同，风险也会比日常的需求高很多。

⍟ 产生变更

随着业务不断的迭代，不可避免地会发生变更，如更新代码、发布配置或做运维层面的变更等，而这些变更则可能引入一些未知的问题，这些问题可能会瞬间暴露出来，或积压一段时间后喷涌式的爆发，一般来说，后者产生的影响可能会更大一些。

⍟ 发现问题

故障定级经常会讲提前发现，如果能够提前发现故障，不仅能降低或者避免因故障带来的损失，也能将故障等级缩小。那么，如何主动发现由变更产生的问题？这一部分则要依赖稳定性建设时比较重要的一环 — 监控告警：

• 我们在上线业务代码前，根据自己判断出的可能产生问题的点，输出的业务日志告警。
  
  
• 容器与中间件性能相关的全景监控大盘。
  
  
• 在线与离线等数据对账相关的大盘。
  

当然，监控不可能百分之百覆盖到所有的问题，也有很多问题会从其他侧反馈过来，此时就要盘点出自己的监控体系中到底还有哪些疏漏，并逐渐完善。

⍟ 解决问题

大致为高可用问题和数据一致性问题两类，针对不同场景有不同的解决方法，高可用问题大家可能比较熟悉了，优化起来目标也比较明确，技术难度有高有低，不详细展开讨论。

✪ 1.2.4 成本缩减

大部分的性能优化，提升系统的性能仅仅是一方面，另一个作用则是通过性能优化提高的性能压缩技术成本。同时，效能提升也是与稳定性同学有关的一件事情，通过制定更好的开发规范以及流程，来帮助同学们提高开发体验和工作效率，也可以将更多的时间投入在业务发展上，来进一步促进业务发展，从而形成一个良性循环。在我个人看来，我将成本划分为两类：

⍟ 效能提升 — 人力成本

人力成本受开发效率影响，效率越高，一个需求需要的人力成本就越低；影响人力成本的原因有很多，解决方案这里不继续展开，简单列举几个会影响到人力成本的因素：

• 软件复杂度：不合理的架构设计，以及拥有很长时间历史包袱的应用，由于其代码的复杂度越来越高，会让开发人员的开发效率明显降低，要定时对应用中的代码进行重构，增加可读性。
  
  
• 测试 & 回归：作为开发过程中的重要一环，为了降低故障频率，自测往往占据了比开发更长的时间，因此提升自测的效率和准确度尤为重要。
  
  
• 工作流程：不合理的流程也会拖慢工作进度，如工作分配不合理，责任互相推诿等；对工作职责的细分没有明确的定义，或者对于问题的推进没有严格的流程和产品化的工具，是这个问题发生的核心原因。
  

⍟ 资源管控 — 技术成本

技术成本主要分为两类：

• 计算成本：以内存运算为主，如容器、计算型中间件、外部平台等，往往流量越高则产生的计算成本越高，因此管控计算成本可以从链路、性能优化上入手，让同等流量下所需要的算力降低。
  
  
• 存储成本：DB等偏重于存储的中间件，存储的数据越多，占用的磁盘空间越大，存储成本则越高，因此管控存储成本可以从数据治理入手。
  

计算成本与存储成本并不是完全分离开的，举例缓存，空间存储等中间件，往往是计算（读写操作）与存储并存，那核算成本的方式以长板为主。

在成本缩减中，技术成本占的比例是最高的，如何帮助缩减掉业务增长时疯狂扩张的成本，也是稳定性同学的一个重要课题。