# A Survey of DevOps Concepts and Challenges ## 概要 DevOpsは、正確性と信頼性を保証しながら新しいソフトウェアバージョンの継続的デリバリーを自動化する、組織内での協働的・学際的な取り組みである。本サーベイは、エンジニア・マネージャー・研究者という3つの視点からDevOpsの課題を調査・議論する。文献レビューを行い、DevOpsの自動化ツールをこれらの概念と関連づけたDevOpsコンセプチュアルマップを構築する。続いて、それらがエンジニア・マネージャー・研究者に対して持つ実践的含意を議論する。最後に、文献で報告されている最も重要なDevOpsの課題のいくつかを批判的に検討する。(Source: 論文Abstract) 本論文はACM Computing Surveys誌(Vol. 52, No. 6, Article 127)に2019年11月に掲載された、DevOps分野で最も広く参照されるサーベイ論文の一つである。ブラジルのサンパウロ大学・ブラジリア大学・サンパウロ連邦大学と、米国Hewlett Packard Labsの共著者による研究であり、2018年9月時点の文献(198本を起点に選定された50本のcore paper)を対象にGrounded Theory的手法でDevOps概念を体系化した。(Source: 論文冒頭・著者情報) ## 論文情報 - 著者: Leonardo Leite([[University of São Paulo]])、Carla Rocha([[University of Brasília]])、Fabio Kon([[University of São Paulo]])、Dejan Milojicic([[Hewlett Packard Labs]])、Paulo Meirelles([[Federal University of São Paulo]]) - 掲載: ACM Computing Surveys, Vol. 52, No. 6, Article 127, 35 pages - 発行: 2019年11月(受理: 2019年8月、改訂: 2019年6月、投稿: 2019年1月) - DOI: https://doi.org/10.1145/3359981 - 種別: 査読付きサーベイ論文(ACM CSUR。arXivではない) ## 問題設定 DevOpsは10年近く議論されてきたにもかかわらず、広く合意された定義を欠いている。著者らは最も引用されるDevOps定義を統合し、Dyck et al.の定義に類似した独自定義を採用する: 「DevOpsは、正確性と信頼性を保証しながら新しいソフトウェアバージョンの継続的デリバリーを自動化するために、組織内で行われる協働的・学際的な取り組みである」。(Source: 論文2節) 研究課題は「エンジニア・マネージャー・アカデミアがDevOpsのツール・含意・課題を探求する際の指針となるコンセプチュアルフレームワークを考案すること」である。既存の複数のDevOpsサーベイや研究は存在するが、その多くは単一の視点(エンジニア視点のみ、あるいはマネージャー視点のみ)に偏っており、複数視点を横断的に扱った研究は少ない([33]を除く)。また、本サーベイはより広範なソースを探索し、より新しい文献をカバーしている点で既存研究と異なる。特に、自動化・密結合対疎結合アーキテクチャ・コンテナ化対構成管理・ツールセット管理といった、DevOps採用の技術的含意と複雑性を扱う点は、既存サーベイがカバーしていなかった側面である。(Source: 論文1節) ## 研究方法(文献レビュー手法・Grounded Theory) 本論文は実証実験を行う研究ではなく、系統的文献レビュー(Systematic Literature Review, SLR)の手続きに着想を得た検索・選定プロトコルと、Grounded Theory戦略に基づく分析手続きによって、DevOps概念を構造化したconceptual frameworkを構築する研究である。手順はFigure 1に示される次のシーケンスに従う: 検索・選定プロトコルの適用 → 文献分析 → conceptual frameworkの構築。(Source: 論文3節) Grounded Theoryのコアとなる手続きは「コーディング」であり、データを分解しラベル付けして小さな構成要素にする。最初のオープンコーディング段階では、研究者は事前の仮定・バイアス・動機を注入しないよう注意しながら文献をハイライトし、コードを生成する。その後、定数比較法(constant comparison)によって、複数ソースから得られたコードを繰り返し比較・相関させ、概念へと抽象化し、概念をカテゴリへとグループ化する。具体的には、50本のcore paperを読みオープンコーディングを適用してコードを生成し、定数比較法によってコードを概念・カテゴリへと分析・抽象化・グループ化し、各カテゴリを1つのconceptual mapとして提示する構成をとる。(Source: 論文3.2節) conceptual map構築は以下の規則に従う: (1) ノードはDevOps概念を表す、(2) リンクは概念間の関係を表す、(3) リンクは「(DevOps) → is a → (culture of collaboration)」のような文として読める、(4) 各core paperは一意の参照コードを持つ、(5) すべての概念とリンクは少なくとも1本のcore paperに裏付けられる、(6) リンクのラベルは参照コードを含む、(7) 1つのリンクが複数のラベル・参照を持ちうる、(8) 図の省スペースのため共通リンクを持つ概念はグループ化される、(9) 1つの概念が複数カテゴリに属してよい。process・people・delivery・runtimeという4カテゴリは、概念グラフにおけるハブ(多数の概念に接続する「teams」のような概念)とサイクル(有向グラフを無向化した際の閉路)という接続パターンの観察から創発した。(Source: 論文3.2節) ## 新規性(既存DevOps SLRとの比較) Table 2は既存のDevOps SLR研究(Erich, França, Ghantous, Smeds, Stahl, Jabbari, Lwakatare)が扱ってきた主要リサーチクエスチョン(RQ1: DevOpsの意味とは何か、RQ2: 採用の動機、RQ3: 期待される利点、RQ4: 期待される課題)を整理する。Table 3はこれら既存研究が調査に用いた情報源(Google Scholar・SpringerLink・ACM Digital Library・IEEE Xplore・Scopus・Web of Science等)と収集論文数を一覧化し、本サーベイが167本(うちcore 50本)という既存研究より広範な文献を収集したことを示す。(Source: 論文4.2節、Table 2・Table 3) 最も参照されるDevOpsのSLRであるErich et al.は、SLRと6組織へのインタビューを行い、「協働文化・自動化・測定・共有・サービス・品質保証・ガバナンス」という7領域を抽出したが、DevOpsの効果を示す量的研究の不足を指摘するにとどまった。França et al.はMultivocal Literature Reviewを行い「社会的側面・自動化・測定・共有・品質保証・リーン性」という6領域を抽出したが、実務家コミュニティの特徴づけが主眼だった。これら既存研究はいずれもprocessとpeopleのカテゴリに集中し、runtimeとdeliveryのカテゴリ(マイクロサービスアーキテクチャ・コンテナ化・ツールセット管理といった技術的含意と複雑性)をほとんど扱っていない。本サーベイはこの欠落を埋め、legacy systemでのDevOps運用・マイクロサービスアーキテクチャ採用時の複雑さと過誤・デリバリーパイプライン自動化のガイドライン・ツールセット選択におけるチーム自律性の利点と欠点、という4点の教訓を提供する点を主要な貢献とする。(Source: 論文4.2節) ## 実験設定(文献選定プロトコル) 探索データベースはACM Digital Library・IEEE Xplore Digital Library・SpringerLinkの3つで、Google Scholarも探索したが追加の関連結果は得られなかった。検索基準は: (1) タイトルまたはアブストラクトに"DevOps"を含む、(2) ジャーナル・カンファレンス・コングレス・シンポジウムに掲載(workshop論文は除外)、(3) 英語で書かれている、(4) 3ページ以上、(5) 文献レビュー論文は除外(関連研究として別途扱う)。この検索で198本の論文が得られた。(Source: 論文3.1節) 198本をirrelevant・relevant・core paperの3区分に分類した。アブストラクト精読(場合により本文精読)により45本のirrelevant paperを除外し153本のrelevant paperに絞り込み、さらに理論的飽和(theoretical saturation)を考慮した第2フィルタで、153本から36本のcore paperを抽出した。分類の一貫性確保のため、各結果に最低2名の著者が合意する必要があり、分類が割れた論文は合意に達するまで個別に精査された。加えてsnowballing処理により、"devops"というクエリ文字列では見つからない重要文献(歴史的・先駆的・高被引用・最新の参照文献)から14本の追加core paperを採用し、最終的に167本のrelevant paper・50本のcore paperという構成になった(Table 1)。各core paperには発見元を示す一意の参照コード(A=ACM Digital Library、I=IEEE Xplore、S=SpringerLink、B=snowballing)が付与され、conceptual map上での参照に用いられる。(Source: 論文3.1節、Table 1) Table 1によれば、50本のcore paperはPractices(15本)・Experience report(8本)・Impact(7本)・Concepts(7本)・Challenges(6本)・Education(4本)・Adoption(3本)の7カテゴリに分類される。IEEE Softwareマガジンが50本中13本を占める最多の出典であり、DevOps専用の査読誌・カンファレンスは存在せず、International Workshop on Release EngineeringとInternational Workshop on Quality-aware DevOpsが最も近い関連イベントとされる。(Source: 論文4.1節、Table 1) ## 実験結果(conceptual mapと DevOpsツール分類) 構築されたconceptual frameworkは、全体を俯瞰する1枚のconceptual map(Figure 4)と、process・people・delivery・runtimeという4カテゴリそれぞれのconceptual map(Figure 5〜8)から構成される。process/peopleはマネジメント視点に、delivery/runtimeはエンジニアリング視点により強く対応し、さらにdeliveryは開発者、runtimeは運用者という伝統的役割にそれぞれ近い。この対応は著者らのDevOps定義とも整合する: 「組織内での協働的・学際的な取り組み」はpeopleに、「継続的デリバリー」というプロセスはprocessに、それを自動化するdelivery技術による「正確性」の保証、そして「信頼性」を担うruntime、という形で4カテゴリすべてが定義文に対応づけられる。(Source: 論文5節、Figure 4) - **process(業務プロセス)**: DevOpsはリスク・コスト削減、規制遵守、製品品質・顧客満足向上といったビジネス成果を、頻繁で信頼性の高いリリースプロセスの達成を通じて実現する。継続的デリバリーは短いフィードバックサイクルを通じて製品品質と顧客満足につながる、という関係が明示される。(Source: 論文5.1節、Figure 5) - **people(組織・文化)**: DevOpsという語の中心には、協働の文化を通じて開発と運用の人々を結びつけるという発想がある。サイロを壊し組織全体でインセンティブを整合させる意図を持つ一方、文化変容の方法・オペレーションスキルの獲得・職種統合の是非など、文献上まだ明確な答えのない多数の問いを提起する(8節で議論)。(Source: 論文5.2節、Figure 6) - **delivery(継続的デリバリー)**: 頻繁で信頼性の高いデリバリーを達成する中核戦略はデプロイメントパイプラインの自動化であり、そこからDevOpsツール・技術が生まれる。自動化ツールは多くがオープンソースで、バージョニング・テスト自動化・継続的インテグレーション・構成管理といったコアプラクティスを可能にする。マイクロサービスとDevOpsの相互支援関係、後方互換性・APIバージョニングも扱われる。(Source: 論文5.3節、Figure 7) - **runtime(実行時信頼性)**: 新バージョンを継続的に届けるだけでなく、各バージョンが安定的・信頼できる必要がある。パフォーマンス・可用性・スケーラビリティ・レジリエンス・信頼性という望ましい成果と、それを実現するInfrastructure as Code・仮想化・コンテナ化・クラウドサービス・監視という手段が示される。本番環境での障害注入によるカオスエンジニアリングもここに位置づけられる。(Source: 論文5.4節、Figure 8) Table 4はDevOpsツールを「知識共有」「ソースコード管理」「ビルドプロセス」「継続的インテグレーション」「デプロイ自動化」「監視・ロギング」の6カテゴリ(本文にはさらにActorsという7つ目の非ツール的分類も存在)に整理し、それぞれ代表ツール例(GitLab wiki・Git/SVN・Maven/Gradle・Jenkins/GitLab CI・Chef/Puppet/Docker・Nagios/Prometheus等)、想定利用者(開発者/運用者/両方)、目標(人的協働/継続的デリバリー/信頼性)、関連するDevOps概念を対応づける。”DevOps Periodic Table”という100以上のツールを列挙する著名なリストが、協働系ツールをわずか8個しか含まないという事実は、人的協働というpeopleカテゴリの概念がより技術的な目標・概念に覆い隠されつつある可能性を示唆する。(Source: 論文6節、Table 4) ![[_attachments/Leite-et-al.-2019---A-Survey-of-DevOps-Concepts-and-Challenges/fig4-overall-conceptual-map.png]] *Figure 4. DevOps overall conceptual map(和訳: DevOps全体コンセプチュアルマップ)。DevOpsをdev/ops軸とengineering/management視点軸で4分割し、それぞれRuntime・People・Delivery・Processの4カテゴリに対応づける俯瞰図。* ![[_attachments/Leite-et-al.-2019---A-Survey-of-DevOps-Concepts-and-Challenges/fig5-process-conceptual-map.png]] *Figure 5. Process conceptual map(和訳: プロセス概念マップ)。DevOpsがtop-management sponsorshipを要求し、frequent and reliable release processを介してrisk/cost削減・compliance対応・short feedback cycleによる製品品質/顧客満足を実現する関係図。* ![[_attachments/Leite-et-al.-2019---A-Survey-of-DevOps-Concepts-and-Challenges/fig6-people-conceptual-map.png]] *Figure 6. People conceptual map(和訳: 人・組織概念マップ)。culture of collaborationを起点にteams・DevOps role・knowledge skills and capabilitiesが相互に接続し、NoOps/SmartOps/ChatOps/SecDevOpsといった派生概念にもつながる図。* ![[_attachments/Leite-et-al.-2019---A-Survey-of-DevOps-Concepts-and-Challenges/fig7-delivery-conceptual-map.png]] *Figure 7. Delivery conceptual map(和訳: デリバリー概念マップ)。DevOpsがMicroservices・Continuous Delivery/Deployment・Tools・Automationを介してVersioning/Build Management/Testing Automation等のコアプラクティスへ接続する図。* ![[_attachments/Leite-et-al.-2019---A-Survey-of-DevOps-Concepts-and-Challenges/fig8-runtime-conceptual-map.png]] *Figure 8. Runtime category of concepts(和訳: ランタイム概念マップ)。DevOpsがSecurity/Stability・Performance/Availability/Scalability/Resilience/Reliabilityを、Infrastructure as Code・Continuous runtime monitoring・Chaos engineeringを介して実現する関係図。* ## 考察(エンジニア・マネージャー・研究者への含意と未解決課題) 7節では、エンジニア(マイクロサービス採用・ロールバック・組み込みシステム・テスト自動化・QAチームの位置づけ・レガシーシステム・コミュニケーション・デプロイメントパイプライン構築等)、マネージャー(リーン原則の採用・DevOps導入方法・アセスメント・トレーニング・職種名・文化・デリバリースループット向上・信頼構築)、研究者(ソフトウェアアーキテクチャ・教育・組み込みシステム/IoT・コンプライアンス・セキュリティ・大規模分散システムテスト・量的アセスメント指標・デプロイメントアプローチ・部門間コミュニケーション改善・複数組織横断研究)それぞれへの実践的含意を列挙する。(Source: 論文7節) 8節では文献上まだ十分に解決されていない4つの課題を議論する。(1) 継続的デリバリーに向けたシステム再設計(マイクロサービス化の是非、バージョニングの是非、構成管理とコンテナ化の関係)。(2) 組織内でのDevOps導入方法(collaborating departments・cross-functional team・DevOps teamの3方式。Google流のSite Reliability Engineeringも、運用エンジニア役割の進化形として本節で言及され、SREチームが運用作業に使える時間を50%以下に制限し残りを信頼性向上のエンジニアリングに充てる仕組みが紹介される。NoOpsという、サードパーティクラウドサービスへの置き換えによって専任運用チームを不要化する概念にも言及)。(3) 組織内でのDevOpsプラクティスの品質評価方法(成熟度モデルの不採用、Forsgren & Kerstenによるsurvey data/system dataの併用提案とメトリクス濫用への警鐘)。(4) DevOps実践のためのエンジニア育成方法(100以上あるツールからの選択基準、教育現場での自動採点の困難さ)。(Source: 論文8節) 9節で著者ら自身が認める限界として、学術ワークショップは対象外とし書籍は数冊のみ言及するにとどめたこと、選定プロセスの主観性バイアス(緩和のため2名以上の著者による合意形成と上級研究者の監督を実施)、失敗したDevOps導入事例の報告が見つからなかったという出版バイアスが挙げられる。(Source: 論文9節) ## 強み・弱点 強み: - 167本の文献から選定した50本のcore paperという既存DevOps SLRより広範な文献基盤に基づき、Grounded Theory的なオープンコーディング・定数比較法という体系的手続きでconceptual frameworkを構築している(Table 3で既存研究より情報源が広いことを定量的に示す)。 - process/people(マネジメント視点)に偏っていた既存DevOps SLRに対し、delivery/runtime(エンジニアリング視点)を含む4カテゴリを均等に扱い、DevOpsツールとの対応表(Table 4)まで提示している点で実務的価値が高い。 - エンジニア・マネージャー・研究者という3視点それぞれへの含意を明示的に切り分けて論じており、読者が自身の立場に応じて必要な情報を参照しやすい構成になっている。 弱点: - 著者ら自身が認めるとおり、実証研究ではなく文献レビューに基づく質的分析であり、失敗事例の欠如という出版バイアスの影響を受けている(9節)。 - コーディングと概念抽出のプロセスは「少なくとも1本のcore paperに裏付けられる」ことを要件とするが、複数著者間の一致度(inter-rater reliability)を定量的に報告していない。 - Grounded TheoryはCharmazらによれば通常、理論的コーディングを経て新理論・仮説の定式化に至るが、本論文は明示的に「新たなDevOps理論の定式化は目指さない」としており、Grounded Theory戦略の適用範囲は「文献レビューにおける主観性の緩和」という限定的な目的にとどまる。 ## 出典 - `.raw/papers/Leite-et-al.-2019---A-Survey-of-DevOps-Concepts-and-Challenges.pdf` - `.raw/papers/Leite-et-al.-2019---A-Survey-of-DevOps-Concepts-and-Challenges.txt` - `.raw/papers/Leite-et-al.-2019---A-Survey-of-DevOps-Concepts-and-Challenges/images/images.json`