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