ロンドンを拠点にサーバモニタリングを提供するServer Densityで，CEOを務めるDavid Mytton氏が，DevOpsDays Amsterdam 2015の観衆に対して，同社がインシデントや機能停止を扱う方法を公開した。同社ではインシデントへの対応プロセスを，準備(preparation)，対応(response)，事後(post-mortem)の３つに分解している。プロセスは，頻繁な公式アップデート，対応アクティビティのログ取得の徹底，チーム活動と効果的エスカレーションという，一連の重要原則に基づいたものだ。
準備
バランスの取れたインシデント対応の最初のステップは，インシデントや機能停止に備えることだ。
Server Densityのオンコール対応では，業務時間外にプライマリとセカンダリの２レベルのエンジニアを配置している。第１のレベルは全エンジニア間で毎週ローテーションするが，第２のレベルはOPSエンジニアのみでローテーションする。第１のレベルのエンジニアが問題を解決できなかった場合，OPSエンジニアの支援が必要になるというロジックだ。業務時間内においては，OPSエンジニアが最初にアラートを処理する。時間外のインシデントがあった場合，第１レベルのエンジニアはその後24時間のオフコールを取得する。疲労による問題発生を防止し，社会的ないし健康的な問題を最小限に収めるためだ。
Mytton氏はドキュメントの重要性を強調する。もっとも重要なソースはコンフィギュレーション管理コードである。これは，インフラストラクチャのセットアップに関する最新の変更を理解する上で役に立つ。しかしドキュメントがアクセスおよび検索可能で，適切に更新されていることも必要だ。 最も重要なのはインシデント対応ガイドである。これはオンコールチームがアラートを受ける度に実行すべき項目を記した，ステップ・バイ・ステップのチェックリストで，氏がインシデントの防止と解決の方法として，ルーチン活動にも多数のチェックリストを用いる航空業界からヒントを得たものだ。
準備には，予期せぬことに備える，という意味もある。ドキュメントは，運用システムと同じインフラストラクチャにホストされていないだろうか？もし，そのインフラストラクチャがダウンした場合はどうなるのか？オフィスのインターネット接続が失われたらどうする？サービス停止中に，ユーザサポートの主要インフラストラクチャがダウンしたら？Mytton氏は，ある会社がデータセンタを失った(トラックがその建物に突っ込んだ)ために，クライアントからのコールがサポートサービスに殺到した例を紹介した。
そして最後に，オンコールエンジニアは，チームやベンダの連絡先などの重要情報を知っておく必要がある。
インシデント対応
インシデントによってアラートが起きた場合，オンコールエンジニアは明確に定義された手順に従う。インシデントの効果的かつ迅速な解決には，明確に定義された手順が不可欠である，とMytton氏は言う。同時にそれは，企業の成長に合わせて新しいエンジニアにオンコール業務を拡張するための，唯一の手段でもあるのだ。
まずインシデント対応チェックリストを開く。そしてOps War Roomにログオンする。この手順も航空業界にインスパイアされたものだ。その目標は，エンジニアが外部からの邪魔されずに，インシデントに対して完全に集中することにある。そしてJIRAのイシューをオープンする。このイシューで，インシデントに関する全エンジニアのアクティビティを追跡するのだ。情報のラジエータとして機能する以外に，この後にくるポストモータムな活動にも影響を与える。その後で始めて，エンジニアがインシデントの調査を開始できる仕組みだ。
インシデントがエンドユーザに影響する場合，Server Densiyではステータスページを使用して，問題の最新状況を伝えるようにしている。可能な限り詳細に記述し，新たな内容がなくても30分毎にアップデートをポストする。ユーザに絶えず情報を通知し，信頼を維持することが目標だ。ステータスページに気付かないユーザは，Eメールユーザサポートに申し込むことで，問題解決時には全員にリプライが返信される。
事後
最初のステップは，インシデントの１ないし２日後に行われる事後検討である。直後やそれ以降に実施しない理由は，状況がまだ流動的であったり，あるいは遅過ぎると記憶があいまいになるからだ。アクティビティをすべて記録したJIRAイシューは，何が起きたのかを適切な技術的詳細情報とともに説明する上で，大きな役に立つ。どの程度の技術的な詳細情報が適当かを決めるには，対象となるユーザを知ることが重要だ，とMytton氏は述べている。
３つの質問に答えることが重要だ。何が故障したのか？ なぜ故障したのか？どうすれば修正できるのか？Mytton氏は事後検討の例として，建設作業員が光ケーブルを切断したのが原因でデータセンタプロバイダがダウンした場合の，インシデントでの報告について説明した。