开发团队可能松散耦合，并且朝着不同的方向工作，他们不知道也不想使用DevOps。 在今天的文章中，我们将讨论如何扭曲和改变DevOps的做法，以便可以在具有悠久的法规，政策和人们习惯的公司中实施它们。



该材料基于2017年 10月DevOops会议的Sergey Berdnikov（金色皇冠）和Artem Kalichkin（CFT）的对话报告。 在剪切下-报告的视频和文本成绩单。




谢尔盖：我是公司运营部门的负责人。 我和阿尔特姆开始了一场小小的革命。 一切始于革命，现在已进入进化阶段。



Artem：该公司自1992年以来一直在金融市场运营。 这项工作包括两个主要部分。 第一部分是软件开发，核心银行业务，银行会计等。 在这里，我们充当供应商：我们开发并向您出售了一个盒子，然后您进行了部署和操作。

第二部分是处理服务。 在这里，我们直接向个人或通过我们的合作伙伴提供服务。 这些是大型交易网络，银行和金融服务市场的其他参与者。 在这里，我们确定了从构思到开发，实施和进一步操作的整个周期。

我们在公司的处理部门与Sergey合作。 关于我们如何在处理过程中使用DevOps来讲述这个故事，我们将告诉您。

那是什么

谢尔盖：我们的遗产完全是银行业务。 该公司最初分别制造银行产品，所有东西都很熟悉：仅SPARC的整个基础架构，自己的数据中心，整个核心都由Oracle编写。 PL / SQL代码，很多东西-扩展不容易。

我们仅垂直缩放：我们购买了一块有力的铁块，一直使用到废旧为止，将其替换为新铁块，然后将旧铁块用于分级。

还用Java写了很多代码。 我们保留了一个温暖的储备：有一个数据中心和整个复制的结构—交换机，服务器，一站式，一站式。



在这里，您可以从流程的角度看到整个结构。 有独立的技术主管开发，然后是防火墙。 接下来是集中式IT，它涉及删除，部署等。 也就是说，开发人员编写了一条大型指令，IT运营分为三个部门：

• 参与部署的应用程序管理员。 他们没有根，机器上有用户，他们可以执行指令-这被称为Monkey代码。
• 能够并且知道如何配置，添加硬件等的Unix管理员。
• 有个别的数据库专家。 由于数据库是我们的主要目标，也是我们长期生存的本质，因此许多过程在那里发生。

Artem：目前还没有DevOps，我们按照规章制度工作，而Sergey不满意。

谢尔盖（Sergey）：我加入了应用程序管理员团队，我记得那是“大好时机”。 我们可以申请三个星期。 一个应用程序出现了，他们发现其中存在某种错误并取消了它，因为他们认为傻瓜自己无法编写应用程序。 正确编写应用程序所需的知识就在我这里。

然后人们一天奔波：“那我们写错了什么？” 我解释说，在没有加减号的地方，他们忘记了逗号。 他们编写了一个应用程序，我提供了一些有关如何在Oracle中工作的专业知识，并将其进一步发送给DBA，那里有经过专门培训的知道如何实现这些应用程序的人员。

他们还与我合作，他们说：“您为什么不在此处指定主要指标，您是否写了分号？” 应用程序被取消，循环重新开始。 现在以这种耻辱，但是在以这种方式工作之前该怎么办。

Artem：然后我们开始改变。 确实有很多应用程序。 当谢尔盖（Sergey）加入我们的团队时，他是一个小小的演变和转变的结果。 我是针对各种类型应用程序的大量法规的作者，因为我不得不以某种方式生存。 总的来说，我们的整个转型不是因为炒作或时尚而发生的，而是因为需要解决特定的问题。

例如，配置更改导致我的战斗中断并且无法正常工作。 我在白天或晚上发现了这一点：碰巧在晚上六点他们滚动了东西，直到早上三点，所有这些都无法正常工作。

有该版本的安装，在此之前没有人去过，也没有讨论如果出了问题该怎么办。 在开始工作前半小时，众所周知的著名的多页安装说明已发送给每个人。 有必要解决一些问题，那时我们找到了解决方案-ITIL流程的自适应实施。

开始战斗后，我们开始检查一切是否正常滚动，服务和主要关键指示器是否正常工作。 在安装版本之前，我们开始约会。 然后，实际上，这是DevOps的开始，当时发送分发工具包的开发团队至少开始与操作团队会面，讨论夜间工作的情况。

