心法|SRE如何制定科学有用的流程制度

Posted 2023-01-05

科学的制定流程制度是非常重要的，好的流程制度能提高生产效率、降低出错，但流程制度用不好是要阻碍创新的，甚至引起工程师的反感和抵触。

比如为了减少工程师出错，把工作的每个角落铺满精细的流程制度规范，每个制度事无巨细的几千上万字，无异于对工程师缚手缚脚，大家也背不过来，唯一的用途就是犯了错误追责任：看，有流程制度你不遵守。

事无巨细的流程制度，是反人类、反人性的，谁能记得住呢？长期积累下去，组织的能力、效率、活力都会下降，工程师成了流程制度的傀儡，成了工具人，与技术团队活跃、创新的文化截然相反，继而团队肯定要出事儿的，最后业务受损、人员离职再所难免。

但流程制度又是不可或缺的，没有流程制度，整个工作可能就是混沌的，低级错误不断，问题频发，关键要找准制定的领域，找到牵一发儿而动全身的点。制定时要围绕SRE的主线顶层目标，流程制度本身要本着数量少、质量高的原则，而且流程制度一定要简单好记、易执行，定原则而不是穷举流程细节。

例如以质量为目标定制度，参照运维质量环（故障前中后），第一是避免问题进入生产环境形成故障，第二是如若无法避免，工程师可以快速发现故障处理。这是两个最重要的节点，类似蛇的七寸，如若做好，就可以大幅减少故障数量和故障发生后的影响，达到提升质量的目标，同时为将来用DevOps承担制度做好准备，以此为例我们团队制定两个流程如下。

1、示例|团队变更规范（知影响、盯指标、懂进退、守流程）

变更12字方针：知影响  盯指标  懂进退  守流程

• 变更时间

工作日 9:30~11:30，14:00~17:30

• 原则

知其然、知其所以然

渐进式变更

• 变更前

 1）清楚变更的影响

        清楚的认识到当前服务变更会影响哪些服务、哪些用户体验

 2）清楚变更是否符合预期的指标

        观察可用性、时延、QPS或者其他关键指标

 3） 清楚变更失败的预案

        回滚，或者其他方案

 4）DoubleCheck

        和自己的mentor或者leader做好确认

 5）变更通知

        必须通知到相关研发负责人以及AIoT SRE变更群

• 变更中

1）灰度单台

        发布单台，观察指标以及对应程序状态、日志，观察10分钟，确保正常再继续

2） 全量其他

        渐进式全量同机房其他节点、其他机房

3）观察指标

        全程实时关注变更后相应业务指标的变化

4）关注报警

        紧盯报警信息，有相关报警及时跟进

5）及时回滚

   变更中发现问题，第一时间操作回滚

• 变更后

1）变更总结

   进度、影响是否符合预期

2) 持续观察指标至少30分钟

   防止打点有延时、或者影响滞后导致未及时发现

3) 持续关注异常信息

  关注相关业务群异常信息、报警是否和变更关联

2、示例|团队Oncall规范（接告警、勤通告、助恢复、做闭环）

Oncall 12字方针：接告警 勤通告 助恢复 做闭环

• Oncall要求

  主备Oncall同学需24小时接收处理告警，保持手机、飞书畅通

• 原则 

  先恢复业务，再排查原因

  Oncall同学是故障处理的组织者

• Oncall处理流程

1）收到告警第一时间在Oncall群通知，并@到对应研发和SRE同学

  P0告警：5分钟没恢复，开启电话会议，并发到AIoT SRE群上报

  P1/P2告警：5分钟没响应，飞书加急或电话通知

2）每10/20分钟在群内通报对应告警监控指标的恢复曲线

3）协助故障恢复，将查到的信息同步到群里，引导先恢复业务再排查原因

4）判断后，如影响严重，第一时间在AIoT SRE群内升级，并@高利绪

  进入重大事故处理流程，由@高利绪 将事故上报质量委

5）闭环跟进，直至业务全部恢复

欢迎关注原创公众号「运维网咖社」——矢量比特（高利绪）