一、前言

二、稳定性介绍

三、实际操作流程

1、需求分析阶段

2、设计阶段

2、1备选架构

2、2方案设计

2、3 架构设计

2、4设计的checklist

2、5的checklist

3、开发联调

4、自测环节

5、上线前环节

6、上线后的验收和复盘

四、稳定性、效率、成本之间的考量

五、稳定性建设的边界

六、稳定性建设的异议

一、前言

最近滴滴、阿里云的宕机时间，引发科技圈和用户的极大关注，对于研发来说，这就是我们系统的稳定性出现了极大问题，而且最近公司也在做些异地多活的事情，同样也是为了做好稳定性。

二、稳定性介绍

那么稳定性是什么呢，稳定性就是系统不出故障，或者出故障的时间越短越好。

编辑

1、指标1

我们先这样定义上述图中数据的含义

N:两次故障

T1:无故障时间

T2:故障等待修复时间

T3:故障修复时间

T21:故障发现时间

T22:故障发现到定位时间

T23:故障定位到处理时间

T31:故障处理时间

由此可以得出

MTTF =∑T1/ N #指系统无故障运行的平均时间，所有系统开始正常运行到发生故障之间的时间段的平均值

MTTR =∑(T2+T3)/ N #指系统从发生故障到维修结束之间的时间段的平均值

MTBF =∑(T2+T3+T1)/ N #指系统两次故障发生时间之间的时间段的平均值

我们要做好稳定性，那就是要减小MTTR的值，我们一般会用sla来衡量一个系统的稳定性，假设是以月来衡量的话，我们看下不同sla下的情况，

90%（1个9的正常运行时间）：这意味着10%的停机时间，也就是说在过去的30天里停机了3天。

99%（2个9的正常运行时间）：意味着在过去30天中有1%，或者说7.2小时的停机时间。

99.9%（3个9的正常运行时间）：意味着0.1%，或者说43.2分钟的停机时间。

99.95%（3.5个9的正常运行时间）：意味着0.05%，或者说21.6分钟的停机时间。

99.99%（4个9的正常运行时间）：意味着0.01%，或者说4.32分钟的停机时间。

99.999%（5个9的正常运行时间）：意味着0.001%，或者说26秒的停机时间

一般来说一般的公司都会达到三个九和四个九的程度，一二线大厂一般会达到5个九的程度，我们不能因为大厂一次的失误就怀疑整体的实力，至少在我理解，下面是一些大厂的日活数据，假设我们每天出现一个万分之一的错误，那影响的人基本都是几万到十万之间，经过舆论发酵，可能会更大，但是大厂基本上都是几年才出一次，证明出事的概率还是很小的，如果大厂都很做到的事情，其他公司要想做好更是难上加难。这其中要投入很久的时间、经济、人力、技术等等资源。

编辑

2、指标2

还有一两个指标是RTO和RPO

恢复时间目标（RTO）：RTO是指在发生灾难事件后，系统或服务需要恢复到正常运行状态所需的时间。RTO是一个时间窗口，表示业务或服务中断的最大可接受时间。较低的RTO意味着系统需要更快地恢复，以减少业务中断的时间，简而言之就是业务恢复的最短时间。

恢复点目标（RPO）：RPO是指在发生灾难事件后，系统或服务需要恢复到的数据状态。RPO表示数据丢失的最大可接受程度。较低的RPO意味着系统需要更快地恢复到较新的数据状态，以减少数据丢失的量，简而言之就是业务数据恢复的最短时间。

这两个指标，在工作中我觉得业务上重视RPO重于RTO，从下面的行业指标也可以看出是这样的。

这方面国家对不同行业都有不太的规定，如下图：我们可以在这样的规范性文件里找到一些信息：在线预览|GB/T 20988-2007，发现有一个这样两个网站：首页 - 全国标准信息公共服务平台和https://wecruit.hotjob.cn/SU642fbf5fbef57c1e269fa798/pb/index.html#/，可以找到一些政策性或行业规范类文件。

