变更红线与问责

变更3要素

1. 可灰度
2. 可监控
3. 可应急

变更红线

1. 禁止在非变更窗口期、封网期进行变更（不同的公司变更期不通，基本都有高峰期/低峰期的规定）；这些变更包括但不限于：压测，代码提交到生成，紧急线上变更需要走审批流程。
2. 禁止未经测试验证， 预发验证，或者灰度的线上变更
3. 禁止无边跟影面、操作步骤、验证方案、应急预案及回滚方案说明的变更，应急预案必须具备可操作性，通俗的讲就是：任何变更都必须评估风险，做好sop，做好操作失败的修复方案。
4. 禁止一切变更方案外的操作，如果变更出现非预期的情况应当立即停止并将情况反馈到上级，不要做额外的操作试图来改变些什么，这中额外操作可能带来更大的不可控的影响。如果需要调整方案，需得到上级的批准，且走了紧急变更流程。
5. 禁止在生产环境执行或变更与线上问题排查无关的操作

说明：

1. 所有的系统都应该接风控平台，做到任何变更有记录，有据可循。触发变更红线的判定，也以系统日志为准。
2. 灰度必须为有效灰度，灰度比例包括但不限于地区、用户、设备、集群、机房。有线上有效流量，灰度时间不小于10分钟。变更期必须盯着监控面板，事后必须线上验证，有异常第一时间会滚
3. 线上变更指：对线上的任何操作，包括应用系统发布，系统调整，后台配置，数据结构变更，数据订正以及规则策略调整等一切线上变更操作。

红线问责

只有红线，却没有触发红线的处罚措施也是不行的，这就如同有了监控系统却没有报警系统一样，监控便成了摆设，发挥不出其价值。当然了，红线问责，也是为了提醒大家不要触碰红线，并非以处罚为目的。

责任人问责

问责，根据不同公司的规章制度进行问责，通常的做法是和和绩效，晋升关联。

1. 一次违反变更红线并引发故障的责任人，半年绩效不合格，并在技术团队范围通报
2. 二次违反变更红线并引发故障的责任人，全年绩效不合格，并在技术团队范围通报
3. 一些重要的活动，促销等期间产生的故障（不论大小，包括冒烟），都按照1，2处理。

违反红线变更，并对公司产生较大利益损害以及舆论压力的，可酌情劝退。

管理问责

如果一个团队连续出现违规变更，触发红线，那么管理者也当一并问责。

1. 每次违反红线的责任人，其主管连带问责严重警告一次，并且技术团队范围通报；如果主管受到2次严重警告，那么半年绩效不合格
2. 新人试用期内，实习生触发的触发规则的，由直接主管代为承担处罚