这是一个创建于 479 天前的主题，其中的信息可能已经有所发展或是发生改变。
背景：本人研发一枚，今晚上线一个技改需求，结果上线时，居然分支发错了，真的是非常非常低级的错误了，万幸的是没有业务影响。后续还要复盘「复盘不可怕，可怕的是低级问题复盘」，想想就头大。
想请教各位，平时都是怎么在工作中避免犯各种低级错误，有没有经验分享分享。
想请教各位，平时都是怎么在工作中避免犯各种低级错误，有没有经验分享分享。
第 1 条附言 2024-06-20 13:05:17 +08:00
各位的发言我都看到了，非常感谢各位提的意见或建议，后续我也会选择适合自己的方式去落地。
P.S. 原谅没时间一一回复各位
 | 1 forgottenPerson 2024-06-19 23:34:23 +08:00 via Android 熟的不能再熟以及善用工具。就像一加一数学上普遍常识上你都会不假思索的给出 2 。 |
 | 2 niboy 2024-06-19 23:40:11 +08:00 上线之前不是有测试妈？ CI 也是自动化的吧？ |
 | 3 cybort 2024-06-19 23:44:15 +08:00 via Android 多个人相互复核 |
 | 4 levelworm 2024-06-19 23:48:56 +08:00  5 我觉得： - 尽量别晚上改。疲劳的时候容易犯错； - 多几个人互相看一下，或者在 CICD 里自动化； |
 | 5 leegradyllljjjj 2024-06-19 23:56:58 +08:00 9 个人血泪史：永远不要在下班的时候或者星期五下午更新程序 |
 | 6 amundsen 2024-06-20 00:21:51 +08:00 1 double check ，组内交 check |
 | 7 Ashe007 2024-06-20 01:24:08 +08:00 via iPhone 楼上说的很好，尽量从流程设计上规避 |
 | 8 crysislinux 2024-06-20 08:25:06 +08:00 via Android 你可以参考机械化工生产的经验。要预防这些问题需要不少成本的。 |
 | 9 Aimirr 2024-06-20 08:26:05 +08:00 打包发布尽量用 CI 自动化发布，不要人工切分支发布。是人总会有错误的。 |
 | 10 imycc 2024-06-20 08:33:32 +08:00 这是个很泛的话题。我遇到的那些，避免的办法概括起来就是在规范上约束、在流程上限制、在交互上提醒。这都没避免的话就只能靠质检拦截、告警兜底了。 |
 | 11 chenliangngng 2024-06-20 08:42:59 +08:00 参照防呆法，最好是在流程上限制，比如一个分支对应一个环境，只有某个分支可以发布生产，这些要 ci cd 加以配合 |
 | 12 yolee599 2024-06-20 09:00:37 +08:00 via Android 1 自己写一个 check list ，提交之前一项一项对，也可以和你同事一起对 |
 | 13 leconio 2024-06-20 09:01:54 +08:00 via iPhone 给别人做，不做就不错 |
 | 14 DonaldErvinKnuth 2024-06-20 09:02:11 +08:00 一开始工作很正常，错误犯多了就记住了 |
 | 15 ktqFDx9m2Bvfq3y4 2024-06-20 09:07:59 +08:00 1 讲真，发错了就发错了，没什么大不了，你做的又不是银行系统。 当然，如果是 Pipeline 是多个 Release 在一起，然后主名称来自于默认的一组会导致误导那是另外一回事。 |
 | 16 ai4u 2024-06-20 09:19:43 +08:00 尽可能地多做检查，当出现“这个应该不会有问题”的想法时，默认一定会有问题，去检查之。 Checklist 尽管做起来比较繁琐，但实则非常有效。 |
 | 17 iyiluo 2024-06-20 09:20:39 +08:00 单线程，一次只做一件事 |
 | 18 wzy44944 2024-06-20 09:23:21 +08:00 2 是人就会犯错的，就算是 cpu 也是有出错的概率的，针对可能出现低级错误的流程增加卡点工具之类的，可以减少不可能完全避免。 |
 | 19 liuliancao 2024-06-20 09:24:28 +08:00 1 增加 review review 以后触发自动发布 发布完成以后增加版本检查 谁都可能出现问题的，就事论事 然后提出解决办法 一般不会咋样的 |
 | 20 augustheart 2024-06-20 09:27:50 +08:00 我的经验就是尽量延长交付期，把测试做足。 不怕代码写得烂，就怕仓促上线 |
 | 21 lasuar 2024-06-20 09:29:23 +08:00 上线自动化 |
 | 22 Pantheoon 2024-06-20 09:30:49 +08:00 每个人都会犯错,只要干活都会犯错,但是要记住一点,同样的错,不要犯两次,允许自己犯第一次错,第二次再犯,不可原谅. 针对 OP 这种发布的错误,建议上线之前搞个 checklist,发些项目,改哪些配置,刷啥 sql,发哪个分支,那个 commitId,这些记录下来,发之前在检查一遍,或者找其他同学看下,double check 可以检查出来很多低级问题 |
 | 23 Kathy1989 2024-06-20 09:32:25 +08:00 我觉得主要问题还是你老板的问题，他没把流程定好，这种事情，老板应该比你更敏感才对 |
 | 24 fengpan567 2024-06-20 09:49:35 +08:00 4 避免不了，世界就是一个巨大的草台班子 |
 | 25 chendy 2024-06-20 09:50:58 +08:00 精力不佳的时候不做复杂或者重要的工作 仔细测试，多花一点时间好好测，可以省下很多着急忙慌处理线上 BUG 的时间 |
 | 26 tog 2024-06-20 09:53:39 +08:00 1 一样，我每次把有问题的东西记录下来。 我从小到大就很粗心，什么事情都是，尤其是改 ppt, 小时候被语文老师评为 `别字大王` blob:https://imgur.com/792ee387-05e9-4238-b7ef-c844ba2d0a46 |