编辑

那作为研发人员，我们想做好自己系统的稳定性建设应该如何做呢？

关于这个话题，我查了下软考架构师关于的第九章 可靠性这个课题，文档中是这么管理可靠性的：

1．需求分析阶段

（1）确定软件的可靠性目标。

（2）分析可能影响可靠性的因素。

（3）确定可靠性的验收标准。

（4）制定可靠性管理框架。

（5）制定可靠性文档编写规范。

（6）制订可靠性活动初步计划。

（7）确定可靠性数据收集规范。

2．概要设计阶段

（1）确定可靠性度量。

（2）制定详细的可靠性验收方案。

（3）可靠性设计。

（4）收集可靠性数据。

（5）调整可靠性活动计划。

（6）明确后续阶段的可靠性活动的详细计划。

（7）编制可靠性文档。

3．详细设计阶段

（1）可靠性设计。

（2）可靠性预测（确定可靠性度量估计值）。

（3）调整可靠性活动计划。

（4）收集可靠性数据。

（5）明确后续阶段的可靠性活动的详细计划。

（6）编制可靠性文档。

4．编码阶段

（1）可靠性测试（含于单元测试）。

（2）排错。

（3）调整可靠性活动计划。

（4）收集可靠性数据。

（5）明确后续阶段的可靠性活动的详细计划。

（6）编制可靠性文档。

5．测试阶段

（1）可靠性测试（含于集成测试、系统测试）。

（2）排错。

（3）可靠性建模。

（4）可靠性评价。

（5）调整可靠性活动计划。

（6）收集可靠性数据。

（7）明确后续阶段的可靠性活动的详细计划。

（8）编制可靠性文档。

6．实施阶段

（1）可靠性测试（含于验收测试）。

（2）排错。

（3）收集可靠性数据。

（4）调整可靠性模型。

（5）可靠性评价。

（6）编制可靠性文档。

但是在正常的工作中，我们要做到这个程度是非常困难的，其中有业务的压力、整套工作的基础设施和人员配备等等。

三、实际操作流程

下面我说说自己的理解的业务研发生产活动如何做这件事，如下图，是研发过程中的活动好对应的角色，假设按照一个正常的流程，红色到绿色是确定性越来越高，风险逐级降低稳定性逐级提升的过程。 编辑

而一个不好的过程会很可能在其中某些步骤是没有做好本级的风险性评估和收敛不确定性遗留到了下一层级，最坏的情况是每一层都有一定的开绿灯情况，导致后面的风险等级越来越高稳定性越来越低，多个层级的疏漏在线上环境产生了化学反应，卷入了更多的部门且临场应急协调处理能力没跟上导致问题暴露给了客户，如下图：

编辑

从上图可以看出，我们研发从需求分析、详设、开发练调、测试、上线前准备和上线后运行一直都参与，所以在整个阶段中都需要做一些工作，我们大致分为需求分析、几个阶段，尽可能的都要做好几项工作。

1、需求分析阶段

在上线前的需求分析阶段，我们要对业务熟悉一些，因为我现在的理解业务流程才是最核心的，产品是业务流程的it线上化，在其中使用了一些产品的设计方法，如mvp、体验等来优化了产品，但是核心还是业务流程，关于理解业务流程，之前读到过这样一段话，虽然自己还没做到，还是借用分享一下哈：我们不能仅限于当前所处的场景中，要针对这个业务想办法了解那个业务的方法论，不局限于那个公司、行业和那群用户。对于我们技术而言，是要结合业务可以从技术的角度评估方案的完整性，并将不确定的点产出会议纪要，由专门的小伙伴去根据。但有时可能需求分析阶段的涉及的人员特别多，我们要借助raci模型来澄清需求，关于raci模型的解释可以看下方 编辑

