码迷,mamicode.com
首页 > 其他好文 > 详细

变更红线与问责

时间:2020-01-06 12:25:30      阅读:85      评论:0      收藏:0      [点我收藏+]

标签:窗口   连续   需要   测试   变更   产生   方案   数据   步骤   

变更3要素

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

变更红线

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

说明:

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

红线问责

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

责任人问责

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

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

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

管理问责

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

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

变更红线与问责

标签:窗口   连续   需要   测试   变更   产生   方案   数据   步骤   

原文地址:https://www.cnblogs.com/vinsent/p/12155517.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!