DevOps, SRE, Platform Engineering: 理想の開発環境をめぐる思想と実装の旅

著者：森　友梨映 (yurie.mori)
目次

DevOps, SRE, Platform Engineering: 理想の開発環境をめぐる思想と実装の旅

はじめに

Microsoft MVP for DevOps & Cloud Securityの森　友梨映です。 昨今、DevOpsやSRE、Platform Engineeringといったキーワードが頻繁に使われていますが、それぞれの概念や役割について混乱が生じていることも多いのではないでしょうか。 XでもよくDevOpsとSREの違いってなに？Platform EngineeringとかSREとかDevOpsとか、結局何が違うの？という話題を結構目にするので、これらの概念の歴史的な背景とそれぞれの関係性について整理してみたいと思います。

DevOps, SRE, Platform Engineeringの発展の歴史

まずはDevOps、SRE、Platform Engineeringのムーブメントがどのように発生、発展してきたのかをふりかえります。

2000s’～：クラウドの誕生とDevOpsムーブメントの発生

クラウドサービスの登場により、インフラの調達・運用が効率化。アジャイル手法をインフラにも適用すべきという考えや、DevOps Daysの開催により、開発と運用の連携が重要視されるようになった時代。

2010’s前半～：DevOpsの普及とSREの登場

CI/CDやコンテナ技術の普及によりソフトウェア開発と運用の自動化が進展。GoogleによるSREの登場で、信頼性と可用性を重視した運用の新たなアプローチが確立されました。また、DevOpsの名著である『The Phoenix Project』が出版され、開発から運用に至るまでのプロセスを効率化するテクノロジーの誕生と相まって、DevOpsのムーブメントが加速しました。

SREとDevOps: SREはDevOpsの実装

Googleでは新機能の開発や効率化よりも、オンコール対応などの運用コストが上回っているという課題を解決するために、運用チームが行ってきたことをソフトウェアエンジニアが行い、運用に必要な人手の管理を極力自動化​するための取り組みとしてSREを提唱しました。手作業で反復的に行わなければならないような運用作業を「トイル」と位置づけ、SREの最大の敵としています。

SREとDevOpsの関係については、GoogleのSREチームが以下のように説明しています。

If you think of DevOps as a philosophy and an approach to working, you can argue that SRE implements some of the philosophy that DevOps describes, and is somewhat closer to a concrete definition of a job or role than, say, “DevOps engineer.” So, in a way, class SRE implements interface DevOps. - Google SRE - How SRE Relates to DevOps

SREはDevOpsの哲学とアプローチを実装したものであり、具体的な職務や役割に近い定義を持つ。つまり、SREはDevOpsのインターフェースを実装するクラスである

つまり、SREはDevOpsが目指す道を、運用の自動化や信頼性の定量的な管理とモニタリングなどを通じて「実装」するための具体的な方法論であると言えます。

SREのミッションは、サービスの信頼性を維持しながら、変更の適用速度を最大化することです。具体的には、以下のような活動が含まれます。

  • SLOの維持: サービスのSLO（Service Level Objective）を下回ることなく、変更適用速度の最大化を目指す。
  • キャパシティプランニング: 需要を予測し、システムの安定運用に必要なキャパシティを計画する。どれくらいのユーザーが使用するか、どれくらいの負荷が発生しうるか、ディスク容量やコンピューティングリソースのスケールが必要かなどを考慮する。
  • モニタリング: 人間による解釈を最小化し、ソフトウェアが判断を行い、人は実行に集中するように設計する。
  • トイルの撲滅: 手作業が必要な運用作業（トイル）を極力撲滅し、自動化する（手作業で繰り返し行われる作業は、長期的な価値を持たず、エンジニアが疲弊する原因となるため）

2010’s後半～：クラウドネイティブとマイクロサービスの普及、Platform Engineeringの萌芽

