なぜ、プラットフォームエンジニアがDevOps変革を導くべきか

2022年9月22日 14:23

Why a Platform Engineer Should Lead Your DevOps Transformation
作者：Mark Shipps
図：Daniel Condon
日本語訳：Ryo Kawase & Yugo Tahara

私たちスラロムビルドでは、DevOpsのマインドセットにのっとったソフトウェア開発をおこなっています。プラットフォームエンジニアリングという領域自体が、このDevOpsマインドセットに適応する（あるいは適応しようとしている）企業から生まれた領域なので、DevOpsマインドセットはプラットフォームエンジニア（以下PE）である私の役割の非常に重要な部分でもあります。最近、私は、プロダクトエンジニアリングとDevOpsの変革が混在するプロジェクトに携わりました。このようなシナリオは、日本のようなクラウド導入の初期段階にある市場ではよく見かけられます。伝統的なIT構造が根ざしている企業は、クラウドコンピューティングによってもたらされる利点を受け入れ、クラウドネイティブなプロダクトという形で、目に見える成果を迅速に得たいと考えています。なので、私はスラロムの仲間と共に、顧客の新しいクラウドネイティブなプロダクトを作りつつ、顧客が実践的にDevOpsを理解するための冒険を導き始めました。私は数カ月のコラボレーションを通し、CICD、SRE、クラウドアーキテクチャ、ツールなどのプラットフォームエンジニアリングに関連する、ベストプラクティスとパターンに関する多くのプレゼンテーションやスプリントデモを行い、同時にDevOpsの概念への関連性を示すということも行いました。これらのセッションの参加者たちは、ビジネス全体に渡って仕事をされている方々であり、彼らからDevOpsの本質、そして自分達の役割がどのようなものなのかを理解できたという感想をいただきました。この機会を通じて私は、PEがDevOpsの変革のリーダーであることを実感するようになりました。なぜそう思ったのかをご理解いただけるように、Gene Kimの「The Three Ways（３つの方法）」を紹介しながら、プラットフォームエンジニアリングの視点から説明します。

第一の方法：システムシンキング

最初の方法は、自分たちの部署のことだけを考えず、システム全体を考えようというもので、「壁越しに仕事を投げつける」事をしないための方法です。ここでのシステムとは、組織としてのシステムや、実際に使用するソフトウェアシステムなど、エンドユーザーに価値を届けるために必要となるすべての仕組みのことを指します。私たちは、システム全体を通して最適化を実現したいので、他のシステムにネガティブな影響を与えるような局所的な最適化をしないことが大切です。その為には、できる限りシステム全体について考えることが重要です。では、どのようにプラットフォームエンジニアリングはシステムシンキングを促進するのでしょうか？

一言で言ってしまえば、プラットフォームエンジニアリングではこれは当たり前のことのように思えます。なぜならプラットフォームエンジニアリングの主な焦点は、エンドユーザーに提供するコード変更に関わるすべての関係者（特に開発者）のために良い経験を提供することだからです。これらのコード変更は、一つのプラットフォームを共有する、様々なプロダクトという形で出現することもあります。それゆえ、PEはコード変更自体の性質だけでなく、全てのシナリオでどのようにシステムに入り、進み、出ていくのかを理解しておく必要があります。そうして初めて、本当の最適化ができるのです。もう少し掘り下げてみて、私のプロジェクトの中でそれほど「当たり前」ではなかった例を紹介します：

効率アップのチャンスを見つけるため、プログラムの管理とツールに注力しました。システム全体を把握しておくことで、バグ、アプリケーション開発、インフラ開発などのすべてのコードを平等に扱うという決断を下すことができました。その後私は、コードコミットにおけるイシューやリリースをGitHubとJIRA間で統合することができました。これによりチームは、どのリリースもしくは成果物で、どのストーリーやバグが実装されたのかを簡単に識別できるようになりました。また、実際のコードの変更に伴うリリースの規模を追跡できるようになったことは、プログラムの計画、監視にも役立ちます。
品質エンジニアリング、セキュリティエンジニアリングの概念を適用しました。これらは典型的にはコードリポジトリ、ブランチ戦略、CICDパイプライン（自動テストやプルリクエスト制御）に実装される形で適用されます。私はこれらの概念を、いつ、どのようにシステムへ統合すべきかを理解するために、新しい自動テストとセキュリティスキャンのソフトウェアについても学びました。例えば、SASTツールとしてVeraCodeを選定しましたが、CICDパイプラインタスクを常に実行（always）設定にしたい場合には実行速度が足りませんでした。JetBrainsが指摘するように、CICDは自動テストに大きく依存しているとはいえ、すべての自動テストは常に実行することを目指すべきではありません。SASTスキャンの意図、対象範囲、ライフサイクルの各段階におけるコードの整合性を理解することで、パイプラインを高速に保ちながらSASTを自動化するソリューションを実装することができました。
アプリケーションが使用するプラットフォームを動作させるためのクラウドのインフラを設計するため、アプリケーション側のアーキテクトと緊密な連携を行いました。本プロジェクトにおいて、私はAWS上のコンテナ内で動作する.NET 6マイクロサービスについて学びました。アプリケーション自体を深く理解しておくことで、インフラがさまざまなユースケースに対し適切に設計されているかどうかを確認することができます。こうすることで、セキュリティや信頼性という軸からだけでなく、ネットワーキング、CICD、IaCツールなどといった軸からも、使用すべきサービスかどうかの判断を下すことができるようになりました。

