第77条
作った者が運用する
サービスを作るチームが運用も担えば、運用上の弱点のコストは、それを直せる人のところに落ちる。
心得
直せる人が、起こされる人であるべきだ
どうするか
サービスをリリースしたチームを、そのサービスのオンコールに就ける。呼び出しの原因を直す権限とデプロイ権限も渡す。デプロイ、可観測性、アラートの共通基盤（舗装された道）とオンコールのローテーションを用意し、一人が全部を抱えないようにする。呼び出される対象を自分で変えられないチームには適用しない。それでは所有を渡したことにならず、呼び出しを押しつけるだけだ。
なぜ起きるか
ソフトウェアを壁の向こうの運用チームに投げ渡すと、呼び出しを受けて怒った顧客に向き合う人と、コードを変えられる人が別々になる。だから修正は遅れるか、回避策で終わる。自分のサービスで呼び出される開発者は、どの手抜きが痛いかを身をもって知り、夜中に起こされるのが自分なので障害を前提に設計する。運用していれば顧客とも日々接するので、苦情から変更までの距離も縮まる。ただしこの動機づけが働くのは、オーナーシップに実態があるときだけだ。呼び出しの原因になったものを、チーム自身が変えられなければならない。
当てはまらなくなるとき
開発者の認知負荷：開発から運用までを丸ごと持つと、開発者一人が知るべきことと毎週抱える優先事項が増える。共通の道具とオンコールのローテーションがなければ燃え尽きに行き着く。このモデルを採る Netflix も、幅より深さを求める人には、そうした役割を見つける手助けをするとしている。
出典
Jim Gray「A Conversation with Werner Vogels」『ACM Queue』4(4) (2006)。Amazon の CTO が、各サービスチームが作ったものを自分で運用する理由を語ったインタビューで、"You build it, you run it." の出典。トレードオフは Philip Fisher-Ogden, Greg Burrell & Dianne Marsh『Full Cycle Developers at Netflix — Operate What You Build』(Netflix Technology Blog, 2018) から。
原典を読む引用するとき
Hammurabi『第77条 作った者が運用する』 https://kanywst.github.io/hammurabi/ja/laws/you-build-it-you-run-it/
BibTeX
@misc{hammurabi-you-build-it-you-run-it,
title = {作った者が運用する},
author = {{Hammurabi contributors}},
note = {Hammurabi, § 77},
url = {https://kanywst.github.io/hammurabi/ja/laws/you-build-it-you-run-it/}
}