上周，因为非生产环境的配置同步到了生产环境，该配置打开了存在问题的旁路开关，开关被打开导致用户流量走了存在问题的旁路，由于研发止血及时，仅仅影响了1000+客户。虽然影响少量客户，但背后暴露的问题让人后怕，试想，若止血不及时，影响面会被无限放大。
序言
过去一段时间，部门线上问题一直控制在一个不错的水平。近期，因各阶段都缺少对线上问题蔓延的重视，造成的线上问题影响面越来接大，几近失控。因此需要1评2做3检。1评 是要求在需求评审阶段评估应用风险，2做 是指系分评审阶段增加质量建设，3检 是指测分评审阶段评估质量方案。
正文
最近一段时间线上小问题频发，线上问题就像森林中星星点点的小火苗，第一很难防范，第二存在蔓延风险。系统链路像森林一样非常之庞杂，没有一位护林人员能保证森林不出现火星，同样也没有一个质量人员能保障系统 100% 不出问题。正所谓星星之火可以燎原，小火苗不致命但若消灭不及时，随时有蔓延的危险！既然问题如此棘手，那这场灭火行动中大家就什么也做不了了吗？
当然不是！虽然没办法保障系统 100% 不出问题，但可以阻止火苗蔓延，把风险杀死在襁褓之中。我们先从上线流程开始逐一分析，上线流程大概有五个阶段: 需求评审阶段，系分评审阶段，测分评审阶段，研发阶段，测试阶段。除去以干活为主的两个阶段:研发阶段和测试阶段，剩下三个阶段都应该加强对“如何阻止线上问题蔓延”的关注。那么，到底该如何加强呢？
我总结了一个方案：阻止问题影响蔓延123——1评2做3检。
1评：需求评审阶段评估应用风险。产品是此阶段的主力军，由于过于关注功能设计，往往缺少对应用上线风险的评估，应该评估受影响的客户量和受影响后果，比如受影响用户超过 1000+ 或者该需求出现问题会引发客诉，产品要标以高风险，必要时建议延迟上线时间，以实现代码上线的保质。
2做：系分评审阶段增加质量建设。研发通常着眼于设计系统架构和确认功能是否符合预期，缺少对高风险应用的质量建设，应该对高风险应用设计代码快速回滚方案和切流方案。在问题出线时，快速回滚代表着快速止血，是掐灭火星的最快的方法 ，切流能控制应用影响范围，通过流量控制影响用户数，能有效防止火苗蔓延。
3检：测分评审阶段评估质量方案。测试着眼于代码的质量检测，缺少对研发质量方案的评估，应该将切流和回滚方案纳入到检测日程，测试是上线前的最后一道防线。
可以看出，犹如消防要人人从日常做起，阻止问题蔓延也需要全流程，各方一起努力。质量同学是这场战役的组织者和监督者，第一要牵头整理方案同步到各方，第二要监督各方稳定运作。