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

Server Densityについて

インシデント、ダウンタイム、機能停止への対処法

機能停止やダウンタイムは避けることができません。障害に対処できるようにシステム設計が、ほとんどの問題への対応を可能にする現代のインフラストラクチャー·アーキテクチャーの重要な部分ですが、全く考えていなかったようなインシデント、見つけられなかったソフトウェアのバグ、サービスのダウンタイムにつながる出来事が起こります。

Microsoft, AmazonやGoogleは四半期ごとに数億ドル越える費用を費やしていますが、それでもシステムの一時停止は起こります。皆さんはどのくらいの費用を費やしていますか?

常に問題を抱えて、不必要に苦しんでいるような企業もいくつかあります。定期的な機能停止は、最終的には受け入れられなくあります。しかし、いくつかの重要な原則を採用し、適切にシステムを設計していれば、顧客によって許されるようなサービスインシデントが少なくなります。

ステップ1: プランニング

重要なアラートがパニックと混乱につながるのであれば、インシデントに苦しむに値します!何か間違いが起こる場合、事前にできることのいくつかのことがあり、チームのメンバーが何をすべきか分かるようにできます。

  • 正しいドキュメントを用意する。これは検索可能で、簡単にアクセスできるようにし、常に最新の状態にする必要があります。当社はこのためにGoogle Docsを使用しています。.
  • 適切な設定管理を使用する。それが、Puppet、Chef、Ansible、Salt Stackまたは他のシステムが制御された方法でインフラストラクチャーに多数の変更ができるようにします。セットアップを定義するコードに簡単にアクセスできるので、チームは新しい問題を理解するのに役立ちます

予期せぬ障害

システム全体に注意を払ってください。予期しない障害が意外な場所から出てくることがあります。AWS上でホストしていますか?機能停止となって、内部通信にSlackやHipchatを使用する必要がある場合はどうなりますか?Googleクラウド上でホストされていますか?Googleクラウド停止中にGmailが使用できない場合どうなりますか?今、住んでる都市内のデータセンターを使用していますか?そこで天候の問題や電話サービスが停止した場合はどうなりますか?

ステップ2: アラートの対処の準備をする

通話を嫌いな人もいれば、好きな人もはいます!どちらにしても、コールローテーションに対処するためのシステムが必要であり、チームのメンバーに問題をエスカレートしたり、到達可能性

pagerduty-on-call-calendar

を計画したり、インシデント後にオフコールに行く許可をします。 当社のチームではウイークリーのローテンションでPageDutyを使用しており、 誰が手があいているか、インターネット接続、病気、休日などを考慮し、問題を迅速に解決できるように、製品エンジニアリングのチームで起きてる人がループができるようにしています。

より多くの機能停止は、単一のものだけでうまくいかなくなることはないので、生産に入るソフトウェアのバグによって引き起こされています。– ダウンタイムを引き起こすことになる問題のカスケードそのため、フロントエンドエンジニアリングなど異なるチーム間でローテーション必要とします。それはオペレーションだけではありません。

ステップ 3: チェックリストを使用して、対処する

アラートが鳴ったら、うまく実行できるようなしっかり定義されたプロセスを持つことが大切です。  チェックリストを使用することで、不要な思考を削除でき、本来の問題に集中できるようになり、キーとなるアクションがとられているか、忘れられていないか確認できます。 内部と外部の両方に通信のチャネルを持っていることが必要です。 – 顧客のサービスがダウンしていて、その問題に取り組んでいるのかかいないのか見当がつかないほどで悪いサービスはありません。

Google Docs Incident Handling

ステップ 4: 事後分析をまとめる

これは信頼を取り戻すためのいい機会です。上記の手順に従い、機能停止時に正確で有益な情報を提供して、人々は何が起こっているか知ることができ、またまとめをするいい機会であり、何が起こったのか説明し、何が決定的に悪かったのか、同じことが起きないように何をするかまとめます。機能停止は、未知のシステム上の欠陥を明確にし、欠陥がもう存在しないか欠陥に対処している途中であることをユーザーに伝えることが重要です。

インシデント、ダウンタイム及び機能停止のビデオ

当社ではインシデント、ダウンタイムと機能停止のベストプラクティスについて、Yelpの Charlie Allom氏 (ネットワークエンジニア) and Brian Trump氏 (サイト信頼性エンジニア)を招いて オープンディスカッションを開催しました。小さな会社とはるかに大きい会社を対比し、以下のようなことに対処する方法を話しました。:

  • オンコール-ローテーション、スケジュール、システム、ポリシー
  • ダウンタイムへの準備 –チーム、システム、製品、アーキテクチャー
  • ドキュメント
  • チェックリストとプレイブック
  • 実際にいかにインシデントに対処するか
  • 事後分析

このビデオは英語版ですが、こちらでご覧いただけます。.