事後回復ハンドブック: 回復後に回復アクションを強化する方法

事後回復プレイブックが必要な理由

障害レビュー (事後分析) が完了すると、チームは通常、原因分析と改善項目のリストを作成します。しかし問題は、リストが Wiki に掲載されたのに、数か月後には誰も覚えていないということです。次に事故が発生したとき、私は依然としてチャット履歴を調べて同僚に「前回はどうやって回復したのですか?」と尋ねることになるでしょう。

事後回復プレイブックは、反復可能な回復アクションをバックアップから抽出し、それを誰でも (勤務中の新人を含む) 従うことができるステップ マニュアルに形式化します。これは根本原因分析に代わるものではありませんが、「回復が遅い」という問題を解決します。Google の SRE 実践では、プレイブック サービスを使用すると MTTR (平均回復時間) を 50% 以上短縮できることが示されています。

しかし、多くの人は、プレイブックを作成するときに罠に陥ります。実際に実行可能なステップを抽出せずに、レビュー レポートの全文をコピーしてしまいます。その結果、プレイブックは誰も読んだり使用したりしない単なるドキュメントになってしまいます。

入力内容のレビュー: 回復アクションを開始する価値のあるコンテンツは何ですか?

レビューの結論すべてがプレイブックになるわけではありません。次の条件を満たすアクションのみを記述する価値があります。

• 検証可能: 効果は実行後すぐに確認できます (サービスの再起動、トラフィックの切り替え、バージョンのロールバックなど)。
• 決定的: 複数の人が同じ条件で実行した場合、結果は一貫します。
• 制限付き: トリガー条件が指定されます (例: 「P99 遅延が 3 分間 500ms を超えた場合」)。

例: レビューでは、「データベース接続プールが枯渇し、リクエストがキューに入れられる」ことが判明しました。根本的な原因は、コード内で接続が閉じられていないことです。根本原因自体は修正タスクであり、開発の繰り返しに委ねられます。 ただし、回復アクションは次のとおりです: 「接続プールの使用率が 2 分間で 90% を超える場合、接続プールの上限を自動的に 200 に拡張し、アラームをトリガーして DBA に介入を通知します。」このアクションは Playbook に書き込むことができます。

よくある失敗シナリオは、チームが「コードレビューの強化」や「単体テストカバレッジの拡大」などの長期的な改善項目をリカバリーアクションとみなすことです。これらは重要ですが、戦略の一部ではなく、改善のバックログの一部です。

回復アクションの沈殿化: レビュー レポートをステップに変換する方法

復旧アクションを抽出するときは、リストではなく「操作フロー」形式で整理することをお勧めします。たとえば:

步骤 1：确认影响范围
  - 登录 Grafana 查看全局错误率面板
  - 如果错误率 > 5%，转步骤 2；否则继续监控 10 分钟
步骤 2：执行回滚
  - 切换到上一次稳定版本标签（v2.3.1）
  - 确认部署后错误率下降至 < 1%
  - 如果回滚失败（如版本冲突），转步骤 3
步骤 3：切换流量到冷备集群
  - 修改 DNS 记录指向备用集群 IP
  - 等待 TTL 过期后验证可用性

重点在于：写清楚判断条件和备选路径。很多团队只写了“执行回滚”，但回滚本身可能失败，没有 fallback 计划就会卡住。

另一个容易失败的地方是：步骤中缺少“负责人”。比如“重启服务”这个动作，谁有权限操作？值班 SRE 还是开发工程师？在 playbook 里明确“由 on-call 工程师发起，需要安全审计授权”可以减少推诿。

告警与负责人：当 playbook 和监控联动

Playbook 不能孤立存在，它必须与告警体系绑定。做法是：在 playbook 头部标明触发此 playbook 的告警规则。例如：

告警名称：HighErrorRate
告警条件：服务错误率 > 2% 持续 5 分钟
负责人（Role）：On-Call SRE（主）, 后端服务负责人（备）
切换条件：On-Call SRE 10 分钟内未响应，自动升级给后端负责人

