異常を見つける仕組みを一つ足すのは、半日あればできます。ところが、見つけたあとに誰がどう閉じるかを同時に決めていないと、未処理の件だけが積み上がります。
当社もこれをやりました。見つける側だけを増やし続けた結果、一覧に赤が並び、どれが本当の異常かが分からなくなりました。増やすなら、見つける側と閉じる側は必ず一組で足す。これが当社の決めごとになっています。
溜まった一覧は、見る気そのものを削ります。赤が並んでいる状態に慣れてしまうと、本当の赤も同じ色に見えます。
閉じるとは、消すことではありません。次のどれかに落ち着かせることです。
自動で直った ── 決まった手順で回復し、記録が残っています。
人が直した ── 手を入れて解消し、原因が書かれています。
直さないと決めた ── 影響が小さいか、様子を見ると判断したものです。理由が書かれています。
三つめが抜けている仕組みは、いずれ詰まります。「直さない」も、立派な結論です。ただし、決めた人と理由は残します。
どれにも入らないまま一週間残っている件は、担当が決まっていないという意味です。そこだけは人が見ます。
自動で直せるのは、原因が分かっていて、直し方が一つに決まっているものに限られます。応答が返ってこなかったのでもう一度呼ぶ、順番待ちが詰まったので止まっているものを流し直す。この程度です。
直せる型は、少しずつ増やしていけます。人が同じ直し方を三回したものは、型として書き出す候補にしています。
反対に、原因が分からない失敗を自動で「直す」のは危険です。動きだけ元に戻り、原因が残ったまま見えなくなります。繰り返しの上限を決めておく話と同じ考え方です（B-04-2 繰り返しの上限と、戻し方）。
自動で直す仕組みを入れると、必ず一度は通る落とし穴があります。直そうとした事実だけを見て、緑にしてしまうことです。手を打った、だから解決した、と扱ってしまいます。
当社は、直したと言えるのはもう一度確かめて通ったときだけ、という線を引いています。実行しただけでは閉じません。この線が無いと、画面は緑なのに実態は止まったまま、という状態が生まれます。
確かめ直す手順は、直す手順とは別に書きます。同じ仕組みが「直した」と「直った」の両方を判定すると、判定は甘くなります。
失敗の扱いを人ではなく仕組みの側に向ける進め方は、運用の実務書でも中心に置かれています。Google SRE Book「Postmortem Culture」（英語）↗
直して終わりにすると、同じことが起きます。当社は、直した件から何が起きて、なぜ起きたかを一件ずつ残しています。
残す形が決まっていると、あとで似た事象を探せます。逆に、書き方が人によってばらばらだと、溜めても引けません。あとで引けない記録は、残していないのとほぼ同じです。
書く量は多くなくて構いません。起きたこと、原因、打った手。この三つがあれば、あとから探せます。
動かし続ける前提の仕組みでは、監視と手当てを設計の一部として組み込むことが前提になります。Google「本番環境の ML システム」↗
当社では、エラー 3,521件 から教訓の候補が 3,518件 生まれています。割合にすると 99.9% です（AIの中身）。ただしこれは拾えた割合であって、直った割合ではありません。
拾った候補のうち、実際に手当てまで進んだものは別に数えています。ここを混ぜると、拾っているだけの状態が、直っているように見えてしまいます。第6章で書いた話がそのまま出てきます（C-06-1 何を測るかを先に決める）。
拾えているだけの状態は、放っておくと積み上がります。ですから、溜まっている件数そのものを見張る対象に入れています。
ここまでで、続けるための見張り方が揃いました。最後の章は、続けるうえで避けて通れない費用の話です。
章と記事の全体は図書館の見取り図で一枚にまとめています。