软件工程之美
宝玉
Groupon资深工程师,微软最有价值专家
立即订阅
6699 人已学习
课程目录
已完结 54 讲
0/4登录后,你可以任选4讲全文学习。
课前必读 (3讲)
开篇词 | 你为什么应该学好软件工程?
免费
特别放送 | 从软件工程的角度解读任正非的新年公开信
学习攻略 | 怎样学好软件工程?
基础理论 (9讲)
01 | 到底应该怎样理解软件工程?
02 | 工程思维:把每件事都当作一个项目来推进
03 | 瀑布模型:像工厂流水线一样把软件开发分层化
04 | 瀑布模型之外,还有哪些开发模型?
05 | 敏捷开发到底是想解决什么问题?
06 | 大厂都在用哪些敏捷方法?(上)
07 | 大厂都在用哪些敏捷方法?(下)
08 | 怎样平衡软件质量与时间成本范围的关系?
“一问一答”第1期 | 30个软件开发常见问题解决策略
项目规划篇 (8讲)
09 | 为什么软件工程项目普遍不重视可行性分析?
10 | 如果你想技术转管理,先来试试管好一个项目
11 | 项目计划:代码未动,计划先行
12 | 流程和规范:红绿灯不是约束,而是用来提高效率
13 | 白天开会,加班写代码的节奏怎么破?
14 | 项目管理工具:一切管理问题,都应思考能否通过工具解决
15 | 风险管理:不能盲目乐观,凡事都应该有B计划
16 | 怎样才能写好项目文档?
需求分析篇 (5讲)
17 | 需求分析到底要分析什么?怎么分析?
18 | 原型设计:如何用最小的代价完成产品特性?
19 | 作为程序员,你应该有产品意识
20 | 如何应对让人头疼的需求变更问题?
“一问一答”第2期 | 30个软件开发常见问题解决策略
系统设计篇 (4讲)
21 | 架构设计:普通程序员也能实现复杂系统?
22 | 如何为项目做好技术选型?
23 | 架构师:不想当架构师的程序员不是好程序员
24 | 技术债务:是继续修修补补凑合着用,还是推翻重来?
开发编码篇 (7讲)
25 | 有哪些方法可以提高开发效率?
26 | 持续交付:如何做到随时发布新版本到生产环境?
27 | 软件工程师的核心竞争力是什么?(上)
28 | 软件工程师的核心竞争力是什么?(下)
29 | 自动化测试:如何把Bug杀死在摇篮里?
30 | 用好源代码管理工具,让你的协作更高效
“一问一答”第3期 | 18个软件开发常见问题解决策略
软件测试篇 (4讲)
31 | 软件测试要为产品质量负责吗?
32 | 软件测试:什么样的公司需要专职测试?
33 | 测试工具:为什么不应该通过QQ/微信/邮件报Bug?
34 | 账号密码泄漏成灾,应该怎样预防?
运行维护篇 (6讲)
35 | 版本发布:软件上线只是新的开始
36 | DevOps工程师到底要做什么事情?
37 | 遇到线上故障,你和高手的差距在哪里?
38 | 日志管理:如何借助工具快速发现和定位产品问题 ?
39 | 项目总结:做好项目复盘,把经验变成能力
“一问一答”第4期 | 14个软件开发常见问题解决策略
经典案例解析篇 (7讲)
40 | 最佳实践:小团队如何应用软件工程?
41 | 为什么程序员的业余项目大多都死了?
42 | 反面案例:盘点那些失败的软件项目
43 | 以VS Code为例,看大型开源项目是如何应用软件工程的?
44 | 微软、谷歌、阿里巴巴等大厂是怎样应用软件工程的?
45 | 从软件工程的角度看微服务、云计算、人工智能这些新技术
“一问一答”第5期(内含彩蛋) | 22个软件开发常见问题解决策略
结束语 (1讲)
结束语 | 万事皆项目,软件工程无处不在
软件工程之美
登录|注册

36 | DevOps工程师到底要做什么事情?

宝玉 2019-05-23
你好,我是宝玉。这些年,有关 DevOps 的概念很火,大家都在讨论 DevOps,有人说 DevOps 就是自动化运维,有人说 DevOps 是流程和管理,还有人说 DevOps 是一种文化。以前的运维工程师也纷纷变成了 DevOps 工程师。
今天,我将带你一起了解一下,究竟什么是 DevOps?DevOps 到底要做什么事情?

传统的运维模式以及面临的挑战

