障害対応のキホン

社内勉強会の資料です。

Transcript

1. 障害対応のキホン 2022/12/06 Moriyama Hiroaki
2. アジェンダ • 障害対応 is 何？ • 障害対応の原則 is 何？ • 障害対応フロー • 障害対応の心得 • 障害対応後も大切だよ
3. 障害対応 is 何？
4. 障害対応 is 何？ 本番環境におけるバグ・デグレなど 予期せぬ状態（障害）に対する 緊急性の高い対応業務のことを指す
5. 障害対応 is 何？ 本番環境におけるバグ・デグレなど 予期せぬ状態（障害）に対する 緊急性の高い対応業務のことを指す
6. 緊急性の高い対応業務 文字通り緊急度がMaxな業務 ↓ すべての業務に優先される業務
7. 障害対応の原則 is 何？
8. 障害対応の原則 is 何？ • 認知 • 判断 • 行動
9. 障害対応の原則 is 何？ • 認知：状況を正しく知る • 判断：対応方法を正しく決定する • 行動：決めた対応方法を速やかに実行する
10. 認知 【Must】 • 何が起こっているのか？ • 誰にどのくらい影響が出ているのか？ 【Want】 • どこに原因があるのか？
11. 判断 【Must】 • 今すべきことは何か？を判断する • 誰がどんな対応をするか？を決める 【Want】 • いつまでに何をするか？を決める
12. 行動 【Must】 • 作業状況を時系列に沿ってログを取る • 予定との乖離は最速で共有する 【Want】 • 最速で動けるように臨機応変さを持つ
13. この原則さえ理解すれば 大きなミスは犯さない
14. 障害対応フロー
15. バグでもデグレでもない 障害対応フロー おかしいな？と思う ことに気付く まず声を上げて 周囲に知らせる 集まったメンバーで状 況の把握 障害の可能性 があるのか？ 何もなくてよかった ね！で業務復帰 障害の可能性が0% 担当割り振り 障害の可能性が0.1%以上 障害の可能性ありと 事業部周知 事象の詳細調査と 原因調査（バグ観点） 事象の詳細調査と 原因調査（デグレ観点） 暫定対応方法検討 恒久対応方法検討 バグやデグレか？ 障害と断定 随時経過報告 調査の結果 問題ないと報告 発生原因の根本を 潰す対応 バグやデグレ 早急に事象を 解消するための対応 状況によってチーム編成を検討 状況によって、対応内容の判断を行う ここまでは、10分以内くらいを目指したい... バグやデグレ
16. 障害対応の心得
17. 障害対応の心得〜全般〜 • 役割などの担当とレポートラインを明確化する • 他部署への状況共有も怠らない • 障害復旧に関するチーム（≒暫定対応チーム）に その領域のエキスパート（≒実装経験者）を集める • スピード優先でリアルタイムの会話を重視 ◦ Slackで連絡＜＜＜Web会議や対面での会話 ◦ ただし、会話内容はSlackなど見える場所にログを残す • 社外との打ち合わせ以外はすべてリスケして対応最優先
18. • 作業に入らず全体を俯瞰する人を必ず1人確保する。 ◦ マネージャーやリーダーが担当することが多い ◦ この人は、各チームを動き回り情報をキャッチ ◦ 必要に応じて、別チームに共有に動く • 時間軸も気にする ◦ 対応に入る際、◯時に再集合など、ブレイクポイントを設定 し、状況共有などをはさみ認知のギャップ解消や、重複調 査や重複対応といったムダを防ぐ 障害対応の心得〜全般〜
19. • 障害かも？と思ったらすぐ周知に動くことが大事 ◦ 「障害かも？」→「障害じゃない」：大きな問題なし ◦ 「障害じゃないでしょ！」→「障害でした」：大問題 • 初動時 ◦ 何が起こっているかの事実の共有を最優先 ◦ その後、影響範囲の認識合わせ ◦ 最後に対応方針やチーム体制を決定 • 声を上げる、声を出すを意識 障害対応の心得〜検知から対応開始まで〜
20. • 最優先すべきは、障害状態の回復 ◦ 最短の時間で回復する方法を考える ◦ デグレが原因なら原則は切り戻し一択 ◦ バグの根本対応より、影響を極小化する方法が優先 ◦ 急ぐあまりの二次災害に注意 • 思考の変遷、検討の結果、など情報はこまめにログに残す。 ◦ スプシなどでまとめてもいいけど、Slackにも必ず残す 障害対応の心得〜対応〜
21. 障害対応後も大切だよ
22. • ポストモーテム ◦ 事実の洗い出し ▪ 発生事象と影響範囲 ▪ 直接/間接原因 ▪ 今回の暫定/根本（恒久）対応の内容 ▪ 対応のチーム編成やタイムライン 振り返り（ポストモーテム）をやろう！
23. • ポストモーテム ◦ 対応のGood/Badを議論 ▪ 全体を俯瞰する ▪ 対応で良かった事を議論 ▪ 対応で改善できることを議論 振り返り（ポストモーテム）をやろう！
24. 振り返り（ポストモーテム）をやろう！ • ポストモーテム ◦ 2軸での再発防止策の検討 ▪ 類似障害を起こさない対応策 • 「心がける」等ではなく仕組みで対応する ▪ 類似障害が起こっても問題ないようにする対応策 • 発生しても自動対応できる仕組み • 発生してもすぐに検知し対応に入れる仕組み
25. • ポストモーテム系の参考記事 ◦ ポストモーテムを理解する - Qiita ◦ freeeが再び全社訓練 ◦ SREチームでポストモーテムを1年半運用してみた 振り返り（ポストモーテム）をやろう！
26. 安心・安全・確実な障害対応で より良い開発者体験を
27. おわり