🥇基础设施即代码：如何使用 XP 克服问题

你好，哈布尔！之前，我抱怨过基础设施即代码范式的生活，并且没有提供任何解决当前情况的方法。今天我回来告诉大家，有哪些方法和做法可以帮助你摆脱绝望的深渊，引导事态向正确的方向发展。

在前面的文章 “基础设施即代码：初识” 我分享了我对这个领域的印象，试图反思这个领域的现状，甚至建议所有开发人员都知道的标准实践可以有所帮助。看似对生活有很多抱怨，却没有提出摆脱现状的出路。

我们是谁，我们在哪里，我们有什么问题

我们目前属于 Sre Onboarding 团队，该团队由六名程序员和三名基础设施工程师组成。我们都在尝试编写基础设施即代码（IaC）。我们这样做是因为我们基本上知道如何编写代码并且拥有“高于平均水平”的开发人员的历史。

我们有一系列的优势：一定的背景、实践知识、编写代码的能力、学习新事物的愿望。
还有一个下垂的部分，这也是一个缺点：缺乏对基础设施硬件的了解。

我们在 IaC 中使用的技术堆栈。

用于创建资源的 Terraform。
用于组装图像的打包器。这些是 Windows、CentOS 7 映像。
Jsonnet 在 Drone.io 中进行强大的构建，以及生成 Packer json 和我们的 terraform 模块。
Azure上。
准备图像时 Ansible。
用于辅助服务和配置脚本的 Python。
所有这一切都在 VSCode 中进行，并在团队成员之间共享插件。

我的结论上一篇是这样的：我试图灌输（首先是我自己）乐观主义，我想说我们将尝试我们已知的方法和实践，以应对该领域存在的困难和复杂性。

我们目前正在努力解决以下 IaC 问题：

代码开发工具和手段不完善。
部署缓慢。基础设施是现实世界的一部分，而且速度可能很慢。
缺乏方法和实践。
我们是新人，了解不多。

极限编程 (XP) 来救援

所有开发人员都熟悉极限编程 (XP) 及其背后的实践。我们中的许多人都采用过这种方法，并且取得了成功。那么为什么不使用其中规定的原则和实践来克服基础设施挑战呢？我们决定采用这种方法，看看会发生什么。

检查 XP 方法对您所在行业的适用性下面描述了 XP 非常适合的环境，以及它与我们的关系：

1. 动态变化的软件需求。我们很清楚最终目标是什么。但细节可能有所不同。我们自己决定需要在哪里打车，因此要求会定期变化（主要是我们自己）。如果我们以 SRE 团队为例，它本身负责自动化，并且本身限制了需求和工作范围，那么这一点就很合适。

2、采用新技术的固定时间项目带来的风险。当我们使用一些我们不知道的东西时，可能会遇到风险。这就是我们 100% 的情况。我们的整个项目使用了我们并不完全熟悉的技术。一般来说，这是一个持续存在的问题，因为...... 基础设施领域不断涌现出许多新技术。

3,4. 规模较小、位于同一地点的扩展开发团队。您使用的自动化技术允许进行单元和功能测试。这两点不太适合我们。首先我们不是一个协调的团队，其次我们有九个人，也算是一个大团队了。不过，根据“大型”团队的一些定义，很多人都是 14 人以上。

让我们看看一些 XP 实践以及它们如何影响反馈的速度和质量。

XP反馈环原理

在我看来，反馈就是问题的答案，我做的事情正确吗？我们会去那里吗？ XP对此有一个神圣的方案：时间反馈循环。有趣的是，我们的位置越低，我们就能越快地让操作系统回答必要的问题。

这是一个相当有趣的讨论话题，在我们的IT行业中，可以快速获得一个操作系统。想象一下，一个项目做了六个月才发现一开始就有错误，这是多么痛苦的事情。这种情况发生在复杂系统的设计和任何构建中。

就我们的 IaC 而言，反馈对我们很有帮助。我马上对上图做一个小调整：发布计划没有每月的周期，而是一天发生几次。我们将更详细地了解一些与此操作系统周期相关的实践。

重要提示：反馈可以解决上述所有问题。结合XP实践，可以将你从绝望的深渊中拉出来。

