关于顶级公司Netflix 的运维揭秘，赵成老师在新书《进化：运维技术变革与实践探索》中有比较详细的分析。
众所周知，Netflix 是业界微服务架构的最佳实践者，其基于公有云上的 微服务架构设计、持续交付、监控、稳定性保障，都为业界提供了大量可以 遵从的原则和实践经验。
Netflix 超前提出了某些理念并付诸实践，以至于在国内众多互联网公司 的技术架构上都可以看到似曾相识的影子。当然，殊途同归也好，经验借鉴 也罢，这都不影响 Netflix 作为业界最佳实践者的地位。
同样，在运维这个细分领域，Netflix 仍然是最佳实践的典范。所以在本 书的开始，就让我们一起看看世界顶级的互联网公司是如何定义运维以及如 何开展运维工作的。
1. 没有运维的 Netflix
准确一点来说，Netflix 是没有运维岗位的，和运维对应的岗位其实是我 们熟知的 SRE(Site Reliability Engineer)。但我们知道 SRE 不等于运维， SRE 理念的核心是，用软件工程的方法重新设计和定义运维工作。
但是 Netflix 的神奇和强大之处在于，连 Google 都非常重视和大力发展 的 SRE 岗位，在 Netflix 却没有几个。按照 Netflix 一位技术主管在 2017 年 9 月更新的博客中所描述的，在 1 亿用户、每天 1.2 亿小时播放时长、万级
微服务实例的业务体量下，Netflix 的 SRE 人数却不超过 10 个，他们称这样 的角色为 Core SRE。具体描述如下:
100+ Million members. 125+ Million hours watched per day. Hundreds of microservices. Hundreds of thousands of instances. Less than 10 Core SREs.
——Katharina Probst
不可否认，Netflix 拥有强大的技术实力和全球最优秀的工程师团队。按 照 SRE 的理念，完全可以打造出一系列的工具产品来取代运维和 SRE 的工作。 但是 Netflix 能够做到如此极致，就不得不让人惊叹和好奇，它到底是怎么 做的?
2. Netflix 是如何成为行业典范的
这确实是一个很有意思的问题，我带着这样的疑问，阅读了大量的 Netflix 技术文章和公开的演讲内容之后，我想可以从 Netflix 的技术架构、 组织架构、企业文化等几个方面来看这个问题。
海量业务规模下的技术架构和挑战
前面提到，Netflix 在业务高速发展以及超大规模业务体量的驱动下，引 入了更为灵活的微服务架构，而且已经成为业界的最佳实践典范。
引入微服务架构后，软件架构的细化拆分和灵活多变，大大提升了开发人员的开发效率，继而也就提升了业务需求的响应和迭代速度，我想这也正是微服务思想在业界能够被广泛接受和采用的根本原因。
但是这样做也并不是说没有一点代价和成本，随之而来的便是架构复杂度大大增加，这种复杂度已经远远超出人的认知能力，也就是我们已经无法靠人力去掌控了，这也就为后续的交付和线上运维带来了极大的难度和挑战。
这是，微服务架构下的运维就必须要靠通过软件工程思路打造工具支撑体系来支持了，也就是要求微服务架构既要能够支持业务功能，也要能够提供和暴露更多在后期交付和线上运维阶段所需的基础维护能力。
简单举几个例子，比如服务上下线、路由策略调整、并发数动态调整、 功能开关、访问 ACL 控制、异常熔断和旁路、调用关系和服务质量日志输 出等，要在这些能力之上建设我们的运维工具和服务平台。
讲到这里，我们可以看到，在微服务架构模式下，运维已经成为整体技 术架构体系中必不可少的一部分，而且与微服务架构相关的体系是紧密相连、 不可拆分的。
我们现在看到很多和 SRE 相关的文章或内容，对于 SRE 产生原因的解 释，大多是说为了缓解开发和运维之间的矛盾，树立共同的目标，让双方能 够更好地协作配合。这样理解也没有太大的问题，但是我认为不够充分，或 者说以上这些只能算是结果，不是背后的根本原因。
我理解的背后最根本的原因是，微服务架构复杂到了一定程度，已经远远超出单纯的开发和单纯的运维职责范畴，也远远超出了单纯的人力认知掌控范围，所以必须寻求在架构之上的更为有效和统一的技术解决方案，来解决复杂度认知的问题。在这一套统一的技术解决方案之上，开发和运维进而产生了新的职责分工和协作方式。
对于目前业界火热的 DevOps 理念及其衍生出来的一系列话题，我们可 以仔细思考一下，其实也是同样的背景和逻辑。DevOps 想要解决的是开发和运维之间日益严重的矛盾，究其根本，还是微服务架构背后的技术复杂度在不断提升的问题。
Netflix 带给我们的启示一:在微服务架构模式下，我们必须换一个思路 来重新定义和思考运维，运维一定要与微服务架构本身紧密结合起来。
更加合理的组织架构和先进的工具体系及理念
前面提到，在微服务架构模式下，运维已经成为整体技术架构和体系中不可分割的一部分，两者脱节就会带来后续一系列的严重问题。
从这一点上，不得不说 Netflix 的前瞻性和技术架构能力还是很强的。 因为早在 2012 年，甚至更早之前，Netflix 就已经意识到了这个问题。在组 织架构上，将中间件、SRE、DBA(DataBase Administrator，数据库管理员)、 交付和自动化工具、基础架构等团队都放在统一的云平台工程(Cloud and Platform Engineering)这个大团队下，在产品层面统一规划和建设，从而能 够最大程度地发挥组织能力，避免了开发和运维的脱节。
当然，这个团队不仅没让大家失望，还给我们带来了很多惊喜。在业界 大名鼎鼎的 Netflix OSS 开源产品体系里，绝大部分的产品都是这个团队贡 献的。
比如，持续交付系统 Spinnaker;稳定性保障工具体系 Chaos Engineering， 这里面最著名的就是那只不安分的猴子，也正是这套稳定性理念和产品最大 程度地保障了 Netflix 系统的稳定运行;被 Spring Cloud 引入并得以更广泛 传播的 Common Runtime Service&Libraries，而且大家选用 Spring Cloud 基本 就是冲着 Spring Cloud Netflix 这个子项目去的。当然还有很多其他优秀的开 源产品，这里就不一一介绍了。
Netflix 带给我们的启示二:合理的组织架构是保障技术架构落地的必要 条件，用技术手段来解决运维过程中遇到的效率和稳定性问题才是根本解决方案。
自由与责任并存的企业文化
上面讲了这么多，看上去好像就是 SRE 常见的理念和套路，只不过 Netflix 在开源和分享上更加开放和透明，让我们有机会更多地了解到一些细 节。但是为什么 Netflix 会做得如此极致呢?好像我们一直没有回答这个问题， 说到这里就不得不提 Netflix 的企业文化了。
Netflix 的企业文化是“Freedom & Responsibility”，也就是自由和责任 并存，高度自由的同时，也需要员工具备更强的责任心和 Owner(责任人) 意识。
体现在技术团队中就是“You Build It，You Run It”。工程师可以随时 向生产环境提交代码或者发布新的服务，但是工程师同时作为 Owner，要对 自己发布的代码和线上服务的稳定运行负责。
在这种文化的驱使下，技术团队自然会考虑从开发设计阶段到交付和线 上运维阶段的端到端整体解决方案，而不会是开发人员就只管需求开发，后 期交付和维护应该由一个叫运维的角色去考虑。文化使然，在 Netflix 是绝对 不允许这种情况存在的，你是开发人员，你就是 Owner，你就要端到端地负责。
所以，虽然是短短两个英文单词——Freedom & Responsibility，却从源 头上决定了团队和员工的做事方式。
Netflix 带给我们的启示三:Owner 意识很重要，正确的做事方式需要引导，这就是优秀和极致的距离。
3. 总结
通过上面的分析，我们可以看到，Netflix 在其技术架构、组织架构和企 业文化等方面的独到之处，造就了其优秀的技术理念和最佳实践。从运维的 角度来说，无论是 SRE 也好，还是 DevOps 也罢，都被 Netflix 发挥到了极致。
当然，Netflix 能做到这一点，是需要非常强大的技术实力和人才储备的。 当前我们虽然没办法直接套用它的整套体系，但是这并不妨碍我们在某些经 验和思路上去借鉴和学习。
比如，现在很多公司在采用了微服务架构后，就没有充分考虑到后续基于微服务架构的运维问题，而且在运维团队的设置上，仍然脱离了整个技术团队，更不用说将其与中间件和架构设计等团队整合拉通区建设，自然也就谈不上在产品层面上的合理规划和建设了。
因此导致的问题就是运维效率低下，完全靠人工，线上故障频发，但是处理效率又极低，开发和运维都处于非常痛苦的状态中，运维团队和成员也会遭遇到转型和成长的障碍。
以上这些问题都很棘手，亟待解决。通过本节内容，我们了解了 Netflix 技术团队的运作模式和思路，不知道给你带来了哪些启示呢?
