システム障害対応の参考になる書籍や最新の考え方を教えて!と思っている方も多いのではないでしょうか。
システム障害対応の改善を進めるにあたり、世の中のシステム障害対応の考え方や
進め方についていろいろ調べることをしました。
その中でも参考になった書籍や考え方などをご紹介いたします。
本記事では、「システム障害対応の改善が必要と考えている」皆様へ
インシデント管理・システム監視にも関係しており、金融・オンプレでも使えるので是非ご利用ください！
PagerDuty Incident Response とは
本日はアメリカで上場しているサービスで「Pagerduty」というものがあります。
その会社がシステム障害対応の考え方を英語文章で公開しており、それを邦訳してくれたページのご紹介です。
ご紹介ページ
良いと思うところ
私も何度か拝見させていただきましたが、この文章のいいところは「ポストモーテム」（振り返り）と「トレーニングガイド」（訓練）があるところです。
ここに書かれていることが必ずしも正しいとは言いませんが、振り返り、訓練のガイドラインとして公開頂いているのはとてもありがたいなと思っております。
その他にも抜粋して参考になりそうな所での感想など記載させていただきます。
「ポストモーテム」（振り返り）
故障対応が落ち着いた後に「どうやったら良い振り返りができるのか？」と考える方も多いのではないでしょうか？
システム障害が起きて、その場は頑張って対処をしますが、その後インシデント管理ツールの入力や、しっかりとした振り返りはなかなかできないものです。
「振り返りはちゃんとやりなさい！」と管理する方がいたり、各社独自の振り返りフォーマットがあったりする組織は多いかもしれませんが、このようにやり方を公開しており、かつ最近の潮流に合わせるものはなかなか無いなぁと思っています。
しかも、有名他社のStripe,AWSなどの振り返りのリンクも貼ってあります。
「トレーニングガイド」（訓練）
システム障害訓練は必要と言われつつ、なかなか後回しになっているのではないでしょうか？
私もそんな記憶はあります…
普段からある程度システム障害対応をしている組織であれば慣れたものですが、たまにしか起きないチームこそなかなかメンバーの育成が難しいですよね。
私も訓練をやったことありますが、人を集めても避難訓練のように手順や経路を確認できるようになったとしても、障害対応ノウハウはなかなかたまらず…
このドキュメントで解決するわけではないですが、他社のシステム障害訓練ってどうなっているか？という意味では面白いドキュメントです。
「オンコール」（障害発生通知やエスカレーション）
保守業務を経験された方は経験あるかと思いますが、故障対応は深夜でも早朝でも対応しなくてはいけません。
深夜に電話を受けた担当者は、眠気の中おこされ、何が起きてるのか必死に、まず孤独に頭を回して、「不安」「苛立ち」「恐怖」の感情を抱きながら、何をすべきか考えます。
わからないまま時間が経ってしまい、事態が深刻になっていかないか、さらに不安が増していく経験がある方もいらっしゃるかと思います。
そんな中記載がありました「誰もが、全てを知っているわけではない。 チーム全体で手助けする。」という文化がとても大事だとおもいました。
わからない事をエスカレーションすることは、恥ずべきことではない、チーム全体の学びになり、助け合うという文化を持っている組織がきっといい運用をされているかと思います。
これを全員が意識できる強い組織は、システム障害が起こっても、迅速に素晴らしいサービスを暫定復旧させているのかと想像できます。
この文化を作るために、まずはトップダウンで上層部から何度も伝えてあげる事が大事かと思います。
現場担当者は、自分でなんとかやろうとしてるんです…エスカレ遠慮しちゃう事もあるんです…
「インシデントの深刻度」と「システム障害対応の関係者」
発生したアラートが、顧客にどのように与えてるか？など発生時点で何もわからず、なんでもかんでも電話があったら出社し駆けつけて調査をしていた経験を思い出しました。
当たり前でしょ！と言われてしまいそうですが、ユーザーがどの程度困るのか？それはどのくらいのユーザーがいるか？顧客の困り具合の大きさと影響人数で、深刻度を決める事が大事だと思います。
そのシステム障害が、どんなサービスが使えなくて困っているのか？それはユーザーの何%に影響しているか？などの「指標に応じたレベル」「深刻度に応じた体制作り」を決めておき、それをシステム障害発生時の指針としておけば、その場でどの関係者まで連絡すべきか？これは連絡しても怒られないか？と悩む事は少なくなるはずです。
そして深刻度がわかるように、ユーザー影響がわかる確認方法を整理や準備する事も進んでいきます。
それは時間あればやってるよ！という声も聞こえてきそうですが、最初から完璧なものはできないのであり、少しずつナレッジを育てていくしか改善は前に進まないかと思っています。
誰に連絡すべきか？についてもおおむね網羅されていいました。
ここに記載ない範囲ですと、サービスを提供しているための他システム連携している他部署や、社外ベンダなどでしょうか。
プロセスのアンチパターン（システム障害対応の失敗プロセス）
色々な事が書いてありますが、中でも「複数の役割を引き受けようとする」「ヒーローになろうとする」という点での感想です。
システム障害対応を素早く対象できる事は、チームの中で尊敬されるべき対象かもしれませんが、顧客やサービス利用者はそんな事関係ありません。
当たり前ですが、システム障害で困っているのはサービス利用者です。システム障害の規模に応じて役割分担を行い、各メンバが最高パフォーマンスを出して頂けるように集中してもらい、チーム全体で立ち向かう事が大事だと思います。
そうなるとそのコントロールをするインシデントコマンダーの位置はとても重要になりますね。
インシデントを解決に導く「インシデントコマンダー」は顧客の事を最優先で考えつつ、
優れたコミュニケーションスキルがあり、高レベルな知識、迅速な意思決定が行える人、専門家の意見を聞き柔軟に計画変更ができる人らしいです。
そんな人に私もなれるよう精進してまいります。
次回以降も数回にわたり、参考になる書籍や考え方などを引き続き共有させていただこうかと思います。
何かございましたら遠慮なく、感想、コメントいただけますと、とても喜んでしまいます。
お読みいただきありがとうございました！
野村浩司
野村浩司：金融システムの開発保守運用と改善を12年担当。7年にわたり合計約 1000 件の障害事例を分析。システム障害対応の改善では、アラートを9割削減。
野村浩司
注目キーワード