一个朋友前段时间加班加得很厉害，事情听起来很简单，就是一次发行前的连续救援。
周五要审查App Store,周四下午发现一个难以处理的大Bug。
发版之前发现严重Bug,最难顶的并不是问题本身，而是它直接压缩了后面验证的时间。
代码要改，可改完后没有时间做灰度，很多本来应该在验证时暴露出来的问题，只能继续隐藏在压力中。
于是两位程序员一同查找问题，直至晚上十点多，才找出问题，随后还要进行测试验证，代码评审, PM评审，最后加入代码。
每个环节都不能少，因为少了任何一个，风险都会随着流程一同带走。
全部做完已经是凌晨两点。
这种夜里两点结束，一般不代表事情结束了，只代表眼前的这一关已经过去了。
第二天晚上十点多，他刚来上班，组长就叫住了他。
大老板又回复了一个网路缓存的问题，并且这个问题也很棘手。
大组长，小组长，还有几个组员都开始动了起来，有人用AI来分析代码，有人单步进行调试，还有人看老板操作记录，想试试老板当时的场景。
这其实就是在排查一个小概率的问题，不能只看代码中最突出的部分，还要尽可能复制一个不容易发生的操作路线。
他中午饭也没吃，觉也没睡，终于在下午解决了问题。
解决了问题之后还是不能马上离开，因为又写了文档报告给了老板，六点多终于去吃饭了。
可是饭还没吃完，七点多就发现，昨天修改的大Bug版本今天灰度时低概率崩溃了。
发版已经到了眼前，新的崩溃又出现了，前面刚刚处理好的事情，立刻被重新拉回到风险中去。
因此程序员高压救火，最痛苦的并不是某个Bug有多难，而是问题常常在不同的环节接踵而至。
你觉得代码改完了就结束了，测试验证接上了，你觉得测试通过了就好了，评审，合入和灰度也接上了。
低概率的崩溃尤为困难，它并非每次都出现，但足以使人不敢将版本视为没有问题。
而发版之前的时间又紧迫，既要修改代码，又要确认修改没有出现新的问题，还要说明过程。
于是形成了一个非常现实的拉扯:越接近发版，越不能匆忙改动，越不改动，已发现的问题也越不可能自行消失。
那天晚上不知道要做到几点，也没有人能够轻易地给出一个正确的答案。
由于在低概率的问题下，所谓的“再看一遍”后面，可能还是一次调试，一次复现，或者一次新的灰度检验。
因此，不要将发版之前的救火当作程序员的加班。
它背后的是时间不够，验证不够，还有一个问题的解决后可能会出现另一个的问题连续的压力。
代码最后能否发出去，并非某人突然爆发，而是测试，评审，灰度与排查等环节共同阻挡风险。
但是如果所有的问题都在最后一天，所谓的流程就会变成一群人一起承担风险。
这也是为何看上去只是个版本，实际上却可能会让人从白天忙到深夜，甚至不知道下次崩溃会在何时出现。
