叫停这个决定，只有在执行前才便宜

在执行过程中无法根据以上信号决定是否停止——因为那时已经将听到的时间缩短了一半的状态继续下去，所以停止的位置必须在执行前写在纸上。

概念图: 继续下去 · 部分应用状态是最危险的。 · 时间也是标准。 · 而且最好的方法是不要做出不可逆转的更改。

假设在应用了大约一半的变更的情况下，对照组的数量与计划不同。现在需要判断的只有一个，那就是“是否停止”，做出这个判断的人的条件与30分钟前完全不同。

已经花了两个小时，客户负责人在屏幕旁边坐着，数据只改变了一半的状态。在这种情况下，人们几乎总是继续下去。“既然已经走了这么远，就结束吧”，“现在停下来的话状态会更奇怪”。这两句话在那一刻听起来都很合理，但后来在事故报告中再读的话，这两句话都是借口。

所以停止的地方是在还没有改变任何东西的时候，也就是在停止不花任何代价的时候确定的。正在执行的我不是重新写那个句子的人，而是保护那个句子的人。

可以使用的中断标准必须包含三个。

관측할 수 있는 지표   무엇을 보고 판단하는가. 느낌이 아니라 세어지는 것.
넘으면 안 되는 값     그 지표가 얼마가 되면 이상인가. 부등호와 숫자로.
그때 할 행동          멈추고 무엇을 하는가. 되돌린다 / 보류하고 보고한다.

即使只有其中一个缺失，在执行过程中也会产生解释的余地，解释的余地总是用来继续的。“如果异常就停止”不是中断标准，而是决心。

**部分应用状态是最危险的。**虽然可以解释变更前的状态和变更后的状态，但只有一半变更的状态没有在任何文档中。所以停止并不是“站在原地”，而是通常是“回头走”。如果因为无法撤销而必须站在原地，那么连立即通知这一事实本身都是中断行为。

**时间也是标准。**如果更改窗口是60分钟，那么应用并不是在60分钟结束，而是需要扣除回溯所需的时间和回溯后确认的时间才能结束。如果处于没有回溯时间的情况下滑动窗口，即使之后有中断标准，也没有执行的手段。

**而且最好的方法是不要做出不可逆转的更改。**如果在删除之前留下删除标记，并在暂停期后删除，那么不可逆转的一次将被分成可逆转的两次。就像先停止写入，观察一个周期，而不是删除列一样。首先询问是否可以这样分割，比起好好使用中断标准更有效。

在执行前，经常有请求者要求只更改一个条件。听起来好像只要说“啊，请把那个订单删掉”就行了，但如果条件更改，范围计算、测试执行和备份都会以不同的条件为基础进行。正确的应对是反映那个条件并重走前一步，如果没有时间的话，就按照原来的条件执行后，再单独更改差异。在现场只更改条件执行是最常见的错误路径。

另外，实际执行中断后，停止的事实本身就是报告对象。如果恢复了，就认为什么都没发生，那么客户公司以后在日志中发现那个痕迹，会认为我们隐瞒了。中断的原因、恢复的范围，以及在当天内写下并发送重新尝试的条件，就是一个周期。

不是“异常时停止”的标准。在执行过程中判断它的人已经紧张，模糊的句子当时没有任何帮助。可以使用的标准是有与数字和比较对象。

如果坏事的目标比预想的要多，就会停止。要用的东西如果是与申请书上的120件不同，就会停止。如果更好的对象不是120件的话，就停止，拍下实际数量。

**分三类写下来。**开始前要确认的东西（范围·备份·权限），进行其中要观察的东西（不变式·误差率·速度），以及结束后要确认的东西（总和·样本对比）。把三个混合起来写的话，在执行过程中应该看什么就会变得模糊不清。

一定要放一个不变式。“总和是不变的”，“状态是A的变成0”，“其他顾客的行为一点也不改变”等必须遵守的是句子。如果没有这个，就只能抓住句数正确但内容错误的错误。

**也一起写停下来的方法。**不知道如何停下来的标准不是标准。如果是逐个处理一项的工作的话，不跳到下一项就足够了，如果是一次性全部更改的工作，可以在事务中进行，可以停止。可以停止以没有形式编写并写下中断标准是最常见的徒劳。

然后，正如前面所说，首先问是否可以进行不可逆转的更改。如果可以缩小的话，将中断标准的重量减半。比起好好使用标准让标准变得不那么重要的方式总是更好的。

收到请求书说有120件，但实际变更对象是480件的现场。不要只在纸上写下中断标准，而是让代码执行。

评分器会根据三个请求直接运行和执行您的脚本前的和之后的比较数据。必须符合范围标准的请求，途中不变式被打破是需要撤回的请求，以及需要通过的请求。

最后很重要——仅仅阻止并不能解决问题，如果事情没有成功，那也是失败。