这是一个创建于 411 天前的主题，其中的信息可能已经有所发展或是发生改变。
背景：本人研发一枚，今晚上线一个技改需求，结果上线时，居然分支发错了，真的是非常非常低级的错误了，万幸的是没有业务影响。后续还要复盘「复盘不可怕，可怕的是低级问题复盘」，想想就头大。
想请教各位，平时都是怎么在工作中避免犯各种低级错误，有没有经验分享分享。
想请教各位，平时都是怎么在工作中避免犯各种低级错误，有没有经验分享分享。
第 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
yusheng88 2024-06-21 10:54:50 +08:00
前面的回复都挺对的。
使用工具自动化||流程规范来避免 无法自动化处理的，想要避免低级错误，那只能不做，或者多做到形成肌肉记忆。 |
Select Language