关于“稳定性建设”的一些思考

 1. 概述

1.1 背景

系统的稳定性是系统提供良好服务的基础，稳定性建设是一个系统化工程，贯穿软件生命周期的全过程。残酷的墨菲定律预示着我们对自己系统提供的服务不要太乐观。我们不能将碰运气当成战略！！！

“If something can go wrong, it will.” An addition to this law reads, “and usually at the worst time.” ---Murphy's Law

1.2 读完本文你可以获得什么？

• 稳定性建设全景图

• 稳定性建设思路

2 全景 

做好稳定性建设如同盖一座坚固的房屋，它需要坚实的根基和强壮的支柱。从时间维度来进行划分，我们将稳定性建设分为不同的阶段；从空间上来看，我们做的稳定性建设是一个结构化、系统性的工作，是一个整体。

2.1 使命

技术服务于业务，保证业务的稳定、高效、安全、持续、增长是第一要务。“使命”听起来是抽象的，所以在落地的时候，需要一套目标体系来度量稳定性建设工作的结果。

2.2 目标 

服务质量指标(SLI: Services Level Indicator ) 服务质量目标(SLO: Service Level Objective) 服务质量协议(SLA: Service-level agreement) SLA=SLO达成部分+SLO未达成部分。

2.2.1 SLIS

在稳定性建设过程中，需要一套指标来度量各项工作的质量、效果和价值。以下，介绍一套指标---VALET ，VALET由单词 Volume、Availability、Latency、Error 和 Ticket首字母构成，从不同层级给出稳定性建设指标的定义。

分类	详情
容量（Volume）	服务承诺的最大容量是多少，从QPS、TPS、流量、连接数、吞吐思考
可用性（Availability）	【计算】 (1) 时间维度: Availability = MTBF / (MTBF + MTTR), 其中平均无故障间隔Mean TimeBetween Failure, 平均修复时间Mean TimeTo Repair(MTTR). (2) 请求维度: Availability = 成功请求数量 / 请求总数量.
延迟（Latency）	服务响应速度是否够快，rt是否在预期范围内；
错误率（Errors）	错误率有多少，看HTTP状态码5xx的占比；
工单（Tickets）	工单数量、 工单响应时间、 工单处理时间、 工单解决率、 工单重复率、 工单满意度、 工单知识库更新频率。

2.2.2 SLO

SLO对应的SLI要实现的目标，下表为一些稳定性建设的SLO示例。

协议	详情
容量（Volume）	服务承诺的最大容量是多少。比如一个应用集群的QPS、TPS、会话数以及连接数等。eg. 支持峰值10w QPS.
4个9	【不可用时间】
TP99 <= 50ms	99%的请求能够在100ms内得到响应。（把一段时间内所有请求的响应时间，按照从小到大进行排序，然后取99%对应的请求的响应时间，即为TP99的值。）
1、5、10	1分钟发现，5分钟定位，10分钟恢复 (1) MTTI(Mean Time To Identify，平均故障发现时间)：指的是从故障实际发生，到我们真正开始感知、识别、响应的时间。这个过程最长见的渠道可能是服务监控告警、常规巡检、用户或者同事反馈，也可能是舆情监控等。 (2) MTTK(Mean Time To Know，平均故障认知时间)：也就是我们常说的平均故障定位时间。 (3) MTTF(Mean Time To Fix，平均故障恢复(解决)时间)：这个时间指从我们定位到故障的原因到我们采取措施恢复业务为止。这里采用的方式可能有很多：故障隔离、容灾切换、限流、降级、熔断等，甚至是重启服务。 (4) MTTV(Mean Time To Verify，平均故障修复验证时间)：即故障解决之后，我们用来验证服务是否真正恢复的时间。 本文在支柱部分，以故障的生命周期为脉络，从时间维度描绘出空间维度。
月工单≤xxxx	工单数量能够反映在处理和解决问题与需求的效率和质量，工单数少一定程度反映出高质量。

2.2.3 SLA

SLA服务等级协议包括两部分，即服务等级目标SLO和未达服务等级目标SLO时，要做出的后果(如经济赔偿、信用等)。 

