成熟度

1. 故障概要，故障的简要描述。

   至少应描述清楚故障的时间、影响概述，持续时长，造成故障的原因，故障的级别等

2. 故障的级别

   应遵从故障级别定义，且与业务方、SRE、PMO等达成一致

3. 故障的影响

   除了定性描述外(比如造成新用户无法登录游戏)，还应尽量包括定量数据， 比如多少或多少比例用户(或API请求)受影响，造成资损多少, 用户反馈多少 例等.

4. 时间线, 以什么时间、发生了什么、谁做了什么决策，采取了什么行动等方 式记录。

   至少应包括: 故障的发生、发现、响应、恢复、后续处理等部分，如果有前 置因素(Leadup)，还需要包括该部分(比如故障由几天前的一次变更导致，则 时间线中应包括该变更)

5. RootCause

   从故障的影响出发，以"5Why"的方式，追问和推导，找到故障的根本原因

6. LaterActions, 对故障进行回顾和分析，确保类似故障下次不再发生，注意以下方面:

   i. 故障的发生: 故障发生的原因是什么？我们能否避免该问题再次出现？如果不能彻底避免的话，能否降低发生的概率，或者减轻产生的损失?

   ii. 故障的发现: 故障发生后，是否有告警发出？告警是否及时? （重大故障，应做到1分钟告警，5分钟响应，10分钟处理）

   iii. 故障的响应：告警发出后，值班同学是否有及时进行响应?

   iv. 故障的处理: 在故障处理过程中，是否有决策不及时或者不正确的地方，后续如何改进?

   v. 流程的遵循: 对于我们既有流程，包括变更流程，故障处理流程，此次故障的处理过程中，是否有很好的遵循?

   vi. Lucky的反思: 在本次故障的处理过程中，是否有些幸运的成分(虽然这次没有造成更大的损失，但依赖希望和运气，绝对不是SRE的策略)，后续在这个部分，如何加强?

   vii. 所有Action，都应该具体，对应到人，有结束时间，方便后续跟进

RCA 模板

参考：[Google - Site Reliability Engineering](https://sre.google/sre-book/example-postmortem/)

示例：[RCA 2021-12-02-xxx API Error Rate High]()

RCA = Root Cause Analysis

Summary 事件描述

用简短的几句话写出事件的摘要。

包括发生了什么、原因、事件的严重性以及影响持续了多长时间。

DurationTime 持续时间

故障持续时间： XXX 分钟

Level 故障定级

故障级别：P1/P2/P3/P4

Timeline 处理步骤

详细说明事件时间线。

包括任何值得注意的前期事件、任何活动的开始、第一个已知影响和升级。

请注意任何决定或做出的更改，以及事件何时结束，以及任何需要注意的影响后事件。

模板

YYYY-MM-DD UTC+8:00

HH:mm - 事件活动；所采取的行动

HH:mm - 事件活动；所采取的行动

HH:mm - 事件活动；所采取的行动

1. 故障生产
2. 发现
3. 初始处理

Impact 影响范围

事件造成的影响。

例如：对是否对用户资金造成亏损。

用户、订单、钱，哪些钱是不可挽回的

Root Causes 故障根源

5 Whys Analysis

描述影响，询问为什么会发生

询问为什么会发生这种情况，以及为什么会产生影响

继续问”为什么”，重复 5 次，直到找到根本原因

示例

应用程序中断，因为数据库被锁定

数据库被锁定，因为对数据库的写入过多

因为我们推动了对服务的更改，并没有想到提升的写入

因为我们没有为负载测试更改建立开发流程

因为在我们达到这个规模水平之前，我们从未觉得负载测试是必要的

注意事件的最终根本原因，即确定需要作出更改，以防止此类事件再次发生

Actions 行动项目

Resolution 解决方案

描述如何恢复服务以及如何认定事件已经结束。

详细说明服务是如何成功恢复的，您知道需要采取哪些步骤来恢复。

Recurrence 后续措施

描述为防止将来再次发生此类事件而采取的纠正措施。

注明负责人，必须完成工作的时间以及跟踪工作的位置。

• 怎么避免
• 2次发生有没有兜底方法
• 报警/用户反馈后，响应时间快否，处理方法对不对，处理过程有没有，通知人，有无故障升级优化

Supporting 关联资料

故障定义 & 定级

故障 ，是指任何不是计划中的服务不可用或服务降级。

停服维护，不是故障;

故障分为4级: P1, P2, P3, P4；其中P1为最高级别，P1、P2为重大故障;

具体的 故障定级 ，参见: xxxx

角色(Roles)

故障处理相关角色，一般包括： 指令长 (Commander)、 联络官 (Liaison)、 组员 (Staff)等； 指令长 的职责，主要包括:

1. 故障前的准备：包括信息收集和组员培训;
2. 故障处理: 根据各方信息，做出决策，尽快解决故障；
3. 故障解决后: 组织RCA的撰写，协助Action的跟进; 联络官 的职责, 主要包括:
4. 找人（包括值班组员、其他组负责人、以及故障相关干系人等);
5. 和各干系人通报故障处理进度;
6. 与各干系人沟通，回答问题，避免故障处理小组受到不必要的干扰; 组员 的职责，主要是执行指令长的指令，调查并解决故障;

