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

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

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

## 技術

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

More Decks by レバレジーズTechアカウント

Other Decks in Technology

Transcript

  1. インシデントマネジメント
    〜実践あるのみ!インシデント対応
    訓練〜
    テクノロジー戦略室SREチーム
    蒲生廣人

    View full-size slide

  2. | © Leverages inc.
    2
    ● 所属:
    ○ テクノロジー戦略室SREチーム
    ● 経歴:
    ○ 2017年4月 ITベンチャー 新卒入社
    ○ 2021年4月 レバレジーズ株式会社 中途入社
    ● 出身:
    ○ 神奈川県横浜市
    ● 趣味:
    ○ フットサル、ずっと真夜中でいいのに
    ● トピック
    ○ 観葉植物置き始めたけど枯れそう、、
    ● 好きなAWSサービス:
    ○ ECS、CloudFront、Lambda
    自己紹介
    Introduction

    View full-size slide

  3. | © Leverages inc.
    3
    ● インシデント対応の難しさ
    ○ なんで難しいの?
    ● インシデントマネジメントの紹介
    ○ タイムライン
    ○ インシデントコマンドシステム
    ○ インシデントマネジメントのベストプラ
    クティス
    ○ 避けられるアンチパターン
    ● インシデント対応訓練
    ○ 訓練の目的
    ○ SREチームでの事例
    ● まとめ
    アジェンダ
    INDEX

    View full-size slide

  4. | © Leverages inc.
    4
    ● インシデント対応を難しくしている要因につ
    いてざっくり理解してる
    ● インシデントマネジメントの重要性をざっくり
    理解してる
    ● インシデント対応訓練やりたいなあって気
    持ちが芽生えてる
    今日のゴール
    目的・目標

    View full-size slide

  5. インシデント対応の難しさ

    View full-size slide

  6. そもそもインシデントってなに
    どこからどこまでがインシデントなのさ
    障害とインシデントって何が違うのさ

    View full-size slide

  7. インシデントの定義

    View full-size slide

  8. 場合による

    View full-size slide

  9. 「何かが起こったときのこと」 by Google
    「事業運営に重大な影響を与える可能性のある、サービ
    ス品質の計画外の中断または低下のこと」 by Amazon
    「「何らかの対応が必要な課題」 by Netflix

    View full-size slide

  10. レバテックでポストモーテムを書く基準
    以下の条件の内、 2つ以上当てはまる場合
    ・複数人のユーザーに影響があった
    ・障害発生期間が5分を超える
    ・過去似たような事象が発生しているまたは
    将来起こる可能性が高い

    View full-size slide

  11. 障害とインシデントの違い

    View full-size slide

  12. インシデント=「ITサービスを利用できない状態」
    障害=インシデントを引き起こす要因の一つ
    by PagerDuty

    View full-size slide

  13. アプリケーションの問題
    設計・仕様の不備
    実装のバグ
    連携の問題
    外部SaaSの障害
    依存するシステムの障害
    社会状況の変化
    法律・規制の更新
    倫理・遵守意識の変化
    人間の問題
    ヒューマンエラー
    システムの属人化

    View full-size slide

  14. 全部防げる?

    View full-size slide

  15. インシデントは起こるもの

    View full-size slide

  16. 誰もが自分のサービスが常にスムーズに動くことを臨
    んでいますが、わたしたちは不完全な世界に生きてい
    るので、障害が発生することもあります

    View full-size slide

  17. でもインシデント対応って難しいよね

    View full-size slide

  18. ● 対応スレッド作る
    ● 第1報でインシデントを周知
    ● 関係者と担当開発チームに共有
    ● 状況を整理して初動を決める
    ○ 影響範囲
    ○ 原因・復旧の目処がつきそうか
    ● 役割の割り振り
    ● 優先順位の決定
    ● 復旧作業と並行して原因調査
    ● 状況を定期的に更新して関係者に共有
    ● 色々なところからくる問い合わせへの対応と説明
    ○ 他のシステムに影響が出ていれば共有して他チームへの協力依頼
    を出す
    ● 復旧したら関係者に周知
    ● 影響範囲と原因がわかっていない場合は引き続き調査
    ● ポストモーテム

    View full-size slide

  19. ● 部内関係者、Pマーク担当に共有
    ● 攻撃であれば攻撃の停止策を検討して実施
    ● 流出した個人情報の精査
    ● ユーザーへの対応検討
    ● 謝罪、事象の報告
    ● Pマーク担当にユーザー対応の進捗共有
    ● 「緊急事態対応報告書」「是正予防措置報告書」を記入し、 Pマーク運営へ
    提出
    ● より厳しい再発防止策の検討
    個人情報絡みのインシデントであればさらに、、
    (弊社はPマークに属しているので以下の対応が必要)

    View full-size slide

  20. 人間への負荷
    ● 複雑なシステム構成による認知不可
    ● 状況・方法の不確実性が高い状況下で作業す
    るプレッシャー
    ● 作業の疲労や緊張からくる身体・精神へのスト
    レス
    ○ 復旧作業のミスによる2次被害へのプ
    レッシャー
    ● 多様な職種間コミュニケーションをまとめる難し

    「機械と人間の重要な違いの一つは、機械は過負荷になると突然停止するのに対して、人間は
    ゆっくりと機能を落とすことである。この傾向は、人間が刻々と増大する情報処理要求に直面し
    た際に顕著となる」by 保守事故 ジェーム・リーズン

    View full-size slide

  21. インシデントは起こるもの
    インシデント対応は難しい><

    View full-size slide

  22. 詰んでね?

    View full-size slide

  23. インシデントマネジメントの紹介

    View full-size slide

  24. システムを運用する組織においてインシデ
    ント対応に立ち向かう人間を支援する仕組
    みや方法論

    View full-size slide

  25. インシデントにエンジニアリングで立ち向かう
    ● インシデントレスポンスのシフトレフト
    ○ インシデント発生時のマニュアル・フロー整備
    ○ インシデント対応レベルのアセスメント実施
    ○ インシデント対応訓練の定期実施
    ○ 脅威モデリング
    ○ ドキュメント整備(システム構成図、データモデル)
    ● インシデントマネジメントの支援の自動化

    View full-size slide

  26. 管理するのは障害じゃなくてインシデント?

    View full-size slide

  27. インシデント=「ITサービスを利用できない状態」
    障害=インシデントを引き起こす要因の一つ
    by PagerDuty

    View full-size slide

  28. 目的の違い
    障害管理=障害の根本的な原因を探り、今後同じことが起きな
    いよう対処することが目的
    インシデントマネジメント=目の前で起きている問題の解決が目

    View full-size slide

  29. 各所への影響を最小限にとどめ、
    早期にサービスを復旧させるプロセス
    システムをもとに戻すことが目的ではない

    View full-size slide

  30. 他業種からの学び

    View full-size slide

  31. タイムラインの定義の目的と効果
    ● インシデントのプロセスの構造化
    ○ 人間のメンタルモデルをある程度統一する
    ● 組織内での用語・概念の統一
    ○ コストや改善の話がしやすくなる
    ● 自動化の設計/実装のモデルになる
    ○ 始めからすべて自動化を考えるのではなく一部の対応から始められる

    View full-size slide

  32. タイムライン

    View full-size slide

  33. インシデントコマンドシステム
    =緊急時における標準化された組織マネジメントの手法

    View full-size slide

  34. 1. まずはインシデントコマンダーを決める
    a. 指揮命令系統の確立
    2. 被害状況の把握(サイズアップ)
    a. まずは目の前で起こっている被害の状況を把握する
    i. 事実に基づいた情報を伝える
    b. その被害がどこまで広がっていきそうかを推測する
    i. これによって取るべき対応(必要な人員、コスト)が決まる
    3. 被害を最小限に留める努力をする
    a. 何はともあれ人命優先(ITにおいてはメンバーの健康)
    4. メンバーのチェックインとチェックアウトを管理する
    a. 人員にどのような人がどこで何をしているのかを把握する

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  37. 避けられるアンチパターン
    ● 群衆によるインシデント対応
    ● マジックスモークを消すのは私だ!
    ● リカバリ時間ではなく障害回避の最適化

    View full-size slide

  38. ● 群衆によるインシデント対応
    ○ 「ボールから目を離さないが、ゾーンから足を踏み出さない」
    ○ わらわらと集まってきては問題に首を突っ込み始めること。あるいは誰もが各自の作業に没頭するだ
    けではいられなくなり、問題が解決されるまで脳裏にこびりついて注意を払わざるを得ない状態
    ■ インシデントコマンドシステムや訓練によって回避しよう
    ■ システムを構築して必要な人が問題の管理にフルコミットして、他の人については必要が生じる
    までエネルギーを温存できるようにすることが重要

    View full-size slide

  39. ● マジックスモークを消すのは私だ!
    ○ エリート戦士/ヒーローの文化は落とし穴です
    ○ 周到な設計や予防の計画よりもインシデント対応の英雄的な行動を高く評価すること
    ■ 優れたエンジニアリングよりも運用での忍耐に報いるのは誤ったインセンティブを与え、運用現
    場の混乱とエンジニアの燃え尽きに直結する
    ■ 組織のレジリエンスを顧みずインシデントを一身に引き受ける誰かを称賛するのはだめよ

    View full-size slide

  40. ● リカバリ時間ではなく障害回避の最適化
    ○ 障害をなくすことに工数を使い、インシデントが発生した際の対処が改善されない
    ■ インシデントは避けられない
    ■ その回避にすべてを賭けるのではなく、うまく処理できるようになること

    View full-size slide

  41. インシデント対応訓練

    View full-size slide

  42. 他業種からの学び

    View full-size slide

  43. インシデント対応訓練の目的
    インシデントレスポンスのプロセスを定期的に利用し、身につける
    逆に訓練をしない場合のリスク
    (1)システムに対して歴が浅いメンバーが Opsリードとなってぶっつけ本番でやるのは危険
    Opsリードの人がシステムの構成などをキャッチアップできていないままインシデント対応を行うと
    作業した結果、状態が悪化したりステークホルダーとの調整がうまくいかなかったりする場合がある
    (2)一部のメンバーがインシデント対応を巻き取ってしまう
    システムへの理解が深かったりスキルがあるメンバーはインシデントへの反応が早いし対応も的確で 1人でやれてし
    まうケースが多い。
    そのためそういった一部のメンバーに対応が集中してしまい、他のメンバーがインシデント対応を経験する機会が失
    われてしまって結果単一障害点につながってしまう。
    (3)コミュニケーションリードやインシデントコマンダーの人が必要な情報連携をいきなりやるのが難しい
    いろんなチーム間、職種間のコミュニケーションが必要になる中で連携すべき情報をまとめて説明する難易度の高さ
    がある

    View full-size slide

  44. インシデント対応訓練の流れ
    ● 事前準備
    ○ ゲームマスター(GM)が訓練用のAWS環境を作成してインシデント内容を決める(対応時間目安は 30分く
    らい)
    ○ 参加メンバーで3人チームを作って以下の役割をふる
    ■ インシデントコマンダー
    ■ コミュニケーションリード
    ■ Opsリード
    ■ 参加メンバー外で事業部メンバー役を用意( GMが兼任してOK)
    ○ GMが訓練用環境へのアクセス権を全員に付与
    ● 訓練
    ○ GMが訓練用環境のシステム構成を説明
    ○ GMが発生させるインシデント内容を簡単に共有(サイトが落ちる、一部の機能が停止する、など)
    ○ インシデントを発生させる
    ○ 参加メンバーが各々の役割で動いてインシデント対応を行う
    ○ 事業部メンバーがインシデント解消を宣言できるまで or制限時間まで対応
    ● フィードバック
    ○ インシデント解消を宣言できたかを改めて確認
    ○ 各チームごとにうまくいったこと、幸運だったこと、改善できることを出し合う

    View full-size slide

  45. 実際の訓練
    ● サービス、使用しているミドルウェアなどの概要
    ○ エンドポイントをHTTPで叩くとトップページが
    表示される
    ● 障害の概要
    ○ SREチームがインフラ設定の変更のために
    TerraformとAnsibleをリリースしたところトップ
    ページが表示されなくなってしまった。
    ● 望まれる復旧時間
    ○ 20分
    訓練後の振り返り
    ● コミュニケーションでスムーズに行かなかったところ
    に気づけた
    ● 影響範囲の確認や復旧作業の方針チェックを Ops
    リード以外の人たちがフォローする動きが大事
    最初はシンプルな構成

    View full-size slide

  46. ポイント
    ● 事前準備
    ○ システム構成
    ■ 訓練を行う環境をどこに置くか
    ○ シナリオ
    ■ ポストモーテムの事例を使おう
    ● 訓練
    ○ 負荷の与え方
    ■ 時間制限
    ■ 事業部役の人がコミュニケーションを複雑にし
    てみる

    View full-size slide

  47. まとめ
    ● インシデント対応の難しさ
    ○ インシデントは起こるもの
    ○ インシデント対応を難しくしている要因
    ■ 人間にかかる様々なプレッシャー
    ● インシデントマネジメントの紹介
    ○ タイムライン
    ○ インシデントコマンドシステム
    ○ 避けられるアンチパターン
    ● インシデント対応訓練の目的とポイント
    ○ インシデントレスポンスのプロセスを定期的に利用し、身につける
    ○ ぶっつけ本番を避け、なるべく多くのメンバーにインシデントを疑似体験してもらう
    ○ ポストモーテムを有効活用して訓練の中では意識的に負荷をかけよう

    View full-size slide