Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
インシデントマネジメント~実践あるのみ!インシデント対応訓練~
Search
レバレジーズTechアカウント
November 22, 2023
Technology
0
84
インシデントマネジメント~実践あるのみ!インシデント対応訓練~
## 技術
SRE, インシデント, ポストモーテム, DevOps
レバレジーズTechアカウント
November 22, 2023
Tweet
Share
More Decks by レバレジーズTechアカウント
See All by レバレジーズTechアカウント
デザインシステム基盤構築実践
leveragestech
1
1.8k
荒廃したテックブログの再生_技術広報LT大会
leveragestech
4
5.4k
文系大学生と学び考える開発生産性
leveragestech
1
27
「マイクロサービスアーキテクチャ」と「アーキテクチャ特性」で読み解くレバテックのこれまでとこれから
leveragestech
0
48
社内共通ルールを値オブジェクトにして社内ライブラリとして運用してみた話
leveragestech
5
2.8k
Effect-TSを利用した副作用を分離する設計について
leveragestech
0
690
マネジメント未経験の脳筋が開発チームのリーダーになって感じた苦悩と学び
leveragestech
0
79
モノリス改善史~運用改善とバージョンアップの軌跡~
leveragestech
0
28
CREって何? CREが生まれた背景と、自社の事例
leveragestech
0
53
Other Decks in Technology
See All in Technology
いいたいことちゃんという
tkengo
0
210
How to do well in consulting–Balkan Ruby 2024
irinanazarova
0
120
One engineer company with Ruby on Rails
rstankov
2
410
AWSに詳しくない人でも始められるコスト最適化ガイド
yuhta28
2
280
成長をサポートするピープルマネジメントのやり方
sioncojp
2
150
どうするコスト最適化のトレードオフ
tetsuyaooooo
1
690
Gitlab本から学んだこと - そーだいなるプレイバック / gitlab-book
soudai
7
1.3k
Cloud Service Mesh に触れ合う
phaya72
1
120
JSON攻略法.pdf
miyakemito
8
5.2k
非同期推論システムによるコスト削減と信頼性向上
koki_nishihara
1
350
MixIT 2024 - Pulumi : Gérer son infra avec son langage de programmation préféré
ju_hnny5
1
120
推しは推せるときに推せ! プロダクトにフィードバックしていこう
nakasho
0
450
Featured
See All Featured
Designing on Purpose - Digital PM Summit 2013
jponch
111
6.5k
VelocityConf: Rendering Performance Case Studies
addyosmani
321
23k
How GitHub (no longer) Works
holman
305
140k
Learning to Love Humans: Emotional Interface Design
aarron
267
39k
The Invisible Customer
myddelton
114
12k
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
323
20k
Templates, Plugins, & Blocks: Oh My! Creating the theme that thinks of everything
marktimemedia
20
1.7k
Rails Girls Zürich Keynote
gr2m
91
13k
Build The Right Thing And Hit Your Dates
maggiecrowley
25
2k
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
188
16k
Designing with Data
zakiwarfel
96
4.8k
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
6
1.3k
Transcript
インシデントマネジメント 〜実践あるのみ!インシデント対応 訓練〜 テクノロジー戦略室SREチーム 蒲生廣人
| © Leverages inc. 2 • 所属: ◦ テクノロジー戦略室SREチーム • 経歴:
◦ 2017年4月 ITベンチャー 新卒入社 ◦ 2021年4月 レバレジーズ株式会社 中途入社 • 出身: ◦ 神奈川県横浜市 • 趣味: ◦ フットサル、ずっと真夜中でいいのに • トピック ◦ 観葉植物置き始めたけど枯れそう、、 • 好きなAWSサービス: ◦ ECS、CloudFront、Lambda 自己紹介 Introduction
| © Leverages inc. 3 • インシデント対応の難しさ ◦ なんで難しいの? • インシデントマネジメントの紹介
◦ タイムライン ◦ インシデントコマンドシステム ◦ インシデントマネジメントのベストプラ クティス ◦ 避けられるアンチパターン • インシデント対応訓練 ◦ 訓練の目的 ◦ SREチームでの事例 • まとめ アジェンダ INDEX
| © Leverages inc. 4 • インシデント対応を難しくしている要因につ いてざっくり理解してる • インシデントマネジメントの重要性をざっくり 理解してる
• インシデント対応訓練やりたいなあって気 持ちが芽生えてる 今日のゴール 目的・目標
インシデント対応の難しさ
そもそもインシデントってなに どこからどこまでがインシデントなのさ 障害とインシデントって何が違うのさ
インシデントの定義
場合による
「何かが起こったときのこと」 by Google 「事業運営に重大な影響を与える可能性のある、サービ ス品質の計画外の中断または低下のこと」 by Amazon 「「何らかの対応が必要な課題」 by Netflix
None
レバテックでポストモーテムを書く基準 以下の条件の内、 2つ以上当てはまる場合 ・複数人のユーザーに影響があった ・障害発生期間が5分を超える ・過去似たような事象が発生しているまたは 将来起こる可能性が高い
障害とインシデントの違い
インシデント=「ITサービスを利用できない状態」 障害=インシデントを引き起こす要因の一つ by PagerDuty
None
アプリケーションの問題 設計・仕様の不備 実装のバグ 連携の問題 外部SaaSの障害 依存するシステムの障害 社会状況の変化 法律・規制の更新 倫理・遵守意識の変化 人間の問題
ヒューマンエラー システムの属人化
全部防げる?
インシデントは起こるもの
誰もが自分のサービスが常にスムーズに動くことを臨 んでいますが、わたしたちは不完全な世界に生きてい るので、障害が発生することもあります
でもインシデント対応って難しいよね
• 対応スレッド作る • 第1報でインシデントを周知 • 関係者と担当開発チームに共有 • 状況を整理して初動を決める ◦ 影響範囲
◦ 原因・復旧の目処がつきそうか • 役割の割り振り • 優先順位の決定 • 復旧作業と並行して原因調査 • 状況を定期的に更新して関係者に共有 • 色々なところからくる問い合わせへの対応と説明 ◦ 他のシステムに影響が出ていれば共有して他チームへの協力依頼 を出す • 復旧したら関係者に周知 • 影響範囲と原因がわかっていない場合は引き続き調査 • ポストモーテム
• 部内関係者、Pマーク担当に共有 • 攻撃であれば攻撃の停止策を検討して実施 • 流出した個人情報の精査 • ユーザーへの対応検討 • 謝罪、事象の報告
• Pマーク担当にユーザー対応の進捗共有 • 「緊急事態対応報告書」「是正予防措置報告書」を記入し、 Pマーク運営へ 提出 • より厳しい再発防止策の検討 個人情報絡みのインシデントであればさらに、、 (弊社はPマークに属しているので以下の対応が必要)
None
人間への負荷 • 複雑なシステム構成による認知不可 • 状況・方法の不確実性が高い状況下で作業す るプレッシャー • 作業の疲労や緊張からくる身体・精神へのスト レス ◦
復旧作業のミスによる2次被害へのプ レッシャー • 多様な職種間コミュニケーションをまとめる難し さ 「機械と人間の重要な違いの一つは、機械は過負荷になると突然停止するのに対して、人間は ゆっくりと機能を落とすことである。この傾向は、人間が刻々と増大する情報処理要求に直面し た際に顕著となる」by 保守事故 ジェーム・リーズン
インシデントは起こるもの インシデント対応は難しい><
詰んでね?
インシデントマネジメントの紹介
システムを運用する組織においてインシデ ント対応に立ち向かう人間を支援する仕組 みや方法論
インシデントにエンジニアリングで立ち向かう • インシデントレスポンスのシフトレフト ◦ インシデント発生時のマニュアル・フロー整備 ◦ インシデント対応レベルのアセスメント実施 ◦ インシデント対応訓練の定期実施 ◦
脅威モデリング ◦ ドキュメント整備(システム構成図、データモデル) • インシデントマネジメントの支援の自動化
管理するのは障害じゃなくてインシデント?
インシデント=「ITサービスを利用できない状態」 障害=インシデントを引き起こす要因の一つ by PagerDuty
目的の違い 障害管理=障害の根本的な原因を探り、今後同じことが起きな いよう対処することが目的 インシデントマネジメント=目の前で起きている問題の解決が目 的
各所への影響を最小限にとどめ、 早期にサービスを復旧させるプロセス システムをもとに戻すことが目的ではない
他業種からの学び
タイムラインの定義の目的と効果 • インシデントのプロセスの構造化 ◦ 人間のメンタルモデルをある程度統一する • 組織内での用語・概念の統一 ◦ コストや改善の話がしやすくなる •
自動化の設計/実装のモデルになる ◦ 始めからすべて自動化を考えるのではなく一部の対応から始められる
タイムライン
インシデントコマンドシステム =緊急時における標準化された組織マネジメントの手法
1. まずはインシデントコマンダーを決める a. 指揮命令系統の確立 2. 被害状況の把握(サイズアップ) a. まずは目の前で起こっている被害の状況を把握する i. 事実に基づいた情報を伝える
b. その被害がどこまで広がっていきそうかを推測する i. これによって取るべき対応(必要な人員、コスト)が決まる 3. 被害を最小限に留める努力をする a. 何はともあれ人命優先(ITにおいてはメンバーの健康) 4. メンバーのチェックインとチェックアウトを管理する a. 人員にどのような人がどこで何をしているのかを把握する
インシデントマネジメントのベストプラクティス • 優先順位 ◦ まず出血を止め、次にサービスを回復し、それから根本原因の証拠を保存しましょう • 準備 ◦ インシデント管理の手順のドキュメント化 •
信頼 ◦ インシデントに関わる全員に、割り当てられた役割内で完全な自律性を持ってもらう • 自己観察 ◦ レスポンスに対応している間の自分の感情の状態に注意を払う。パニックや圧倒されている感 覚が生じてきたら支援を求める • 代案の検討 ◦ 選択肢を定期的に考慮し、インシデントレスポンスとして今やっていることをそのまま続けること が妥当なのか、あるいは他の筋道をとるべきなのか • 訓練 ◦ インシデントレスポンスのプロセスを定期的に利用し、身につける • 持ち回り ◦ インシデントコマンダーを持ち回りにしよう
インシデントマネジメントのベストプラクティス • 優先順位 ◦ まず出血を止め、次にサービスを回復し、それから根本原因の証拠を保存しましょう • 準備 ◦ インシデント管理の手順のドキュメント化 •
信頼 ◦ インシデントに関わる全員に、割り当てられた役割内で完全な自律性を持ってもらう • 自己観察 ◦ レスポンスに対応している間の自分の感情の状態に注意を払う。パニックや圧倒されている感 覚が生じてきたら支援を求める • 代案の検討 ◦ 選択肢を定期的に考慮し、インシデントレスポンスとして今やっていることをそのまま続けること が妥当なのか、あるいは他の筋道をとるべきなのか • 訓練 ◦ インシデントレスポンスのプロセスを定期的に利用し、身につける • 持ち回り ◦ インシデントコマンダーを持ち回りにしよう
避けられるアンチパターン • 群衆によるインシデント対応 • マジックスモークを消すのは私だ! • リカバリ時間ではなく障害回避の最適化
• 群衆によるインシデント対応 ◦ 「ボールから目を離さないが、ゾーンから足を踏み出さない」 ◦ わらわらと集まってきては問題に首を突っ込み始めること。あるいは誰もが各自の作業に没頭するだ けではいられなくなり、問題が解決されるまで脳裏にこびりついて注意を払わざるを得ない状態 ▪ インシデントコマンドシステムや訓練によって回避しよう ▪
システムを構築して必要な人が問題の管理にフルコミットして、他の人については必要が生じる までエネルギーを温存できるようにすることが重要
• マジックスモークを消すのは私だ! ◦ エリート戦士/ヒーローの文化は落とし穴です ◦ 周到な設計や予防の計画よりもインシデント対応の英雄的な行動を高く評価すること ▪ 優れたエンジニアリングよりも運用での忍耐に報いるのは誤ったインセンティブを与え、運用現 場の混乱とエンジニアの燃え尽きに直結する ▪
組織のレジリエンスを顧みずインシデントを一身に引き受ける誰かを称賛するのはだめよ
• リカバリ時間ではなく障害回避の最適化 ◦ 障害をなくすことに工数を使い、インシデントが発生した際の対処が改善されない ▪ インシデントは避けられない ▪ その回避にすべてを賭けるのではなく、うまく処理できるようになること
インシデント対応訓練
訓練?
他業種からの学び
インシデント対応訓練の目的 インシデントレスポンスのプロセスを定期的に利用し、身につける 逆に訓練をしない場合のリスク (1)システムに対して歴が浅いメンバーが Opsリードとなってぶっつけ本番でやるのは危険 Opsリードの人がシステムの構成などをキャッチアップできていないままインシデント対応を行うと 作業した結果、状態が悪化したりステークホルダーとの調整がうまくいかなかったりする場合がある (2)一部のメンバーがインシデント対応を巻き取ってしまう システムへの理解が深かったりスキルがあるメンバーはインシデントへの反応が早いし対応も的確で 1人でやれてし
まうケースが多い。 そのためそういった一部のメンバーに対応が集中してしまい、他のメンバーがインシデント対応を経験する機会が失 われてしまって結果単一障害点につながってしまう。 (3)コミュニケーションリードやインシデントコマンダーの人が必要な情報連携をいきなりやるのが難しい いろんなチーム間、職種間のコミュニケーションが必要になる中で連携すべき情報をまとめて説明する難易度の高さ がある
インシデント対応訓練の流れ • 事前準備 ◦ ゲームマスター(GM)が訓練用のAWS環境を作成してインシデント内容を決める(対応時間目安は 30分く らい) ◦ 参加メンバーで3人チームを作って以下の役割をふる ▪
インシデントコマンダー ▪ コミュニケーションリード ▪ Opsリード ▪ 参加メンバー外で事業部メンバー役を用意( GMが兼任してOK) ◦ GMが訓練用環境へのアクセス権を全員に付与 • 訓練 ◦ GMが訓練用環境のシステム構成を説明 ◦ GMが発生させるインシデント内容を簡単に共有(サイトが落ちる、一部の機能が停止する、など) ◦ インシデントを発生させる ◦ 参加メンバーが各々の役割で動いてインシデント対応を行う ◦ 事業部メンバーがインシデント解消を宣言できるまで or制限時間まで対応 • フィードバック ◦ インシデント解消を宣言できたかを改めて確認 ◦ 各チームごとにうまくいったこと、幸運だったこと、改善できることを出し合う
実際の訓練 • サービス、使用しているミドルウェアなどの概要 ◦ エンドポイントをHTTPで叩くとトップページが 表示される • 障害の概要 ◦ SREチームがインフラ設定の変更のために
TerraformとAnsibleをリリースしたところトップ ページが表示されなくなってしまった。 • 望まれる復旧時間 ◦ 20分 訓練後の振り返り • コミュニケーションでスムーズに行かなかったところ に気づけた • 影響範囲の確認や復旧作業の方針チェックを Ops リード以外の人たちがフォローする動きが大事 最初はシンプルな構成
ポイント • 事前準備 ◦ システム構成 ▪ 訓練を行う環境をどこに置くか ◦ シナリオ ▪
ポストモーテムの事例を使おう • 訓練 ◦ 負荷の与え方 ▪ 時間制限 ▪ 事業部役の人がコミュニケーションを複雑にし てみる
まとめ
まとめ • インシデント対応の難しさ ◦ インシデントは起こるもの ◦ インシデント対応を難しくしている要因 ▪ 人間にかかる様々なプレッシャー •
インシデントマネジメントの紹介 ◦ タイムライン ◦ インシデントコマンドシステム ◦ 避けられるアンチパターン • インシデント対応訓練の目的とポイント ◦ インシデントレスポンスのプロセスを定期的に利用し、身につける ◦ ぶっつけ本番を避け、なるべく多くのメンバーにインシデントを疑似体験してもらう ◦ ポストモーテムを有効活用して訓練の中では意識的に負荷をかけよう