個人的障害対応心得集 - れれのーとうるとら

この記事は Ubiregi Advent Calendar 2019 13日目のエントリです。

こんにちは、れれのーとです。

気づけばブログを放置して2年強。某スタートアップからさらに転職しまして、ひさしぶりの記事がアドベントカレンダーのエントリです。遅刻しちゃいましたごめんなさい。

さて、アドベントカレンダーといえばクリスマス。クリスマスといえば障害対応。

システムエンジニア時代、華やぐ街の雰囲気にのまれ「障害対応も終わったしケーキでも買っちゃおうかな」とホールケーキを買って帰った思い出がよみがえります。2日間かけて1人で1ホール食べました。

今回は9社経験するうちに培われてしまった障害対応時に意識している心得のようなものを綴ってみます。

違和感をつぶやく

「なんかここがおかしい気がするのでちょっと見てみるわ」とか「なんかここが気になるので見てみている」とチャットでぼそっとつぶやくようにしています。実は障害の予兆だったというときに「そういえばこいつがこんなこと言ってたな」という情報がある状態から障害調査にはいることができます。なにもなかった場合は「ごめん気のせいだった」とつぶやくことになりますが、障害がないということなのでそれはそれでよし。

作業内容を時間軸で記録、共有する

障害が発生したシステムを復旧するために、ここのデータがこうなっていれば辻褄が合うはずだけどーとデータを直接変更したりとか、以前にあった手順を再度行うことが度々発生します。それで復旧すれば問題ないのですが、復旧しない場合がたまーにあります。データでもプログラムでも設定でも、何か変更を行う場合はその変更をいつ行ったか、を記録しておくことで「どういう状態からどういう状態に変化したのか」「その結果どういう矛盾が発生し続けているのか」など解析するのに役立ちます。「こういう変更をするよ」ということを共有することで、周囲からのレビューを受けてもらえる効果もあります。

障害報告書を作成する必要がある場合、「経緯」として障害発生から対応が完了するまでにやったことを記す必要があり、作業記録はその時にも役立ちます。

復旧させてから原因調査をする

障害が発生した時に優先すべきは復旧のはずなのですが、つい原因調査に夢中になってしまうことがあります。復旧に入る前に原因調査に必要そうなものをとりあえず保存して復旧を優先しましょう。なお、これは私が新卒の時に先輩SEからよく言われていたことだったりします。（ホームトレーディングシステムの開発運用で、取引時間内に発生した場合は1秒でも早い復旧が求められるため、本当によく言われていました）

できるだけ一人で対応しない

大規模障害では「障害内容を調査する」「復旧する」「障害が発生した原因調査をする」という他に、他社・他部署からの問い合わせ対応も発生します。一人で対応するのは至難の業ですので、障害対応班と連絡班に分かれて対応することで、障害対応班が復旧作業に集中しやすくなります。

ただし、深夜帯など一人で対応せざるをえない状況になってしまうことがあります。そのような時は作業状況を逐次チャットに流しておくことで、翌朝の対応状況連絡や対応引継ぎの助けになります。（深夜や寝起きのテンションで、うっかり作業ミスをしていないかのチェックを自分で後から行うこともできます）

長期間にわたる障害の場合はクライアントや他部署に一定間隔で連絡をいれる

長期間にわたる障害ではユーザー側も「サービスなしでのオペレーションをどうするか」「（さらにエンドユーザ―がいる場合）エンドユーザーへの対応をどうするか」を決定する必要があります。復旧見込みが立っている場合はそれを伝えればよいのですが、復旧見込みが立てられない場合は1時間ごとなど間隔を決めて（進捗がないとしても）定期連絡をいれるとユーザー側もどう対応するか決定をする手助けになります。また、一定間隔で連絡をいれることで、ユーザー側・システム側双方の問い合わせ対応時間を削減することもできます。

待ち時間がある場合は障害報告書を作成しはじめる

開発・運用会社が自社ではない場合、調査結果連絡までの時間は待ち時間になってしまいます。また、そのような体制で開発・運用を行っている場合、障害報告書の運用があることが多いこともあり、待ち時間中に経緯をまとめながら障害報告書を作成しはじめるようにしています。これをやっておくことで長期化した場合でも「障害報告書（第n報）」「障害報告書（最終報）」など、報告書を速やかに出すこともできるようになります。

監視グラフを毎日見ておく

「障害の兆候発見」に関する心得です。いきなりどーんと障害が発生するケースもありますが、だいたいはちょっとした変化からはじまるケースが多いように感じます。「あれこんなログ見たことあるっけ？」とか「CPUの使用率がなんかよくわからんとこで跳ねてるなー」とか「I/O待ちのキューがいやにたまってるなー」とか。監視ツールが出してくれる各種グラフ、アクセス解析ツールが出してくれるグラフなど、普段の状態のグラフの波形を知っておくだけでも、ちょっとした違いに気づくことができます。

サービスの使われ方を普段から把握しておく

社内向けの障害報告書を作成する場合、ビジネスの損失額の算出を求められることがあります。webサービスの場合、障害発生期間中の想定ユーザー数、想定PV数や販売数などから算出を行うため復旧が完了してから算出します。「土日だからいつもより販売数は少ないはず」とか「昼の時間帯はアクセスのピーク」などの雰囲気を知っていると、おおよその見当をつけることができます。また、運営を担当する他部署などとも障害に対する温度感が合いやすくなるため、会話の波長が合い、協力してもらえるなーと感じることがあります。

障害対応が完了したら「お疲れさまでした」と互いの健闘を称えあって通常モードにもどる

心得ではなく前職のチームでやっていたことの紹介です。前職のチームでは人数が少なかったこともあり、障害発生時は開発の手を止めて全員で調査にあたることもありました。特に誰かがやろうと言って始めたわけではないのですが、障害対応が完了したら「お疲れさまでした」と頭を下げてあいさつをし、通常モードにもどるという流れがありました。切り替えがはっきりするのと、謎の団結感も出るのでおすすめです。

問い合わせ対応をした後で記録を必ず残す

これは今のチームで実施されていることです。どのような内容の問い合わせがあって、どのような手順を行って解決したのか、対応を行わなかったことも含めて、記録として残すところまでが問い合わせ対応として扱われています。これを続けていることで、過去に同様の障害があった時に、対応者以外でも過去の記録を参考にして対応を行うことができています。また、対応しなくて済んだものについても「なぜ対応の必要がないのか」ということが仕様理解につながるため、非常に貴重な情報源となっています。

最後に

障害をいち早く発見し、できるだけ早く復旧状態に持っていくには「システムの全体構成をなんとなくレベルでもよいので把握しておくこと」「普段のシステム状態を知っておくこと」「複数の視点からシステムを見つめること」が大切と実感することが多いです。そもそも障害が発生しないシステムであることに越したことはないのですが、さまざまなシステムと連携することで成立するシステムが多くなっている現在の状況では、障害が発生するのは当然だという前提で開発運用を行っていく方が時代に合っているのではないでしょうか。

心得としてまとめたものを眺めてみると、当たり前のことしか書いていなかったことに気づきましたが、当たり前だからこそ心に留めて行動できればよいのかなと感じました。雀の涙ほどでも参考になったり助けになったことがあれば幸いです。