プラットフォームチームが作った高速道路を誰も使わないとき
新しい社内プラットフォームをリリースしてから数ヶ月後、奇妙なことが起こる。プラットフォームチームのダッシュボードはきれいに整っている。ゴールデンパスはドキュメント化されている。パイプラインは標準化されている。すべてが正しく見える。
しかし、アプリケーションチームはそれを使っていない。
代わりに、彼らは自分のラップトップからデプロイスクリプトを実行している。公式パイプラインを通っていないDockerイメージをプッシュしている。ターミナルから直接データベースマイグレーションを実行している。彼らが反抗的だからではない。プラットフォームがもはや彼らの働き方に合わなくなったからだ。
これは技術の失敗ではない。プラットフォームを生きたサービスではなく、完成品として扱ったことの失敗である。
チームが社内プラットフォームを放棄する理由
トラブルの最初の兆候は、たいてい摩擦である。プラットフォームは6ヶ月前に特定のバージョンのベースイメージで構築された。それ以来、アプリケーションチームは設定を管理する新しい方法を採用した。プラットフォームはそれをサポートしていない。そこで彼らは回避策をとる。
その回避策は小さなショートカットから始まる。ここにスクリプト、あそこに手動ステップ。時間が経つにつれて、これらのショートカットは非公式のパスになる。監視されていない。セキュアでもない。そして、何かが壊れるまでプラットフォームチームには見えない。
根本原因はほとんど悪意ではない。アプリケーションチームは、プラットフォームのルールに従うことではなく、機能を提供することで評価される。プラットフォームが彼らを遅らせるとき、彼らはより速い方法を見つける。プラットフォームチームが気づかなければ、公式と実際のデプロイプラクティスのギャップは、プラットフォームが無関係になるまで拡大する。
プラットフォームをプロダクトのように扱う
最も効果的なプラットフォームチームは、自分の仕事をインフラストラクチャとして考えるのをやめる。彼らはそれをプロダクトとして考え始める。ユーザーはソフトウェアを購入する顧客ではない。彼らは毎日コードを出荷する必要がある他のエンジニアリングチームである。
プロダクトチームは機能をリリースして立ち去らない。彼らは人々がどのようにそれを使うかを見守る。何がフラストレーションを引き起こしているかを尋ねる。反復する。プラットフォームチームも同じ考え方を必要とする。
これには正式なプロダクトマネジメントプロセスは必要ない。簡単な習慣から始めることができる：
- アプリケーションチームの代表者と定期的に話し合う。今週何が彼らを遅くしたか尋ねる。
- 四半期ごとに短いアンケートを実施する。可能なら何を変えたいか尋ねる。
- 人々がプラットフォームについて助けを求める回数を追跡する。それぞれの質問は、何かが明確でないか、機能していないというシグナルである。
フィードバックは常に快適とは限らない。チームは、ビルドプロセスが遅すぎる、ドキュメントが古い、自動化すべき手動ステップがあると言うかもしれない。それは批判ではない。それはロードマップである。
プラットフォームを最新に保つ
プラットフォームの更新は、単にツールのバージョンを上げることではない。デプロイパスをチームが実際に働く方法に合わせ続けることである。
チームがフィーチャーフラグをより頻繁に使い始めたら、プラットフォームはそれらを安全に管理する方法を提供すべきである。コンポーネントにセキュリティ脆弱性が見つかった場合、誰かに悪用される前にプラットフォームを更新しなければならない。ランタイムの新しいバージョンが依存関係の解決方法を変更した場合、チームが壁にぶつかる前にプラットフォームが適応すべきである。
更新はクリーンアップも意味する。すべてのプラットフォームには、古いパイプライン、未使用のスクリプト、古びた環境が蓄積される。放置すれば、これらは罠になる。新しいチームメンバーが、正しく見えるがセキュリティチェックのない古いパイプラインを見つけるかもしれない。彼らはそれを実行し、今や本番環境には誰も計画していなかったギャップが生まれる。
古いパスをクリーンアップするには注意が必要である。チームが依存しているものを警告なしに削除することはできない。ここで非推奨ポリシーが役立つ。それは単純な合意である：パスや機能が廃止される場合、プラットフォームチームは早期に発表し、理由を説明し、移行ガイドを提供する。驚きはない。突然の破損もない。
放置されたプラットフォームのコスト
メンテナンスされていないプラットフォームは放棄される。チームは独自のデプロイ方法を構築し、それらの方法は一貫性がなく監視されない。プラットフォームチームはまだ存在するが、誰も信頼しないものを維持していることになる。
ユーザーとともに進化するプラットフォームは、チームが働きたいと思う場所になる。彼らはデプロイ方法について考える必要がない。プラットフォームは、安全で高速で、彼らが実際にソフトウェアを構築する方法に合ったパスを提供する。
それが起こるとき、デプロイは各チームが自分で解決する技術的な活動ではなくなる。それは会社全体が頼りにできる組織的な能力になる。
プラットフォームチームのための短いチェックリスト
プラットフォームを担当している場合、定期的に確認すべきことがいくつかある：
- 最後にアプリケーションチームと彼らをフラストレーションさせていることについて話したのはいつか？
- チームが監視していない非公式のデプロイパスはあるか？
- 非推奨ポリシーはあるか、それとも物事はただ消えていくだけか？
- ゴールデンパスのベースイメージと依存関係を最後に更新したのはいつか？
- チームが同じ問題について複数回助けを求める必要があるか？
これらの質問はツールについてではない。プラットフォームがそれに依存する人々にとってまだ有用かどうかについてである。
プラットフォームの真の尺度
プラットフォームは、きれいなドキュメントや美しいダッシュボードがあるから成功するのではない。誰も見ていないときでも、チームがそれを使うことを選択するから成功するのである。
チームが独自のショートカットを構築する代わりに公式パスに従うことを決めた瞬間、それがプラットフォームがその価値を発揮する瞬間である。そして、その信頼を得る唯一の方法は、耳を傾け続け、更新し続け、もう機能しないものを削除し続けることである。