赵成的运维体系管理课
赵成
蘑菇街平台技术总监
立即订阅
5576 人已学习
课程目录
已完结 48 讲
0/4登录后,你可以任选4讲全文学习。
开篇词 (1讲)
开篇词 | 带给你不一样的运维思考
免费
应用运维体系建设 (11讲)
01 | 为什么Netflix没有运维岗位?
02 | 微服务架构时代,运维体系建设为什么要以“应用”为核心?
03 | 标准化体系建设(上):如何建立应用标准化体系和模型?
04 | 标准化体系建设(下):如何建立基础架构标准化及服务化体系?
05 | 如何从生命周期的视角看待应用运维体系建设?
06 | 聊聊CMDB的前世今生
07 | 有了CMDB,为什么还需要应用配置管理?
08 | 如何在CMDB中落地应用的概念?
09 | 如何打造运维组织架构?
10 | 谷歌SRE运维模式解读
11 | 从谷歌CRE谈起,运维如何培养服务意识?
效率和稳定性最佳实践 (20讲)
12 | 持续交付知易行难,想做成这事你要理解这几个关键点
13 | 持续交付的第一关键点:配置管理
14 | 如何做好持续交付中的多环境配置管理?
15 | 开发和测试争抢环境?是时候进行多环境建设了
16 | 线上环境建设,要扛得住真刀真枪的考验
17 | 人多力量大vs.两个披萨原则,聊聊持续交付中的流水线模式
18 | 持续交付流水线软件构建难吗?有哪些关键问题?
19 | 持续交付中流水线构建完成后就大功告成了吗?别忘了质量保障
20 | 做持续交付概念重要还是场景重要?看“笨办法”如何找到最佳方案
21 | 极端业务场景下,我们应该如何做好稳定性保障?
22 | 稳定性实践:容量规划之业务场景分析
23 | 稳定性实践:容量规划之压测系统建设
24 | 稳定性实践:限流降级
25 | 稳定性实践:开关和预案
26 | 稳定性实践:全链路跟踪系统,技术运营能力的体现
27 | 故障管理:谈谈我对故障的理解
28 | 故障管理:故障定级和定责
29 | 故障管理:鼓励做事,而不是处罚错误
30 | 故障管理:故障应急和故障复盘
31 | 唇亡齿寒,运维与安全
云计算时代的运维实践 (6讲)
32 | 为什么蘑菇街会选择上云?是被动选择还是主动出击?
33 | 为什么混合云是未来云计算的主流形态?
34 | Spring Cloud:面向应用层的云架构解决方案
35 | 以绝对优势立足:从CDN和云存储来聊聊云生态的崛起
36 | 量体裁衣方得最优解:聊聊页面静态化架构和二级CDN建设
37 | 云计算时代,我们所说的弹性伸缩,弹的到底是什么?
个人成长 (5讲)
38 | 我是如何走上运维岗位的?
39 | 云计算和AI时代,运维应该如何做好转型?
40 | 运维需要懂产品和运营吗?
41 | 冷静下来想想,员工离职这事真能“防得住”吗?
42 | 树立个人品牌意识:从背景调查谈谈职业口碑的重要性
加餐 (4讲)
划重点:赵成的运维体系管理课精华(一)
划重点:赵成的运维体系管理课精华(二)
划重点:赵成的运维体系管理课精华(三)
新书 |《进化:运维技术变革与实践探索》
结束语 (1讲)
结束语 | 学习的过程,多些耐心和脚踏实地
赵成的运维体系管理课
登录|注册

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

