DevOps工程师的必备技能清单 - 农业工程技术杂志社投稿_期刊论文发表|版面费|电话|编辑部|论文发表

一、来稿必须是作者独立取得的原创性学术研究成果，来稿的文字复制比（相似度或重复率）必须低于用稿标准，引用部分文字的要在参考文献中注明；署名和作者单位无误，未曾以任何形式用任何文种在国内外公开发表过；未一稿多投。二、来稿除文中特别加以标注和致谢之外，不侵犯任何版权或损害第三方的任何其他权利。如果20天后未收到本刊的录用通知，可自行处理(双方另有约定的除外)。三、来稿经审阅通过，编辑部会将修改意见反馈给您，您应在收到通知7天内提交修改稿。作者享有引用和复制该文的权利及著作权法的其它权利。四、一般来说，4500字（电脑WORD统计，图表另计）以下的文章，不能说清问题，很难保证学术质量，本刊恕不受理。五、论文格式及要素：标题、作者、工作单位全称(院系处室)、摘要、关键词、正文、注释、参考文献(遵从国家标准：GB\T7714-2005，点击查看参考文献格式示例)、作者简介(100字内)、联系方式(通信地址、邮编、电话、电子信箱)。六、处理流程：（1）通过电子邮件将稿件发到我刊唯一投稿信箱（2）我刊初审周期为2－3个工作日，请在投稿3天后查看您的邮箱，收阅我们的审稿回复或用稿通知；若30天内没有收到我们的回复，稿件可自行处理。（3）按用稿通知上的要求办理相关手续后，稿件将进入出版程序。（4）杂志出刊后，我们会按照您提供的地址免费奉寄样刊。七、凡向文教资料杂志社投稿者均被视为接受如下声明：（1）稿件必须是作者本人独立完成的，属原创作品（包括翻译），杜绝抄袭行为，严禁学术腐败现象，严格学术不端检测，如发现系抄袭作品并由此引起的一切责任均由作者本人承担，本刊不承担任何民事连带责任。（2）本刊发表的所有文章，除另有说明外，只代表作者本人的观点，不代表本刊观点。由此引发的任何纠纷和争议本刊不受任何牵连。（3）本刊拥有自主编辑权，但仅限于不违背作者原意的技术性调整。如必须进行重大改动的，编辑部有义务告知作者，或由作者授权编辑修改，或提出意见由作者自己修改。（4）作品在《文教资料》发表后，作者同意其电子版同时发布在文教资料杂志社官方网上。（5）作者同意将其拥有的对其论文的汇编权、翻译权、印刷版和电子版的复制权、网络传播权、发行权等权利在世界范围内无限期转让给《文教资料》杂志社。本刊在与国内外文献数据库或检索系统进行交流合作时，不再征询作者意见，并且不再支付稿酬。九、特别欢迎用电子文档投稿，或邮寄编辑部,勿邮寄私人，以免延误稿件处理时间。

DevOps工程师的必备技能清单

作者:

关键词:

摘要：

作者 | Andrew S.

策划 | 田晓旭

在公司成立之前，我们团队就已经开始应用 DevOps 实践，而我个人，早在十年前，在另一家公司担任系统管理员的时候，就第一次接触到了这种新鲜的思维方式。那个时候，还没有 DevOps 这种标准说法，但是当时实践的人也自己摸索出了一些相关的概念与原则。

持续集成；

自动交付；

每位团队成员都对产品负有责任；

与客户直接沟通；

收集并分析业务 / 应用程序指标；

说明文档等；

后来证明以上这一切都是对敏捷倡议中各项实践的逻辑扩展，而催生出这些方法的温床，则是开发者不再单纯为本地主机编写代码这一基本前提。

Atlassian 提出的 DevOps 原理

由 Atlassian 提出的 DevOps 模式直到今天仍然非常重要。从本质上讲，其代表着产品开发与交付的现代化周期，同时涵盖产品启动之后的运作流程。

