DevOps的定义非常复杂，所以我们每次都要重新开始讨论它。 仅就哈布雷而言，就有上千篇关于该主题的出版物。 但如果您正在阅读本文，您可能知道 DevOps 是什么。 因为我不是。 你好我的名字是 亚历山大·蒂托夫（@），我们只讨论 DevOps，我会分享我的经验。
我已经思考了很长时间如何让我的故事变得有用，所以这里会有很多问题——我问自己的问题和我问我们公司客户的问题。 通过回答这些问题，理解会变得更好。 我将从我的角度告诉你为什么需要 DevOps，从我的角度再次告诉你 DevOps 是什么，以及如何从我的角度理解你正在再次走向 DevOps。 最后一点将通过问题进行。 通过亲自回答这些问题，您可以了解您的公司是否正在向 DevOps 迈进，或者是否存在某种问题。
有一段时间，我正乘着并购浪潮。 首先，我在一家名为 Qik 的小型初创公司工作，然后它被一家规模稍大的公司 Skype 收购，然后又被一家规模稍大的公司 Microsoft 收购。 那一刻，我开始看到DevOps的理念在不同规模的公司中是如何转变的。 之后，我开始对从市场角度看待DevOps产生了兴趣，我和我的同事创立了Express 42公司。六年来，我们一直沿着市场的浪潮前进。
除此之外，我是 DevOps 莫斯科社区的组织者之一，也是 2017 年 DevOps-Days 的组织者，但 2018 年我没有组织。 Express 42 与许多公司合作。 我们在那里发展 DevOps，观察它是如何发生的，得出结论，分析，告诉每个人我们的结论，并培训人们进行 DevOps 实践。 总的来说，我们正在尽最大努力增加这方面的经验和专业知识。
为什么选择 DevOps
始终困扰着每个人的第一个问题是——为什么？ 许多人认为 DevOps 只是自动化或每个公司已经拥有的类似东西。
— 我们有持续集成 - 这意味着我们已经有了 DevOps，为什么需要所有这些东西？ 他们在国外玩得很开心，却阻止我们工作！
社区和方法论经过 9 年的发展，已经很清楚这仍然不是营销闪光，但仍然不完全清楚为什么需要它。 与任何工具和流程一样，DevOps 也有最终实现的特定目标。
这一切都是因为世界正在发生变化。 他放弃了企业方法，当公司直接朝着梦想前进时，正如我们圣彼得堡的经典歌曲所唱的那样，根据特定的策略从A点到B点，并为此建立了特定的结构。
原则上，IT 中的一切都应该按照这种方法构建。 在这里，IT 专门用于自动化流程。
自动化不会经常改变，因为当一家公司陷入困境时，还有什么需要改变的呢？ 它有效 - 不要碰它。 现在世界上的方法正在发生变化，而所谓的敏捷方法表明终点 B 并不是立即可见的。
当一个公司走过市场，与客户合作时，它不断地探索市场并改变终点B。而且，公司改变方向的次数越多，最终就越成功，因为它选择了更多的市场利基市场。
我最近了解到的一家有趣的公司展示了该策略。 One Box Shave 是一项订购送货服务，提供盒装剃须刀和剃须配件。 他们知道如何为不同的客户定制他们的“盒子”。 这是通过某种软件完成的，然后该软件将订单发送到生产该产品的韩国工厂。
该产品被联合利华以 1 亿美元收购。 现在它与吉列竞争，抢走了美国市场相当大的消费者份额。 一盒剃须 说：
— 4 个刀片？ 你认真的吗？ 为什么您需要这个 - 它不会提高剃须质量。 特选的奶油、香水和带有两个刀片的高品质剃须刀比那些愚蠢的 4 个吉列刀片解决了更多的问题！ 我们很快就会达到 10 吗？
世界就是这样改变的。 联合利华声称他们有一个很酷的 IT 系统可以让你做到这一点。 最后看起来像是一个概念 上市时间，没有人谈论过这一点。
上市时间的重点不在于我们部署的频率。 可以经常部署，但是发布周期会很长。 如果将三个月的发布周期相互叠加，将其移动一周，则结果表明该公司似乎每周部署一次。 而从产生想法到最终实施需要3个月的时间。
上市时间是指最大限度地缩短从想法到最终实施的时间。
在这种情况下，软件与市场相互作用。 这就是 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，但你对所有问题都回答“否”，那么它就像那头美丽的犀牛永远不会改变。
组织
正如我所说，根据康威定律，公司的组织会发生变化。 我将从组织的角度开始讨论阻碍 DevOps 渗透到公司内部的因素。
“井”的问题
英语单词“Silo”在这里被翻译成俄语“井”。 这个问题的要点在于 团队之间没有信息交换。 每个团队都深入挖掘自己的专业知识，但没有构建通用的导航地图。
在某些方面，这让我想起一个刚到达莫斯科、还不知道如何导航地铁地图的人。 莫斯科人通常非常了解自己所在的地区，他们可以使用地铁地图在整个莫斯科进行导航。 当你第一次来莫斯科时，你没有这个技能，你只是迷失了方向。
DevOps 建议度过这个迷失方向的时刻，所有部门共同努力构建一个共同的交互图。
有两个因素阻碍了这一点。
公司管理体系的后果。 它建立在单独的分层“井”中。 例如，支持该系统的公司有某些 KPI。 另一方面，如果一个人发现很难超越自己的专业知识范围并驾驭整个系统，那么他的大脑就会成为障碍。 就是不舒服。 想象一下，您在曼谷机场 - 您不会很快找到路。 DevOps 也很难驾驭，这就是为什么人们说你需要找到一个指南才能到达那里。
但最重要的是，对于一个充满 DevOps 精神、读过 Fowler 和其他一堆书籍的工程师来说，“井”的问题表现为： “井”不允许你做“明显”的事情。 我们经常在莫斯科 DevOps 之后聚在一起互相交谈，人们抱怨：
——我们只是想推出 CI，但结果发现管理层不需要它。
发生这种情况正是因为 CI и 持续交付流程 正处于许多考试的边缘。 如果不克服组织层面的“井”问题，无论你做什么，无论多么悲伤，你都无法前进。
公司流程中的每个参与者：后端和前端开发人员、测试、DBA、运营、网络，都在自己的方向上挖掘，除了经理之外，没有人有共同的地图，经理以某种方式监视他们并使用“划分”来管理他们并征服”的方法。
人们都在争夺一些明星或旗帜，每个人都在挖掘自己的专长。
因此，当出现将所有这些连接在一起并建立一个共同管道的任务时，并且不再需要争夺星星和旗帜时，问题就出现了 - 无论如何该怎么办？ 我们需要以某种方式达成协议，但在学校没有人教我们如何做到这一点。 我们从学校起就被教导：八年级 - 哇！ - 与七年级相比！ 这里也是一样。
你们公司也是这样吗？
要检查这一点，您可以问自己以下问题。
团队是否使用通用工具并为这些通用工具的更改做出贡献？
团队重组的频率是多少——一个团队的一些专家转移到另一个团队？ 在 DevOps 环境中，这变得很正常，因为有时一个人根本无法理解另一个专业领域在做什么。 他调到另一个部门，在那里工作了两周，为自己绘制了一张与该部门的定位和互动地图。
是否有可能成立一个变革委员会来改变现状？ 还是需要最高管理层的强力指导？ 我最近在 Facebook 上写道，一家鲜为人知的银行如何通过订单实施工具：我们写下订单，实施一年，看看会发生什么。 当然，这是漫长而悲伤的。
对于管理者来说，不考虑公司的成就而获得个人的成就有多重要？
如果你自己回答这些问题，你的公司是否存在这样的问题就会变得更加清楚。
基础设施即代码
这个问题通过之后，第一个重要的实践，没有它很难在DevOps中进一步推进，就是 基础设施即代码.
大多数情况下，基础设施即代码被认为如下：
— 让我们在 bash 中自动化一切，用脚本覆盖我们自己，这样管理员就可以减少手动工作！
但事实并非如此。
基础设施即代码意味着您以代码的形式描述您使用的 IT 系统，以便不断了解其状态。
与其他团队一起，以代码的形式创建一个每个人都可以理解并且可以导航和导航的地图。 无论是在 Chef、Ansible、Salt 还是在 Kubernetes 中使用 YAML 文件，都没有什么区别。
在会议上，2GIS 的一位同事讲述了他们如何为 Kubernetes 制作自己的内部东西，它描述了各个系统的结构。 为了描述 500 个系统，他们需要一个单独的工具来生成此描述。 当有这个描述时，每个人都可以互相检查，监控变化，如何改变它和改进它，缺少什么。
同意，个别 bash 脚本通常不提供这种理解。 在我工作的一家公司中，甚至有一个“只写”脚本的名称——当脚本被写入时，但不再可能读取它。 我想这对你来说也很熟悉。
基础设施即代码 描述基础设施当前状态的代码。 许多产品、基础设施和服务团队共同处理此代码，最重要的是，他们都需要了解此代码的实际工作原理。
代码根据最佳代码实践进行维护：联合开发、代码审查、XP 编程、测试、拉取请求、代码基础设施 CI - 所有这些都是合适的并且可以使用。
代码成为所有工程师的通用语言。
改变代码中的基础设施并不需要太多时间。 是的，基础设施代码也可能有技术债务。 通常，团队在开始以一堆脚本甚至 Ansible 的形式实现“基础设施即代码”一年半后就会遇到这种情况，他们编写的脚本就像意大利面条代码一样，而且他们还会将 bash 脚本混入其中！
这一点很重要：如果您还没有尝试过这些东西，请记住 Ansible 不是 bash！ 仔细阅读文档，研究他们写的内容。
基础设施即代码是将基础设施代码分离到不同的层中。
在我们公司，我们区分了3个基本层，非常清晰和简单，但可能还有更多。 您可以查看您的基础设施代码并判断您是否有这种情况。 如果没有突出显示任何层，那么您需要花一些时间进行一些重构。
基层 - 这就是操作系统、备份和其他低级事物的配置方式，例如 Kubernetes 在基础级别的部署方式。
服务水平 - 这些是您向开发人员提供的服务：日志记录作为服务、监控作为服务、数据库作为服务、平衡器作为服务、队列作为服务、持续交付作为服务 - 各个团队提供的一系列服务可以提供发展。 这一切都需要在配置管理系统的单独模块中进行描述。
进行应用程序的层 并描述它们将如何在前两层之上展开。
控制问题
贵公司有通用的基础设施存储库吗？ 您是否正在管理基础设施中的技术债务？ 您是否在基础设施存储库中使用开发实践？ 您的基础设施是否分层？ 您可以查看Base-service-APP图。 做出改变有多难？
如果您经历过需要一天半的时间才能进行更改，这意味着您有技术债务并且需要处理它。 您刚刚在基础设施代码中偶然发现了技术债务。 我记得很多这样的故事，为了改变一些 CCTL，你需要重写一半的基础设施代码，因为创造力和自动化一切的愿望导致一切都到处腐蚀，所有的手柄都被移除了，并且有必要重构。
持续交付
让我们比较一下借方和贷方。 首先是对基础设施的描述，这可能非常基础。 您不必详细描述所有内容，但需要一些基本描述，以便您可以使用它。 否则持续交付接下来要做什么就不清楚了。 当您接触 DevOps 时，所有这些实践都会同时展开，但首先要了解您拥有什么以及如何管理它。 这正是基础设施即代码的实践。
一旦明确您拥有它以及如何管理它，您就开始弄清楚如何尽快将开发人员代码发送到生产环境。 我的意思是与开发商一起 - 我们记得“井”的问题，也就是说，不是个人提出这个问题，而是一个团队。
当我们和 瓦尼亚·叶夫图霍维奇 看过第一本书 杰兹谦卑 和作者群体 “持续交付”2009年上映时，我们思考了很长时间如何将其标题翻译成俄语。 他们想将其翻译为“Constantly Deliver”，但不幸的是，它被翻译为“Continously Delivery”。 在我看来，我们的名字里有一些俄罗斯的东西，带着压力。
不断传递手段
产品存储库中的代码始终可以下载到生产环境。 他可能不会泄气，但他总是做好准备。 因此，你在写代码时总是带着一种难以解释的焦虑感。 当您推出基础设施代码时，它经常出现。 这种焦虑感应该存在——它会触发大脑过程，让你以稍微不同的方式编写代码。 这应该记录在开发的规则中。
为了一致地交付，您需要一种跨基础设施平台运行的工件格式。 如果你把不同格式的“生活垃圾”扔到一个基础设施平台上，那么它就会变得统一，难以维护，并且会出现技术债务问题。 工件的格式需要保持一致——这也是一项集体任务：我们都需要聚在一起，开动脑筋，想出这种格式。
当工件通过交付管道时，它会不断改进和更改以适应生产环境。 当一个工件沿着管道移动时，它不断地遇到一些不方便的事情，这与您投入生产的工件所遇到的情况类似。 如果在经典开发中，这是由进行部署的系统管理员完成的，那么在 DevOps 过程中，这种情况一直在发生：这里他们通过一些测试对其进行了测试，这里他们将其放入 Kubernetes 集群中，这或多或少是相似的到生产，然后突然他们开始负载测试。
这有点让人想起吃豆人游戏——这个神器经历了某种故事。 同时，控制代码是否真正贯穿故事以及它是否与您的制作有某种关系也很重要。 生产中的故事可以拖到持续交付过程中：当东西掉下来时就像这样，现在让我们在系统内编写这个场景。 每次代码也会经历这个场景，下次就不会再遇到这个问题了。 在它到达您的客户之前，您会更早了解到它。
不同的部署策略。 例如，您使用 AB 测试或金丝雀部署在不同客户端上以不同方式测试代码，获取有关代码如何工作的信息，并且比向 100 亿用户推出的时间早得多。
“持续交付”看起来像这样。
交付过程 Dev、CI、Test、PreProd、Prod 不是一个单独的环境，这些是您的工件所经过的具有防火总和的阶段或站。
如果您有被描述为基础服务应用程序的基础设施代码，那么它会有所帮助 不要忘记所有的脚本，并将它们写下来作为该工件的代码， 推广神器 并随时更改它。
自查问题
95%的情况下从功能描述到发布到生产的时间不到一周？ 工件的质量是否在流程的每个阶段都有所提高？ 有没有一个故事是这样发生的呢？ 您是否使用不同的部署策略？
如果所有的答案都是肯定的，那么你就太酷了！ 在评论中写下你的答案 - 我会很高兴）。
反馈
这是所有练习中最困难的。 在 DevOpsConf 会议上，Infobip 的一位同事在谈到这个问题时，语气有点困惑，因为这确实是一个非常复杂的实践，因为你需要监控一切！
例如，很久以前，当我在 Qik 工作时，我们意识到我们需要监控一切。 我们这样做了，现在 Zabbix 中有 150 个项目，这些项目受到持续监控。 吓人了，技术总监扭了扭太阳穴：
- 伙计们，你们为什么要用一些不明确的东西来强奸服务器？
但后来发生的一件事表明，这确实是一个非常酷的策略。
其中一项服务开始不断崩溃。 最初，它没有崩溃，这很有趣，代码没有添加到那里，因为它是一个基本代理，实际上没有业务功能 - 它只是在各个服务之间发送消息。 该服务 4 个月没有改变，突然开始崩溃并出现“分段错误”错误。
我们很震惊，在 Zabbix 中打开图表，结果发现一周半前，该代理使用的 API 服务中的请求行为发生了很大变化。 接下来我们看到发送某种类型消息的频率发生了变化。 后来我们发现这些都是安卓客户端。 我们问：
— 伙计们，一周半前你们发生了什么？
作为回应，我们听到了一个关于他们如何重新设计用户界面的有趣故事。 不太可能有人会立即说他们更改了 HTTP 库。 对于 Android 客户端来说，这就像在浴室里更换肥皂一样 - 他们只是不记得了。 结果，经过 40 分钟的交谈，我们发现他们更改了 HTTP 库，并且其默认计时也发生了变化。 这导致 API 服务器上的流量行为发生变化，从而导致出现了导致代理内部竞争的情况，并且开始崩溃。
如果没有深度监控，一般不可能打开这个。 如果组织仍然存在“井”的问题，当每个人互相扔钱时，这种情况可能会持续很多年。 你只需重新启动服务器，因为这是不可能解决问题的。 当您监视、跟踪、跟踪您拥有的所有事件，并将监视用作测试时 - 编写代码并立即指示如何监视它，也是以代码的形式（我们已经有了代码形式的基础设施），一切都变得清晰起来在手掌上。 即使如此复杂的问题也很容易追踪。
收集有关工件在交付过程的每个阶段（而不是生产阶段）发生的情况的所有信息。
将监控上传到CI，一些基本的东西已经在那里可见了。 稍后您将在 Test、PredProd 和负载测试中看到它们。 收集各个阶段的信息，不仅包括指标、统计数据，还包括日志：应用程序如何推出、异常情况 - 收集一切。
不然的话就很难弄清楚了。 我已经说过 DevOps 更复杂。 为了应对这种复杂性，您需要进行正常的分析.
关于自我控制的问题
您的监控和记录开发工具适合您吗？ 在写代码的时候，你的开发者，包括你，有没有想过如何去监控？
您是否听说过客户提出的问题？ 您是否通过监控和记录更好地了解客户端？ 通过监控和日志记录，您是否对系统有了更深入的了解？ 你改变系统只是因为你看到系统的趋势在增长并且你知道再过三周一切都会消亡吗？
一旦有了这三个组件，您就可以考虑您的公司拥有什么样的基础设施平台。
基础设施平台
重点不在于它是每家公司都拥有的一套不同的工具。
基础设施平台的重点是所有团队都使用这些工具并共同开发它们。
显然，有单独的团队负责基础设施平台各个部分的开发。 但同时，每一位工程师都对基础设施平台的开发、性能和推广负有责任。 在内部层面，它成为一种通用工具.
所有团队都开发基础设施平台并将其视为自己的 IDE。 在 IDE 中，您可以安装不同的插件以使一切变得又好又快，并配置热键。 当你打开 Sublime、Atom 或 Visual Studio Code 时，代码错误蜂拥而至，你意识到根本无法工作，你立即感到悲伤，并跑去修复你的 IDE。
以同样的方式对待您的基础设施平台。 如果您了解其中存在问题，并且您无法自行修复，请留下请求。 如果有简单的东西，你自己编辑它，发送拉取请求，人们会考虑它并添加它。 这是开发人员头脑中工程工具的一种略有不同的方法。
基础设施平台确保工件从开发到客户端的转移，并不断提高质量。 IP 是用生产中的代码中发生的一组故事进行编程的。 经过多年的发展，有很多这样的故事，其中一些是独一无二的并且只与您相关 - 它们无法通过谷歌搜索。
此时，基础设施平台就成为您的竞争优势，因为它内置了竞争对手工具中没有的东西。 您的知识产权越深，您在上市时间方面的竞争优势就越大。 出现在这里 供应商锁定问题：你可以拿别人的平台，但是用别人的经验，你不会明白它与你有多大的相关性。 是的，并不是每个公司都能建立像亚马逊这样的平台。 这是一条困难的线，公司的经验与其在市场中的地位相关，并且你不能在那里使用供应商锁定。 这也是值得思考的重要问题。
方案
这是基础架构平台的基本图，它将帮助您在 DevOps 公司中设置所有实践和流程。
让我们看看它由什么组成。
资源编排系统，它为应用程序提供CPU、内存、磁盘等服务。 最重要的是—— 低水平服务：监控、日志记录、CI/CD 引擎、工件存储、基础设施即系统代码。
更高水平的服务：数据库即服务、队列即服务、负载均衡即服务、图像调整大小即服务、大数据工厂即服务。 最重要的是—— 向您的客户提供不断修改的代码的管道.
您会收到有关您的软件如何为客户端工作的信息，对其进行更改，再次提供此代码，接收信息 - 这样您就可以不断开发基础设施平台和您的软件。
在图中，交付管道由许多阶段组成。 但这只是作为示例给出的示意图，无需一一重复。 阶段与服务交互，就好像它们是服务一样——平台的每个砖块都有自己的故事：如何分配资源、如何启动应用程序、如何使用资源、如何监控和更改。
重要的是要了解平台的每个部分都承载着一个故事，并问问自己这块砖块承载着什么故事，也许它应该被扔掉并用第三方服务替换。 例如，是否可以安装 Okmeter 来代替砖块？ 也许这些人在这方面的专业知识已经比我们成熟得多了。 但也许不是——也许我们拥有独特的专业知识，我们需要安装 Prometheus 并进一步开发它。
平台创建
这是一个复杂的沟通过程。 当您有了基本实践后，您就开始在开发需求和标准的不同工程师和专家之间进行沟通，并不断将其更改为不同的工具和方法。 我们在 DevOps 中拥有的文化在这里很重要。
有了文化，一切就变得很简单了—— 这是关于协作和沟通的，即渴望在共同的领域中彼此合作，渴望共同使用一种工具。 这里没有火箭科学——一切都很简单、平庸。 比如我们都住门口，保持干净——这样的文化水平。
你有什么？
再说一遍，你可以问自己一些问题。
基础设施平台是否专用？ 谁负责其发展？ 您了解您的基础设施平台的竞争优势吗？
你需要不断问自己这些问题。 如果有东西可以转移到第三方服务，就应该转移；如果第三方服务开始阻止你的行动，那么你需要在自己内部建立一个系统。
那么，DevOps...
...这是一个复杂的系统，它必须具有：
- 数码产品。
- 开发此数字产品的业务模块。
- 编写代码的产品团队。
- 持续交付实践。
- 平台即服务。
- 基础设施即服务。
- 基础设施即代码。
- DevOps 中内置的维护可靠性的单独实践。
- 描述这一切的反馈实践。
您可以使用此图表，以某种形式突出显示您公司中已有的内容：已开发或仍需要开发。
几周后就会结束 。 作为 RIT++ 的一部分。 参加会议，您会发现许多有关持续交付、基础架构即代码和 DevOps 转型的精彩报告。 ，最后价格截止日期为 20 月 XNUMX 日
来源： habr.com