赵成 2017-12-20
众所周知,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/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《赵成的运维体系管理课》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(16)

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

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

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

    作者回复: 推荐两个Netflix的技术网站(需要翻越):

    Netflix的Tech Blog:https://medium.com/netflix-techblog

    Netflix公开分享的PPT合集:https://www.slideshare.net/netflix

    特别是第一个,Netflix会持续更新他们的技术动态和实践,很好的学习案例。slideshare这个虽然内容大部分是前些年的,不过仍然会有很大的启发意义,在这里会体验到Netflix的技术前瞻性。

    后面我也会有文章分享我们的一些实践,期望对你会更有帮助。

    2017-12-21
    5
  • 朱雯
    运维价值
    1:定义范围:除了业务需求实现层面,其他都是运维
    价值所在:运维能力就是架构能力,运维层面爆发问题或者故障,一定是技术架构中的问题,单纯看待没有意义
    矛盾:割裂运维和开发,按照软件生命周期开始划分运维和开发,所以应该先转换运维思路,后提升运维技术,让运维和研发团队保持一致,聚焦效率,稳定和成本

    netflix 运维现状
    sre运维: 用软件工程的方法重新设计和定义运维工作
    方式:微服务化
    代价和成本:架构复杂度大大增加,无法人力掌控,后续的交付和线上运维难度提高,必须通过软件工程思路打造工具体系支持。
    例子:比如服务上下线、路由策略调整、并发数动态调整、功能开关、访问...
    为什么微服务会产生sre: 微服务架构复杂到了一定的程度,已经远远超过单纯开发和运维的职责范围,也超过了单纯人力的认知掌控范畴,所以必须的有效的统一的解决方案必须出现
    自由与责任并存的企业文化:ower意识,谁构建谁负责

    netflix启示一:微服务架构模式下,我们必须换一个思路来重新定义和思考运,运维一定要与微服务架构本身紧密结合起来
    Netflix 带给我们的启示二:合理的组织架构是保障技术架构是落地的必要条件,用技术手段来解决运维过程中遇到的效率和稳定问题才是根本解决方案

    应用:从整体服务拆出来的独立模块,每个模块只执行一个功能,可以独立运行和部署。每一个应用都有单一的业务职能,如果要完成整体的业务流程和目标,那么需要和其他应用交互,同时执行过程中会和其他的基础设施和组件进行交互,比如机器,域名,db,缓存,消息队列等
    2019-04-18
    2
  • 玉剑冰锋
    老师您好,听了两小节了课程了,有几个想法想听听您的见解:1.案例中提到的毕竟是整个行业的风向标或者说是趋势,但是这毕竟是大公司或者具备很强团队才能达到预期效果,如果一个公司才几十个人或者上百人,这种情况该如何处理?2.我相信大部分中小型公司运维岗位还是必须要设立的,而且更多的是人肉运维,是否能给这些人一些建议或者发现方向,谢谢!
    2018-09-03
    2
  • 岑崟
    在组织架构设计方面有没有什么方法论层面的内容和方向

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

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

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

    2018-03-26
    1
  • zyq
    我能明白市场选择所带来的阵痛,不管是对企业对个人。其实运维主要面临两个问题:一个是企业方面,如果市场趋势如此,那企业在选择业务服务的话,是否应该把运维独立出来以服务的形式提供,并且押宝在上面。另一个就是运维人员,因为如果按照这种趋势下去,运维最终会由工具的使用者转变为工具的制造者。这个转变是巨大的,也有会一部分开发者进入这一领域,对传统运维冲击很大。另外就是对第三方独立应用来说,如何提供产品,以及后续的交付都是值得深思的地方。
    2017-12-25
    1
  • zyq
    作为运维人员如何权衡自己的发展呢?如果将来的运维人员的发展方向更偏于容器,k8s,自动化。那企业内应用,比如说windows的AD运维,exchange运维。企业如何在没有开发团队的基础上实现运维?开发团队如何在远离生产环境的模式中实现owner&build?

    作者回复: 我看下来应该是三个问题,也确实是一个个非常典型的现状,我的答复如下:

    第一个,关于如何衡量个人发展,这个问题说实话有点大,我可能无法回答全面,我建议可以把问题再具体一些。然后,个人是否能够有发展,是否能够发展地还不错,这里暗含着一个关键的前提,就是要看你个人想要什么,想要成长成什么样子。

    第二个,容器、k8s和自动化,一定是未来的演进趋势,因为它们确实能够带来更高的效率,让人工作的更轻松,任何技术的发展只要能够起到上面这两个作用,就一定是有生命力的,代表着未来趋势。

    第三个,关于企业内第三方产品的运维和开发问题,我的建议是当内部无法基于这些产品进行运维效率和稳定性提升方面的二次开发时,还是尽量依赖第产品方的服务,看产品方是否可以提供一些运维方便产品技术支持。

    从你反馈的单个案例来看,如果还是保持现状,你提到的运维和开发这两个事情都很难改变,因为受限于产品形态和合作模式。但是从整个业界来看,你提到的这两个产品,其实微软都已经将它们上云了,如果是在云上应用,这些问题是不是就不是问题了?

    可能有些问题的答案是在问题之外的,这一点可以多考虑一下,因为随之而来的还会有其它一系列问题要去考虑。

    思考之后,可以继续留言给我。

    2017-12-22
    1
  • leo
    期待后续更新
    2017-12-21
    1
  • zyq
    传统应用的运维模式会逐渐转变到这种模式下吗?那运维外包业务岂不是会慢慢萎缩,运维人员的成长也被局限了

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

    2017-12-21
    1
  • 苦行僧
    you build it ,you run it
    2019-03-27
  • 趁早
    那具体的话,作为一个owner如何保障自己“随意”每次提交的代码没有问题?
    2019-01-08
  • cc
    很有感触,我觉得这种模式正是需要的,运维不能只做背锅侠
    2018-11-19
  • kkgo
    这种技术储备要掌握那些技能
    2018-09-05
  • 大爷静悄悄
    Netflix 带给我们的启示二:合理的组织架构是保障技术架构落地的必要条件,用技术手段来解决运维过程中遇到的效率和稳定问题才是根本解决方案。
    2018-05-20
  • 希望
    从专精的角度上考虑,开发和运维技术栈,看待问题的角度还是有所区别的,我比较好奇Netflix的开发人员如何做到既能关注自身开发的功能,又能关注到产品上线后的运维和部署架构?他们到达今天这个程度是开发的能力推动,还是因为运维基础平台的完善推动?

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

    2018-01-23
收起评论
16
返回
顶部