收益	详情
增强运行态的确定性	SLA可以帮助构建线上运行态的确定性，让产品从“能够正常对外提供服务”跨度到“能主动控制服务状态” (1) 产品能明确自身的短板，能以最优的资源投入产出比提升服务质量。一个简单的例子就是：某服务可用性从99.9%提升到99.99%所需的资源和带来的收益之比，是决定该服务是否应该提供4个9的重要依据。 (2) 产品能增强对突发情况的应对能力。合适的SLI指标能帮助产品在故障发生时进行更好的决策，产品有能力在资源不足时去选择舍弃哪些服务。 (3) 产品能给用户提供差异化的服务，进而节省成本。Google SRE认为，基础设施服务运维的关键战略就是明确划分服务水平，从而让客户在构建系统时能够进行正确的风险和成本权衡。
建立用户预期	从用户的视角来看，SLA可以帮助用户建立对服务质量的预期。这可以避免用户对某项服务的过度依赖，甚至会左右用户的技术方案和架构设计。
错误预算	错误预算可以用来平衡稳定性与创新迭代速度之间的关系。错误预算定义了某个服务在一段时间内的稳定性目标，错误预算是通过1-SLO得出来，如对于某个99.99%可用性目标的服务具有0.01%的错误预算。

在确立稳定性建设的目标后，具体如何来推进稳定性建设呢？下文将从稳定性建设的根基和支柱两方面进行介绍。

3 根基 

3.1 文化建设

“文化建设”是“稳定性建设”之基。做好文化建设听起来“假大空”，但是一个“无组织、无纪律、无约束”的团队的战斗力一定是有限的。系统在不断迭代，人员也会不停流动，如果没有一个好的文化传承，我们其实无法保证稳定性建设的持续投入和效果。

良好的文化就像一个稳定平衡的生态环境，有助于团队成员以有效的方式思考和学习技术，促进自身的成长，保障业务健康稳定发展。下图是稳定性建设文化建设过程图，分为“形”、“信”、“行”三个阶段。

3.2 稳定建设的要素

做好稳定性建设离不开“人”、“管理”、“技术”三要素。

3.2.1 第一要素---“人”

【个人成长】

谁应该参与稳定性建设？	“稳定性建设”本身是一个全员参与的过程。 (1) 负责人：有责任心和单兵作战能力强的人。 (2) 参与者：研发、测试、运维、安全、产品 等同学参与，主导方应该是研发、测试和运维。
如何单兵能力？	“学习金字塔理论”认为学习效果在30%以下的几种传统方式都是个人学习或被动学习，而学习效果在50%以上的都是团队学习、主动学习和参与式学习。最有效的提高稳定性建设能力的手段是让自己成为稳定性建设的布道者。

【团队建设】稳定性建设所需的速度、频率、复杂性意味着团队是必不可少的。依赖强悍的单兵能力的本质是不可持续的，事实上，团队活力远比任何一个个体在团队中更重要。

from: 《高效能团队模式：支持软件快速交付的组织架构》

团队类型	详情	稳定性建设相关
流动式团队 Stream-aligned Team	面向有价值的工作流，团队有能力快速、安全、独立的交付用户价值。	参与业务建设，实施稳定性建设的工作。
赋能团队 Enabling Team	具备专业领域的技能，指导并帮助流动式团队成功。	提供稳定性建设的指导而不是具体执行。
复杂子系统团队 Complicated-Subsystem Team	负责构建和维护系统中严重依赖专业领域知识的子系统团队。	较为复杂的算法、公用的组件（如ip库）
平台团队 Platform Team	面向底层服务，降低认知负荷。	基础架构、基础框架、基础平台建设、工具建设。

3.2.2 第二要素---管理

稳定性建设和保障工作需要各方配合，因而稳定性相关工作宜从管理的角度着手制定工单、监控、预警、故障、应急、变更、演练、压测、度量、问责等多维度的规范，统一规范标准，并通过一系列的机制保证规范的执行，形成一套全生命周期的管理流程。

【规范：静态的、明确的】

