この記事はスタンバイ Advent Calendar 2022の12日目の記事です。

Platform Engineering と Site Reliability Engineering（以下SRE）について考えていきたいと思います。

この記事の目的

この記事では

SREという言葉の定義と最近の取り組み事例についての考察
Platform Engineeringという考えの紹介
Platform EngineeringとSRE の相違点、共通点

について書きたいと思います。

これは決して特定の個人や団体の考えを否定するものではなく、ご自身のキャリアや組織を考える際のヒントとして使って頂けたら幸いです。

SREという言葉

まずはSREという言葉について確認してみましょう。

O'Reilly Japan - SRE サイトリライアビリティエンジニアリングによると、

（開発/運用の分断に対して）Googleが選択したのはこれまでと異なるアプローチでシステムを動作させることでした。
Googleのサイトリライアビリティエンジニアリングチームは、ソフトウェアエンジニアを採用することに注力し、採用したエンジニアにサービスを運用させ、従来であればシスアドによってしばしば手作業で行われたであろう作業を遂行するシステムを構築しています。

SREとは、ソフトウェアエンジニアに運用チームの設計を依頼したときに出来上がるものです。

とあります。

日本のIT業界風に言えば、『従来のインフラ/運用チームではなく、業務アプリケーションを書くエンジニアに運用設計をお願いしたら出来上がったもの』のようです。

さらにO'Reilly Japan - サイトリライアビリティワークブックには、以下のようなSREの原理が定義されています。（原文を要約してます）

運用はソフトウェアの問題

SREは運用をうまく行うためにソフトウェアエンジニアリングのアプローチを用いる

SLOによる管理

サービスはプロダクトチームとSREチームによって選択されたSLOに応じて管理される

SLO違反が起きた場合は誰かを避難するのではなく、全員で取り組む

トイル最小化のための作業

トイル（手作業で構造的に矯正されるタスク）は仕事ではなく、仕事になりうるものでもない

プロジェクトの作業こそが、サービスの信頼性とスケーラビリティを高める方法

ジョブの自動化

トイルに費やすことができる時間の上限は50%

残りのの50%以上はをプロダクト開発に充てる

失敗のコスト削減による速度の向上

SREがMTTRを削減することで開発速度の向上が見込まれる

SREは早期に問題を発見し解決することを期待されている

開発者との共有オーナーシップ

SREはプロダクト開発チームとスキルセット（担当サービスのインフラ構成や運用に関する知識）を共有する

いわゆる開発と運用の境界線をぼかすことで、特定の機能を独占的に守ろうとするインセンティブを除こうとする

役割や肩書に関わらず同じツールを使う

SREは単一のコードベースやシステムのツール群を持ち、プロダクト開発チームもこのツールを使う

組織内の役割に関わらず同じツールを使う

SREチームは各プロダクト開発チームの運用における問題をソフトウェアエンジニアリングで解決し開発速度を上げ、アプリケーション開発も行うエンジニアのように定義されています。

それはSREなのか問題

SREという考えが広く受けられていく一方で、認識の齟齬が生まれるようになっていきました。

広がっていくSREという考え

O'Reilly Japan - SRE サイトリライアビリティエンジニアリングがに2017年08月出版されて以降その考えはまたたく間に広がり、個人のキャリアや組織の取り組みとして『SRE』という言葉が一般化されていきました。

SNSや勉強会を通じて情報交換が活発になり、『SRE NEXT』という大規模カンファレンスが開かれるまでになりました。

そこで取り組み事例を見ていると、SREへの取り組みとしていくつかのパターンがあるようでした。

7種類のSRE実践パターン - 株式会社X-Tech 5（株式会社クロステックファイブ）にまとめられているので是非参考にしてください。

以下は上記サイトのSRE実装例として紹介されているパターンに、私の考えを加筆したものです。

Embedded SRE
- メンバーとして機能開発を担当することもあれば、SREのエキスパートとしてSite Reliabilityに関連する機能を開発する
Enabling SRE
- 機能開発メンバーに対してSREの考え方や文化を浸透させ、他のメンバーのコードや開発方針をSRE観点でレビューし、立ち上がりを支援する
Everything SRE
- 1つのSREチームとして全ての機能開発チームのSREタスクを実施する
Platform SRE
- 機能開発チームが使うインフラ環境を整備する

同じ『SRE』という名を冠していても、組織の方針や事情によってSREの振る舞いが異なっています。特に、機能開発のためのコードを書くかどうかが異なっているようです。Embedded SRE以外はコードを書かないように見受けられます。

SREは業務アプリケーション開発をするべきなのか

先に上げたパターンはもちろん厳密な定義でもルールでもないので、守る必要はありません。ただ、『SRE』という言葉で各人が思い浮かべるSREの振る舞いが異なっているという事はありそうです。

Embedded SREがSREだと思ってる人から見れば、機能開発に関わらないPlatform SREには違和感を覚えるでしょうし、その逆もまた然りです。

何のためのSRE?

SREがチームとして活動していく中で、以下のような問題に直面した場合、どのように考えたら良いのでしょうか？

Platform SREが組織として独立している場合、機能開発に関わらない彼らが自身のトイルを減らした場合、余剰時間を何に充てるべきなのでしょうか。
『SREチーム』という名でEmbedded SREチームを立ち上げたのに、実態としてはPlatform SREになっていた場合は、どこでズレが生じてしまったのでしょうか。

Platform Engineering とは

What is platform engineering?によると、パブリッククラドの台頭でDevOpsの流れが加速し、開発のイテレーション高速化のためにエンジニアはインフラ構成のセットアップからアプリケーションの実装、デプロイまでを独立して行うことが求められるケースが増えてきました『You build it, you run it』の世界です。

