feat(sreweekly): 补入 431 篇中文译文与 534 期 html,新增翻译队列脚本并更新 manifest

This commit is contained in:
2026-09-15 21:13:34 +08:00
parent 529b2677e7
commit 836fa3b04d
1205 changed files with 16204 additions and 1 deletions

View 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),因为,嗯,我讨厌自己出错的感觉。但我总是尽量采用这个做法,因为它能最大化我自己(但愿也包括读者)的学习效果。我硬着头皮上。当你知道你的工作会被专家审阅时,清晰但错误,要好过含糊其辞。
## 关于《硬着头皮上》的一则评论