在一般的软件项目中，阶段和角色的定义应该是这样的，但是在需求质量不高，或者需求方的产品文档很难承接业务流程的时候，我们研发和在需求收集阶段自己处于R这个角色，将产品经理和实际的业务人员当做C，防止需求经常变动或者业务流程设计本身有缺陷，更好的是我们本身对这个领域就很熟悉。

编辑

在讨论过程中如果涉及的相关方比较多，产生多次拉锯而无实际性进展的时候，我们可以借助这样一个决策模型来尽快的推进澄清需求确立分工和分批通过，主要是要描述清楚问题和背景、整理利益相关者和其关注的焦点，针对每个争论点会有几种解决方案和其利弊，和最终的结论和待办事项的处理人和完成时间，具体可以看下面这个模版的一到五（此处觉得可能还得学习项目集项管的内容，更有说服力的说明项目间冲突的时候该如何解决）：

一、问题陈述

要决策的问题是什么？这是工作计划或项目方案的一部分吗？为什么我们需要这个决策？

二、利益相关者

决策者

其他利益相关方

三、可选的解决方案

待决策问题的解决方案有哪些？每个方案的利弊是什么？

四、重要结论

在决策会议后，总结决策的结论，重点突出决策前后的对比

• 结论一：

• 结论二：

• 结论三：

五、任务分配

• 事项1：描述具体的下一步任务，负责人： ，截止时间：

• 如有额外考虑或需完成前置条件才能解决上述问题，在此行备注

• 事项 2：

在做好需求分析之后，涉及到外部的进入到设计阶段后一定要提前确定好和对方交互方式，是否强依赖对方，强依赖的要和对方确认好接口人和共同沟通的渠道，定好设计评审、开发联调、共同测试的排期，和该项目在对方该时间段的优先级和是否有阻碍性或者其他风险性因素。

2、设计阶段

到了我们自己的设计阶段，我们需要根据需求大小做好设计文档，关于设计文档，可以参考华仔老师的备选架构、详细架构、方案设计三个很完善(架构实战营 - 方案设计文档模板_架构实战营_华仔_InfoQ写作社区)，三者的区别如下图

编辑

我在这里贴一下华仔老师的原文内容（防止跳来跳去的）：

2、1备选架构

1. 业务介绍

[业务介绍主要描述需求的背景、目标、范围等]

2. 业务分析

[业务分析主要全方位地描述需求相关的信息，这里使用的方法是 5W1H8C]

2.1 业务背景分析

[业务背景分析方法采用 5W，分别指 Who、When、What、Why、Where。

Who：需求利益干系人，包括开发者、使用者、购买者、决策者等。

When：需求使用时间，包括季节、时间、里程碑等。

What：需求的产出是什么，包括系统、数据、文件、开发库、平台等。

Where：需求的应用场景，包括国家、地点、环境等，例如测试平台只会在测试环境使用。

Why：需求需要解决的问题，通常和需求背景相关]

2.2 核心业务流程

[业务流程分析方法采用 1H，注意这里的 How 不是设计方案也不是架构方案，而是“关键”业务流程。消息队列系统这部分内容很简单，但有的业务系统 1H 就是具体的用例了，有兴趣的同学可以尝试写写 ATM 机取款的业务流程。如果是复杂的业务系统，这部分也可以独立成“用例文档”]

2.3 关键业务约束 &限制

[约束和限制分析对应 8C，指的是 8 个常见约束和限制，即 Constraints，包括性能 Performance、成本 Cost、时间 Time、可靠性 Reliability、安全性 Security、合规性 Compliance、技术性 Technology、兼容性 Compatibility。

注 1：需求中涉及的性能、成本、可靠性等仅仅是利益关联方提出的诉求，不一定准确；如果经过分析有的约束没有必要，或成本太高、难度太大，这些约束是可以调整的。

注 2：不一定只能 8 个，可以更多

注 3：某个方面的约束和限制没有也要写“无需考虑”，不要不写，这样才知道是分析过了而不是遗漏了]

