働いている環境
Platform Engineeringの話をする前に、僕が今どのような環境で仕事しているのかについて説明しておく。
会社と組織
従業員1万人程度のWeb系企業でSREをしており、本社はアメリカで世界各地に開発拠点がある。
エンジニア組織としては大きく3つのチームに分かれている。
- Productチーム：エンドユーザー向けのサービスを開発する
- Platformチーム：Productチームの生産性を高めたり、サービスを稼働するための基盤を整える
- SREチーム：各Productチーム／PlatformチームにEbmeddedされてSREのロールを担う
Embedded SRE
僕は今Embedded SREとして、大体25人くらいのエンジニアがいるグループと一緒に仕事をしている。グループの中にはチームが3つある。
社内向けツールとか含めると本当にサービスの数は多くて、1チーム5〜10くらいのサービスを運用している。
重要度の高いサービスを中心に、SREのプラクティスの適用やReliablityの向上に取り組んでいる。
SREという組織としての活動は少ないが、SRE内での情報共有や、全社で取り組む案件の各チームでの推進を担っている。
そういった背景からも、Platformチームが用意したPlatformを利用する機会や、開発チームがそれを利用する際のサポートをすることが多い。
OnCall
各Productチームが自分たちのサービスのOnCall対応をするのが基本だが、業務時間外をカバーするために、GlobalOnCallをSREが提供している。
つまり、SREメンバーが交代で全ての重要なサービスの障害の一次対応を行なうのだ。
社内のPlatform Engineeringの状況
個人的には非常に整っていると感じている。
どんなものが用意されている？
全てはここで挙げないが、開発サイクルの中で必要になるありとあらゆるものが、SelfServiceなツール化されており、ドキュメントとSlackの専用チャネルでのサポートが基本セットとなって提供されている。
- Computer Platform
- Pipeline
- Observability
- Secret Management
- AWS/Terraform acconunt management
- ...
例えばアプリを動かすために直接Kubernetesの知識やYAMLの書き方を知っている必要はなく、UIから少し設定するだけでアプリのPodを好きなリージョンに必要なだけデプロイし、必要なSecret情報が自動でアプリから利用可能な状態になり、サービスメッシュ、ログ、基本メトリクスが取れるようになっている。
各ツール群は社内事情に合わせて高度に抽象化・自動化されていて、慣れれば非常に便利で使いやすい反面、良い意味でも悪い意味でもブラックボックスではあるので、サポート用のチャネルはいつも問い合わせで賑わっている。
問い合わせに対するレスポンスは基本的には早いのだが、稀にスルーされたり、メインのチームが地球の反対側にいたりすると、レスポンスが次の日になることもある。
どれくらい利用されている？
自分が観測している範囲内では、ほぼ全てのサービスがPlatformチームが用意したツール群、基盤を利用している。
利用した方が確実に楽だし、Productの開発に集中したければ、Platformチームが用意したものを利用するのが最短であることを皆が理解している感じ。
ほぼ全てのサービスが同じPlatformで同じように動いているため、GlobalOnCallで全然知らないサービスの障害の一次受けやその対応を行なうことができているとも感じている。
Embedded SRE から見た Platform Engineering (本題)
今まで説明してきたような状況の中で、自分がEmbedded SREとして、Platform Engineeringに感じていることを書き出してみる。
Platform Engineeringの大事だと思う要素
- Self Service／自動化
- 充実したドキュメント
- サポート（マイグレーション含む）
- オープン化
多くのサービスが利用するPlatformは確実にSelf Serviceであるべきだし、自動化されているべきであると思う。
間に人の作業が入ってしまうと、タイムゾーンが別々の場合、最低でも1日以上待たなければいけない状況も想像に難くない。
また、FAQや各種ユースケースを網羅したドキュメントはPlatformの質を高めると感じている。
それでもどうしてもユースケースは多岐にわたってしまうし、不具合もゼロにはできないので、Publicなチャットなどでのサポートは必須だろう。
マイグレーションのサポート
サポートとして重要な点の1つにマイグレーション（例えばPipelineをJenkinsからGitHubActionsに切り替えるなど）やバージョンアップのサポートがあげられる。
Platformチームが作った仕組みが広く普及しない現場は前職含めていろんな場所で見てきたが、一番の理由は「マイグレーションにコストがかけられない」だと感じている。
今の会社では、Productチーム側でマイグレーションを進めるのが難しい場合、Platformチーム側が「Lift and Shift」という名前で一気に移行してしまうのだ。
当然全てのサービスで100％うまく動かない場合もあるので、Embedded SREも加わりこの「Lift and Shift」を進めていくことになる。
オープン化
ProductチームもEmbedded SREもPlatformを利用する側なので、作る側ではないが、積極的なコントリビューションが奨励されている。
利用者側からのリクエストがあれば当然チケットは切り、同時にPullRequestを送ることもOKなのだ。
また、問い合わせの際にも、ある程度Platformの裏側でどんなことが行われているかを理解しつつ問い合わせをすることで、チャット上での効率的なやり取りを行うことができるようになると感じている。
そのためにも、Platform自体のオープン化、つまり裏で動いているツールのソースコードが公開されていることや、その仕組みについてのWikiが公開されていることは重要だと感じている。
Platform Engineering に対する Embedded SRE としての強み
自分でPlatformを作っているわけではないが、Platformのオープン化によって、ある程度の裏の仕組みも理解できる状況にある。
また利用者側として、Productチームが感じるペインポイントや、他のPlatformとの親和性など、Platformチーム側では気づきにくい改善ポイントのアイデアを持つことができる。
Platformの利用者、提供者、両方の立場の中間的な立場からPlatformの改善を行えるという点は、Embedded SREの強みではにないかと感じている。
Platform Engineering の SRE への影響
共通化の恩恵は大きい。本当にこれに尽きると思う。チームが変わっても自分の培ってきた知識をすぐに適用できるし、横断的な仕事もとてもしやすい。
GlobalOnCallとして、本当にいくつものサービスを見なければいけない状況も、この共通化無くして実現できていないのではないかと思う。
最後に
Platformを作るPlatformチーム側でも、Platformを直接利用するProductチーム側でもない、第3の視点からPlatform Engineeringについて書いてみた。
Platform Engineeringに取り組む／取り入れたいと思っている人の何かしらのの参考にでもなれば良いなぁと思う。