研发效率破局之道
葛俊
前Facebook内部工具团队Tech Lead
立即订阅
3343 人已学习
课程目录
已完结 39 讲
0/4登录后,你可以任选4讲全文学习。
开篇词 (1讲)
开篇词 | 为什么你要关注研发效能?
免费
研发效能综述 (3讲)
01 | 效能模型:如何系统地理解研发效能?
02 | 效能度量:效果不好甚至有副作用,怎么回事?
03 | 效能度量:如何选对指标与方法,真正提升效能?
研发流程 (7讲)
04 | 流程优化:怎样才能让敏捷、精益真正为我所用?
05 | 代码入库前:Facebook如何让开发人员聚焦于开发?
06 | 代码入库到产品上线:Facebook如何使用CI/CD满足业务要求?
07 | 分支管理:Facebook的策略,适合我的团队吗?
08 | DevOps、SRE的共性:应用全栈思路打通开发和运维
09 | 信息流通:让团队高效协同,让产品准确击中目标
10 | 答疑篇:反对996并不是反对奋斗
工程方法 (10讲)
11 | 研发环境:Facebook怎样让开发人员不再操心环境?
12 | 代码审查:哪种方式更适合我的团队?
13 | 代码审查:学习Facebook真正发挥代码审查的提效作用
14 | 质量与速度的均衡:让“唯快不破”快得更持久
15 | 开源:从Phabricator的开源历程看开源利弊
16 | 高效上云:如何用云计算来提高效能?
17 | 测试左移:测试如何应对新的开发模式?
18 | 蓝绿红黑灰度发布:这些五颜六色的发布到底怎么用?
19 | 不再掉队,研发流程、工程方法趋势解读和展望
20 | 答疑篇:如何平衡短期收益和长期收益?
个人效能 (11讲)
21 | 高效工作:Facebook的10x程序员效率心法
22 | 深度工作:聚焦最有价值的事儿
23 | 效率工具:选对用对才能事半功倍
特别放送 | 每个开发人员都应该学一些VIM
24 | VIM:如何高性价比地学习VIM的实用技巧?
25 | 玩转Git:五种提高代码提交原子性的基本操作
26 | Facebook怎样实现代码提交的原子性?
27 | 命令行:不只是酷,更重要的是能提高个人效能
28 | 从工作场景出发,寻找炫酷且有效的命令行工具
29 | 1+1>2,灵活的工具组合及环境让你的工作效率翻倍
30 | 答疑篇:关于价值导向和沟通
管理和文化 (6讲)
31 | 业务目标和技术目标两手抓:怎样打造高效团队?
32 | 从Netflix公开的著名PPT谈硅谷公司文化
33 | Facebook企业文化:工程师文化是创造力引擎
34 | Facebook工程师文化实践三大支柱之一做感兴趣的事
35 | Facebook工程师文化实践三大支柱之二拥有信息和权限
36 | Facebook工程师文化实践三大支柱之三绩效调节
结束语 (1讲)
结束语 | 超越昨天的自己,享受成长的快乐
研发效率破局之道
登录|注册

08 | DevOps、SRE的共性:应用全栈思路打通开发和运维

葛俊 2019-09-09
你好,我是葛俊。今天,我来跟你聊一聊 DevOps 和 SRE。
DevOps 和 SRE,尤其是 DevOps,是最近几年软件研发方法的重要趋势。因为它们都跟打通开发和运维流程相关,所以常常被混淆。比如,SRE 等同于 Google 的 DevOps、SRE 是升级版的 DevOps,就是两个常见的误区。
事实上,DevOps 和 SRE 虽然关系紧密,但差别还是蛮大的。所以今天,我首先会通过 DevOps 和 SRE 的对比,引出它们背后的 Why、How 和 What(也就是它们的目标、原则和具体实践)。然后,我会结合自己在一个创业公司的经验,向你推荐如何在团队落地 DevOps。

DevOps 和 SRE 的定义和异同

