障害発生時のウェブサイト運営者のお作法(障害発生時の対応マニュアル)

| コメント(0) | トラックバック(0)


このエントリーをはてなブックマークに追加
ウェブサイト運営者が、障害発生時に行うべきことと、そのフローやプライオリティなどをまとめてみます。

なぜまとめるか? と問われると、理由は特にありません。なんとなく。

しいて言うなら、そこに障害があるから、かな。

サイトの規模としては、技術担当者と運営担当者が別々に存在し、なんらかの外部取引がある状態、障害レベルは中の上ぐらい(影響範囲は大きいが、当日中には暫定的にでも復旧できるレベル)のイメージで話を進めましょう。常に、あるいは断続的にサイトに接続できない、エラーが表示される、著しく表示時間が遅く正常な利用に耐えられないといった状態が継続しているようなシーンを想定します。サイトは、自社運営をベースとしますが、受託の場合の注意事項にも随時触れます。

フローとしては、ざっと以下の流れになりますね。

  1. 障害の検知
  2. 状況、及び、再現性の確認
  3. 一次対応実施
  4. 技術担当者へ連絡
  5. サイト上での告知(障害連絡)
  6. 関係各位へ連絡(障害連絡)
  7. モニタリング、技術担当者との連携
  8. 復旧後、動作確認
  9. サイト上での告知(復旧連絡)
  10. 関係各位へ連絡(復旧連絡)
  11. 恒久対応に関する技術担当者との協議
  12. 関係者各位へ連絡(障害報告)

1.障害の検知

これによって全てが始まります。自分が見つけた場合、他の担当外社員が見つけて連絡をくれた場合、ユーザーからの問い合わせの場合などがあるでしょう。深夜や深酒中に見つけてしまった時は、そのまま気付かなかったことにしてPCの電源を落とそうかな……なんて邪念が働いてしまうこともありますが、ダメです。まず、現実を直視しましょう。

担当外社員が見つけた場合に、誰に連絡をすればよいのかといった交通整理は、日ごろから行っておく必要があります。各サイトごとに、緊急連絡先を2,3名ずつ、連絡する優先順位をつけて用意、共有しておくのが通常ですね。この場合の連絡先は、プロジェクトマネージャのであったり、少し規模の大きな組織であれば、運営責任者、担当者の場合が多いでしょう。

2.状況、及び、再現性の確認

障害っぽいなと思った段階で、すぐに技術担当者に連絡を入れるべきではありません。一時的な不具合である可能性もありますし、何より、具体的な再現性や状況を把握してからでないと、速やかな対応に至りません。また、自分の環境に起因する不具合である可能性も潰しておかなければなりません。深夜に技術担当者に電話して起こしたけど、実は自宅のネット自体が落ちていた……なんてことになると、その後の社内での人間関係にも亀裂が入ります(笑)

この段階で確認すべきことと言えば、ここら辺でしょうか。

  1. 他のウェブサイトの表示確認(自宅インフラによる原因をつぶす)
  2. ブラウザキャッシュのクリア&再起動後の確認、及び、他のブラウザでの確認(ブラウザ依存による原因をつぶす)
  3. 2,3分程度の間、30秒間隔位でリロード時の状況確認(再現性、及び、具体的な不具合状況の確認)
  4. 同サーバに同居している他のドメインのサイトの表示確認(原因がサーバサイドか、アプリサイドかの確認)
  5. サイト内の投稿タイムスタンプの確認(不具合発生時刻、及び継続性の推測)※CGM系サイトに限る

3の段階では、主に、表示系、投稿系、ログイン系などに切り分けて状況確認するとよいでしょう。

3.一次対応実施

多くの障害は、サーバのリブート(再起動)で解決することが多くありますので、障害が発生していることが確実だと判断した場合は、まず、サーバのリブートを実施してみることです。状況によっては、障害状況の確認途中に、何度かリブートを試みる方が良いかもしれません。リブートぐらいは、技術者でなくても用意に実施できますので、日ごろから、リブート方法を確認しておく、操作マニュアルなどを用意しておくなどの準備を怠らないようにしましょう。

4.技術担当者へ連絡

それでも解決しない場合、このタイミングでようやく技術担当者へ連絡をすることになります。深夜や休日でも容赦のない連絡をすることになりますので、連絡時には、細やかな気配り(笑)と、できる限り具体的な状況の報告が必要になります。まずは電話連絡をすべきですが、状況を簡潔にまとめたメールをあわせて送ります。

具体的な連絡項目としては、以下あたりがそろっていれば完璧です。

  • 障害発見者
  • 障害の具体的な内容
  • 障害発生時刻(検知した時間及び、推測される初期発生時刻)
  • 障害発生箇所(全てか一部か。一部であれば、どの場所か)
  • 影響範囲(全ユーザが対象か、ログインユーザのみか)
  • 発生頻度(常にか、断続的に発生し、正常な場合もあるか。)
  • 一次対応実施の有無、実施後の状況
  • 連絡後の自分の動き(サイト上での告知、関係者への連絡の実施有無など)

5.サイト上での告知(障害連絡)

