本文作者：Hank Jacobs，来自 NetFlix 的 CORE 团队的 SRE 工程师。原文地址：https://netflixtechblog.com/keeping-customers-streaming-the-centralized-site-reliability-practice-at-netflix-205cc37aa9fb
Netflix 的可靠性实践有一个很重要的特点：并不是所有 SRE 都嵌入具体业务团队，也不是所有 SRE 都负责某个服务的日常运维。Netflix 的 CORE 团队代表了另一种实践方式：中心化、跨团队、围绕整体业务可靠性工作。
核心要点
- CORE 是 Critical Operations and Reliability Engineering team 的简称，是 Netflix 的中心化可靠性团队。
- CORE 不负责具体服务运维、不做线上变更、不构建基础设施，也不嵌入业务团队。
- CORE 关注 Netflix 整体服务稳定性，重点工作包括业务 KPI 告警响应、事件生命周期管理、可靠性咨询和系统性风险识别。
- 在事件中，CORE On-call 工程师通常承担故障 Manager 的角色，负责协调、决策、记录、排查协助和沟通。
- Netflix 的事件后分析强调社会技术视角，不只看技术缺陷，也关注团队协作、沟通流程和决策过程。
Netflix 如何理解可靠性
Netflix 的目标是为客户持续提供稳定的流媒体服务。无论是新的剧集内容，还是新的产品功能，都需要建立在可靠服务之上。
可靠性，正式来讲，是一个系统在给定条件下持续运行的能力。简单说，可靠性意味着系统应该工作，并且持续工作。
从故障注入测试到周期性切流演练，Netflix 工程师投入了大量精力来确保服务稳定可靠。许多团队都为 Netflix 的可靠性做出贡献，负责各自服务和领域的稳定性。
其中，CORE 团队（The Critical Operations and Reliability Engineering team）负责 Netflix 整体服务的稳定性。
注意，CORE 是一个团队名称的简写，并不是指某个团队的核心成员。
CORE 团队是什么
CORE 是一个由站点可靠性工程师、弹性工程师和性能工程师组成的团队。这个团队负责关键业务的运营稳定性。
译者注：从职责描述看，CORE 团队主要关注公司的北极星指标。
与大多数 SRE 团队不同，CORE 有几个显著特点：
| 维度 | 常见 SRE 团队 | Netflix CORE 团队 |
|---|---|---|
| 服务归属 | 通常负责具体服务或业务线 | 不负责具体服务运维 |
| 线上变更 | 可能参与发布、变更和基础设施维护 | 不做线上变更 |
| 组织形态 | 可能嵌入业务团队 | 公司级中心化组织 |
| 工作重点 | 服务稳定性、运维、平台能力 | Netflix 整体可靠性、事件管理、风险识别、咨询 |
CORE 的主要重点是确保 Netflix 保持正常运行。实际工作包括系统性风险识别、事件生命周期处理和可靠性咨询。
译者注：大白话来讲，他们的核心职能是：平时研究 Netflix IT 系统，看看哪里可能有问题；故障发生时拉通各个团队解决；最后做可靠性咨询，类似教练角色。这个团队的人应该不多，而且都是经验丰富的工程师。不确定这个团队是否参与制定线上规范。
服务所有权模式下，CORE 为什么还需要存在
Netflix 的团队遵循服务所有权模式：自己开发，自己运维。
大多数时候，服务 owner 会在问题影响客户之前发现问题。但是系统仍然可能出现偏差，并发生影响客户体验的事件。这个时候，CORE 团队就会介入。
CORE 会配置、维护并响应监控高级业务 KPI 的告警，例如每秒流启动数。当 KPI 告警时，CORE On-call 工程师会评估情况：
- 判断影响范围。
- 识别相关服务。
- 拉入对应服务 owner 一起处理。
- 开始管理事件。
也就是说，CORE 不替代服务 owner 解决所有具体问题，但它负责把跨团队事件组织起来，确保影响被识别、相关团队被拉入、缓解动作被推进。
Netflix 的事件管理方式
Netflix 的事件管理不遵循 ITIL 模型等常见管理实践。
在事件中，CORE On-call 工程师通常担任故障 Manager 的角色。他负责执行或委派下面这些任务：
- 协调：引入相关服务的 owner，帮助调查并专注于缓解措施。
- 决策：做出关键选择以降低影响或止损，例如决定是否切流。
- 记录：持续跟踪故障详情，包括涉及哪些团队、为缓解故障做了哪些努力、当前影响范围如何。
- 排查：协助各个服务 owner 了解哪些系统导致了故障。
- 联络：根据需要，与内部和外部团队跨业务职能部门传达事件信息。
这类角色的价值在于把事件处理从“各团队各自看局部”拉回到“围绕客户影响做整体协调”。在复杂系统里，这种中心化协调能减少信息断层。
事件后分析：关注社会技术因素
一旦成功减轻对客户的影响，CORE 就会负责协调事件后分析。
译者注：原文用的是 mitigated，这里可以理解为先降低影响或止损，然后再进入复盘和分析。严格来说，完全恢复和影响缓解之间可能还存在差异。
根据事件影响和独特性，事件后分析有多种形式和规模。大多数事件都会经历 Netflix 所说的 “memorialization”。
这个过程包括记录：
- 发生了什么。
- 采取了哪些缓解措施。
- 讨论了哪些后续工作。
对于特别独特、有趣或影响较大的事件，CORE 可能会举办事件复盘，或进行更深入的长期调查。大多数事后分析，尤其是影响较大的事件，都会与 CORE 的一位应用弹性工程师合作完成。
需要强调的是，所有事件分析工作都侧重事件的社会技术（sociotechnical）方面。
“sociotechnical” 即“社会技术的”，是一个融合社会因素与技术因素的概念。
在事件分析场景中，它强调不能只从技术角度看问题，例如系统漏洞、代码错误等；还要考虑社会因素，例如团队协作、沟通流程、人为决策等。分析一起服务故障时，不仅要排查技术层面的系统缺陷，也要审视团队响应过程中的协作效率和信息传递是否顺畅，从而全面理解事件成因并找到更有效的改进方案。
因此，Netflix 的事后分析往往会为相关人员发现许多实际经验和改进项。CORE 也会把这些发现传播给直接相关人员之外的人，帮助整个公司共享经验教训。
CORE 工程师平时做什么
如果 CORE 工程师没有在 On-call，也没有做故障分析，他们平时会做什么？
典型工作包括：
- 保持运营可见性和响应能力：修复和改进仪表板、告警和自动化。
- 可靠性咨询：讨论架构决策、系统可观测性、应用程序性能和 On-call 健康培训。
- 系统性风险识别和缓解：与各团队合作，识别和修复事件揭示出的系统性风险。
- 内部工具：构建和维护支持事件响应能力的工具。
- 学习和重新学习复杂、不断变化的系统。
- 与其他团队建立和维护关系。
这些工作有一个共同点：都不是围绕某一个服务的日常运维，而是围绕“整体可靠性能力”持续积累。
这种中心化 SRE 模式适合什么问题
Netflix 认为，这种可靠性工作形式适合自己的需求和目标。
原因包括：
- CORE 以可靠性为主要关注点，因此有余力主动探索潜在关键业务风险，并应对这些风险。
- CORE 拥有更广阔的系统视野，能够在系统性风险发展时发现它们。
- 作为独立的中央团队，CORE 更容易在更大的工程组织中共享经验教训。
- CORE 可以更方便地临时为其他团队提供可靠性咨询。
最终，CORE 对可靠性的专注，使它能够揭示关键业务社会技术风险，促进对这些风险的有效响应，并确保 Netflix 持续为客户提供稳定服务。
对其他技术团队的启发
Netflix CORE 的实践不等于所有公司都应该成立同样的团队。更实际的启发是：当组织规模变大、系统耦合变复杂、业务 KPI 需要跨团队保障时，只靠“每个服务 owner 管好自己”可能还不够。
可以借鉴的不是组织名称，而是几个机制：
- 用高级业务 KPI 作为跨团队可靠性入口。
- 在重大事件中明确故障 Manager 角色。
- 用中心化角色协调服务 owner，而不是替代服务 owner。
- 事件后分析同时看技术因素和协作因素。
- 把事件经验传播到更大的工程组织，而不是只停留在事故团队内部。
FAQ
Q1：CORE 团队是不是负责 Netflix 所有服务运维？ A：不是。CORE 不负责具体服务运维，也不做线上变更或构建基础设施。服务仍由服务 owner 负责，CORE 负责整体可靠性、事件管理、咨询和风险识别。
Q2：CORE On-call 和普通业务团队 On-call 有什么区别？ A：业务团队 On-call 通常负责自己服务的问题。CORE On-call 更关注高级业务 KPI 和跨团队事件，在事件中承担协调、决策、记录和沟通角色。
Q3：社会技术分析和普通故障复盘有什么不同？ A：社会技术分析不只看代码、系统和配置，也看团队协作、信息流、决策过程和组织机制。它试图解释事件为什么会在真实组织环境中发生。
总结
Netflix CORE 团队展示了一种中心化 SRE 实践：不接管具体服务，不替代服务 owner，而是围绕业务 KPI、事件生命周期、可靠性咨询和系统性风险识别工作。对复杂组织来说，这种模式的核心价值是建立跨团队的可靠性视角，让事件响应不只停留在局部系统修复，而能持续沉淀为组织级经验。
