为什么Netflix没有运维岗位？
Netflix 是业界微服务架构的最佳实践者，其基于公有云上的微服务架构设计、持续交付、监控、稳定性保障，都为业界提供了大量可遵从的原则和实践经验。
在运维这个细分领域，Netflix 仍然是最佳实践的典范。世界顶级的互联网公司是如何定义运维以及如何开展运维工作的。
Netflix 运维现状
Netflix 是没有运维岗位的，和运维对应的岗位是SRE（Site Reliability Engineer）.SRE≠运维，SRE 理念的核心是：用软件工程的方法重新设计和定义运维工作。
改变之前靠人去做运维的方式，转而通过工具体系、团队协作、组织机制和文化氛围等方式去改变，将之前处于研发体系最末端的运维，拉回到与开发肩并肩的同一起跑线上。
为什么 Netflix 会做得如此极致？
可以从 Netflix 的技术架构、组织架构、企业文化等几个方面来看。
1. 海量业务规模下的技术架构和挑战
引入了灵活的微服务架构，提高了开发人员的开发效率。但架构复杂度大大增加，已经无法靠人工去掌控了，为后续的交付和线上运维带来了极大的难度和挑战，所以必须寻求在此架构之上的更为有效和统一的技术解决方案来解决复杂度认知的问题。进而，在这一套统一的技术解决方案之上，开发和运维产生了新的职责分工和协作方式，也就是SRE。这时，微服务架构下的运维就必须要靠软件工程思路去打造工具支撑体系来支持。也就是要求微服务架构既要能够支持业务功能，还要能够提供和暴露更多的在后期交付和线上运维阶段所需的基础维护能力。
简单举几个例子，比如服务上下线、路由策略调整、并发数动态调整、功能开关、访问 ACL 控制、异常熔断和旁路、调用关系和服务质量日志输出等等，要在这些能力之上去建设我们的运维工具和服务平台。
可以看到，微服务架构模式下，运维已经成为整体技术架构体系中必不可少的一部分，而且与微服务架构相关的体系是紧密相连不可拆分的。
DevOps 理念及衍生出来的一系列话题，可以仔细思考一下，其实也是同样的背景和逻辑。DevOps 想要解决的开发和运维之间日益严重的矛盾，究其根本，还是微服务架构背后带来的技术复杂度在不断提升的问题。
Netflix 带给我们的启示一：微服务架构模式下，我们必须换一个思路来重新定义和思考运维，运维一定要与微服务架构本身紧密结合起来。
2. 更加合理的组织架构和先进的工具体系及理念
上面提到，在微服务架构模式下，运维已经成为整体技术架构和体系中不可分割的一部分，两者脱节就会带来后续一系列的严重问题。
早在 2012 年，甚至更早之前，Netflix 就已经意识到了这个问题。在组织架构上，将中间件、SRE、DBA、交付和自动化工具、基础架构等团队都放在统一的云平台工程（Cloud and Platform Engineering）这个大团队下，在产品层面统一规划和建设，从而能够最大程度地发挥组织能力，避免了开发和运维的脱节。
Netflix 带给我们的启示二：合理的组织架构是保障技术架构落地的必要条件，用技术手段来解决运维过程中遇到的效率和稳定问题才是根本解决方案。
3. 自由与责任并存的企业文化
Netflix 的企业文化是 Freedom & Responsibility，也就是自由和责任并存，高度自由的同时，也需要员工具备更强的责任心和 Owner 意识。
体现在技术团队中就是，You Build It，You Run It。工程师可以随时向生产环境提交代码或者发布新的服务，但是同时你作为 Owner，要对你发布的代码和线上服务的稳定运行负责。
在这种文化的驱使下，技术团队自然会考虑从开发设计阶段到交付和线上运维阶段的端到端整体解决方案，而不会是开发就只管需求开发，后期交付和维护应该是一个叫运维的角色去考虑。No，文化使然，在 Netflix 是绝对不允许这种情况存在的，你是开发，你就是 Owner，你就要端到端负责。
Netflix 带给我们的启示三：Owner 意识很重要，正确的做事方式需要引导，这就是优秀和极致的距离。
问题：
现在很多公司在采用了微服务架构后，就没有充分考虑到后续基于微服务架构的运维问题。而且在运维团队设置上，仍然是脱离整个技术团队，更不用说将其与中间件和架构设计等团队整合拉通去建设，自然也就谈不上在产品层面的合理规划和建设了。
因此导致的问题就是运维效率低下，完全靠人工，线上故障频发，但是处理效率又极低，开发和运维都处于非常痛苦的状态之中，运维团队和成员也会遭遇到转型和成长的障碍。
总结：
1.微服务架构模式下，我们必须换一个思路来重新定义和思考运维，运维一定要与微服务架构本身紧密结合起来。
2.合理的组织架构是保障技术架构落地的必要条件，用技术手段来解决运维过程中遇到的效率和稳定问题才是根本解决方案。
3.Owner 意识很重要，正确的做事方式需要引导，这就是优秀和极致的距离。
4.从人工运维转向通过工具体系、团队协作、组织机制和文化氛围等方式去改变。
最新文章
- 从Google工程师到创业CTO，他的8项理念也许可以帮到你
- int与string类型的转换
- 如何在没有域的环境中搭建AlwaysOn（一）
- volcanol_Linux_ 问题汇总系列_4_Thinkpad_E40_0578MDC_在Fedora 13 Linux(FC13)中如何安装无线网卡驱动
- iOS开发UI篇—Quartz2D简单使用(二)
- Intel DPDK的一些参资料
- Swift数据类型简介
- 【LeetCode OJ】LRU Cache
- 国外大神Leo-G的 DevopsWiki
- 一道来自华为的C机试题目
- kinect for windows - 环境搭建
- HTML 5 简介、视频、Video + DOM、音频、拖放
- Cannot be cast to java.lang.Comparable异常
- MapReduce 原理与 Python 实践
- mysql数据库 索引 事务和事务回滚
- sc.exe用法详解
- 解决.NET iis初次加载超级慢
- Css中如何使英文和拼音变成全大写、全小写和首字母大写？
- Python while 循环使用实例
- 训练赛第二场C题 zoj 2339 Hyperhuffman