3. 复杂度分析

[分析需求的复杂度，复杂度常见的有高可用、高性能、可扩展等，具体分析方法请参考课程]

注：文档的内容省略了分析过程，实际操作的时候每个约束和限制都要有详细的逻辑推导，避免完全拍脑袋式决策。

4.备选架构

[备选架构设计，至少 3 个备选架构，每个备选架构需要描述关键的实现，无须描述具体的实现细节。此处省略具体架构描述，详细请参考课程内容]

4.1 备选架构 1：

4.2 备选架构 2：

4.3 备选架构 3：

5.备选架构评估

识别复杂度是在高性能、高可用、扩展性、低成本还是安全，设计备选方案、备选方案的影响点主要是需求、团队、技术、资源等、备选方案不要过于详细、以3到5个为最佳、要有差异、不能只局限于已经熟悉的方案，要坚持简单合适演化的原则，不能只设计一个最优秀的原则而没有顾忌多个因素有备选项

5.1 备选架构 360 对比

列出我们需要关注的质量属性点，然后分别从这些质量属性的维度去评估每个方案，再综合挑选适合当时情况的最优方案。常见的方案质量属性点有：性能、可用性、硬件成本、项目投入、复杂度、安全性、可扩展性等。在评估这些质量属性时，需要遵循架构设计合适原则和简单原则和演化原则，避免贪大求全，基本上某个质量属性能够满足一定时期内业务发展就可以了。完成方案的 360 度环评后，我们可以基于评估结果整理出 360 度环评表，一目了然地看到各个方案的优劣点。

5.2 备选架构决策

最后架构师综合当前的业务发展情况、团队人员规模和技能、业务发展预测等因素，将质量属性按照优先级排序，首先挑选满足第一优先级的，如果方案都满足，那就再看第二优先级……以此类推

有参考 从 0 开始学架构

2、2方案设计

前言

[可选，用于总体上描述本篇文档的内容和目的，一般包括项目名称（或者需求名称）、应用名称，目的一般都是“开发、测试、部署”]

[样例]

本文是扫码支付项目中会员域认证微服务的方案设计文档，用于指导认证微服务后续的开发、测试和部署。

修订历史

[可选，文档会因为各种原因导致修订，通过修订历史来记录变更情况]

[样例，因 infoq 写作平台不支持插入表格，这里用图片代替，实际 word 文档请用表格] 编辑

词汇表

[可选，用于明确定义和说明一些英文缩写、术语等，请用表格来呈现]

[样例，因 infoq 写作平台不支持插入表格，这里用图片代替，实际 word 文档请用表格] 编辑

1. 项目背景

[必选，概要的介绍项目背景，一般可以从立项文档、会议纪要、架构设计文档中找到资料进行提炼，提炼的核心内容可以用 5W 模型（who、when、where、why、what）来写，建议不要超过 5 行，更详细的信息可以直接贴需求文档、项目立项文档等链接]

[样例]

香港地铁公司（who）为了方便广大市民出行（why），准备在 2021 年（when）实现手机扫码乘车的功能（what），一期项目计划在 XX 线试点（where）。详细的项目背景信息请参考（注：链接仅为示意，不是实际的项目立项文档）：XXX项目立项文档。

2. 总体设计

[必选，概要介绍一下全流程的架构设计，如果架构有变化就需要介绍架构的变化，包括 Role、Relation；不管架构是否有变化，都要介绍一下需求的全流程的实现逻辑（对应 4R 架构定义的 Rule）。更详细的信息可以直接贴链接。]

[样例]

扫码支付的完整流程如下，详细请参考（注：链接仅为示意，不是实际的架构设计文档）：扫码支付架构设计文档。

编辑

3. 系统设计

系统设计就是指单个应用自己的设计。

3.1 系统边界