Sergey：还有一些要讨论的内容：我们有四页的安装说明-执行命令，执行计划。 没有错误几乎是不可能写的。 我们经常在我们写错，阅读和类似内容的开发之间发誓。 会议有时变成地狱。

Artem：我们尝试将应用程序迁移到Confluence，因为在Word中传输不方便-可能会形成错误。 在Confluence中，他们始终计划上传具有所有更改的当前版本。

我们插入了一段代码来投入战斗。 Confluence咀嚼了元标记，发布了其他不正确的内容，管理员拿走了代码，将其变成面条并开始使用它-这是一场灾难。

我们意识到，不管页面指令多么令人反感，无论如何构架，所有这些都变成了完全废话。

延长夜间停机时间是重要的先决条件，这会导致安装后的起飞质量差，被撞死，以及开发和运营之间存在大量冲突。

• 传递变更时出现很多人为错误；
• 不断寻找罪恶感；
• 新模块的去除率长达3周；
• 单点故障（仅垂直扩展），缺乏平衡；
• 更新期间计划的停机时间为2小时。

转型背景

谢尔盖：有很多变化，我们经常搞砸。 每个星期，我们聚会，被诅咒，镇定下来。 这个过程永远重复着，他们寻找有罪的：“这些都是编写弯曲代码的开发人员，甚至Java模块也无法传输。”

Artem：但是开发人员认为这是基本的事情：日志中的错误掉了出来-对其进行分类，谷歌搜索并了解需要在配置中修复的内容。

谢尔盖：他们还发布了很长时间的新产品。 这只是结构上的关系：他们为我们创建了一个请求，我们必须创建一个请求以在服务器上创建用户，然后创建一个方案。 然后足球开始了应用程序。 开发人员发布了模块，但是我们不能使用它们，我们已经按照规定拥有一切。

另外，我们设置了很长时间。 该说明非常重要，您边阅读边读，大约要花两个小时。 这些动作本身并没有在一秒钟内完成。

Artem：还有一些常规操作，例如30个Java模块。 总而言之，这里有一个配置，您需要在每个配置中进行更改。 首先，您可以发疯进行相同的更改：您讨厌自己和其他人类。 其次，在第25个配置上出错的可能性变得非常高。

谢尔盖（Sergey）：我记得我是如何获得水平扩展的报价的。 我们有150个具有不同配置的模块：如果错误是一个版本的配置，那么它们会给我第二个版本，而我会在其中出错。 毕竟，我们不是机器人。

Artem：计划的2小时停机时间是我们开始寻求解决方案以及如何摆脱困境的关键因素之一。

事实是我们提供金融服务，加工服务。 我们在国外工作。 然后，我们在11个时区工作，在2013年，我们只有一个小时的窗口，当该服务的使用量降至最低时，客户端呼叫的数量已降至最低，平静下来了，并且可以采取一些措施。

有条件的，我们可以从一小时到晚上进行两个小时的工作。 两个小时比这个窗口大得多。 我们正在经历一场灾难，即使不是为了转型，也因为我们现在实际上没有窗户。

对于所有这些问题的答案，我有了一个主意，试图找出什么是DevOps。

那时，我们的同事来了HighLoad，当时我忙于CMBD的实施，因为我需要确保配置不会中断，并且至少可以管理一些东西。 他听了Sasha Titov的报道，他谈到了一些厨师。 好像也是配置管理

在2013年，我阅读了有关它的所有内容，并决定不再需要一些垃圾。 我需要控制，他们迫使代码写在那里。 但是，情况并没有改变，问题不断累积，我强迫自己坐在家里开始整理事情。 我以为这是某种救赎。

然后，我发现我们应该具有相同的环境，相同的推出和更新脚本的假设和值，我们应该从测试环境开始检查这些方案。

有机会最小化说明和手动操作，并尽可能地使所有操作自动化，而不仅仅是使用不同的bash脚本，否则另一位管理员稍后会摔断腿。

那时我想到了这个想法，并首次声明了我想要得到的东西。 这是2013年的文件，这是公司针对DevOps创建的第一份文件。

谢尔盖：这是一个关键思想：降低新模块的拆卸速度，减少拆卸过程中出现的错误数量。 也就是说，在新版本的发布的第一阶段我们要实现一些特定的目标。



有很多反对的说法。 例如，担心自动化会破坏一切：它难以理解地起作用，很难执行别人的代码，这是一项很棒的服务，人们通过我们获利。 不严重