如何将自己从绝望的深渊中拉出来：三个练习

测试

XP 反馈循环中两次提到了测试。不只是这样。它们对于整个极限编程技术极其重要。

假设您进行了单元测试和验收测试。有些会在几分钟内给你反馈，有些会在几天内给你反馈，所以他们需要更长的时间来写，并且很少被审阅。

有一个经典的测试金字塔，它表明应该有更多的测试。

这个框架如何应用于我们的 IaC 项目？事实上……一点也不。

单元测试虽然应该很多，但也不能太多。或者他们正在非常间接地测试某些东西。事实上，我们可以说我们根本不写它们。但以下是我们能够进行的此类测试的一些应用：
1. 测试 jsonnet 代码。例如，这是我们的无人机组装流水线，相当复杂。 jsonnet 代码已被测试很好地覆盖。
  我们用这个 Jsonnet 的单元测试框架.
2. 测试资源启动时执行的脚本。脚本是用 Python 编写的，因此可以对其进行测试。
有可能在测试中检查配置，但我们不这样做。还可以通过配置检查资源配置规则特弗林特。然而，那里的检查对于 terraform 来说太基础了，但许多测试脚本是为 AWS 编写的。而且我们使用的是 Azure，所以这又不适用。
组件集成测试：这取决于您如何对它们进行分类以及将它们放在哪里。但它们基本上有效。
这就是集成测试的样子。

这是在 Drone CI 中构建图像时的示例。要到达它们，您必须等待 30 分钟，让 Packer 图像形成，然后再等待 15 分钟，让它们通过。但它们确实存在！

图像验证算法
1. Packer首先必须准备好镜像。
2. 在测试旁边有一个具有本地状态的 terraform，我们用它来部署此映像。
3. 展开时，附近有一个小模块，可以更轻松地处理图像。
4. 从映像部署 VM 后，即可开始检查。基本上，检查是用汽车进行的。它检查脚本在启动时如何工作以及守护进程如何工作。为此，我们通过 ssh 或 winrm 登录新启动的计算机并检查配置状态或服务是否已启动。
这种情况与 terraform 模块中的集成测试类似。这是一个简短的表格，解释了此类测试的特征。

管道反馈时间约为 40 分钟。一切都会发生很长时间。它可以用于回归，但对于新的开发来说通常是不现实的。如果你对此准备得非常非常充分，准备运行脚本，那么你可以将其减少到 10 分钟。但这些仍然不是 5 秒内完成 100 条的单元测试。

组装图像或 terraform 模块时缺乏单元测试，鼓励将工作转移到可以简单地通过 REST 运行的单独服务或 Python 脚本。

例如，我们需要确保当虚拟机启动时，它会在服务中注册自己规模FT，当虚拟机被销毁时，它会自行删除。

由于我们将 ScaleFT 作为一项服务，因此我们被迫通过 API 来使用它。那里写着一个包装纸，你可以拉出它并说：“进去删除这个那个。” 它存储所有必要的设置和访问。

我们已经可以为此编写正常的测试，因为它与普通软件没有什么不同：某种 apiha 被模拟，你拉它，看看会发生什么。

测试结果：单元测试应该在一分钟内给出操作系统，但没有给出。金字塔高层的测试类型是有效的，但只能覆盖部分问题。

结对编程

测试当然是好的。你可以写很多，它们可以有不同的类型。他们将按照自己的水平工作并向我们提供反馈。但糟糕的单元测试（提供最快的操作系统）的问题仍然存在。与此同时，我仍然想要一个快速且易于使用的操作系统。更不用说最终解决方案的质量了。幸运的是，有些技术可以提供比单元测试更快的反馈。这就是结对编程。

编写代码时，您希望尽快获得有关其质量的反馈。是的，你可以在功能分支中编写所有内容（以免破坏任何人的任何东西），在 Github 中发出拉取请求，将其分配给意见有分量的人，然后等待响应。

但你可以等很长时间。人们都很忙，即使有答案，也可能不是最高质量的。假设答案立即出现，审稿人立即理解了整个想法，但答案仍然迟到，在事实之后。我希望早一点。这就是结对编程的目标——在撰写本文时立即进行。

