いわゆる devops （platform engineering と呼んでいる）において、インフラ自体をひとつのプロダクトとみなして他のプロダクションチームに、一貫したやり方で提供することに価値があると筆者はいう。そして以下はこれに関して見聞きしてきた知見をまとめたチェックリスト。ただしこれをすべて守ることが必要だといっているわけではない。特にスタートアップを念頭に書かれていて、早めに基盤の構築に投資しておくことを薦めている。
- 1. システムがコードによりプロビジョニングされている。
- このリストの中でもイチオシ。
- ハードをセットアップする時間を節約し、システムの他の部分を組み立てるための部品を手にすることができる。
- 2. フィーチャーチームに配属されているエンジニアはプロダクション環境を触る権限がある。
- プラットフォームチームがプラットフォーム自身に忙しかったら、他のチームの面倒を見ている余裕はないはず。開発チームにツールや権限を渡し、どうしても必要なときに呼んでもらうようにする。
- 3. プロダクションのアプリケーションは Twelve-Factor App である。
- 4. 監視とアラートの設定は集約化されていて、必要なら簡単にアクセスできる。
- 開発者の速度向上と、システムのドキュメント化のため。アラートはシステムのどこに問題があるかを明確にする。
- 5. システムは人の手を借りず自動的に異状から復旧する。
- まともなシステムであれば復旧方法は if-then で表されているべきで、そうであれば自動化可能なはず。
- もし自動化できる範囲を超えて人間にメールを送る場合は、何をすべきかではなく、何が行われたかを情報として含める。
- 6. 毎日の管理タスクは自動化されている。
- さらに進んで「開発者がプロダクションに SSH する必要があってはいけない」という話もあるが、筆者はここまでは求めない。
- 7. 設定データは中央リポジトリに置かれ、アプリケーションは最新の設定を反映する。
- これの実現はデプロイ環境によりまちまち。
- 8. 開発環境はプロダクション環境を反映している。
- 9. アプリケーションはデプロイ先の環境に依存しないランタイムを提供される。
- 長年動いているアプリにどれだけパッチが当てられているか誰にも分からないとか、デプロイ環境に置いてあるファイルが実は利用されているとかいうのはホラー。
- 10. ひと月に一度以上デプロイされるシステムはコーヒーを淹れるよりはやくデプロイできる。
- デプロイして確認するのに発生するインタラプトはバカにならない。
- 何かあった時にすぐに直せるというのは大事なセーフティネットである。
- 11. 開発環境はプラットフォームチームのプロダクション環境である。
- プラットフォームチームが気にかけなければならないものがプロダクション。
- ここに不整合が起きるとプラットフォームチームのプロダクトへの信頼が損なわれてしまう。
- 12. プラットフォームチームは現在のニーズのみならず、将来におけるそれをも考慮にいれる裁量をもつ。
- スタートアップの最初期ならばこのリストに従っている必要はないが、将来組織が拡大してもそのままでいてはいけない。
- 早めに投資しておくことで、生じうるコストを小さく抑えることができる。