接下来加入警卫队。 他们全程走过我们：某种相同的阶段！ 他们对世界有完美的印象：在闪存驱动器上，传输版本，我们将使用PGP密钥对其进行签名，一切都会好起来-完美的服务。 我们与他们合作了很长时间才走到尽头，这仅归功于我们开展了一些项目活动。

Artem：这里我们从价值观出发：这是我们赔钱的地方，这个简单的做法是不可接受的。

伙计们和我想出了一种减少这些损失的方法。 您有更好的选择吗？ 如果不是，请保持安静；如果是，请批评并提出。 没有提供什么？ 然后我们尝试。

有一个说服和强迫的过程：我们建议在数量有限的系统上使用我们的想法。

Sergey：我们被要求写出所有风险，以及如何释放风险。 必须与可能亏钱的人进行协调。 另外，程序员说：“我们编写了某种代码，我们通常用于传输zip，编写了指令，并编写了其他一些代码以便删除？！”

Artem： “我编写业务逻辑应用程序代码，我使用框架来减少代码中不必要的部分。 然后您要求编写更多代码。 接受和退出，最后”-此类对话才刚刚开始。 然而，所有这些通过示威和信仰逐渐得以实现。



Sergey：在第一次迭代中，我们就公司的结构和技术做出了许多重要的决定。 首先，我们实施了配置管理。 这免除了我们用10张A4页进行错误配置的麻烦。

然后，业务开始下沉，应用程序管理员移至开发人员的技术主管。 它给人一种指挥的感觉，一种肘部的感觉。 我们开始了解到，我们正在制造产品，而不是出于拒绝它们的愿望而无法满足那些难以理解的应用程序的制定，这是有特定目标的。

当您坐在人们旁边，何时看到他们的工作方式，何时他们看到我们的工作方式，团队合作就会凝聚在一起。 我们甚至在团队之间进行了对话：这是真正的DevOps的第一个火花。 没有技术，没有新技术。 从技术的角度来看，我们认为在另一个世界中，什么也不会扎根，我们的工作方式也不同。

第一个想法是自己编写配置管理，有很多开发人员。 然后我们想起了自己写的所有东西，然后拒绝了-我们所有人都感到痛苦。

Artem：我会纠正我的同事的。 谢尔盖错了：我们自己编写的所有内容都在我们强大的应用领域中完美地发挥了作用。 当他们试图编写一些蜘蛛图以自动构建CMDB或某种自行编写的监视系统来控制业务逻辑时-是的，这里出现了另一类系统。

在这一阶段，事实证明，应用程序管理员已从IT部门移至我们的技术部门。 正如谢尔盖（Sergey）所说，他们开始感受到所有的商业价值，这主要归功于商业利益。

我们有机会向他们支付成就奖金，这非常有动力。 当他们开始对话时，模块的删除从三周减少到一周或更长时间，即使没有任何深度自动化也取得了一些进展。



Sergey：目前，如果我们对应用程序不了解，我们会要求开发人员提出：“让我们共同决定并写出应用程序的发音”。

Artem：在这种有条件的命令结构上，我们开始进入技术领域。

Sergey：现在我们将告诉您我们如何选择系统。 这很有趣。 首先，我们尝试厨师的原因很简单-我们认识一位认识厨师的大师。 然后我们尝试使用Puppet，因为那时Oracle宣布了对Puppet的支持。

Ansible也尝试过，但是两个团队都不喜欢它作为系统。 还有一些安全问题：2013年的Ansible与当前的有很大不同。

我们并行启动了两个具有相同功能的不同项目。 一切工作都很棒，感觉这里有些问题，应该独自一人处理。 我们如何选择？

Artem：程序员在Chef上撰写，管理员在Puppet上撰写。 我们的想法就是尝试，然后比较哪些地方更好，然后选择。 但是当我们组装时，最终时间过去了，二元性开始产生问题，因为代码量在增长，它还在不断增长，并且每个人都喜欢，开发人员编写并自动化。

我聚集了所有人，问我们会写些什么。 程序员说：“我们真的很喜欢厨师。” 和管理员：“还有我们在Puppet上！”。 那是完整的罐子。 我比较并了解，在当前环境和当前参数下，没有客观的方法来选择该产品或该产品。

结果，正如他们在我国所说的那样，我进行了可预测的选举。 参与者之间的某种“封闭式”投票。 但是没有伪造，对大脑有条件的影响，因此选择了木偶。 我决定比被冒犯的管理员更快地使被冒犯的开发人员平静下来。 根本没有其他选择标准。

