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

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

DevOps工程师的必备技能清单(2)

作者:

关键词:

摘要：

自动化 + 万物即代码

大家应该尽快摆脱手动操作的困扰。时至今日，几乎一切日常工作都对应着自动化工具。如果找不到现成的工具，您也可以使用 Python 及 bash 自行编写。例如，如果需要创建虚拟机镜像，请使用 Packer。如果需要配置 10 台以上的主机，请使用 Ansible。如果您在 Google Cloud Platform 中创建 Kubernertes 集群，或者需要在 Amazon 上使用 CDN，请使用 Terraform 以简化操作流程。总而言之，从通过网络加载新的裸机服务器到在现有集群中部署新容器，一切都应以自动化方式进行。另外，您编写的代码应该具有可复制性与幂等性，提交内容必须经过跟踪程序的审核，且严格遵循以上要求。

云与混合架构

目前，我们发现大多数企业都不会只使用一家云服务供应商（为了避免供应商锁定问题）。没错，一切不该简单粗暴地交给云方案处理，我们可以将服务中的不同部分运行在 AWS、Heroku 以及其他 IaaS、PaaS 与 SaaS 之上。请努力找到最理想的解决方案，并保证能够在特定时段内完成不同平台之间的服务迁移。另外，也别忘了之前提到的自动化原则，自动化程度越高、迁移难度就越低。

可扩展性与高可用性要求

最重要的是意识到企业能够在特定时段内承受怎样的停机与数据丢失影响。明确这一点之后，大家会发现长达 24 个小时的资源停机假设将毫无意义。另外，资源哪怕只宕机一个小时，造成的损失就可能高于一整年的完整热备份服务使用成本。借助云服务与容器化技术，扩大系统规模变得愈发轻松。但是，基础设施与服务本身也需要为这种灵活扩展能力做好准备（这里再次向本地对象存储开炮，这简直就是麻烦的终极根源）。

监控与警报

为了及时做出回顾、预测与响应，我们当然有必要收集系统、应用程序及业务中的一切可用指标。这些指标就像团队的眼睛，而且无法通过单一监控解决方案全面实现。每种云服务或平台都提供自己的一组可用指标与警报，但大家还需要结合需求使用 Librato 或 Datadog 等外部系统，或者在 Prometheus 上构建自定义监控服务。总之，一切选择都应该以合理的预算、时间及任务需求为基础。

安全性

安全保障确实不是 DevOps 工程师的核心职责。但是，大家必须掌握相关安全基础知识。端点上部署 SSL，策略中没有 * 号，不存在公开或可写入的存储桶、分区需要进行加密，注意部署封闭的防火墙、安全组以及多因素验证等等。另外，DevOps 还应该与安全部门合作，在实现流程自动化的同时快速在服务中应用新的安全策略。

DevOps 工程师的作用

不需要 DevOps 工程师，太阳似乎也会照常升起……

如果整个业务体系已经配置完成并能够正常工作，还需要 DevOps 专家干嘛？说得没错，不少开发人员已经建立起一套完善的环境，包括良好运行的数据库甚至是自动规模伸缩组。当然，更实际的情况，应该是他们在 Heroku 上启动了相关应用、添加了必要插件，警报和监控指标已经轻松实现，一切看起来都无缘美好。

在这种情况下，仍有以下问题需要解决。

所有操作通常只能手动完成，如果您的云服务供应商出了问题，您将无法复制架构或者对架构进行部分还原。

由于缺乏对资源消耗的有效控制，这种方案的运营成本很高。在配置完成后，很多服务可能根本没有发挥作用，但您仍然需要为此付费。一般来讲，快速发布是开发流程的重中之重，但同时又缺少必要的优惠选项及替代方案等成本调整空间。另外，这类方案大多没有充分发挥预留实例的成本优势。

部署流程不够完善。由于缺少统一的测试方法，集成测试往往只是空谈。大部分运行测试只能由开发人员在本地执行。

某些奇怪的错误只出现在生产环境中，但却无法在本地重现。这会影响客户对于 IT 部门的信任，最终 IT 部门与项目负责人将成为不共戴天的死对头。

性能问题时常出现，但原因总不明确。单点故障无处不在，解决与修复需要耗费大量时间，甚至会进一步拖慢已经非常缓慢的开发进程。

需要将您的服务迁移至另一平台，并为快速增长的业务做好架构层面的准备。

监控警报来得太晚，来不及采取行动。开发团队很可能是最后一帮意识到出了问题的人。在最极端的情况下，甚至用户和客户那边已经怒火中烧，开发团队却仍被蒙在鼓里。

这份清单当然不够完整，我们还可以添加更多问题，其中一些可以通过及时沟通来解决，也有一些需要配合交付与开发流程层面的优化。但要完成这些优化，就得探讨纯粹的技术技能或者与特定平台相关的知识，因此本文暂不讨论。

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