はじめに
2009年に John Allspaw と Paul Hammond が DevOps についてプレゼンした当初から、 DevOps の課題はいかに Dev と Ops の対立を解消し、組織のアジリティを上げるかでした。
DevOps はこの対立を Dev と Ops のコラボレーションやツールによって解決しようとしましたし、 SRE は厳密な SLO とエラーバジェットの適用によって、あるいは運用をソフトウェアエンジニアリングの領域に持ち込むことによって解決しようとしました。また、「You build it, you run it」や「Full Cycle Developers」などの考え方は開発エンジニアが一緒に運用（などを含めた周辺領域）も行うという手法で解決を試みました。
もちろんこれらは全て有効な手段ですが、 SRE や Full Cycle Developers はかなり高度で洗練された組織でしか適用できないジレンマがあります。ほとんどユーザーのいないスタートアップで SLO を理由に開発を止めることができるでしょうか？あるいは小さな会社に開発も運用もできるスーパーエンジニアがごろごろいるでしょうか？
ある意味で SRE も Full Cycle Developers もそれぞれ Google や Netflix だからこそ可能なアプローチであるといえます。しかし、だからといって SRE が全くの夢物語であるというわけではありません。 SRW 本にあるように、具体的な事例から学べることは数多くあります。
Dev と Ops の対立を解消するには上のような3パターンしかないのか、あるいは他にも第4のアプローチがあるのか、この一年間私はその答えを考えてきました。そして、ある考えが閃きました。開発チームと運用チームが広い意味で同じ組織に所属しており、両方の責任者が同じであれば対立を解消することができるのではないかという仮説です。
CSRE
便宜的に、この「開発チームと運用チームが広い意味で同じ組織に所属しており、両方の責任者が同じである」という組織構造を CSRE (CAMPFIRE SRE) と名付けます。
通常の DevOps はあくまでチーム間でのコラボレーションなので、理論上は対立する余地が残ります。なぜなら開発チームのモチベーションは数多くの開発を短期間でデプロイすることにある一方で、運用チームのモチベーションは可能な限り可用性を高く保つことだからです。
しかし、 CSRE の場合、責任者が同じなのでその意味での対立は発生しません。開発が進まない時も可用性が下がっている時も、その責任者が然るべき責任を負って判断すればいいだけだからです。ここでのメンバーの評価は開発速度や可用性と連動していません。
また、 SRE のように厳密に数値のみに依拠していないため、より柔軟なコントロールが可能になります。もちろん、この辺りは諸刃の剣でもあります。
初日のアドベントカレンダーで書いたように、たまたま私が今期から開発チームと SRE チームのマネージャーを兼任することになり、偶然にもこの思考実験を試せる環境が生まれたので、これまで採ってきたアプローチを書いていきたいと思います。
評価
上記の通り、開発速度や可用性を評価の軸にしてしまうとチーム間での対立が発生してしまうため、開発チームと運用チームの評価は包括的な総合評価としています。しっかりとした基準がないと評価が難しいのはその通りなのですが、その点については私がバックグラウンド的にかなり組織の開発や SRE について理解している人間であることと、頻繁にコミュニケーションを取ることで解決しています。
ミーティング
どちらも私が責任者のチームではあるのですが、一緒にすると人数が多くなるのと、役割が異なるのでミーティングは別にしました。今は開発チームも SRE チームも毎朝10~15分程度のデイリースタンドアップを行っており、私は両方のミーティングに出ています。
ここでは「昨日やったこと」、「今日やること」、「困っていること」などを話しており、頻繁にコミュニケーションを取ることでチームとしてのアジリティを高めています。また、それぞれのチームでリードエンジニアを立てることで、私への依存を減らし、同じ組織でありながらある程度独立して動くことができるようにしました。
一方で、お互いに交流する機会が全くないと一緒の組織になっているメリットが薄れてしまうため、定期的に社内交流会を開催してお互いにコミュニケーションを取ることができる環境を作りました。初日の記事で書いた個人チャンネルや質問チャンネルもそのうちの一つです。
お互いの領域を補い合う
DevOps が解消するべき課題としてよく言われるのが、「誰も責任を取らず、非難ばかりしている」組織です。これはサイロ化が進み、誰も他の部署のことはわからないし、自分たちの仕事にさえ専念していれば良いのだという組織になります。この状態になると誰もオーナーシップを取ろうとはせず、コミュニケーションは停滞し、当然情報は共有されないので、結果として組織全体のパフォーマンスが下がってしまいます。
しかし、本当に大切なのは、部署間でサイロをなくしコラボレートすることで全体にとって最適な選択をすることであるはずです。
CSRE では Dev と Ops 同士が「誰も責任を取らず、非難ばかりしている」のではなく、「責任を取り、助け合う」ことができるように、いくつかの仕組みを導入しています。
Datadog
最近 CAMPFIRE では Datadog というモニタリングツールを導入しました。 Datadog のメリットは高機能であること、そして APM (Application Performance Management) が可能なことです。 APM はモニタリングツールなので基本的には SRE が責任を負いますが、アプリケーション側のモニタリングのため当然開発チームの協力も必要です。
このように、両方の領域をカバーするツールを導入することでコミュニケーションを活性化させ、開発エンジニアにもパフォーマンスについて意識してもらうようにしています。将来的にはパフォーマンスバジェットのようなものを導入して、設定したレスポンスタイムを超える場合は開発を見直すことができるようにしていきたいです。
運用当番
昨年のアドベントカレンダーでも書いたように、 CAMPFIRE では週単位の運用当番を設けています。これはアプリケーション側の運用なので、元々は開発エンジニアだけで担当していたのですが、新しい試みとしてここに SRE も入るようにしました。SRE も入るようにした理由は、大変な仕事は開発と運用で分け合うべきだと考えたからです。
SRE が外から SLO やエラーバジェットについて指摘し、開発エンジニアに改善を迫るのは簡単です。しかし、それが続けば開発側に SRE は非難ばかりで何もしてくれないという印象を与えてしまいます。
SRE がアプリケーション側の運用に入るのは大変ですが、慣れてくれば最初のトリアージや簡単なタスクはできるようになりますし、何よりも開発エンジニアに頼ることでポジティブなコミュニケーションが生まれます。開発エンジニアがモニタリングツールの見方で SRE を頼るように、 SRE もアプリケーション側の仕様について開発エンジニアに頼ることができるのです。
もちろん複雑な調査や修正は SRE ではできないため開発エンジニアに任せざるを得ませんが、少しだけでも大変な仕事を引き受けてくれたという感覚は結構大きいと思っています。また、 SRE 側から見ても、運用当番に参加することはドメイン知識の習得やコミュニケーションに繋がるため決して悪いことばかりではありません。
おわりに
このように、開発チームと運用チームが広い意味で同じ組織に所属しており、両方の責任者が同じであるという組織構造を取ることによって、 Dev と Ops の対立を解消することができます。実際にこの体制になってから、 Dev と Ops の対立は起こっていません。
一方で CSRE にも当然デメリットはあります。それは両方の組織を見る責任者に大きく依存してしまうということです。手前味噌ですが、今 CAMPFIRE でこれが実現できているのは、 長年 CAMPFIRE の開発や SRE に深く関わってきた私がいることと、両チームを合わせても人数がそこまで多くないという事情があります。 Google SRE と同様にそのまま全ての組織に適用できるものではないと思いますが、 状況が近い組織の方は Yet Another な選択肢として検討されてみてはいかがでしょうか。