> [!abstract] > テストは信頼性に対するシステムの確信度を定量化する手段である。従来型テスト（ユニット・インテグレーション・システム）と本番テスト（設定・ストレス・カナリア）を階層的に組み合わせ、MTTR の短縮と MTBF の延長を実現する。大規模環境では統計的テスト手法やブレークグラス機構を導入し、設定ファイルにもコードと同等のテスト厳密性を求めることで、高速かつ安全なリリースサイクルを維持する。 ## 書誌情報 - タイトル: Testing for Reliability（Chapter 17） - 著者: Alex Perry, Max Luebbe（編集: Diane Bates） - 書籍: [[SRE Book]]（Site Reliability Engineering: How Google Runs Production Systems, O'Reilly, 2016） - URL: https://sre.google/sre-book/testing-reliability/ ## テストと平均修復時間の関係 テストの通過は信頼性を保証しないが、テストの失敗は信頼性の欠如を証明する。システムレベルのテストがバグの本番到達を完全に防止できれば、MTTR（平均修復時間）はゼロになる。テスト品質の向上は MTBF（平均障害間隔）を延ばし、結果としてより高速なフィーチャーリリースを促進する。 ## 従来型テスト テストは階層的に構成される。 ### ユニットテスト 最小の単位で個々の関数やモジュールの正しさを検証する。テストピラミッドの土台であり、高速なフィードバックループを提供する。 ### インテグレーションテスト コンポーネント間の連携を検証する。依存性注入（Dagger などのフレームワーク）を用いて複雑な依存関係をモックに置き換え、テストの独立性を確保する。 ### システムテスト システム全体をエンドツーエンドで検証する。以下の 3 種類に細分される。 - **スモークテスト（smoke test）**: 基本的な機能が動作するかの健全性チェック。複雑なテストに入る前の門番として機能する。 - **パフォーマンステスト（performance test）**: 開発サイクルを通じてシステムの効率が劣化しないことを確認する。 - **リグレッションテスト（regression test）**: 過去に修正したバグが再発しないことを保証する。 ## 本番テスト 本番環境と相互作用するテストであり、ブラックボックスモニタリングに類似する。 ### 設定テスト 実際の本番設定がバージョン管理された仕様と一致するかを検証する。設定の誤りは障害の主要な原因であり、コードと同等のテスト厳密性を要する。 ### ストレステスト システムの破壊点と障害閾値を特定する。想定負荷を超えた際のシステムの振る舞いを把握し、容量計画に活用する。 ### カナリアテスト 全体展開の前にサーバのサブセットで新バージョンを検証する。「バイナリを焼く（baking the binary）」と呼ばれるインキュベーション期間を経て、段階的にロールアウトする。障害の次数（U）によってカナリアでの検出可能性が異なり、U=1（単一リクエストに影響する障害コード）は線形に検出可能だが、U=2（将来のリクエストに影響するデータ破壊）以上は検出が困難になる。 ## テスト・ビルド環境の構築 バージョン管理されたソースコントロール、継続的ビルドシステムの導入、そしてビルド破損を最優先で対処する文化が不可欠である。Bazel のようなビルドシステムは依存関係の追跡と選択的テスト実行を可能にし、テストの実行速度を向上させる。 ## 大規模テスト ### スケーラブルなツールのテスト SRE ツールはメインストリームの API 外で動作するため、独自のテスト戦略が必要である。バリア防御（barrier defense）を用いて、リスクのあるソフトウェアがユーザ向けレプリカにアクセスすることを防ぐ。 ### 災害テスト オフラインツールはチェックポイント状態の計算により比較的容易にテストできる。オンライン修復ツールはより高度なアプローチを要し、統合された計装済みバイナリの使用が有効である。 ### 統計的テスト ファジング、Chaos Monkey、Jepsen などの手法は再現性がないが、ランダムシードの記録、重大度の洞察、フレーキーテストの特定を通じて価値を提供する。 ### テスト速度と信頼性 21,000 以上のテストを持つ環境では、偽のリジェクトを避けるために個々のテスト信頼性は 99.9999% 以上が必要である。コンテキストスイッチングのデッドラインがテスト実行の優先順位を左右する。 ### 設定ファイルの分類 設定ファイルは変更頻度に基づいて 2 種類に分類される。 - **MTTR 削減型**: 変更頻度が低く、障害時の修復時間短縮に寄与する - **リリース状態型**: 変更頻度が高く、リリースサイクルと連動する ### ブレークグラス機構 緊急時にリリーステストを迂回するための仕組みである。テスト優先度の引き上げ（priority boosting）と併用し、緊急プッシュの安全性を担保する。 ## 本番プローブ 既知の正常リクエストと既知の異常リクエストをプローブとして使い、本番環境をモニタリングする。フロントエンドとバックエンドの独立したリリースサイクルにより、以前はテストされていなかった設定の組み合わせが発生するため、プローブによる検証が不可欠である。フェイクバックエンドバージョンを用いることで、異なるコンポーネントの組み合わせを体系的にテストできる。 ## ハーメティックテスト ハーメティックテスト（hermetic testing）は、本番環境の変化から隔離された自己完結型のテスト環境である。しかし、フロントエンドとバックエンドの独立したリリースサイクルや段階的ロールアウトにより、完全なハーメティックテストは実質的に不可能である。 ## 実践的指針 - テストピラミッドに従い、ユニットテストを最多に、システムテストを最少に配分する - 設定ファイルはコードと同等のテスト厳密性で扱い、変更頻度による分類を行う - カナリアテストでは障害の次数（U）を考慮し、段階的ロールアウトの速度を調整する - 統計的テスト手法（ファジング等）を従来型テストの補完として導入する - ブレークグラス機構を整備し、緊急時のリリースパスを確保しつつテストの優先度を維持する - 本番プローブを常時稼働させ、リリースサイクルの隙間で生じる未テスト設定を検知する - ビルド破損は最優先で対処し、テスト基盤の信頼性を担保する ## 関連 - [[@2016__OReilly__SRE Book - Chapter 1 Introduction]]: SRE の基本原則 - [[@2016__OReilly__SRE Book - Chapter 6 Monitoring Distributed Systems]]: モニタリングとテストの関係 - [[SRE Book]]: 書籍全体 - [[SRE]]: サイトリライアビリティエンジニアリング ## 出典 - Perry, A. and Luebbe, M., "Testing for Reliability," in *Site Reliability Engineering: How Google Runs Production Systems*, Beyer, B. et al. (eds.), O'Reilly, 2016.