工作中如何避免犯低级错误

[harrisonkang]

背景：本人研发一枚，今晚上线一个技改需求，结果上线时，居然分支发错了，真的是非常非常低级的错误了，万幸的是没有业务影响。后续还要复盘「复盘不可怕，可怕的是低级问题复盘」，想想就头大。

想请教各位，平时都是怎么在工作中避免犯各种低级错误，有没有经验分享分享。

各位的发言我都看到了，非常感谢各位提的意见或建议，后续我也会选择适合自己的方式去落地。

P.S. 原谅没时间一一回复各位🙏

[forgottenPerson]

熟的不能再熟以及善用工具。就像一加一数学上普遍常识上你都会不假思索的给出 2 。

[niboy]

上线之前不是有测试妈？ CI 也是自动化的吧？

[cybort]

多个人相互复核

[levelworm]

我觉得：

- 尽量别晚上改。疲劳的时候容易犯错；

- 多几个人互相看一下，或者在 CICD 里自动化；

[leegradyllljjjj]

个人血泪史：永远不要在下班的时候或者星期五下午更新程序

[amundsen]

double check ，组内交叉 check

[Ashe007]

楼上说的很好，尽量从流程设计上规避

[crysislinux]

你可以参考机械化工生产的经验。要预防这些问题需要不少成本的。

[Aimirr]

打包发布尽量用 CI 自动化发布，不要人工切分支发布。是人总会有错误的。

[imycc]

这是个很泛的话题。我遇到的那些，避免的办法概括起来就是在规范上约束、在流程上限制、在交互上提醒。这都没避免的话就只能靠质检拦截、告警兜底了。

[chenliangngng]

参照防呆法，最好是在流程上限制，比如一个分支对应一个环境，只有某个分支可以发布生产，这些要 ci cd 加以配合

[yolee599]

自己写一个 check list ，提交之前一项一项对，也可以和你同事一起对

[leconio]

给别人做，不做就不错

[DonaldErvinKnuth]

一开始工作很正常，错误犯多了就记住了

[Chad0000]

讲真，发错了就发错了，没什么大不了，你做的又不是银行系统。

当然，如果是 Pipeline 是多个 Release 在一起，然后主名称来自于默认的一组会导致误导那是另外一回事。

[ai4u]

尽可能地多做检查，当出现“这个应该不会有问题”的想法时，默认一定会有问题，去检查之。
Checklist 尽管做起来比较繁琐，但实则非常有效。

[iyiluo]

单线程，一次只做一件事

[wzy44944]

是人就会犯错的，就算是 cpu 也是有出错的概率的，针对可能出现低级错误的流程增加卡点工具之类的，可以减少不可能完全避免。

[liuliancao]

增加 review review 以后触发自动发布 发布完成以后增加版本检查
谁都可能出现问题的，就事论事 然后提出解决办法 一般不会咋样的

[augustheart]

我的经验就是尽量延长交付期，把测试做足。
不怕代码写得烂，就怕仓促上线

[lasuar]

上线自动化

[Pantheoon]

每个人都会犯错,只要干活都会犯错,但是要记住一点,同样的错,不要犯两次,允许自己犯第一次错,第二次再犯,不可原谅.

针对 OP 这种发布的错误,建议上线之前搞个 checklist,发些项目,改哪些配置,刷啥 sql,发哪个分支,那个 commitId,这些记录下来,发之前在检查一遍,或者找其他同学看下,double check 可以检查出来很多低级问题

[Kathy1989]

我觉得主要问题还是你老板的问题，他没把流程定好，这种事情，老板应该比你更敏感才对

[fengpan567]

避免不了，世界就是一个巨大的草台班子

[chendy]

精力不佳的时候不做复杂或者重要的工作
仔细测试，多花一点时间好好测，可以省下很多着急忙慌处理线上 BUG 的时间

[tog]

一样，我每次把有问题的东西记录下来。
我从小到大就很粗心，什么事情都是，尤其是改 ppt, 小时候被语文老师评为 `别字大王`

blob:https://imgur.com/792ee387-05e9-4238-b7ef-c844ba2d0a46

[NevadaLi]

@Pantheoon #22

“每个人都会犯错,只要干活都会犯错,但是要记住一点,同样的错,不要犯两次,允许自己犯第一次错,第二次再犯,不可原谅.”

