やさしい障害対応

社内勉強会で発表したスライドです。
題材にした書籍はこちらです。
システム障害対応の教科書(https://gihyo.jp/book/2024/978-4-297-14012-0)

Transcript

1. やさしい障害対応
2. ©tete marche CO., LTD. 自己紹介 2 • 所属：テテマーチ株式会社 • お仕事：プロダクトエンジニア • ヒロシマ　ダイスケ • 大阪在住 • X（旧Twitter）: @164fm • 趣味でカメラやってます
3. ©tete marche CO., LTD. 3 読んだ本 https://gihyo.jp/book/2024/978-4-297-14012-0 ・どちらかといえば大企業向けの本だった ・鵜呑みにせず自分たちの組織でどう取り組むかが 　大事だなという感想でした
4. ©tete marche CO., LTD. 4 はじめに エンジニアやってて障害出したことがある人、 遭遇したことがある人
5. ©tete marche CO., LTD. 5 はじめに エンジニアやってて障害出したことがある人、 遭遇したことがある人 おそらくみんなある。
6. ©tete marche CO., LTD. 6 はじめに しかし障害対応の方法をちゃんと教わった経験は、 皆さんあまりないのではないでしょうか？ 　　　　？？「背中を見て学べ」 　　　　？？「経験していくしかないよ」
7. ©tete marche CO., LTD. 7 体系で学ぶことができない要因はいくつか存在する アプリケーション開発 インフラ開発 ・体系だった勉強法や書籍が充実している ・発生がハンドリングできる
8. ©tete marche CO., LTD. 8 体系で学ぶことができない要因はいくつか存在する 障害対応 ・体系だった勉強や書籍が充実はしていない ・発生が突発で予測不能 ・だいたい経験で何とかしがち
9. ©tete marche CO., LTD. 9 体系で学ぶことができない要因はいくつか存在する 障害対応 ・体系だった勉強や書籍が充実はしていない ・発生が突発で予測不能 ・だいたい経験で何とかしがち ↓ 現場ごとに経験が成熟されていて 暗黙知になっていることが多い
10. ©tete marche CO., LTD. 10 暗黙知であることのデメリット 1. 属人化によるリスク 2. チーム内での認識齟齬 3. ドキュメント・設計書に反映されない 4. 再利用性・保守性の低下
11. ©tete marche CO., LTD. 11 障害対応を学ぶには 何を学ばなくてはいけないのかをはっきりさせるため
12. ©tete marche CO., LTD. 12 障害対応を学ぶには 何を学ばなくてはいけないのかをはっきりさせるため 暗黙知　→　形式知 にする必要がある
13. ©tete marche CO., LTD. 13 そもそもなんで暗黙知になってしまうのか ・対応と終結までが優先され振り返りの機会が優先度下がり がち ・技術の進化による複雑性の増加 　・ブラックボックス化されやすい 　・インフラ集約と分散化 　・監視対象増加 　・etc…
14. ©tete marche CO., LTD. 14 そもそもなんで暗黙知になってしまうのか 会社の組織規模の観点で見ると、 人員が増えるほど線形でコミュニケーションコストが増大し、 形式知にする優先度が上がらない
15. ©tete marche CO., LTD. 15 そもそもなんで暗黙知になってしまうのか 会社の組織規模の観点で見ると、 人員が増えるほど線形でコミュニケーションコストが増大し、 形式知にする優先度が上がらない ↓ 障害対応に強いチームにするには、、、
16. ©tete marche CO., LTD. システム障害の定義・目的 16
17. ©tete marche CO., LTD. 17 強いチームを作る、そのまえにちょっと休憩 まずは障害対応の定義について知っておく必要がある
18. ©tete marche CO., LTD. 18 システム障害の定義を話す前に 障害対応はなんのためにやるんだっけ
19. ©tete marche CO., LTD. 19 システム障害の定義を話す前に 障害対応はなんのためにやるんだっけ ↓ ユーザの業務に支障を出さない状態にすることが目的 開発者はついついシステムを直すことに 目がいきがちであるが、極論ユーザの業務に影響がなければそれでいい。 ということを念頭に置く。 （最終的には恒久対応で直す必要はあるが）
20. ©tete marche CO., LTD. 20 システム障害の定義 障害対応を開始するトリガー（引き金）の見極めで必要になってくる 定義を決めておかないと ？？「これ ◦◦課に連絡したほうがいいのか」 ？？「深夜に連絡したら迷惑かも、、、」 と対応のスタートがあやふやになってしまう。 定義が曖昧だと対応の遅れにつながることもある 以前複数アカウントの画面が固まってしまう問題を開発が対応したことがあった。 が、実はCSはその問題を開発対応の前日に知っていたことがあった。
21. ©tete marche CO., LTD. 21 定義の決め方 ・ユーザ視点に立って定義することが重要 　・サーバが、、、 　・アプリケーションが、、、 　のような非機能要件ではなく、この機能が利用できていないなどで定義するのが　望 ましい。 ・なるべく広範囲で定義したほうがよい 　・範囲を限定しすぎると、逆にトリガーの網羅性を欠いてしまう ・決めたらドキュメントを残すなどして、ステークホルダに展開するのが望ましい
22. ©tete marche CO., LTD. 22 障害対応の目的 ・障害対応＝システムを直す　とは限らない 　・ユーザの業務に影響が出ないようにするのを優先する 　・これによって組織としてどういうプロセス、意思決定で動いていくかが明確に　なる
23. ©tete marche CO., LTD. 障害対応の登場人物 23
24. ©tete marche CO., LTD. 24 組織の最小構成 インシデントコマンダー一人 作業者　一人
25. ©tete marche CO., LTD. 25 組織の最小構成 組織の規模にもよるが、他にも役割は存在する CIO ユーザー担当
26. ©tete marche CO., LTD. 26 組織の最小構成 インシデントコマンダーとは 障害が発生したときに任命される
27. ©tete marche CO., LTD. 27 インシデントコマンダーに必要な能力 ・マネジメントスキル 　・現場における舵取り 　・情報の発信 ・とはいえ説明することはあるので 　アーキテクチャへの理解は必要
28. ©tete marche CO., LTD. 28 組織の最小構成 作業者とは
29. ©tete marche CO., LTD. 29 作業者に必要な能力 ・プロダクト、技術領域の専門性 　・マネジメント＜技術
30. ©tete marche CO., LTD. 30 ユーザ担当・ CIO ・ユーザ担当 　・ユーザの窓口になって一時的に情報を受け、インシデントコマンダー、ないしは　　社 内に連携する人 ・CIO（Chief Information Officer） 　・最高情報責任者。とても偉い人。 　・IT戦略の立案と実行・情報システムを管理する立場で、 　　重大インシデントが発生した時には意思決定をすることもある。
31. ©tete marche CO., LTD. 障害対応のプロセス 31
32. ©tete marche CO., LTD. 32 障害対応の プロセス ・開発組織での障害対応プロセスはどこからどこまでかは確認しておいたほうがいい 　・プロセスが決まっていないと対応に余分な時間を使ってしまうことになる 引用: システム障害対応の教科書 https://gihyo.jp/book/2024/978-4-297-14012-0
33. ©tete marche CO., LTD. 33 イベントの確認 - 1 ・ 前述のように何をトリガーにして障害の対応をスタートとするか 　・対応窓口からの通知 　・Sentryからの通知 　・アラート ・イベントの分類分けをおこなう 　・エスカレーション 　・静観 ・ロギングの分類わけもしておこう 　・info, error, warning, alert
34. ©tete marche CO., LTD. 34 イベントの確認 - 2 ・ ロギング、アラートの注意点 　・なんでもかんでも通知しない 　　・オオカミ少年になってしまい、本当にやばい通知を見逃してしまう 　　・監視者が疲弊する 　・自動で復旧する仕組みが使えるなら積極的に利用する
35. ©tete marche CO., LTD. 35 検知・事象の確認 ・ トリガーをもとに何が発生しているのかを事象の確認をする 　・あるべき状態を明確にし、差分を明確にすることで事象がわかりやすくなる 　・まずは迅速に一報する。不明点は不明と伝えてよい 　・曖昧な表現は避けてくねくねしない ・場合によってはインシデントコマンダーの任命・人員の招集をおこなう
36. ©tete marche CO., LTD. 36 業務調査 ・ユーザ視点での業務影響を調査する 　例）管理画面の ◦◦でデータの更新に失敗する、 ◦◦の帳票が破損している ・業務影響によって更なる影響がないかリレーションを確認する ・障害レベルを更新する（あとで話します） tips 影響あり、なし、調査中のような ステータスを付与する
37. ©tete marche CO., LTD. 37 原因調査 ・仮説を立て検証する ・原因の究明というよりはあくまでも障害部位の特定でいい
38. ©tete marche CO., LTD. 38 復旧対応 ・システム障害による業務影響の回避・拡大防止・復旧させるための対応を決定す　る のが目的 ・復旧対応策の調査・検討・準備・実施までおこなう 　・もし想定外の事態が起きたら作業はいったんストップする。二次被害を防ぐた　　め 　・例）クエリの結果が思ってたんと違う、、、 ・復旧を確認し、 　体制の解散までおこなう
39. ©tete marche CO., LTD. 39 本格（恒久）対応以降 ・再発防止策を考える（あとで話します） ・改めてステークホルダ向けの事後共有をおこなう
40. ©tete marche CO., LTD. 40 休憩 ・障害対応フレームワークにインシデントコマンドシステム（ ICS）というのがある 　・米国の医療・災害対応で使われるフレームワーク 　・人命にかかわる活動のフレームワークなので、 　　システム側の人間でも学びは多いのかなと感じました。
41. ©tete marche CO., LTD. 障害対応力の改善・教育・体制づくり 41
42. ©tete marche CO., LTD. 42 分析・改善のスコープ ・システム品質、障害対応品質の二軸がある 　・システム品質、、、なぜ障害が発生したか 　・障害対応品質、、、障害対応は適切だったか 　　　・システム品質と比べてあまり話されないそう
43. ©tete marche CO., LTD. 43 振り返り手法 ・ポストモーテム（レトロスペクティブ） ・決して非難をおこなわない 　・ポジティブな空間をつくろう ・時間をあけずにおこなう ・障害対応中にまよったことも言語化する ・あくまで内部向けに振り返る 引用: システム障害対応の教科書 https://gihyo.jp/book/2024/978-4-297-14012-0
44. ©tete marche CO., LTD. 44 振り返り手法 ・みんなだいすきなぜなぜ分析 ・精神論に帰結させないこと ・改善不可能な方向に完結させない 　・あくまでも現実的に 引用: システム障害対応の教科書 https://gihyo.jp/book/2024/978-4-297-14012-0
45. ©tete marche CO., LTD. 45 振り返り手法 ・みんなだいすき KPT
46. ©tete marche CO., LTD. 46 防止策のポイント ・再発防止策は具体性を持たせる ・マンパワーで解決しようとしない 　・仕組化できるところはして、自動化できるところは自動化する 　・チェックを増やすのはいいが、 　　人員だよりはだめ 著作権アレなのでSpeakerDeckに載せない
47. ©tete marche CO., LTD. 47 防止策のポイント ・再発防止策は具体性を持たせる ・マンパワーで解決しようとしない 　・仕組化できるところはして、自動化できるところは自動化する 　・チェックを増やすのはいいが、 　　人員だよりはだめ 著作権アレなのでSpeakerDeckに載せない
48. ©tete marche CO., LTD. 48 定量なプロアクティブ分析 ・プロアクティブとは問題が起きる前に活動すること ・定量で分析して、障害の発生を抑制できるのかというチェック 引用: システム障害対応の教科書 https://gihyo.jp/book/2024/978-4-297-14012-0
49. ©tete marche CO., LTD. 49 教育方法 ・システム・マネジメントの網羅的なレクチャー ・ローテーション教育 　・作業者とインシデントコマンダーをローテしてみたりなど 　・または持ち回り ・シャドーイング 　・俺の背中を見ておけ（ベテランと新人が一緒に対応、または新人が見守る） ・カオスエンジニアリング（教育というよりは訓練）
50. ©tete marche CO., LTD. 50 教育で目指すべきレベル ・チームとして、個人としてどのレベルに達するべきかを目指すことも大事 引用: システム障害対応の教科書 https://gihyo.jp/book/2024/978-4-297-14012-0
51. ©tete marche CO., LTD. 51 障害対応時の体制づくり 引用: システム障害対応の教科書 https://gihyo.jp/book/2024/978-4-297-14012-0
52. ©tete marche CO., LTD. 52 障害対応時の体制づくり ・ハイブリッド勤務で情報格差を作らない 　・利用するツールを事前に明らかにし、 　　なるべく情報を集約し格差を発生させない 　・我々でいうと SlackかNotionに集約させるのがよい ・ただなんでも集約させるのは一部ノイズになるので、 　ユーザの意見、技術的事象はカテゴライズして集約したほうがよい ・重大インシデントの場合の集合場所はちゃんと決めておく 　（会議室、仮想であれば Slackチャンネル）
53. ©tete marche CO., LTD. エンドユーザー向け情報発信 53
54. ©tete marche CO., LTD. 54 情報発信の目的 ・システム障害を受けたユーザが最善の行動を取れるようにすること 　・復旧方法には無数の手段があるので、ユーザが行動を取れるように 　　情報発信をおこなう必要がある
55. ©tete marche CO., LTD. 55 エンドユーザ向け情報発信の例 引用: システム障害対応の教科書 https://gihyo.jp/book/2024/978-4-297-14012-0
56. ©tete marche CO., LTD. 56 エンドユーザ向け情報発信の例 引用: システム障害対応の教科書 https://gihyo.jp/book/2024/978-4-297-14012-0
57. ©tete marche CO., LTD. 57 エンドユーザ向け情報発信の例 https://status.circleci.com/incidents/9qn2njm10z15
58. ©tete marche CO., LTD. 58 情報発信の頻度と内容 ・発信の頻度は積極的な方が良い 　・自社の評判を優先し、ユーザ体験、業務をないがしろにするとかえって評判が　　悪 くなる ・詳細な技術的原因よりユーザ影響を発信する 　・ユーザはシステムが使えるかどうか、取るべき対応についてにしか関心がない 　・ただし復旧後は原因と再発防止策を発信する
59. ©tete marche CO., LTD. おまけ 59
60. ©tete marche CO., LTD. 60 AI活用 ・AIの出番がないというとそんなことはない ・ユーザストーリーやシーケンス図の作成 　・特にユーザ担当やインシデントコマンダーとの共有で役に立つ ・修正コード・テストコードの修正 ・復旧作業時のコマンド生成 ・NotebookLMを使った情報の整理（できるかも？）
61. ©tete marche CO., LTD. 61 まとめ - 1 ・今で言う SREの側面が大きいおおきい分野なのかなと感じた ・ユーザの業務に支障を出さない、早期回復を最優先にする ・手段は問わない ・インシデントコマンダーと作業者は適性の観点・役割の観点からも分けるべきと　ある が、組織の規模と障害を見てのトレードオフなのかなと思う 　・要はバランス 　・重大障害の発生に備えて組織する準備はあってもいいかも ・なによりも回答の速度は早いほうがいい 　・不明点は不明でもいい。デマを流すよりかはマシ
62. ©tete marche CO., LTD. 62 まとめ - 2 ・自動化は正義 ・ドキュメントは正義 　・対応プロセス、システムの構成図 　・メンテはちゃんとしよう
63. ©tete marche CO., LTD. ご清聴、ありがとうございました！ 63