Burn out 逃生指南

在同一家公司工作两年以上，有很大概率会 burn out（意思就是精疲力尽，俺不中了）。如果岗位又是 SRE，那么 burn out 时刻几乎是必然。

为什么会这样？一个是因为工作的时间越长，做的东西就越多，维护的东西也越多，维护的工作就越多，然而新的项目还是要做，就会忙不过来了。加上在大公司分工明确，没有人关心甲方的死活，所以你依赖的库时常会有不兼容更新，依赖的组件经常因为组织结构调整而下线，依赖的 IDC 也会下线，安全团队时不时也会找过来让做一些安全方面的加固。总有一天，会发现自己的 todo list 里面放满了待迁移的事项，自己的用户天天来问一些相同的问题，老板有新的想法需要马上实现。每天下了班都在想着工作，每天都不想上班。这个时候，你就知道这是 burn out 了。

作为一个资深的 SRE，我这里有两条靠谱的路可以逃生。

第一条：每两年换一次工作。

很显然，这样的话，上面这些工作就不会积累下来压死骆驼了。但是如果不想工作三十年打 15 份工的话，就需要一些技巧了。

建议一：提高工作效率，而不是工作时间

之所以放在第一条，是因为这是最重要的一条建议，也是常常被我们忽略的一条。

工作总量 = 工作效率 x 时间

在工作量大的时候，自然而然想到的是延长工作时间，这是非常不可取的，工作时间应该固定在每天 8小时，一周5天，不能再增加了。尤其是 SRE，工作时间越长，出错的概率越大，出了事故就得去救火，review incidents，提出改进措施，实施改进措施，带来更多的工作。此外，如果延长工作时间，那后面要讨论的心理管理等话题就都没有意义了。

所以工作量增加的时候，重点要放在提高工作效率，而不是增加工作时间，end of story.

建议二：安排工作的优先级和时间

在焦头烂额的时候，如果有人天天来跟你说「这个需求很重要，什么时候能完成？」可能就会先做这个需求。有段时间每天至少 5 个人来问我 xx 什么时候可以做完，我的回答每天都一样，「和最初承诺的时间一样，如果最近有空了可以加快一些」。因为最初的时间就是按照优先级排列的，不会因为有人天天来问就变得快一些。

优先级如何排列，也不是只看需求方说的。如果对方提了一个不合理的时间，要了解下为什么这样着急。很多 deadline 都是随意拍脑袋定的，可能是为了某人在某个时间点可以向大老板汇报，可能是依赖你的工作的人先承诺了一个 deadline，也可能就是随意定的一个日期。在焦头烂额的一堆工作中，有几个有着让人焦虑的 deadline，让人很难忽略这些工作。但是优先级不应该按照 deadline 来排列，而应该按照真正的重要程度来排列。

• 项目的发布日期已经对外宣布，用户期待在这一天使用新功能；
• 线上的系统摇摇欲坠，必须更新一个 fix；
• 新的集群需要部署，但是如果晚几天部署，也不会 block 任何人的工作；
• ……

遇到不合理的预期的时候，可以问这几个问题：

• 这个需求是服务谁的？为什么要做？如果不按照这个时间上线会有什么后果？
• 其他人的工作是否可以并行做，如果我的这个工作不做，会 block 谁？

有时候把项目在 deadline 之前做完了，却发现后续的一段时间并没有用起来，或者项目继续被其他人 block 着，原来给出的时间线本身就是不切实际的。在最开始就讨论好项目整体的计划，了解真正的紧急程度，避免这些问题。

按照优先级给出需求方截止时间，然后按时间交付工作。但是这之间难免会遇到其他事情，比如临时插入了更紧急的需求，线上发生了事故需要立即处理等等。这一般也不是问题，在时间线有变化，无法按时交付的时候，应该立即通知需求方遇到的困难，新的预估时间。忌讳的是没有和需求方同步，直到交付日期的时候才说，因为某某原因项目无法按时交付了。

建议三：大项目如何推进？

对于大型的项目，尤其是需要多方参与的那种，如果你不幸当了项目的 owner，那么这个建议很实用：用笔记软件记录每天的进展，记录每天遇到的问题，以及这些问题的进展。

以前有一次我们要新建一个数据中心，infra 把机器准备好，然后中间件团队部署好各种服务，缓存，队列，网关等等，然后业务团队部署好业务程序，最后上线。但是我们已经好几年没有完整地上线过一个数据中心了，很多代码中都已经编码了 IDC 的名字，所以这项工作异常困难，要么这个组件启动不了，要么那个组件存在硬编码问题。

