プラットフォームはコラボレーション システムであり、インフラストラクチャではありません。文化は構造に従う: プラットフォーム チームはオープン サポート セッションを作成し、貢献した開発者に対するトップ ユーザー賞を作成し、エンジニアリングの考え方を開発するための共通のオープン標準を確立できます。KubeCon および CloudNativeCon Europe での銀行におけるクラウド ネイティブ文化の構築に関する講演で Marcy Paramononova 氏と Stephane Cusin 氏は説明しました。
開発者と製品チームはプラットフォーム チームに依存しているとパラモノバ氏は言いました。プラットフォーム チームはアプリケーション チームに依存しており、両方とも前進する必要があります。そのためには共通の基準が必要です。
プラットフォームはインフラストラクチャではありません。これは、多くのコミュニケーションが通過するコラボレーション システムであると、Paramononova と Cusin が「プラットフォームの作成におけるオープンソースによるコラボレーションの実現方法」で説明しました。
クラウド ネイティブは単なる技術的な変化ではなく、文化的な変化です。彼らの変革の旅には文化的な変化も必要だったとパラモノワ氏は主張した。プラットフォーム チームは、開発者が参加して一緒に問題を解決できるオープン サポート セッションの提供を開始しました。
私たちは、通常のドライバー チケット サポートから離れて、ユーザーに新しくて新鮮なものを提供したいと考えていました。インフラストラクチャ、サイバーセキュリティ、ネットワーク、アイデンティティ、クラウドのチームを含む多くの人々が関心を持ちました。私たちは一緒に座り、解決策を共有し、協力して問題を解決するのを支援します。
すべてのアクションにチケット、手動介入、またはプラットフォーム エンジニアからの直接サポートが必要な場合、私たちは意図せず依存の文化を生み出してしまうだろうとカズン氏は言います。チームは独自に学習して運用するのではなく、プラットフォーム チームを待つことになります。
Paramonova 氏は、プラットフォームの採用を表彰するイベントを作成したと述べました。彼らは、プラットフォームの改善に積極的に貢献した開発者にスーパー ユーザー賞を導入しました。
彼らのフィードバックは、時には聞き取りにくく、少し苦痛なものでしたが、実際に私たちがより良い、より優れたものを作成するのに役立ちました。ですから、私たちはそのことに感謝しています。
彼らが組織した活動は、人間の能力の認識と評価の仕方を変えました。
オープンソースをオープンスタンダードで使用すると、スキルは非常に応用可能になる、とパラモノバ氏は語った。あなたは何かを一から学び直すわけではありません。オープンテクノロジー全体で共有される共通の基盤の上に構築されている、と彼女は付け加えた。
エンジニアリングの考え方が最も重要であるとパラモノワ氏は主張しました。それはあなたが今日知っていることではなく、新しいテクノロジーを使用、学習、実行、運用する能力と能力です。
エンジニアになるということは、問題を解決し、それに情熱を持ち、問題解決に対する情熱を共有することです。
文化は構造に従います。文化が自然に出現するのを待つことはできません。カズン氏は、自分が望む文化を生み出すシステムを設計する必要があると説明しました。
自分のチームがいつも邪魔されることに不満を抱いている場合は、他のチームを責めないでください。自問してみてください: 人々があなたに連絡するための構造を定義しましたか?
Kubernetes が変革したのはプラットフォームだけではありません。これにより、私たちの組織がソフトウェアを構築する方法が変わりました、とカズン氏は結論付けました。
InfoQ は講演後、Marcy Paramononova 氏と Stephane Cusin 氏にインタビューしました。
情報: エンジニアリング文化は時間の経過とともにどのように変化しましたか?
ステファン・カズン：私たちが初日から確立した原則は、プラットフォームの機能が手動介入に依存すべきではないということでした。チケットを開いてエンジニアが変更を加えるのを待つ代わりに、チームは宣言型構成と自動化されたワークフローを通じてプラットフォームと対話します。たとえば、機能の有効化は Git の簡単な構成変更で行うことができ、これは GitOps プロセスによって自動的に適用されます。これにより、セルフサービス エクスペリエンスが実現されると同時に、プラットフォームの導入に対する完全な追跡可能性と可視性が提供されます。
このアプローチにより、プラットフォームの運用方法が変わりました。これで、どの機能が採用され、どの機能が不要になり、どのユーザーが変更の影響を受けるかを理解できるようになりました。これにより、未使用の機能を安全に廃止し、チームを新しいプラットフォーム機能に自信を持って移行できるようになりました。
InfoQ: 確立したい文化を生み出すシステムはどのように設計しましたか?
マーシー・パラモノワ: 文化を強制的に存在させることはできませんが、特定の行動を自然にする構造を設計することはできます。私たちにとって、それはコラボレーションについて話すのではなく、コラボレーションを中心とした儀式を構築することを意味しました。
私たちは週に 2 回、各セッション 2 時間の「Genius Bar」を開催しています。プラットフォームについて質問がある場合、何かが期待どおりに動作しない場合、コンポーネントがどのように連携するかを理解したい場合は、そこに来てください。チケットも必要ないし、誰かのカレンダーが開くのを待つ必要もありません。混乱したり苦痛なことがあったときにすぐに聞くことができるため、フィードバック ループが短くなり、私たちが正直に保つことができます。
また、ユーザー インサイト セッションも開催し、優先順位、完了した作業、獲得した可視性を共有し、ユーザーのためではなくユーザーと一緒に優先順位を付けます。そして、私たちはデモを行って、何が提供されるか、何がロードマップに載っているか、そして今日のプラットフォームを実際に使用する方法を示しています。
社内では、プラットフォーム チームが独自の計画セッションを開催し、連携を保ち、単なる事後対応的な作業ではなく、意図的な決定を行う余地を確保しています。
これはどれも革命的ではありません。しかし、これらのリズムを積み重ねると、あなたが構築している構造から、あなたが望む文化が現れ始めます。それは魔法ではありませんが、ランダムでもありません。
料理: 私たちはプラットフォームの決定を可視化しようとしました。プラットフォーム機能は、チーム間の個別の合意を通じてではなく、バージョン管理された成果物、再利用可能な実装パターン、文書化されたインターフェイスを通じて提供されます。これにより、組織全体に一貫性と共通の理解が生まれます。
もう 1 つの重要な設計原則は、すべてのプラットフォーム機能にはライフサイクルがある必要があるということでした。私たちは、機能を誰が使用しているか、どのように使用されているか、そしてそれがまだ価値を提供しているかどうかを知りたかったのです。この可視性により、時間の経過とともに複雑さを蓄積するのではなく、プラットフォームを意図的に進化させることができます。
多くの点で、私たちのプラットフォームは、チケットベースの操作よりもセルフサービス、カスタマイズよりも標準化、部族の知識よりも透明性、少数の専門家に依存するよりも所有権の共有など、私たちが奨励したいと考えていた行動を強化するためのメカニズムとなりました。
これらの原則がプラットフォーム自体に組み込まれると、望ましい文化が人々にとって最も働きやすい方法になります。
