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

https://fortee.jp/sre-kaigi-2025/proposal/4dcbc059-da02-4aeb-a28b-4bfdbac0710c

Transcript

1. どうやれば インシデント対応能力を 鍛えられるのか？ 髙石 諒 / @r_takaishi SRE Kaigi 2025
2. みなさん
3. インシデント対応 障害対応
4. してますか 🖐
5. 自分の対応能力に 自信がある人 🖐
6. 対応能力を 高めたい人 🖐
7. 今日は インシデント能力を 鍛える話をします！
8. 自己紹介 • 髙石 諒 / @r_takaishi • ソフトウェア エンジニア • 現所属は株式会社フライル ◦ クラウドインフラ中心にいろいろ • 副業でスタートアップのクラウドインフラ・基盤整備 • CloudNative Daysのシステム開発
9. こういうの作ってます • tfclean (https://github.com/takaishi/tfclean) ◦ terraformの import/moved/removed ブロックを削除するツール • terraform-j2md (https://github.com/reproio/terraform-j2md) ◦ terraform planの結果をMarkdownとして整形するツール
10. インシデント対応歴 • ソフトウェアエンジニア歴：2012年〜 • オンコール歴：2016年〜 ◦ 結構曖昧 ◦ 合間合間にオンコールに入っていない期間もある • どういうシステムの対応をしていたか ◦ パブリッククラウド（AWS）上に構築したサービス ◦ プライベートクラウド（OpenStack）やその上に構築したサービス ◦ etc…
11. そもそも インシデント対応能力と は？
12. インシデントとは？ • 定義は組織によって異なる • システムの障害やセキュリティインシデントなど… • 今回は「ユーザーのサービス利用に影響が出ているもの、もしくは出る可能 性のあるもの」とします • 例：不具合やユーザーの操作ミス、ソフトウェア・ライブラリの脆弱性など
13. インシデント対応能力とは？ • ユーザーのサービス利用への影響を最小限に抑え、信頼性を維持する • 原因の特定・暫定対応 • 恒久対応・再発防止 • 社内やユーザーとのやりとり • ポストモーテム • etc…
14. やることが多い…！
15. インシデント対応能力 を得るのは大変
16. 『システム障害対応の教科書』 p.12 インシデント対応能力を得るのは大変 そもそもシステム障害は未知の領域です。基本的に同じ障害は二 度と起きません（不具合を直さない理由があれば別ですが、それ は健全とは言えません）。そのため、教育の基本である反復訓練 を行えません。
17. 『システム障害対応の教科書』 p.12 インシデント対応能力を得るのは大変 そもそもシステム障害は未知の領域です。基本的に同じ障害は二 度と起きません（不具合を直さない理由があれば別ですが、それ は健全とは言えません）。そのため、教育の基本である反復訓練 を行えません。 実際のインシデント対応を繰り返すことで熟達しがち
18. インシデント対応能力を得るのは大変 システム障害は、深夜であろうが休日であろうが容赦なく発生し ます。計画的に障害を起こすことは不可能ですから、計画的に誰 かに経験させるということができません。 『システム障害対応の教科書』 p.12
19. インシデント対応能力を得るのは大変 システム障害は、深夜であろうが休日であろうが容赦なく発生し ます。計画的に障害を起こすことは不可能ですから、計画的に誰 かに経験させるということができません。 『システム障害対応の教科書』 p.12 実際のインシデント対応を繰り返すことで熟達しがち
20. 生き残ったものが 強いのか？
21. 組織として強くなる • 障害・障害レベル・対応フローの定義 • 監視や障害対応時用のシステムの運用 • 組織の体制強化 • 教育や訓練
22. どれも大事だけど…
23. 今日は組織の話は （ほとんど）しません
24. オレが 強くなりたいんだ
25. 今日のスコープ • 前提条件 ◦ 主にWebサービスに関するインシデントを対象としています • 話すこと ◦ 「個人」がインシデント対応能力を得る、伸ばすためには何をするといいか • あまり話さないこと ◦ 「組織」がインシデント対応能力を得る、伸ばすためには何をするといいか ◦ ちょっと話します
26. やっていきましょう
27. インシデント対応能力とは？ • ユーザーのサービス利用への影響を最小限に抑え、信頼性を維持する • 原因の特定・暫定対応 • 恒久対応・再発防止 • 社内やユーザーとのやりとり • ポストモーテム • etc…
28. やることが多い…！
29. インシデント対応は 総合競技
30. インシデント対応は総合競技 • 知識や経験、技能など様々な要素が求められる • いくつかの要素に分解できそう ◦ ハードスキル ◦ ソフトスキル ◦ 経験 ◦ システム理解 • これらの要素の掛け合わせによってインシデント能力を鍛えることができる ◦ （もちろん、チームで分担するのもアリ）
31. ハードスキル
32. ハードスキルとは • 個人が持つ知識・技術・技能・ノウハウなど ◦ プログラミング言語 ◦ データベース ◦ Linux ◦ クラウドプラットフォーム全般 ◦ 各種ツール ◦ ターミナルオペレーション ◦ パフォーマンスチューニング
33. 使える道具は多い方がいい（それはそう） • これを身につけていれば一生安泰、というものはかなり少ない • 技術トレンドの移り変わり • 使えなくなる技術 • チームや職場が変わることによる使用技術の変化 • それでも、可搬性の高いものはあるはず
34. 個人の意見による可搬性の高さ • データベース（MySQLやPostgreSQLなど） ◦ この先もかなり長く使えるのではないか • 広く使われる言語・フレームワーク • Linuxオペレーション ◦ 業務による。クラウドにより隠蔽されておりほぼ使わないケースもあるだろう ◦ 個人的な状況だと、サーバーにSSHしてオペレーションする機会はかなり減った • ターミナルオペレーション ◦ 様々なコマンドを組み合わせてログデータの加工を行ったりするような作業は今でもよくや る
35. 関わるシステム次第で必要な技術は変わる • クラウドオンリーか、オンプレミスオンリーか • 扱うデータ量が少ないか、多いか、めちゃくちゃ多いか • リクエストが少ないか、多いか、めちゃくちゃ多いか • 動画配信や音声配信などはあるか • etc…
36. ハードスキル • これがなければ始まらない基礎要素 • 時間をかけて習得していくしかない ◦ LLMで学習効率Up↑ • 寿命が長く、使われている場所が多い技術は便利
37. ソフトスキル
38. ソフトスキルとは • ハードスキルに較べると対人寄りのスキル（賛否はありそう） • チーム内のコミュニケーション • チーム外とのコミュニケーション • 状況判断や指示を行うリーダーシップ • インシデントコマンダーという役割としても広まってきたイメージ
39. チーム外とのコミュニケーション • CSやマネージャーなど、社内のステークホルダーに状況を共有する • 彼らが必要な情報を適切に伝えることが重要 • 定期的な共有の場を作る
40. チーム内のコミュニケーション • 対応する各メンバーの役割を明確化する ◦ 不必要に複数人で同じ調査を行う必要はない • 声かけ・ファシリテーション ◦ 定期的な状況の同期・ネクストアクション決め • 情報の一元管理 ◦ チャットなのか、ビデオ会議なのか ◦ 調査結果や時系列の情報を保存する場所の明確化
41. リーダーシップ・判断・決断 • 状況把握・優先順位設定 • ネクストアクションの決定 ◦ すべて自分で決める必要はなく、調査したメンバーの意見を元にまとめるのでも十分だろう
42. ソフトスキルは可搬性が高く寿命が長い？ • 可搬性：高 ◦ どこの組織でも重要 ◦ 体制が整っていない場合に整えることができる、というのも強いと思う • 寿命：長 ◦ 今後10年、20年と廃れることはなさそう ◦ スキルの一部はソフトウェアによって代替可能ではある
43. ソフトスキル • 技術とは別に重要 • 普段からファシリテーションをしたり、議論の交通整理をすることで多少学 べる？ • 実践で身につける要素が大きそう（「対応経験」に近い）
44. 対応経験
45. 対応経験とは • これまでに行ったインシデント対応の経験の量 • 一度も対応したことがない人がいきなり対応するのは難しい ◦ 対応時の緊張、ストレス、パニック ◦ 何から手をつけるべきか • 練習試合をしたことがない人がいきなり全国大会で勝てるか？ ◦ （勝てる人もいそうだけど）
46. 実際のトラブルだけで経験を積むのは難しい • システム開発や運用、インフラの進化により、トラブルは発生しにくくなっ ている • 簡単なトラブルは自動修復されることもある • 人間が対応しないといけないトラブルは難易度が高いかもしれない • トラブル対応のオンボーディングが難しいのではないか
47. どのようにして擬似的に経験を積むか • シャドーイング • 障害対応訓練 • イベントに参加してみる
48. シャドーイング • 経験豊富なメンバーを観察して学ぶプロセス • 実際のオペレーションはせず、対応している人を観察 • 責任は発生しないので、障害対応の方法に集中できる • いきなり難易度の高い障害のシャドーイングに入ると大変かも
49. 障害対応訓練 • 開発環境や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を通して身代金を要求したという。
50. Hardening Project • https://wasforum.jp/hardening-project/ • セキュリティ堅牢化に関する競技 • 脆弱性のあるビジネスシステム（ECサイトなど）が与えられ、売り上げを上 げつつセキュリティインシデントに対応するというもの • 擬似的にセキュリティインシデントを対応することができる
51. ISUCON • https://isucon.net/ • パフォーマンスに関する競技 • Webサービスがお題として与えられ、レギュレーションの中で高速化を図る チューニングバトル • 擬似的にパフォーマンスに関するトラブルシュートを体験できる
52. 対応経験 • 長く業界に身を置くか、ハードな現場に身を置くことで得られる ◦ 身も蓋もない… • それ以外は擬似的に経験を積むしかない
53. システム理解
54. システム理解とは • 対象システム（自分が責任を持つサービスやシステム）についてどこまで理 解しているか • アーキテクチャやシステム構成、コード、設計、データベース、ドメイン知 識、過去の経緯、etc…
55. 入社初日にインシデント対応できるか？ • 高スキルかつ対応経験が豊富でもシステムを知らないと難しい ◦ できる人もいると思うが… • 個人・組織の両方で取り組むことが大事 ◦ ドキュメントはあるか ◦ オンコールに入る前にシステム理解の時間を確保しているか ◦ 過去の経緯を記録として残しているか
56. どこからシステムを理解していくか • パターン1：システムの全体像を把握し、ユーザーリクエストの経路から理 解していく ◦ 個人的には、まずはシステム構成図を自分で書くところから始める • パターン2：データベースのテーブルなど、データから理解していく • 最終的にはどちらも大事
57. システム理解 • 適切な対応に必須の要素 • アンチパターン：お手並み拝見 • 個人・組織の両輪で進める必要あり
58. まとめ
59. インシデント対応は「総合競技」 • 技術・技能を身につけた上でソフトスキルや経験を積む ◦ 高速道路はあるがどこでもドアはない ◦ LLMを活用しよう • これまでの経験に甘えず、目の前のシステムに向き合う
60. とはいえ一人で全部やるのは難しい • やはりチーム・組織単位でも鍛える必要はある • 全部できるやつが集まるのが一番強い • 個人・組織の両輪でやっていく
61. インシデント対応 やっていくぞ！
62. ここにフライルの紹介スライドをいれる
63. We are hiring!