因为 DevOps 和 SRE 都是比较新的概念,而且在不断地发展变化,所以学术界和工业界对它们的定义并未达成一致。
接下来,我参考已有定义,并加入自己的理解,对 DevOps 和 SRE 的大致定义如下:
DevOps,Development 和 Operations 的组合词,是一种重视“软件开发人员(Dev)”和“IT 运维技术人员(Ops)”之间沟通合作的文化、活动或惯例。 通过自动化“软件交付”和“架构变更”的流程,使得软件的构建、测试、发布更加快捷、频繁和可靠。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《研发效率破局之道》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(8)

  • 名贤集
    这位大佬,你也没说使用devops遇到什么问题,如何解决的。
    devops跟9999没有直接关系,用devops不一定能达到9999,不用也不一定达不到。
    全栈开发跟devops有关系吗?前端和后端都是写代码-单元测试-签入-集成测试,所用的devops也是一样的。怎么感觉你的文章都飘在天上呢?

    作者回复: > 这位大佬,你也没说使用devops遇到什么问题,如何解决的。
    你是指DevOps是用来解决什么问题,还是使用DevOps遇到的问题?
    如果是前者的话,文中已经讲了是为了打通Dev和Ops,从而使得研发流程顺畅,提高效能。
    如果问的是后者,跟这篇文章的主题相关性不大,所以没有专门提。不过既然你提到了,我觉得DevOps的一个大问题是当前方法论提的比较多,大家理解的还不深入,更关注的是工具。

    > devops跟9999没有直接关系,用devops不一定能达到9999,不用也不一定达不到。
    DevOps可以大大帮助提高质量,帮助实现9999。至少从我在Facebook的经验和Stand公司来看,是这样的。

    > 全栈开发跟devops有关系吗?
    文中已经说了,全栈开发是实现DevOps的一个重要方法。

    > 前端和后端都是写代码-单元测试-签入-集成测试,所用的devops也是一样的。怎么感觉你的文章都飘在天上呢?
    谢谢你给反馈。你觉得什么算”飘在天上“,什么才算“不飘在天上”?

    2019-09-17
    2
  • 刘晓光
    全栈!=全干
    全栈的支撑基础是服务化和技术封装。其实还是底层支撑越来越牛逼了。如果一个组织没有很好的底层技术支撑,

    作者回复: 全栈!=全干 简介明了!

    2019-09-09
    2
  • 兴国
    成为全栈工程师也是分阶段,分领域的。比如平常主要做java的开发人员,基于工作需要,也需要写前端,会golang/php等语言;也需要对运维服务器进行部署/使用,使用运维工具进行发布等。刚开始可能对前端等只是会写,并不能搭建框架,不了解其原理;对服务器部署原理,网络搭建原理也不了解。但是能够满足日常的开发,运维需要。随着时间的推移,业务的发展以及问题的不断出现和解决。慢慢的能够更深入了解除java开发之外的东西,慢慢加强巩固自己的技术栈。当然也不是说什么都要会,更多的还是工作中,业务中用到的,主要还是要服务于业务发展。所以是分时间段,分领域的。

    作者回复: 分时间段这个思考维度是对的。同时也说明了我们软件开发挑战和有趣的地方:不断有新的东西出现需要学习。

    2019-09-09
    2
  • 刘丹
    全栈工程师不一定全领域,准确的说法应该是多领域,掌握大部分领域,精通少数领域。

    作者回复: 是的。全栈的开发是T字型人才。一横表示了解多领域。一竖表示精通少数领域。

    2019-09-09
    2
  • Do
    Facebook是没有测试团队的吗?所有功能都是对应的开发自测?

    作者回复: 是的。可以参考一下文章中的相关介绍:https://techbeacon.com/app-dev-testing/5-effective-powerful-ways-test-tech-giants

    2019-10-20
    1
  • 💪😊
    其实早起在土鳖公司都是全栈的,全栈的好处很明显减少扯皮,对功能聚焦。刚开始可能觉得有难度,其实刚开始比如可以有一个资深的前端搭建框架,后面更改和填充功能就容易多了

    作者回复: 是这样的。很多公司一开始都是全栈的。不过。这种全栈和我们在文章中提到的全栈有一些区别。这种全栈是什么都要从头到尾做,而文中提到的全栈是专注于开发这一领域。其他的领域会有领域专家提供一些技术和工具支持。

    2019-09-10
    1
  • 桃源小盼
    全栈工程师,在面对一些非常见问题时,会更快的定位问题,而不是以前那样,大家都觉得跟自己没关系,就等着别人去解决。

    作者回复: 是的。这就是目标一致的好处。

    2019-09-09
    1
  • MiffyLiye
    现有的工具越来越成熟,个人/小团队能掌控的复杂度越来越高。
    同时社会发展变快,提高研发效率,对市场需求快速反应越来越重要。
    这些因素就让成为全栈工程师的投入产出比越来越高,变成了非常值得去发展的方向。

    作者回复: 👍👍👍

    2019-09-09
收起评论
8
返回
顶部