为什么要做稳定性保障？

以前写过不少和稳定性相关的文章，其中介绍了不少稳定性保障的实践案例和方法，比如全链路压测和服务治理，这些案例和方法更多的是技术层面解决问题的方法和手段。但为什么要做稳定性保障？如何理解稳定性保障？以前一直没太想明白。最近整理之前的技术笔记，翻了很多资料，对这个问题的理解开始清晰了。

这篇文章，我想聊聊我对于稳定性保障的理解，以及稳定性保障对团队带来的价值。

什么是稳定性保障？

通俗来说，稳定性是一个很抽象的术语，各人有各人的解读。在技术领域，稳定性保障相对来说就很好理解，一句话概括的话，就是：少出线上问题，尽量别影响业务正常运营。但是业务是不断迭代的，复杂度和迭代的频率在不断加快，同时业务的迭代对技术提出了更高的要求。为了满足业务需要，技术架构也在不断迭代和扩展。从早期的单体架构，到集群、分布式、微服务、容器化、云原生各种方法论和技术实践。

单位时间内变更的次数多了，系统更复杂了，同时流量也起来了，这个时候影响稳定性的因素就多了，典型的案例就是电商大促：从双 11 到 618，然后到现在的各种促销节购物节。为了解决这种复杂业务和架构下可能出现的问题，就诞生了诸如全链路压测、服务治理、异地多活等各种技术实践。

如果要给稳定性保障一个比较通用的定义，那这个公式大概是成立的：稳定性保障=良好的架构设计实现+完善的软件研发交付流程+持续的线上应急机制和方法+专业的技术团队+优秀的项目管理和团队协作。

为什么要实践稳定性保障

基础技术设施和稳定性保障体系的建设，是业务长期倒逼的产物。举个典型的例子：双 11 大促。

• 为了提升 GMV，要开展一次营销活动；

• 营销活动有大量的引流和复杂的活动玩法；

• 引流带来更高的流量，复杂的活动带来更复杂的编码实现；

• 更高的流量和复杂的技术实现导致影响稳定性的因素变多；

• 线上不稳定因素越多，营销活动无法正常运行的概率越大；

• 营销活动出问题，业务目标未达成，技术没有做到支撑业务发展；

结果：技术要优化改进，减少线上问题，支撑业务目标达成，体现技术存在的价值！

如何支撑业务目标达成，甚至让业务目标更轻松的达到更好的目标呢？做好线上的业务和系统稳定性保障！知道了目标，接下来就是拆解目标、设计优化方案、开展技术实践、验证结果。

稳定性保障对团队的价值

业务对技术团队的要求，无非这三点：快速实现需求+快速响应变更+高质量的交付。要满足这三点要求，技术团队要做的就是在降本增效的前提下，保证质量在一个水准线之上。

快速实现需求和响应变更，需要提高效率，如何提高效率呢？除了简化流程、高效沟通外，还需要学会利用工具的优势来赋能技术同学更专注于理解和响应业务。很早以前我们实现一个需求，往往都是通过项目的方式实现，实现过程和沟通效率很低。后来出现了清单、看板等信息可视化方法，提高了这个过程的部分效率。再后来开始出现了各种定制化的平台，直到现在的低代码、人工智能等，这些都是通过技术实践带来的效率提升。

从软件工程的角度来，影响质量的三要素有范围、时间和成本。要保证质量在水准线之上的高效率交付，就要在这三者中取平衡。所以出现了 mvp 方案（小步快跑）、CICD 流水线（快速交付）、容器化云原生（降低硬件和维护成本）等各种方法和工具。这其实就是技术迭代和优化带来的优势。

总的来说，稳定性保障对业务的价值在于：保证用户体验，满足业务诉求，支撑业务目标达成。

对技术团队本身来说，其价值在于：

• 赋能技术同学更了解业务；

• 通过工具提升了研发效率，降低技术成本；

• 通过技术优化体现了先进方法的优势以及技术的价值；

一张图概括稳定性保障的价值：