谢尔盖：那一刻，我们思考了很长时间，如何提出二元论。 在幻灯片上，您可以看到来自董事会和会议的照片。 我们决定您需要使用某种包装系统，而不是您的自行车。 再次赢得了头脑。

实际上，我们选择的不是RPM，而是IPS-Solaris软件包管理器。 我们将自己从第11版导入了前十名，并开始使用它。 最正确的决定是拒绝当时手写的bash拐杖和拉链。

Artem：这就是为什么它仍然很重要的原因：在配方中，结果以版本号更改的形式出现，它从存储库中延伸的越来越远，因此变得很有必要。

当我们到达培训DevOps，Chef的所有这些事情时，我们想到：“现在他们会告诉我们如何传输二进制文件”，但是他们什么也没告诉我们。 答案通常是：“每个人都以自己的方式做出决定，并尽自己所能。” 因此，他们意识到业界对此的反应是“ 42”，就像《宇宙漫游者指南》中对宇宙主要问题的回答。

谢尔盖：关于如何制作CI / CD，它的含义，我们也进行了长时间的辩论。 像配置管理一样，一个实用程序也可以使用并交付。 他们争论了很长时间，这里有很多选择和选择，开发人员创建了自己的系统，在操作中我们为删除提供了自己的系统。

当时，我们意识到还没有完美的解决方案。 只要采取我们所获得并忍受的一切。 开发人员拥有自己的组装系统，我们自己交付。 没有完美的选择，并且仍然以不同的方式与不同的团队合作。 没有理想。

我们还有一个很大的堆栈，我们的大多数代码都嵌入数据库中：所有财务处理，不幸的是，其中的范例是“越接近数据，它就越快”。 福勒同意甲骨文出售。 金融交易挂在PS / SQL中，我们没有找到任何有助于解决版本控制和交付问题的开源产品。 也许他是，但我们开始编写自己的乐器。

Artem：实际上，我们有一个大问题，因为正如在初始幻灯片中所述，Production是一个大型的垂直服务器。 因此，将相同的大型垂直服务器提升到Stage十分昂贵且非常困难。 这还不错。

事实是，我们需要提供一个性能近似的环境，并用数量相似且基数同样重要的数据填充该环境，以便我们的阶段测试正确通过。

这是非常困难的决定。 首先，我们在缩放方面做了什么-我们意识到我们无法在舞台上提供与战斗中相同的垂直载具。但是我们可以在X时刻在Stage环境中固定系统性能请求的参考指标，并在推出新软件包时进行比较。如果它们开始发生异常变化，则意味着某些东西漂浮在我们内部，并且某些东西没有发生错误。这是一个问题。

然后，我们发现了将数据从战斗转移到舞台以便用相同数量的数据填充的问题。不能根据文档访问客户数据的人都不可能访问它。

我们无权将客户的个人数据和银行机密信息注入Stage。为了传输这些数据，我编写了数据混淆脚本，以使它们无法恢复并且无法与真实脚本进行比较。同时，重要的是不可能用aaa bbb替换所有名称，因为我们正在丢失数据基数，并且我们在Stage上进行的所有检查都显示不正确的信息。

因此，我们还编写了此脚本，目的是为这些文本数据生成一些有条件的随机基数，以便我们的请求可以显示与战斗相当的画面，并且我们可以理解这些变化。

我们正在远离绝对的绩效状态，我们正在观察变化。与以前的版本相比，情况没有恶化，我们认为该版本的性能还不错。



这是第二次迭代。这里的关键词很可能是项目到此为止。没有DevOps项目。这里最初是内部客户-我。我得到了我的结果：减少了指令，减少了版本发布过程中的错误，战斗配置开始更改，通过Puppet进行管理，从而变得受控，清晰。我想要的就是我得到的。

谢尔盖：您提交的内容有一些细微的变化。责任再次从集中式IT转移到技术局。

它成为了扎根的成熟OPS。实际上，这有助于完成删除新模块方面的任务。我们开始提高模块的速度，三周后在短短三天内执行对我们来说似乎很理想。结果是切实的：有了动力，团队开始就如何以及如何进行改进产生想法。



从相关部门的角度来看，我们做了什么：我们有200多人的团队，150个开发人员，6个OPS。护送人员很多。首先-已经认识到不需要进行最理想的应用。他们开始尝试以下方法：如果一个人有机会做某件事而不创建应用程序，那么每个人都很好。而且它的完成速度非常快。

Artyom：这是一个示例，我们通过git报价。经理本人进来并提出要约。