规范	详情
设计规范	规范的方案：见公众号“大袤宏图”《技术方案模板》设计原则：SOLID原则、KISS原则等.
编码规范	请阅读公众号“大袤宏图”文章《防御式编程（Defensive Programming）》
测试规范	测试用例设计规范：测试用例是测试过程中最重要的部分，需要明确测试用例的设计规范，包括测试用例的编写标准、命名规则、用例设计方法等。 测试数据管理规范：测试过程中需要使用和管理大量的测试数据，需要制定测试数据管理规范，包括测试数据的准备、存储、保护和恢复等方面的要求。 测试环境管理规范：测试环境是测试过程中必不可少的部分，需要制定测试环境管理规范，包括测试环境的搭建、配置、升级和维护等方面的要求。 缺陷管理规范：缺陷管理是测试过程中重要的一环，需要制定缺陷管理规范，包括缺陷的发现、记录、跟踪、修复等方面的要求。 测试报告编写规范：测试报告是测试过程的总结和评估，需要制定测试报告编写规范，包括测试报告的内容、格式、编写时间等方面的要求。 自动化测试规范：自动化测试可以提高测试效率和准确性，需要制定自动化测试规范，包括自动化测试的脚本编写、执行、调试和维护等方面的要求。 安全性测试规范：安全性是软件质量的重要方面，需要制定安全性测试规范，包括安全性漏洞的检测、评估和修复等方面的要求。
变更规范	变更申请规范：变更申请应该明确变更的目的、内容、影响范围、实施时间等信息，以确保变更的合理性和必要性。 变更评估规范：对变更的影响范围和实施难度进行评估，以确保变更不会对整个系统造成不良影响。 变更审批规范：对变更申请进行审批，以确保变更的合法性和合规性。 变更实施规范：对变更进行实施，包括变更的测试、验证和上线等环节，以确保变更的准确性和稳定性。 变更文档规范：对变更进行文档记录，包括变更日志、操作手册、故障处理指南等，以确保变更的可追溯性和可维护性。 变更沟通规范：在变更过程中，需要进行及时有效的沟通，包括内部沟通、客户沟通、供应商沟通等，以确保变更的协调和一致性。 变更安全规范：在变更过程中，需要确保系统的安全性，包括防止漏洞利用、保护敏感数据等，以确保系统的安全性。

【机制：动态的、过程性的】

机制	详情
评审机制	【简介】方案评审、代码评审(review)、COE Review等。 【意义】a. 发现潜在问题：通过评审机制，可以发现并纠正潜在的问题或错误，避免这些问题对工作或项目造成不良影响。b. 提高质量：评审机制可以提供反馈和建议，帮助改进工作或项目的质量。通过不断改进和优化，可以提高成果的质量和水平。c. 减少风险：评审机制可以发现潜在的风险和隐患，并及时采取措施加以解决。这有助于减少风险对工作或项目的影响。d. 促进知识共享：评审机制可以促进团队成员之间的知识共享和经验交流。通过互相学习和借鉴，可以提高整个团队的知识水平和技能。e. 增强透明度：评审机制可以增强工作或项目的透明度，使相关方更好地了解进展情况，并提高决策的准确性。f. 改进流程：评审机制可以发现流程中的不足之处，并提供改进建议。通过不断优化流程，可以提高工作效率和质量。g. 增强信任：通过评审机制，可以增强相关方对工作或项目的信任和认可，有助于建立良好的合作关系。
值班机制	【简介】指在特定时间段（日、周、月）内，由专人负责监控和维护稳定运行的机制。 【意义】a. 提高服务质量：确保服务流程的顺畅和及时响应，有效避免因人员调整、缺勤等情况而导致的服务延误。值班制度的规范化管理下，可以更轻松地找到需要的信息或解决问题。b. 提高员工责任感：明确的服务端值班制度，员工的责任感和工作效率都能够得到提高。值班的员工不仅要承担服务对象的需求，还需要保障服务的正常运转，从而提升服务水平和客户满意度。c. 优化资源分配和降低成本：通过合理的值班安排，能够实现资源的优化配置和有效利用，降低服务成本和运营成本
复盘机制	请阅读公众号“大袤宏图”文章《软件质量工程之COE》
记账机制	【简介】业务方登记(eg. 业务场景、负责人、配置等)、资源记账（eg. 部署环境、机器参数等） 【意义】避免遗忘、遗漏。
例会机制	【简介】固定周期或特定时间举行稳定性建设会议。（eg. 稳定性建设周会、月报等） 【意义】帮助团队成员提高沟通效率、解决问题和调整方向、促进合作和增强凝聚力、实现资源共享和知识积累。
权限管控机制	【简介】通过对系统或应用中对用户或角色的操作进行限制和管理，以确保只有经过授权的用户或角色能够执行特定的操作或访问特定的资源。 【意义】高危操作可实现double check或多次check；防止未经授权的用户获取敏感信息、执行非法操作或对系统进行恶意操作。
应急响应机制	【简介】制定详细的应急响应计划、建立应急响应团队、建立通报机制以及跟进和总结等措施。 【意义】快速响应可能出现的各种异常情况。
培养、考核机制	【简介】专项训练、考核等。 【意义】培养机制和团队考核机制相辅相成。通过有效的培养机制，可以提高成员的综合素质；而完善的团队考核机制可以激励团队成员积极进取，促进团队的稳定和发展。