负责这个项目的同事是一个很靠谱的人，每遇到一个问题，他都在文档中记录下来。问题原因，负责人，解决方法，解决进度。项目结束之后，这个文档列出来长长的一串问题。看到这个文档我的感受有二：项目真难，这位负责的同事真靠谱。

同时我也学会了这项工作方法， 那时候起我就开始写工作笔记（用的软件是 Roam Research，笔记经过整理记录在公司的文档系统中），每一个项目都有详细的记录，记录的问题也成千上万了。

工作笔记的好处多多，显而易见的是，没有人能记住如此多的问题和细节，所以必须追踪记录。另外也让工作进度和内容透明，如果项目不能如期完成，也能知道问题在哪里。如果没有项目文档，无法解释项目进展和问题，就只能项目负责人的问题了。

经过实践我发现一个额外的好处是，可以带来工作心态的变化。

如果没有记录——想起来这个项目满是头疼，已经经历过 x 问题，y 问题，天知道还要经历什么问题，感觉每走一步都困难重重，想起来就头疼。

有了记录——我们已经解决了 x 问题和 y 问题，我倒要看看还可能出现什么问题！

建议四：使用异步的沟通方式

前面提到过我们要提高工作效率。一个重要的方法就是不要破坏自己的整块时间，不要让自己总是处于被打断的情况。如果养成了过几分钟就要切换到聊天软件查看消息的状态，那工作效率就完蛋了。

要像使用邮件一样使用消息软件，异步轮询沟通。（证明：基于忙轮询的 DPDK 比基于中断的 Linux 网络栈，性能就高多了）。

怎样做呢？前面我们已经学会写工作笔记了，在被 block 需要与人沟通的地方，就在这里记录下需要沟通和确认的地方。然后在每天定时（比如早上刚来和午饭之后）遍历所有在 block 的点，对每一个点都问一遍相关的同事需要确认的问题。但是一定要把所有的细节说全，比如咨询一个网络问题，要提供自己的 IP，对方的 IP 端口，现象是什么，预期结果是什么，traceroute 是什么。防止对方缺少信息需要跟你再次确认。这就回到问问题的艺术的话题¹了。这样就不需要等待回复，所有相关的消息发出去之后就可以继续做没有被 block 的工作，然后等下下次轮询的时间查看消息。

对于收到的信息也一样，几乎所有的消息都不必立即回复。也可以用轮询的方式处理。很多人问问题的时候都不懂如何一次性把信息都提供出来，比如，报告网络问题，连从哪里到哪里有问题都说不明白。不必在等待回复上浪费时间。

建议五：安排工作计划

这条建议可以让你带着一个好心情上班：每周安排好这周要做的事情，每天安排好明天要做的事情，可以已经确定的优先级来安排。

如果没有工作计划，那每天上班看到的就是一个长长的 todo list，怎么能让人不焦虑。

如果有工作计划的话，至少确定今天只要完成这些工作就好了。心理上的负担也会轻松很多。明天的工作就让明天的自己去担心好了。

建议六：每天至少完成一件事情

这条建议可以让你带着一个好心情下班：每天至少完成一件事情，比如解决集群搭建中一个 block 的点，比如完整实现一个需求。

如果一天的时间都在开会，和不同的人讨论细节，到下班的时候一事无成，是很挫败的。每天至少动手完成了点什么，这点满足感会带来很大的不同。

建议七：不要完全放弃有长期收益的事情

不要花所有的时间去做紧急的事情，要花时间去做不紧急但是重要的事情。

比如：

• 提高监控的覆盖度；
• 自动化一个操作；
• 从根本解决一个性能问题；

每天忙于救火，就永远无法从这种工作状态中脱身。去从根本解决问题，工作也会越来越少，形成良性循环。

举个例子：在给产品值班的时候，会有很多用户来问问题。我一般会提供用户文档链接，文档中有答案。如果对于一个问题没有现有的文档可以回答，要么是产品设计出了问题——为什么用户会有此疑问？要么是文档不够全面，我会去写一个关于这个问题的文档，然后再给用户文档链接。虽然表面上可以直接回答的问题花了更长的时间去解决，但是长远来看，将来的用户可能因为这个文档就不来问这个问题了，即使有人问相同的问题，我也可以给文档链接。

有关操作的自动化，也不是所有的操作都应该自动化，也要看投入产出比。如果一个操作一个月才有机会操作一次，那么用文档记录下来如何手工操作，也可以。相较之下，手工操作反而可能成本更低。此外，如果使用频率不高，那么下次用到的时候，自动化的流程很可能是坏掉的，需要临时去 debug 哪里出了问题。

1. 程序员如何高效和同行交流 ↩︎

---