科学的制定流程制度是非常重要的，好的流程制度能提高生产效率、降低出错，但流程制度用不好是要阻碍创新的，甚至引起工程师的反感和抵触。
比如为了减少工程师出错，把工作的每个角落铺满精细的流程制度规范，每个制度事无巨细的几千上万字，无异于对工程师缚手缚脚，大家也背不过来，唯一的用途就是犯了错误追责任：看，有流程制度你不遵守。
事无巨细的流程制度，是反人类、反人性的，谁能记得住呢？长期积累下去，组织的能力、效率、活力都会下降，工程师成了流程制度的傀儡，成了工具人，与技术团队活跃、创新的文化截然相反，继而团队肯定要出事儿的，最后业务受损、人员离职再所难免。
但流程制度又是不可或缺的，没有流程制度，整个工作可能就是混沌的，低级错误不断，问题频发，关键要找准制定的领域，找到牵一发儿而动全身的点。制定时要围绕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）闭环跟进，直至业务全部恢复