「確認待ち」による遅延を避けるために、担当者とアップグレード条件を明確に書き留めてください。実際のケース: チームのプレイブックには「DBA に連絡する」と書かれていましたが、当番の DBA が誰であるかは示されていませんでした。その結果、電話がつながるまでに 20 分かかりました。改善後は、プレイブックに「Enterprise WeChat Robot @DBA Duty Group」を直接記述し、5分間応答がなかった場合に自動的に電話をかけるルールを埋め込みます。

人物だけでなく、ツールの入り口も明確に記載する必要があります。たとえば、「ロールバックを実行する」アクションの場合、単に「CI/CD プラットフォームを使用する」と記述することはできず、「Jenkins (アドレス: xxx) にログインし、「最後の安定したものにロールバックする」パラメーター化ビルドを選択する」と具体的に記述する必要があります。

次のチュートリアル: プレイブックがゾンビ ドキュメントになるのを防ぐ方法

Playbook の最大の敵は使用されていないことです。定期的な訓練が唯一の解決策です。

訓練の頻度は、サービスの重要性と変更の頻度によって異なります。私の提案は次のとおりです。

• コア決済サービス: 毎月のウォークスルー
• 一般 API サービス: 四半期ごと
• 内部ツール: 半年ごと

訓練はフルフロー ストレス テストである必要はなく、机上訓練でもかまいません。チーム メンバーはハンドブックの周りに集まり、口頭で手順を実行して、不足している領域や不明瞭な領域を見つけます。

失敗シナリオ: 多くのチーム訓練は、異常な状態をシミュレートすることなく、単なる「読み上げ」に過ぎません。より効果的なアプローチは、訓練中にプレイブックに書かれていない障害ポイント (アラーム チャネル自体が切断されている、ロールバックのバージョン番号が間違って書き込まれているなど) を意図的に作成し、実践者がそれを回避する方法を知っているかどうかを観察することです。

各演習の後、プレイブックのバージョン番号を更新し、変更内容をチーム グループで発表する必要があります。 Git をバージョン管理に使用できます。各提出記録には「この演習で特定のステップに判定条件が不足していることが判明したため、補足しました。」と記載されています。

よくある誤解と境界線

1. **プレイブックは詳細であればあるほど良いですか? ** いいえ。 20 ステップを超えるプレイブックは、実行中にフォーカスを失う傾向があります。 10 ステップ以内で制御し、必要に応じてサブ Playbook (「ロールバック サブプロセス」、「拡張サブプロセス」など) に分割することをお勧めします。
2. **Playbook は一度作成されると変更されませんか? ** 不可能。重大な事故の調査後および四半期ごとの訓練後に改訂する必要があります。
3. **プレイブックは大規模なチームにのみ適していますか? **小規模なチームも必要です。一人で作業する場合、プレイブックは忘れないための保険となります。

シナリオケース: 1 回限りの支払いタイムアウト回復プロセスのプレイブック化

レビューの結論が得られたとします。支払注文インターフェイスは、Redis ホット キーが原因でキャッシュ雪崩を引き起こし、回復アクションはホット キーを手動でクリアしてフローを制限することです。

抽出されたプレイブックのフラグメント:

告警条件：支付下单接口 P99 延迟 > 3s
步骤：
1. 登录 Redis-cli，执行 `MEMORY USAGE 支払い:hot_order` 确认热 key 内存占用
2. 如果占用 > 100 MB，执行 `DEL 支払い:hot_order` 清除缓存（注意：会短暂增加 DB 压力）
3. 同步在网关层对 /payment/order 接口限流 50%（跳转 Nginx 限流配置页）
4. 观察 2 分钟，如果 P99 恢复 < 1s，结束；否则转步骤 5（回滚版本）
责任人：On-Call SRE

このプレイブックは、「最初に開発に連絡して確認する」というステップを回避し、担当者が実行できるようにします。