[必选，描述为了实现需求，自己负责的应用与外部哪些应用有关联（relation），这些关联可能是直接的接口访问、也可能是通过消息队列发送消息等方式，可以用架构设计中的“系统边界黑盒图”来展现边界和关联。

注意这里不要一一列举所有的接口，而应该按照分类来介绍接口类别，例如：会员接口，库存接口、订单接口这种就可以了，详细的接口在后面会一一说明。]

3.2 逻辑设计

[必选，逻辑设计其实就是指导如何写代码的，如果是 Java 这种面向对象设计，那就是类设计；如果用了 DDD 之类的方法，那就是领域对象设计；如果是 golang 这种，那就是 goroutine 和 channel 这种设计。

注意这里不是写伪代码，而是写代码的设计思路。

为什么要单独拿出逻辑设计来写，而不是放在接口设计里面写呢？因为逻辑设计是给很多接口用的，不能放在某个接口里面写。]

3.3 存储设计

[可选，描述存储系统的数据结构如何设计，例如 MySQL 的表设计、Redis 的 key 设计，Elasticsearch 的 index 设计等。

为什么要单独将存储设计独立出来，而不是放在接口设计里面呢？原因和“逻辑设计”是一样的。]

3.4 接口设计

3.4.1 会员中心交互接口

3.4.1.1 接口流程

[必选，描述自己的系统内部接口的处理逻辑，一般用 UML 的 Sequence diagram 展示，用文字描述处理步骤的具体处理逻辑。]

3.4.1.2 接口输入

[必选，用表格的形式描述输入参数和要求，可以根据实际需求添加更多列] 编辑

3.4.1.3 接口输出

[必选，用表格的形式描述返回数据，重点是错误码，需要一一列举，并且说明含义]

3.4.1.4 关键设计

[可选，如果接口处理流程中有一些关键的设计，例如全局幂等、限流、算法、兼容旧接口、熔断、安全加密等，需要在这里特别描述，注意不要把关键设计放到接口流程里面讲，因为那样会导致不同的关注点混杂在一起，不方便阅读和理解]

3.4.1.5 接口要求

[必选，估算接口的性能要求、响应时间要求、请求量等]

3.4.1.6 接口依赖

[必选，用表格形式列出接口处理流程中依赖的其它系统的接口、前置条件等。]

3.5 其它设计

[可选，包括特殊的网络设计、安全设计、证书设计、工具设计等。注意这里的相关设计内容是多个接口或者功能相关的，如果设计方案只针对某个接口，请放在接口设计部分的“关键设计”]

4. 部署设计

4.1 部署流程

[可选，部署的方式和步骤，方式包括金丝雀发布、灰度发布、蓝绿发布等，步骤包括准备工作、执行步骤、验证操作等，如果公司的基建比较完善，可以做到自动化，那么这部分可以简单描述。]

4.1.1 准备工作

[可选，包括需要的资源（例如服务器或者容器数量，存储磁盘容量，网络带宽……），依赖的外部条件（例如第三方系统升级到 XX 版本）等。]

4.1.2 执行步骤

4.1.3 部署验证

4.2 回滚流程

4.2.1 回滚标准

[可选，描述在什么情况下要进行回滚]

4.2.2 回滚操作

4.2.3 回滚验证

5. 风险评估

[可选，常见的风险有：

技术风险，例如引入了某个新技术，还不熟悉；

项目风险：人员不熟悉，人员变动大；

外部风险：政策风险、业务变动、外部配合进度等。]

5.1 疫情风险评估

5.1.1 风险评估

5.1.2 应对策略

2、3 架构设计

前言

[可选，用于总体上描述本篇文档的内容和目的，对于上层的架构设计，这里一般写“指导各个子域进行架构设计”；对于最下层的架构设计，这里一般写“指导后续开发测试和运维”]

[样例 1：本文是游戏业务线消息队列中间件详细架构设计文档，用于指导消息队列后续的开发、测试和运维]