状況の確認が終わり、自分自身が障害復旧に対して直接できることがなくなったら、速やかにサイト上へのアナウンスが必要になります。逆に言うと、自分でも容易に、かつ、速やかに復旧が可能な可能性がある状態では、告知よりも、復旧作業を優先すべきです。この場合は、サイト上でのアナウンスは事後報告になりますし、数分、著しく表示に時間がかかっていた、程度の状況であれば、告知自体を行わないと言う判断もあるでしょうが、これは各サイトの運営ポリシーによります。

さて、この段階では、不確かな要素が多いことが多いため、あまり詳しいことには触れず、障害が起こっているという事実と、その内容、復旧作業に入っている旨ぐらいの告知が定石です。告知後、状況が変わって、正文を出すような形で、下手に二転三転訂してしまうと、逆に不安を煽ってしまうためです。

なお、受託で管理しているサイトの場合は、告知自体の実施権限や判断責任が先方にあることが普通ですので、先に、6の関係者各位への連絡に進む方がベターでしょう。

6.関係各位へ連絡(障害連絡)

ユーザーへの告知が終わったら、速やかに関係者各位へ連絡します。どこまでの範囲に連絡すべきか、などは、各契約に依存する部分ですので、予め、整理しておく必要がありますね。また、日常の業務の窓口としても、営業担当が立っている場合には、営業担当を捕まえて連絡を入れさせるべきでしょうが、つかまらなければ連絡を優先しましょう。

電話連絡が基本ですが、不在の場合は、伝言を残した上でメール連絡すべきです。また、深夜・休日の場合は、メールでの連絡の後、翌営業日の先方の業務開始より少し後ぐらいに、改めて電話連絡します。誠意を見せたつもりで、業務開始時刻ちょうどに連絡すると、全体朝礼をされている時間だったり、バタバタと忙しくしているケースもあり、また、既に障害自体が復旧していることも多いはずですので、プライオリティは若干下げ目の方が、先方にも迷惑がかからないのではないかと思われます。

7.モニタリング、技術担当者との連携

さて、一連のタスクが片付いた後は、待機してモニタリングします。あまりリロードしまくるのは、わずかながらもサーバに負荷をかけるでしょうから自重するとして、10分おきぐらいには、状況をチェックします。

その際、技術担当者とは、電話やメッセンジャーなどで、逐一状況を確認しておく方がよいですが、あまりこちらから声をかけすぎるのは、作業自体の邪魔になりますので、最新の状況や、一次報告時以降に新しく分かった情報などを提供する場合を除き、基本的には受け身のスタンスでいるべきです。技術担当者には、原因が分かった段階、暫定対応完了見込みなどがある程度まとまった段階で、必ず連絡をくれるように伝えておけばよいでしょう。

この段階で、速やかな解決が難しいなどの状況が見えてきてしまった場合は、ユーザーにも、すぐの復旧が難しい旨を、以前の告知に追記する形でアナウンスする必要があります。

8.復旧後、動作確認

技術担当者から、復旧連絡を受けた場合は、まず、自分の環境でも確認を行います。この段階で、実はまだ解決してなかったなんてこともよくある話ですので、二重チェックの意味も兼ねて復旧確認を実施します。

9.サイト上での告知(復旧連絡)

復旧が確認されたら、改めて、サイト上に、復旧の旨と、簡単な原因、実施した対策の報告と、お詫びを行います。

10.関係各位へ連絡(復旧連絡)

その後、関係者各位へも、まずは復旧した旨と簡単な原因や実施した対策についてを連絡します。その際、正式な報告は、後日書面にて行う旨も伝えておくべきでしょう。ここら辺は、お互いの関係性や契約内容によって、必ずしなければならないものでもありませんが、行っておく方が、当然信頼関係は強くなるでしょうから、手間を惜しまずに、きちんと報告を行うべきでしょうね。受託の場合は、サイト上での告知の前に、関係者への連絡をすることになります。

11.恒久対応に関する技術担当者との協議

復旧したとはいえ、暫定対応であることが多いです。技術担当者とは、今回の対応が暫定的なものなのか、恒久的なものなのかを確認し、前者である場合には、今後どういった対応を行うのか、行うのであればいつのタイミングなのか、などを確認します。

12.関係者各位へ連絡(障害報告)

暫定対応に関する協議が終われば、関係者各位へ、正式に報告を行う必要があります。できれば暫定対応完了後、1時間、2時間位はサービスが安定稼働するのを確認した後が良いでしょう。報告書をあげた後にまた同じ障害が……なんてことになると、すぐの連絡が逆効果になってしまうためです。

深夜の障害であれば、翌日中位には、営業時間内の障害であれば、当日中に報告を行うのが通常です。障害報告は、ワードなどで書式を整えて、ほとんどはメール添付などで行う形で許されるでしょうけれど、場合によっては、書面を携えて、日を改めて謝罪に行く必要があるケースなどもありますよね。こういう場合は、だいたい営業担当者さんですが……、御苦労さまです。

まとめ

会社の規模や取引先の有無、数、関係性なんかにもよりますが、流れとしては大体こんな感じでしょうか。ポイントとしては、技術担当者を捕まえる前に行っておくべきことと、対応を引き継いだ後の一連の動きでしょうかね。

特に深夜の障害なんかは、無駄にテンションあがり気味ですけど、落ち着いて、取りこぼしの無きよう対応しましょう。


トラックバック(0)

トラックバックURL: http://www.enjoy-com.com/mt/mt5/mt-tb.cgi/787

コメントする

        

人気エントリー