Upgrade to Pro — share decks privately, control downloads, hide ads and more …

インシデントマネジメント~実践あるのみ!インシデント対応訓練~

 インシデントマネジメント~実践あるのみ!インシデント対応訓練~

## 技術

SRE, インシデント, ポストモーテム, DevOps

Tech Leverages

November 22, 2023
Tweet

More Decks by Tech Leverages

Other Decks in Technology

Transcript

  1. | © Leverages inc. 2 • 所属: ◦ テクノロジー戦略室SREチーム • 経歴:

    ◦ 2017年4月 ITベンチャー 新卒入社 ◦ 2021年4月 レバレジーズ株式会社 中途入社 • 出身: ◦ 神奈川県横浜市 • 趣味: ◦ フットサル、ずっと真夜中でいいのに • トピック ◦ 観葉植物置き始めたけど枯れそう、、 • 好きなAWSサービス: ◦ ECS、CloudFront、Lambda 自己紹介 Introduction
  2. | © Leverages inc. 3 • インシデント対応の難しさ ◦ なんで難しいの? • インシデントマネジメントの紹介

    ◦ タイムライン ◦ インシデントコマンドシステム ◦ インシデントマネジメントのベストプラ クティス ◦ 避けられるアンチパターン • インシデント対応訓練 ◦ 訓練の目的 ◦ SREチームでの事例 • まとめ アジェンダ INDEX
  3. • 対応スレッド作る • 第1報でインシデントを周知 • 関係者と担当開発チームに共有 • 状況を整理して初動を決める ◦ 影響範囲

    ◦ 原因・復旧の目処がつきそうか • 役割の割り振り • 優先順位の決定 • 復旧作業と並行して原因調査 • 状況を定期的に更新して関係者に共有 • 色々なところからくる問い合わせへの対応と説明 ◦ 他のシステムに影響が出ていれば共有して他チームへの協力依頼 を出す • 復旧したら関係者に周知 • 影響範囲と原因がわかっていない場合は引き続き調査 • ポストモーテム
  4. • 部内関係者、Pマーク担当に共有 • 攻撃であれば攻撃の停止策を検討して実施 • 流出した個人情報の精査 • ユーザーへの対応検討 • 謝罪、事象の報告

    • Pマーク担当にユーザー対応の進捗共有 • 「緊急事態対応報告書」「是正予防措置報告書」を記入し、 Pマーク運営へ 提出 • より厳しい再発防止策の検討 個人情報絡みのインシデントであればさらに、、 (弊社はPマークに属しているので以下の対応が必要)
  5. 人間への負荷 • 複雑なシステム構成による認知不可 • 状況・方法の不確実性が高い状況下で作業す るプレッシャー • 作業の疲労や緊張からくる身体・精神へのスト レス ◦

    復旧作業のミスによる2次被害へのプ レッシャー • 多様な職種間コミュニケーションをまとめる難し さ 「機械と人間の重要な違いの一つは、機械は過負荷になると突然停止するのに対して、人間は ゆっくりと機能を落とすことである。この傾向は、人間が刻々と増大する情報処理要求に直面し た際に顕著となる」by 保守事故 ジェーム・リーズン
  6. 1. まずはインシデントコマンダーを決める a. 指揮命令系統の確立 2. 被害状況の把握(サイズアップ) a. まずは目の前で起こっている被害の状況を把握する i. 事実に基づいた情報を伝える

    b. その被害がどこまで広がっていきそうかを推測する i. これによって取るべき対応(必要な人員、コスト)が決まる 3. 被害を最小限に留める努力をする a. 何はともあれ人命優先(ITにおいてはメンバーの健康) 4. メンバーのチェックインとチェックアウトを管理する a. 人員にどのような人がどこで何をしているのかを把握する
  7. インシデントマネジメントのベストプラクティス • 優先順位 ◦ まず出血を止め、次にサービスを回復し、それから根本原因の証拠を保存しましょう • 準備 ◦ インシデント管理の手順のドキュメント化 •

    信頼 ◦ インシデントに関わる全員に、割り当てられた役割内で完全な自律性を持ってもらう • 自己観察 ◦ レスポンスに対応している間の自分の感情の状態に注意を払う。パニックや圧倒されている感 覚が生じてきたら支援を求める • 代案の検討 ◦ 選択肢を定期的に考慮し、インシデントレスポンスとして今やっていることをそのまま続けること が妥当なのか、あるいは他の筋道をとるべきなのか • 訓練 ◦ インシデントレスポンスのプロセスを定期的に利用し、身につける • 持ち回り ◦ インシデントコマンダーを持ち回りにしよう
  8. インシデントマネジメントのベストプラクティス • 優先順位 ◦ まず出血を止め、次にサービスを回復し、それから根本原因の証拠を保存しましょう • 準備 ◦ インシデント管理の手順のドキュメント化 •

    信頼 ◦ インシデントに関わる全員に、割り当てられた役割内で完全な自律性を持ってもらう • 自己観察 ◦ レスポンスに対応している間の自分の感情の状態に注意を払う。パニックや圧倒されている感 覚が生じてきたら支援を求める • 代案の検討 ◦ 選択肢を定期的に考慮し、インシデントレスポンスとして今やっていることをそのまま続けること が妥当なのか、あるいは他の筋道をとるべきなのか • 訓練 ◦ インシデントレスポンスのプロセスを定期的に利用し、身につける • 持ち回り ◦ インシデントコマンダーを持ち回りにしよう
  9. インシデント対応訓練の目的 インシデントレスポンスのプロセスを定期的に利用し、身につける 逆に訓練をしない場合のリスク (1)システムに対して歴が浅いメンバーが Opsリードとなってぶっつけ本番でやるのは危険 Opsリードの人がシステムの構成などをキャッチアップできていないままインシデント対応を行うと 作業した結果、状態が悪化したりステークホルダーとの調整がうまくいかなかったりする場合がある (2)一部のメンバーがインシデント対応を巻き取ってしまう システムへの理解が深かったりスキルがあるメンバーはインシデントへの反応が早いし対応も的確で 1人でやれてし

    まうケースが多い。 そのためそういった一部のメンバーに対応が集中してしまい、他のメンバーがインシデント対応を経験する機会が失 われてしまって結果単一障害点につながってしまう。 (3)コミュニケーションリードやインシデントコマンダーの人が必要な情報連携をいきなりやるのが難しい いろんなチーム間、職種間のコミュニケーションが必要になる中で連携すべき情報をまとめて説明する難易度の高さ がある
  10. インシデント対応訓練の流れ • 事前準備 ◦ ゲームマスター(GM)が訓練用のAWS環境を作成してインシデント内容を決める(対応時間目安は 30分く らい) ◦ 参加メンバーで3人チームを作って以下の役割をふる ▪

    インシデントコマンダー ▪ コミュニケーションリード ▪ Opsリード ▪ 参加メンバー外で事業部メンバー役を用意( GMが兼任してOK) ◦ GMが訓練用環境へのアクセス権を全員に付与 • 訓練 ◦ GMが訓練用環境のシステム構成を説明 ◦ GMが発生させるインシデント内容を簡単に共有(サイトが落ちる、一部の機能が停止する、など) ◦ インシデントを発生させる ◦ 参加メンバーが各々の役割で動いてインシデント対応を行う ◦ 事業部メンバーがインシデント解消を宣言できるまで or制限時間まで対応 • フィードバック ◦ インシデント解消を宣言できたかを改めて確認 ◦ 各チームごとにうまくいったこと、幸運だったこと、改善できることを出し合う
  11. 実際の訓練 • サービス、使用しているミドルウェアなどの概要 ◦ エンドポイントをHTTPで叩くとトップページが 表示される • 障害の概要 ◦ SREチームがインフラ設定の変更のために

    TerraformとAnsibleをリリースしたところトップ ページが表示されなくなってしまった。 • 望まれる復旧時間 ◦ 20分 訓練後の振り返り • コミュニケーションでスムーズに行かなかったところ に気づけた • 影響範囲の確認や復旧作業の方針チェックを Ops リード以外の人たちがフォローする動きが大事 最初はシンプルな構成
  12. ポイント • 事前準備 ◦ システム構成 ▪ 訓練を行う環境をどこに置くか ◦ シナリオ ▪

    ポストモーテムの事例を使おう • 訓練 ◦ 負荷の与え方 ▪ 時間制限 ▪ 事業部役の人がコミュニケーションを複雑にし てみる
  13. まとめ • インシデント対応の難しさ ◦ インシデントは起こるもの ◦ インシデント対応を難しくしている要因 ▪ 人間にかかる様々なプレッシャー •

    インシデントマネジメントの紹介 ◦ タイムライン ◦ インシデントコマンドシステム ◦ 避けられるアンチパターン • インシデント対応訓練の目的とポイント ◦ インシデントレスポンスのプロセスを定期的に利用し、身につける ◦ ぶっつけ本番を避け、なるべく多くのメンバーにインシデントを疑似体験してもらう ◦ ポストモーテムを有効活用して訓練の中では意識的に負荷をかけよう