当整个团队在一场拖长的 incident 中承压时，你如何维持士气？

Question

Accepted Answer

保护**人**，好让他们去保护**系统**。在一场漫长的 incident 中，士气会因混乱、疲惫和对被指责的恐惧而崩溃 —— 所以作为 Tech Lead，你的工作是消除这三者：带来结构、强制休息，并把来自上层的压力吸收掉，好让团队能思考。

## 我实际做的事

- **建立清晰的角色。** 指定一个 **Incident Commander**、一个 comms 人，以及亲自动手的 responder。当每个人都知道自己的车道，恐慌就降下来，专注就回来了。
- **屏蔽团队。** 把对 stakeholder 的通报和管理层的压力揽到自己身上。正在调试的工程师不该每十分钟还要应付一句“修好了没？”。
- **轮换并强制休息。** 精疲力竭的人会让宕机更糟。对任何多小时的事，安排轮班，让没人靠余烬硬撑 —— 疲惫的 responder 会造成第二起 incident。
- **保持冷静和具体。** 平稳的语气、细小的下一步、可见的进展。冷静会传染；恐慌也是。诚实地承认压力，而不是假装一切都好。
- **给人喂饭、把控节奏。** 点吃的、明确叫暂停、庆祝小胜（“错误率在下降”）。持续的危机需要可持续的节奏。

## 结束之后

- **具体且公开地感谢人**，并确保领导层看到这份付出。
- **给恢复时间** —— 一场艰难的 incident 值得休息，而不是直接回到 sprint。
- 运行**无指责的 postmortem**，让压力转化为持久的改进，也让没人独自背着私下的愧疚。

## 取舍与陷阱

- **英雄文化** —— 让一个人连干 18 小时感觉很英勇，却把他 burnout，并制造 bus-factor 风险。抵制它。
- **有毒的正能量** —— “保持积极！”却不承认现实，读起来是轻慢，会侵蚀信任。
- **当下指责**是士气的毒药；把所有评判推迟到 postmortem，而且即便在那里也要保持无指责。
- 别为了显得高产而跳过**人的恢复**；burnout 会在两周后以流失的形式显现。

## 为什么这很重要

incident 考验文化甚于考验能力。一个团队在它最糟糕的时刻如何被对待，会被记住许多年，并塑造好工程师是否留下。一位能在炮火下让人保持稳定、得到休息、不被指责的 Tech Lead，会建立起任何风平浪静时的管理都买不到的那种信任与韧性。