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

17章信頼性のためのテスト

執筆：Alex Perry、Max Luebbe

編集：Diane Bates

まだ動かしたことがないのであれば、それは動かないものとみなすべきだ。

——よみ人しらず

SREの主要な役割の一つは、担当するシステムの信頼度の数値化です。SREは旧来のソフトウェアテストの手法を規模を拡大して適用することによって、これを行います†1。信頼度は過去の信頼性と将来の信頼性の両方から計測できます。前者は時系列のモニタリングシステムの挙動データを分析することで、後者は過去のシステムの挙動に関するデータから予測することで数値化できます。とはいえ以下の条件のうち少なくとも1つが満たされなければ、これらの予測は十分有用であるとは言えません。

• 対象期間において、そのサイトに対するソフトウェアのリリースがなく、サーバー群にも変更がないこと。これはすなわちその期間、そのサイトがまったく変更されていないということで、将来の挙動が過去の挙動に近いものになるということを意味します。
• サイトに対するすべての変更が完全に明らかになっていること。これは、それぞれの変更によって生じる不確実性を許し、その分析をするのに必要です。

テストとは、変更が生じたときにある領域における等価性を示すための仕組みです†2。変更前後の双方で同じテストが通ったら、許容しなければならない不確実性が分析によって減ったということです。徹底したテストは、対象のサイトの将来の信頼性を十分詳細に予測しやすくなるので、実際に役立ちます。

実施しなければならないテストの量はシステムに求められる信頼性によります。テストがカバーするコードベースの割合が高まるにつれて、変更によって信頼性に不安が生じたり、信頼性が低下する可能性が減ります。テストのカバレッジが十分であるということは、信頼性が許容できる範囲において、より多くの変更を加えることができることを意味します。ただしあまりに大量の変更を短期間に投入しすぎれば、予想される信頼性が許容限界に近づきます。そうなった場合には、新しいモニタリングデータが蓄積されるまで変更を止める方が良いでしょう。蓄積されたデータはテストのカバレッジを補完してくれるものであり、変更された実行パスに対して主張された信頼性を裏付けてくれます。サービスを利用するクライアントがランダムに分散しているなら ...