インフラエンジニアのための障害対応と顧客報告

スピーカー：じょぶずさん

障害対応タスク(よくある例)

お客様にWEBサーバのダウンのご報告
ログを見て状況調査
調査結果から、原因の特定と復旧策の検討
復旧作業
WEBサービスが利用できるか確認
お客様に復旧のご報告

「WEBサーバダウンの報告」？「復旧のご報告」？本当にこれでよいのでしょうか・・・

イケてる障害報告をするために

意識したい４つのこと

（1）あなたは何のインフラを管理しているのか

お客様のWEBサービスなのか
お客様の業務サービスなのか
自社の　〃

など

（2）稼働しているサービスは？　

ゲーム
ショッピングサイト
金融サービス
動画配信サービス

稼働しているサービスにより求められえる正確性、スピードが異なります

（3）サービスが停止するとどうなるのか？

損害の報告にも関わってくるいつどこに何が起きたのか、記録を取ることが大事

（4）お客様への影響は？

具体的にお客様は何ができなくなるのか

第一報の時点でここがわかるのが「一流のインフラエンジニア！」

例

何のインフラ？
- お客様のWEBサイトと周辺サービス
稼働しているサービスは？
- 一般消費者向けWEBサービス
停止すると？
- 一般消費者がサービスを利用できない
お客様は？
- 利益が落ちる。信用低下による解約も

エンジニアとしてはサービスを再起動すれば直るでしょう？思いがちですが、お客様はそれでは納得しません。

悪い例

初報

サーバ障害によりWEBサーバダウン
SSHログイン不可、ping応答あり

続報

〇時〇分に復旧済み

これでは、サービスが利用できるのか、できないのかがわからない。 SE視点の報告でありわかりにくい

改善例

初報

現在、システム障害により〇〇サイトの〇〇がご利用いただけない状態です。
復旧目処は〇〇：〇〇を予定しております。

続報

〇〇：〇〇に復旧し、通常通り〇〇をご利用いただける状態となっております。
原因の特定及び、再発防止策の検討につきましては、追ってご報告させていただきます。

以下のような細かい報告もあると良い(続々報でも)

発生時刻
検知時刻
関連サービスへの影響
復旧時刻
再発防止策

さらにやっている感をだす

何をして復旧させたのか

WEBサーバの再起動

原因はなんだったのか？

アクセス増により子プロセスが増殖し、サーバリソースを使い果たしたため

再発防止策は？

サーバ性能を上げ、増殖には制限をかける

(余談)急いで復旧させたい気持ちはわかります。しかしながら原因がわかるまでは復旧対策は控えること！状況が悪化する可能性があります。ヒューマンエラーの再発防止策を立てるのはきわめて難しいです・・・

まとめ

障害報告では、お客様のサービスへの影響範囲を必ず確認する

障害内容(技術的内容)よりもサービスへの影響を優先する

復旧報後、落ち着いてから原因と再発防止策を報告する

質疑応答

Q.原因分析のなぜなぜは何回ぐらいくりかえしますか？ A.3～5回？

Q.障害回避のチェックシートは作るべき？ A.報告の際にこれとこれはやっていたという免罪符にもなるのであったほうが良い

Q.ありがちな障害は？ A.新機能リリースの際に既存サービスが動作しなくなるパターンなど

Q.障害検知から初報までどのくらいの時間がベストか A.短ければ短いほど良い。検知の定義は先にしておいた方が良い

Q.調査、解析はヒューマンスキルに依存してしまうことがありますか？ A.あります。サービス運用経験等によります。

Q.お客様に直接頭を下げに行ったことはありますか？ A.ヒューマンエラーにより大きな損害が生じた場合等は部門長が謝罪にいくこともあります。

Q.障害範囲の洗い出しに時間がかかることがありますが、これを改善するには？ A.フローチャート、ネットワーク構成するホスト一覧、ホスト名とかIPアドレス帯をキーに索引できるように全部リストするなど資料を作っておく。

Q.原因調査に時間がかかってしまう場合に調査時間を削減するのはお客様にとって善？ A.なぜ原因調査に時間がかかるのかの説明が不足している可能性があるので、それを解消する

Q.設計構築の資料を運用会社も知っておいたほうが良い？ A.責任範囲を明確にするためにあまりお勧めしない