# デプロイ関連の負荷 ## 定義 デプロイ関連の負荷(deployment pain)とは、エンジニアや技術スタッフがコードを本番環境にプッシュする際に抱く恐怖感や不安を指す測定尺度である。ソフトウェアの開発・テスト段階の作業と運用・保守段階の作業との間に存在する摩擦や食い違いを浮き彫りにし、開発側と運用側の接点であり、環境・プロセス・方法論・考え方、さらには職場や作業に関する用語においてさえ最も差異が生じやすい局面を測定対象とする。『LeanとDevOpsの科学［Accelerate］』は2015・2016・2017年の調査でこの構成概念に関する質問を追加し、「デプロイに際して恐怖心を抱いたり、デプロイが通常の作業の妨げとなったりすることがあるか、それともデプロイは別に苦もなく容易にできるか」という尺度で測定した。(Source: [[@2018__Impress__LeanとDevOpsの科学 - Chapter 9 作業を持続可能にするデプロイ負荷とバーンアウトの軽減]] §9.1) ## パフォーマンスとの相関 デプロイ関連の負荷とソフトウェアデリバリのパフォーマンス・組織のパフォーマンス・組織文化の間には強い相関があることが統計分析で裏付けられた。コードのデプロイに関わる負荷が大きなチームは、これら3つのいずれのレベルも最低である。デプロイ関連の負荷からは2つのことが読み取れる。1つは「ソフトウェアの開発とデリバリが持続可能でないこと」、もう1つは「開発チームやテストチームがデプロイの現況を把握できていないこと」であり、後者はしばしば開発者を自分たちの仕事の結果から切り離す「壁」の存在を示唆する。(Source: [[@2018__Impress__LeanとDevOpsの科学 - Chapter 9 作業を持続可能にするデプロイ負荷とバーンアウトの軽減]] §9.1) ## 3つの典型的な原因 デプロイ関連の負荷の大半は、複雑で不安定なデプロイのプロセスに起因する。典型的な要因は3つある。 1. **デプロイの容易性を念頭に置かない設計**: ソフトウェアが環境との厳密な依存関係を必要とし要件からの逸脱を許容しないため、管理者は不具合の原因について有益な情報を得られず、複雑かつ組織的なデプロイを余儀なくされる。この特徴からは分散システムの設計の不備も読み取れる。 2. **手作業による本番環境への変更・追加**: デプロイの失敗率がかなり高まる。タイピングやコピー/ペーストのミス、不備の多いドキュメンテーションに起因する失策が生じやすく、コンフィギュレーションを手作業で管理していると環境間の同期が失われる「コンフィギュレーション・ドリフト」が発生し、デバッグ時の負担が増大し、さらなる手作業による変更を招いて問題を増大させる恐れがある。 3. **チーム間の複雑な作業の引き継ぎ**: デプロイが複雑なため多くの引き継ぎが必要になる。データベース・ネットワーク・システム・情報セキュリティ・テスト/QA・開発をそれぞれ別個のチームが担当する縦割り組織で特に顕著である。 (Source: [[@2018__Impress__LeanとDevOpsの科学 - Chapter 9 作業を持続可能にするデプロイ負荷とバーンアウトの軽減]] §9.1) ## 軽減策 デプロイ関連の負荷を軽減するには次の措置を要する: (1) 複数の環境に容易にシステムをデプロイでき、各環境の不具合を探知・許容でき、コンポーネントを独立して更新できるよう設計する、(2) 本番システムの状態をバージョンコントロールの情報に基づき自動化された方法で再現できるようにする(本番データは除く)、(3) アプリケーションとプラットフォームをより賢いものにしデプロイプロセスを極力簡素化する。Heroku・Pivotal Cloud Foundry・Red Hat OpenShift・Google Cloud Platform・Amazon Web Services・Microsoft Azure などのPaaSを使えば、コマンド1つでのデプロイが可能である。デプロイを通常の勤務時間内にこなせない場合、それは対処すべき問題がアーキテクチャに存在する兆候であり、しかるべき投資を前提とすれば複雑で大規模な分散システムでも完全自動・ダウンタイムゼロのデプロイメントは十分可能である。より根本的には、テストとデプロイの包括的自動化、トランクベースの開発を含む継続的インテグレーション、情報セキュリティのシフトレフト、テストデータの効果的管理、疎結合のアーキテクチャ、個々のスタッフが独立して作業できる環境、本番環境再現に必要な要素のバージョンコントロールによる管理という技術的ケイパビリティの向上が、デプロイ関連の負荷を緩和する。(Source: [[@2018__Impress__LeanとDevOpsの科学 - Chapter 9 作業を持続可能にするデプロイ負荷とバーンアウトの軽減]] §9.1) ## 横断的知見 - **デプロイ関連の負荷は、第4章が統計的に効果ありと結論づけた7つのケイパビリティの「効果の中身」を測定した尺度として位置づけられる**: [[継続的デリバリ]] concept が集約する第4章は、2014〜2016年調査でバージョン管理・テストの自動化・デプロイメントの自動化・継続的インテグレーション・情報セキュリティのシフトレフト・トランクベースの開発・テストデータの管理という7つのケイパビリティが「デプロイ関連の負荷とチームの燃え尽き症候群を軽減する効果を持つ」と統計的に結論づけるが、デプロイ関連の負荷そのものの定義・測定尺度・原因分析には第4章では踏み込まない。第9章は同じ7つのケイパビリティ(表現はほぼ同一)を挙げつつ、これらが緩和する対象である「デプロイ関連の負荷」を、恐怖感・不安という測定尺度として定義し、3つの典型的な原因(設計・手作業・チーム間引き継ぎ)まで分解する。第4章が「何が効くか」という統計的な効果測定を担い、本ページ(第9章)が「何に効いているのか、その内実」を定性的に説明するという役割分担が、両章を並べると見えてくる。(Source: [[@2018__Impress__LeanとDevOpsの科学 - Chapter 4 技術的プラクティス―継続的デリバリの基本原則と効果]] §4.2, [[@2018__Impress__LeanとDevOpsの科学 - Chapter 9 作業を持続可能にするデプロイ負荷とバーンアウトの軽減]] §9.1) ## 未解決の問い - Microsoft/Bing チームの事例(コラム、Thiago Almeida)は「仕事とオフのバランスに対する満足度」が38%から75%へ改善したという単一組織の定性的な逸話であるが、これは本ページが集約する統計的な相関(デプロイ関連の負荷とパフォーマンス3指標の相関)とどの程度整合するか。単一事例と大規模調査の対応関係は本章だけでは検証できない。 - コンフィギュレーション・ドリフトはデプロイ関連の負荷の原因の1つとして挙げられるが、これを自動検知・是正する具体的な技術・プラクティスは第9章では詳述されない。第4章・第5章のどの技術的プラクティスがこれに直接対応するかは未整理。 - デプロイ関連の負荷の3つの典型的原因(設計・手作業・チーム間引き継ぎ)のうち、どれが最もパフォーマンスへの影響が大きいかは、本章では順序づけられていない。 ## 関連 - 概念: [[継続的デリバリ]](デプロイ関連の負荷を軽減する技術的ケイパビリティの効果を統計的に示すソース) / [[バーンアウト]](デプロイ関連の負荷が招くもう1つの帰結) / [[DORA]] / [[ソフトウェア変更管理]] - ソース: [[@2018__Impress__LeanとDevOpsの科学 - Chapter 9 作業を持続可能にするデプロイ負荷とバーンアウトの軽減]] / [[@2018__Impress__LeanとDevOpsの科学 - Chapter 4 技術的プラクティス―継続的デリバリの基本原則と効果]] - 実体: [[Jez Humble]] / [[Nicole Forsgren]] / [[Gene Kim]] - 書籍: [[LeanとDevOpsの科学［Accelerate］]] ## 出典 - Nicole Forsgren, Jez Humble, Gene Kim 著, 武舎広幸・武舎るみ 訳, 『LeanとDevOpsの科学［Accelerate］』, インプレス, 2018, 第9章 §9.1.