2006年にAmazonのCTO ワーナー・ヴォゲルスが発言した「You build it, you run it」という言葉。この言葉が示すとおり、真の価値を提供していくためには開発者が運用フェーズにまで携わることが重要だとされている。
本記事では、「Developer eXperience Day 2024」（主催：日本CTO協会）にておこなわれた、PagerDuty株式会社の草間さんによるセッションを紹介する。真のDevOpsを実現するための方法について、草間さんが発表した。
草間 一人 さん
PagerDuty株式会社プロダクトエバンジェリスト。プロダクトエバンジェリストとしてPagerDutyやインシデント管理の啓蒙活動に携わる。一般社団法人クラウドネイティブイノベーターズ協会 代表理事、Platform Engineering Meetup/Kaigiオーガナイザー。
目次
PagerDutyの概要とシステム運用を取り巻く現状
PagerDutyは、インシデントをより早く、少ないリソースで解決していくためのプロダクトです。DatadogやSplunkなどのツールで監視をしていて、なんらかの問題が発生するとアラートが送られてきます。それをPagerDutyに送ってもらうと、フィルタリングをして必要なアラートだけに絞り込んでエンジニアに通知するプロダクトです。
みなさんもご存じのように、今年に入ってから大きなインシデントが続いています。商品が出荷できなくなったり、Webサービスが数か月間ダウンしてしまったりと経営にも大きな影響を及ぼしています。そういったインシデントが長期にわたってしまうと、IT部門だけではなく経営にとっても大きなリスクです。
なので、インシデントには素早く対応していかなければなりません。とはいえ、対応するための課題も多くあります。
私がエンジニアとしてデビューしたのが約15年前です。そのときと比べると、システムの複雑さが全然違います。いろいろなシステムが複雑に絡み合って動いている時代です。しかも10数年前からのレガシーシステムが残り続けていて、継ぎ足しで巨大なシステムが存在するところもあります。
こうした複雑な状況のなか、トラブルが起きたときにいかに対応していくか。いろいろな会社が直面している課題と言えます。
フルサービスオーナーシップとは
ここからフルサービスオーナーシップの話をしていきます。「コードを書いた者が、その責任を負う」ことをフルサービスオーナーシップと呼んでいます。設計と実装の点から見て、テクノロジーにもっとも精通した人が、製品開発ライフサイクル全体の責任を引き受ける運用モデルです。
本番環境において、自分が書いたコードの責任を負うように、もっともシンプルな形でエンジニアに権限を与える考え方です。「You build it, you run it」というAmazon CTOのワーナー・ヴォゲルスの言葉をご存じの方も多いと思います。同じことを言っていますよね。
製品開発ライフサイクルをシンプル化すると、「Build」「Test」「Ship」「Run」となります。
ただ、DevOpsという言葉が2009年に登場して、責任範囲の境界はあいまいになってきました。開発担当と運用担当でざっくりと分かれているのが現状です。
これで問題なく回っている方も多いと思いますが、「おお！」と思った表現があったので紹介します。それが「障害のほとんどはデプロイによって引き起こされる」という言葉です。『エレガントパズル エンジニアのマネジメントという難問にあなたはどう立ち向かうのか』（日経BP）からの引用です。これ、たしかにそうだなと思いました。
直感的に8割くらいは新しくサービスリリースしたあと、問題に気づくんですよね。もちろん、動かしている環境自体のトラブルによって起きる問題もあります。
では、さきほどのDevとOpsに分かれている図に戻って、障害が起きているのはどちらかと考えると右のOpsになります。なので、Opsの人たちが気づいて対処していくことになるのですが、原因はDevの過程によって起きていますので、直せるのもDevの人たちなんですよね。
DevとOpsで組織が分かれていると、コミュニケーションが必要になり、時間がかかってしまいます。そこでフルサービスオーナーシップという考え方が出てくるわけです。もっともくわしい人が全体を見る考え方にすれば、コミュニケーションを減らして素早く対応できるようになります。
DevOpsという考え方も15年前に登場して、いろいろと解釈が分かれていると思いますが、ある意味で「真のDevOps」をやっていこうという話に近いです。
コードに責任を持つメリット
自分のコードに責任を持つ開発者は、エンドユーザーエクスペリエンスに大きな影響を及ぼします。自分たちのサービスが、どのようにユーザーへ影響するかを体験できて、ビジネスのなかでの影響も見えるようになるわけです。開発者のモチベーションを高めるだけでなく、なにか問題がある場合は修正するスピードアップにもつながります。
サイロ化している組織だとサポートが別にいて、そこからのフィードバックになるのですが、それだと生の声ではありませんよね。コードに責任を持てば、自分自身で問題を確認できます。
あとは、品質管理のループが生まれます。責任を持つことで、運用面も含めて品質を向上させていこうというモチベーションにつながっていくわけです。
また、組織構造ではなく、提供するものに集中できます。組織で分かれていると、どのチームの誰が担当なの？ という感じになることがよくあると思います。フルサービスオーナーシップの形を取れば責任者が明確になり、シンプルです。さらに、自分たちがその場で直せるので、MTTR（平均修復時間）削減にもつながります。
でも、現実問題として本当にうまくいくのか？ と疑問に思うのではないでしょうか。分業化されているのは、メリットがあるからではないのか？ と思われる方もいるはずです。もちろん、分業にも明確なメリットがありますし、否定しているわけでもありません。ここで言いたいのは、「責任はすべて自分で取れるように考えましょうねと」いう考え方です。
フルサービスオーナーシップを実践するうえでの2つの課題
現実問題として、フルサービスオーナーシップには「認知負荷」と「オンコール」の課題があります。さきほど、真のDevOpsについて話しました。開発者がアプリをエンドツーエンドでデプロイして実行することが理想です。技術的には可能ですが、現実的ではないですよね。やりきれる人材はたまにいますけど、それに依存したチームをつくるのは、おそらく悪手です。
認知負荷について、わかりやすい図があるので紹介します。
2015年ごろから状況が変わってきていて、コンテナやKubernetesなどのクラウドネイティブ技術が登場したことで、開発者の認知負荷は増大しました。それがこの10年弱の動きです。
こうした状況をどうするか、いろいろなチームが試行錯誤してきました。そのなかで、アンチパターンの罠も結構あります。やりがちだなと思ったものがあったので、持ってきました。
チームのなかにDevOpsのような、開発からリリースまでできる体制をつくります。DevチームのなかにOpsが1人みたいな形です。分業として悪くないように思えますが、これができるのはチームのエースなんですよね。チームとしては回るけれど、エースがほかの仕事をできなくなるため、そのぶん出力は落ちているかもしれません。なので、いわゆるシャドーオペレーションになり、チーム全体のポテンシャルを活かしきれない状況が起きている可能性もあります。
チームトポロジーとは
考えはじめると、そもそもDevとOpsというチーム分け自体が正しいんだっけ？ という気になってきます。そこで最近出てきている考え方が「チームトポロジー（Team Topologies）」です。『チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計』（日本能率協会マネジメントセンター）という本に書かれています。とてもいい本なので、まだ読んでいない方はぜひ読んでください。
チームトポロジーでは、次の4タイプのチームが定義されています。それが「ストリームアラインドチーム」「コンプリケイテッド・サブシステムチーム」「イネイブリングチーム」「プラットフォームチーム」です。
チーム間の関わり方は「コラボレーション」「X-as-a-Service」「ファシリテーション」の3つがあり、これらによってスケールして機能するチームが組めると説明されています。
「コンプリケイテッド・サブシステムチーム」「イネイブリングチーム」については、今回は直接関係しないので割愛します。
ストリームアラインドチームは、価値ある単一の仕事のストリームに沿って働くチームです。ストリームというのは、ビジネスドメインや組織の能力に沿った仕事の継続的な流れを指します。
サービスチームには、開発者だけがいるわけではなく、職能横断型です。サービスを管理したり、設計・開発をして、顧客サポートまでの能力をチーム自体が持っている必要があります。1つのストリームのなかで必要なものはすべてチームが備えている状況に持っていきます。チームメンバーごとに専門分野はあるけれど、それだけをやるわけではなくて、ほかの部分でもチームに貢献していくものです。
ただ、そうするとうまく回らなくなってきます。愚直におこなうと認知負荷の問題がありますし、チーム内の得意な人に任せるのでは、さきほど説明したアンチパターンの話と変わりません。そこで出てくるのが、プラットフォームチームです。ストリームアラインドチームが開発し、リリースしてサポートできるようにするために、ツールやドキュメントなどのプラットフォームを提供します。この提供するものを表現した言葉が「ゴールデンパス」です。ストリームアラインドチームは、プラットフォームチームが提供するゴールデンパスに沿って進めることで、少人数であっても細かいことを考えずにライフサイクルを回せるようになります。
プラットフォームチームが社内向けのプラットフォームをつくり、開発者の認知負荷を下げていくわけです。この辺りの分野をプラットフォームエンジニアリングと呼んでいて、注目を集めています。
このようにフルサービスオーナーシップを実現するためには、プラットフォームチームを用意して、開発者の認知負荷を下げていくことが大事です。
オンコールで決めておいたほうがいいこと
フルサービスオーナーシップを実践するうえで、もう1つの課題としてオンコールがあります。運用で緊急事態が発生した場合にすぐ対応できるように待機する勤務形態ですね。担当者にとっては負担のある勤務形態です。
フルサービスオーナーシップの場合、開発者もオンコールのローテーションに入ります。オンコールでは、エスカレーションポリシーを決めていくことが大事です。3段階のエスカレーションポリシーが標準的で、アラートが発生した場合にまずは1段階目の人が受け取ります。場合によっては出られないこともあるので、その場合は2段階目の人が受け取ります。その人も受け取れなかった場合は3段階目の人たちが受け取る形です。
開発者がオンコールに入ってしまうと、そもそも生産性が下がるのでは？ という疑問があるのではないでしょうか。結論としては、少なからず影響はあります。大事なのはチームとしてサービスに責任を持つことです。開発者が1人で深夜までオンコールにも対応していたら、生産性は当然下がります。そうならないように、チームとしてオンコール体制をつくっていくことが重要です。
結果としては似ているのかもしれませんが、「開発者に運用もやらせる」のではなく、「ライフサイクル全体に責任を持たせる」ことが大事です。そうすれば、オンコールにならないようにインシデントの発生を減らしていく仕組みを考えたり、インシデントが発生したときの工夫を考えたりします。すべてに責任を持つことにより、結果的にインシデントを減らして品質が上がっていくことになるわけです。
ぜひフルサービスオーナーシップを実践して、よりよいシステム運用を目指していただければと思います。
取材後記：コードを書いた者が、その責任を負う
今回のセッションで、はじめて「フルサービスオーナーシップ」という言葉を知った。テクノロジーにもっとも精通した人が、製品開発ライフサイクル全体の責任を引き受ける運用モデルということで、理にかなっている考え方に感じる。
セッションのなかで、2冊の書籍が紹介された。1つが『チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計』（日本能率協会マネジメントセンター）。もう1つが『エレガントパズル エンジニアのマネジメントという難問にあなたはどう立ち向かうのか』（日経BP）だ。草間さんのセッションで発表された内容を深く学びたい方は、読んでみてはいかがだろうか。
（取材／文：川崎博則）