前 DevOps 时代：管理员与开发者之间的鸿沟

长久以来，产品的运营与开发工作彼此割裂。这条鸿沟的一端是勤劳朴实的开发人员，另一端则是开发者眼中那些如同行尸走肉般的系统管理员。系统管理员不参与开发，也不会与开发团队沟通，他们通常只是直接拿到代码包，然后尝试在某个位置加以运行。每一次运行尝试都痛苦万分，管理员们需要花几天时间慢慢查看日志、寻找种种难以理解的错误、分析数据库查询、陷入无穷无尽的 strace 过程等。而很多时候的事实都证明，只需要定义一项新的环境变量或者添加一个新参数，问题就能迎刃而解。但遗憾的是，开发者从来不会、也没有机会把情况告知管理员，后者唯一了解的就是产品的名称及其用什么语言编写而成……

十年前的“DevOps”工作

十年之前，我刚开始在团队中担任管理员，当时的公司思维比较灵活，我不像《IT 狂人》的剧情那样被安排在地下室某个阴暗的小房间里，而是在开发者当中拥有了自己的办公桌。从那一刻开始，我也踏上了自己的 DevOps 工程师之旅。

在公司的工作中，我很快意识到，虽然知识和技能都很重要，但从沟通及运营角度审视并影响产品的能力更值得关注。我有权提出异议、表达自己的担忧，并在距离最终交付还有很久的时候就及时向开发者传达观点或提醒他们调整编写方法。这才是真正的管理员，他们不该被“囚禁”在地下室里！

事实很快证明，将产品的设计、开发与运营等元素进行综合审视，确实能够带来巨大的收益。只有每一个人都对产品负责，并清楚意识到产品将在怎样的生产环境中运行时，开发流程将真正与生产流程融合起来。这一切如今人们习以为常的思路，在当时不啻为一种文化冲击——开发者与管理员真正携起手来，天下再无难事！而这一切，都是被沟通鸿沟所严重割裂的传统流程所无法实现的。

但如果 DevOps 只是一种敏捷开发流程，而且在其中引入了开发阶段的概念，那么 DevOps 工程师又是干什么的？DevOps 世界中的核心职责究竟是什么？这就带来了另一个重要问题：DevOps 团队的理想领袖应该是谁？

团队负责人的角色可以由中层专业人士担任，而且对职位或背景没有特别明确的要求（可以是开发人员、管理员甚至是质量保证人员）。DevOps 之所以存在，主要目的就是填补产品在持续集成、交付以及运行周期中的种种空白。

从个人的主观角度出发，我认为 DevOps 领导者最好具有管理员背景（而非选择所谓的「技术骨干」）。以此为基础，他 / 她能够将与数据库升级、配置管理或者一切其他令开发者分心或烦恼的底层基础设施相关因素剥离出来。这里，我还要提出另一项管理员有更适合担任 DevOps 领导工作的观点：随着产品的发展与成熟，DevOps 团队也将随之扩大，因此需要投入的时间及精力会同步增长。如果指定开发人员领导您的 DevOps 团队，其将很难全神贯注继续处理开发工作。最后一个理由：管理员更易于上手 DevOps 工作，所以起步速度会更快一些。

DevOps 工程师该懂些什么？

DevOps 工程师们应该懂点什么，又该会做些什么？本文整理了一份 DevOps 工程师的技能清单，当然列举的可能不完整，只涵盖工程师们应当具备的部分核心技能。

敏捷开发原则

这也是现代开发世界中最重要的技能之一（特别是在远程协作开发场景之下）。其中不仅包括区分 Kanban 与 Scrum 间的差异，同时也要求我们能够与团队顺畅沟通、了解客户价值、跟踪时间进度，以及整理出易于理解的工作日志、独立报告与清晰说明文档的能力。

文章来源：《农业工程技术》网址: http://www.gcjszzs.cn/zonghexinwen/2020/1010/1161.html