クラウドネイティブやマイクロサービスの普及。「コードですべてを管理して自動化する」GitOpsが提唱されたり、GitHubのユーザー数が40万を超えるなど、開発プラットフォームの重要性が高まりはじめた時代でもあります。しかし、クラウドネイティブがエンジニアに与えたのは恩恵だけでなく、Charity Majors、Liz Fong-Jones、George MirandaのObservability Engineeringでも指摘されているように オンプレミス/モノリシック時代よりも高い管理コスト、抽象化されたが故の非階層的な通信パターンなど、運用の複雑化ももたらしました。 また、2019年に出版されたTeam Topologiesでは、開発者がプロダクト開発に集中できるようにするためのPlatform Teamの設置が提唱され、Platform Engineeringの萌芽が見られました。

2020’s～：生成AIの誕生と発展、Agentic AIの時代へ

2020年にはThoughtworksがTechnology Radar Vol. 22でプロダクトとしてのInternal Developer Platform(IDP)を紹介し、Platform as Productの考え方が広まりました。

More and more companies are building internal platforms to roll out new digital solutions quickly and efficiently. Companies that succeed with this strategy are applying product management to internal platforms. This means establishing empathy with internal consumers (the development teams) and collaborating with them on the design. Platform product managers create roadmaps and ensure the platform delivers value to the business and enhances the developer experience. より多くの企業が、迅速かつ効率的に新しいデジタルソリューションを展開するために、社内プラットフォームの構築を進めています。この戦略で成功している企業は、社内プラットフォームにもプロダクトマネジメントの手法を適用しています。これは、社内の利用者（開発チーム）への共感を持ち、設計段階から協働することを意味します。プラットフォームプロダクトマネージャーはロードマップを作成し、プラットフォームがビジネスに価値をもたらし、開発者体験を向上させることを保証します。

by Thoughtworks Technology Radar Vol. 22

その翌年にはHumanitecがplatformengineering.orgを設立し、Platform Engineeringという言葉が広まり始めました。platformengineering.orgでは、Platform Engineeringを以下のように定義しています。

Platform engineering is a new discipline that builds on the principles of DevOps and SRE, focusing on creating internal developer platforms (IDPs) that enhance developer productivity and experience. It aims to provide a self-service platform for developers, enabling them to deploy and manage applications without deep operational knowledge. - Platform Engineering Community プラットフォーム・エンジニアリングは、DevOpsとSREの原則に基づいて構築された新しい分野であり、開発者の生産性とエクスペリエンスを向上させる内部開発者プラットフォーム（IDP）の構築に重点を置いている。開発者にセルフサービス・プラットフォームを提供し、深い運用知識がなくてもアプリケーションのデプロイと管理ができるようにすることを目的としている。

Is DevOps dead?

DevOpsの誕生からSRE、Platform Engineeringの登場までを概観すると、これらのムーブメントは、ソフトウェア開発と運用の効率化、信頼性の向上、開発者体験の改善を目指して進化してきたことがわかります。DevOpsが唱えた開発と運用のコラボレーションから、JenkinsなどのCI/CDツール、コンテナ技術の誕生による開発からリリースまでの効率化、運用作業の自動化や信頼性向上のためのSREの導入、そしてPlatform Engineeringによる開発者体験の向上といった流れが見て取れます。

最近は海外サイトを巡回してると「DevOpsは死んだ？」という割と香ばしいタイトルの記事が散見されます。たとえば、HumanitecのCTOのChris Stephensonは、Platform Engineering Communityのブログで’DevOps is Dead, Long Live Platform Engineering’という記事を書いています。

https://platformengineering.org/talks-library/devops-is-dead-long-live-platform-engineering

True DevOps - “you build it, you run it” - has been the guiding methodology behind many development teams for years. However, the harsh reality is that most developers don’t like dealing with infrastructure. It isn’t just a source of significant cognitive load, but it also takes time away from their core job of writing, debugging, and running applications. This is where Internal Developer Platforms (IDPs) present a significant advantage. By employing platform engineers to abstract this complexity away from developers, organizations can move away from the outdated DevOps model to a solution that’s more suited to their business.

  • DevOpsは理想的だが、現実として多くの開発者はインフラ対応を好まない。インフラ対応は認知負荷が大きく、開発者本来の目的に集中できなくなる
  • だからこそInternal Developer Platforms (IDPs)が必要なのだ。IDPは開発者からインフラの複雑さを抽象化し、DevOpsモデルからよりビジネスに適したソリューションへ移行することを可能にする。