[样例 2：本文是支付中台 L0 的架构设计文档，用于指导 L1 的各个子域（例如：交易域、支付域、营销域等）进行架构设计]

修订历史

[可选，文档会因为各种原因导致修订，通过修订历史来记录变更情况]

[样例，因 infoq 写作平台不支持插入表格，这里用图片代替，实际 word 文档请用表格] 编辑

词汇表

[可选，用于明确定义和说明一些英文缩写、术语等，请用表格来呈现，infoq 写作平台不支持表格，所以只能一个一个的列，实际编写的时候请用表格来展示]

1. 业务背景

[必选，从以下常见的角度来回答，你准备构建或者重构系统的目的和所处的位置是什么，可以是 1 个角度，也可以是多个角度，一般挑选重点的 3 个目的就差不多了：1.解决什么问题；2.带来什么价值；3.实现什么目标；4.完成什么任务；5.处于什么地位。]

[技巧：使用系统边界黑盒图来描述系统与外界的边界和交互关系]

2. 约束和限制

[必选，列出明确的约束和限制，常见的约束和限制有：1.投资方的成本要求；2. 监管方的监管要求；3. 技术选型的硬性要求；4. 项目时间要求；5. 质量要求]

[技巧：约束和限制越多越好]

3. 总体架构

[必选，描述经过备选架构决策后定下来的架构方案，这一章主要是描述架构的 3R：Rank、Role、Relation]

[技巧：1. 系统边界白盒图描述系统内的角色与外界的交互(Rank + Role + 外部 Relation)；2. 系统架构图来描述内部的 Role + 内部 Relation]

[注意：不建议一张图同时描述系统架构的 3R 以及与外界的交互，因为图太复杂，画系统边界白盒图的时候，系统内部的 Relation 可以不画]

3.1 架构分析

[可选，这部分主要是架构复杂度的分析，基本上从备选架构文档中提炼关键内容过来即可]

[技巧：常见的复杂度都要覆盖到，即使分析后不涉及也要描述，避免评审的时候被人认为遗漏了关键点]

3.2 总体架构

[必选，描述总体架构设计]

[技巧：

1.用系统架构图来描述架构，如果是前端或者客户端，用前端架构图或客户端架构图来描述架构

2.基于架构图中的内容，使用文字描述 Role、Relation 的基本内容，文档目录可以自由调整

]

4. 详细设计

[必选，描述核心场景或者流程的实现机制]

4.1 核心功能

[必选，描述核心场景或者流程的实现机制，对应 4R 架构中的 Rule，每个核心场景一个小节]

[技巧：使用系统序列图来描述 Rule，跟项目开发中写设计文档一样的写法]

4.2 关键设计

[必选，描述系统的一些关键设计点是如何实现和取舍的]

[技巧：常见的关键设计点包括高性能、高可用、可扩展、安全等]

4.3 设计规范

[必选，描述 Role 和 Relation 相关的开发框架、连接协议、数据包格式等]

[技巧：如果某个规范涉及内容比较多，请独立章节描述，例如数据包格式定义]

5. 质量设计

[必选，描述和质量相关的设计，包括：可测试性、可维护性、可观测性、成本等设计]

可观测性之前了解到做的比较好的是观测云和阿里云上的可观测性，需要贴链接

[技巧：如果某个维度不涉及，也请在文档中说明，避免评审的时候被认为考虑不周全]

6. 演进规划

[必选，可以是演进规划，也可以是项目计划，需要描述每个里程碑或者版本具体要实现的能力]

[技巧：开发阶段快速迭代，小步快跑，但要基本完善后才能正式推出给其他人用]

2、4设计的checklist

在做设计的时候我们还要遵循一些checklist，有技术的也有业务的

2、4、1技术checklist

⼀、技术维度（和本项⽬息息相关，从经验、项⽬、典型线上事故和测试

环境bug）

1、公共部分

2、场景化部分

