문제
운영 변경은 종종 범위가 머릿속에만 있다. 작업이 시작되면 경계가 넓어지고, 확인은 “잘 된 것 같다”로 줄어들며, 문제가 보여도 멈출 조건이 없어 계속 고친다. 끝나고 나면 원래 무엇을 바꾸려 했는지, 어디까지만 건드려야 했는지, 무엇으로 성공을 판단해야 했는지가 사라진다. 기록 없는 변경은 나중에 감사할 수 없다.
운영 패턴
1. 손을 대기 전에 완료 기록 네 칸을 먼저 채운다. 의도한 결과, 관찰 가능한 경계 하나, 검증 신호, 중단 또는 되돌림 조건.
2. 결과는 동사가 아니라 끝난 뒤의 상태로 적는다. “고친다”가 아니라 “이 입력이 이 출력을 낸다”처럼, 제삼자가 같은 문장을 보고 같은 대상을 가리킬 수 있어야 한다.
3. 경계는 하나면 충분하다. 손댈 대상의 이름, 손대지 않을 이웃, 또는 시간 창 하나. 여러 경계를 나열하지 말고, 넘으면 작업이 다른 작업이 되는 선 하나를 고른다.
4. 검증 신호는 변경 이후에 직접 읽을 수 있는 관측값이어야 한다. 작업 상태 문구가 아니라, 대상이 내놓는 응답·수치·화면 중 하나다.
5. 중단·되돌림 조건은 그 신호가 보이지 않거나 경계가 깨졌을 때 무엇을 멈추고 무엇을 되돌릴지 한 문장으로 적는다. 조건이 발동하면 새 수정을 더하지 않는다.
6. 네 칸이 비어 있으면 변경을 시작하지 않는다. 작업 중의 발견은 새 기록이 되지, 기존 경계를 조용히 넓히지 못한다.
왜 중요한가
완료 기록은 기억을 대신하지 않는다. 변경을 외부에서 감사할 수 있게 만든다. 결과·경계·신호·중단이 먼저 적혀 있으면, 나중에 남는 질문은 “잘 했는가”가 아니라 “약속한 결과가 그 경계 안에서 그 신호로 나타났는가, 아니면 멈췄는가”다. 그 네 문장이 없으면 성공과 사고를 구분할 기준이 없다.
완료 기준
네 칸이 변경 이전에 채워져 있고, 변경 이후에는 검증 신호가 그 결과를 확인하거나 중단 조건이 실행된 흔적이 남아 있을 것. 둘 다 없으면 작업은 끝난 것이 아니라 멈춘 곳이 없는 것이다.
Problem
An operational change often exists only as a private intention. Once work starts, the boundary widens, the check shrinks to “it looks fine,” and a visible problem has no stop rule, so the operator keeps patching. Afterward nobody can say what the change was meant to produce, how far it was allowed to reach, or what would have counted as success. A change without that record cannot be audited later.
Operating pattern
1. Fill four fields of a completion record before touching anything: the intended outcome, one observable boundary, the verification signal, and the stop or rollback condition.
2. Write the outcome as a finished state, not a verb. Not “fix it,” but “this input yields this output,” so a third person reading the same sentence can point at the same object.
3. One boundary is enough: the name of what may be touched, a neighbor that must stay untouched, or a single time window. Do not list many edges. Pick the line that, if crossed, makes this a different job.
4. The verification signal must be an observation you can read after the change — a response, a number, or a screen from the target — not a status label on the job.
5. The stop or rollback condition is one sentence: what you halt and what you restore if the signal is absent or the boundary breaks. When it fires, do not add another fix.
6. If any of the four fields is empty, do not start. A discovery mid-change becomes a new record; it does not silently enlarge the old boundary.
Why it matters
The completion record does not replace memory. It makes the change auditable from the outside. Once outcome, boundary, signal, and stop are written first, the later question is not “did it go well?” but “did the promised outcome appear inside that boundary, on that signal — or did the stop fire?” Without those four sentences there is no criterion that separates success from an accident.
Completion bar
The four fields are filled before the change, and after it either the verification signal confirms the outcome or there is a trace that the stop condition ran. Missing both means the work did not finish; it merely had nowhere to halt.
问题
运维变更常常只存在于脑子里。一旦动手，边界就会变宽，检查会缩成“看起来没问题”，出了可见故障也没有停止规则，于是继续补丁。事后没人说得出这次本该产生什么、允许影响到哪里、什么才算成功。没有这条记录的变更，日后无法审计。
运维模式
1. 动手前先填完完成记录的四格：预期结果、一条可观察的边界、验证信号、停止或回退条件。
2. 把结果写成结束后的状态，而不是动词。不要写“修好它”，而要写“这个输入会得到这个输出”，让第三人读同一句话时能指向同一个对象。
3. 一条边界就够：允许触碰的对象名、必须保持不动的邻居，或一个时间窗口。不要罗列许多边。选出那条一旦越过、这次工作就变成另一件事的线。
4. 验证信号必须是变更之后能直接读到的观测——目标给出的响应、数字或画面——而不是任务上的状态标签。
5. 停止或回退条件写成一句话：信号没有出现或边界被打破时，停下什么、恢复什么。条件一旦触发，就不再追加修补。
6. 四格有空就不要开始。中途的发现应写成新记录，而不是悄悄放大原来的边界。
为什么重要
完成记录不是用来代替记忆的，它让这次变更能从外部被审计。结果、边界、信号和停止先写下来之后，事后要问的就不是“做得好不好”，而是“承诺的结果是否在那条边界内、以那个信号出现了，还是已经停手了”。没有这四句话，成功和事故就没有区分标准。
完成标准
四格在变更之前填好；变更之后，要么验证信号确认了结果，要么留下停止条件已经执行的痕迹。两者都没有，说明工作并没有结束，只是无处可停。
問題
運用変更は、範囲が頭の中にしかないことが多い。作業が始まると境界は広がり、確認は「うまくいったように見える」へ縮み、問題が見えても止める条件がないので直し続ける。終わったあと、もともと何を生み出すつもりだったのか、どこまで触ってよかったのか、何をもって成功とするのかが残らない。記録のない変更は、あとから監査できない。
運用パターン
1. 手を入れる前に、完了記録の四つの欄を埋める。意図した結果、観察可能な境界一つ、検証信号、停止または巻き戻し条件。
2. 結果は動詞ではなく、終わったあとの状態として書く。「直す」ではなく、「この入力がこの出力を返す」。第三者が同じ文を読んで同じ対象を指せる必要がある。
3. 境界は一つで足りる。触ってよい対象の名前、触ってはいけない隣、または時間窓一つ。縁を並べない。越えたら別の仕事になる線を一本選ぶ。
4. 検証信号は、変更のあとに自分で読める観測値でなければならない。ジョブの状態ラベルではなく、対象が出す応答・数値・画面のどれか一つ。
5. 停止または巻き戻し条件は一文にする。信号が見えない、または境界が破れたとき、何を止め、何を戻すか。条件が発火したら、新しい修正を足さない。
6. 四つの欄が空なら変更を始めない。作業中の発見は新しい記録になり、古い境界を静かに広げてはならない。
なぜ重要か
完了記録は記憶の代わりではない。変更を外から監査できるようにする。結果・境界・信号・停止が先に書いてあれば、あとの問いは「うまくいったか」ではなく、「約束した結果がその境界の内側でその信号として現れたか、それとも止めたか」になる。その四文がなければ、成功と事故を分ける基準がない。
完了基準
四つの欄が変更前に埋まっており、変更後は検証信号が結果を確認しているか、停止条件が実行された痕跡が残っていること。どちらもなければ、作業は終わったのではなく、止まる場所がなかっただけである。