Netfix业务运维分析和总结

Netfix业务运维分析和总结

众所周知，Netfix是业界微服务架构的最佳实践者，其基于公有云上的微服务架构设计、持续交付、监控、稳定性保障，都为业界提供了大量可遵从的原则和实践经验。

Netfix超前提出某些理念并付诸实践，以至于在国内众多互联网公司的技术架构上也可以看到似曾相识的影子。当然殊途同归也好，经验借鉴也罢，这都不影响Netfix业界最佳实践者的地位。

Netfix运维现状

准确一点说，Netfix是没有运维岗位的，和运维对应的岗位其实是我们熟知的SRE（Site Reliability Engineer）。但我们知道SRE≠运维，SRE理念的核心是：用软件工程的方法重新设计和定义运维工作。

也就是要改变之前靠人去做运维的方式，转而通过工具体系、团队协作、组织机制和文化氛围等方式去改变，同时将之前处于研发体系最末端的运维，拉回到与开发肩并肩的同一起跑线上。

但是Netfix的神奇和强大之处在于，连Google都非常重视和大力发展的SRE岗位，在Netfix却没有几个。按照Netfix一位技术主管（Katharina Probst）在今年9月份更新的博客中所描述，在1亿用户，每天1.2亿播放时长、万级微服务实例的业务体量下，SRE人数竟然不超过10个，他们称这样的角色为Core SRE。

不可否认，Netfix拥有强大的技术实力和全球最优秀的工程师团队。按照SRE的理念，完全可以打造出这一系列的工具产品来取代运维和SRE的工作。但是能够做到如此极致，就不得不让人惊叹和好奇，Netfix到底是怎么做到的？

为什么Netfix会做得如此极致？

这确实是一个很有意思的问题，带着这样的疑问，阅读了大量的Netfix技术文章和公开的演讲内容之后，我想这个问题可以从Netfix的技术架构、组织架构、企业文化等几个方面来看。

海量业务规模下的技术架构和挑战

前面我也提到，Netfix在业务高速发展以及超大规模业务体量的驱动下，引入了更为灵活的微服务架构，而且已经成为业界的最佳实践典范。

引入微服务架构后，软件架构的细化拆分和灵活多变，大大提升了开发人员的开发效率，继而也就提升了业务需求的响应和迭代速度，我想这也正是微服务思想在业界能够被广泛接受和采用的根本原因。

但是这也并不是说没有一点代价和成本，随之而来的便是架构复杂度大大增加，而且这种复杂度已经远远超出人的认知能力，也就是我们已经无法靠人力去掌控了，这也就为后续的交付和线上运维带来了极大的难度和挑战。 这时，微服务架构下的运维就必须要靠软件工程思路去打造工具支撑体系来支持了，也就是要求微服务架构既要能够支持业务功能，还要能够提供和暴露更多的在后期交付和线上运维阶段所需的基础维护能力。

简单举几个例子，比如服务上下线、路由策略调整、并发数动态调整、功能开关、访问ACL控制、异常熔断和旁路、调用关系和服务质量日志输出等等，要在这些能力之上去建设我们的运维工具和服务平台。

讲到这里，我们可以看到，微服务架构模式下，运维已经成为整体技术架构体系中必不可少的一部分，而且与微服务架构相关的体系是紧密相连不可拆分的。

我们现在看到很多跟SRE相关的文章或内容，对于SRE产生原因的解释，大多是说为了缓解开发和运维之间的矛盾，树立共同的目标，让双方能够更好地协作配合。这样理解也没有太大的问题，但是我认为不够充分，或者说以上这些只能算是结果，但不是背后的根本原因。

我理解的这背后最根本的原因是，微服务架构复杂度到了一定程度，已经远远超出单纯的开发和单纯的运维职责范畴，也远远超出了单纯人力的认知掌控范围，所以必须寻求在此架构之上的更为有效和统一的技术解决方案来解决复杂度认知的问题。进而，在这一套统一的技术解决方案之上，开发和运维产生了新的职责分工和协作方式。

目前业界火热的DevOps理念及衍生出来的一系列话题，我们可以仔细思考一下，其实也是同样的背景和逻辑。DevOps想要解决的开发和运维之间日益严重的矛盾，究其根本，还是微服务架构背后带来的技术复杂度在不断提升的问题。