1、场景1

2、4、2业务checklist（和本项⽬息息相关，从产品、经验、项⽬、典型线上事故

和测试环境bug）

1、公共部分

2、场景化部分

做设计的难点做好上线前后的改动点的影响面分析和兼容性，因为一个老系统已经经手多个人甚至多个系统，很难评估清楚，这样的问题现在的理解是建设好自动化测试用例，利用好ArchGuard：ArchGuard | ArchGuard 架构治理或者蚂蚁bizstack这样的框架来进行变更影响分析。或者设计好业务开关和技术业务指标的可观测性（可观测现在理解阿里云还有观测云上的产品还是很好啊）方便在上线过程中有问题可以直观反应出来，或者在上线后可以经常看到，配合监控告警手段来提早发现，关于可观测性和整个的监控告警和根因分析也是一盒很大的话题，我还得再看看。大家可以逛一逛这个社区：TakinTalks稳定性社区， 来学习业内先进的一些已经落地经验

3、开发联调

在开发联调和cr环节，这部分觉得比较重要的是遵循各种组件开发规范、适用范围和优缺点，这方面涉及的很多，我也在学习中，

4、自测环节

对于测试点可以借鉴一下金字塔原理中的几项内容：以上统下，归类分组，逻辑递进，先核心分支后次要分支，并且和测试约定冒烟用力范围，并严格执行。因为我现在的理解业务流程才是最核心的，产品是业务流程的it线上化，我们所负责的系统又是产品中的一个组成部分，所以我们很难从一个全局视角看清楚不测一部分会影响什么，会不会是核心业务流程？对于测试过程中一些偶发问题异常点要保持一些关注，否则真正的错误可能就被忽略过去了。

5、上线前环节

在上线过程中，做好一个上线的checklist，我们可以根据这样的检查点输出一份需求上线计划：

根据上面的点，我们可以整理一份上线checklist，如下：

基本信息归档

1. 涉及系发布顺序

1.1 涉及的系统和发布owner

备注：是否涉及前后端发布，如果不涉及需要备注

1.2 发布依赖

备注：相关系统如果有发布依赖，请按照发布依赖顺序进行发布，避免因发布依赖导致生产故障1.3 回滚顺序

备注：因发布（发布中/发布后）导致的生产故障，需要回滚系统，需要按照相关回滚顺序进行，避免回滚问题导致更多的生产故障。

1.4 系统兼容性分析

备注：

1. 说明系统间依赖兼容性问题

2. 说明系统内兼容性问题

配置变更

2.1 前端配置

备注：如前端获取协议请求，不同环境请求参数可能不一致，发布前需要确认是生产环境配置的协议编号

2.2 后端配置

2.2.1 后管接口相关配置

备注：包含不止以下配置项，如果有其他后管配置，则需要单独新增

2.2.1.1 新增/修改系统接口配置

备注：如系统新增接口，需要在后管平台目录：「系统管理-接口管理-系统接口」 中添加配置

2.2.1.2 新增/修改系统依赖接口配置

备注：如系统新增依赖接口，需要在后管平台目录：「系统管理-接口管理-三方接口」 中添加配置

2.2.1.3 新增/修改系统接口返回码配置

备注：如系统接口新增返回码，需要在后管平台目录：「系统管理-接口管理-返回码」 中添加配置

2.2.1.4 新增/修改系统元数据

备注：如系统新增元数据，需要在后管平台目录：「系统管理-接口管理-元数据」 中添加配置

2.2.2 开关配置

备注：包含系统开关配置数据，此类配置修改不需要系统发布

2.2.3 系统配置

2.2.4 数据库配置

新增/修改表结构汇总

2.2.5 缓存配置

备注：此处主要记录本次需求新增缓存类型，并评估是否合理；如果存在缓存相关配置变更，则单独说明

2.2.6 消息配置

2.2.7 定时任务

3.风险点

