我们曾经在一家工厂向客户提供了电子文档管理系统。 然后到另一个对象。 还有一个。 还有第四次、第五次。 我们太得意忘形了，以至于我们发现了 10 个分布式对象。 结果非常有力……尤其是当我们要交付更改时。 作为交付到生产电路的一部分，测试系统的 5 个场景最终需要 10 个小时和 6-7 名员工。 这些成本迫使我们尽可能减少交货。 经过三年的运营，我们无法忍受，决定通过一些 DevOps 来为该项目增添趣味。
现在所有测试都在 3 小时内完成，有 3 个人参与：一名工程师和两名测试员。 这些改进以数字明确表达，并导致备受喜爱的 TTM 降低。 根据我们的经验，能够从 DevOps 中受益的客户比了解 DevOps 的客户还要多。 因此，为了让 DevOps 更贴近人们，我们开发了一个简单的构造函数，我们将在这篇文章中更详细地讨论它。
现在让我们更详细地告诉您。 一家能源公司正在 10 个大型设施中部署技术文档管理系统。 如果没有 DevOps，要驾驭这种规模的项目并不容易，因为大量的体力劳动极大地延迟了工作，也降低了质量——所有的体力工作都充满了错误。 另一方面，有些项目只有一个安装，但一切都需要自动、持续且无故障地工作 - 例如，大型整体组织中的相同文档流系统。 否则，有人会手动进行设置，忘记部署说明 - 结果，在生产中设置将丢失，一切都会崩溃。
通常我们通过合同与客户合作，在这种情况下我们的利益略有不同。 客户严格按照预算和技术规格审视项目。 向他解释技术规范中未包含的各种 DevOps 实践的好处可能很困难。 如果他对具有附加业务价值的快速发布感兴趣，或者对构建自动化管道感兴趣怎么办？
遗憾的是，当使用预先批准的成本时，并不总是能找到这种兴趣。 在我们的实践中，曾经有过这样的情况：我们不得不接一个无良且粗心的承包商的开发。 这太糟糕了：没有最新的源代码，同一系统的代码库在不同的安装上是不同的，文档部分缺失，部分质量很差。 当然，客户无法控制源代码、汇编、发布等。
到目前为止，并不是每个人都了解DevOps，但是一旦我们谈论它的优势，谈论真正的资源节省，所有客户的眼睛都亮了。 因此，包含 DevOps 的请求数量随着时间的推移而不断增加。 在这里，为了轻松地与客户说同一种语言，我们需要快速连接业务问题和 DevOps 实践，这将有助于构建合适的开发管道。
因此，我们一方面有一系列问题，另一方面我们有 DevOps 知识、实践和工具。 为什么不把经验分享给大家呢？
创建 DevOps 构造函数
敏捷有自己的宣言。 ITIL有自己的方法论。 DevOps 就没那么幸运了——它还没有获得模板和标准。 虽然 根据对公司发展和运营实践的评估来确定公司的成熟度。
幸运的是，2014年知名公司Gartner 并分析了关键的 DevOps 实践以及它们之间的关系。 基于此，我发布了一个信息图：
我们把它作为我们的基础 。 这四个领域中的每一个领域都有一套工具 - 我们将它们收集到数据库中，确定了最流行的工具，确定了集成点和合适的优化机制。 总共结果是 36 个实践和 115 个工具，其中四分之一是开源或免费软件。 接下来，我们将讨论我们在每个领域取得的成就，并作为示例，讨论如何在创建技术文档管理的项目中实施这一点，我们就是以此开始的。
流程
在臭名昭著的 EDMS 项目中，技术文档管理系统按照相同的方案部署在 10 个对象中。 该安装包括4台服务器：数据库服务器、应用程序服务器、全文索引和内容管理。 在安装过程中，它们在单个节点内运行，并位于设施的数据中心内。 所有对象的基础设施都略有不同，但这不会影响全局交互。
首先，根据DevOps实践，我们在本地自动化基础设施，然后将交付到测试电路，然后交付到客户的产品。 每一个流程都是一步步制定出来的。 环境设置在源代码系统中是固定的，并考虑到分发工具包的编译以进行自动更新。 如果配置发生变化，工程师只需对版本控制系统进行适当的更改 - 然后自动更新就会毫无问题地进行。
由于这种方法，测试过程得到了极大的简化。 此前，该项目的测试人员除了手动更新支架外什么也不做。 现在他们来了，看到一切都在运转，并做更多有用的事情。 每个更新都会自动测试 - 从表面级别到业务场景自动化。 结果作为单独的报告发布在 TestRail 中。
Культура
通过测试设计的例子可以最好地解释连续实验。 测试尚不存在的系统是一项创造性工作。 在编写测试计划时，您需要了解如何正确测试以及遵循哪些分支。 并且还要在时间和预算之间找到平衡，以确定最佳检查次数。 重要的是准确选择必要的测试，考虑用户将如何与系统交互，考虑环境和可能的外部因素。 没有不断的实验是不可能做到的。
现在谈谈互动文化。 此前，有两个对立的方面——工程师和开发人员。 开发商表示： “我们不关心它将如何启动。 你们是工程师，你们很聪明，确保它运行无故障”。 工程师们回复： “你们开发商太粗心了。 让我们更加小心，我们会减少播放您的版本的频率。 因为每次你给我们一个有漏洞的代码时，我们都不清楚如何进行交互。”。 这是一个从 DevOps 角度来看结构不同的文化互动问题。 在这里，工程师和开发人员都是一个团队的一部分，该团队专注于不断变化但同时可靠的软件。
在同一个团队中，专家们决心互相帮助。 和以前一样吗？ 比如，正在准备一些厚厚的部署说明，大概有50页左右，工程师看了，有什么不懂，就骂骂咧咧，凌晨三点就让开发人员评论。 开发商评论了，也骂了——最后没人高兴。 另外，自然会出现一些错误，因为你无法记住说明中的所有内容。 现在，工程师与开发人员一起正在编写用于自动部署应用软件基础设施的脚本。 他们几乎用同一种语言互相交谈。
人
团队的规模由更新的范围决定。 该团队是在交付形成期间招募的；其中包括来自一般项目团队的感兴趣的人员。 然后，与负责每个阶段的人员一起编写更新计划，并在进展过程中团队进行报告。 所有团队成员都是可以互换的。 作为团队的一部分，我们还有一名后备开发人员，但他几乎从不需要连接。
技术
在技术图中，突出显示了一些点，但在它们下面有一堆技术 - 您可以出版一整本书及其描述。 所以我们将突出显示最有趣的内容。
基础架构即代码
现在，这个概念可能不会让任何人感到惊讶，但以前对基础设施的描述还有很多不足之处。 ，测试环境独特，它们被珍惜和珍惜，灰尘颗粒被吹掉了。
如今没有人害怕尝试。 有虚拟机的基本镜像，以及部署环境的现成场景。 所有模板和脚本都存储在版本控制系统中并及时更新。 以前，当需要将包裹运送到展台时，就会出现配置差距。 现在您只需在源代码中添加一行即可。
除了基础设施脚本和管道之外，文档即代码方法也用于文档编制。 因此，可以轻松地将新人员连接到项目，根据测试计划中描述的功能将他们引入系统，并且还可以重用测试用例。
持续交付和监控
关于DevOps，我们讨论了如何选择用于实施持续交付和监控的工具。 通常不需要重写任何东西 - 使用以前编写的脚本、正确构建组件之间的集成并创建通用管理控制台就足够了。 所有流程都可以使用一键或时间表启动。
在英语中有不同的概念，持续交付和持续部署。 两者都可以翻译为“持续交付”，但实际上它们之间还是有细微差别的。 在我们的分布式能源公司的技术文档流项目中，相反，使用交付 - 当根据命令进行生产安装时。 在部署中，安装会自动发生。 该项目中的持续交付通常已成为 DevOps 的核心部分.
一般来说，通过收集某些参数，您可以清楚地了解 DevOps 实践为何有用。 并将这一点传达给真正热爱数字的管理层。 启动总数、脚本阶段的执行时间、成功启动的比例——所有这些都直接影响到每个人最喜欢的上市时间，即从提交到版本控制系统到在平台上发布版本的时间。生产环境。 通过实施必要的工具，工程师通过邮件收到有价值的指标，项目经理可以在仪表板上看到它们。 这样您就可以立即评估新工具的好处。 您可以使用 DevOps 设计器在您的基础设施上尝试它们。
谁需要我们的 ?
我们不要假装：从一开始，他就对我们有用了。 正如我们已经说过的，您需要与客户使用相同的语言，并且在 DevOps 设计师的帮助下，我们可以快速勾画出此类对话的基础。 业务专家将能够自行评估他们的需求，从而更快地发展。 我们试图让设计器尽可能详细，添加大量描述，以便任何用户都能理解他所选择的内容。
设计器的格式允许您考虑公司在构建流程和自动化方面的现有发展。 如果您只能选择与现有流程良好集成并且可以轻松填补空白的解决方案，则无需拆除所有内容并重建它。
也许您的开发已经迈向更高的水平，而我们的工具看起来太“队长”了。 但我们发现它对我们自己有用，并希望它对某些读者有用。 我们提醒您 给设计师 - 如果有的话，您在输入初始数据后立即收到图表。 我们将感谢您的反馈和补充。
来源： habr.com