第二の方法：フィードバックループを増幅

二つ目の方法は、システム内で「右から左へ」フィードバックループを作成することを重視します。Gene Kimによると、この方法では結果として「社内外すべてのお客様に応じる」ことができます。ここでのポイントは、フィードバックの受け取りが早ければ早いほど、検証・妥当性の確認、その後の軌道修正が早くなるということです。これは、時間、労力、費用を節約するもので、プロセス最適化理論の中心的なテーマです。プラットフォームエンジニアリングにおける一番明確な例は継続的インテグレーションですが、ここでは私のプロジェクトで継続的インテグレーションを取り入れたいくつかの方法を紹介します：

アプリケーションエンジニアや品質エンジニアと協力し、開発者のローカルコンピュータに本番さながらの環境を構築しました。開発者が最も早く得られるフィードバックは、CICDパイプラインへプッシュする前に、リモート環境へ接続せずに、書いたコードをテストできることです。私は、必要なインフラをさまざまなコンテナ内（docker-composeを使用）に立ち上げ、統合テストを行う自動化を実装しました。本番のAWS環境を完全に再現することは現実的ではありませんが、私たちは、十分有用なフィードバックを得られる程度に本番環境に類似した環境を作成することができました。こうすることで、コードをコミットする前に多くの問題を発見することができ、コードリポジトリの品質を、小さな変更に至るまで、素早く安価に向上させることができました。
New Relicを用いてアプリケーション監視ソフトウェアとのシステム統合を行いました。一例として、開発チームと協力し、ログとメトリクスをNew Relicインスタンスに集約し、パフォーマンスとエラーのデータを統合して表示できるようになりました。その後、ログ上にエラーが検出された時や、許容範囲を下回るレベルにパフォーマンスが落ち込んだ時に通知が行われるよう、アラートポリシーや通知の設定を行いました。さらに、アプリケーションのリリースごとのメトリクスの基準を作成してくれるデプロイメントマーカーも実装しました。これにより、リリースごとのパフォーマンスの違いをモニタリングすることで瞬時に異常を検知できるようになり、エラーやパフォーマンスに関するトラブルシューティングに役立てることができるようになりました。これらのオペレーションに関するフィードバックツールは、本番環境だけでなく、あらゆる環境で活用でき、私たちが採用しているSRE戦略の重要な要素となっています。

第三の方法：実験と学習の文化の構築

第三の方法は、DevOpsとはカルチャーを改善するものである、ということを強調しているため、個人的にお気に入りの方法です。エンジニアは実験する機会が増えれば増えるほど、イノベーションは加速し、新たな発見が生まれ、開発力（そして回復力）が上がります。それが結果的に技術の成熟や高度化につながるだけでなく、学びの喜び、達成感、そしてチーム内の恐怖を信頼に置き換えることになるのです。The Phoenix Projectにも、「偉大なチームとは、最も賢い人々がいたということを意味しない。偉大なチームとは、皆がお互いを信頼しているチームだ。信頼という魔法が存在するとき、強大な力が発生する。」と書かれています。前述の通り、プラットフォームエンジニアリングは、迅速なフィードバックと信頼できるシステムを構築することに焦点を当てており、リスクを最小限に抑えた実験を可能にします。失敗がある程度許容範囲になるのは、ダメージの影響範囲が抑えられ、可能な限り自動的な回復が望めるからです。私のプロジェクトでは、実験と学習の文化を、次のような形で構築しました：

