代码退回去配置还留着，这种半截状态着实难查明白
线上出了状况，代码退回上一版，请求却还是不对。查了一圈才想起这次发布顺带改过两个配置值，代码退了，值没退，两半截拼在一起，谁都不像自己该有的样子。一、每次改动留一份旧值
改配置时把旧值连同版本、时间存成一条，别只在备注里写一句改大了。备注里的大到底是多少，过两天连写的人自己都记不清。审批流里给紧急回退留一条先做后补的通道，但补记的时限要写死，通道留着不补，几次之后台账就成了断断续续的。
存的地方要跟配置本身分开，别放在同一台机器上。真到那台出状况的时候，取旧值也得从别处取，存在一处就等于没有备份。值班表里把回退这一步对应到具体的人写清楚，半夜真要动手不用在群里挨个问谁有权限，问上一圈，窗口早就过去了。
二、回退要连着依赖一起退
一次发布动过的东西列成一组，代码、配置、开关都挂在组里。退的时候整组一起退，别让人凭印象挑着退，挑漏一件就又回到半截状态。季度盘点数一数演练里卡过的次数，同一处卡了两回就说明步骤还该再拆细，别每回都靠当时在场的人临场想办法。
组里也写清先后顺序，有的值得先退，有的要等代码退完再动。顺序颠过来，中间那一小段两边对不上，请求正好撞进来的话，日志里会多出几条看不懂的记录。成本那一栏别只填机器和人力，把每次演练占掉的工时也折进去，摊开看过才知道这套退路养着值不值，花在哪一段也能说给后来的人听。
三、生效前先做一次预检
按下改动之前，拿几组典型输入试算一遍，看新值会不会把某条路卡住。试算不费事，比起推上去再退回来，省下的是一屋子人跟着盯的时间。和值班的几位约好把退完之后的确认也当成一步，别退完就散，隔一阵回头看一眼那几台是不是真的都跟上了。
预检的样例从真实请求里挑，别只挑顺的那几种。边界上的大额、空值、跨天时间，常常就是新值一上去先出问题的地方。交接的时候把上一回退到哪一步、还剩哪几项没核完逐条列上，接手的人照着往下走，不会把别人已经做过的又重来一遍。
四、回退窗口按业务定
留多长回退窗口，看业务的节奏，不看发布者的排期。有的活一天只跑一回，窗口就得盖过那一回，否则等想退的时候，那笔已经按新值算完了。排期表上给每季度那次清理留一格，别等谁想起来才做，日子定住了，各团队交归属人的时候也有个能对着安排的时间。
窗口里别再叠别的改动，几件事挤在一起，出了状况也分不清是哪件引起的。安安静静看一阵，确认稳了再往下走。复盘会上先对着时间线看一遍，从发现到退完各花了多久，卡在哪一段一目了然，比只讨论下次注意些什么管用得多。
五、谁按的按钮要有记录
改动和回退都记下操作人、时刻、动了哪一项。不是要追究谁，是交接时对得上，下一班接手不用先花半小时问刚才到底退没退。预算里把长期挂着的键占的那点存储和值守折成一行写出来，数不大，可摆出来之后，该不该留这件事就容易谈得拢。
记录里附一句缘由，哪怕是临时放量这种短句子。过一个月再看，有缘由的那条还能读懂，只有时间和键名的那条基本等于没写。新人上手的头一个月安排他旁观一次演练，从头听到尾再写一遍步骤，写不出来的那几处，往往就是手册里没讲明白的地方。
六、演练过一遍才算数
找试运行环境把回退整套走一遍，从取旧值到确认生效，掐一下用了多久。没走过的时候，纸上的步骤看着都顺，真到夜里才发现某个入口要另外的权限。值班交接时把待删清单交下去，写清哪几项还在观察期，接手的人不会看见零调用就顺手清掉，季末才跑的那一类很容易被误伤。
演练里卡住的那一处，当场补进步骤里。补完再走一遍，直到换个人照着单子也能做下来，这套回退才算真的能用。归档时把每次的旧值记录、当时的缘由和演练结论放在一处，过半年有人问起某回为什么退得慢，顺着目录就能找齐材料。
回退难的从来不是把代码换回去，是那些跟着一起动过、又没人记着的值。旧值、成组、预检、窗口、留名、演练，六件事平时看着琐碎，真到要退的那晚，每一件都能省下十几分钟。 这样用心的帖子不多见，必须顶上去让更多人看到优质内容。 楼主的经历很有参考价值，给了我很多新的思考方向，非常感谢。 之前一直半知半解，看了你的解释一下子就明白了，讲得通俗易懂。
页:
[1]