在传统的瀑布模型开发中,软件生命周期中的运行维护这部分工作通常是交给运维工程师来完成的。
当开发人员完成编码,测试人员测试验收通过后,到了要发布的时候,就会将程序交给运维人员部署发布到生产环境。
除了程序的部署更新,传统运维工程师最重要的职责就是保障线上服务的稳定运行。对服务器 24 小时监控,有意外情况发生时需要及时处理和解决。
除此之外,还有日常的更新维护,比如说安装升级操作系统、安装更新应用软件,更新数据库、配置文件等。
早些年这种运维模式运行的很好,但随着这些年互联网发展,有两个主要的因素对传统的运维模式产生了很大挑战。
第一,服务器规模快速增长和虚拟化技术的高速发展。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《软件工程之美》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(10)

  • yellowcloud
    前面听老师介绍了很多自动化测试的方法、工具以及现在的devOps,听到这些可以快速提高生产效率的方法,使我有点跃跃欲试了。宝玉老师能不能介绍一整套可以简易部署使用的devOps的工具,方便小公司快速部署、实现,在实践中感受devOps的魅力。

    作者回复: 如果你要部署持续集成环境,可以先试试Jenkins或者Gitlab CI。如果你要部署日志和监控系统,可以试试ELK,也就是Elasticsearch、Logstash、Kibana三者的结合。网上可以找到很多安装使用教程。

    2019-05-23
    5
  • 林云
    如果标题改成“Devops这样实施就对了”也许会好些。这样至少不会混淆所有Devops实施的工作只需要一个角色就能完成。(招聘岗位title写着Devops工程师?一定是一个不懂Devops的HR所为)

    就像文中提到的“道 法 术”概念,首先有定义,然后根据定义建立体系,而不是使用有争议的词汇,让读者对论述产生误解。

    就像软件工程通过一套方法使得软件交付可预期,Devops如何实施也是一套严谨的知识体系,有不同的分工和角色。只有用严谨的方法才能得到可预期的结果。

    作者回复: 👍你这个标题《Devops这样实施就对了》的建议不错

    2019-05-25
    4
  • 林云
    需要指出“Devops工程师”是一个概念错误。事实上Devops并不是一个职位,如果按照文中所说:“Devops工程师帮助团队搭建CI/CD工具”则应该叫做持续交付工具架构师,而这与文首所说:“运维工程师纷纷改名Devops工程师”在工程师的技术栈领域互相矛盾,难道所有持续交付系统都是由运维工程师搭建的吗?

    而《Devops实施手册》提出了DevOps能力中心的核心角色其中包括:协调资源的项目经理;推动工具方案实施与评价结果的执行经理;交付DevOps平台的基础架构经理;DevOps教练和技术布道者。由这些角色配合才能完成传统企业Devops的全面转型。
    即使是初创企业推行Devops也不是只有一个工具链工程师可以完成的。

    参考连接:https://www.jianshu.com/p/7cf36451ee83?from=groupmessage

    作者回复: 谢谢指正

    “以前的运维工程师也纷纷变成了 DevOps 工程师。”是为了说明DevOps火爆,比如你可以到招聘网站去搜索一下职位。这其实也类似于“以前的软件测试也纷纷变成了QA”。

    我也知道这个定义是有争议的,所以文中已经说明:“对于 DevOps 工程师的定义其实是有争议的”,并且“在这里我们没必要陷入这种争论,而是从 DevOps 实践的角度,来看看 DevOps 工程师,要做什么事情,可以帮助团队来实践 DevOps 的工作方式。”

    对于DevOps这种观点,不像瀑布模型这种定义已经很明确了,大家都可能有不同解读很正常,但核心本质其实是类似的,就像楼上 @纯洁的憎恶 同学总结的那样:DevOps的道:开发与运维紧密协作的工作方式,以更快更可靠的构建、测试、发布软件。

    所以要实施DevOps,不是说需要有一个实施手册,需要有一个教练,要有一个Title才可以,恰恰相反,如果你是遵循DevOps的道,开发与运维紧密协作,高效的构建、测试、发布软件,那就是DevOps的开发方式。

    这其实也是专栏最开始就提到的:我们学软件工程,还是要掌握好其中的“道”,再通过“道”去学“术”和用“器”,而不是去追求“术”和“器”而反而忽视了“道”。

    2019-05-24
    4
  • maomaostyle
    我个人觉得devops是个很大的概念,理论上开看更侧重的是一种协作方式,也就是想法先行,单从目前的IT业态发展趋势来看,devops下面包含了很多学科,与基础设施相关的云计算,容器化,自动化运维监控等,与软件工程相关的敏捷开发,CI/CD,微服务等,以及与组织架构相关的诸如SRE这种角色的导入还有OKR考核方式等

    作者回复: DevOps目前解读比较多,我觉得如果什么都往里面装,那么DevOps就会变成“现代软件工程”了:)

    2019-06-11
    2
  • 纯洁的憎恶
    传统运维工作:程序部署到生产环境、保障服务器稳定运行、日常更新维护(操作系统、应用软件、数据库、配置文件)。

    变化:服务器规模与日俱增,因此带来的自动化运维计划的普遍应用;生产环境程序部署的频率更高,高频部署与系统稳定的冲突助长引发运与开发的职能壁垒。

    运维人员的新要求:应用大量自动化运维技术,具备搭建自动化运维工具或功能的能力,更多的了解、参与、引导开发环节工作。

    DevOps的道:开发与运维紧密协作的工作方式,以更快更可靠的构建、测试、发布软件。

    DevOps的术:通过软件技术打通开发与运维环节的信息壁垒,提高软件工程全过程自动化水平,固化、引导跨职能协作文化,提升整体效能。

    本公司有多个外包团队,每个规模都比较小,所以往往几个人同时负责产品、测试、运维的工作,没有明确的分工反而挺高效。规模较大的公司由于管理的项目更负责、人员也更多样,所以岗位上区分的比较明确,也有利于专注本职工作。但这也在一定程度上助长了岗位壁垒,需要强调跨职能协作的工作方式与手段。“分分合合”的过程中,效率是不变的追求。

    作者回复: 👍👍非常好的总结和补充!

    2019-05-23
    2
  • Charles
    曾经部门里有一个运维工程师觉得工作不饱和,成就感不强,一个是因为业务一直上不去规模,还有一个是他自己也有一点焦虑,觉得基础的运维越来越被云计算厂商给做完了,所以他就想到自己开发一点日志监控和预警、甚至应用程序的性能追踪和异常发现,今天看到老师的文章,发现这种发现问题解决问题方式在实践devops的方式好像也挺好的,并且更容易落地

    作者回复: 👍你们运维方向应该是没问题的,能站在技术的角度去思考如何更好的发现系统潜在问题。

    运维如果往开发这边跨一点,能做的事情还挺多的,可以帮助搭建持续集成环境、搭建自动化监控、实现自动化部署等等。

    2019-05-23
    2
  • kirogiyi
    对于Devops我只是听说过,并没有具体的去了解过它的使用和应用场景。根据宝玉老师的讲述,Devops 的基础是自动化,那么自动化之外好像更多的是一种概念,可以因环境而产生各种不同的方式和方法,并没有比较明确的定论。感觉就像敏捷开发一样,满足敏捷宣言思想的操作都可以是敏捷开发,最终适合自己或团队的才是最好的。

    作者回复: 自动化确实没有明确的定论,重要的是得要有应用自动化的意识,让自动化变成你项目开发流程的一部分,从而提升效率、改进质量。

    应用自动化本质就是应用工具和基于工具二次开发,常用的自动化工具比如说自动测试框架、持续集成、日志监控报警。这些都是基础工具,还需要针对自己项目的环境,基于工具提供的API,去定制化的写配置脚本,让它可以适合你的项目。

    最重要的还是要把这些工具整合到你的开发流程中,比如说:

    当你提交代码的时候,持续集成能帮你自动运行自动化测试脚本,可以直观看到测试结果,根据结果再决定是否合并或者继续修改;

    当你合并代码后,持续集成能帮你自动化部署到测试环境,并且构建生成生产环境的部署包,甚至帮你自动部署生产环境。

    当你要部署的时候,通过自动化的脚本直接部署到生产环境,而不需要手工去干预太多,避免人为因素的失误。

    当你部署上线后,通过日志监控报警系统能实时看到部署后的数据变化,及时发现问题。

    这样的流程其实是比较通用的、大部分项目都是适用的,只是前期需要投入一定的时间精力去研究和搭建,但是搭建好了这样的整套自动化环境和建设好了相应的开发流程,相应的从效率和质量上的回报也是很大的。

    2019-05-23
    2
  • 一步
    搭建自动化测试,自动化部署,自动化监控系统,都自动化了,开发都做了,是不是就不需要运维和测试了.......

    作者回复: 自动化只是把重复的体力活做了。

    自动化测试的话,还是需要测试人员写测试用例才能有更好的测试效果;

    自动化部署和监控,也离不开专业运维人员的设计和搭建。

    但是可以预见的是,以后低端的手工测试和运维岗位会被挤压的很厉害。如果你看大厂的招聘岗位,这些低端手工岗位都极少或者根本就没有。

    2019-05-23
    2
  • 小老鼠
    1、有什么软件企业不适用于DevOps 吗?比如嵌入式软件产品?2、有没有一套比较成熟拿来可用的DevOps 产品,比如Tomcat+mysql+git的?3、现在有DevTestOps概念,DevOps 与DevTestOps区别在哪儿?

    作者回复: 1. 我觉得像对于嵌入式软件产品,一样要提倡紧密协作、自动化、可度量。所以DevOps对于软件企业,都是值得提倡的。
    2. 如果从自动化和可度量的角度,是有不少软件产品的,比如像《26 | 持续交付:如何做到随时发布新版本到生产环境?》、《38 | 日志管理:如何借助工具快速发现和定位产品问题 ?》里面介绍的一些工具。
    3. DevOps通常指开发(Dev)和运维(Ops),DevTestOps就是把测试(Test)也加进来了。其实本质都是指构建跨工种的协作文化。

    2019-10-07
    1
  • 风翱
    确实说出了目前我们团队中的痛点,不同岗位人员之间的不理解。 不同岗位工作内容的渗透,跨职能协作,是可以融入我们的团队中的方法。当然这个不是能一步促成的事,需要一步一步走。

    作者回复: 👍发现问题是最关键的一步,解决问题的方案反倒是有很多选择。

    2019-06-27
    1
收起评论
10
返回
顶部