什么是DevOps

定义DevOps非常复杂，因此您每次都必须重新开始有关它的讨论。 仅在哈布雷（Habré）上，一千本有关该主题的出版物。 但是，如果您阅读此书，则可能知道什么是DevOps。 因为我没有。 嗨，我叫Alexander Titov（@ osminog ），我们将只讨论DevOps，我将分享我的经验。



我想了很长时间，我想如何使我的故事有用，所以这里会有很多问题-我问自己和我公司客户的问题。 通过回答这些问题，理解会越来越好。 我将告诉您为什么从我的角度来看需要DevOps，从我的角度来看又是什么，以及如何从我的角度理解您正在再次转向DevOps。 最后一项将通过问题。 通过亲自回答他们，您可以了解您的公司是否正在向DevOps迈进，或者是否存在问题。


一次我走过了并购的浪潮。 最初，我在一家小型创业公司Qik工作，然后被一家规模稍大的公司Skype收购，然后又被规模稍大的微软公司收购。 那时，我有了一个愿景，如何在不同的公司中转变DevOps的想法。 之后，从市场的角度来看DevOps对我来说很有趣，我和我的同事组建了Express 42公司。六年来，我们一直在沿着市场浪潮前进。

我是莫斯科DevOps社区的组织者之一，也是DevOps -Days 2017的组织者之一，但我没有组织2018年。 Express 42与许多公司合作。 我们在那里开发DevOps，观察其发生方式，得出结论，进行分析，将我们的发现告诉所有人，并教人们DevOps的实践。 一般而言，我们会以各种方式发展经验和专业知识。

为什么选择DevOps

困扰着所有人的第一个问题-为什么？ 许多人认为DevOps只是自动化或每家公司都已经拥有的类似产品。

-我们进行了持续集成-这意味着已经有了DevOps，为什么需要所有这些顶层？ 他们在国外玩得开心，但是却干扰了我们的工作！

在社区和方法论的9年发展中，已经很清楚这些不是营销亮点，但仍不清楚为什么需要它。 像任何工具和流程一样，DevOps具有最终解决的特定目标。

所有这些都是由于世界在变化的事实。 当公司如梦如幻的圣彼得堡歌唱一样，他按照某种策略从A点到B点，从企业的方法转向企业的方法，并为此构建了一定的结构。

原则上，在IT中，应为此方法构建所有内容。 在这里，IT仅用于流程自动化。

自动化不会经常更改，因为当公司沿着一条步履蹒跚的轨迹滚动时，有什么要改变的？ 有效-请勿触摸。 现在，世界上的方法正在发生变化，一种叫做“敏捷”（Agile）的词表示端点B并非立即可见。



当公司在市场中移动，与客户合作时，它会不断研究市场并更改其终点B。此外，公司改变方向的频率越高，最终它就越成功，因为它选择了更多的市场壁ni。

该策略由一家有趣的公司演示，我最近才了解到这一点。 一件式剃须刀-剃须刀和按箱剃须刀的送货服务。 他们知道如何为不同的客户定制他们的“盒子”。 这是由某些软件完成的，然后将订单发送给生产商品的韩国工厂。

该产品被联合利华以10亿美元的价格收购。 现在，他正在与吉列竞争，并抢走了他在美国市场上大量消费者的份额。 一盒刮胡子说：

-4把刀片？ 你是认真的吗 为什么需要此功能-它不能提高剃须质量。 与两个愚蠢的吉列4刀片相比，特选的奶油，香水和带两个刀片的高品质剃刀可以解决更多的问题！ 那么很快我们将达到10？

因此，世界在变化。 联合利华声称拥有可以使用的出色IT系统。 最后，它似乎是一个尚未面世的上市时间概念。



上市时间的重点不是我们部署的频率。 您通常可以部署，但是发布周期会很长。 如果三个月的发布周期彼此重叠，每星期偏移一次，那么事实证明该公司似乎每周部署一次。 从构思到最终实施，三个月过去了。

上市时间就是将从构思到最终实施的时间减至最少。

在这种情况下，软件与市场互动。 这就是One Box Shave与网站互动的方式。 他们没有卖家-只是访客点击并留下愿望的网站。 因此，站点必须不断发布新内容，并根据需要对其进行更新。 例如，在韩国，剃须的方式与在俄罗斯不同，他们喜欢松木的气味，但例如，香精中的香草胡萝卜 。

