Uber大型分布式系统可靠性运维实践( 七 )

附加给警告的运行Runbook , 可以用描述简单的解决步骤是第一道防线 。 具有良好Runbook的团队 , 尽管值守工程师没有深入了解系统 , 也很少会出现问题 。 Runbook需要随时更新并添加处理新类型的解决措施 。

只要有多个团队部署服务 , 就必须在整个组织内进行通信 。 在优步工作的体系结构中 , 成千上万的工程师可以在他们认为合适的时候将服务部署到生产环境 , 每小时都会有数百次部署 。 在一个服务上看似无关的部署可能会影响另一个服务 。 在这里 , 标准化的中断广播和通信渠道有很大的不同 。 有多个案例 , 告警遇以前见过的情况 , 并且意识到其他团队中的人有可能遇到同样奇怪的事情 。 通过聊天组 , 很快确定了导致中断的服务 , 并迅速缓解了问题 。 这样问题解决的速度要快很多 , 作为一个团体远比每一个自己解决要快的多 。

先回退缓解故障 , 第二天调查 。 通常故障的根本原因是代码部署问题 , 代码更改有明显的错误 。 有人可能会现场修复错误 , 推送修复程序并重新上线而不仅仅是回滚该代码更改 。 但是 , 在宕机中再解决根问题是一个可怕的想法 。 通过这种在线临时修复 , 不会带来任何好处 , 反而会带来种种问题 。 由于必须快速完成的修复 , 因此必须在生产中进行测试 。 那个问题可能会在在现有错误之上引入第二个错误 , 或第二个宕机 。 导致恶性循环 , 疲于奔命 , 最后还是得会退 。 只需专注于先减轻压力 , 抵制修复或要找出真正的原因的冲动 。 适当的调查可以等到第二天 。

推荐阅读