# ローンチチェックリスト ## 定義 ローンチチェックリスト(Launch Checklist)は、Google の Launch Coordination Engineering(LCE)チームが新製品・新機能のローンチを審査するために用いる中核成果物である。航空機の離陸前チェックリストや外科手術チェックリストと同種の、「質問」と「アクションアイテム」の対で構成され、失敗を減らし一貫性と網羅性を確保する仕組みである。LCE はソフトウェアエンジニアとシステムエンジニア(一部は他の SRE チームでの経験者)からなる SRE 内の専任コンサルティングチームで、Google の信頼性標準への準拠監査・複数チーム間の連絡役・ローンチの技術的推進・「安全」ローンチへのゲートキーピングとしての署名・開発者教育を担う。Google はローンチを「アプリケーションに外部から見える変更をもたらす新規コード」と定義し、この定義のもとで週最大70件のローンチをこなす。(Source: [[@2016__OReilly__SRE Book - Chapter 27 Reliable Product Launches at Scale]]) チェックリストは無制限に肥大化しうる。それを防ぐため、各質問の重要性は**過去のローンチ災害で裏付けられていること**、各アクションアイテムは**具体的・実践的・開発者が達成可能であること**という2つのガイドラインで運用される。一時期は新規質問の追加に副社長(VP)承認を要求していたほど、肥大化は現実の脅威として扱われてきた。チェックリストは1〜2年に1回、全体レビューで陳腐化した項目を洗い出し、日常的にも LCE メンバーが継続的に小さな更新を加える。良いローンチプロセスの5基準——軽量(lightweight)・頑健(robust)・徹底的(thorough)・スケーラブル(scalable)・適応的(adaptable)——は相互に矛盾しうるため(軽量さと徹底性は特に衝突しやすい)、シンプルさの徹底・経験豊富なエンジニアによるハイタッチな個別対応・よくあるローンチパターンへの簡易パスの提供という3戦術でバランスを取る。(Source: [[@2016__OReilly__SRE Book - Chapter 27 Reliable Product Launches at Scale]]) ## 横断的知見 - **チェックリストの抽象的な行動項目(例:「カナリアを使って段階的にロールアウトせよ」)は、それ単体では自己完結した指示ではなく、書籍内の別の章が体系化した技術的な詳細への参照として機能する**: 第27章は「選ばれた信頼性の高いローンチのための技法」節で、カナリアを「少数マシン・1データセンターで観察し、問題なければ全体展開へ進める」段階的ロールアウトの最初の段階と説明し、「変更が検証期間を通過しなければ自動的にロールバックされる」という運用まで述べるが、この検証がどのような判定基準で下されるかには立ち入らない。第17章「Testing for Reliability」はまさにこの空白を埋める: カナリアテストを「バイナリを焼く(baking the binary)」と呼ばれるインキュベーション期間として位置づけ、障害の次数(degree of failure, U)という枠組みでカナリアの検出可能性を分析する——単一リクエストにのみ影響する障害コード(U=1)は線形に検出できるが、将来のリクエストに影響するデータ破壊(U=2以上)は検出が困難になる。第27章のチェックリスト項目は「共有インフラを既存の建材として使え」という同章自身の原則([[フィーチャーフラグ]]の項でも同型の記述がある「レート制限は自前実装せずシステムXを使え」)の一例であり、「カナリアを使え」という指示の実質的な中身は、チェックリストの外、すなわち第17章のような専門知識の蓄積に委ねられている。チェックリストという成果物は、判定ロジックそのものではなく、判定ロジックへの**入口(ポインタ)**として機能していることが、2つの章を突き合わせて初めて見える。(Source: [[@2016__OReilly__SRE Book - Chapter 27 Reliable Product Launches at Scale]], [[@2016__OReilly__SRE Book - Chapter 17 Testing for Reliability]]) ## 未解決の問い - チェックリストの各項目が「どの過去のローンチ災害に由来するか」を追跡・記録する仕組みは、第27章では明示されない。項目の来歴(なぜこの質問が存在するのか)が失われると、レビュー時に「意図(intent)を忘れて機械的に適用する」リスクが生じることは第27章自身が指摘している(Android ローンチの例)が、来歴を保存する具体的な仕組みは記述がない。 - 第27章はチェックリスト項目が指し示す先(共有インフラ・専門技法)の存在を前提にしているが、新しい製品領域(本章の例では Android)でその指し示す先がまだ存在しない場合、LCE はドメインエキスパートとの対話から抽象的な第一原理に立ち返るとしか述べていない。この「参照先の技術知識をゼロから作る」プロセスと、参照先が確立している通常のケースとで、チェックリストの運用がどう変わるかは本ページの範囲では未整理。 - 低リスクローンチ(新規サーバー実行ファイルなし・トラフィック増加10%未満など)の判定基準は、2008年時点でレビューの30%を占めるまでに拡大したと第27章は述べるが、この閾値がどう決定・更新されるか、また判定を誤った場合(実際には高リスクだったローンチを低リスクと誤判定した場合)にどう検知・修正されるかは記述されていない。 ## 関連 - 概念: [[フィーチャーフラグ]](チェックリストが指し示す具体的な段階的展開機構の1つ) / [[カナリアテスト]](チェックリストの「カナリアを使え」という指示が実質的に指し示す技術的詳細) / [[キャパシティ計画]](チェックリストの主要テーマの1つ、ローンチスパイクの需要予測) - 実体: [[Rhandeev Singh]] / [[Sebastian Kirsch]] / [[Vivek Rau]] - source: [[@2016__OReilly__SRE Book - Chapter 27 Reliable Product Launches at Scale]] / [[@2016__OReilly__SRE Book - Chapter 17 Testing for Reliability]] - 書籍: [[SRE Book]] ## 出典 - Rhandeev Singh, Sebastian Kirsch, and Vivek Rau, "Reliable Product Launches at Scale," in *Site Reliability Engineering: How Google Runs Production Systems*, Beyer, B. et al. (eds.), O'Reilly, 2016, Chapter 27. - Alex Perry and Max Luebbe, "Testing for Reliability," in *Site Reliability Engineering: How Google Runs Production Systems*, Beyer, B. et al. (eds.), O'Reilly, 2016, Chapter 17.