人总是会失误的，不存在什么第二次不会犯，更不存在 [不可原谅] ，举个例子，你能确定小时候上楼被绊了一次，之后就不会再被绊到了么？又或者，二十年前犯的错，下次遇到同样的问题，当真不会再犯？

同意#15 #18 #24 ，没什么大不了的，人总会犯错的，如果很关键的地方，还是得用其他方法尽量避免，即便这样也不可能 100%没问题的。

[Jinnrry]

复盘不是要写改进项吗？这个问题的改进项肯定是自动化部署+自动化检查啊，都做成自动化以后不就不会错了？

错一次没什么关系，只要别反复出问题就行，反复出问题也不代表研发本人有问题，而是代表管理流程有问题，做的复盘都是无效复盘。

[fine886]

把要做的事情用文字的方式记录下来，写的时候可以详细一些。不要过分的相信大脑。

[leesin8848]

没有好办法，就是多 check ，还有就是手速不要太快，稳一点更好

[Pantheoon]

@NevadaLi
绊倒不是犯错,另外,我说的犯错,是指 op 这种低级错误

[hahastudio]

人会犯低级错误的，所以需要流程降低出错率

[NevadaLi]

@Pantheoon #31 人的一生很长的，你能确定弄错分支这种事情在你 40 多年的职业生涯中只会出现一次嘛。。。比如 40 年当中不会状态不佳弄错分支，不会因为孩子琐碎事分心而弄错分支，不会因为哪天身体不适还得上班而弄错分支，不会因为比目标分支多了一个结尾空格而弄错分支。

没有什么方法能够完全避免，把时间拉长到人生中整个工作时间，同样的错误犯好多遍也是无所谓的事情吧。

犯各种类型的错误是人类的一个特点（其实 cpu 也会经常犯错的。。），这是无法避免的事情。

[yiqiao]

@leegradyllljjjj 我们以前是这么弄的，后面改了，只在周二周四发版本。

[guanzhangzhang]

尽量自动化，也不是说要完全自动化，自动化到上线的时候，必须多人审核 confirm 后才可以继续执行

[bzw875]

生产环境操作：2 个操作员，一个念操作单，一个执行操作，按照口胡手指操作

[carytseng]

是人就会犯错，平常心对待，不然你这辈子一惊一乍

[HenrikC]

许多低级错误源于人们做熟练某种工作后形成的肌肉或意识上的“所以然”，还有一种情况是疲劳，导致注意力不集中，解决的根本办法是：针对流程相对固定的工作，采用自动化程序，减少人为的参与。

[Sawyerhou]

不用太在意，把精力花在避免造成重大损失的严重错误上，分清主次。

[wtsamuel]

既然是低级错误，那影响不严重，问题不大

[chairuosen]

人不可靠，工具可靠。用工具把路限制死，你就不会走错

[AreYou0k]

写个命令行发布或者 ci/cd, 我之前也发错过, 测试也没认真检查, 好在是晚上发的, 早上回退了.

[c466934322]

我一般都是列好 todolist
1. 上传 sql
2. 上传代码
3. 上传 xxx
4. 上传配置文件
5. 修改更新发版提示
6. 修改 nginx
7. 修改 xx
8. 配置镜像
就这样，一条条列出来，上线的时候就逐个看一遍

[harrisonkang]

@Pantheoon 这个流程我们是有的，包括里面的具体步骤也都差不多。只是因为我这个需求是自测，测试同学就没有帮 check 分支「不是甩锅给测试」

后续让自己/同事多做 double check 吧

[harrisonkang]

@carytseng 感谢提醒(-🙏-)

[harrisonkang]

@fine886 "不要过分相信大脑" 我记住了🙏

[sampeng]

上线一定是 100%自动化。而且是非选择的那种。只能一键上线

[harryWebb]

只要是人，就没法避免的，人的脑子会疲惫，肯定不可能保持 100%的运行状态

[orioleq]

不怪你，上线的分支只能用 release 分支，个人代码都 pull request 过去，有人需要 review 。弄错了只能说你们流程有问题。让你复盘的人是 pua 你，该复盘的人是 pm

[maemolee]

@Pantheoon #22 太极端了，犯错是无法避免的，人的自纠自查机制，根本不足以实现你说的理想效果。

[zzdgfv]

之前公司会结对发布，或者用专门的自动化发布工具，避免分支选错

[yusheng88]

前面的回复都挺对的。

使用工具自动化||流程规范来避免
无法自动化处理的，想要避免低级错误，那只能不做，或者多做到形成肌肉记忆。