SRE实践


故障排查手段

故障报告–> 定位问题 –> 检查 –> 诊断 –> 测试/修复 –> 治愈
常见的问题主要集中在定位、检查和诊断环节上
应该避免

  • 关注了错误的系统现象,或者错误地理解了系统现象的含义
  • 不能正确修改系统的配置信息、输入信息或者系统运行环境,造成不能安全和有效地的是假设
  • 将问题过早地归结为极为不可能的因素,或者念念不忘之前曾今发生过的系统问题
  • 试图解决与当前系统问题相关的问题,却没有认识到这些其实只是翘课或者这些问题其实是由于当前系统的问题造成的
    遇到问题的正确做法是尽最大可能让系统恢复服务,缓解系统问题是第一要务

事故流程管理

  1. 划分优先级:控制影响范围,恢复服务,同时为根源调查保存现场
  2. 事前准备:事先和所有事故处理参与者一起准备一套流程
  3. 信任:充分相信每个事故参与者,分配职责让他们自主行动
  4. 反思:在事故处理过程中注意自己的情绪和精神状态,发现自己开始惊慌失措或者感觉到压力难以承受,应寻求更多的帮助
  5. 考虑替代方案:周期性重新审视目前的情况,重新评估目前的工作是否应该继续执行,还是需要执行更重要的事情或者更紧急的事情
  6. 联系:平常不断地使用这项流程,直到习惯成自然
  7. 换位思考:上次你是事故总负责人,下一可以换一个职责试试,鼓励每个团队成员熟悉流程中的其他角色

事后总结

需要总结的条件:

  • 用户可见的宕机事件或者服务质量降级程度达到一定标准
  • 任何类型的数据丢失
  • on-call工程师需要人工介入的事故(包括回滚、切换用户流量)
  • 问题解决耗时超过一定限制
  • 监控问题(预示着问题由人工发现的,而非警报系统)

    协作和共享

    工具选择:
  • 实时协作
  • 开放的评论系统
  • 邮件通知
    事后总结还包括正式的评审和发布过程,首先在团队内部发布,同时有目的的找资深工程师评估文档的完整程度,评审条件
  • 关键的灾难数据是否已经被收集并且保存起来
  • 本次事故的影响评估是否完整
  • 造成事故的根源问题是否足够深入
  • 文档中记录的任务优先级是否合理,能否即使解决了根源问题
  • 事故处理过程是否共享了所有相关部门

文章作者: 彭峰
版权声明: 本博客所有文章除特別声明外,均采用 CC BY 4.0 许可协议。转载请注明来源 彭峰 !
  目录