IT公司如何才能在2019年取得成功？ 会议和聚会上的讲师说了很多普通人并不总是能理解的大声话语。 部署时间、微服务、放弃单体、DevOps 转型等等的斗争。 如果我们放弃华丽的语言，直接用俄语说话，那么一切都可以归结为一个简单的论点：制造高质量的产品，并让团队感到舒适。
后者已变得至关重要。 商业界终于得出这样的结论：舒适的开发流程可以提高生产力，如果一切都调试好并且像时钟一样工作，那么在关键情况下也可以提供一些回旋余地。 曾几何时，为了这种策略，某个聪明的人想出了备份，但行业正在发展，我们找到了 DevOps 工程师 - 他们将开发和外部基础设施之间的交互过程转变为充分且可靠的东西。与萨满教无关。
整个“模块化”故事很精彩，但是……碰巧的是，一些管理员突然被称为 DevOps，而 DevOps 工程师本身开始被要求至少具备心灵感应和千里眼的技能。
在我们讨论提供基础设施的现代问题之前，让我们先定义一下这个术语的含义。 目前，情况的发展使我们达到了这个概念的二元性：基础设施可以是有条件的外部的，也可以是有条件的内部的。
通过外部基础设施，我们指的是确保团队正在开发的服务或产品功能的一切。 这些是应用程序或网站服务器、托管和其他确保产品功能的服务。
内部基础设施包括开发团队本身和其他员工（通常有很多）使用的服务和设备。 这些是代码存储系统的内部服务器、本地部署的任务管理器以及企业内部网中存在的一切、一切、一切。
系统管理员在公司做什么？ 除了管理企业内部网的工作之外，它还常常承担着经济问题的负担，以确保办公设备的可操作性。 管理员是同一个人，他会迅速从后面的房间拖出一个新的系统单元或一台准备使用的备用笔记本电脑，拿出一个新的键盘，然后四肢着地爬过办公室，拉伸以太网电缆。 管理员不仅是内部和外部服务器的本地所有者和统治者，而且还是业务主管。 是的，有些管理员只能在系统平面工作，没有硬件。 他们应该被分为“基础设施系统管理员”的单独子类。 有些专门维修办公设备；幸运的是，如果公司有一百多人，工作就永远不会结束。 但他们都不是 DevOps。
DevOps 是谁？ DevOps 是谈论软件开发与外部基础设施交互的人。 更准确地说，现代 DevOps 参与开发和部署过程的程度比简单地将更新上传到 ftp 的管理员参与的程度要深得多。 现在，DevOps 工程师的关键任务之一是确保开发团队和产品基础架构之间有一个舒适且有效的结构化交互流程。 正是这些人负责部署回滚和部署系统；正是这些人减轻了开发人员的一些负担，并尽可能专注于他们极其重要的任务。 与此同时，devops 永远不会从后面的房间运行新的电缆或发放新的笔记本电脑 (c) KO
捕获量是多少？
对于“谁是 DevOps？”这个问题该领域的一半工作人员开始回答类似“嗯，简而言之，这是管理员......”以及文本中的进一步内容。 是的，曾几何时，当 DevOps 工程师这个职业刚刚从服务维护方面最有才华的管理员中脱颖而出时，他们之间的差异并不是每个人都显而易见的。 但现在，当团队中DevOps和Admin的职能已经变得截然不同时，将它们相互混淆，甚至等同起来是不可接受的。
但这对商业意味着什么？
招聘，一切都在于此。
你开设了一个“系统管理员”的职位空缺，里面列出的需求有“与开发和客户的交互”、“CI/CD交付系统”、“公司服务器和设备的维护”、“内部系统的管理”等等在; 你明白雇主在胡说八道。 问题在于，空缺头衔应该是“DevOps 工程师”，而不是“系统管理员”，如果更改此头衔，那么一切都会水到渠成。
然而，当人们读到这样的职位空缺时，会得到什么印象呢？ 该公司正在寻找一名多机操作员，他将部署版本控制和监控系统，并用牙齿挤压扭转器......
但为了不增加劳动力市场的毒瘾程度，用正确的名字称呼空缺职位并清楚地了解DevOps工程师和系统管理员是两个不同的实体就足够了。 但一些雇主无法抑制地向候选人提出尽可能广泛的要求，导致“经典”系统管理员不再了解他们周围发生的事情。 什么，这个职业正在变异，他们已经落后于时代了？
不不，再一次不。 负责管理公司内部服务器或担任 L2/L3 支持职位并帮助其他员工的基础设施管理员尚未消失，也不会消失。
这些专家能成为 DevOps 工程师吗？ 他们当然可以。 事实上，这是一个需要系统管理技能的相关环境，但除此之外，还需要与监控、交付系统合作，并且通常还需要与开发和测试团队密切互动。
另一个 DevOps 问题
事实上，一切并不仅限于招聘以及管理员和开发人员之间不断混淆。 在某些时候，企业面临着交付更新以及开发团队与最终基础架构交互的问题。
也许是当一位眼睛闪闪发光的叔叔站在某个会议的舞台上说：“我们这样做，称之为DevOps。 这些人会解决你所有的问题”——并开始讲述实施 DevOps 实践后公司的生活是多么美好。
然而，仅仅聘请 DevOps 工程师来让一切正常运转还不够。 公司必须进行一次完整的DevOps转型，就是说我们DevOps的作用和能力在产品开发和测试团队这边也必须清楚地认识到。 我们有一个关于这个主题的“精彩”故事，充分说明了一些地方正在发生的所有暴行。
情况。 DevOps 需要部署一个版本回滚系统，而无需真正深入研究它是如何工作的。 假设在用户系统中，名字、姓氏和密码有单独的字段。 新版本的产品问世了，但对于开发者来说，“回滚”只是一根万能的魔杖，他们甚至不知道它是如何工作的。 因此，例如，在下一个补丁中，开发人员组合了名字和姓氏字段，将其投入生产，但由于某种原因该版本很慢。 发生了什么？ 管理层找到 devops 并说“拉动开关！”，即要求他回滚到之前的版本。 DevOps 做什么？ 它会回滚到之前的版本，但由于开发人员不想弄清楚这个回滚是如何完成的，所以没有人告诉 DevOps 团队数据库也需要回滚。 结果，一切都崩溃了，用户看到的不是缓慢的网站，而是“500”错误，因为旧版本无法使用新数据库的字段。 Devops 并不知道这一点。 开发商沉默了。 管理层开始失去勇气和金钱，并记住了备份，并提出回滚它们，以便“至少有些东西会起作用”。 结果，用户在一段时间内丢失了所有数据。
当然，最疯狂的是 devops，他们“没有做出适当的回滚系统”，而且没有人关心这个故事中的驼鹿是开发人员。
结论很简单：如果没有正常的 DevOps 方法，它就没有多大用处。
要记住的主要事情是：DevOps 工程师不是魔术师，如果没有高质量的沟通和与开发的双向交互，他将无法应对他的任务。 开发人员不能独自处理他们的“问题”，也不能被命令“不要干涉开发人员，他们的工作是编码”，然后希望在关键时刻一切都会按预期进行。 事情不是这样的。
本质上，DevOps 是一种介于管理和技术之间的能力。 此外，在这杯鸡尾酒中，技术含量应该多于管理含量，这一点也远非显而易见。 如果您确实想要构建更快、更高效的开发流程，您必须信任您的 DevOps 团队。 他知道正确的工具，他实施过类似的项目，他知道如何去做。 帮助他，听听他的建议，不要试图把他隔离成某种自治单位。 如果管理员可以自己工作，那么 DevOps 在这种情况下就没用了；如果你自己不想接受这种帮助，他们将无法帮助你变得更好。
最后一件事：停止冒犯基础设施管理员。 他们有自己的、极其重要的工作前沿。 是的，管理员可以成为 DevOps 工程师，但这应该是在该人本人的要求下发生的，而不是在压力下发生的。 系统管理员想要继续担任系统管理员这一事实并没有什么问题——这是他独立的职业，也是他的权利。 如果你想进行职业转型，那么你千万不要忘记，你不仅要培养技术技能，还要培养管理技能。 最有可能的是，你作为领导者将所有这些人聚集在一起并教他们用同一种语言进行交流。
来源： habr.com