しかしこれは現実的ではない場合があります。例えばフロントエンド開発を得意とするチームがAWSに環境構築するためにキャパシティ、可用性、性能、コストなどを考慮した適切なAWS構成を選択し、それをTerraformやAnsibleでコード化し、さらに運用監視に必要なメトリクスや監視方法を考慮し運用監視のセットアップを行うというのは、認知負荷が高いと言えます。

機能開発が本来の任務であるチームではインフラの構築運用タスクの優先度が自ずと下がり、中途半端なソリューションや良くないアプローチをしてしまうかも知れません。

また、経験豊富なエンジニアに他のエンジニアをサポートするバックエンド/インフラ関連のタスクが集中してしまい、バーンアウトや組織の生産性低下に陥る危険性もあります。

では、そういったアンチパターンを回避して高パフォーマンスを発揮している組織がどのような取り組みを行っているかというと、開発者が自力でアプリケーションの実行環境を容易にセットアップできる、独自プラットフォームを構築している組織が多いです。

記事中ではプラットフォームは以下のように定義されています。

プラットフォームは「セルフサービス API、ツール、サービス、知識、およびサポートの基盤であり、魅力的な内部製品として配置されています。自律的なデリバリーチームは、このプラットフォームを利用して、調整を減らしながら、より速いペースで製品機能を提供できます。

このプラットフォームを構築運用するためのアプローチがPlatform Engineeringです。

プラットフォームエンジニアリングは、クラウドネイティブ時代のソフトウェアエンジニアリング組織のセルフサービス機能を可能にするツールチェーンとワークフローを設計および構築する分野です。プラットフォームエンジニアは、アプリケーションのライフサイクル全体の運用上の必要性をカバーする「内部開発者プラットフォーム（Internal Developper Platform）」と呼ばれる統合製品を提供します。

とあります。

開発者のDevOpsに対する認知負荷を軽減し、アプリケーションの実行基盤を抽象化した、開発者がセルフサービスで容易に実行基盤を構築できるプラットフォームを提供します。

Platfrom Engineeringの原則として、以下のようなものが紹介されています。

明確な使命と役割を持つ
プラットフォームを製品として扱う
共通的な問題に焦点を当てる
車輪の再発明をしない

では、Platform EngineeringとSREの間にどのような違いや共通点があるのでしょうか。

Platform Engineering と SRE の共通点と相違点

両者は非常に似ていますが、異なる点もあります。

私が思うPlatform Engineering と SRE の共通点と相違点は、以下の通りです。

共通点

プラットフォームを製品として扱う
トイル最小化のための作業を行う
開発イテレーションを高速化させる
開発チームに教育をし、知識を共有化する
ソフトウェアエンジニアリングのスキル

相違点

顧客

Platform Engineeringにおける顧客は開発者です
SREにおける顧客はシステムのエンドユーザです

目的

*　Platform Engineeringの目的は、開発者の体験と生産性の向上に努めることです
*　SREの目的は、SLO（Service Level Objective）を定め、サービス品質向上に努めることです

最後に

そのSREは間違えていますか？

いろんな用語を紹介してきましたが、私の目的は言葉遊びではなく、ましてや特定の人や組織に対して「あなたがやっているSREは間違えています」とか「あなたの組織名にある『SRE』という看板を外してください」ということでは決してありません。

目的を成就するにあたって、Platform Engineeringという手法（Engineering）を紹介しているのです。

ワードに捕らわれて変な期待値を発生させないようにプラクティスを優先させるやり方もあります。興味のある方はSRE_NEXTで発表された非ITの事業会社にSREと言わずにSREを持ち込んだという資料をご覧ください。

大事なのは目的と手法（Engineering）

あなた（や組織）にとって、Siteとは何で、Reliabilityはどのように定義されて、その向上のためにどのようなEngineeringをしているのでしょうか。

先に上げた問いに対しても、Platform Engineeringの考えを取り入れると、以下のような答えが出るかも知れません。

Platform SREが組織として独立している場合、機能開発に関わらない彼らが自身のトイルを減らした場合、余剰時間を何に充てるべきなのでしょうか。

という問いに対する答えとしては、「内部開発者プラットフォーム（Internal Developper Platform）」の開発に当ててはいかがでしょうか。他の機能開発チームと同様にIDPにSLOを設けてもいいかも知れません。SLOモニタリング機能のドッグフーディングも行えるからです。

『SREチーム』という名でEmbedded SREチームを立ち上げたのに、実態としてはPlatform SREになっていた場合は、どこでズレが生じてしまったのでしょうか。

という問いに対する答えとしては、開発者向けのプラットフォームに改善の余地があるのかも知れません。開発を顧客として捉え、しっかりコミュニケーションをとってプラットフォーム開発チームを立ち上げるべきかも知れません。

『SRE』だからSLO、自動化、IaCではなく、それがどのような目的のための手段なのか。『Platform Engineer』だから開発しなくていいのではなく、顧客のための最善が何なのか。

プラットフォーム開発のために必要なエッセンスはCloudNative Days Tokyoで発表された、独りよがりのプラットフォーム / For Whom that Platform Runsや、役に立つプラットフォームを作ろう - プラットフォームエンジニアが知っておくべき『プロダクト』の考え方が参考になるでしょう。

この記事を執筆するために資料をいくつか拝見しましたが、2022年に書かれた記事が多かったです。

DevOpsやSREといった用語集に新たなBuzzワードが増えるかも知れませんが、自分や組織の方向性を考える上で、今回紹介したPlatform Engineeringという考えが、良いヒントになることを祈っています。

最後までお読み頂き有難うございました。

Platform Engineering と Site Reliability Engineering について