# レディネスレビュー (Readiness Review) ## 定義 レディネスレビューとは、サービスが本番運用に耐える準備状況を判定するために Google が用いる審査の仕組みで、ローンチレディネスレビュー(Launch Readiness Review = LRR)と引き継ぎレディネスレビュー(Handoffs Readiness Review = HRR)の2種からなる。開発グループが自サービスをプロダクションで自己管理する段階から、集中型の運用グループ(SRE)による管理へ移行するまでの間に位置し、LRR は「サービスが実際の顧客とやり取りしてプロダクションの現実のトラフィックに乗るために満足しなければならないローンチ要件」を、HRR はその先の運用引き継ぎの準備状況を判定する。判定項目は次の6つである。 1. **欠陥のカウントと重大度** — アプリケーションは実際に設計通りのパフォーマンスを発揮しているか 2. **ページャーへのアラートのタイプと頻度** — プロダクションでサポートできない数のアラートを発生させていないか 3. **モニタリングのカバレッジ** — 問題発生時にサービスをリストアするのに十分か 4. **システムアーキテクチャ** — プロダクションで高頻度の変更やデプロイをサポートするのに十分な疎結合となっているか 5. **デプロイプロセス** — 予測可能で決定的な、十分に自動化されたプロセスが存在しているか 6. **プロダクションのハイジーン(衛生管理)** — プロダクションのサポートを他者に管理させられるだけの十分に優れた習慣が確立されている証拠はあるか これに加えて、収益規模(SOX法404条該当性)・ユーザートラフィック規模と障害コスト・個人情報の保存の有無・輸出規制やPCI-DSS/HIPAAなどのコンプライアンス要件、という規制・コンプライアンス上のリスク評価も同時に行われる。レビューで欠陥が見つかった場合、運用エンジニアは機能チームによる問題解決やサービスの作り直しを支援する。(Source: [[@2021__OReillyJapan__SREの探求 - Chapter 11 DevOpsの幅広い実践現場で活用されているSREのパターン]] §11.2) 出典元は Tom Limoncelli による講演 "SRE@Google: Thousands Of DevOps Since 2004"(YouTube、USENIX、2012年1月12日)であり、Limoncelli 自身は「最高の条件が揃えば、プロダクトチームは LRR のチェックリストをガイドラインとして使用し、その履行に取り組むのと並行してサービスを開発し、必要な場合には SRE に支援を要請します」と述べる。HRR でプロダクションの承認が最も早いチームは、設計段階からローンチに至るまで SRE と最も早くから協力していたチームである、と Limoncelli は 2016 年に補足している。(Source: [[@2021__OReillyJapan__SREの探求 - Chapter 11 DevOpsの幅広い実践現場で活用されているSREのパターン]] §11.2) ## 横断的知見 - 本 concept は現時点で単一ソース(『SREの探求』11章)のみに基づく。11章は本書自体が『The DevOps Handbook』からの抜粋・編集であるため、原典である The DevOps Handbook(2016年)や、引用元講演("SRE@Google: Thousands Of DevOps Since 2004")が別途 wiki に取り込まれた場合は、複数ソースの突き合わせが可能になる。それまでは本節を空欄にせず、単一ソース内で観察できる構造的な対応関係を記録するにとどめる。 - **LRR/HRR の判定項目(6項目)は、Colyer(2016)がオペラビリティの第1段階として位置づける「運用性のための設計」を、具体的なゲート審査の形に運用化したものと解釈できる**: [[オペラビリティ]] 概念ページが記録する Colyer の4段階モデルの第1段階は「設計段階で運用性を組み込む」ことであり、Hamilton の「運用上の問題の80%は設計と開発に起因する」という知見を核とする。LRR/HRR の6項目(欠陥数・アラート・モニタリングカバレッジ・システムアーキテクチャ・デプロイプロセス・プロダクションハイジーン)は、この「設計段階での運用性組み込み」を、レビューという具体的な組織的ゲートとして制度化したものと読める。ただしこの対応関係は本 concept の現ソース群(『SREの探求』11章のみ)では検証されておらず、[[オペラビリティ]] 側のソース([[@2016__blog.acolyer__The Morning Paper on Operability]])とを直接突き合わせた記述はまだない。(Source: [[@2021__OReillyJapan__SREの探求 - Chapter 11 DevOpsの幅広い実践現場で活用されているSREのパターン]] §11.2) ## 未解決の問い - LRR と HRR は具体的にどのように使い分けられるのか。11章の記述からは、LRR がローンチ(顧客への公開)の可否を、HRR が運用引き継ぎ(開発グループから SRE への移管)の可否を判定するものと推測できるが、両者が同一のチェックリストを異なるタイミングで適用するのか、判定基準自体が異なるのかは本 concept の現ソース群では未検証。 - 図11-2 が示す「差し戻し(rollback)」は、HRR で不合格となった場合に何が具体的に起きるのか(開発チームへの引き継ぎ延期、追加の改善サイクル等)は、原資料("SRE@Google: Thousands Of DevOps Since 2004")の一次確認が必要。 - SRE Book・SRE Workbook が記述する PRR(Production Readiness Review)との異同は何か。LRR/HRR と PRR が同一の仕組みを異なる呼称で指しているのか、別の仕組みなのかは、本 concept の現ソース群では未確認。 - HRR での承認速度が「設計段階からの SRE との早期協力」に相関するという Limoncelli の観察は、[[SREエンゲージメントモデル]] が扱う「誰がやる形か」の各位置(Kitchen Sink/Product・Embedded・Consulting・Infrastructure/Tools)のどれと最も強く結び付くか。11章の記述だけでは、SRE がボランティアで早期助言する形態が「Consulting」に近いという以上の特定はできない。 - [[Handover Communications]] が扱う対人的な引き継ぎ(オンコール交代・インシデント指揮官交代)と、HRR が扱うサービス単位の運用移管(開発チームからSREチームへ)は、同じ「引き継ぎ(handoff/handover)」という語を異なる粒度の対象に用いている。両者を接続する具体的なソースは、本 concept・[[Handover Communications]] のいずれの現ソース群にもまだない。 ## 関連 - [[SRE]] — レディネスレビューは SRE が運用する審査制度 - [[DevOps]] — 本 concept の初出ソースは『The DevOps Handbook』からの抜粋であり、DevOps コミュニティへ向けて紹介された SRE パターンの1つ - [[SREエンゲージメントモデル]] — SRE がプロジェクトへボランティアで早期関与する形態との関係 - [[ソフトウェアライフサイクル]] — レディネスレビューはライフサイクル上の「自己管理→引き継ぎ」の移行点に位置する - [[オペラビリティ]] — 6項目の判定基準はオペラビリティの「設計段階での組み込み」を制度化したものと解釈できる - [[Handover Communications]] — 「引き継ぎ」という語を共有するが対象粒度が異なる(対人シフト交代 vs サービス単位の運用移管) - [[@2021__OReillyJapan__SREの探求 - Chapter 11 DevOpsの幅広い実践現場で活用されているSREのパターン]] — 本概念の初出ソース、LRR/HRRの6項目とコンプライアンス評価、Tom Limoncelliの証言 ## 出典 - [[@2021__OReillyJapan__SREの探求 - Chapter 11 DevOpsの幅広い実践現場で活用されているSREのパターン]](Gene Kim, 『SREの探求』, オライリー・ジャパン, 2021, 11章)— 『The DevOps Handbook』からの抜粋。LRR/HRRの6項目の判定基準、規制・コンプライアンス評価、Tom Limoncelliの証言(図11-1・図11-2)