由于您需要快速更改站点的内容，因此软件开发正在发生巨大变化。 通过软件，我们必须找出客户想要什么。 以前，我们通过一些变通方法（例如，通过业务管理）了解了这一点。 然后，他们进行了设计，并将其放置在IT系统中，一切都变得很酷。 现在已经不一样了-该软件是由参与该过程的每个人（包括工程师）设计的，因为他们可以通过技术规范了解市场的运作方式，并与企业分享他们的见解。

例如，在Qik，我们突然发现人们真的很喜欢将联系人列表上传到服务器，然后他们将应用程序交给了我们。 最初，我们没有考虑这一点。 在一家经典公司中，每个人都会认为这是一个错误，因为该规范并未说它应该很酷并且通常在膝盖上实现，所以他们会关闭该功能并说：“这不需要任何人，最重要的是主要功能正常工作” 。 科技公司将这视为机遇，并开始据此更改软件。



1968年，有远见的家伙梅尔文·康威（Melvin Conway）提出了以下想法。

创建系统的组织限于复制该组织中的通信结构的设计。

更详细地，为了生产不同类型的系统，一个人还必须在另一类型的公司内具有通信结构。 如果您的通信结构是最高层次的，则不允许您创建可以提供很高的上市时间指标的系统。

您可以通过 以下链接 阅读有关康韦定律的信息 。 这对于理解DevOps的文化或理念非常重要，因为在DevOps中唯一发生根本变化的是团队之间的沟通结构 。

从流程的角度来看，在DevOps之前，所有阶段：分析，开发，测试，操作都是线性的。
对于DevOps，所有这些过程都将同时进行。



上市时间只能通过这种方式完成。 对于在旧过程中工作的人来说，它看起来有些宇宙，而且一般来说都是这样。

那么，为什么需要DevOps？

为开发数码产品 。 如果您的公司中没有数字产品，则不需要DevOps-这非常重要。

DevOps克服了一致的软件生产方案的速度限制 。 在其中，所有过程同时发生。

增加难度。 当DevOps宣传人员告诉您，使用它发行软件会更容易，这是胡说八道。

使用DevOps，事情只会变得更加复杂。

在Avito展台上的会议上，人们可以看到部署Docker容器是什么-这是不现实的任务。 复杂性变得令人望而却步，您必须同时处理许多球。

DevOps完全改变了公司的流程和组织 -更准确地说，它并没有改变DevOps，而是改变了数字产品。 要使用DevOps，您仍然需要完全更改此过程。

给专家的问题

那你呢 在公司工作和发展为专家时可能会问自己的问题。

您有数字产品策略吗？ 如果有的话，那已经很好了。 这意味着您的公司正在向DevOps迈进。

您的公司已经在创建数字产品吗？ 这意味着您可以再提升一个级别，并做更多有趣的事情-从DevOps的角度来看。 我只是从这个角度讲。

您的公司是数字产品利基市场的领导者之一吗？ Spotify，Yandex，Uber-目前处于技术进步高峰的公司。

问问自己这些问题，如果所有答案都是否定的，那么也许您不应该与该公司的DevOps打交道。 如果DevOps主题对您真的很有趣，也许……您应该搬到另一家公司吗？ 如果您的公司想使用DevOps，但您对所有问题都回答“否”，那么它就像是永远不会改变的美丽犀牛。

组织机构

就像我说的那样，根据康威（Conway）的法律，组织在公司中会发生变化。 首先，是从组织的角度阻止DevOps进入公司的原因。

“井”的问题

英语单词“ Silo”在这里被翻译成俄语“ well”。 这个问题的意思是， 团队之间没有信息交换 。 每个团队都深入挖掘其专业知识，而不构建可导航的通用地图。

在某些方面，它类似于刚到达莫斯科但仍然不知道如何导航地铁地图的人。 莫斯科通常对他们的地区非常了解，整个莫斯科都受到地铁地图的引导。 当您第一次来莫斯科时，没有这项技能，您只是迷失了方向。

DevOps愿意度过这一迷茫的时刻，并与所有部门共同构建一个共同的互动地图。

有两个因素会干扰这一点。

公司管理系统的结果。 它由单独的分层“井”构建。 例如，公司中有某些KPI支持此系统。 另一方面，一个人的大脑难以超越其专业知识的范围，并且很难在整个系统中导航。 真是不舒服。 想象一下您到达了曼谷机场-在那儿您将不会很快找到自己的方位。 DevOps也很难导航，因此人们说您需要找到指南才能找到它。