3.2.3 第三要素---技术

技术是实现稳定性的重要手段，通过采用先进的技术架构、应用适当的算法和工具，可以提高系统的可靠性和可用性，从而增强稳定性。以下是稳定性建设不同的技术领域涉及到的技术。

领域	详情
研发流程域	迭代管理、代码扫描等
测试仿真域	单元测试、灰度环境、自动化测试、灰度验证、性能压测等
运维变更域	代码发布、配置管理等
数据域	采集、预处理、存储、计算和分析等
监控巡检域	监控系统、资金核对、巡检、舆情监控等
事件流程域	事件管理、流程审批、工单系统、故障管理等

4 支柱 

稳定性建设的支柱部分对稳定性建设的不同生命周期所涉及的具体工作进行细化。

4.1 预防

“稳定性建设”的绝大部分工作是“预防”工作，真实的业务场景、环境千变万化，采取积极的措施来预防或减轻潜在的风险损失。“未雨绸缪”，拥有前瞻性的思考和行动对于稳定性的建设必不可少。

4.1.1 梳理摸底

“梳理”是一项极性价比极高工作，做好梳理工作，我们才能够了解到系统的瓶颈、风险、提升空间。遗憾的是研发人员很多时候将自己定义为一个“编码”人员，将很多精力放在代码“堆砌”上，更狭隘的甚至一味追求“奇技淫巧”上。

在开展梳理工作的时候，一般我们从“系统梳理”和“业务梳理”两个方向出发，回答“现状是什么？”和“不足(风险)是什么？”两个核心问题！

【系统梳理】

【业务梳理】在做“业务梳理”时，我们从用户、产品、核心能力、核心流程逐级深入了解，首先我们需要抛开“细节”，从宏观上了解业务的形态，观其貌：业务面向哪些用户，提供出了哪些产品；在吸收了“业务”背景后，我们去了解系统的核心能力。最后我们需要深入细节，从微观上梳理核心流程，发现当前存在的缺陷。以下是一个基本的业务梳理流程：

步骤	详情
确定梳理目标	首先需要明确业务梳理的目标，例如了解业务流程、发现痛点、优化流程等。
收集流程信息	收集相关的业务流程信息，包括流程图、流程说明、相关表单等。
挖掘问题	对收集到的流程信息进行分析，发现问题，例如流程不顺畅、效率低下、错误率高等。
制定改进措施	根据分析结果，制定相应的改进措施，例如优化流程、简化操作、提高自动化程度等。

4.1.2 容量保障

容量容量是稳定性假设的Silver Bullet，保障的目的是根据业务优先级、资源消耗情况等合理评估和分配资源，良好的容量设计可以提升业务的稳定性、节约成本。从宏观上来看，容量保障要做好“容量需求分析”、“容量调度”、“容量供给”三个方面的事情。

【容量需求】

行业	业务峰值场景
电子政务	政策发布、大型活动、普查调查等。
出行	节假日、春运、促销活动。
电商	双十一、年货节等大促活动。
直播	直播秒杀、直播活动、超级网红直播。
物流	电商促销活动、季节性高峰（如圣诞节、双十一等）、大型会议或展览等时期。
金融	重大政策出台、金融市场波动、年终结算等。
能源	统一缴费日、活动日。
零售	会员日、广告集中投放营销。

