赵成的运维体系管理课
赵成
《进化: 运维技术变革与实践探索》作者
37829 人已学习
新⼈⾸单¥59
登录后,你可以任选4讲全文学习
课程目录
已完结/共 49 讲
开篇词 (1讲)
效率和稳定性最佳实践 (20讲)
赵成的运维体系管理课
15
15
1.0x
00:00/00:00
登录|注册

01 | 为什么Netflix没有运维岗位?

Owner意识的重要性
工程师的端到端责任
Freedom & Responsibility文化
用技术手段解决运维效率和稳定问题
NetflixOSS开源产品体系
统一的云平台工程团队
运维与微服务架构紧密相连
运维必须靠软件工程思路去打造工具支撑体系
微服务架构的灵活性和复杂度
微服务架构下的运维问题亟待解决
借鉴和学习Netflix的经验和思路
SRE和DevOps在Netflix得到极致发挥
Netflix的优秀技术理念和最佳实践
自由与责任并存的企业文化
更加合理的组织架构和先进的工具体系及理念
海量业务规模下的技术架构和挑战
Netflix的SRE人数不超过10个
用软件工程的方法重新定义运维工作
SRE(Site Reliability Engineer)≠运维
总结
为什么Netflix会做得如此极致?
Netflix运维现状
为什么Netflix没有运维岗位?

该思维导图由 AI 生成,仅供参考

众所周知,Netflix 是业界微服务架构的最佳实践者,其基于公有云上的微服务架构设计、持续交付、监控、稳定性保障,都为业界提供了大量可遵从的原则和实践经验。
Netflix 超前提出某些理念并付诸实践,以至于在国内众多互联网公司的技术架构上也可以看到似曾相识的影子。当然殊途同归也好,经验借鉴也罢,这都不影响 Netflix 业界最佳实践者的地位。
同样,在运维这个细分领域,Netflix 仍然是最佳实践的典范。所以专栏的开始,就让我们一起看看世界顶级的互联网公司是如何定义运维以及如何开展运维工作的。

Netflix 运维现状

准确一点说,Netflix 是没有运维岗位的,和运维对应的岗位其实是我们熟知的 SRE(Site Reliability Engineer)。但我们知道 SRE≠运维,SRE 理念的核心是:用软件工程的方法重新设计和定义运维工作
也就是要改变之前靠人去做运维的方式,转而通过工具体系、团队协作、组织机制和文化氛围等方式去改变,同时将之前处于研发体系最末端的运维,拉回到与开发肩并肩的同一起跑线上。
但是 Netflix 的神奇和强大之处在于,连 Google 都非常重视和大力发展的 SRE 岗位,在 Netflix 却没有几个。按照 Netflix 一位技术主管(Katharina Probst)在今年 9 月份更新的博客中所描述,在 1 亿用户,每天 1.2 亿播放时长、万级微服务实例的业务体量下,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.
不可否认,Netflix 拥有强大的技术实力和全球最优秀的工程师团队。按照 SRE 的理念,完全可以打造出这一系列的工具产品来取代运维和 SRE 的工作。但是能够做到如此极致,就不得不让人惊叹和好奇,Netflix 到底是怎么做到的?
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

Netflix作为业界微服务架构的典范,通过SRE理念和自由与责任并存的企业文化,实现了极致的运维和技术实践。其核心SRE团队支持着拥有1亿用户、每天1.2亿播放时长、数以万计微服务实例的庞大业务体量。Netflix将运维与微服务架构紧密结合,通过软件工程思路打造工具支撑体系来解决复杂度认知的问题。其企业文化强调自由和责任并存,鼓励员工具备Owner意识,从源头上决定了团队和员工的做事方式。这种文化驱使下,技术团队考虑从开发设计到交付和线上运维的端到端整体解决方案。Netflix的经验为我们提供了两点启示:微服务架构模式下,运维必须与微服务架构本身紧密结合;合理的组织架构是保障技术架构落地的必要条件。Netflix的技术团队运作模式和思路为业界提供了借鉴和学习的机会,尤其对于采用微服务架构的公司,应充分考虑后续基于微服务架构的运维问题,以及在运维团队设置上与整个技术团队的整合。Netflix的经验为我们指明了解决运维效率低下、线上故障频发等问题的方向。 Netflix的技术实力和人才储备是其能够做到极致运维的关键,尽管我们无法直接套用,但可以在某些经验和思路上进行借鉴和学习。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《赵成的运维体系管理课》
新⼈⾸单¥59
立即购买
登录 后留言