但最重要的是，福勒（Fowler）和其他许多书籍都对受DevOps精神启发的工程师而言，“井”问题表现为“井” 不允许您做“显而易见的”事情 。 在莫斯科DevOps之后，我们经常聚在一起，互相交谈，人们抱怨：

-我们只是想启动CI，但事实证明，管理层并不需要它。

正是由于这样的事实， CI和连续交付过程处于许多检查的边界。 仅仅在组织层面上不能克服“井”的问题，您将无法进一步前进，无论您做什么，可能会多么悲伤。



公司流程中的每个参与者：后端和前端开发人员，测试，DBA，操作，网络，按自己的方向挖矿，除了经理以某种方式观察并控制分而治之的方法外，没有人拥有一张普通卡。

人们为争夺一些小星星或旗帜而战，每个人都挖掘自己的专业知识。

结果，当任务似乎将所有这些连接在一起并建立一条公共管道，而无需争夺星号和旗帜时，问题就出现了-我该怎么办？ 我们必须以某种方式达成共识，但是没有人教我们如何做到这一点。 我们从学校教书：八年级-哇！ -相比七年级！ 这里是一样的

贵公司也一样吗？

要进行检查，您可以问自己以下问题。

团队是否使用通用工具，他们是否对这些通用工具做出了贡献？

团队多久进行一次改革？一个团队中的一些专家会迁移到另一团队吗？ 在DevOps环境中，这变得很正常，因为有时一个人根本无法理解另一个专业领域正在做什么。 他搬到另一个部门，在那里工作了两个星期，为自己创建了一个方向和与该部门互动的地图。

是否可以成立一个变革委员会并进行某些改变？ 还是这需要最高领导和领导的强有力的支持？ 我最近在Facebook上写道，一家鲜为人知的银行是如何通过订单实施工具的：我们写了订单，实施了一年，然后看看会发生什么。 当然，这是漫长而可悲的。

对于经理而言，不考虑公司成就而获得个人成就有多重要？

如果您亲自回答这些问题，那么在公司中遇到此类问题将变得更加清楚。

基础架构即代码

解决此问题之后， 基础架构即代码是第一个重要的实践，如果没有该实践，将很难进一步进入DevOps。

大多数情况下，将基础结构视为代码如下：

-让我们自动执行bash上的所有操作，用脚本覆盖自己，以便管理区域减少手动工作！

但是事实并非如此。

基础架构作为代码意味着您要描述与其一起使用的IT系统，以便不断了解其状态。

与其他团队一起，以每个人都能理解的代码形式创建地图，您可以进行导航。 做什么都没有关系-Kubernetes中使用Chef，Ansible，Salt或YAML文件-没有区别。

在会议上，来自2GIS的一位同事讨论了他们如何为Kubernetes制作自己的内部事物，它描述了各个系统的结构。 为了描述500个系统，他们需要一个单独的工具来生成此描述。 有了此描述，每个人都可以相互检查，监视更改，如何更改和改进它（缺少）。

同意，单独的bash脚本通常无法提供这种理解。 在我工作过的一家公司中，编写脚本时甚至有一个名字“只写”（即只写脚本），而且已经无法读取。 我想您也很熟悉。

基础结构作为代码是描述基础结构当前状态的代码 。 许多产品，基础架构和服务团队在此代码上共同工作，最重要的是，他们都需要了解此代码通常是如何工作的。

该代码是根据与代码一起使用的最佳实践随附的 ：联合开发，代码审查，XP编程，测试，pull-quests，代码基础结构的CI-所有这些都是合适的并且可以使用。

代码正在成为所有工程师的通用语言。

更改代码中的基础结构不会花费很多时间 。 是的，基础架构代码中也可能存在技术债务。 通常，团队在开始以一堆脚本甚至Ansible的形式实现“基础架构即代码”一年半之后就遇到了，他们将其编写为意大利面条式代码，甚至bash脚本也将其放入了火箱！

重要提示 ：如果您还没有尝试过这些东西，请记住Ansible不是bash ！ 仔细阅读文档，研究他们对此的一般看法。

基础架构即代码是将基础架构代码划分为单独的层。