【容量调度】

项目	详情
评估	业务流量预估阶段：通过分析历史数据以及实时的线上监控，预估未来某个时间点或者某个业务可能会有多少多少的流量冲击； 系统容量评估阶段：根据具体的业务场景，分析每个业务场景的流量配比，然后计算每个业务大概需要多少服务节点来提供可靠稳定的性能支撑；
预测	压力测试
决策	根据用户的需求和权限进行优先级和权限的管理。它还可以与其他系统和工具进行集成和扩展，从而满足不同用户和组织的需求。这可以帮助管理员和用户做出更明智的决策，更好地管理和使用计算机系统上的资源。
调度	弹性调度、分时调度等。
风险	容量调度器可以提高系统的整体性能和效率，但也存在一定的风险。例如，如果容量调度器的配置不合理，可能会导致资源的过度分配或浪费，影响系统的正常运行。此外，如果容量调度器受到攻击或出现故障，也可能会对系统的正常运行造成影响。因此，在使用容量调度器时，需要注意风险管理和安全保障。
核算	有效地管理计算机系统上的资源占用，尤其是在多用户、多任务和大型分布式系统中。通过动态地分配计算资源，避免系统资源的过度占用或浪费，提高系统的利用率和响应速度。这可以减少系统的成本，提高系统的经济效益。

【容量供给】私有云、公有云、混部资源。

云类型	详情
私有云	私有云部署对于服务和基础架构始终都在私有网络上进行维护，其中包括硬件、软件的使用。
公有云	第三方提供商为用户提供的能够使用的云，可实现资源共享，资源灵活调配的一种云计算类型。用户可通过使用的实际资源、时间进行付费。
混部云	整合公有云、私有云、社区云的优势。以高扩展性为核心要点，实现存储空间大、灵活计费等形势，这些都是混合云的主要特点。

以下雷达图对公有云、私有云、混部云进行比较：

4.1.3 可观测建设

可观测性是一种技术手段，它通过系统产生的输出数据（指标---Metrics、 日志---Logging、 链路---Tracing）来衡量当前系统运行状态的能力。可观测性建设就是以可观测性为指导原则，对系统进行全面的数据收集、分析和利用，以实现对系统运行状态的实时监控、问题定位和优化改进。

可观测系统的整体架构如下：

4.1.4 预案、灾备

【预案】在日常工作中，充满了稳定性建设的“契机”，在面对具体开展专项的稳定性保障工作时，可先参照下图，绘制稳定性假设的作战地图，并指定保障预案。

稳定性相关预案要点如下表：

要点	详情
触发条件	明确预案执行的时机。一般从监控大盘、告警或用户反馈得知故障后，通过预案设定的触发标准来决定是否执行预案、执行哪些预案。
执行步骤	详细描述预案执行的过程，不同角色分工合作。例如系统Owner负责操作回滚命令或脚本以止损，其他同学负责问题定位和查看监控大盘，Team Leader需要组织团队内同学协作并将故障处理进展同步给业务方和客服。
观察效果	在预案执行过程中，需要观察执行的效果。可以提前配置好对应的观察大盘，并记录在预案中。

【灾备】通过灾备技术保证业务不中断、数据不丢失。

4.1.5 专项治理

通过专项治理，发现和解决系统中的一些突出问题，如性能瓶颈、安全漏洞、数据不一致等，从而提高系统的性能和稳定性。专项治理过程中会对系统的安全性和可靠性进行全面检查，及时发现并解决存在的安全漏洞和隐患，有效保障用户数据的安全性。解决用户在使用系统过程中遇到的一些突出问题，提升用户体验，增加用户满意度，进而推进系统的全面优化和改进。

