障害発生時に被害を最小限にするための第一歩
こんにちは、Kouyizです。ナビタイムジャパンで各サービスの品質マネジメントを組織横断でサポートするチームを運営しています。
障害（インシデント）
様々なサービスを運用していると、システムの欠陥やハードウェアの故障等によって障害が発生することがあります。
本番提供中のサービスの機能不全、およびサービスに影響はなくてもサイバー攻撃など緊急対応が必要な事象を当社では「障害」や「インシデント」と呼んでいます。
障害の例としては、スマートフォンアプリで経路が検索できなくなったり、PCブラウザ向けの地図が表示されなくなったりといった事象です。
お客様にサービスを提供する側として絶対に壊れない仕組みを作るのが理想ではありますが、細心の注意を払って対策を行っていてもインターネットやクラウドサービスの障害など防ぎきれない要因も存在します。
障害発生時に一番大事なこと
障害の影響をできるだけ小さくし、お客様のご不便・不利益を最小限にすることが重要なため、障害が発生した際は早期復旧（被害を軽減するための対応も含みます）を第一としています。
何を一番最初にすべきか？
サービスをいち早く復旧するために何を一番最初に行うべきでしょうか？
発生原因調査
影響調査
関係者への連絡・周知
修正方法の検討
修正作業
当社ではまず最初に関係者への連絡・周知をすることとしています。
具体的には障害らしき事象を検知した際は、slackで全社共通の障害連絡チャンネルに通知するルールを定めています。
チャンネルに投稿するのは障害が発生したサービスの開発担当者だけでなく、カスタマーサービス担当者やたまたま事象を見つけた人など誰でも投稿できます。
なぜ連絡を最初に行うのか？
まずは調査の前にわかっている目の前の事象をありのままに連絡して情報共有します。
情報共有を最初に行う理由ですが大まかに分けると３点あります。
影響が他サービスにも及んでいるケースがある
あるサービスで障害が見つかった際に、他のサービスでも同じ事象が発生しているケースがあります。
内部で同じシステムを参照していた
同じ欠陥が存在するバージョンのライブラリを使っていた
Android/iOS等の特定のOSバージョンに共通する不具合があった
利用しているクラウドサービスで障害が発生していた
など、サービス間で共通する要因で発生する可能性があります。
この可能性を排除しないと、あるサービスで障害を検知して個別に復旧対応した事象が、実は他の複数サービスで発生し続けていた。といったことが起こります。
各サービス・機能の担当者が同時並行で影響を確認することで、サービス全体として障害が長引く可能性を取り除くことにつながります。
発生原因は最初から特定できない
復旧対応をするにあたって、障害の発生起因、つまり何がきっかけで発生したか？を調査する必要があります。
例えば時刻表が表示されない障害を検知したら、その前にどんなリリース・デプロイがあったか？を調べます。
発生原因はサーバーやスマートフォンアプリのプログラム、データ、インフラなどさまざまな箇所に存在する可能性があります。各開発担当者に連絡して同時並行で調査することで原因箇所の特定までの時間を短くできます。
障害に関係するリリース物が特定できれば、まず切り戻し対応をその影響も含めて検討して、可能であれば切り戻し作業を行います。
この際、成果物間の依存関係を把握した担当者が対応に加わることで作業が迅速化するだけでなく、さらなる障害を引き起こす可能性を減らすことができます。
お客様への情報提供をリアルタイムに行う必要がある
障害が発生したら、復旧作業と並行して、お客様に状況を整理して事象の詳細や復旧予定などをご説明する必要があります。
その際にカスタマーサービス担当がリアルタイムにキャッチして必要な情報を提供する準備にとりかかります。
またお客様からいただいた情報も復旧対応に大変有益です。
いつから起こっているか？どんなスマートフォンを利用されているか？など開発担当へ連携することで発生要因の特定を早期化することができます。
実際の運用について
障害連絡チャンネル内ですべてのやり取りを行うと、必要な情報の把握がしづらくなるので、第１報に連なるスレッドを立ててその中でやりとりすることが多いです。
必要に応じてより専門的なチャンネルへのポインタを用意して、そこで調査・議論した結果をスレッドに投稿します。
障害が復旧した等大きな進展があった場合は障害連絡チャンネルにも投稿して状況を共有します。
障害を調査する過程では仮説や結果的に誤りだった情報も混在するので、錯綜を防ぐために、確定した情報をJIRAで管理している障害チケットに記載していきます。このチケットは再発防止策検討の際にも活用します。
また、検証環境の障害については別の共有チャンネルを用意して情報が錯綜しないようにしています。
DiRT・障害対応演習を実施する際もこちらのチャンネルを利用しています。
障害連絡の心理的ハードル
障害報を通知する際は自分が原因でなくてもやはり少し緊張します。
ネガティブな報告をすることで自分に悪いイメージがつかないか心配にもなるでしょう。
報告をした人を責めるような雰囲気があればなおさらそうだと思いますが、そういったことを社内で耳にしたことはありません。
実際に第一報を投稿している人を何名か見てみると社内では信頼されている人ばかりです。障害を通知した人はまさに一番槍、火中の栗を拾える人というイメージを持たれるように思います。
通知した時点でサービスに貢献できるという美味しい役割ではないでしょうか。
障害報告～復旧のスピードを向上させるために大事なことは社員全員が当事者であることです。
「障害」にあたる事象かどうか判断できない場合であっても、まずは障害連絡チャンネルに通知することを推奨しています。
どういったことが起こっているのか、たとえサービス担当者でも最初はわからなくて当然で、情報を共有すれば不明点は周りの人が埋めてくれます。
さいごに
今後も引き続き障害対応のボトルネックを取り除く環境づくりを行っていきます。
書かせていただいた内容は全社共通の開発ガイドラインにもより詳しく載せています。
皆様の移動をサポートするサービス提供者として、障害を未然に防ぐとともに、発生したとしても早期に復旧できるように全社一丸となって改善を進めてまいります。