Slide 1

Slide 1 text

障害対応のキホン 2022/12/06 Moriyama Hiroaki

Slide 2

Slide 2 text

アジェンダ ● 障害対応 is 何? ● 障害対応の原則 is 何? ● 障害対応フロー ● 障害対応の心得 ● 障害対応後も大切だよ

Slide 3

Slide 3 text

障害対応 is 何?

Slide 4

Slide 4 text

障害対応 is 何? 本番環境におけるバグ・デグレなど 予期せぬ状態(障害)に対する 緊急性の高い対応業務のことを指す

Slide 5

Slide 5 text

障害対応 is 何? 本番環境におけるバグ・デグレなど 予期せぬ状態(障害)に対する 緊急性の高い対応業務のことを指す

Slide 6

Slide 6 text

緊急性の高い対応業務 文字通り緊急度がMaxな業務 ↓ すべての業務に優先される業務

Slide 7

Slide 7 text

障害対応の原則 is 何?

Slide 8

Slide 8 text

障害対応の原則 is 何? ● 認知 ● 判断 ● 行動

Slide 9

Slide 9 text

障害対応の原則 is 何? ● 認知:状況を正しく知る ● 判断:対応方法を正しく決定する ● 行動:決めた対応方法を速やかに実行する

Slide 10

Slide 10 text

認知 【Must】 ● 何が起こっているのか? ● 誰にどのくらい影響が出ているのか? 【Want】 ● どこに原因があるのか?

Slide 11

Slide 11 text

判断 【Must】 ● 今すべきことは何か?を判断する ● 誰がどんな対応をするか?を決める 【Want】 ● いつまでに何をするか?を決める

Slide 12

Slide 12 text

行動 【Must】 ● 作業状況を時系列に沿ってログを取る ● 予定との乖離は最速で共有する 【Want】 ● 最速で動けるように臨機応変さを持つ

Slide 13

Slide 13 text

この原則さえ理解すれば 大きなミスは犯さない

Slide 14

Slide 14 text

障害対応フロー

Slide 15

Slide 15 text

バグでもデグレでもない 障害対応フロー おかしいな?と思う ことに気付く まず声を上げて 周囲に知らせる 集まったメンバーで状 況の把握 障害の可能性 があるのか? 何もなくてよかった ね!で業務復帰 障害の可能性が0% 担当割り振り 障害の可能性が0.1%以上 障害の可能性ありと 事業部周知 事象の詳細調査と 原因調査(バグ観点) 事象の詳細調査と 原因調査(デグレ観点) 暫定対応方法検討 恒久対応方法検討 バグやデグレか? 障害と断定 随時経過報告 調査の結果 問題ないと報告 発生原因の根本を 潰す対応 バグやデグレ 早急に事象を 解消するための対応 状況によってチーム編成を検討 状況によって、対応内容の判断を行う ここまでは、10分以内くらいを目指したい... バグやデグレ

Slide 16

Slide 16 text

障害対応の心得

Slide 17

Slide 17 text

障害対応の心得〜全般〜 ● 役割などの担当とレポートラインを明確化する ● 他部署への状況共有も怠らない ● 障害復旧に関するチーム(≒暫定対応チーム)に その領域のエキスパート(≒実装経験者)を集める ● スピード優先でリアルタイムの会話を重視 ○ Slackで連絡<<<Web会議や対面での会話 ○ ただし、会話内容はSlackなど見える場所にログを残す ● 社外との打ち合わせ以外はすべてリスケして対応最優先

Slide 18

Slide 18 text

● 作業に入らず全体を俯瞰する人を必ず1人確保する。 ○ マネージャーやリーダーが担当することが多い ○ この人は、各チームを動き回り情報をキャッチ ○ 必要に応じて、別チームに共有に動く ● 時間軸も気にする ○ 対応に入る際、◯時に再集合など、ブレイクポイントを設定 し、状況共有などをはさみ認知のギャップ解消や、重複調 査や重複対応といったムダを防ぐ 障害対応の心得〜全般〜

Slide 19

Slide 19 text

● 障害かも?と思ったらすぐ周知に動くことが大事 ○ 「障害かも?」→「障害じゃない」:大きな問題なし ○ 「障害じゃないでしょ!」→「障害でした」:大問題 ● 初動時 ○ 何が起こっているかの事実の共有を最優先 ○ その後、影響範囲の認識合わせ ○ 最後に対応方針やチーム体制を決定 ● 声を上げる、声を出すを意識 障害対応の心得〜検知から対応開始まで〜

Slide 20

Slide 20 text

● 最優先すべきは、障害状態の回復 ○ 最短の時間で回復する方法を考える ○ デグレが原因なら原則は切り戻し一択 ○ バグの根本対応より、影響を極小化する方法が優先 ○ 急ぐあまりの二次災害に注意 ● 思考の変遷、検討の結果、など情報はこまめにログに残す。 ○ スプシなどでまとめてもいいけど、Slackにも必ず残す 障害対応の心得〜対応〜

Slide 21

Slide 21 text

障害対応後も大切だよ

Slide 22

Slide 22 text

● ポストモーテム ○ 事実の洗い出し ■ 発生事象と影響範囲 ■ 直接/間接原因 ■ 今回の暫定/根本(恒久)対応の内容 ■ 対応のチーム編成やタイムライン 振り返り(ポストモーテム)をやろう!

Slide 23

Slide 23 text

● ポストモーテム ○ 対応のGood/Badを議論 ■ 全体を俯瞰する ■ 対応で良かった事を議論 ■ 対応で改善できることを議論 振り返り(ポストモーテム)をやろう!

Slide 24

Slide 24 text

振り返り(ポストモーテム)をやろう! ● ポストモーテム ○ 2軸での再発防止策の検討 ■ 類似障害を起こさない対応策 ● 「心がける」等ではなく仕組みで対応する ■ 類似障害が起こっても問題ないようにする対応策 ● 発生しても自動対応できる仕組み ● 発生してもすぐに検知し対応に入れる仕組み

Slide 25

Slide 25 text

● ポストモーテム系の参考記事 ○ ポストモーテムを理解する - Qiita ○ freeeが再び全社訓練 ○ SREチームでポストモーテムを1年半運用してみた 振り返り(ポストモーテム)をやろう!

Slide 26

Slide 26 text

安心・安全・確実な障害対応で より良い開発者体験を

Slide 27

Slide 27 text

おわり