Netfix带给我们的启示一：

微服务架构模式下，我们必须换一个思路来重新定义和思考运维，运维一定要与微服务架构本身紧密结合起来。

2.更加合理的组织架构和先进的工具体系及理念

我上面提到，在微服务架构模式下，运维已经成为整体技术架构和体系中不可分割的一部分，两者脱节就会带来后续一系列的严重问题。

从这一点上，不得不说Netfix的前瞻性和技术架构能力还是很强的。因为早在2012年，甚至更早之前，Netfix就已经意识到了这个问题。在组织架构上，将中间件、SRE、DBA、交付和自动化工具、基础架构等团队都放在统一的云平台工程（Cloud and Platform Engineering）这个大团队下，在产品层面统一规划和建设，从而能够最大程度地发挥组织能力，避免了开发和运维的脱节。

当然，这个团队不仅没让大家失望，还给我们带来了太多惊喜。业界大名鼎鼎的NetfixOSS开源产品体系里，绝大部分的产品都是这个团队贡献的。

比如持续交付系统Spinnaker；稳定性保障工具体系Chaos Engineering，这里面最著名的就是那只不安分的猴子，也正是这套稳定性理念和产品最大程度地保障了Netfix系统的稳定运行；被Spring Cloud引入并得以更广泛传播的Common Runtime Service&Libraries，而且大家选用Spring Cloud基本就是冲着Spring Cloud Netfix这个子项目去的。

当然还有很多其它优秀的开源产品，这里我就不一一介绍了。

Netfix带给我们的启示二：

合理的组织架构是保障技术架构落地的必要条件，用技术手段来解决运维过程中遇到的效率和稳定问题才是根本解决方案。

3.自由与责任并存的企业文化

上面讲了这么多，看上去好像就是SRE常见的理念和套路，只不过Netfix在开源和分享上更加开放和透明，让我们有机会更多地了解到一些细节。但是为什么Netfix会做的如此极致呢？好像我们一直没有回答到这个问题，那这里就不得不提Netfix的企业文化了。

Netfix的企业文化是 Freedom & Responsibility，也就是自由和责任并存，高度自由的同时，也需要员工具备更强的责任心和Owner意识。

体现在技术团队中就是，You Build It，You Run It。工程师可以随时向生产环境提交代码或者发布新的服务，但是同时你作为Owner，要对你发布的代码和线上服务的稳定运行负责。

在这种文化的驱使下，技术团队自然会考虑从开发设计阶段到交付和线上运维阶段的端到端整体解决方案，而不会是开发就只管需求开发，后期交付和维护应该是一个叫运维的角色去考虑。No，文化使然，在Netfix是绝对不允许这种情况存在的，你是开发，你就是Owner，你就要端到端负责。

所以，短短两个英文单词，Freedom & Responsibility，却从源头上就决定了团队和员工的做事方式。

Netfix带给我们的启示三：Owner意识很重要，正确的做事方式需要引导，这就是优秀和极致的距离。

总结

通过上面的分析，我们可以看到，Netfix在其技术架构、组织架构和企业文化等方面的独到之处，造就了其优秀的技术理念和最佳实践。从运维的角度来说，无论是SRE也好，还是DevOps也罢，都被Netfix发挥到了极致。

当然，Netfix能做到这一点，是需要非常强大的技术实力和人才储备的。当前我们虽然没法直接套用，但是这并不妨碍我们在某些经验和思路上去借鉴和学习。

比如，现在很多公司在采用了微服务架构后，就没有充分考虑到后续基于微服务架构的运维问题。而且在运维团队设置上，仍然是脱离整个技术团队，更不用说将其与中间件和架构设计等团队整合拉通去建设，自然也就谈不上在产品层面的合理规划和建设了。

因此导致的问题就是运维效率低下，完全靠人工，线上故障频发，但是处理效率又极低，开发和运维都处于非常痛苦的状态之中，运维团队和成员也会遭遇到转型和成长的障碍。

以上这些问题都很棘手，亟待解决。

通过今天的分享，我们了解了Netfix的技术团队运作模式和思路，不知道给你带来了哪些启示呢？