| 27 swLoXtOtd89pGg8t 2024-06-20 09:57:31 +08:00 2 @Pantheoon #22 “每个人都会犯错,只要干活都会犯错,但是要记住一点,同样的错,不要犯两次,允许自己犯第一次错,第二次再犯,不可原谅.” 人总是会失误的，不存在什么第二次不会犯，更不存在 [不可原谅] ，举个例子，你能确定小时候上楼被绊了一次，之后就不会再被绊到了么？又或者，二十年前犯的错，下次遇到同样的问题，当真不会再犯？ 同意#15 #18 #24 ，没什么大不了的，人总会犯错的，如果很关键的地方，还是得用其他方法尽量避免，即便这样也不可能 100%没问题的。 |
 | 28 Jinnrry 2024-06-20 10:02:47 +08:00 via Android 1 复盘不是要写改进项吗？这个问题的改进项肯定是自动化部署+自动化检查啊，都做成自动化以后不就不会错了？ 错一次没什么关系，只要别反复出问题就行，反复出问题也不代表研发本人有问题，而是代表管理流程有问题，做的复盘都是无效复盘。 |
 | 29 fine886 2024-06-20 10:07:22 +08:00 1 把要做的事情用文字的方式记录下来，写的时候可以详细一些。不要过分的相信大脑。 |
 | 30 73cn4XL4Ufv3V65L 2024-06-20 10:10:54 +08:00 1 没有好办法，就是多 check ，还有就是手速不要太快，稳一点更好 |
 | 32 hahastudio 2024-06-20 10:14:09 +08:00 人会犯低级错误的，所以需要流程降低出错率 |