以下是结对编程风格及其在 IaC 工作中的适用性：

1.经典，经验+经验，定时轮班。 两个角色——驾驶员和领航员。两个人。他们使用相同的代码，并在一定的预定时间后切换角色。

让我们考虑一下我们的问题与风格的兼容性：

问题：代码开发的工具和工具不完善。
负面影响：开发需要更长的时间，我们放慢速度，失去工作的节奏/节奏。
我们如何战斗：我们使用不同的工具、通用的 IDE，并且还学习快捷方式。
问题：部署缓慢。
负面影响：增加创建工作代码所需的时间。我们在等待的过程中感到无聊，在等待的过程中我们伸出双手去做其他的事情。
我们如何战斗：我们没有克服它。
问题：缺乏方法和实践。
负面影响：不知道如何做好、如何做好。延长反馈的接收时间。
我们如何战斗：结对工作中相互交换意见和做法几乎可以解决问题。

在 IaC 中使用这种风格的主要问题是工作节奏不均匀。在传统的软件开发中，你的动作非常统一。你可以花10分钟写N。花2分钟写15N，3分钟写30N。在这里你可以花五分钟写下N，然后再花XNUMX分钟写下N的十分之一。在这里你什么都不知道，你被卡住了，愚蠢的。调查需要时间并且会分散编程本身的注意力。

结论：它的纯粹形式不适合我们。

2.乒乓球。这种方法涉及一个人编写测试，另一个人执行测试。 考虑到单元测试一切都很复杂，而且你必须编写一个需要很长时间编程的集成测试，所有乒乓球的轻松感都消失了。

我可以说，我们尝试将设计测试脚本和实现代码的职责分开。剧本是由一位参与者提出的，这部分工作是他负责的，他有最终决定权。另一个负责实施。效果很好。采用这种方法的脚本质量会提高。

结论：唉，工作节奏不允许在 IaC 中使用乒乓球作为结对编程练习。

3.风格强烈。 练习困难。这个想法是，一个参与者成为指令导航者，第二个参与者扮演执行驱动者的角色。在这种情况下，决策权完全属于导航员。驱动程序仅打印并且可以通过单词影响正在发生的事情。角色很长一段时间不会改变。

适合学习，但需要很强的软技能。这就是我们动摇的地方。这项技术很困难。这甚至与基础设施无关。

结论：它有可能被使用，我们不会放弃尝试。

4. 围攻、蜂拥而至以及所有已知但未列出的风格 我们不考虑它，因为我们还没有尝试过，也不可能在我们的工作中谈论它。

使用结对编程的一般结果：

我们的工作节奏参差不齐，这令人困惑。

我们遇到了软技能不够好的问题。而这个学科领域无助于克服我们的这些缺点。

长时间的测试和工具问题使得配对开发变得困难。

5. 尽管如此，还是取得了成功。我们提出了自己的方法“收敛-发散”。 我将简要描述它是如何工作的。

我们有几天（不到一周）的永久合作伙伴。我们一起做一项任务。我们坐在一起一会儿：一个人写作，另一个人坐下来观看支持团队的工作。然后我们分散一段时间，各自做一些独立的事情，然后我们又聚在一起，很快同步，一起做一些事情，然后又分散。

规划与沟通

解决操作系统问题的最后一个实践块是任务本身的工作组织。这还包括结对工作之外的经验交流。我们来看看三个实践：

1. 通过目标树实现目标。 我们通过一棵无限延伸到未来的树来组织项目的整体管理。从技术上讲，跟踪是在 Miro 中完成的。有一个任务 - 这是一个中间目标。从中可以得出较小的目标或任务组。任务本身来自于他们。所有任务均在此板上创建和维护。

该方案还提供反馈，当我们在集会上同步时，每天都会发生一次。在每个人面前有一个共同的计划，但结构化且完全开放，可以让每个人都知道正在发生的事情以及我们取得了多大进展。

视觉视觉任务的优点：

因果关系。每项任务都会导致一些全局目标。任务被分为更小的目标。基础设施领域本身就具有很强的技术性。并不总是立即清楚具体的影响，例如，编写有关迁移到另一个 nginx 的操作手册对业务有何影响。将目标卡放在附近会更清晰。

