给首次担任专家级 SRE（网站可靠性工程师）的几点建议

译文 2025-12-08 14:45:33

从高级SRE晋升到高级SRE：思维模式的转变

问：您认为从高级SRE晋升到高级SRE（此处原文表述可能存在重复，结合上下文应指从普通高级SRE到承担更核心职责的高级SRE），最大的思维模式转变是什么？

卡兰：这是一个很大的转变。

作为一名普通的高级工程师，我的关注点在于自己和具体问题——快速解决事件、在自己值班期间保持系统稳定、处理日志记录和监控任务。

但成为高级SRE后，思维模式会彻底改变。关注点不再是“我能多快解决问题”，而是“团队如何共同对系统可用性负责”——上至资深工程师，下至新入职的毕业生，都要参与其中——以及我们如何维护这种共同的可靠性愿景。

这关乎构建长期适用的系统，而非仅仅是快速修复。你需要从设计阶段到运维阶段，全程考虑可靠性问题。这意味着要更早地参与到开发流程中、培训团队成员，并且确保每个人都明白：系统可用性是大家共同的责任。

简而言之，重点不再是个人表现，而是助力团队共同取得成功。

关于晋升

问：这确实是一个巨大的转变。您认为自己之所以能晋升为高级SRE，关键原因是什么？

卡兰：没错——而且说实话，我从来没有刻意追求过这个头衔。

在获得晋升时，我其实已经在以高级SRE的标准行事了——对整个系统负责，而不只是对自己8小时的值班时间负责。我会确保团队成员都能跟上进度，因为系统可用性不是一份朝九晚五的工作，而是需要24小时不间断地关注。

这种责任感是关键。当你真正认定系统可靠性是自己的责任时，其他所有事情——团队培训、知识缺口填补、跨团队协作——都会自然而然地步入正轨。

这就像救火：发生火灾时，无论职级高低，每个人都会主动参与。但最优秀的消防员往往是训练最刻苦的那些人。训练时流的汗越多，实战时流的血就越少。

首次担任高级SRE常犯的错误

问：您见过首次担任高级SRE的人常犯哪些错误？

卡兰：错误有很多，但最主要的一个是陷入无休止的“救火模式”。

你过于专注于修复眼前的事件，却从未停下来反思这些事件发生的原因。团队会因为一直处于被动响应状态而精疲力竭。

另一个错误是认为自己团队能解决所有问题。但实际上，你做不到。成功的高级SRE会将开发人员、平台工程师、网络工程师和性能工程师聚集在一起，围绕共同的目标开展工作。

我在哈米德（Hamed）手下工作时，我们开始每周召开OKR（运营关键职责）会议。开发、平台、质量保证（QA）和网络团队的所有人都会参加，共同讨论工作中的障碍和优先事项。让各个团队都能看到运营过程中的问题，有助于打破部门壁垒，提升协作效率。

高级SRE：不只是“最资深”的工程师

问：这正好契合了“高级SRE不只是‘最资深’的工程师，更是‘连接者’”这一观点。那么，在您看来，技术领导力意味着什么？

卡兰：对我来说，技术领导力就是“串联各个环节”的能力。

你不需要精通每一个系统，但必须了解所有系统如何协同工作——上游系统和下游系统如何互动、网络层、应用层和基础设施层如何相互影响。

优秀的高级SRE能看到整个系统的全貌，能够解读各种信号——预判问题可能出现的位置，以及各个组件之间的关联。在我看来，这种“系统层面的思维”正是技术领导力的核心。

如何指导团队

问：作为高级SRE，您是如何指导团队成员的？

卡兰：主要有两点。

第一：允许他们犯错——但不能犯同样的错两次。通过实践（包括试错）来学习是至关重要的。

第二：给他们提供接触不同事物的机会。鼓励他们进行演示、在论坛上发言、自主做决策。他们与其他团队的互动越多，成长就越快。

高级SRE需要具备深厚的“横向知识”——了解从数据中心到应用部署的所有环节如何衔接。你不需要在每个领域都达到专家级的深度，但必须对每个领域有足够的了解，以便做出明智的判断。

知识共享也很关键。我们会每天召开交接会议，让整个团队都了解最新情况，确保在发生事件时，没有人处于信息闭塞的状态。

