Googleは障害に順位と指揮官を与えた、消防の現場から借用して

2000年代初頭までに、Googleのデータセンターの規模は従来の運用モデルを超えて拡大していた。従来のモデルでは、サーバーが増えればより多くのオペレーターを雇うことになっていた。2003年に本番運用を担当するために招かれたベン・トレイナー・スロスは、その比率で採用を続けることは費用面でも人材確保の面でも現実的ではなく、また障害は場当たり的に処理されていた——最初に呼び出された者が即興で対応し、軽微な一時的障害と全社的な障害を区別する一貫した方法がなかった——と判断した。

ソフトウェア運用には、消防署のような階級構造に相当するものがなかった。アラートは発報するかしないかのどちらかであり、あらゆるインシデントが規模に関係なく同じ未分化な注意を奪い合っていた。伝統的なシステム管理者ではなくソフトウェアエンジニアで構成されたトレイナーのチームは、これを人員の問題ではなくエンジニアリングの問題として扱った。

サイトリライアビリティエンジニアリングは、深刻度レベル、ページングの階層、そしてインシデントコマンドの役割を、緊急サービスから意識的に模倣して正式化した。

消防署のインシデントコマンドシステムを借用した。深刻度の階層に加えて指揮官とリードを置くことで、対応が影響の大きさに応じて拡張されるようにした。

深刻度の階層がなければ、あらゆるアラートが同じ対応を引き起こし、軽微な問題に注意を浪費し、深刻な問題にはリソースが不足する。

事前に割り当てられた役割（インシデントコマンダーなど）が混沌を組織的な対応に変えるため、労力が実際の影響に応じて拡張される。

緊急サービスから実証済みの構造を借用することで、調整システムをゼロから発明することを避けられる。

あらゆる問題が同等の注意を奪い合っているときは、プレッシャー下での調整をすでに解決している領域から、段階的な深刻度スケールと事前に割り当てられた指揮役割を借用せよ。

SEVレベルとインシデントコマンドは現在、ソフトウェア業界全体で標準的な実務となっている。Googleのインシデントフレームワーク（IMAG）は、消防署のインシデントコマンドシステムの上に明示的に構築されており、宣言されたすべてのインシデントに対して指定されたインシデントコマンダー、コミュニケーションリード、オペレーションリードが置かれる。