🍿

システム障害対応実践ガイドの備忘録

2023/11/19に公開

はじめに

不具合を直すことや障害対応をすることが目的ではない
ITサービスが生み出す価値を既存させず維持することが目的
マインドセットとしては、適切な保守が行われなかった場合に比べ将来価値の総量を増やす行為と言える

つい情報を多く集めようとしてしまうが、整理しきれない情報量は現場が混乱するだけ。
電車で緊急アナウンスで、
火事なので逃げてください
と
9号車の前から2番目のシートの荷物置き場にあった荷物の中に可燃性の薬物が入っていて発火したので逃げてください。
の例を思い出そう

障害対応時は「事象」に注目して対策を考える
一方で、障害対応の改善は「アクション」に注目して考える
なぜなら、「事象」は幾通りもあるので改善を考える際に適切でない
例えば、ログを見るや再起動する、連絡するといったアクションは高頻度で実施されるし、単純であることが多いため手を打ちやすい

アプローチとしては、簡単で効果が大きいところ「だけ」を目指すこと
一歩でも改善が進んでいることを関係者が実感できるのが大事（背景としては改善は緊急度が低く後回しにされがち）

重要度は高いが緊急度が低い
- 売上が優先されやすいという力学を織り込んで関係者に提案する必要がある
  - 改善することで今後妨げとなる売上の毀損額や復旧のための工数の削減という観点で協議する
- 日常業務の中で重要じゃないものをやめることで改善の時間を捻出する
関連システムと関係者が多い
- 意思決定する難易度が高い
- システム連携部分の仕様は継承が薄くなりがち（人の入れ替えが起きる業界なので引き継ぎの難しさがある）
- 責任範囲を事前に明確にしておかないとお見合いする
元の運用設計が不完全、または設計できていない