系统的稳定性，主要决定于整体的系统架构设计，然而也不可忽略编程的细节，正所谓“千里之堤，溃于蚁穴”，一旦考虑不周，看似无关紧要的代码片段可能会带来整体软件系统的崩溃。
稳定性的工作，一般都是水下的工作。就像冰山，真正强大的系统下，要有更加强大的底层支撑，水面下的问题才是真正需要解决的问题。当然不一样的工作内容，水下的工作是不同的，对于盖楼来说，可能就是地基的深度。对于我们写业务逻辑来说，水下的工作就是CatchException的处理，异常情况的处理。对于系统来说，水下的工作可能是一些接口系统的稳定性。类似于金字塔结构，下层基础决定上层建筑。对于软件系统来说，稳定性至关重要。
在严苛的服务级别协议背后，其实是一些列规范要求来进行保障。
2021年全球重大的系统事故，其中不乏亚马逊、特斯拉、Facebook等行业巨头。
机构名称
持续时
长
影响范围
原因
亚马逊
2021年
12月
约3小时
全球亚马逊云计算服务
数据中心及网络连接问题
特斯拉
11月
约5小时
特斯拉App全球范围
服务中断
配置错误导致网络流量过载
10月
约7小时
Facebook及旗下Messenger、Instagram、WhatsApp等多个服务
运维操作失误
哔哩哔哩
7月
约1小时
哔哩哔哩视频播放、
直播等多项服务
机房故障，灾备系统失效
Fastly
6月
系统漏洞被配置更改操作触发
推特
3月
约2小时
系统内部错误
滴滴打车
2月
滴滴打车APP
美联储
约4小时
美联储大部分业务
操作失误
我们先看下百度百科对稳定性定义：
系统稳定性是指系统要素在外界影响下表现出的某种稳定状态。
其次维基百科对稳定性定义：
稳定性是数学或工程上的用语，判别一系统在有界的输入是否也产生有界的输出。
若是，称系统为稳定；若否，则称系统为不稳定。
简单理解，系统稳定性本质上是系统的确定性应答。
从另一个角度解释，服务稳定性建设就是如何保障系统能够满足SLA所要求的服务等级协议。
GoogleSRE中(SRE三部曲[1])有一个层级模型来描述系统可靠性基础和高层次需求(Dickerson'sHierarchyofServiceReliability)，如下图：
该模型由GoogleSRE工程师MikeyDickerson在2013年提出，将系统稳定性需求按照基础程度进行了不同层次的体系化区分，形成稳定性标准金字塔模型。
金字塔的底座是监控(Monitoring)，这是一个系统对于稳定性最基础的要求，缺少监控的系统，如同蒙上眼睛狂奔的野马，无从谈及可控性，更遑论稳定性。更上层是应急响应(IncidentResponse)，从一个问题被监控发现到最终解决，这期间的耗时直接取决于应急响应机制的成熟度。合理的应急策略能保证当故障发生时，所有问题能得到有序且妥善的处理，而不是慌乱成一锅粥。事后总结以及根因分析(Postmortem&RootCaueAnalysis)，即我们平时谈到的“复盘”，虽然很多人都不太喜欢这项活动，但是不得不承认这是避免我们下次犯同样错误的最有效手段，只有当摸清故障的根因以及对应的缺陷，我们才能对症下药，合理进行规避。
假设一个系统从初次发布后就不再进行更新迭代，做好上述三个方面的工作就能基本满足系统对于稳定性的全部需求。可惜目前基本不会存在这样的系统，大大小小的应用都离不开不断的变更与发布，因此要保证系统在这些迭代中持续稳定，测试和发布管控(Testing&Releaseprocedures)是必不可少的。有效的测试与发布策略能保障系统所有新增变量都处于可控稳定区间内，从而达到整体服务终态稳定。除了代码逻辑更新，迭代同样可能带来业务规模及流量的变化，容量规划(CapacityPlanning)则是针对于这方面变化进行的保障策略。现有系统体量是否足够支撑新的流量需求，整体链路上是否存在不对等的薄弱节点，都是容量规划需要考虑的问题。
位于金字塔模型最顶端的是产品设计(Product)与软件研发(Development)，即通过优秀的产品设计与软件设计使系统具备更高的可靠性，构建高可用产品架构体系，从而提升用户体验。
防火的最高境界是，防患于未然。这也就催生了，现代软件系统里面，大家把更多的精力放在事前（全链路压测和故障演练方面）。
影响稳定性的主要在两个阶段，一个阶段是非运行期，一个阶段是运行期。非运行期主要就是我们日常进行开发的时候，技术方案设计，代码书写，线上操作配置等引发的稳定性问题。运行期主要是因服务自身问题、外部调用问题，外部依赖问题引发的稳定性，所以治理也主要从这两个方面出发。
接下来会以上线前、上线中、上线后三个阶段进行总结稳定性治理。
很多时候我们都以为系统稳定只是线上运行稳定就好了，但事实上需求研发流程是否规范，也会极大地影响到系统的稳定性。试想一下，如果谁都可以随便提需求、做的功能没有做方案设计、谁都可以直接操作线上服务器，那么这样的系统服务能够稳定得了吗？所以说，需求上线前的过程也是影响系统稳定性的重大因素。
在我看来，在上线前这个阶段，主要有三大块非常重要的稳定性建设内容，分别是：
研发流程规范，指的是一个需求从提出到完成的整个过程应该是怎样流转的。一般的需求研发流程包括：产品提出需求、技术预研、需求评审、技术方案设计、测试用例评审、技术方案评审、测试用例评审、需求开发、代码评审、需求测试。不同公司根据情况会有所调整，但大差不差。
如果能够处理好上述几个节点，那么就能够极大地降低研发流程导致的问题。这里每个节点都有很深的学问，这里就不展开讲了，我们主要说个思路。
研发团队最希望拿到的需求是真正有业务价值的需求，而不是一个短期或临时的需求，因为如果是一个临时需求的话，往往对应的解决方案也是临时的，如果太多临时的解决方案遗留在系统中，久而久之将会变成巨大的“技术债”，总有一天会爆发，对系统稳定性及业务迭代速度造成巨大影响。
另外有一点比较重要的是，通过需求评审，不仅仅是评审产品业务需求，更重要的是需要研发挖掘出一些非功能需求，包括性能指标要求、依赖三方接口qps、安全等要求。
对于编码规范、技术方案评审、代码评审、发布计划评审，这里重点讲一下这四点。
对外接口命名方式、统一异常父类、业务异常码规范、对外提供服务不可用是抛异常还是返回错误码、统一第三方库的版本、哪些场景必须使用内部公共库、埋点日志怎么打、提供统一的日志、监控切面实现等，编码规范除了能规范开发的编码行为、避免犯一些低级错误和踩一些重复的坑外，另一个好处是让新入职的同学能快速了解公司的编码原则，这点对编码快速上手很重要，更多可以参考阿里巴巴的Java开发规范。
再也没有比糟糕的设计更有破坏力的东西了，技术方案设计评审和CR可以放在一起做，先评审设计再进行CR，有人就会说，都编码完了才进行设计评审是不是晚了？其实这要看情况而定，如果团队内部经常产出“糟糕设计”，那么我觉得设计评审就应该编码之前来做，但如果团队成员专业能力和经验都还不错，那么我们允许你再编码之后再做设计评审，而且编码的过程其实也是设计的过程，可以规避提前设计而导致后续编码和设计不一致的问题。设计评审的原则是，既要讲最终的设计方案，也要讲你淘汰的设计方案！
《如何写好&评审一份技术方案》
Farley1005，公众号：互联网技术集中营如何写好&评审一份技术方案
代码质量包括功能性代码质量和非功能性代码质量，功能质量大多通过测试能够去发现问题，非功能性代码质量用户不能直接体验到这种质量的好坏，代码质量不好，最直接的“受害者”是开发者或组织自身，因为代码质量好坏直接决定了软件的可维护性成本的高低。代码质量应该更多的应该从可测性，可读性，可理解性，容变性等代码可维护性维度去衡量，其中CodeReview是保证代码质量非常重要的一个环节，建立良好的CodeReview规范与习惯，对于一个技术团队是一件非常重要核心的事情，没有CodeReview的团队没有未来。
《如何做好codereview》
孔凡勇，公众号：互联网技术集中营如何做好CodeReview
涉及到10人日以上的项目，必须有明确的发布计划，并组织项目成员统一参加项目发布计划review，发布计划主要包含如下几点：
1）明确是否有外部依赖接口，如有请同步协调好业务方；
2）发布前配置确认包括配置文件、数据库配置、中间件配置等各种配置，尤其各种环境下的差异化配置项；
3）二方库发布顺序，是否有依赖；
4）应用发布顺序；
5）数据库是否有数据变更和订正，以及表结构调整；
6）回滚计划，必须要有回滚计划，发布出现问题要有紧急回滚策略；
7）生产环境回归测试重点Case。
发布流程规范主要是为了控制发布权限以及发布频率的问题。
在项目初始，为了快速响应业务，一般权限控制都很松，很多人都可以进行线上服务的发布。但随着业务越来越多、流量越来越大，相对应的故障也越来越多，到了某个时候就需要对权限做管控，并且需要对需求的发布频率做控制。
高可用架构设计指的是为了让系统在各种异常情况下都能正常工作，从而使得系统更加稳定。其实这块应该是属于研发流程规范中的技术方案设计的，但研发流程规范更加注重于规范，高可用设计更加注重高可用。另外，也由于高可用设计是非常重要，因此独立拿出来作为一块来说说。
对于高可用设计来说，一般可分为两大块，分别是：服务治理和容灾设计。
服务治理就包括了限流、降级、熔断、隔离等，这一些考虑点都是为了让系统在某些特殊情况下，都能稳定工作。例如限流是为了在上游请求量太大的时候，系统不至于被巨大的流量击垮，还可以正常提供服务。服务治理这块像SpringCloudAlibaba都有标准的成熟解决方案，比如可以基于sentinel实现限流、降级、熔断、隔离，隔离可以实现线程池隔离和信号量隔离，这里不再做详细介绍。
容灾设计应该说是更加高端点的设计了，指的是当下游系、第三方、中间件挂了，如何保证系统还能正常运行？可以说容灾设计比起服务治理，其面临的情况更加糟糕。例如支付系统最终是通过A服务商进行支付的，如果A服务商突然挂了，那我们的支付系统是不是就挂了？那有什么办法可以在这种情况（灾难）发生的时候，让我们的系统还能够正常提供服务呢？这就是容灾设计需要做的事情了，接下来将重点介绍一些容灾设计方案。
从请求发起侧到服务处理返回的调用全链路的各个环节上避免存在单点（某个环节只由单个服务器完成功能），做到每个环节使用相互独立的多台服务器进行分布式处理，要针对不同稳定性要求级别和成本能力做到不同服务器规模分布式，这样就避免单个服务器挂掉引发单点故障后进而导致服务整体挂掉的风险。可能涉及的环节有端动态获取资源服务(html&js&小程序包等)、域名解析、多服务商多区域多机房IP入口、静态资源服务、接入路由层、服务逻辑层、任务调度执行层、依赖的微服务、数据库及消息中间件。
冗余依赖，消除单点的策略：
冗余设计，对于飞机而言，体现在机组包括机长副机长，引擎至少双发，操作系统至少两套等等，于我们的系统而言，则通常体现在:
《高可用容灾架构设计》
孔凡勇，公众号：互联网技术集中营高可用容灾架构演进之路
极限场景中不同类型场景处理架构方案也不一样，可能的方式：
消息重复消费、接口重复调用对应的服务是否保证幂等？是否考虑了服务降级？哪些业务支持降级？支持自动降级还是手工降级？是否考虑了服务的超时熔断、异常熔断、限流熔断？触发熔断后对客户的影响？服务是否做了隔离，单一服务故障是否影响全局？这些问题统统需要我们想清楚对应的解决方案，才会进一步保证架构设计的合理性。
上下游依赖是否梳理过，影响范围多大？怎么进行新老系统替换？新老系统能否来回切换？数据存储是否兼容老的数据处理？如果对你的上下游系统有影响，是否通知到上下游业务方？上下游依赖方进行升级的方案成本如何最小化？这些问题需要有完美的解决方案，稍有不慎会导致故障。
是否彻底避免SQL注入和XSS？是否有数据泄露的可能性？是否做了风控策略？接口服务是否有防刷保护机制？数据、功能权限是否做了控制？小二后台系统是否做了日志审计？数据传输是否加密验签？应用代码中是否有明文的AK/SK、密码？这些安全细节问题需要我们统统考虑清楚，安全问题任何时候都不能轻视。
整体系统架构高可用还需要考虑可测性、可运维性，除了正向逻辑、性能、扩展性设计等外，要增加一个异常设计视角，穷尽思考各类异常情况以及设计应对策略。
系统设计整体至少考虑应对5到10倍或近1到3年系统规模增长，要保障后续通过增加机器资源等快速方式能实现系统水平扩容。例如分库分表的规模提前设计好提前量，避免临时数据库能力不足导致需要临时重构扩容（增加分库分表以及修改路由以及迁移数据）；服务逻辑层设计持有数据状态导致无法加机器做服务层扩容。互联网产品发展变化较快，不一定会如期爆发，容量架构设计上也要注意不要过度提前设计，避免提前复杂化引发研发效率以及机器成本问题。
针对线上流量峰值，建议系统常态保持近期峰值3倍左右容量余量，上线前和上线后要定期做压测摸高，写流量可用影子表等方式做压测，压测可单接口以及模拟线上流量分布压测结合，根据压测结果优化架构或扩容，持续保持容量富余。
对于可能超过系统现有容量的突发峰值，限流策略是线上要配置的策略。入口侧入口流量调用、不同渠道服务依赖调用、对依赖服务的调用都要评估可极限调研的上限值，通过中间件等合适方式限制超过阈值调用，避免引发雪崩效应。特定业务系统，对于超过峰值流量，可以通过消息架构以及合适体验设计做削峰填谷。针对恶意攻击流量也要考虑在入口层部署防DDOS攻击的流量清洗层。
部分系统峰值变化较大且需要持续尽可能承载保障，可考虑引入弹性伸缩策略，预约或根据流量变化触发系统自动扩缩容，以确保以尽量小成本来自动化满足变化峰值。
对于发布前的checklist更多可以参考前面所讲的发布计划，发布后的checklist更多的需要根据测试提供的测试用例进行生产环境回归测试验证。
这里涉及到的变更审批非常关键，根据实际情况，有些审批可以提前提交申请。
当系统成功上线后，很多小伙伴以为工作就结束了，但实际上我们还有不少工作可以做。根据我的经验，在上线后我们能做的稳定性建设包括：
监控报警，指的是我们需要对应用做好运行数据的收集，监控好系统的运行状态。当系统状态异常时，我们需要及时地发现并报警，从而让研发人员快速地解决问题。一般来说，监控报警分为系统级别的监控报警和业务级别的监控报警。系统级别的监控报警包括CPU、内存、磁盘等服务器资源的监控，而业务级别的报警则需要根据业务情况自行定义。
故障容灾演练需要从已知、半已知和未知三个维度去做。
故障容灾演练是提升系统稳定性的一把利器，很多时候即使我们设计得很完美，但实际上却没发挥作用，究其根本就是没有实践过。是驴是马，得拉出来溜溜才知道。
故障管理，就是当发生故障时，我们需要遵循的整套处理规范。团队小的时候可能无所谓，但是当团队大了的时候，我们就需要统一大家的故障处理流程，从而可以更快速地解决故障。此外，在故障解决完成之后还需要进行复盘，产出对应的故障报告。
CaseStudy机制指的是定期学习其他团队的高可用或者线上故障进行学习，从而提高团队的系统设计能力，避免踩坑。
紧急处理预案，简单就是要想到各种可能发现的情况，然后做好预案。之后结合容灾演练不断进行优化，从而形成一套很好的处理预案。这样当线上发生类似故障时，就可以轻松应对了。
在发生故障的时候，大多数人的脑子都是一片空白，很难迅速做出最合理的反应。衡量一个应急预案的好坏，关键是看它是否足够“无脑化”。
举个例子：如果发现了故障A，那么我们需要排查B和C两个方面来精准定位问题，定位后，我们再通过D—>E—>F三个操作来解决问题。
另外，预案也不是一蹴而就的事情，需要跟随架构和业务的演进，不断进行更新迭代，同时，也需要不断做减法，该摒弃的摒弃，该合并的合并，如果只增不减，那么一年以后，预案就会变成一本书。
紧急预案一般要包含如下内容：
这是件很能体现出工程师能力和素养的事情，需要工程师在coding过程中，在任何关键环节都具备安全意识。如：
全链路压测，指的是对整个链路进行压测。不同公司可能会采用不同的方案，有些会直接在线上进行压测，然后用流量标记的方式识别测试流量。有些则是进行流量录制，之后重新搭建一套与线上非常类似的系统进行压测。一般来说，第一种效果肯定会更好，成本也更低，但是对研发人员要求也更高，风险也更大。比如阿里天猫每年双11都会进行全链路压测，基于线上流量回放机制。
全链路跟踪是生产环境问题排查利器，开源的有skywalking，阿里内部对应的是eagleeye，能够根据请求traceid，快速诊断出生产环境bug。
人的意识是最重要的，专业能力可以锻炼培养。如果意识不足或松懈，好的能力以及机制流程也会形同虚设。
永远要对敬畏线上，敬畏客户体验。面向线上的稳定性战术上可以基于专业度锻炼后自信，但战略和思想上必须持续如履薄冰、三省吾身。线上稳定性保障是作为技术人自己专业度的追求和必须保持初心，始终保持敬畏。不因为业务繁忙、个人心情状态、团队是否重视而有变化，只要职责在，就要守护好。技术主管以及系统owner要有持续感知稳定性隐患和风险，保持锐度，集中性以及系统性查差补漏。
为什么要把系统健康度巡检放到技术管理里，我觉得这是一个非常重要的环节。像传统的航空、电力、汽车行业都要有一定的巡检机制，保障设备系统正常运转，同样软件系统也同样需要巡检机制保障业务健康发展。
随着业务的不断发展，业务量和数据量不断的上涨，系统架构的腐蚀是避免不了的，为了保障系统的健康度，需要不断的考虑对系统架构、性能进行优化。
系统的监控与报警能够一定程度发现系统存在的问题，系统存在的一些隐患需要通过对系统的巡检去发现，如果优化不及时在极端情况会导致故障，巡检粒度建议每周巡检一次自己所负责的业务系统。
系统指标：系统CPU、负载、内存、网络、磁盘有无异常情况波动，确认是否由发布导致，还是系统调用异常。
错误日志：通过错误日志去发现系统隐藏的一些BUG，避免这些BUG被放大，甚至极端情况下会导致故障。
快速定位和快速恢复是个人以及团队专业能力沉淀，但快速报警响应是每个敬畏线上敬畏用户体验的技术同学可以做到的。
从团队角度，报警及时响应必须配合报警治理进行，否则过多无效报警也会让有责任心的同学变得麻木。所以必须控制无效报警的数量，例如单应用无效报警（不需要线上问题进行定位以及修复处理的）不要超过5条，个人维度无效报警天级别不超过10条。
小的线上问题也要复盘，复盘准备度可以低于定级故障，但都需要思考反思以及落实优化Action。小的线上问题就是未来线上故障的前兆。我们团队周会上都会有一个环节，上周如有线上问题则会安排对触发人做复盘。
一个用户反馈背后必然有多个实际线上问题，只是这个用户无法忍受，知道反馈路径以及对这个产品有热爱或强依赖才选择反馈的。彻底定位一个voc，就是修复了一类线上问题。而且到用户反馈的程度，这个线上问题就已经有一定程度用户体验影响了。我们现在技术团队有一个voc日清机制，针对线上voc问题对用户做好日内响应答复，也是一个不错对于这个意识的数字化衡量。
单个技术同学个人技术以及稳定性保障能力是团队在每个稳定性任务上拿到结果的执行者和基础，因此技术主管重视识别不同同学个人优势和不足，针对性做工作安排以及培养锻炼。只要线上意识上足够重视，能力对于大部门技术同学是可以培养的。
能力培养方式有技术Review、代码CR和辅导、参与团队稳定性保障机制、安排合适师兄指导、过程中主管指导、逐渐承担更高职责等。代码层面，对于Java同学来说，《阿里巴巴Java开发手册》是一个很好的实践性指南，超出代码风格，提供了日志、异常处理、集合等库使用、数据库设计、分层设计等多个提升代码质量的实践做法，我们自己团队所有Java研发同学都会100%通过阿里云上阿里巴巴代码认证考试，同时团队有一个团队内新人品码机制，这些都是不错地培养同学写出好代码的培养方式。
在软件架构上有一句名言，没有最完美的架构，只有最适合的架构。推广到稳定性上，没有完全完美的稳定性方案，只有适合的稳定性方案。
系统稳定性压倒一切，只有保障了好了稳定性，才能帮助业务蓬勃增长，因此稳定性治理始终是工程师基本能力之一。