DevOps至少有两个公认的视图-从系统管理员的角度和从开发人员的角度。 前者通常吹嘘他们自200X以来就一直在使用Chef / Puppet / Ansible / Docker，后者则认为DevOps要么已经寿终正寝，最终导致NoOps，要么是“我将所有东西都包装在了一个容器中，然后又如何了”。
同时，该公司在文章中阅读了有关DevOps的信息，并希望下面的人能弄清楚该怎么做。 同时，DevOps本身不会发生，业务不会像Google那样，公司不会变成绿松石，人们不会创造新的方法来检验世界上的假设。
本文是关于DevOps作为系统的。 它如何帮助业务，应如何发挥DevOps的工程师能力，可以通过软件生产的DevOps方法解决哪些业务任务，以及在DevOps生产过程中可能出现的错误以及如何避免或停止它们。 最终，工程师如何才能成为这个世界上的人并成为创造者，如何为此建立职业道路，以及如何开始以人为视角看待技术。
该材料基于我们2017年10月DevOops会议
的 Alexander
osminog Titov的
报告抄本。
对于那些习惯于观看会议记录的人，我们附有视频。我为Express 42工作。我的故事是关于我的职业道路的，但我会为他提供有趣的提示和结论。 它有一个易记的名称“从系统管理员到人员”。 我将系统管理员的角色与某些人的情况分开。 DevOps使我们不仅是艺术家，而且是新数字产品的创作者等等。
由于我的故事基于我的经验，因此我将向您介绍一些有关我自己的事情。 我上大学时开始担任系统管理员。 他从事夜班工作，然后开始从事白班工作，然后升任主管系统管理员的职位。 然后，我在社交网络connectect.ua和fakultet.ru工作，然后在Oversan-Skalaksi公司担任技术总监。 事实证明，这是在俄罗斯启动云托管的首批尝试之一。 只是现在才出现了对俄罗斯托管云的需求。 我们只是了解了如何使用它们，意识到它们是灵活的资源，它们需要以不同的方式编写应用程序，等等。 在那些日子里，没人能完全理解这一点，因此出售它非常困难。
然后，我在硅谷的一家Qik初创公司工作，该公司的开发办公室在俄罗斯。 在Qik，我真的感受到了DevOps概念的好处，因为在两个月内，我们开发了一个产品，用户数量从0增加到500万。 如果从服务的角度来看，在Oversan-Skalaxi中，我认为需要DevOps并且人们需要了解使用云托管的DevOps是什么，那么在Qik中，我作为系统管理员和系统管理员部门的负责人感到如此。 然后我们被Skype收购，我们开始在那里进行集成，并且在那里也集成了DevOps领域的发展，因为它不在Skype中。 然后Skype收购了Microsoft。 看来他来的公司大约有40名员工，几年后您在一家拥有10万员工的大公司工作。 这是一次非常有趣的经历。
结果，我在这些公司中找不到前进的方向，我和我的同事们打开了Express 42，将DevOps推向大众。 这个想法起源于Oversan-Skalaksi，并且让我感动。 除其他事项外，我非常重视俄罗斯的DevOps社区。 我是莫斯科DevOpsDays和莫斯科DevOps会议的组织者。
长期以来，我一直担心使用Ansible可能是坏事。 整个工具无法解决任何问题。 您可以使用Docker，Kubernetes，安装最新的Prometheus，但是与此同时，您所做的与使用bash脚本的人没有什么不同。 我将尝试回答为什么会这样。 从许多方面来说，这个答案就在我们内部，因此这篇文章就这样被称为。 系统管理员会思考如何为他编写bash脚本，而此人会有所不同。
DevOps如何出现在公司中？
DevOps开发人员
DevOps可以通过多种方式出现在公司中。 其中一种方法是，当开发人员厌倦了要求系统管理员执行某些操作时，并且在听说了DevOps之后，尝试实现它。 但是与此同时，他们对DevOps有独特的了解。 他们认为可以使用任何技术，将所有内容包装在Docker容器中，然后将其发送给系统管理员，但他们根本没有考虑代码在生产中的工作方式。 他们并没有改变任何想法以切换到DevOps，但是与此同时，他们开始使用新技术。
我见过很多这样的公司。 您来找他们-他们有四个开发部门。 每个部门都编写自己的微服务，每个部门都有自己的数据库。 有人Redis，有人PostgreSQL，同时有人PostgreSQL和MySQL。 并且它们伴随着这一点，直到数据库增长到无法再扩展的程度为止。
在这一点上，一切都开始崩溃和崩溃，并产生了可怕的后果。 这是一个技术动物园，目前尚不清楚该怎么做。 此外，开发人员的独特之处在于他可以通过拖动新库来解决问题。 我认为与Node.js开发人员合作的人员对此很熟悉。 当Node.js开发人员发现数据库运行不正常时，他们可以从PostgreSQL跳转到某个版本，添加一些扩展名，或者开始使用一些JSONB。 结果，出现了可怕的体系结构状态，但是总的来说，他们对一切都感到满意。 该应用程序难以管理，您无法弄清楚那里发生了什么，它的稳定性很差，并且经常崩溃。 为应对崩溃的应用程序，开发人员在此处添加了其他内容，并且该内容继续下降，结果，人们一无所知。
系统管理员DevOps
有诸如DevOps-sysadmin之类的东西。 通常，这些都是非常有能力的人，已经证明了自己的能力。 他们说：
“伙计们，你不能那样生活，我们已经厌倦了抽水，我们现在正在使一切自动化，我们将使交付管道变得如此甜蜜，美好，并且运转良好。 我们非常了解应用程序在生产中应如何工作。 比这些笨蛋在Node.js上写的要好得多。 我们知道需要使用什么才能使一切都完美。”几次我遇到这样的事实，即这些人在FreeBSD上构建了DevOps。 结果是他们自己编写了一个封闭的系统，只有他们了解它是如何工作的。 尽管有系统管理员的经验，但我无法弄清楚，但如果不能，那么开发人员应该如何理解如何通过此CI系统进行部署？ 结果，尽管我真诚地爱护并尊重系统本身，尤其是我爱OpenBSD，但我还是在行政上禁止在公司中使用FreeBSD。 但是一周之后，在Linux服务器中，FreeBSD服务器又开始出现了，就像飞木耳一样。
DevOps系统管理员以及开发人员都认为技术是最重要的，没有它们就无法做任何事情。 如果他们喜欢这项技术，他们会尝试将其推广到任何地方。
在Oversan-Skalaxi，我们创造了只写配置和脚本一词。 这是一个人可以写作但没人可以阅读的时间。
同时，系统管理员继续修复肥皂中的某些东西。 您来找他并提供帮助，他会用三层高的垫子给您一些东西。 您什么都不懂，因为您必须弄清楚他的工作。 好吧，如果开发人员来说，例如，他需要一个容错数据库？ 他将获得这个三层高的垫子的东西，他会坐下来，不知道该怎么做。 万事俱备，开发人员和系统管理员无法沟通。 尽管内部使用了所有最现代，最精致的材料。
系统管理员的传统观念从这里诞生：这是一个多臂的人，可以做某事，但是您不会完全了解。 顺便说一下，大多数HR现在都在寻找这样的东西。 我可以告诉你，在公司中找到这样的人不会为您节省100％的麻烦。
商业DevOps
DevOps出现的另一种方式是从业务方面。 您的一些高级管理人员参加了一些商务会议，例如去了山谷，他们告诉他，如果您没有Docker，一些持续集成（CI）等功能，那么您就不会被认为是科技公司。 经理返回，收集员工并从笔记本中读取文字：DevOps，Docker，Concourse CI。 伙计们开始理解，然后发生了上面提到的混合场景：DevOps-developer，DevOps-sysadmin，所有这些都会导致您一团糟。
实际上，我经常看到这种情况。 为什么会发生这种情况：您参加会议时，每个人都有一个理性的，正常的看法-然后进入战production，进入生产，然后出现垃圾和烟雾？ 就是说，每个人都了解所有东西，但是由于某种原因他们没有工作。 我有一个假设，即每个人都了解一部分，而不是全部。 因此，现在我将尝试从整体上谈论DevOps。
从企业到敏捷
首先，从业务的角度来看，我们正在经历一个转折点：我们正在从实施重大项目的企业转移到将业务本身从A点转移到B点（例如，一项为期五年的战略，以占领70％的市场）...
……来到敏捷世界。 敏捷性的观点不是灵活的，但是A点是已知的，而B点则不是。 这是可能发生的最深刻的事情。 因为我们和企业都不习惯与此一起工作。 想象一下，您不知道一周或两周后会发生什么，领导来找您说：
“所以，请给我找一些不可能的东西，写下您的名字，这样您就不会着急了 。
” 而且您不知道该怎么做，但是世界和商业正在以这种方式发展，您需要习惯它。 而所有这些实践，例如敏捷，Scrum，看板，都与如何生活无关。
我们正在从企业和公司的方式转变为技术的方式。 一些软件开始在市场上与我们互动。 如果以前的人们，公司与我们互动，卖家打了电话等等，现在打电话给出租车，订购披萨，听音乐，我们将转到该应用程序。 应用程序是某人需要编写并不断适应市场的软件。 我们，工程师和从事商业活动的人员必须从应用程序中了解市场的变化。 最后，它使我们转向了DevOps。
之所以不会出现DevOps，是因为你们其中之一应该很舒服，而不是因为您需要使用更酷的技术。 NoSQL不比SQL更酷；而且，到3-4年前，它比SQL还差。 SQL数据库已开发20年，NoSQL数据库已开发1年。 我们还记得4年前MongoDB的悲惨状态，当时它根本不是数据库。
DevOps与以前相同，只是现在我们同时进行所有操作。 如果您是开发人员，则可以编写代码并立即编写测试，Kubernetes的包装器或只是Docker容器，了解其在生产中的工作方式。 为此，您必须满足一个最低条件-运行此代码。 因为前一个时代的许多开发人员都没有这样做：编译器已经编译，并且从那里开始并开始在应用程序容器中工作的内容已经是第十件事了。 同时，编写指标，应收集的日志。 然后，将其全部释放到Delivery Pipeline，Jenkins，TeamCity或其他地方。 这是公司的开发人员与技术公司的开发人员之间的根本区别。 在这里，开发人员不仅开始编写算法，还开始编写整个产品。
DevOps的历史
现在是时候回顾一下DevOps的历史了。 这一切是怎么产生的？ 我生活在这里，不断地阅读新闻，跟随历史链条，它们如何出现。 现在，来自不同年份的不同人告诉我DevOps是什么以及它是如何产生的不同版本。 对我来说，回归根源似乎很重要。
2003年，Google的Ben Trainor创立了SRE团队。 Google是世界上第一家大型数字公司。 早在2003年，他们就面临着一个问题，即所有软件开发人员都习惯了经典的方式，他们无法做自己想做的事情。 他们通过引入SRE团队进行了创新，并从此发展了这种做法。
2009年，约翰·阿尔斯帕（John Alspaw）和保罗·哈蒙德（Paul Hammond）谈论了如何在Flickr中合作以及如何每天共享10次。 当时是一种轰动和爆炸。 帕特里克·德博伊特（Patrick Deboit）窥探了这份报告，并创造了DevOps一词，组织了国际社会，以进一步发展这种实践。
科技公司应运而生，需要快速共享。 旧的方法不合适，他们开始提出新的方法。 顺理成章地，自然地，对它们进行了重新安排，使他们有了创建软件的新实践。
我们处于非常困难的状况，因为我们没有这种自然的变化。 当那里已经发生了某些事情时，就会出现此类技术，但是我们仍然不知道如何使用它们。 在那里，人们逐渐进化到了这一点，我们必须进行一场革命，重新思考所有这一切，并以某种方式将其转移到自己的土壤上。
如何应用DevOps？
使用DevOps时，真正意识到您正在生产数字产品非常重要，并且上市时间（TTM）对公司来说很重要。
将所有团队变成开发团队非常重要。 不再有单独的sysadmin和单独的开发人员。 因为我们称为系统管理员的人员编写了称为基础架构平台的内容，而开发人员则编写了称为产品的内容，因此他们彼此提供了服务。
我们都忘记的另一个显而易见的非常重要的事情是组织团队内部以及团队之间知识的积累和交换的组织。 我们对此有很大的问题。 例如，我们不喜欢共享尚未准备好的东西，这是DevOps存在的关键。 我们必须谈论尚未准备好的东西，检验假设，我们必须对告诉我们他们还没有准备好的人保持开放。 例如，因为我们习惯于系统管理员测试过一些很酷的东西，所以他们回答说：
“不，但是它在生产中如何工作，您测试了什么？”系统管理员意识到他们不了解的地方，他们没有进行测试的地方，离开，关闭，这些知识消失了，因此我们不往前走。 正确地说：
“伙计们，看！ 您做得非常好，很出色，但是我真的想问一个问题：这在生产中将如何工作？ 你有想过吗 “下次您向我们展示如何在生产中实现此功能时，它将非常酷！”他们已经离开了任务。 在我们的经典俄罗斯方法
“是的，不是，所有垃圾”的情况下
，他们的想法是
“如果我们都被拒绝，我们为什么要这样做” 。 这是DevOps社区内部的一个大问题。 我们不会互相分享，因为我们不确定这不会像看起来那样明显或不那么坚强，等等。
我已经从会议组织者那里听到，每个人都需要一个超级铁杆。 好吧，也许您不能成为一个超级铁杆，但是让一个人分享真实的经验并且您可以谈论它，这也很酷。
DevOps的开发人员
DevOps的开发人员不编写代码，而是编写产品。 这不是一件显而易见的事情，因为在研究所，课程和书籍中，我们作为程序员被教导写算法，而不是产品，被教导要解决的不是业务问题，而是算法问题。 这是一个巨大的问题。 在您的头脑中，跟踪在什么时候解决算法问题以及什么时候是实际的业务问题非常重要。
在一家从事DevOps运营的公司中，开发人员立即想到了他的代码将如何与其他组件集成。 立即开始对此进行交流。 例如，为了在聊天中阐明用于检查的API更改的路线图。 这是合作的开始。
开发人员对应用程序的体系结构有个想法-这很重要，因为如果不了解体系结构的工作原理，技术层是什么以及它们之间如何交互，就不可能考虑集成。
开发人员知道代码在战斗中如何工作，并了解此应用程序正在发生什么。 在我的示例中，当开发人员同时编写代码和Docker容器并进行监视时，他应该对架构如何工作，代码在生产中如何工作以及如何集成到应用程序中有所了解。 那些担任系统管理员或基础架构工程师的人正在考虑如何将这些知识传达给开发人员。 您的任务是告诉他们。 您可以聘请顾问，但可以自己聘请。
基础架构工程师
DevOps的下一个角色是基础架构工程师，他之前被称为系统管理员。 我非常不喜欢“ DevOps工程师”一词，因为DevOps是涵盖开发，测试和操作的常见实践。 正如我之前所说，您可以拥有一个DevOps工程师，一个DevOps团队，最好的技术，而您没有DevOps。
基础结构工程师创建主要用于产品开发的平台，但是对于开发人员来说应该很方便。 必须设法保持这种平衡。
基础架构工程师使用多层抽象来提供服务。 例如，
尼古拉·里芝科夫
（Nikolai Ryzhikov）有一篇有关Kubernetes的好
报告 ，他在那里展示了如何选择和使用多层抽象。 他在那里有一个理想的模型，并付诸实践。 可以将此类模型划分为不同的抽象级别。 这样做是为了减少问题解决和集成的复杂性。 当您具有可理解的抽象级别时，可以在它们之间进行切换，并查看差异在哪里。 您不必信任抽象层，但是谈论它们非常有用。 也就是说，它们不应该是绝对的，而是有用的工具。
基础架构工程师将平台设计为产品，知道如何成为产品所有者，了解什么设计思想，知道如何从开发人员那里收集需求。 但这是一个很高的层次，我不确定此类工程师是否以基础架构工程师的形式出现在市场中。
测试技术员
测试人员也做了些改动，成为一名技术人员，可以提高软件质量，并将此过程转换为代码。
发布经理/服务站
经理牢记持续交付软件的过程，管理业务期望和技术能力，生产发行版和发行版。他正在生产而不是计划，因为从A点到B点的转换过程是非线性的，在这种情况下他无法计划。结果，他们共同构建了一个基础架构平台，该平台是每个人的工具：基础架构工程师，开发人员和测试人员。
在此重要的是，代码应在传递过程中向右移动，并保留有关其运行方式的信息。您会不断获得有关代码如何通过交付管道的信息，并使用此信息进行更改。需要相互传达给开发人员以及每个人的主要事情是，所有这些基础架构都是一个通用工具（如git），每个人都在改进它。您不能说这是Petina的问题，因为他会超负荷工作，因此他将无法应对来自代码的信息的复杂性，结果您将无法正常运行的连续交付管道。在这样的方案中，有必要划分责任而不是知识和经验。有些人（发行经理或CTO）对一切都有知识和经验-他们掌握了整个情况。其他人则具有有关资源编排系统的知识和经验，其他人则具有数据库等，这些人是不同的团队，在这里工作并同时负责整个基础架构平台的不同人员。
在Express 42中，我们称此级别为base-service-app的概念。有一定的基本级别-资源的编排（分配）级别和各种低级别的基础结构服务。基础架构工程师在这里拥有更多的知识和经验。有一个服务级别：不同的数据库，负载平衡器，监视，日志记录，CI引擎（以TeamCity为引擎或以Jenkins为引擎）。有一个应用程序级别，它通过各种API，函数等将这些级别收集在一起。再一次，我参考了Nikolai Ryzhikov的报告，他完美地展示了这一切如何协同工作以及如何在Kubernetes上实现CI。
流程和技术至关重要。除了自己之外，您所使用的技术还有一种使用方式。例如，您可以用刀切面包，也可以杀死一个人。就在这里，只是在我们的情况下，它仍然更加复杂，甚至具有更高的抽象级别。您为此创建的过程非常重要。这些原则上，除了公司内部，没人能创建，因为它们是针对特定应用程序高度定制的。现在，原则上，像以前一样，您不可能雇用ITIL顾问，而他会为您准备好所有流程。网上银行应用程序和Yandex.Music就像天堂一样。有通用原则，但是过程本身是完全不同的。技术的每一层都有其必须构建的过程。在这里，我指的是艾伦·凯（Alan Kay）的话，他曾在一次采访中对哈布鲁（Habru）说过一个惊人的短语：“计算机可以比作乐器，它们的音乐就是创意。”因此，我们所拥有的技术应包括在创建想法的过程中（改进产品的想法，更改过程的想法，创建新产品的想法）。这很重要。
开展DevOps的公司应在自己内部搭建一个平台，并建立一个价值体系，这将使我们能够讨论使用我们使用的技术创建的构想以及我们使用这些技术（Kubernetes，Prometheus，Docker等）的程度。 ，以便播放音乐，并且不会折断邻居头上的吉他。原则上，从公司内部人员的角度出发，DevOps流程应安排如下。必须有需要讨论此事的人组成的组织单位，例如委员会。它不应该是架构部门，集成部门，连续交付部门或质量部门，而应该是负责收集和讨论我们的工作方式以及基于我们的技术创造新想法的委员会。他们创造并改变了工作方式，并在此基础上创造了知识，知识的一部分将是非正式的，这是正常的。总体而言，例如，当一个机械师说“给我废话”时，俄罗斯人就非常了解如何通过隐喻来传递知识。通过合作和交流，这些知识可以通过使用技术和技术本身的方式来创建和嵌入，而这种知识标准是在技术上实施的。当前时刻与旧企业时刻的不同之处在于，标准被固定在那里，而现在它们正在不断变化。在过去的3-4年中，许多技术和使用标准发生了变化，仅将其固定在人们的脑海中，甚至无法将它们固定在文档中。如果您喜欢此报告，请参加DevOops 2018会议：您不仅可以收听报告，还可以与讨论区中的任何发言人聊天。该会议将于10月14日在圣彼得堡举行，从9月1日开始，票价将增加。