「オペレーションルームに歩いて行く – もうこれ以上何もする必要はないと思う」

開発者のための最新の機能のリリース（訳注：英語サイトに飛びます）で、PagerDutyのシニアエンジニアDavid Yang氏と私は、私たちの内部アーキテクチャが単一のモノリシックなコードベースから数十のマイクロサービスの組み合わせにまで進化していくのを見てきました。

彼は、8000人以上のPagerDutyの全顧客にアラート通知を送信するサービスを所管するIncident Management – Peopleチームのテクニカルリーダーです。私たちは座って、彼らのサービスの運用について彼のチームがオーナーになるよう切り替えた後の生活について話しました。 私たちが見た利点と欠点に関するいくつかの観察を紹介します。

今はチームがサービスのオーナーになっています

開発者がサービスのオーナーになるモデルに移行して以来、開発者の独立性はますます高まっています。副作用は、インフラストラクチャのプロビジョニングと管理の難しさを最小限に抑えられたことです。現在、チームは邪魔と障害を最小化するように最適化したいと考えています。 インフラをサポートするチームは、人間の介入の必要性を最小限に抑えるために優れたセルフサービスツールを提供することに重点を置いています。

開発者がコードのオーナーになると、サイクルタイム、つまり「これは問題だ」というメッセージがどこかで表示されてから実際に問題を解決するまでの時間が短縮されます。これは非常に価値があります。

文化面での変化は

人々がより多くのコードのオーナーになり、自分たちが運営するシステムのために一般的にはより多くの責任を負うようになると、道を邪魔するものを排除することを重視する文化が広がります。各チームは、 「自分が今まで、あるいは将来ブロックされていないことを確認するにはどうするか」という考え方に向かって最適化されます。ブロックされるともっとはっきり分かります。以前は、ホストをプロビジョニングするたびに私は毎回運用チームに問い合わせなければなりませんでした。 私のチームは他のチームの障害物で隠されていないため、自分たちの障害物をよりはっきり見ることができます。

私たちには、エンドツーエンドの顧客価値を提供するプロセスのすべてを所有することに重点を置いたチームがあります。これは非常に貴重です。

インシデント対応プロセスではどうに役立つ？

サービスのオーナーシップの境界が明確になっています。運用の問題が発生した場合に、影響を受けるチームを簡単に特定できます。そして、自分が従うべき正しい手順、例えばそれは「これがそのチェックリストです」という客観的な手順ですが、それを知っているということが大事です。 これによって問題の解決に100％集中し、インシデント前後のコミュニケーションに集中することができます。

それほどうまくいかなかったことも

サービスのオーナーになっていても、そのサービスに問題が発生しないとは限りません。当社のサービスの運用維持に専念するためには、そのためだけに使う時間が必要です。 これが結局はチームの時間の多くを占めます。特に知識のギャップがあるレガシーサービスで問題になります。 当初は、私たちのスプリントでの作業性を守るために十分なガードレールを設置していませんでした。 これは客観的な意思決定を可能にするためにKPI（特定のスケーリング目標や運用負荷レベルなど）を活用することで改善されています。

将来は？

[業務関連のワークロードと機能開発ワークのバランスをとるため]各チームは、メトリックによって客観的な意思決定を推進するために、次のように問い続けています。「私はこうした道具を日常的にどう活用していますか？ どのようにして客観的な意思決定を行うのですか？」と。

私たちの製品開発はすべて、「顧客価値とは何か」、「成功基準とは何か」などで定義されています。私が思うに、同じセンスを持って業務を伝えようとすると、効果的に優先順位をつけやすくなります。 私たちはすべて同じチームに所属し、顧客に価値を提供するという同じ目標に向かっており、同時に、優先度の競合を解決する必要があります。

組織内の業務の中で変更を実行しようとすると、多くのコラボレーションが必要になります。 適切なメトリックが何であるかを把握し、それらのメトリックについて議論することも必要です。