どうやればインシデント対応能力を鍛えられるのか？ / SRE Kaigi 2025

Slide 1

Slide 1 text

どうやればインシデント対応能力を鍛えられるのか？髙石諒 / @r_takaishi SRE Kaigi 2025

Slide 2

Slide 2 text

みなさん

Slide 3

Slide 3 text

インシデント対応障害対応

Slide 4

Slide 4 text

してますか 🖐

Slide 5

Slide 5 text

自分の対応能力に自信がある人 🖐

Slide 6

Slide 6 text

対応能力を高めたい人 🖐

Slide 7

Slide 7 text

今日はインシデント能力を鍛える話をします！

Slide 8

Slide 8 text

自己紹介 ● 髙石諒 / @r_takaishi ● ソフトウェアエンジニア ● 現所属は株式会社フライル ○ クラウドインフラ中心にいろいろ ● 副業でスタートアップのクラウドインフラ・基盤整備 ● CloudNative Daysのシステム開発

Slide 9

Slide 9 text

こういうの作ってます ● tfclean (https://github.com/takaishi/tfclean) ○ terraformの import/moved/removed ブロックを削除するツール ● terraform-j2md (https://github.com/reproio/terraform-j2md) ○ terraform planの結果をMarkdownとして整形するツール

Slide 10

Slide 10 text

インシデント対応歴 ● ソフトウェアエンジニア歴：2012年〜 ● オンコール歴：2016年〜 ○ 結構曖昧 ○ 合間合間にオンコールに入っていない期間もある ● どういうシステムの対応をしていたか ○ パブリッククラウド（AWS）上に構築したサービス ○ プライベートクラウド（OpenStack）やその上に構築したサービス ○ etc…

Slide 11

Slide 11 text

そもそもインシデント対応能力とは？

Slide 12

Slide 12 text

インシデントとは？ ● 定義は組織によって異なる ● システムの障害やセキュリティインシデントなど… ● 今回は「ユーザーのサービス利用に影響が出ているもの、もしくは出る可能性のあるもの」とします ● 例：不具合やユーザーの操作ミス、ソフトウェア・ライブラリの脆弱性など

Slide 13

Slide 13 text

インシデント対応能力とは？ ● ユーザーのサービス利用への影響を最小限に抑え、信頼性を維持する ● 原因の特定・暫定対応 ● 恒久対応・再発防止 ● 社内やユーザーとのやりとり ● ポストモーテム ● etc…

Slide 14

Slide 14 text

やることが多い…！

Slide 15

Slide 15 text

インシデント対応能力を得るのは大変

Slide 16

Slide 16 text

『システム障害対応の教科書』 p.12 インシデント対応能力を得るのは大変そもそもシステム障害は未知の領域です。基本的に同じ障害は二度と起きません（不具合を直さない理由があれば別ですが、それは健全とは言えません）。そのため、教育の基本である反復訓練を行えません。

Slide 17

Slide 17 text

『システム障害対応の教科書』 p.12 インシデント対応能力を得るのは大変そもそもシステム障害は未知の領域です。基本的に同じ障害は二度と起きません（不具合を直さない理由があれば別ですが、それは健全とは言えません）。そのため、教育の基本である反復訓練を行えません。実際のインシデント対応を繰り返すことで熟達しがち

Slide 18

Slide 18 text

インシデント対応能力を得るのは大変システム障害は、深夜であろうが休日であろうが容赦なく発生します。計画的に障害を起こすことは不可能ですから、計画的に誰かに経験させるということができません。『システム障害対応の教科書』 p.12

Slide 19

Slide 19 text

インシデント対応能力を得るのは大変システム障害は、深夜であろうが休日であろうが容赦なく発生します。計画的に障害を起こすことは不可能ですから、計画的に誰かに経験させるということができません。『システム障害対応の教科書』 p.12 実際のインシデント対応を繰り返すことで熟達しがち

Slide 20

Slide 20 text

生き残ったものが強いのか？

Slide 21

Slide 21 text

組織として強くなる ● 障害・障害レベル・対応フローの定義 ● 監視や障害対応時用のシステムの運用 ● 組織の体制強化 ● 教育や訓練

Slide 22

Slide 22 text

どれも大事だけど…

Slide 23

Slide 23 text

今日は組織の話は（ほとんど）しません

Slide 24

Slide 24 text

オレが強くなりたいんだ

Slide 25

Slide 25 text

今日のスコープ ● 前提条件 ○ 主にWebサービスに関するインシデントを対象としています ● 話すこと ○ 「個人」がインシデント対応能力を得る、伸ばすためには何をするといいか ● あまり話さないこと ○ 「組織」がインシデント対応能力を得る、伸ばすためには何をするといいか ○ ちょっと話します

Slide 26

Slide 26 text

やっていきましょう

Slide 27

Slide 27 text

Slide 28

Slide 28 text

やることが多い…！

Slide 29

Slide 29 text

インシデント対応は総合競技

Slide 30

Slide 30 text

インシデント対応は総合競技 ● 知識や経験、技能など様々な要素が求められる ● いくつかの要素に分解できそう ○ ハードスキル ○ ソフトスキル ○ 経験 ○ システム理解 ● これらの要素の掛け合わせによってインシデント能力を鍛えることができる ○ （もちろん、チームで分担するのもアリ）

Slide 31

Slide 31 text

ハードスキル

Slide 32

Slide 32 text

ハードスキルとは ● 個人が持つ知識・技術・技能・ノウハウなど ○ プログラミング言語 ○ データベース ○ Linux ○ クラウドプラットフォーム全般 ○ 各種ツール ○ ターミナルオペレーション ○ パフォーマンスチューニング

Slide 33

Slide 33 text

使える道具は多い方がいい（それはそう） ● これを身につけていれば一生安泰、というものはかなり少ない ● 技術トレンドの移り変わり ● 使えなくなる技術 ● チームや職場が変わることによる使用技術の変化 ● それでも、可搬性の高いものはあるはず

Slide 34

Slide 34 text

個人の意見による可搬性の高さ ● データベース（MySQLやPostgreSQLなど） ○ この先もかなり長く使えるのではないか ● 広く使われる言語・フレームワーク ● Linuxオペレーション ○ 業務による。クラウドにより隠蔽されておりほぼ使わないケースもあるだろう ○ 個人的な状況だと、サーバーにSSHしてオペレーションする機会はかなり減った ● ターミナルオペレーション ○ 様々なコマンドを組み合わせてログデータの加工を行ったりするような作業は今でもよくやる

Slide 35

Slide 35 text

関わるシステム次第で必要な技術は変わる ● クラウドオンリーか、オンプレミスオンリーか ● 扱うデータ量が少ないか、多いか、めちゃくちゃ多いか ● リクエストが少ないか、多いか、めちゃくちゃ多いか ● 動画配信や音声配信などはあるか ● etc…

Slide 36

Slide 36 text

ハードスキル ● これがなければ始まらない基礎要素 ● 時間をかけて習得していくしかない ○ LLMで学習効率Up↑ ● 寿命が長く、使われている場所が多い技術は便利

Slide 37

Slide 37 text

ソフトスキル

Slide 38

Slide 38 text

ソフトスキルとは ● ハードスキルに較べると対人寄りのスキル（賛否はありそう） ● チーム内のコミュニケーション ● チーム外とのコミュニケーション ● 状況判断や指示を行うリーダーシップ ● インシデントコマンダーという役割としても広まってきたイメージ

Slide 39

Slide 39 text

チーム外とのコミュニケーション ● CSやマネージャーなど、社内のステークホルダーに状況を共有する ● 彼らが必要な情報を適切に伝えることが重要 ● 定期的な共有の場を作る

Slide 40

Slide 40 text

チーム内のコミュニケーション ● 対応する各メンバーの役割を明確化する ○ 不必要に複数人で同じ調査を行う必要はない ● 声かけ・ファシリテーション ○ 定期的な状況の同期・ネクストアクション決め ● 情報の一元管理 ○ チャットなのか、ビデオ会議なのか ○ 調査結果や時系列の情報を保存する場所の明確化

Slide 41

Slide 41 text

リーダーシップ・判断・決断 ● 状況把握・優先順位設定 ● ネクストアクションの決定 ○ すべて自分で決める必要はなく、調査したメンバーの意見を元にまとめるのでも十分だろう

Slide 42

Slide 42 text

ソフトスキルは可搬性が高く寿命が長い？ ● 可搬性：高 ○ どこの組織でも重要 ○ 体制が整っていない場合に整えることができる、というのも強いと思う ● 寿命：長 ○ 今後10年、20年と廃れることはなさそう ○ スキルの一部はソフトウェアによって代替可能ではある

Slide 43

Slide 43 text

ソフトスキル ● 技術とは別に重要 ● 普段からファシリテーションをしたり、議論の交通整理をすることで多少学べる？ ● 実践で身につける要素が大きそう（「対応経験」に近い）

Slide 44

Slide 44 text

対応経験

Slide 45

Slide 45 text

対応経験とは ● これまでに行ったインシデント対応の経験の量 ● 一度も対応したことがない人がいきなり対応するのは難しい ○ 対応時の緊張、ストレス、パニック ○ 何から手をつけるべきか ● 練習試合をしたことがない人がいきなり全国大会で勝てるか？ ○ （勝てる人もいそうだけど）

Slide 46

Slide 46 text

実際のトラブルだけで経験を積むのは難しい ● システム開発や運用、インフラの進化により、トラブルは発生しにくくなっている ● 簡単なトラブルは自動修復されることもある ● 人間が対応しないといけないトラブルは難易度が高いかもしれない ● トラブル対応のオンボーディングが難しいのではないか

Slide 47

Slide 47 text

どのようにして擬似的に経験を積むか ● シャドーイング ● 障害対応訓練 ● イベントに参加してみる

Slide 48

Slide 48 text

シャドーイング ● 経験豊富なメンバーを観察して学ぶプロセス ● 実際のオペレーションはせず、対応している人を観察 ● 責任は発生しないので、障害対応の方法に集中できる ● いきなり難易度の高い障害のシャドーイングに入ると大変かも

Slide 49

Slide 49 text

障害対応訓練 ● 開発環境やStaging環境で意図的に障害を発生させて対応の経験を積む ○ 地震や火事の訓練、しますよね ● 自社の環境で訓練するのでリアリティがある ● 効果は高いが準備など含め高コスト自社のDB破壊しCEOに身代金要求、freeeが本当にやったクラウド障害訓練の舞台裏　「従業員はトラウマに」（1/3 ページ） - ITmedia NEWS https://www.itmedia.co.jp/news/articles/2203/17/news038.html freeeは2021年10月、標的型攻撃とランサムウェアを組み合わせたシナリオを基に全社的な訓練を実施。AWS上のDBからデータを盗み出し、バックアップを消した上で、自社の CEOに社内SNSを通して身代金を要求したという。

Slide 50

Slide 50 text

Hardening Project ● https://wasforum.jp/hardening-project/ ● セキュリティ堅牢化に関する競技 ● 脆弱性のあるビジネスシステム（ECサイトなど）が与えられ、売り上げを上げつつセキュリティインシデントに対応するというもの ● 擬似的にセキュリティインシデントを対応することができる

Slide 51

Slide 51 text

ISUCON ● https://isucon.net/ ● パフォーマンスに関する競技 ● Webサービスがお題として与えられ、レギュレーションの中で高速化を図るチューニングバトル ● 擬似的にパフォーマンスに関するトラブルシュートを体験できる

Slide 52

Slide 52 text

対応経験 ● 長く業界に身を置くか、ハードな現場に身を置くことで得られる ○ 身も蓋もない… ● それ以外は擬似的に経験を積むしかない

Slide 53

Slide 53 text

システム理解

Slide 54

Slide 54 text

システム理解とは ● 対象システム（自分が責任を持つサービスやシステム）についてどこまで理解しているか ● アーキテクチャやシステム構成、コード、設計、データベース、ドメイン知識、過去の経緯、etc…

Slide 55

Slide 55 text

入社初日にインシデント対応できるか？ ● 高スキルかつ対応経験が豊富でもシステムを知らないと難しい ○ できる人もいると思うが… ● 個人・組織の両方で取り組むことが大事 ○ ドキュメントはあるか ○ オンコールに入る前にシステム理解の時間を確保しているか ○ 過去の経緯を記録として残しているか

Slide 56

Slide 56 text

どこからシステムを理解していくか ● パターン1：システムの全体像を把握し、ユーザーリクエストの経路から理解していく ○ 個人的には、まずはシステム構成図を自分で書くところから始める ● パターン2：データベースのテーブルなど、データから理解していく ● 最終的にはどちらも大事

Slide 57

Slide 57 text

システム理解 ● 適切な対応に必須の要素 ● アンチパターン：お手並み拝見 ● 個人・組織の両輪で進める必要あり

Slide 58

Slide 58 text

まとめ

Slide 59

Slide 59 text

インシデント対応は「総合競技」 ● 技術・技能を身につけた上でソフトスキルや経験を積む ○ 高速道路はあるがどこでもドアはない ○ LLMを活用しよう ● これまでの経験に甘えず、目の前のシステムに向き合う

Slide 60

Slide 60 text

とはいえ一人で全部やるのは難しい ● やはりチーム・組織単位でも鍛える必要はある ● 全部できるやつが集まるのが一番強い ● 個人・組織の両輪でやっていく