在我们公司中，我们区分了3个基本层，它们非常清晰和简单，但可能还有更多。 您可以查看基础结构代码，并说出是否具有此条件。 如果没有突出显示任何层，则需要分配时间并进行一些重构。


基础层是如何配置操作系统，备份和其他低级内容，例如，如何在基本级别上部署Kubernetes。

服务级别是您为开发人员提供的服务：作为服务记录，作为服务监视，作为服务的数据库，作为服务的平衡器，作为服务的队列，作为服务的持续交付-各个团队可以提供开发的一堆服务。 所有这些都必须在配置管理系统中描述为单独的模块。

制作应用程序的层以及如何将它们部署在前两层之上。

安全问题

您的公司中是否有通用的基础结构存储库？ 您控制基础设施中的技术债务吗？ 您是否在基础结构存储库中使用开发实践？ 您的基础架构是否被分割？ 您可以检查Base-service-APP模式。 进行更改有多困难？

如果您面对引入变更需要一天半的事实，这意味着您承担了技术上的债务，需要与之合作。 您只是偶然发现了基础架构代码中大量的技术债务。 我记得许多这样的故事，当时为了更改任何CCTL，有必要重写一半的基础设施代码，因为创造力和使一切自动化的愿望导致这样的事实，即所有地方都被缩短了，所有笔都被移走了，而您需要重构。

持续交付

类似的借记借方。 首先，出现对基础结构的描述，这可能是非常基本的。 不必详细描述所有内容，但是需要一些基本描述，以便您可以使用它。 否则，尚不清楚下一步该做什么。 所有这些实践都在您进入DevOps的同时展开，但是您需要首先了解自己所拥有的以及如何对其进行管理。 这只是基础架构作为代码的实践。

在明确了您如何管理它之后，您开始考虑如何尽快将开发人员代码发送到生产环境。 我的意思是，与开发人员一起-我们记得“井”的问题，也就是说，不是每个人都提出这个问题，而是由团队提出。

当Vanya Yevtukhovich和我看到Jes Hamble的第一本书以及2009年发行的作者“ Continuous Delivery”时 ，很久以来我们一直在考虑如何将其名称翻译成俄语。 他们想将其翻译为“持续交付”，但不幸的是，将其翻译为“连续交付”。 在我看来，我们的头衔有些压力。

不断交付-这意味着

杂货库中的代码始终可以在生产环境中下载 。 它可能没有放气，但它随时可以为之准备。 因此，您在编写代码时总是很难理解尾骨下的某种担忧。 当您推出基础结构代码时，它通常会出现。 — , -. .

, , . « », , , . — : , .

- . , - , , , . , , DevOps- : - , — Kubernetes- , - , .

- — - . , - . Continuous Delivery : , - , . , . , .

. , AB- , - «» , , , , 100 .

« » .

Dev, CI, Test, PreProd, Prod — , , .

, Base Service APP, , , .

95 % ? ? , ? ?

, ! — ).

意见反馈

. DevOpsConf Infobip, , , , !



, -, Qik , . , Zabbix 150 000 items, . , :

— , ?

, , .

. , , , , - — . 4 , «Segmentation fault».

, Zabbix, , , , API-, . , . , android-. :

— , ?

, UI. , HTTP-. android- — . , 40 , , - HTTP-, . , API , , , .

. «», , . , . , , , , — , , ( ), . .

, — .

CI, - . Test, PredProd, . , , , : , — .

. , DevOps — . , .

— ? , , , , ?

? ? ? , , , 3 ?

, , .

, , .

, .

, , . , , . .

, IDE . IDE , , . Sublime, Atom Visual Studio Code, , , IDE.

. , - , , . - — , pull request — , . .

. , . , — .

, , . , Time-to-market. vendor lock : , , , . , . , , vendor lock . .

, DevOps-.



, .

, CPU, , . — : , , CI/CD Engine, , .

: , , , Load Balance , resizing , Big Data . — , .

, , , , — , .

delivery pipeline . , — . , — : , , , , .

, , — , , . , Okmeter? , , . — , , Prometheus .

. , , , . , DevOps.


— , , . rocket science — , . , — .

?

, .

? ? ?

. - — , , .

, DevOps...

… , :

• .
  
• , .
  
• , .
  
• Continuous Delivery.
  
• .
  
• .
  
• .
  
• , DevOps.
  
• , .
  

, , - : .

DevOpsConf 2019 . ++. , , DevOps-. , 20