谈一谈线上事故的故事

背景

做过不少公司的咨询，发现有些公司对于线上事故没有规范化的认知，没有预防措施，发生之后也没有一个规范的流程去响应。甚至有的公司发生线上事故之后，没有监控没有预警，只有开发或运维知道，然后他们就悄悄的把线上事故修复了，神不知鬼不觉。

那么接下来我就从下面这几个方面来谈一谈线上事故的故事。

线上事故预防

线上事故预防分为3个方面

• 预发环境
• 上线checklist
• 日志与运维监控

预发环境

预发环境也叫UAT环境，或者预生产环境等。

非生产环境中应该有一个预发环境，此环境理论上应该和生产环境一模一样，包括一样的配置来保证性能一致，一样的数据来保证行为一致。

这样才能最大限度的模拟生产环境，并提前发现问题解决问题，起到沙盘演练的作用。

预发环境的位置如下图：

预发环境搭建好了之后，应该定期的同步生产环境的数据到预发环境做测试。

注意：同步数据时得有一定的脱敏策略，不然会有安全风险。

影子流量

由于预发环境毕竟不是生产环境，所有的请求都是由测试人员模拟的，并不是真实的情况。

而影子流量(shadow traffic)就是将发给生产环境的请求复制一份转发到类生产环境上去，以此来达到压力测试和正确性测试的目的。

影子流量的实现有多种方式，常见的比如在统一的入口处API Gateway等地方复制一份流量转发到预发环境，由此来监测预发环境有没有异常情况发生。

影子流量的过程如下图所示。

由于影子流量来自真实的生产环境，过程中一定要注意安全防范，以及流量转发给生产环境性能带来的性能影响。

影子库

同理影子流量，理论上预发环境应该有一份和生产环境一模一样的数据库，才能更真实的模拟生产环境的情况。影子库就是把生产环境的数据库复制了一份，有相同的数据量和相同的数据库配置。

当然，理论上，影子库的数据应该是经过脱敏处理之后的。

上线checklist

上线前应该有一份不断累计不断更新的checklist，用于上线前的检查，每项检查都通过之后，方能上线。

有任何一项检查不通过，则不能上线。直到问题解决之后，才能上线。另外，应该避免在业务高峰期进行上线操作。

下面是一些常见的checklist项，不同的项目会根据需要有不同的checklist：

• 测试报告是否已通过
• 业务验收报告是否已通过
• 是否有其他版本正在上线
• 是否有线上问题未解决
• 是否有回滚方案

虽然它是checklist，但很多公司在实践的时候都把它做成了上线报告。

更推荐的做法是把checklist做得越轻量级越好，就像checklist，轻量级的检查就能上线。

不然就会让上线变得越来越困难、越来越花时间，违背了持续交付的理念。

日志与运维监控

如果有非常完备的日志系统，比如常见的ELK，splunk等，则可以在预发环境的影子流量中和生产环境中，监测到异常日志，提前发现问题，提前解决问题。

日志监控是一个挺大的话题，这里就不展开讲了。

但日志是我们定位问题和追溯问题中不可或缺的一环。

线上事故修复

线上报警

线上环境应该有监控预警，一旦发生任何事故，都应该及时报警。

这些事故可能发生的情况包括但不限于：

• 服务不可用
• 数据库不可用
• 服务器不可用
• 高级别日志警告
• 流量异常

发生了事故，应该第一时间自动通知开发团队，并抄送相关负责人或领导。收到邮件或通知的开发团队则应该第一时间修复该线上问题。

邮件中应该包含事故的现象描述，原因，日志等信息，以方便开发团队分析和修复。

最重要的是，上述过程都应该是全自动化的，才能保证开发人员或者运维人员第一时间响应。

通常一个团队中会建立某种机制来保证发生线上事故的时候有人能及时响应事故。

我见过有的公司是运维人员24小时待命的。

也见过做的比较好的公司是，团队成员轮流做那个站岗的人，系统通知自动绑定站岗人的电话和邮件，发生线上事故之后，第一时间自动逐级通知站岗人，负责人，领导等。由站岗人作为线上事故的owner，他不一定能修，但他要保证问题被修复。如果事故发生在工作时间以外，则根据响应的时间来调休。

回滚机制

优秀的团队都是使用CI/CD的pipeline来进行上线部署，一旦失败了，pipeline都是支持回滚到上一个版本的。

如果是使用的Kubernetes，则只需要回滚到上一个版本的镜像则可以了。

这就要求，我们每次构建的包或者镜像都应该带上版本号，才方便我们追踪每个版本的状态，以及根据版本来进行回滚操作。

灾备恢复

线上事故如果是灾难性的，则应该启动灾备恢复程序。 我了解的大部分公司其实都没有灾备恢复的相关流程。理论上，一个意识比较好的公司，通常都会有严格的灾备恢复流程。

灾备恢复可以是一个操作手册，指导员工如何一步一步的从0恢复服务。通常银行业是一定有这样的灾备恢复的。

同时，每次发生了大的基础设施架构变更的时候，比如服务器配置变化，数据库变化等，都需要及时更新灾备恢复手册。

线上事故复盘

线上事故修复之后，需要对此事故做一次复盘，目的是为了避免下次再发生，以及发生了之后能更快的应对。

这个复盘有很多种形式。其中一种形式叫无过错验尸报告。

具体的介绍可以看我的另外一篇文章：
无过错验尸报告 - Blameless Postmortem

总结

这里简单列举了一些关于线上事故我能想到的几个点，如果大家对于这个话题还有其他感兴趣的部分，欢迎给我留言，我们下回接着探讨。