全部留言(23)

  • 最新
  • 精选
  • 宵伯特
    就像自动化取代传统手工业,技术的发展使得生产率提升的同时,也使得行业内的职能配置不断发生变化。现在大部分的软件行业由于敏捷开发的流行也逐渐的淘汰或替换了传统的QA部门,运维的职能也逐渐的从传统的手工业向自动化不断的改进,软件的生命周期也早已不是传统瀑布开发所规定的那样简单。从软件开发的历史来看,代码层级的一些规范也逐渐的向架构层次延展,像微服务的出现不就是kiss原则和dry原则在架构设计上的应用嘛。所以,从大的方向上来看软件行业的发展其实并没有那么快,绝大多数的改变和革新都只不过是过去的理论在现在合适的时刻得到了应用而已。

    作者回复: 赞!技术应用也是需要看场景和时机的。

    2017-12-21
    16
  • 白开水
    有具体的Netflix原则和最佳实践参考吗?

    作者回复: 推荐两个Netflix的技术网站(需要翻越): Netflix的Tech Blog:https://medium.com/netflix-techblog Netflix公开分享的PPT合集:https://www.slideshare.net/netflix 特别是第一个,Netflix会持续更新他们的技术动态和实践,很好的学习案例。slideshare这个虽然内容大部分是前些年的,不过仍然会有很大的启发意义,在这里会体验到Netflix的技术前瞻性。 后面我也会有文章分享我们的一些实践,期望对你会更有帮助。

    2017-12-21
    13
  • 阿隆索
    作为运维人员如何权衡自己的发展呢?如果将来的运维人员的发展方向更偏于容器,k8s,自动化。那企业内应用,比如说windows的AD运维,exchange运维。企业如何在没有开发团队的基础上实现运维?开发团队如何在远离生产环境的模式中实现owner&build?

    作者回复: 我看下来应该是三个问题,也确实是一个个非常典型的现状,我的答复如下: 第一个,关于如何衡量个人发展,这个问题说实话有点大,我可能无法回答全面,我建议可以把问题再具体一些。然后,个人是否能够有发展,是否能够发展地还不错,这里暗含着一个关键的前提,就是要看你个人想要什么,想要成长成什么样子。 第二个,容器、k8s和自动化,一定是未来的演进趋势,因为它们确实能够带来更高的效率,让人工作的更轻松,任何技术的发展只要能够起到上面这两个作用,就一定是有生命力的,代表着未来趋势。 第三个,关于企业内第三方产品的运维和开发问题,我的建议是当内部无法基于这些产品进行运维效率和稳定性提升方面的二次开发时,还是尽量依赖第产品方的服务,看产品方是否可以提供一些运维方便产品技术支持。 从你反馈的单个案例来看,如果还是保持现状,你提到的运维和开发这两个事情都很难改变,因为受限于产品形态和合作模式。但是从整个业界来看,你提到的这两个产品,其实微软都已经将它们上云了,如果是在云上应用,这些问题是不是就不是问题了? 可能有些问题的答案是在问题之外的,这一点可以多考虑一下,因为随之而来的还会有其它一系列问题要去考虑。 思考之后,可以继续留言给我。

    2017-12-22
    4
  • 岑崟
    在组织架构设计方面有没有什么方法论层面的内容和方向

    作者回复: 会有的,专门有两篇介绍组织架构和协作,以及个人转型的文章。

    2017-12-20
    3
  • 诺克大叔
    owner 直接体现了自带责任属性 可以避免好多推锅和定位故障难问题

    作者回复: 把事情当作自己的,处理起来最高效

    2018-03-26
    2
  • 希望
    从专精的角度上考虑,开发和运维技术栈,看待问题的角度还是有所区别的,我比较好奇Netflix的开发人员如何做到既能关注自身开发的功能,又能关注到产品上线后的运维和部署架构?他们到达今天这个程度是开发的能力推动,还是因为运维基础平台的完善推动?

    作者回复: 这个是自驱动型的,当然,很重要的一个前提是,他们技术能力非常强大,这个是国内达不到的,所以更多的需要组织架构上互补。

    2018-01-23
    2
  • 阿隆索
    传统应用的运维模式会逐渐转变到这种模式下吗?那运维外包业务岂不是会慢慢萎缩,运维人员的成长也被局限了

    作者回复: 必然会向这个方向发展,是不是会萎缩不一定,但是发展空间一定会受限。后面我也会有一篇也想来介绍这个情况。

    2017-12-21
    1
  • 华仔
    奈飞的贡献真大 到处都是它的影子

    作者回复: 奈飞在很多方面都做到了极致,成为了我们的榜样。

    2020-03-28
  • 趁早
    那具体的话,作为一个owner如何保障自己“随意”每次提交的代码没有问题?

    作者回复: 从实践角度,也不是完全随意,必要的code review流程,单元测试通过率等这些肯定还是要保障的,但是肯定更多的是通过自动化的手段来完成。

    2019-01-08
  • 朱雯
    运维价值 1:定义范围:除了业务需求实现层面,其他都是运维 价值所在:运维能力就是架构能力,运维层面爆发问题或者故障,一定是技术架构中的问题,单纯看待没有意义 矛盾:割裂运维和开发,按照软件生命周期开始划分运维和开发,所以应该先转换运维思路,后提升运维技术,让运维和研发团队保持一致,聚焦效率,稳定和成本 netflix 运维现状 sre运维: 用软件工程的方法重新设计和定义运维工作 方式:微服务化 代价和成本:架构复杂度大大增加,无法人力掌控,后续的交付和线上运维难度提高,必须通过软件工程思路打造工具体系支持。 例子:比如服务上下线、路由策略调整、并发数动态调整、功能开关、访问... 为什么微服务会产生sre: 微服务架构复杂到了一定的程度,已经远远超过单纯开发和运维的职责范围,也超过了单纯人力的认知掌控范畴,所以必须的有效的统一的解决方案必须出现 自由与责任并存的企业文化:ower意识,谁构建谁负责 netflix启示一:微服务架构模式下,我们必须换一个思路来重新定义和思考运,运维一定要与微服务架构本身紧密结合起来 Netflix 带给我们的启示二:合理的组织架构是保障技术架构是落地的必要条件,用技术手段来解决运维过程中遇到的效率和稳定问题才是根本解决方案 应用:从整体服务拆出来的独立模块,每个模块只执行一个功能,可以独立运行和部署。每一个应用都有单一的业务职能,如果要完成整体的业务流程和目标,那么需要和其他应用交互,同时执行过程中会和其他的基础设施和组件进行交互,比如机器,域名,db,缓存,消息队列等
    2019-04-18
    8
收起评论
显示
设置
留言
23
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部