因果关系是问题的一个重要属性。它直接回答了这个问题：“我做的事情正确吗？”
并行性。我们有九个人，从身体上来说根本不可能让每个人都完成一项任务。一个领域的任务也可能并不总是足够的。我们被迫在小型工作组之间并行工作。与此同时，各小组会在自己的任务上停留一段时间，他们可以得到其他人的加强。有时人们会脱离这个工作组。有人去度假，有人为 DevOps 会议做报告，有人写一篇关于 Habr 的文章。了解哪些目标和任务可以并行完成变得非常重要。

2. 更换早会主持人。 在站立会议中，我们遇到了这个问题——人们同时执行许多任务。有时任务之间的联系松散，无法了解谁在做什么。另一位团队成员的意见非常重要。这是可以改变问题解决过程的附加信息。当然，通常有人陪伴您，但建议和提示总是有用的。

为了改善这种情况，我们采用了“改变领先站立”技术。现在它们按照一定的列表轮换，这就有了它的效果。当轮到你时，你必须深入了解正在发生的事情，以便召开一次良好的 Scrum 会议。

3.内部演示。 通过结对编程帮助解决问题、问题树可视化以及在早上的 scrum 会议上提供帮助都是不错的，但并不理想。作为夫妻，你们只受你们知识的限制。任务树有助于全局了解谁在做什么。上午会议上的演讲者和同事不会深入探讨你的问题。他们肯定可能会错过一些东西。

解决方案是通过向彼此展示所做的工作然后进行讨论来找到的。我们每周会面一次，每次一小时，展示我们过去一周完成的任务的解决方案的详细信息。

在演示过程中，需要揭示任务的细节，并一定要演示其操作。

该报告可以使用清单进行。1.进入上下文。任务从何而来，为什么有必要？

2、之前这个问题是怎么解决的？例如，需要大量点击鼠标，或者根本无法执行任何操作。

3.我们如何改进它。例如：“看，现在有 scriptosik，这是自述文件。”

4. 展示它是如何工作的。建议直接实现一些用户场景。我想要 X，我做 Y，我看到 Y（或 Z）。例如，我部署 NGINX，检查 url，然后得到 200 OK。如果动作较长，请提前准备好，以便稍后展示。如果它很脆弱，建议在演示前一小时不要对其进行太多破坏。

5. 解释问题是如何成功解决的，还有哪些困难，哪些尚未完成，未来可以改进哪些。比如现在有CLI，那么CI就会完全自动化。

建议每位发言者的发言时间控制在 5 至 10 分钟。如果您的演讲显然很重要并且需要更长的时间，请提前在 sre-takeover 渠道中进行协调。

面对面的部分之后总是会在帖子中进行讨论。这是我们需要的任务反馈出现的地方。

因此，进行了一项调查以确定正在发生的事情的有用性。这是对演讲本质和任务重要性的反馈。

长结论和下一步

文章的基调似乎有些悲观。这是错误的。两个较低级别的反馈，即测试和结对编程，起作用。不像传统开发那样完美，但也有积极的效果。

当前形式的测试仅提供部分代码覆盖率。许多配置功能最终都未经测试。他们在编写代码时对实际工作的影响很小。然而，集成测试有一定的作用，它们可以让你无所畏惧地进行重构。这是一项伟大的成就。此外，随着重点转向高级语言（我们有 python、go）开发，问题就消失了。而且您不需要对“粘合剂”进行大量检查；一般集成检查就足够了。

结对工作更多地取决于特定的人。有任务因素和我们的软技能。对于某些人来说，效果很好，而对于另一些人来说，效果则更糟。这肯定有好处。显然，即使没有充分遵守结对工作的规则，一起执行任务这一事实也会对结果的质量产生积极的影响。就我个人而言，我发现结对工作更容易、更愉快。

影响操作系统的更高级别的方法 - 规划和处理任务精确地产生效果：高质量的知识交换和提高的开发质量。

一行简短的结论

HR从业者在IaC中工作，但效率较低。
加强有效的措施。
提出你自己的补偿机制和做法。

来源： habr.com

基础设施即代码：如何使用 XP 克服问题