タイトルはなかなか香ばしいし’Outdated DevOps model（時代遅れのDevOpsモデル）‘というのもなかなか強烈だなぁとは思いますが、DevOpsの理想と現実のギャップを指摘している点は興味深いです。

DevOpsから見たPlatform Engineering: DevOps-as-a-Service（DaaS）

DevOps.comで投稿された記事では、Platform Engineeringの重要性が高まる中で、DevOpsの役割は変化していると指摘されています。

This blog will argue that platform engineering is essentially an evolution of DevOps into a more structured and service-oriented model, providing a standardized and scalable approach to implementing DevOps practices across organizations.　(中略) Platform engineering represents the evolution of DevOps into a more structured and service-oriented model, effectively embodying the principles of DevOps-as-a-service.

by DevOps.com - Platform Engineering: The Evolution of DevOps

プラットフォーム・エンジニアリングは本質的にDevOpsをより構造化されたサービス指向モデルへと進化させたものであり、組織全体でDevOpsプラクティスを実装するための標準化されたスケーラブルなアプローチを提供するものだと主張する。　(中略）プラットフォーム・エンジニアリングは、DevOpsをより構造化されたサービス指向モデルへと進化させたものであり、DevOps-as-a-serviceの原則を効果的に体現している。

DevOpsの道：ほんとうにDevOpsはオワコンなのか？

DevOpsはもうオワコンなのか？ということを考えるためには、DevOpsが本来目指している目標を理解する必要があります。

Gene KimのThe Phoenix Projectでは、DevOpsの3つの「道」として以下のように説明されています。

“第1の道は、開発からIT運用への仕事の流れを早くするにはどうすればよいかだ。IT運用こそ、会社と顧客の間にあるものだからだ。第2の道は、フィードバックループを短縮、強化する方法だ。すると、源のところで品質を上げ、やり直しを避けることができる。そして、第3の道は、実験、失敗からの学習、反復と練習が熟達には不可欠という考え方を並行して育てていく企業文化を作ることだ” - The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win（邦訳：「The DevOps　逆転だ！究極の継続的デリバリー」 ）

つまり、以下の3つがDevOpsの熟達を育むための道とされています。

  1. Dev（開発）からOps（運用）への仕事の流れ（フロー）を早くする
  2. Dev（開発）- Ops（運用）間のフィードバックループを短縮、強化する
  3. 継続的に実験し、失敗から学び、反復と練習を通じて熟達を育むカルチャーの創造

DevOpsの現実

個人的には、DevOps is deadではないけど、DevOpsの実践が難しくなっているのは事実だと思っています。年表のセクションでも触れましたが、DevOpsの実践が難しいといわれる理由には以下のようなものがあると思っています。

  • クラウドネイティブの加速により、DevOpsの役割が複雑化/スコープが広がった
  • DevOpsの推進のために要求されるスキルが幅広くて採用が難しい

ひとことでいうと、DevOpsの実践に習得しないといけないスキルが多すぎるよね、という現実問題があると思ってます。以下は筆者が社内エンジニア向けの勉強会で紹介したDevOpsが関わる範囲とそれに対応するスキルや必要な知識を概観したものですが、これをみると「やること多すぎでは？」となるのではないでしょうか。 devops-and-sdlc

画像出典：https://speakerdeck.com/yuriemori/devopsniguan-suruaruarunawu-jie?slide=5

Effective DevOpsではDevOpsに関するあるあるな誤解として、「DevOpsはチームではない、DevOpsチームみたいな特定のチームを作ってオフロードするのは誤りである。なぜならDevOpsは組織全体の文化やプラクティスであり、特定のチームに限定されるものではないからだ」と述べています。

DevOpsの思想的には、たしかにDevOpsというのは誰かにオフロードして実現させるようなものではないとは思いますが、現実的に考えると、DevOpsを実践するための環境の維持コストと技術の進化が、開発者がプロダクト開発や運用と並行して担うには膨大になりすぎたのだと思います。

David N. Blank-EdelmanのSREの探求でも紹介されているように、SREを組織の中でどのように配置するかは、プロダクトチームの中で活動するSRE engineerや、プロダクトチームとは分離されて専任として活動するSREチームを配属するパターンがあります。この時点で、すでに「開発を効率化することにcontributeする役割」は兼務するにはやることがありすぎる、となったのではないかなと思います。

そして、Team Topologiesの中では、Platform Teamを設置して、開発者がプロダクト開発に集中できるようにするというチームの配置を提唱しています。これも、開発者がプロダクト開発に集中できるようにするために、開発環境の整備や運用の効率化を専門のチームが推進するという考え方です。

さらに、Findyさんのソフトウェア開発における「開発生産性」に関する実態調査レポートでは開発基盤に対する満足度の低さが生産性を低下させる要因として挙げられており、今後のソフトウェアエンジニアリングにとって開発プラットフォームがエンジニアにとってストレスにならないレベルで整備されることが重要であるということは否定しようがなく、そういった意味でもPlatform Engineeringの重要性は高まっていると思います。

我々はどこに向かうのか？

スピードvs品質（安定性/信頼性）：ソフトウェア開発における永遠のシーソーゲーム

これまでのソフトウェア開発の効率化の歴史をふりかえると、DevOpsが掲げている3つの道は達成できているのでしょうか？ CI/CDやコンテナ技術の登場、そして昨今の生成AIの発展により、開発からリリースまでのフローは確実に早くなっています。しかし、DevOpsの2つ目の道である「Dev（開発）- Ops（運用）間のフィードバックループの高速化」は、SREやObserbability Engineeringの登場により、ある程度は実現されているものの、どちらかというとその課題に対して立ち向かえるだけのエンジニアリング技術やプラクティスが登場したということを意味しており、ある意味ではようやく第2の道に足を踏み入れた段階なのではないかと思います。

DORA(DevOps Research and Assessment)のState of DevOps2024のレポートでは、生成AIの導入によって開発のスピードは上がるものの、デリバリーのスループット（どれだけ成果物をリリースできるか）と安定性（成果物の品質や信頼性の一貫性）の両方が若干低下する可能性があると示されています。これは、生成AIが開発の効率化に寄与する一方で、品質や安定性の確保が難しくなる可能性を示唆しています。さらに、SREの認知負荷の増大も懸念されます。このような問題は、開発を効率化させる技術が登場して開発がスピードアップしたら、どんどん生産されるソフトウェアの品質や信頼性を確保や運用をそれにどう追い付かせていくかというソフトウェア開発における永遠のシーソーゲームのようなものだと思います。

DevOps IS NOT dead, its journey still goes on.

そのため、DevOpsの道の旅はまだ終わっていないと考えています。むしろ、DevOpsの道は新たな局面を迎え、生成AIやAgentic AIの登場により、開発者がプロダクト開発に集中できるようにするための開発プラットフォームの整備と、どんどん生産されるソフトウェアの信頼性や安定性を確保するためのSREの実践、そして開発のスピードに追い付くためのOps（運用）フェーズの効率化、SREの負荷の最小化が求められる時代に突入したと言えるのではないでしょうか。

なので、Is DevOps dead? という問いに対しては、「DevOpsはまだ死なない。旅は続く」と答えたいと思います。

ソフトウェア開発ライフサイクルのモダナイゼーションの次なるフロンティアは、生成AIやAgentic AIの登場によってどんどん生産されるソフトウェアの信頼性や安定性を確保しつつ、開発者がプロダクト開発に集中できるようにするための開発プラットフォームの整備と、開発者体験の向上ではないかと思います。 そのため、次なるフロンティアはOps（運用）フェーズのモダナイゼーション（SRE Agent, remediation, インストルメンテーションデータの活用）と、Agentic AIの利用を前提とした開発プラットフォームの自由と統制の両立ではないかなと思います。

SRE Agentに関しては、Azure SRE AgentのPublic Previewが開始されており、これによりSREの実践がさらに効率化されることが期待されています。SRE Agentは、SREの活動を自動化し、運用の効率化と信頼性の向上を目指すものです。 また、New RelicではNew Relic AIというAIによるインシデントの検出や分析を行う機能が提供されており、これによりSREの実践がさらに効率化されることが期待されています。

参考文献

※書籍に関しては、本編で紹介した書籍の日本語版のamazonへのリンクを記載しています