值班表 & 紧急联络表

(TBA)

故障响应(Incident Response)

• 处理原则

  故障响应的处理原则为，以恢复服务为最高优先级; 指令长的任务就是推动故障的快速解决；

• 响应流程

  响应流程分为：启动、处理、善后三阶段.

  • 启动阶段
    • 值班同学在收到告警、投诉反馈后，回复"处理中";
    • 第一接警人通过查看监控，确认是否故障；如果是故障，则拉起视频会议，启动故障响应流程.
  • 处理阶段
    • 当日值班长为故障指令长；如果值班长联系不上，则副值班长为指令长; 指令长负责处理此故障;
    • 根据紧急预案，进行降级和止血，尝试恢复服务;
    • 根据最近的变更，找到可能与此故障相关的变更，进行回滚（关闭功能开关，或者紧急回滚发布)，观察故障是否解决;
    • 召集相关问题专家，进行诊断，并制定解决方案;
  • 善后阶段
    • 组织团队观察，确认故障不再出现;
    • 组织RCA的调查和撰写;

• 故障升级

  故障发生后，10分钟没有处理完毕，升级至二线值班长;

  30分钟没有处理完毕，升级至三线值班长;

• 故障沟通

  • 故障响应流程启动后，联络官：

    i. 拉起Zoom会议，通知业务负责人和TL;

    ii. 在Jira中创建故障Ticket;

    iii. 在故障slack群中，发送故障通知，并给出应急会议的链接;

  • 当故障应急小组，涉及钉钉会议和Zoom会议两方时，负责同步两方信息;
  • 在故障Slack群和Zoom会议中，同步故障的处理进展;
  • 按照故障升级要求，通知相应干系人；

故障RCA

故障处理完毕后，需要整理 故障RCA 。故障发生当天的值班长，负责组织撰写; SRE组负责评审验收;

故障RCA模板，参见:

(TBA)

故障响应的持续优化

• 故障现场保留
  1. 服务因各种原因崩溃、或者被自动/人工重启时，需确保相关的信息（包括GC日志、线程栈、应用日志等)已被保存并转储;
  2. 系统和应用日志需要集中收集，系统日志至少保留3天，应用日志至少保留7天;
  3. 监控信息，需要至少保存30天以上;
• 故障处理过程存档
  1. 故障处理过程中的行动（包括调查和处理)，及其进度更新等，使用dingtalk/slack同步更新，这样附带有时间戳，便于事后回溯;
  2. 钉钉会议和zoom会议，进行录音、录像；
• 故障复盘 & 持续优化
  1. RCA是最重要的复盘手段，确保RCA中的后续行动落实到人，SRE组负责后续的跟进;
  2. SRE组在故障处理完毕后，需要及时汇总分析故障处理过程，对值班组相关成员进行持续培训;
  3. SRE组每月整理稳定性月报，将相关经验和教训，与全员分享;
  4. SRE组定期做故障模拟和演练，确保系统和值班团队时刻保持着警惕，做好了准备；

业务自身功能、资损、客诉等维度持续时间内的影响面。

一. 变更定义

变更 ，指对线上系统的任何操作（如：发布、增加、修改或移除等），或其他对生产业务可能有影响的任何操作。

包括但不限于：代码发布、数据库操作、配置修改、基础环境变更（如K8S版本升级等)。

变更实施，需要满足风险防控三原则： 可灰度 ， 可监控 ， 可回滚 。

变更类型

紧急变更: 为修复重大故障，或可能引起重大故障的问题而发起的变更;

一般变更 ：除紧急变更以外的线上变更，包括代码变更，配置变更(包括发布的灰度比例调整等)，基础设施变更等;

数据变更 : 数据变更，包括但不限于以下操作:

i. 增加数据库表或字段;
ii. 废除数据库表或字段;
iii. 对数据库表或字段的语义或内容格式，进行修改；(例如，某订单表，原来只包含真实用户的订单，现在可能包括压测用户的订单数据，或者反过来；)

二. 变更窗口

周一到周四（非节假日，非封网期) 7:00~20:00（北京时间) 是 变更窗口

除紧急变更外，其余变更都只能在变更窗口进行