备注：此处需要记录开发过程中和发布计划评审过程中，在发布前未解决的风险点，在不影响当期功能的下可发布，后期新增迭代修改；如果存在阻碍生产流程的，或存在可能导致生产故障的风险点，则禁止发布

4.变更三板斧

备注：可监控（4.1、4.2）、可灰度（4.3）、可回滚（1.3）

可监控：发布过程中清晰对比不同批次基础监控与应用监控指标异动，及时暴露问题，定位变更风险；

可灰度：支持单批、分批、金丝雀等多种发布策略；支持按流量灰度，批次间自动/手动发布，分批间隔等多种发布选项；

可回滚：在发布过程中，允许人工介入控制发布流程，如异常中止、一键回滚。

4.1 变更监控

4.2 变更核对

4.3 灰度方案

备注：业务按照用户维度进行灰度验证

5.应急方案

在三板斧中，我们要用好业务开关（结合配置中心做灰度）、发布系统的流量开关、ab测试，ab测试我用过的是类似FeatureProbe这样的工具https://docs.featureprobe.io/zh-CN/等工具来确保产生问题的范围可控。

业务开关比较好的工具是配置中心，进行变动搭配权限下放可以到一线员工的上级，这样反应比较快。假设公司对于研发修改研发资产比较严格的话，可以借用配置中心的restful功能，例如nacos的：Open API 指南和apollo的：Apollo，来将修改的功能集成到权限较松的其他平台上

流量开关可以用阿里云的mse工具：阿里云微服务引擎MSE，（但是其实我实际还没在生产上用过）

6、上线后的验收和复盘

在上线后做好技术业务的验收工作和巡检工作，巡检模版待整理

在出现问题后，要走比较好的协同机制来进行善后，待写（稳定性指南）

在解决之后要有复盘，

tips：这这块的主要工作还待学习《SRE原理与实践》中的一些内容

四、稳定性、效率、成本之间的考量

在这个问题中，大家可能有些疑问，需求这么赶时间就这么一点，虽然自驱力可以解决一部分事情，但是整个系统的稳定性哪有时间做的这么细致啊。这也是我作为一个研发人员曾经想了很久也想不明白的点，后来在参加一场稳定性建设的讨论会后，我得到了一些答案：

不同业务对风险的容错率不一样，由业务线技术负责人把控需求分配，需要根据不同业务来平衡收益和风险，若稳定性问题严重，设置横向的稳定性小组和虚拟成员，主持故障评定、梳理、跟进，不设边界统管稳定性问题，则由稳定性小组介入立项整改，建立统一故障认知的前提下，在每一个事件 action 中不断加强流程落地，确保日常不低于10%的精力投入在稳定性建设中，，加强稳定性规范的培训和考核是比较好的手段，可以参考传统企业的“精益生产”思路落地稳定性规范

参考：开发任务都完不成，哪有空搞稳定性？先看看这13条建议｜TakinTalks论道和有借鉴张观石老师的书中一些思想

五、稳定性建设的边界

我现在的理解是要根据国家对这类业务的科技能力的国家规定、行业规范，还有公司对这块业务的卖点是什么，公司内对这里的规定是什么还有组内的默认行事方式是什么来确认适用边界。

六、稳定性建设的异议

大多数冲突在业务认为的开发速度无法满足业务的要求了，还要抽出人力做稳定性，现在的理解上要提前在月初甚至是季度出就沟通，

以项目管理的想法来和自己工作的所有干系人来核对清楚自己和关键干系人的下一个考核周期的目标，不致于遗留到很后面才暴露冲突，那时已经很难很好的相互沟通清楚，可能还会面对部门内研发效能的冲突，本质上是各自岗位对价值的定义和考核，成本和效率的认同不一样导致的。

虽然做好稳定性很难，但是还是我们在做需求过程中平衡好效率、成本和稳定性之间的权衡，做好自己系统的尽可能的稳定性，不再上新闻！