| 33 swLoXtOtd89pGg8t 2024-06-20 10:23:29 +08:00 @Pantheoon #31 人的一生很长的，你能确定弄错分支这种事情在你 40 多年的职业生涯中只会出现一次嘛。。。比如 40 年当中不会状态不佳弄错分支，不会因为孩子琐碎事分心而弄错分支，不会因为哪天身体不适还得上班而弄错分支，不会因为比目标分支多了一个结尾空格而弄错分支。 没有什么方法能够完全避免，把时间拉长到人生中整个工作时间，同样的错误犯好多遍也是无所谓的事情吧。 犯各种类型的错误是人类的一个特点（其实 cpu 也会经常犯错的。。），这是无法避免的事情。 |
 | 34 yiqiao 2024-06-20 10:24:57 +08:00 @leegradyllljjjj 我们以前是这么弄的，后面改了，只在周二周四发版本。 |
 | 35 guanzhangzhang 2024-06-20 10:29:55 +08:00 尽量自动化，也不是说要完全自动化，自动化到上线的时候，必须多人审核 confirm 后才可以继续执行 |
 | 36 bzw875 2024-06-20 10:34:49 +08:00 生产环境操作：2 个操作员，一个念操作单，一个执行操作，按照口胡手指操作 |
 | 37 carytseng 2024-06-20 10:36:27 +08:00 是人就会犯错，平常心对待，不然你这辈子一惊一乍 |
 | 38 HenrikC 2024-06-20 10:37:26 +08:00 1 许多低级错误源于人们做熟练某种工作后形成的肌肉或意识上的“所以然”，还有一种情况是疲劳，导致注意力不集中，解决的根本办法是：针对流程相对固定的工作，采用自动化程序，减少人为的参与。 |
 | 39 Sawyerhou 2024-06-20 10:37:47 +08:00 1 不用太在意，把精力花在避免造成重大损失的严重错误上，分清主次。 |
 | 40 wtsamuel 2024-06-20 10:43:48 +08:00 1 既然是低级错误，那影响不严重，问题不大 |
 | 41 chairuosen 2024-06-20 10:57:24 +08:00 人不可靠，工具可靠。用工具把路限制死，你就不会走错 |
 | 42 AreYou0k 2024-06-20 11:10:18 +08:00 写个命令行发布或者 ci/cd, 我之前也发错过, 测试也没认真检查, 好在是晚上发的, 早上回退了. |
| 43 c466934322 2024-06-20 12:05:27 +08:00 我一般都是列好 todolist 1. 上传 sql 2. 上传代码 3. 上传 xxx 4. 上传配置文件 5. 修改更新发版提示 6. 修改 nginx 7. 修改 xx 8. 配置镜像 就这样，一条条列出来，上线的时候就逐个看一遍 |
 | 44 harrisonkang OP @Pantheoon 这个流程我们是有的，包括里面的具体步骤也都差不多。只是因为我这个需求是自测，测试同学就没有帮 check 分支「不是甩锅给测试」 后续让自己/同事多做 double check 吧 |
| 45 harrisonkang OP @carytseng 感谢提醒(--) |
| 46 harrisonkang OP @fine886 "不要过分相信大脑" 我记住了 |
 | 47 sampeng 2024-06-20 13:55:25 +08:00 上线一定是 100%自动化。而且是非选择的那种。只能一键上线 |
 | 48 harryWebb 2024-06-20 14:49:24 +08:00 只要是人，就没法避免的，人的脑子会疲惫，肯定不可能保持 100%的运行状态 |
 | 49 orioleq 2024-06-20 22:14:12 +08:00 via iPhone 不怪你，上线的分支只能用 release 分支，个人代码都 pull request 过去，有人需要 review 。弄错了只能说你们流程有问题。让你复盘的人是 pua 你，该复盘的人是 pm |
 | 51 zzdgfv 2024-06-21 10:01:16 +08:00 之前公司会结对发布，或者用专门的自动化发布工具，避免分支选错 |
| 52 a5X77vajGRyLA2aF 2024-06-21 10:54:50 +08:00 前面的回复都挺对的。 使用工具自动化||流程规范来避免 无法自动化处理的，想要避免低级错误，那只能不做，或者多做到形成肌肉记忆。 |
Select Language