Sergey：我们发现了Gitlab之类的工具，我们喜欢一个人可以使用图形界面来工作。有一个“下载”按钮，用户甚至可能不了解提交实际执行的操作。

同时，我们根据安全小组发布的规则编写了脚本来检查内容，例如pdf是pdf，检查文件大小以及其他逻辑。人们有机会在不创建应用程序的情况下更新这些文档。操作的负载已减少。

另一个困难是如何计算这样的时刻。在例行程序中，尚不清楚如何查找问题区域。因此，我们想出了自己的秤，称其为“ J狼”。

我们受到了旧照片的启发。我们认为我们为每个执行的应用程序分配了of狼的数量，它的无聊程度，而且我们不想这样做。在月底，他们考虑了jack狼得分最高的应用。

他们作为一个整体坐下来，思考如何摆脱这种耻辱。如何使不必为此创建应用程序，这很酷，并驱使人们前进。

在下一个阶段，我们找到了自动化方法，那就是机器人。我们掌握了Telegram API，开始为所有人，尤其是我们自己，减少机器人的数量。我们总结了最后的触发因素。



商业喜欢它：在某些情况下，当某物在撒谎时，每个人都开始打电话询问发生的事情。这样，一个人可以接听电话，选择“事件”命令并阅读最新的事件。人们开始更详细地处理事件，因此没人会打电话或询问。

然后，我们开始编写其他功能，以获取以前在Jira中用作查询的信息。企业想知道转移是否完成：输入数字，得到结果。就应用而言，这也极大地促进了生活。

Artyom：同时，我们在谢尔盖（Sergey）部门进行了另一项组织转型，但已经在本地进行。然后，我们对值班工程师的想法非常感动，而且由于谢尔盖（Sergey），我们得以在部门中建立此计划。有一名坐着的工程师处理事件，有一名坐着的工程师处理应用程序，其余的全部销毁了als狼，都在进行射击。

与DEV合作

谢尔盖：部队开始做的事情：重新安排出现了，人们不仅从事jack狼活动，还从事其他事务。首先，我们与发展进行了对话。我们告诉新团队，DevOps是什么，如何正确做饭，教会了CM。

从我们自己编写配方开始，到他们学会了对其进行编辑，然后自己编写，我们已经走了很长一段路。我们还将讨论CI，帮助建立管道并收集软件包。我们帮助建立安全的开发环境。

Artem：从CI的角度来看，这都是非常重要的。同时，我担任产品负责人，领导项目和领导开发团队。这是一个非常有趣的案例。

在小型团队中，我们将操作功能（即Stage和Prod）合并在一个单元中。在这些小型项目，小型产品，团队和基础架构上，这非常方便。您将了解如何进行战斗。

谢尔盖（Sergey）：当战斗工程师设置测试环境时，他会一对一地进行测试，因为她知道她稍后会来找他，他会因此而受苦。这是一个无法摆脱的重要心理因素，最好一次又正常地做所有事情。



这是怎么回事？在这里，许多人说没有DevOps部门，我们相信我们有一个DevOps部门。该部门的主要任务是什么？

他走路，推销和谈论DevOps。每个人都知道它是什么以及如何烹饪。他们讲述并展示了如何在五分钟内推出带有数据库的新产品。

我们唯一的限制是安全性，方案的协调。当我们有一个虚拟机并同意了方案时，那么一切将花费五分钟。一切都会完全自动滚动。

Artem： 8月，我在战斗中推出了一种新产品，即全新产品时，我们每天推出15-20个版本，而不会产生冲突和紧张。这里有一种价值感：当您静下来安顿下来并准备下一个时，这很酷。



谢尔盖：我将谈论痛苦。我们从头开始支持DRP恢复计划。当没有自动化时，我们几乎复制了那里的配置。不断添加新模块，并且计划需要不断更新。随着DevOps和自动化技术的到来，该计划逐渐缩水：我们采用了最新的Git版本并为其添加了计划。

这个部署计划正变得诚实。测试部署运行对此提供了支持。我们会进行试运行，而在战斗中我们会切换到预备队。整个例行故事都消失了。顺便说一下，这帮助我们稍微移动了堆栈。

我们曾经使用SPARC Solaris，现在出现x86的原因很简单：今天，没有人为Sparc编写或测试时髦的应用程序。例如，我们使用Haproxy，与开发人员一起，我们看到了针对Solaris的错误修复。它困扰着我们，我不想再忍受它了。我们选择了一个平台，每个人都可以在此平台上测试产品，现在我们可以正常地对其进行开发。这也使我们加快了整个过程。