项目	详情
日志治理	日志覆盖、规范化和标准化：收集系统各个组件和应用程序的日志信息，确保日志信息的完整性和准确性。制定统一的日志规范和标准，确保日志信息的格式和质量的一致性，方便后续的分析和处理。 日志存储：将收集的日志信息存储在可靠的存储设备中，确保日志信息的安全性和可访问性。 日志分析：对收集的日志信息进行分析，发现其中的规律和异常信息，进而诊断和解决问题。 日志搜索：提供日志搜索功能，方便用户快速查找和定位问题。 日志可视化：通过可视化界面展示日志信息和分析结果，帮助用户更好地理解系统的运行状态和问题。 日志审计和监控：对日志系统进行审计和监控，确保日志信息的准确性和完整性，及时发现并解决潜在的问题。
监控治理	a. “覆盖度”：完善监控配置，确保监控覆盖所有关键业务和系统组件。 b. “准确性”：采取监控分层的方法，按照故障等级和业务链路监控，对监控进行分级管理，减少噪声和冗余信息。 c. “有效性”：要定期检查和更新监控配置，以适应业务变化和系统升级。
服务治理	a. 慢sql治理 b. 幂等 c. 解耦 d. 读写分离、缓存 等等。
数据安全
资金安全	以下为资金安全“风险立方体”，可从“业务场景”“流转环节”“风险视角”三个维度出发开展“资金安全”建设工作。
清理专项	产品是资产，代码是负债。你的产品解决了客户的问题，因此是你的资产。代码则是创造资产的成本。你拥有的代码越多，阅读、测试、更改和理解所付出的成本就越高。

4.2 发现

4.2.1 常规巡检

分类	详情
硬件检查	检查服务器硬件的健康状态，包括电源供应、风扇、温度传感器等。检查磁盘存储的可用空间，确保没有过度使用或存储故障。检查网络连接和接口，确保网络设备工作正常。
软件更新和安全补丁	检查系统上的软件版本，并与最新的稳定版本进行比较。 定期应用操作系统和软件的安全补丁，确保系统免受已知漏洞的攻击。 更新防病毒软件和防火墙规则，以提高系统的安全性。
数据库和备份	检查数据库服务器的状态和性能，确保数据库可靠且高效。 确认备份过程正常运行，并验证备份数据的完整性和可恢复性。
对账	主动发现数据差异。
检查安全性和访问控制	确保系统的安全性和访问控制。检查用户身份验证、授权和访问控制机制，以及任何相关的安全更新和漏洞修复。

4.2.2 监控告警

【监控能力矩阵】

4.2.3 客诉响应/舆情感知

下图是客诉至舆情发展的过程图。

那么，舆情动态感知应该怎么实现呢？

步骤	详情
数据收集	通过高效的监测技术，自动从互联网上收集数据，包括但不限于新闻媒体、社交媒体、权威网站、短视频平台、境外网站、论坛、博客等。
事件监测	通过关键词监测和自然语言处理技术，快速发现热点和事件，比如舆情危机、新闻事件等。利用该功能，企业可以人性化的灵活设置关键词，识别出重点事件，及时把握分析和预测市场动向。
情感分析	针对文本内容进行情感分析，自动识别文本中蕴含的情感倾向，如喜、怒、哀、乐等，并同步进行危机预警通知，从而帮助企业了解舆情的基调，判断市场态势。
竞品分析	可以针对性的了解竞争对手在网络平台的舆情动态，包括负面声量、品牌宣传、新品发布、公关活动等，洞悉竞争对手的商业战略变化，为赢得和保持竞争优势提供决策支持。
画像分析	专业的舆情报告团队，对企业营销及行业热门事件进行分析，对相关信息的爆发特点、传播路径、传播节点、传播分布偏好、衍生话题、舆论焦点、品牌好感度、用户画像等方面进行全面分析，帮助客户全面了解事件特点、梳理事件发展及相关舆情变化的脉络及趋势，并在此基础上，针对事件负面情绪爆发原因、话题倾向特点，就应对及处置方法提出专业建议或观点。

4.2.4 智能感知

智能感知是指利用NLP等技术自动分析、识别和跟踪，以实现自动化监控和预警。监控智能感知技术包括目标检测、目标跟踪、行为分析、异常检测等功能，能够自动识别和提取监控场景中的关键信息，并对异常情况进行预警和报警。监控智能感知技术的能够提高监控的精准度和效率，减少人力成本，并为决策提供更加准确和及时的数据支持。

