Skip to content

Latest commit

 

History

History
15 lines (14 loc) · 1.74 KB

ops_code.md

File metadata and controls

15 lines (14 loc) · 1.74 KB

运维准则

  • 尽量公开(chat 群、issue 等)讨论问题,避免 chat 私聊,避免信息不对称以降低沟通成本。
  • 值班的对当天所有事务负责,包括工单、chat 群的提问、报警等。
  • 驱动问题解决:
    • 及时响应。
    • 及时反馈进度或结论,至少每天一次,避免被对方追问进度,对于偶发或较难解决的问题,禁止采用对方不追问就不再管的处理方式,严禁问题不了了之,必要的话可以创建 issue 追踪。
    • 自己不清楚这个问题的话,咨询其他成员,或者督促其他成员解决,确保问题得以解决;禁止只是让对方找某某某然后不再管。
    • 回复问题结论时,最好说明问题原因。
  • 所有对各环境的改动,最终要体现在配置或代码中,严禁出现环境状态与配置或代码不一致、不同步。
  • 每一个报警要及时分析原因,确认是否需要干预,以及如何避免再次报警,不合适的报警规则要及时进行调整,不确定如何处理的询问 SRE lead 。
  • 对于特殊的请求,询问原因,必要的话跟 SRE lead 确认是否可以,不要一味得执行。
  • 避免特殊处理,必要的话跟 SRE lead 确认是否可以,临时应急方案必须留好 TODO issue ,事后清理。
  • 从根本上解决问题,考虑每个问题的成因,是否有可能再次出现,如何避免,不知道如何处理的,与 SRE lead 讨论。对于问题成因,要有理论依据,最好能通过实践证明,不要做无根据的猜测或进行无根据的修复尝试。
  • 在 staging 等公用环境测试时,有一定风险的,先在 chat 群通知所有人,什么时间会做什么事情,会或者可能会有什么影响。