软件工程之美
宝玉
Groupon 资深工程师,微软最有价值专家
44272 人已学习
新⼈⾸单¥59
登录后,你可以任选4讲全文学习
课程目录
已完结/共 55 讲
软件工程之美
15
15
1.0x
00:00/00:00
登录|注册

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

构建协作文化
信息透明可测量
自动化
形成DevOps的文化
构建基于云计算和虚拟化技术的基础设施
建立基于日志的监控报警的系统,以及故障响应的流程
建立基于持续集成和持续交付工作流程
DevOps的主要原则
DevOps工程师要做什么事情

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

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

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

在传统的瀑布模型开发中,软件生命周期中的运行维护这部分工作通常是交给运维工程师来完成的。
当开发人员完成编码,测试人员测试验收通过后,到了要发布的时候,就会将程序交给运维人员部署发布到生产环境。
除了程序的部署更新,传统运维工程师最重要的职责就是保障线上服务的稳定运行。对服务器 24 小时监控,有意外情况发生时需要及时处理和解决。
除此之外,还有日常的更新维护,比如说安装升级操作系统、安装更新应用软件,更新数据库、配置文件等。
早些年这种运维模式运行的很好,但随着这些年互联网发展,有两个主要的因素对传统的运维模式产生了很大挑战。
第一,服务器规模快速增长和虚拟化技术的高速发展。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

DevOps工程师的角色在软件开发和运维领域中变得越来越重要。DevOps不仅意味着开发和运维之间更紧密的协作,更重要的是通过自动化、信息透明和跨职能协作的文化,实现更快、更可靠的软件构建、测试和发布。DevOps工程师的主要任务包括建立持续集成和持续交付工作流程、构建基于日志的监控报警系统和故障响应流程、搭建基于云计算和虚拟化技术的基础设施,以及促进形成DevOps的文化。通过遵守DevOps原则,团队可以逐步实现更紫更可靠的工作方式转变。 DevOps的核心价值在于跨职能之间紧密协作,更快更可靠地构建、测试和发布软件,这种工作方式的建立需要团队逐步改变,但并不需要改变开发模式或者靠管理层推动,而是通过理解核心价值,一步步做出改变。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《软件工程之美》
新⼈⾸单¥59
立即购买
登录 后留言

全部留言(12)

  • 最新
  • 精选
  • 林云
    需要指出“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
    13
  • yellowcloud
    前面听老师介绍了很多自动化测试的方法、工具以及现在的devOps,听到这些可以快速提高生产效率的方法,使我有点跃跃欲试了。宝玉老师能不能介绍一整套可以简易部署使用的devOps的工具,方便小公司快速部署、实现,在实践中感受devOps的魅力。

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

    2019-05-23
    6
  • 林云
    如果标题改成“Devops这样实施就对了”也许会好些。这样至少不会混淆所有Devops实施的工作只需要一个角色就能完成。(招聘岗位title写着Devops工程师?一定是一个不懂Devops的HR所为) 就像文中提到的“道 法 术”概念,首先有定义,然后根据定义建立体系,而不是使用有争议的词汇,让读者对论述产生误解。 就像软件工程通过一套方法使得软件交付可预期,Devops如何实施也是一套严谨的知识体系,有不同的分工和角色。只有用严谨的方法才能得到可预期的结果。

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

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

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

    2019-06-11
    3
  • 纯洁的憎恶
    传统运维工作:程序部署到生产环境、保障服务器稳定运行、日常更新维护(操作系统、应用软件、数据库、配置文件)。 变化:服务器规模与日俱增,因此带来的自动化运维计划的普遍应用;生产环境程序部署的频率更高,高频部署与系统稳定的冲突助长引发运与开发的职能壁垒。 运维人员的新要求:应用大量自动化运维技术,具备搭建自动化运维工具或功能的能力,更多的了解、参与、引导开发环节工作。 DevOps的道:开发与运维紧密协作的工作方式,以更快更可靠的构建、测试、发布软件。 DevOps的术:通过软件技术打通开发与运维环节的信息壁垒,提高软件工程全过程自动化水平,固化、引导跨职能协作文化,提升整体效能。 本公司有多个外包团队,每个规模都比较小,所以往往几个人同时负责产品、测试、运维的工作,没有明确的分工反而挺高效。规模较大的公司由于管理的项目更负责、人员也更多样,所以岗位上区分的比较明确,也有利于专注本职工作。但这也在一定程度上助长了岗位壁垒,需要强调跨职能协作的工作方式与手段。“分分合合”的过程中,效率是不变的追求。

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

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

    作者回复: 👍你们运维方向应该是没问题的,能站在技术的角度去思考如何更好的发现系统潜在问题。 运维如果往开发这边跨一点,能做的事情还挺多的,可以帮助搭建持续集成环境、搭建自动化监控、实现自动化部署等等。

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

    作者回复: 自动化确实没有明确的定论,重要的是得要有应用自动化的意识,让自动化变成你项目开发流程的一部分,从而提升效率、改进质量。 应用自动化本质就是应用工具和基于工具二次开发,常用的自动化工具比如说自动测试框架、持续集成、日志监控报警。这些都是基础工具,还需要针对自己项目的环境,基于工具提供的API,去定制化的写配置脚本,让它可以适合你的项目。 最重要的还是要把这些工具整合到你的开发流程中,比如说: 当你提交代码的时候,持续集成能帮你自动运行自动化测试脚本,可以直观看到测试结果,根据结果再决定是否合并或者继续修改; 当你合并代码后,持续集成能帮你自动化部署到测试环境,并且构建生成生产环境的部署包,甚至帮你自动部署生产环境。 当你要部署的时候,通过自动化的脚本直接部署到生产环境,而不需要手工去干预太多,避免人为因素的失误。 当你部署上线后,通过日志监控报警系统能实时看到部署后的数据变化,及时发现问题。 这样的流程其实是比较通用的、大部分项目都是适用的,只是前期需要投入一定的时间精力去研究和搭建,但是搭建好了这样的整套自动化环境和建设好了相应的开发流程,相应的从效率和质量上的回报也是很大的。

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

    作者回复: 自动化只是把重复的体力活做了。 自动化测试的话,还是需要测试人员写测试用例才能有更好的测试效果; 自动化部署和监控,也离不开专业运维人员的设计和搭建。 但是可以预见的是,以后低端的手工测试和运维岗位会被挤压的很厉害。如果你看大厂的招聘岗位,这些低端手工岗位都极少或者根本就没有。

    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
收起评论
显示
设置
留言
12
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部