4.3 定位

4.3.1 监控、日志、链路分析

【指标】

方法	详情
阈值方法	a. 固定阈值法：如日活大于或者小于固定值时进行异常预警; b. 同环比阈值法：如日活环比上周同期波动大于或者小于固定百分比时进行异常预警；
统计方法	a. 2/3倍标准差法：我们知道正态分布中，数据分布在2倍标准差内的概率是95.5%，在3倍标准差的概率内是99.7%，因此如果日活大于或小于过1个月日活均值的2倍标准差（如果数据有明显的按周波动，可按星期往前推，如目前是周五，考察前5个周五的均值和标准差，并进行对比），则可认为数据异常波动。 b. 1.5倍IQR：和标准差类似，该方法是基于箱线图进行异常判断。
建模方法	a. 建立模型：根据问题的性质和数据的特点，选择合适的建模方法。这可能包括机器学习、深度学习、统计建模等不同的方法。在建立模型时，需要确定模型的参数和超参数，并选择合适的优化算法和评估指标。 b. 模型评估：使用评估指标对模型的性能进行评估。这通常涉及将模型的预测结果与真实标签进行比较，并根据评估指标计算模型的得分。常用的评估指标包括准确率、精确率、召回率、F1值等。 模型优化：根据评估结果对模型进行优化。这可能包括调整模型的参数、改变模型的结构、使用不同的优化算法等。优化目标通常是提高模型的性能，即提高评估指标的得分。 c. 模型部署：将优化后的模型部署到生产环境中，以解决实际问题。这可能涉及将模型集成到现有的系统中，或者将模型部署到云平台或服务器上，以提供在线服务。 d. 模型监控与维护：在模型部署后，需要持续监控模型的性能，并及时调整和维护模型。这可能涉及监控模型的输入和输出数据的质量，以及定期重新训练和更新模型。

【日志】日志记录了离散的事件，如应用程序的调试信息、异常错误信息，是诊断问题的依据。

【链路】链路追踪的基本原理就是在分布式应用的接口方法上设置一些观察点，然后在入口节点给每个请求分配一个全局唯一的标识 TraceId，当请求流经这些观察点时就会记录一行对应的链路日志（包含链路唯一标识，接口名称，时间戳，主机信息等）。最后通过 TraceId 将一次请求的所有链路日志进行组装，就可以还原出该次请求的链路轨迹。

4.3.2 场景复现

步骤	详情
收集历史故障数据	通过收集历史故障数据，了解故障发生时的具体情况，包括故障类型、现象、影响范围等信息。
分析故障原因	通过对历史故障数据进行深入分析，了解导致故障的根本原因，这有助于针对性地制定预防和解决措施。
构建故障场景	根据历史故障数据和分析结果，构建与原始故障相似的场景，包括设备配置、网络环境、应用程序等。
复现故障	在构建的故障场景中，通过模拟触发条件，如输入特定数据或执行特定操作，来复现故障。
验证解决方案	在复现故障后，可以验证所提出的解决方案是否有效，并观察解决方案实施后的效果。

4.3.3 根因分析

Root Cause Analysis

方法	详情
5W1H分析法	通过回答问题的五个W（Who、What、When、Where、Why）和一个H（How），来全面了解问题的各个方面。这个方法可以帮助我们系统地收集和整理问题相关的信息。
鱼骨图（Ishikawa图）	将问题作为鱼的头部，将导致问题发生的各种因素作为鱼骨的骨架，通过分析这些因素之间的关系。
5 Whys法	通过反复追问“为什么”来深入挖掘问题的根本原因。这个方法可以帮助我们逐步剖析问题，直至找到最根本的原因。需要注意的是，这个方法需要避免陷入表面原因和主观假设，要保持客观和系统性。
故事线分析	通过构建问题发生的时间线和事件顺序，将问题分解为多个子问题，并分析每个子问题的原因和影响。这个方法可以帮助我们更好地理解问题的演变过程和关键节点。
树状图分析	将问题作为根节点，将导致问题发生的各种因素作为分支节点，通过分析每个因素的影响和关联（指标关联、告警关联、变更关联等），找到问题的根本原因。这个方法可以帮助我们建立问题和因素之间的关系图，更好地理解问题的复杂性。
DMAIC方法	DMAIC（Define、Measure、Analyze、Improve、Control）是六西格玛质量管理方法中的一种常用的问题解决方法。它通过明确问题、测量数据、分析原因、改进过程和控制变化，来解决问题并持续改进。