救火与长期改进的平衡

问：要处理的事情太多了，您如何平衡“救火”和“长期改进”之间的关系？

卡兰：这是高级SRE普遍面临的难题，没有完美的平衡方案。

有一段时间，在哈米德的带领下，我们尝试了“洗车模式”——选取一组应用程序，彻底解决其中的问题，然后将其交还给开发团队，之后再接手新的应用程序。

我们还制定了一条简单的规则：如果同一个问题发生了两次，就必须找到根本原因并解决。同一问题的临时解决方案不能使用超过两次。如果之后这个问题再次出现，那它就不再是SRE的问题，而是设计层面的问题，开发团队必须对此负责。

如果没有这种思维，你会永远被困在“救火模式”中。

自动化与流程、人员的权衡

问：在解决问题时，您如何决定是采用自动化方案，还是改进流程或提升人员能力？

卡兰：

我的原则是先从“系统”找原因，而不是归咎于个人。即使是人为错误，通常也能反映出系统设计上的缺陷——是系统允许了错误的发生。

这种思维会促使你优先考虑自动化。要系统性地解决问题，而非依赖人工操作。

只有当问题超出了系统的控制范围（比如交易员手动修改配置）时，才应该优先考虑改进流程。除此之外，技术手段永远是首选解决方案。

养成健康的值班习惯

问：我们来聊聊值班制度。保持健康值班习惯的关键是什么？

卡兰：最重要的一点是，确保每一条警报都是“可采取行动的”。

我刚担任高级SRE时，80%的非工作时间警报都是无法采取行动的——它们只是“噪音”。解决了这个问题后，团队的倦怠感大幅减轻。

我们会对每一条警报进行审核：哪些是可采取行动的？哪些只是无用的信号？如何定义“健康的系统”？这就像医疗报告一样——你只需要能提示真正问题的警报，而不是虚假警报。

第二点，如果有人在非工作时间被警报呼叫，那么这条警报对应的问题会成为第二天优先解决的“永久性修复”任务。

对我来说，事件结束后的工作才是真正的重点——弄清楚事件发生的原因，并防止其再次发生。

优秀高级SRE与卓越高级SRE的区别

问：最后一个问题，您认为优秀的高级SRE和卓越的高级SRE之间有什么区别？

卡兰：这个问题应该由我的团队来回答！但我认为，“同理心”是关键。

卓越的高级SRE不仅对人有同理心，对系统也有同理心。你了解系统的运行方式、知道它在哪些地方容易出问题、清楚其他团队如何与它交互。

卓越的高级SRE能带动开发人员、平台工程师和网络工程师，让他们将系统可用性视为共同目标——而不只是SRE的责任。

可靠性是一项“团队运动”。当每个人都能主动对系统可用性负责时，你就从“优秀”迈向了“卓越”。

建议总结

从“个人负责”转变为“集体保障可靠性” 从普通高级SRE晋升到高级SRE，意味着不能只关注自己手头的事件清单。你的工作是帮助整个团队对系统可用性负责，而不只是自己解决问题。
聚焦长期可靠性，而非快速修复高级SRE需要从整体角度审视系统，通过影响设计、开发和流程来预防未来的事件——而不只是被动应对故障。
跳出“救火模式”，培养“系统思维” 一直处于被动响应状态会导致团队倦怠。要花时间分析问题的根本原因，并联合跨职能团队共同解决。
推动跨团队共同负责可靠性不是SRE一个团队的问题。要让开发、平台和网络工程师参与到共同的OKR中，共同探讨系统可用性问题。
以同理心和“提供机会”为核心进行领导允许团队成员犯错（并从中学习），鼓励他们在更大的平台上发声，确保知识得到广泛共享。
优先养成健康的值班习惯每一条警报都应是可采取行动的。剔除无用警报，彻底解决重复出现的问题，将事件后的复盘视为工作的重点。
尽可能实现自动化——问责系统，而非个人即使是人为错误，往往也源于系统设计缺陷。只要有可能，就建立系统性的自动化保障措施，而不是依赖人工流程。
注重演练，而非恐慌应对在低风险环境中对事件处理进行越多演练，遇到真实事件时就会越冷静、越高效——这也印证了Uptime Labs的理念：“像实战一样演练，像演练一样应对”。