feat(sreweekly): 补入 431 篇中文译文与 534 期 html,新增翻译队列脚本并更新 manifest
This commit is contained in:
29
sreweekly/markdown/317/05-taking-the-hit-zh.md
Normal file
29
sreweekly/markdown/317/05-taking-the-hit-zh.md
Normal file
@@ -0,0 +1,29 @@
|
||||
# 硬着头皮上(Taking the hit)
|
||||
|
||||
- **期号**: SRE Weekly Issue #317(2022-04-10)
|
||||
- **作者**: Lorin Hochstein
|
||||
- **链接**: https://surfingcomplexity.blog/2022/04/09/taking-the-hit/
|
||||
|
||||
## 简介
|
||||
|
||||
我以前就这么干过,而且是无意中干的;回头看,那是一个很棒的战略。
|
||||
|
||||
> 当你知道自己的工作会被专家审阅时,清晰但错误,要好过含糊其辞。
|
||||
|
||||
## 正文
|
||||
|
||||
这是我经常遇到的一个场景:我正在撰写一篇事故复盘或 [OOPS 复盘](https://surfingcomplexity.blog/2021/11/21/oops-writeups/)。我已经访谈过系统中的关键专家,基于这些访谈,我对实现细节已经理解到足以用文字解释故障模式的程度。
|
||||
|
||||
但当我真正落笔写解释的时候,我发现自己对所有相关细节其实并没有很好的理解。我可以回头再去问澄清问题,但我担心这样会问很多次,而我想避免占用别人太多时间。
|
||||
|
||||
现在,在描述故障模式时,我面临一个选择。我可以:
|
||||
|
||||
(a) 对自己理解不透彻的部分刻意含糊其辞。
|
||||
|
||||
(b) 对自己不确定的部分,就实现细节做出自己最好的猜测。
|
||||
|
||||
每当我选择 (b) 时,总会有一些细节弄错。当我把草稿拿给关键专家看,他们直截了当地告诉我“Lorin,这一节是*错的*”时,这一点就会变得无比清晰。
|
||||
|
||||
我把选择 (b) 称为***硬着头皮上***(taking the hit),因为,嗯,我讨厌自己出错的感觉。但我总是尽量采用这个做法,因为它能最大化我自己(但愿也包括读者)的学习效果。我硬着头皮上。当你知道你的工作会被专家审阅时,清晰但错误,要好过含糊其辞。
|
||||
|
||||
## 关于《硬着头皮上》的一则评论
|
||||
Reference in New Issue
Block a user