Artem：这通常打开了通往充满奇迹的新世界的大门。因为x86的出现使我们能够将真正相关且有用的实用程序用于我们的任务。而且，当我们获得这个机会时，我们同时转向集群。

实际上，除中央处理和核处理外，现在所有事物都聚集在一起并且可以与我们正常工作。我们不用担心：没有停机时间，或者即使没有群集，最长也要花费一分钟。

他唯一住的地方是至少迁移了两个小时，这是中央处理方案的迁移。现在需要八分钟。



谢尔盖：幻灯片上是一个新文档，是一个单行应用程序：在git中合并。不再有那十张A4纸。

部署新模块最多需要三个小时。当您需要在Oracle中执行某些操作（例如，获取虚拟机）时，会遇到一些困难的情况。偏移消失了。我不记得有人传错了什么。当然，有一些粗糙度，但是它们都很小，无聊，可以很快地校正。



是什么让我们取得成功？首先，我们没有从现在开始发动革命。我没有说：“我们需要在三周内实施DevOps。”我们有条不紊地处理了这个过程，激动了很长时间，告诉人们，全神贯注地谈论了我们要实现的目标。

阿尔特姆（Artem）：我避免了当局的提问：“阿尔特姆（Artem），什么时候是DevOps？”他说不会有最后期限，我们在Prod中尝试，不问任何问题。

谢尔盖：另一方面，一切也都很酷。我们并未将所使用的技术强加于所有单元。邻居们看着这家公司很大，他们说：“是的，很好，但是我们每六个月就会部署一次。”他们不需要它。我们不会走路，也不会告诉我们我们拥有唯一正确的决定。在某些我们不想使用堆栈的地方，我们为它们组装了简单的bash脚本，该脚本可与其他命令集成。

Artem：在这里，我坚信不能强迫高层实施DevOps。对于这样的项目，这是不现实的。



Sergey：我们分析了大部分时间浪费在哪里：今天，我们在安全方面损失了大部分时间。

我们知道如何快速工作，快速部署，但是同意部署方案-这真是太糟糕了。现在我们来看一下它，当Dev和Ops的部门完全不同时，它会让人想起同一件事。现在我们还没有一个计划，我们正在考虑如何在我们的流程中包括安全性，以便他们可以分析更改。

Artem：例如，您可以使用“合并”，查看配方中发生了什么变化。保安员也是工程师。

谢尔盖：通常，我们的正式流程无法提供真正的安全性。当我们进行审核时，我们了解所有程序均已通过，但我们尚未获得所需的安全级别，并且已花费大量时间和资源。我们经常发现由于安全流程和CI / CD集成不良而发生的一些问题。

从OPS的角度来看，我们仍然存在浪费时间在CI和调整配方上的问题。这东西已经开始变得“​​ jack狼”。因此，我们着眼于为开发人员提供框架的系统，着眼于Docker，Kubernetes，以便我们可以这样写：“伙计，有工具，没有大文件，您可以统一交付过程。”

我们想提出这个想法，但是安全再次遭到了抵制。他们说：“您拥有什么样的虚拟网络，这些服务在没有防火墙的情况下将如何发展？”有一些矛盾，但是，我认为我们还是会赢。

Artem：我有自己的痛苦，我想解决。我们有一个很大的问题：我们是一家公司，而且我们不是唯一一家这样的公司，有些代表处在同一情况下。我们在监管机构的不断控制下，中央银行不断进行审计。我们通过审核，显然是独立审核。

很难责怪审核员，他是根据标准规定工作的，该标准规定物理硬件应为单独的非虚拟机。没有容器。

目前，还没有一个国际标准将一项新技术推向了新的高度。有一个黑洞。他们没有注意到这是一个大问题。我不能怪审计师，他们是按照标准进行审计的。他们无处可取，但是没有一个标准在这种意义上试图改变，转变并发展。

我需要弄清楚如何用这些可怕的话来描绘公司的现状，以便一切都是正确和诚实的。

如果您厌倦了长时间阅读，我们建议与我们的朋友Baruch Sadogursky和Vyacheslav Kuznetsov一起收听“五分钟PHP”播客的发布 。 DORA的趋势DevOps，DecSecOps，Kubernetes胜利和DevOps状态报告2018。

如果您想获得更酷的报告，请参加DevOops 2018大会，其中有Baruch，Glory甚至John Willis ！ 所有发言人和节目均在现场 。

一个不错的奖励：直到10月1日，可以以折扣价预订 2018 DevOops 的门票 。