組織に対して障害復旧のコーチングを行い、Game dayを導入しました。
Game dayとは、プラットフォーム上で多数の障害を発生させたり、シミュレーションしたりすることで、耐久力をテストする実験や演習のことです。このようなイベントは、チームとしての失敗への取り組み方を鍛錬するとともに、プラットフォーム上のアーキテクチャや処理に弱点が存在しないかを特定でき、組織としての学びの機会となります。
「小さな変更」と「フェイル・フォワード」の考え方を強調しました。私は、失敗を前提として技術的判断を行うなど、学びとしての失敗の重要性を頻繁に話していました。例えば、我々のブランチ戦略やCICDプロセスは、標準的なGitflowにおけるhotfixなど、特殊なワークフローが発生しないように構築しました。代わりに私は、各々の作業の大きさを正しく把握できるようにシステムを設計、組織をコーチングし、小さな失敗は小さな修正で解決できるような状態を作りました。
より安全に実験を行える独立した環境を開発者に提供しました。このプロジェクトでのプラットフォーム設計の主なテーマの一つに、開発者が他の誰にも、他の何にも影響を与えずにAWSのインフラ上で作業を行える環境を準備するというものがありました。このテーマのもとに、開発者がプッシュを行った際に一時的な環境が構築され、破棄されるようにCICDの設計を行いました。これらの環境は、開発者の作業用リポジトリ（作業用ブランチ）向けに完全に分離された、その開発者固有の環境でした。

最後に

ご覧の通り、プラットフォームエンジニアリングに関わる作業はDevOpsの３つの方法と非常に良く合致しています。大きな組織がDevOpsの変革を始めた時、多くの場合、彼らはすでにプラットフォームエンジニアリングチームを編成し始めています。そのようなチームの中で、PEたちは自分たちの仕事をこなし、組織全体と共有することで、すばやくDevOpsを理解し、DevOpsの提唱者となります。PEはテック企業の接着剤と言われているように、プラットフォームエンジニアリングチームが前進することで、組織自体も前進することになるのです。あらゆる種類の大規模な変革が困難であることは周知の事実ですが、DevOpsのようなカルチャーの変革はその中でも特に困難です。なので、もしあなたの組織が動き始めている、あるいは途中で失速しているのであれば、プラットフォームエンジニアリングチーム以上に変革を促進するリーダーは存在しないでしょう。

注：

「伝統的な組織」や「伝統的なIT」などの表現を用いている時は、クラウドやDevOpsが到来する前の時代の組織のことを指しています。これらの組織は、IT部門を「後付け」のように捉えていることが多く、また、開発手法もウォーターフォールが中心でした。
Gene KimはおそらくはDevOpsの真髄ともいえるThe Phoenix Projectの著者の一人で、DevOpsコミュニティ内でよく知られている人物です。この本の中で紹介されている３つの方法（The Three Ways）は、とあるITディレクターが彼の組織のDevOps変革を通して実践したストーリーとして書かれています。まだお読みでない方は、ぜひ一度お読みいただくことをおすすめします。
本記事を簡潔なものにするため、記事内で示したPEの仕事がDevOpsの３つの方法に合致する例は、ほんの一握りにすぎません。また、プラットフォームエンジニアリングという分野自体も比較的新しいものであるため、各組織におけるプラットフォームエンジニアリングチームの役割は少しずつ違うものと推測します。スラロムビルドでは、プラットフォームエンジニアリングの中にDevOpsもSREも存在します。
この数年、DevSecOpsやDevSecFinBizOpsなど、新たなDevOpsの「味付け」が登場しています。これらは、Development（開発）とOperations（運用）を統合することだけに焦点を当てたカルチャーから脱却するためのものです。本記事内でDevOpsについて話すとき、私は暗にプロダクトエンジニアリングに関係するすべてのグループや関係者を含めて話しています。
また、DevOpsの変革はPEだけではなくあらゆるポジションから推進されるべきで、PEだけがDevOpsの変革を推進するのに適していると言いたいわけではありません。これは、PEの視点から見た私の感想です。実際、本記事の内容は、エクストリームオーナーシップと呼ばれるもう一つのカルチャーコンセプトとも合致しています。最近、私の同僚はDevOpsDaysにてプレゼンテーションを行いました。そのプレゼンテーションの中で彼らは、どのような責務をもつ人であろうと、システムをリードし、オーナーシップを持つことができるかについて論じています。

この記事が気に入ったらサポートをしてみませんか？