4.4 恢复

故障处理是一个特别符合“台上一分钟，台下十年功”这句俗语的场景，一次故障就是一次考试。

4.5 故障改进

4.5.1 故障复盘

海恩法则(Heinrich's Law)指出：每一起严重事故背后，必然有29次轻微事故和300起未遂先兆以及1000起事故隐患。通过故障复盘挖掘故障背后的原因，能够跟进一步将风险扼杀在摇篮中。关于故障复盘，请阅读公众号“大袤宏图”文章《软件质量工程之COE》。

4.5.2 改进验收

在进行故障改进时，需要注意以下几点：

要点	详情
及时性	对于发生的故障，要尽快进行改进，以防止类似问题再次发生。
针对性	改进措施要针对故障的根本原因进行制定和实施，不能只关注表面现象而忽略了问题的本质。
可行性	在制定改进措施时，要考虑其可行性和可操作性。如果措施难以实施或者效果不明显，需要及时调整方案。
预防性	除了针对已发生的故障进行改进外，还要考虑如何预防类似问题的再次发生。例如，可以加强设备的日常检查和维护保养，提高操作人员的技能水平等。
持续性	故障改进是一个持续的过程，需要不断关注新出现的问题和变化，及时进行调整和改进。

4.5.3 故障演练

【故障库的形成】每一次故障发生、处理、复盘在一定程度能够让我们获益：让系统不断进化，形成正向循环，逐步提高系统的质量，保证系统的健壮性。下图为故障演练可注入的故障库，供参考。

通过演练，主要达成以下目标。

目标	详情
检查预案	强化预案执行流程、检查预案完整性和有效性。
锻炼队伍	通过预案增强演练组织部门、参与人员等对灾备方案的熟悉程度，提高处置人员的响应效率和处置能力。
磨合机制	检验部门间联动效率，完善联动机制。

【混沌工程】混沌工程提倡使用一系列实验来真实地验证系统在各类故障场景下的表现，通过频繁地进行大量实验，使得系统本身的反脆弱性持续增强。

风会熄灭蜡烛，却能使火越烧越旺。对随机性、不确定性和混沌也是一样：你要利用它们，而不是躲避它们。你要成为火，渴望得到风的吹拂。这总结了我对随机性和不确定性的明确态度。我们不只是希望从不确定性中存活下来，或仅仅是战胜不确定性。除了从不确定性中存活下来，我们更希望像罗马斯多葛学派的某一分支，拥有最后的决定权。我们的使命是驯化、主宰，甚至征服那些看不见的、不透明的和难以解释的事物。---《反脆弱：从不确定性中获益》

下图为混沌工程架构图。

至此，本文从故障的生命周期“预防”“发现”“定位”“恢复”“复盘”五个阶段，对稳定性建设的各项工作进行了简要介绍。

5 总结 

稳定性建设是一个长期而持续的过程，需要不断改进和完善。只有通过全面的分析、科学的方案和有效的实施，才能确保系统的稳定性和可靠性，为业务发展提供有力保障，道阻且长行则将至。

6 参考资料 

[1]《SRE：Google运维解密》(美)贝特西·拜尔等 著.

[2]《反脆弱：从不确定性中获益》纳西姆·尼古拉斯·塔勒布（Nassim Nicholas Taleb）著.

[3]《分布式系统稳定性建设指南(2022年)》中国信息通信研究院CAICT.

[4]《Dapper, a Large-Scale Distributed Systems Tracing Infrastructure》 Google Technical Report dapper-2010-1, April 2010.

[5] 《高效能团队模式：支持软件快速交付的组织架构》（英）Matthew Skelton（马修·斯凯尔顿），（西班牙）Manuel Pais（曼纽尔·派斯）著.

7 附件 

关注公众号“大袤宏图”，回复“稳定性”获取本文全部绘图(draw.io)。