在过去的几年里，DevOps 已经成为一个非常流行的话题。 许多人梦想加入其中，但实践表明，往往只是因为工资水平。
有些人在简历中列出了 DevOps，尽管他们并不总是知道或理解这个术语的本质。 有人认为，学习了 Ansible、GitLab、Jenkins、Terraform 之类的东西（这个列表可以根据你的口味继续），你会立即成为“devopsist”。 当然，这不是真的。
过去几年，我主要参与各个公司DevOps的实施。 在此之前，他在从系统管理员到 IT 总监等职位上工作了 20 多年。 目前是 Playgendary 的 DevOps 首席工程师。
谁是 DevOps
写一篇文章的想法是在另一个问题之后产生的：“谁是 DevOps？” 对于它是什么或是谁，仍然没有既定的术语。 有些答案已经在这个了 。 首先我会强调其中的要点，然后我会分享我的观察和想法。
DevOps 不是一个可以被雇佣的专家，不是一组公用事业，也不是一个由工程师组成的开发部门。
DevOps 是一种哲学和方法论。
换句话说，它是一组帮助开发人员主动与系统管理员交互的实践。 也就是说，将工作流程相互连接和集成。
随着 DevOps 的出现，专家的结构和角色保持不变（有开发人员，有工程师），但交互规则发生了变化。 部门之间的界限已经模糊。
DevOps 的目标可以用三点来描述：
- 软件必须定期更新。
- 软件必须快速完成。
- 软件的部署应该方便、时间短。
DevOps 没有单一的工具。 配置、交付和研究几个产品并不意味着DevOps已经在公司出现。 工具有很多，它们都在不同的阶段使用，但都有一个共同的目的。
这只是 DevOps 工具的一部分
我面试 DevOps 工程师职位的人已经有两年多了，我开始意识到清楚地理解这个术语的本质是多么重要。 我积累了一些我想分享的具体经验、观察和想法。
根据面试经验，我看到如下图： 将 DevOps 视为职位名称的专家通常与同事存在误解.
有一个引人注目的例子。 一位年轻人来面试，他的简历上写着很多聪明的话。 在他的前三份工作中，他有 5 至 6 个月的工作经验。 我离开了两家初创公司，因为它们“没有起飞”。 但谈到第三家公司，他说那里没有人理解他：开发人员在 Windows 上编写代码，总监强制将这些代码“包装”在常规 Docker 中并构建到 CI/CD 管道中。 那家伙说了很多关于他目前的工作地点和同事的负面言论——我只想回答：“所以你不会卖大象。”
然后我问了他一个问题，这个问题在我的每个候选人的清单中都排在前列。
— DevOps 对您个人来说意味着什么？
- 一般而言或者我如何看待它？
我对他的个人意见很感兴趣。 他知道这个术语的理论和起源，但他强烈不同意它们。 他认为 DevOps 是一个职位名称。 这就是他问题的根源所在。 以及其他持相同观点的专家。
雇主们听过很多“DevOps 的魔力”之后，希望找到一个能够创造这种“魔力”的人。 来自“DevOps 是一份工作”类别的申请人不明白，通过这种方法，他们将无法满足期望。 而且，总的来说，他们在简历中写下了 DevOps，因为这是一种趋势，而且他们为此付出了很多。
DevOps 方法论和理念
该方法可以是理论的和实践的。 在我们的例子中，这是第二个。 正如我上面提到的，DevOps 是一组用于实现既定目标的实践和策略。 在每种情况下，根据公司的业务流程，可能会有很大差异。 这并不会让事情变得更好或更糟。
DevOps 方法只是实现目标的一种手段。
现在谈谈 DevOps 理念是什么。 这可能是最困难的问题。
制定一个简短而简洁的答案相当困难，因为它尚未正式化。 由于 DevOps 哲学的追随者更多地参与实践，因此根本没有时间进行哲学思考。 然而，这是一个非常重要的过程。 而且，它与工程活动直接相关。 甚至还有一个专门的知识领域—— .
我的大学里没有这样的科目，我必须利用90年代能找到的材料自学一切。 该主题对于工程教育来说是可选的，因此缺乏正式的答案。 但那些认真投入 DevOps 的人开始感受到公司所有流程的某种“精神”或“无意识的全面性”。
根据我自己的经验，我试图将这一哲学的一些“假设”形式化。 结果如下：
- DevOps 并不是独立的东西，可以分成单独的知识或活动领域。
- 所有公司员工在规划其活动时都应遵循 DevOps 方法。
- DevOps 影响公司内的所有流程。
- DevOps 的存在是为了减少公司内任何流程的时间成本，以确保其服务的开发和最大程度的客户舒适度。
- DevOps，用现代语言来说，是公司每个员工的主动立场，旨在降低时间成本并提高我们周围IT产品的质量。
我认为我的“假设”是一个单独的讨论主题。 但现在有一些东西可以继续发展。
DevOps 做什么
这里的关键词是沟通。 有很多沟通，发起人应该是同一个 DevOps 工程师。 这是为什么？ 因为这是哲学和方法论，然后才是工程知识。
我不能对西方劳动力市场有 100% 的信心。 但我对俄罗斯的 DevOps 市场了解很多。 除了数百次采访之外，在过去的一年半时间里，我还参与了数百次为俄罗斯大公司和银行提供的“DevOps 实施”服务的技术预售。
在俄罗斯，DevOps 仍然是一个非常年轻的话题，但已经成为热门话题。 据我了解，2019年仅莫斯科一地此类专家的缺口就超过1000人。 Kubernetes 这个词对于雇主来说几乎就像红布对于公牛一样。 即使在没有必要且经济上有利可图的情况下，该工具的追随者也准备使用它。 雇主并不总是了解在什么情况下使用什么更合适，并且通过正确的部署，维护 Kubernetes 集群的成本比使用传统集群方案部署应用程序高 2-3 倍。 在您真正需要的地方使用它。
实施 DevOps 的资金成本很高。 而且只有当它在其他领域带来经济利益时才是合理的，而不是其本身。
事实上，DevOps 工程师是先驱——他们应该是第一个在公司中实施这种方法并构建流程的人。 为了取得成功，专家必须不断与各级员工和同事互动。 正如我通常所说，所有公司员工都应该参与 DevOps 实施过程：从清洁女工到首席执行官。 这是一个先决条件。 如果团队中资历最浅的成员不知道和理解 DevOps 是什么以及为什么要执行某些组织操作，那么成功的实施就行不通。
此外，DevOps 工程师需要不时使用管理资源。 例如，克服“环境阻力”——当团队尚未准备好接受 DevOps 工具和方法时。
开发人员应该只编写代码和测试。 为此，他不需要一台功能强大的笔记本电脑来部署和本地支持整个项目基础设施。 例如，前端开发人员将应用程序的所有元素都保存在他的笔记本电脑上，包括数据库、S3 模拟器（minio）等。 也就是说，他花费了大量的时间来维护这个本地基础设施，并独自努力解决这种解决方案的所有问题。 而不是为前端开发代码。 这些人可能非常抵制任何改变。
但有些团队却相反，乐于引入新的工具和方法，并积极参与这一过程。 尽管即使在这种情况下，DevOps 工程师和团队之间的沟通也没有取消。
当不需要 DevOps 时
在某些情况下，不需要 DevOps。 这是事实——需要理解和接受。
首先，这适用于任何公司（尤其是小型企业），其利润并不直接取决于是否有向客户提供信息服务的IT产品。 这里我们谈论的不是公司的网站，无论是静态的“名片”还是动态的新闻块等。
当您的客户的满意度以及他再次回到您身边的愿望取决于这些与客户交互的信息服务的可用性、其质量和目标时，就需要 DevOps。
一个显着的例子是一家知名银行。 该公司没有传统的客户办公室，文件流转通过邮件或快递进行，许多员工在家工作。 在我看来，该公司不再只是一家银行，而是一家拥有成熟 DevOps 技术的 IT 公司。
在专题聚会和会议的录音中可以找到许多其他示例和讲座。 我亲自拜访了他们中的一些人——这对于那些想朝这个方向发展的人来说是非常有用的经历。 以下是 YouTube 频道的链接，其中包含有关 DevOps 的精彩讲座和材料：
现在看看您的业务并思考一下：您的公司及其利润在多大程度上依赖 IT 产品来实现客户互动？
如果你的公司在一个小商店里卖鱼，唯一的IT产品是两个1C：企业配置（会计和UNF），那么谈论DevOps几乎没有意义。
如果你在一家大型贸易和制造企业工作（例如，你生产猎枪），那么你应该考虑一下。 您可以主动向管理层传达实施 DevOps 的前景。 好吧，同时，领导这个过程。 积极主动是 DevOps 理念的重要原则之一。
每年财务周转的规模和数量并不是决定你的公司是否需要DevOps的主要标准。
让我们想象一个不直接与客户互动的大型工业企业。 例如，一些汽车制造商和汽车制造公司。 我现在不确定，但根据我过去的经验，多年来所有客户互动都是通过电子邮件和电话完成的。
他们的客户是有限的汽车经销商。 每一位产品都配备了制造商的一名专家。 所有内部文档流均通过 SAP ERP 进行。 内部员工本质上是信息系统的客户。 但这个 IS 是通过管理集群系统的经典方法来控制的。 这就排除了使用 DevOps 实践的可能性。
因此得出的结论是：对于此类企业来说，如果我们回想本文开头的方法论目标，那么实施 DevOps 并不是至关重要的事情。 但我不排除他们现在使用一些 DevOps 工具。
另一方面，有许多小公司使用 DevOps 方法、理念、实践和工具来开发软件。 并且他们认为，实施DevOps的成本就是让他们能够在软件市场上有效竞争的成本。 此类公司的例子可见 .
了解是否需要DevOps的主要标准是：你的IT产品对公司和客户有什么价值。
如果公司产生利润的主要产品是软件，那么就需要DevOps。 如果您使用其他产品赚取真金白银，那么这并不那么重要。 这还包括在线商店或带有游戏的移动应用程序。
任何游戏的存在都要归功于资金：直接或间接来自玩家。 在 Playgendary，我们开发免费手机游戏，有超过 200 人直接参与创作。 我们如何使用 DevOps？
是的，与上面描述的完全一样。 我不断与开发人员和测试人员沟通，并对员工进行 DevOps 方法论和工具的内部培训。
我们现在积极使用 Jenkins 作为 CI/CD 管道工具，通过 Unity 执行所有组装管道，并随后部署到 App Store 和 Play Market。 经典工具包的更多内容：
- Asana - 用于项目管理。 与 Jenkins 的集成已配置。
- Google Meet - 用于视频会议。
- Slack - 用于通信和各种警报，包括来自 Jenkins 的通知。
- Atlassian Confluence - 用于文档和小组工作。
我们的近期计划包括使用 SonarQube 引入静态代码分析，并在持续集成阶段使用 Selenium 进行自动化 UI 测试。
取而代之的是结论
最后我想提出以下想法：要成为一名高素质的 DevOps 工程师，学会如何与人进行现场交流至关重要。
DevOps 工程师是一名团队合作者。 没有别的。 与同事沟通的主动权应该来自于他，而不是受某些环境的影响。 DevOps 专家必须为团队查看并提出最佳解决方案。
是的，任何解决方案的实施都需要大量的讨论，到最后它可能会完全改变。 这样的人能够独立发展、提出并实施自己的想法，对团队和雇主来说都具有越来越大的价值。 最终，这反映在他每月的薪酬金额或额外奖金的形式中。
来源： habr.com