IT公司在2019年的成功需要什么？ konfs和mitaps的讲师向普通人说很多大声的，但并非总是清晰的词。 部署，微服务，单片拒绝，DevOps转换等方面的斗争。 如果您放弃言语上的美，直接用俄语说，这一切都取决于一个简单的论点：制造出优质的产品，并为团队带来舒适感。
后者已变得至关重要。 商业最终得出结论，一个舒适的开发过程可以提高生产率，并且如果所有内容都经过调试并且像发条一样工作，那么它在紧急情况下也有一定的回旋余地。 曾经有一次，为了这个策略，一些聪明的人发明了备份，但是这个行业正在发展，我们来到了DevOps工程师那里，他们将开发和外部基础设施之间的交互过程变成了与萨满教无关的适当东西。
“模数”的整个故事很美，但是...碰巧有些管理员突然被称为DevOps，而DevOps工程师本身开始至少需要心灵感应和千里眼技巧。
在讨论提供基础结构的现代问题之前，让我们先确定一下这个术语的含义。 迄今为止，情况以这样的方式发展，我们已经达到了这个概念的双重性：基础架构可以有条件地是外部的，而有条件地是内部的。
外部基础架构应指确保团队正在开发的服务或产品的可维护性的一切。 这些是应用程序或站点服务器，托管和其他服务，可确保产品的性能。
内部基础结构包括开发团队本身和其他员工使用的服务和设备，其中通常有很多。 这些是代码存储系统的内部服务器，本地部署的任务管理器以及公司内部网中存在的所有内容。
系统管理员在公司中做什么？ 除了管理该公司内部网本身之外，它通常还带来了经济上的麻烦，以确保办公设备的可用性。 管理员是同一个人，他迅速将一个新的系统单元从后室或备用笔记本电脑中拉出，准备工作，发出一个新鲜的键盘，爬到办公室四周，伸出以太网电缆。 管理员不仅是内部和外部服务器的本地所有者和主人，而且还是业务主管。 是的，有些管理员只能在系统平面上工作，而没有硬件。 应该在“基础结构系统管理员”的单独子类中区分它们。 有人专门专门维修办公设备，幸运的是，如果公司有一百多人，工作将永无止境。 但是，任何一方都不是。
谁是DevOps？ Devops是谈论软件开发与外部基础结构的交互的人。 更准确地说，现代开发人员所涉及的开发和部署过程比仅涉及ftp更新泛滥的管理员要深入得多。 现在，DevOps工程师的关键任务之一是确保开发团队与产品基础架构之间的交互过程舒适而高效地构建。 这些人负责回滚和部署系统的部署，这些人负责减轻开发人员的负担，并尽可能专注于其极其重要的任务。 同时，开发人员将永远不会拉长新电缆或从后室分发新笔记本电脑
有什么收获？
问“谁是DevOps？” 一半的员工开始以类似“嗯，简而言之，是……的管理员”之类的方式回应。 是的，曾几何时，在服务方面，DevOps-engineer的职业只是从才华横溢的管理员开始的，因此彼此之间的差异并不明显。 但是现在，当团队中的开发人员和管理员的功能开始出现根本性的差异时，将它们彼此混淆，甚至在它们之间放一个相等的标记，都是不可接受的。
但是，这会转化为业务吗？
招聘，一切都与他有关。
您打开空缺的“系统管理员”，其中列出了以下要求：“与开发人员和客户的交互”，“ CI / CD交付系统”，“为公司的服务器和设备提供服务”，“管理内部系统”等； 您了解雇主正在胡说八道。 要注意的是，空缺标题中的标题应该是“ DevOps-engineer”而不是“ System Administrator”，并且如果更改了该标题，则所有内容都就位了。
但是，阅读这样的空缺会给人留下什么样的印象？ 该公司正在寻找一种多功能工具操作员，该操作员将部署版本控制和监视系统，并用牙齿摇动牙齿...
但是，为了不增加劳动力市场上的药物成瘾程度，只需用空缺的专有名称来称呼这些空缺，并清楚地知道DevOps工程师和系统管理员是两个不同的实体。 一些雇主向候选人提出尽可能广泛的要求的唯一不可抑制的愿望导致了这样一个事实，即“经典”系统管理员不再了解周围发生的事情。 什么，行业发生变化，他们落后于生活？
不，不，不再。 负责指导公司内部服务器，或担任L2 / L3支持人员并帮助其他员工的基础架构管理员，他们什么都没有走，也不会走。
这些专家可以成为DevOps工程师吗？ 当然可以。 实际上，这是他们的姊妹环境，需要系统管理技能，但是此外，还需要与监视，交付系统一起使用，并且通常会与开发和测试团队进行紧密的交互。
另一个DevOps问题
实际上，一切不仅仅限于招聘和管理员与开发人员之间的持续混乱。 在某个时候，企业面临交付更新以及开发团队与最终基础架构之间交互的问题。
也许是那时候，有一个burning着眼睛的叔叔来到会议现场时说：“我们正在这样做，并将其称为DevOps。 这些家伙将解决您的所有问题”，并开始讲述在实施DevOps实践后他在公司的生活状况。
但是，仅聘请DevOps工程师来使一切正常工作是不够的。 公司必须完全经历DevOps转型，也就是说，在产品开发和测试团队方面也应该清楚地了解我们开发人员的角色和能力。 我们在这个主题上有一个“美丽”的故事，充分说明了所有地方的锡。
情况。 需要Devops部署版本回滚系统，而不必特别研究其工作方式。 假设在用户系统内，这些是名字，姓氏和密码下面的单独字段。 该产品已经发布了新版本，但是对于开发人员来说，“回滚”只是可以解决所有问题的魔杖，他们甚至都不知道它是如何工作的。 因此，例如，下一个补丁程序中的开发人员将名字和姓氏字段组合在一起，将其推广到产品中，并且版本由于某种原因而变慢。 这是怎么回事？ 手册出现在开发人员面前，并说“拉动刀开关！”，也就是说，要求他回滚到以前的版本。 devop是做什么的？ 它可以回滚到以前的版本，但是由于开发人员不想了解这种回滚是如何完成的，因此没有人告诉开发人员也有必要回滚基础。 结果，一切对我们来说都是失败的，而不是让站点变慢，用户会看到错误“ 500”，因为旧版本不适用于新数据库的字段。 Devops没有意识到这一点。 发达都沉默了。 管理层开始失去神经和金钱，并撤回了备份，并提出从备份中回滚，以便“至少有事可做”。 结果，用户会在一段时间内丢失所有数据。
当然，发疯的是开发人员，他们“没有建立正确的回滚系统”，而这个故事中的驼鹿是开发人员这一事实并不会打扰任何人。
结论很简单：如果没有像这样的DevOps常规方法，那么就没有太多了。
要记住的主要事情：DevOps工程师不是魔术师，并且如果没有高质量的交流和与开发的双向交互，他将无法应付自己的任务。 Devops不能独自面对“问题”，也不能给予命令“不要交给开发人员，不要为他们的业务编写代码”，然后希望在关键时刻一切都能正常进行。 因此它不起作用。
本质上，DevOps是介于管理和技术之间的能力。 而且，在这一系列技术中，除了管理之外，还远远不够。 如果您真的想构建更快，更高效的开发流程，则必须信任您的开发人员。 他知道正确的工具，他已经实施了类似的项目，他知道如何去做。 帮助他，听取他的建议，不要试图孤立在某个自治单位中。 如果管理员可以自己工作，则devop在这种情况下是没有用的，如果您自己不想接受此帮助，则他们将无法帮助您变得更好。
最后一件事：停止冒犯基础架构管理员。 他们有自己的极其重要的工作领域。 是的，管理员可以成为DevOps工程师，但这应在个人本人的要求下进行，而不是从底层进行。 系统管理员想要保留系统管理员这一事实没有错-这是他的独立职业，也是他的权利。 如果有进行专业变革的愿望，那么我们决不能忘记，不仅有必要建立技术技能，而且还必须建立管理技能。 作为领导者，您很有可能必须将所有这些人召集在一起，并学会用一种语言进行交流。