SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム

32章進化するSREのエンゲージメントモデル

執筆：Acacio Cruz、Ashish Bhambhani

編集：Betsy Beyer、Tim Harvey

32.1　SREのエンゲージメント：その対象、方法、理由

本書で述べているのはすでにSREがサービスを受け持っている場合のことですが、本章ではSREがサービスを受け持つ前の事柄について述べます。ライフサイクルの最初からSREの支援を受けているサービスは少なく、サポートを開始するには、サービスを評価してSREのサポートに値するかを確認し、SREのサポートの妨げとなる問題の改善方法を交渉し、実際のSREのサポートを開始するためのプロセスが必要になります。私たちは、このプロセスをオンボーディングと呼んでいます。既存のサービスがたくさんあり、それらの完成度がまちまちな状況であれば、最も高いレベルの目標を達成できるようになるには、SREチームはかなりの時間をかけて優先順位付けをして順番にオンボーディングをしていかなければなりません。

そういった状況は普通のことであり、上に述べた手順も既存の環境への対処方法として妥当なものではありますが、古いサービスにも新しいサービスにも同じようにプロダクション環境に関する英知やSREのサポートを提供できるもっと良い方法が、少なくとも2つあります。

1つ目の方法は、単にソフトウェアエンジニアリングの場合と同じです。すなわち、バグが見つかるのが早ければ早いほど修復のコストが低くてすむのと同じように、SREチームのコンサルテーションが早い段階で始められるほどサービスの質は高くなり、メリットが早く感じられるようになります。SREが設計の早い段階で関わることができれば、オンボードまでの時間は短くなり、サービスは「門をくぐった」直後から信頼性の高いものになります。これは通常、最適とは言えないような設計や実装をやり直すことに時間を取られずにすむためです。 ...