故障处理流程和工具.md

Meta Data

Date: 2021-01-11 Address: 在线会议

背景

1. 有一千个微服务左右，全部跑在AWS ECS上。监控/日志收集得比较完整。

模型

Three Phases of Observability . 参见Beyond the 3 Pillars of Observability

问题

故障处理流程不够成熟：

1. Know阶段：SLO受损的时候，大多数团队会收到告警
2. 困难在于triage阶段，很难快速找出故障的Scope和impact。
3. 不能快速triage的后果是团队可能采取错误的remediation方案，比如扩容前端服务而掩盖了后端服务性能下降的事实，这样会拉长MTTR。
4. [Understand阶段]其实不很关键。

为什么不能快速scope？

1. 服务众多，服务之间的依赖关系不明确。
2. 虽然有很多可观测数据，但是分布在不同的系统，故障处理人员需要依据经验手工拉取查看。
3. 拉取到信息没有统一的展示地点，分布在Slack/google meeting/电话/办公桌，沟通成本非常高。
4. DevOps组织架构下，Dev对SRE技能的掌握参差不齐。

建议

1. 可靠性需要在系统设计阶段即加以保证，比如设计冗余服务。
2. 一个故障中心可以把主要依赖关系/SLO加以统一展示。
3. Datadog或者观测云可以把SLO和指标/日志/变更关联起来。