ウェブサイト及びサーバー監視の プレミアム製品

Server Densityについて

インシデント対応のガイドブックにはどのような内容が含まれていますか

今年の2月に、当社ではすべての運用マニュアルを一元化し、刷新を開始しました。私はいくつかのツールを試してみましたが、Server Density に関するあらゆる情報を保管するためにGoogle Docsを使用することにしました。すべてのインフラの管理についてはPuppetを活用しています。何がインストールされているか、設定、サーバーの管理、フェイルオーバーや配備など、ほとんどすべてのドキュメントを管理しようしていますが、他の文書のドキュメントの管理も必要です。最も重要なのはインシデント対応のガイドブックで、これはアラートが発信された際に、当社の緊急対応チームが対応処理のために確認するすべてのチェックリストです。iPhone サーバー監視のアラート

なぜインシデント対応のガイドブックが必要なのでしょうか?

チームが拡大するにつれて、その場限りのやり方でインシデントに対処する方法をすべてを知っている1人か2人の限られた社員に頼ることができなくなります。システムは複雑化するので、チームのメンバー間で責任を分担して、皆が同じ知識だけ持たないようにする配慮する必要があります。インシデント発生時には、順序だてて正しく対応が行われることが非常に重要です。ここで、いくつかの点に注意を払わねばなりません。:

  • 実行することのすべてを記録します。これは、他の応答者がすぐに状況を把握し、何が行われたかを把握するために重要です。またインシデント解決後に、リビューをすることも重要であり、事後に改善の検討をしていくことができます。

  • 社内及びエンドユーザーとコミュニケーションをとる方法を知る。チームとしてできるだけ効率的であるように心がけてください。しかし、エンドユーザーが何が起こっているか理解できるようにできるだけアップデートした情報を伝えてください。

  • 他のチームメンバーに連絡する方法を知っている。第一対応者が助けが必要であれば、他のチームメンバーにサポートを求めるための迅速な簡単な方法が必要です。

インシデント発生時のストレスもあり、これらをすべて覚えていることは難しいために、インシデント対応のガイドブックが必要になるのです。これは、警告が発せられた時に、いつでもフォローできる明確なステップがまとめられた手短な文書です。Google Docs インシデント対応

インシデント対応のガイドブックにはどのような内容が網羅されるべきでしょうか?

当社のインシデント対応のガイドブックには、以下のような6つのステップが記されており、その理由を含めて詳細をまとめてあります。実際のドキュメントは、複雑な指示をフォローする必要がないように簡潔であるべきです!

  1. JIRAにインシデントをログ記録します 。当社では、プロジェクト管理にJIRAを使用しているので、すべてのインシデントをログに記録することに意味があります。当社では応答者がアラートを受信するとすぐに、インシデント・チケットを設け、その中にアラートの基本的な詳細が含まれます。問題の診断や解決に関するすべてのステップは、コメントとして記録されます。これにより、インシデントを特定のIDによって言及することができ、他のチームメンバーがどのような事象が起こってるか追跡でき、インシデントのフォローアップタスクやまた事後の改善に結びつけることができます。

  2. PagerDutyでアラートを確認。インシデントがログ記録されるまでアラートを認知することがありません。それでは、認知とインシデントがリンクされているからです。これにより、他のチームメンバーは、誰かが間違ってアラーとを認知して、忘れてしまったのではなく、問題が調査されていることを理解することができます。

  3. Hipchatのオプスウェールームにログイン。[当社では、Hipchatを使用しており]、チーム間のリアルタイムのコミュニケーションをとったり、継続中の障害について討議するためだけに、別の「ウォールーム」を使用したりしています。当社ではコックピットルールを使用 これにより、タイムスタンプでソートされて、何が起こっているか理解することができます。時には、話す方がタイプするよりも早いので、何かについての討議やアクションについて調整をする際には、電話に切り替えることもあります。(Google HangoutsはCPUへの負荷が高すぎるので、通常はSkypeを使用します!)。その際にでも、関連のJIRAのインシデントのチケットには詳細をログ記録します。

  4. インシデント対応のGoogle Docsフォルダを検索し、既知の問題を確認。当社では、
    配備されたデバッグの系統または時にオンコールアラートになるような既知の問題のリストを保有しています。ほとんどの場合には、あらゆるタイプのアラートについてのドキュメントがあり、エアーの系列により検索ができ、デバッグのステップなどの正しいドキュメントを見つけることができます。自動スクリプトで解決できるような問題については、できるだけ実際の人にオンコールのアラートを投げかけないようにしており、これらのステップでは問題の原因を追跡するのに役立つデバッグのステップになります。

  5. 問題がエンドユーザーに影響を与えている場合は、 ステータスのサイトに投稿を行う。当社のシステムの設計により、当社の製品に使用に影響を与えるようなインシデントは稀にしかありません。しかしながら、お客様に影響を及ぼすような問題がある場合には、パブリックのステータスのページに投稿します。 当社としてはできるだけ詳細の情報を提供し、何もレポートすることがない場合にも少なくとも30分ごとに分かる範囲でできるだけアップデートを投稿します。自分の問題を公開することは良いことであるという考えは、直感に反することと思われるでしょうが、問題が発生している時に、頻繁にアップデートすることに関して、お客様は概して好意的に反応します。これは問題が頻繁に発生することに言い訳にはなりませんが、問題が発生した際に、お客様は状況を知りたいのです。

  6. 自分で問題を解決できない場合には、それをエスカレートする。応対者が、問題を解決できない場合、当社は障害を引き伸ばすよりは、できるだけ早く手助けをすることを好みます。これは、PagerDutyで第二のオンコールチームへのアラートによりエスカレートするか 他のチームメンバーを直接呼び出すかのいずれかです。

お客様からのメールへの返信

その他に注意すべき点は、問題を報告することで発生するサポートチケットについてです。必然的に一部のお客様は、パブリックステータスページを認識しておらず、彼らは直接任意の問題を報告します。当社では、 Zendeskは活用し、最初のチケットを「問題」として設定し、お客様を当社のステータスページに誘導します。以後の任意のチケットはその「問題」の「インシデント」として設定され、当社が問題を解決する際には、すべてのリンクされたチケットの一斉返信を行うことができます。ステータスのページから同様の情報が得られない場合、お客様へのメール発信も実践すべきことです。

ガイドブックにはどのような内容が含まれるべきですか?

各企業は、それぞれ異なるやり方でインシデントを処理します。当社は長年の経験に基づいて、他の企業がどのように対処し、自社のサービスに一時停止が発生した場合の感情などを理解しながら、プロセスを構築して来ました。一時停止を防ぐために多くのことを実行できますが、それを除去することはできません。従って、それらを処理するためのプロセスを計画するために多大な時間を費やす必要があるのです。インシデント対応のためのプロセスが御社にはありますか?是非とも、コメントを聞かせてください!