如果确有业务需要，必须在变更窗口之外(包括封网期)的时间进行发布，提交破网变更申请，由总值班长审批后进行发布.

三. 上线流程

日常验证 -> (预发验证) -> 提交变更申请并审批通过 -> 灰度发布并观察 -> 线上验证

• 日常验证

  日常环境为QA集成环境，与生产环境物理隔离。

  所有变更上线前，必须在日常进行验证：本功能完全测试，影响功能的测试，回归测试，回滚测试;

• 预发验证

  预发环境，与生产环境数据相同，但有一定隔离。

  对于有预发环境的业务，在上线前，必须在预发进行验证:

  本功能通过测试，影响功能的通过测试，回归测试;

• 变更申请

  根据变更类型，提前发起变更申请，变更申请以邮件形式发出，必须经值班长/总值班长审批通过后才可以进行发布.

  1. 除特别说明的变更以外，所有变更都应该提交变更申请，并在审批通过后才可以进行变更操作;
  2. 紧急变更，不需要提交变更申请（但仍需值班长同意，且做变更通知);
  3. 调整灰度发布的比例，不需要提交变更申请（但仍需值班长同意，且做变更通知);
  4. 对于破网变更申请，需要总值班长审批;
  5. 对于不满足”可监控、可灰度、可回滚”要求的变更，需要总值班长审批;
  6. 一次变更，应只解决一个问题，或者新加一个feature，这样对于变更的风险更可控，万一发布出现问题解决起来也容易。不建议搭车发布;
  7. 具体模板，参见”/变更申请模板/”.

• 灰度发布

  所有变更，都需要进行灰度发布，并在灰度发布期间，观察相应指标，包括业务监控&告警、Sentry中的新异常告警、服务器日志等;

  1. 根据变更类型特点、业务复杂程度及变更的风险，选择合适的灰度策略。
  2. 根据业务特点，选择灰度时间的长度;
  3. 灰度期间，必须要有一定的流量; 在半夜发布，并结束灰度，没有任何意义;
  4. 对于某些功能，后端先发布，前端后发布；对于这种情况，后端发布后，先保持Feature功能开关关闭，等前端发布完后，再进行灰度;
  5. 对于Nacos配置，也应做灰度发布;

  常见灰度策略包括:

  • 分批发布
    • 根据服务器数量，一般选择4批以上;
    • 先发布第一批，观察10分钟，没问题后再发布后续批次;
    • 该策略的一个变种是，先做Beta发布(发一台或若干台服务器), 观察没问题后，再继续做分批发布;
  • 按用户灰度
    • 此策略按照用户ID，进行灰度;
    • 通常形式是，使用FeatureFlag模式，在分批发布完毕后，按照白名单，1%，10%，50%，100%逐步放量灰度;

  • 其他灰度策略

    其他灰度策略，包括按服务灰度（如JDK版本升级)，按机房灰度（如基础设 施变更)，按业务灰度（如中台功能变更）等.

• 线上验证

  变更完成后，需在线上进行验证，验证内容包括：本次变更相关功能的正向流程(验收用例)，以及系统核心回归用例。

• 变更通知

  变更前后，需要在对应的oncall群，发消息.

• 发布失败的处理

  当发布失败时，应及时回滚;

  如果回滚失败，应立即停止操作，通知值班长，进行下一步处理, 避免二次故障;

• 数据变更

  对于数据变更，需要同步给对应BI同学，避免数据故障

四. 其他

1. 运营执行的操作，比如在OPS控制台对某些配置进行调整等，参见运营相关规范，不属于本流程规定范围;
2. 前端、客户端的变更，暂不属于本流程规定范围;
3. 变更时间窗口，按实际上线开始时间计算，而不是变更审核完成时间计算；比如在周四15:00发的变更申请邮件，17:00审批，但截至20:00还没有完成上线前的最后验证，则不可以继续发布;
4. 可监控(可观测)的要求是，至少包括2个以上的核心业务指标（比如下单、付款等)，以及Sentry新异常监控;
5. 系统核心回归用例，指系统核心功能的回归用例集，包括系统核心功能，覆盖P1P2故障，所有研发(QA,后端，前端)都可以快速执行;

1. 代码变更(包括后端，前端，客户端)，必须做CodeReview;
2. 变更（包括紧急变更）上线前必须进行测试;
3. 变更上线后必须进行线上验证;
4. 变更执行过程中，必须观察监控、告警和反馈;
5. 禁止一切未按规定提交变更申请或暂未审批通过的变更;
6. 变更执行前后（包括灰度比例调整)，必须通知相关干系人;
7. 禁止在变更执行过程中，进行与变更申请中的方案不符或无关的线上操作;