谁是DevOps,什么时候不需要



在过去的几年中,DevOps主题变得非常流行。许多人梦想加入该组织,但是,正如实践所示,这通常仅是因为薪水水平。

有些人在其简历中指出了DevOps,尽管他们并不总是了解和理解该术语的本质。有人认为,对Ansible,GitLab,Jenkins,Terraform等进行了研究(列表可以继续按您的喜好进行),它将立即成为“开发者”。当然,事实并非如此。

在过去的几年中,我主要参与了在多家公司中实施DevOps的工作。在此之前,他从系统管理员到IT主管,已经工作了20多年。现在-DevOps Playgendary首席工程师。

谁是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进行的。内部员工实际上是信息系统的客户。但是,此IP的管理是通过管理集群系统的经典方法来执行的。这排除了使用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-用于通信和各种警报,包括来自詹金斯的通知。
  • Atlassian Confluence-用于文档和小组工作。

在不久的将来,我们将在连续集成阶段使用SonarQube进行静态代码分析,并使用Selenium工具进行自动化的UI测试。

而不是结论


我想以以下想法结束:为了成为一名高素质的DevOps工程师,学习如何与人进行活泼的沟通至关重要。

DevOps工程师是团队合作者。别无他法。与同事沟通的主动性应该来自他本人,而不是在任何情况下的影响。DevOps专家应查看并为团队提供最佳解决方案。

是的,任何解决方案的实施都需要大量讨论,最终甚至可能会改变。通过独立地发展,提供和实施他们的想法,这样的人对团队和雇主都具有增加的价值。最终,这反映在他的月薪金额或额外奖金的形式中。

All Articles