01 | 为什么Netflix没有运维岗位?
该思维导图由 AI 生成,仅供参考
Netflix 运维现状
- 深入了解
- 翻译
- 解释
- 总结
Netflix作为业界微服务架构的典范,通过SRE理念和自由与责任并存的企业文化,实现了极致的运维和技术实践。其核心SRE团队支持着拥有1亿用户、每天1.2亿播放时长、数以万计微服务实例的庞大业务体量。Netflix将运维与微服务架构紧密结合,通过软件工程思路打造工具支撑体系来解决复杂度认知的问题。其企业文化强调自由和责任并存,鼓励员工具备Owner意识,从源头上决定了团队和员工的做事方式。这种文化驱使下,技术团队考虑从开发设计到交付和线上运维的端到端整体解决方案。Netflix的经验为我们提供了两点启示:微服务架构模式下,运维必须与微服务架构本身紧密结合;合理的组织架构是保障技术架构落地的必要条件。Netflix的技术团队运作模式和思路为业界提供了借鉴和学习的机会,尤其对于采用微服务架构的公司,应充分考虑后续基于微服务架构的运维问题,以及在运维团队设置上与整个技术团队的整合。Netflix的经验为我们指明了解决运维效率低下、线上故障频发等问题的方向。 Netflix的技术实力和人才储备是其能够做到极致运维的关键,尽管我们无法直接套用,但可以在某些经验和思路上进行借鉴和学习。
《赵成的运维体系管理课》,新⼈⾸单¥59
全部留言(23)
- 最新
- 精选
- 宵伯特就像自动化取代传统手工业,技术的发展使得生产率提升的同时,也使得行业内的职能配置不断发生变化。现在大部分的软件行业由于敏捷开发的流行也逐渐的淘汰或替换了传统的QA部门,运维的职能也逐渐的从传统的手工业向自动化不断的改进,软件的生命周期也早已不是传统瀑布开发所规定的那样简单。从软件开发的历史来看,代码层级的一些规范也逐渐的向架构层次延展,像微服务的出现不就是kiss原则和dry原则在架构设计上的应用嘛。所以,从大的方向上来看软件行业的发展其实并没有那么快,绝大多数的改变和革新都只不过是过去的理论在现在合适的时刻得到了应用而已。
作者回复: 赞!技术应用也是需要看场景和时机的。
2017-12-2116 - 白开水有具体的Netflix原则和最佳实践参考吗?
作者回复: 推荐两个Netflix的技术网站(需要翻越): Netflix的Tech Blog:https://medium.com/netflix-techblog Netflix公开分享的PPT合集:https://www.slideshare.net/netflix 特别是第一个,Netflix会持续更新他们的技术动态和实践,很好的学习案例。slideshare这个虽然内容大部分是前些年的,不过仍然会有很大的启发意义,在这里会体验到Netflix的技术前瞻性。 后面我也会有文章分享我们的一些实践,期望对你会更有帮助。
2017-12-2113 - 阿隆索作为运维人员如何权衡自己的发展呢?如果将来的运维人员的发展方向更偏于容器,k8s,自动化。那企业内应用,比如说windows的AD运维,exchange运维。企业如何在没有开发团队的基础上实现运维?开发团队如何在远离生产环境的模式中实现owner&build?
作者回复: 我看下来应该是三个问题,也确实是一个个非常典型的现状,我的答复如下: 第一个,关于如何衡量个人发展,这个问题说实话有点大,我可能无法回答全面,我建议可以把问题再具体一些。然后,个人是否能够有发展,是否能够发展地还不错,这里暗含着一个关键的前提,就是要看你个人想要什么,想要成长成什么样子。 第二个,容器、k8s和自动化,一定是未来的演进趋势,因为它们确实能够带来更高的效率,让人工作的更轻松,任何技术的发展只要能够起到上面这两个作用,就一定是有生命力的,代表着未来趋势。 第三个,关于企业内第三方产品的运维和开发问题,我的建议是当内部无法基于这些产品进行运维效率和稳定性提升方面的二次开发时,还是尽量依赖第产品方的服务,看产品方是否可以提供一些运维方便产品技术支持。 从你反馈的单个案例来看,如果还是保持现状,你提到的运维和开发这两个事情都很难改变,因为受限于产品形态和合作模式。但是从整个业界来看,你提到的这两个产品,其实微软都已经将它们上云了,如果是在云上应用,这些问题是不是就不是问题了? 可能有些问题的答案是在问题之外的,这一点可以多考虑一下,因为随之而来的还会有其它一系列问题要去考虑。 思考之后,可以继续留言给我。
2017-12-224 - 岑崟在组织架构设计方面有没有什么方法论层面的内容和方向
作者回复: 会有的,专门有两篇介绍组织架构和协作,以及个人转型的文章。
2017-12-203 - 诺克大叔owner 直接体现了自带责任属性 可以避免好多推锅和定位故障难问题
作者回复: 把事情当作自己的,处理起来最高效
2018-03-262 - 希望从专精的角度上考虑,开发和运维技术栈,看待问题的角度还是有所区别的,我比较好奇Netflix的开发人员如何做到既能关注自身开发的功能,又能关注到产品上线后的运维和部署架构?他们到达今天这个程度是开发的能力推动,还是因为运维基础平台的完善推动?
作者回复: 这个是自驱动型的,当然,很重要的一个前提是,他们技术能力非常强大,这个是国内达不到的,所以更多的需要组织架构上互补。
2018-01-232 - 阿隆索传统应用的运维模式会逐渐转变到这种模式下吗?那运维外包业务岂不是会慢慢萎缩,运维人员的成长也被局限了
作者回复: 必然会向这个方向发展,是不是会萎缩不一定,但是发展空间一定会受限。后面我也会有一篇也想来介绍这个情况。
2017-12-211 - 华仔奈飞的贡献真大 到处都是它的影子
作者回复: 奈飞在很多方面都做到了极致,成为了我们的榜样。
2020-03-28 - 趁早那具体的话,作为一个owner如何保障自己“随意”每次提交的代码没有问题?
作者回复: 从实践角度,也不是完全随意,必要的code review流程,单元测试通过率等这些肯定还是要保障的,但是肯定更多的是通过自动化的手段来完成。
2019-01-08 - 朱雯运维价值 1:定义范围:除了业务需求实现层面,其他都是运维 价值所在:运维能力就是架构能力,运维层面爆发问题或者故障,一定是技术架构中的问题,单纯看待没有意义 矛盾:割裂运维和开发,按照软件生命周期开始划分运维和开发,所以应该先转换运维思路,后提升运维技术,让运维和研发团队保持一致,聚焦效率,稳定和成本 netflix 运维现状 sre运维: 用软件工程的方法重新设计和定义运维工作 方式:微服务化 代价和成本:架构复杂度大大增加,无法人力掌控,后续的交付和线上运维难度提高,必须通过软件工程思路打造工具体系支持。 例子:比如服务上下线、路由策略调整、并发数动态调整、功能开关、访问... 为什么微服务会产生sre: 微服务架构复杂到了一定的程度,已经远远超过单纯开发和运维的职责范围,也超过了单纯人力的认知掌控范畴,所以必须的有效的统一的解决方案必须出现 自由与责任并存的企业文化:ower意识,谁构建谁负责 netflix启示一:微服务架构模式下,我们必须换一个思路来重新定义和思考运,运维一定要与微服务架构本身紧密结合起来 Netflix 带给我们的启示二:合理的组织架构是保障技术架构是落地的必要条件,用技术手段来解决运维过程中遇到的效率和稳定问题才是根本解决方案 应用:从整体服务拆出来的独立模块,每个模块只执行一个功能,可以独立运行和部署。每一个应用都有单一的业务职能,如果要完成整体的业务流程和目标,那么需要和其他应用交互,同时执行过程中会和其他的基础设施和组件进行交互,比如机器,域名,db,缓存,消息队列等2019-04-188