基础架构即代码：如何克服XP的问题

哈Ha！ 以前，我抱怨基础架构中的生命是代码范式，但没有提供任何解决方案。 今天，我再次告诉您，什么方法和做法将有助于摆脱绝望的深渊，并使局势走上正确的轨道。



在上一篇文章“将基础结构作为代码：第一次相识”中，我分享了我对该领域的印象，试图反思该领域的当前状况，甚至建议所有开发人员都知道的标准实践可以提供帮助。 似乎有很多关于生活的抱怨，但是没有提出摆脱这种情况的建议。

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

我们现在在Sre Onboarding团队中，该团队由六名程序员和三名基础架构工程师组成。 我们都试图将基础架构编写为代码（IaC）。 我们之所以这样做，是因为原则上我们能够编写代码，并且在历史上我们是“高于平均水平”级别的开发人员。

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

我上一篇文章的结论是：我试图激发乐观情绪（主要是对我自己），我想说的是，我们将尝试我们已知的方法和实践，以解决这一领域中存在的困难和困难。

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

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

极限编程（XP）可以解救

所有开发人员都熟悉极限编程（XP）及其背后的实践。 我们许多人都在研究这种方法，并且成功了。 那么，为什么不利用那里制定的原则和实践来克服基础架构的困难呢？ 我们决定采用这种方法，看看会发生什么。


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

XP反馈回路原理

以我的理解，反馈是对问题的答案，我做得对吗，我们要去那里吗？ 在XP中，这方面有一个很棒的小方案：时间反馈循环。 有趣的是，我们越低，我们就能够更快地获得操作系统以回答必要的问题。



对于我们在IT行业中可以快速获得操作系统的讨论来说，这是一个非常有趣的话题。 想象一下，进行一个半年的项目是多么痛苦 ，然后才发现一开始就犯了一个错误。 这发生在设计以及复杂系统的任何构造中。

就我们而言，IaC可帮助我们提供反馈。 我立即对上图进行了一些小的调整：我们没有月度发布计划，但一天会发生几次。 一些实践与此操作系统周期相关，我们将对其进行更详细的研究。

重要提示：反馈可以解决上述所有问题。 结合XP的实践，它可以使绝望摆脱深渊。

如何摆脱绝望的深渊：三种做法

测验

XP反馈循环中两次提到测试。 不仅如此。 它们对于所有极限编程技术都极为重要。

假定您已进行单元测试和验收测试。 有些会在几分钟内给您反馈，有些会在几天内给您反馈，因为它们写的时间更长，运行频率更低。

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



此方案在IaC项目中如何适用于我们？ 其实...什么都没有。

• 尽管应该有很多单元测试，但不能太多。 还是他们非常间接地测试了某些东西。 实际上，可以说我们根本不写它们。 但是这里有一些用于此类测试的应用程序，我们仍然设法做到了：
  
  
  1. 在jsonnet上测试代码。 例如，这是我们在无人机中进行的管道装配，这非常复杂。 测试很好地涵盖了jsonnet代码。
     我们将这个单元测试框架用于Jsonnet 。
  2. 测试资源启动时执行的脚本。 可以编写Python脚本，并因此对其进行测试。
• 测试中可能会验证配置，但我们无法验证。 也可以通过tflint配置对资源配置规则的验证。 但是，仅针对terraform进行过基本检查，但是为AWS编写了许多测试脚本。 而且我们在Azure上，因此再次不合适。
• 组件集成测试：这取决于您如何对它们进行分类以及将它们放置在何处。 但它们基本上可以工作。
  
  这就是集成测试的样子。
  
  
  
  这是在Drone CI中组装图像的示例。 要到达它们，您必须等待30分钟以收集Packer图像，然后再等待15分钟以使它们通过。 但是他们是！
  
  
  图像验证算法

  1. 首先，Packer必须完全准备映像。
  2. 在测试旁边，有一个具有局部状态的地形，我们使用它来部署此映像。
  3. 部署时，将在其旁边使用一个小模块，以便更轻松地处理映像。
  4. 从映像部署VM后，即可开始检查。 大多数检查是通过汽车进行的。 它检查脚本在启动时如何工作，守护程序如何工作。 为此，通过ssh或winrm，我们转到刚被提升的机器，并检查配置状态或服务是否已提升。

  
  
• 集成测试和terraform模块中的情况类似。 这是一张简短的表格，解释了此类测试的功能。
  
  
  
  在40分钟内提供管道反馈。 一切都需要很长时间。 它可以用于回归，但是对于新开发而言，这通常是不现实的。 如果您确实为此做准备，请准备运行的脚本，可以将其减少到10分钟。 但这仍然不是单元测试，它在5秒钟内达到100个。

在地形图像或模块的组装过程中，没有单元测试，这鼓励将工作转移到可以通过REST简单地拉动的单独服务或Python脚本。

例如，我们需要进行配置，以便在虚拟机启动时将其注册到ScaleFT服务中，在将其销毁时将其删除。

由于ScaleFT是一项服务，因此我们不得不通过API使用它。 那里写了一个包装，你可以拉说：“进来然后删除它。” 它存储所有必要的设置和访问。

我们已经可以为此编写常规测试，因为它与普通软件没有任何区别：某些api被弄湿了，您猛拉一下，看看会发生什么。

测试结果：应该在一分钟内为操作系统提供的单元测试却没有。 在金字塔中进行更高级别的测试会产生效果，但是只涵盖了部分问题。

配对编程

测试当然是好的。 您可以写很多，它们可以是不同的类型。 他们将在自己的水平上工作，并给我们反馈。 但是，给出最快操作系统的不良单元测试仍然存在问题。 同时，他继续希望有一个快速的OS，使用它很容易而且很愉快。 更不用说解决方案的质量了。 幸运的是，有一些技术可以提供比单元测试更快的反馈。 这是配对编程。

编写代码时，我希望尽快获得有关其质量的反馈。 是的，您可以在feature分支中编写所有内容（以免对任何人造成任何伤害），在github中发出拉取请求，将其分配给有意见的人，然后等待答案。

但是您可以等待很长时间。 人们都很忙，即使答案是高质量的，也不一定。 假设答案马上就来了，审阅者立即理解了整个想法，但是答案仍然是迟来的。 但是我要早点。 这里是成对编程，并针对此编程，以便在撰写本文时立即进行。

以下是结对编程样式及其在IaC上的适用性：

1.经典，有经验+有经验，计时器更改。 两个角色-驱动程序和导航器。 两个人 他们使用一个代码工作，并在预定的一段时间后更改角色。

考虑我们的问题与样式的兼容性：

• 问题：工具不完善，代码开发工具。
  负面影响：发展时间更长，我们放慢脚步，工作的节奏/节奏会误入歧途。
  战斗方法：我们使用另一种调优，通用的IDE，并且仍然学习快捷方式。
• 问题：部署缓慢。
  负面影响：增加创建有效代码段的时间。 我们在等待的过程中怀念，在等待的过程中，我们会抽签做其他事情。
  怎么打：没克服。
• 问题：缺乏方法和实践。
  负面影响：不知道如何做善事，但对如何做坏事一无所知。 扩展反馈。
  战斗方法：配对时交换意见和实践几乎可以解决问题。

在IaC上以不均匀的速度应用这种样式的主要问题。 在传统的软件开发中，您的动作非常统一。 您可以花5分钟写N。花10分钟写2N，15分钟-3N。 在这里，您可以花5分钟写N，然后再花费30分钟并写N的十分之一。在这里您什么都不知道，有堵嘴，笨蛋。 试用需要时间，并且会分散编程本身的注意力。

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

2.乒乓球。 这种方法假定一个参与者正在编写测试，而另一参与者正在为他执行一个实现。 鉴于所有的单元测试都很复杂，并且您必须编写长时间的集成测试，所以整个乒乓球的难处就消失了。

我可以说我们尝试了分离设计测试脚本并为其执行代码的职责。 一位参与者想出了一个剧本，在他负责的这部分工作中，他说了最后一句话。 另一个负责实施。 效果很好。 使用这种方法的方案的质量提高了。

结论：las，工作节奏不允许使用乒乓球，因为IaC中使用配对编程。

3.风格强。 练习困难 。 这个想法是，一个参与者成为目录导航器，而第二个参与者则扮演执行驱动程序的角色。 在这种情况下，仅由导航员做出决定的权利。 驱动程序仅打印，一句话会影响正在发生的事情。 角色不会长时间更改。

非常适合训练，但需要很强的软技巧。 在这方面，我们步履蹒跚。 该技术很困难。 这里的重点甚至不是基础架构。

结论：潜在地可以应用，我们不会放弃尝试。

4.围攻，群集和所有众所周知的但此处未列出的样式均不考虑，因为 没有尝试说这件事在我们的工作范围内是行不通的。

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

• 我们的工作节奏不平衡，令人失望。
• 我们遇到了不够好的软技能。 而且，主题领域并不能帮助克服我们的这些缺点。
• 长时间的测试，工具的问题使结对开发变得粘稠。

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

我们有几天（不到一周）的定期合作伙伴。 我们一起完成一项任务。 我们在一起坐了一会儿：一个人写作，另一个人坐下来，看着支持团队。 然后我们不同意了一段时间，每个人都做一些独立的事情，然后我们再次融合，非常快速地同步，一起做某事，再一次发散。

规划与沟通

解决OS问题的最后一步实践是组织任务本身的工作。 这还包括交流经验，这是结对工作之外的事情。 考虑三种做法：

1.通过目标树执行任务。 我们通过一棵无尽的未来树来组织该项目的总体管理。 从技术上讲，领导由Miro完成。 有一项任务-这是一个中间目标。 较小的目标或任务组都可以从中实现。 任务本身就是这些任务。 在此板上创建并执行所有任务。



当我们在集会上进行同步时，该方案还提供每天发生一次的反馈。 共同计划在每个人面前都可以看到，尽管结构清晰且完全开放，但每个人都可以随时了解正在发生的事情以及我们取得的进展。

视觉视觉任务的优势：

• 因果关系。 每个任务都会导致一些全球目标。 任务分为较小的目标。 基础结构域本身是相当技术性的。 例如，通过编写关于迁移到另一个Nginx的排名书，并不总是立即就能清楚地知道对业务产生了什么具体影响。 附近目标卡的存在使情况更加清晰。
  
  因果关系是任务的重要属性。 它直接回答了这个问题：“我在做吗？”
• 并行性。 我们有九个人，不可能仅凭身体上的一项任务就攻击所有人。 来自一个区域的任务也可能并不总是足够的。 我们被迫从事小型工作组之间的并行工作。 同时，这些小组在他们的任务上坐了一段时间，可以被其他人加强。 人们有时会脱离这个工作组。 有人去度假，有人为DevOps conf会议做报告，有人在Habr上写文章。 知道可以同时完成哪些目标很重要。

2.上午集会的主持人多变。 在站立时，我们遇到了这样的问题-人们并行执行许多任务。 有时，任务是松散耦合的，并且不了解谁在做什么。 而且另一位团队成员的意见非常重要。 这是其他信息，可以改变解决问题的过程。 当然，通常会有人与您配对，但是咨询和提示永远不会多余。

为了改善这种情况，我们采用了“改变领先的立场”的技术。 现在，它们在特定列表上旋转，这会产生效果。 当涉及到您时，您被迫投入大量精力并了解正在发生的事情，以便顺利召开一次会议。



3.内部演示。 协助解决配对编程中的问题，在任务树上可视化以及在早上的集会中提供帮助是好的，但不是完美的。 在一对夫妇中，您仅受知识的限制。 任务树可帮助您全局了解谁在做什么。 主持人和早上开会的同事不会深入研究您的问题。 他们当然可以错过一些东西。

找到的解决方案是演示彼此完成的工作以及他们随后的讨论。 我们每周收集一个小时，一次，并显示上周完成的任务的解决方案的详细信息。

在演示过程中，有必要揭示任务的细节并确保演示其工作。


在全日制课程之后，线程中总是会有讨论。 这是有关我们任务的必要反馈出现的地方。


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

长期结论和下一步

文章的语气似乎有些悲观。 事实并非如此。 两个基层反馈级别（即测试和结对编程）起作用。 虽然不如传统的发展那么完美，但是从中产生了积极的影响。

以当前形式进行的测试仅提供部分代码覆盖。 许多配置功能未经测试。 编写代码时，它们对直接工作的影响很小。 但是，集成测试会产生影响，正是它们使进行重构成为可能，而无需担心。 这是一项伟大的成就。 而且，随着将重点转移到高级语言的开发上（我们有python，go），问题就消失了。 但是，对“胶水”的检查很多，因此不需要足够全面的整合。

成对工作更多地取决于特定的人。 有一个任务因素和我们的软技能。 结果与某人相处得很好，而与某人相处得更糟。 绝对有好处。 显然，即使不充分遵守配对工作规则，联合执行任务也会对结果质量产生积极影响。 就个人而言，我在一起工作更轻松愉快。

影响操作系统的高级方法-计划和处理任务正好产生效果：高质量的知识交流和开发质量的提高。

简短总结

• XP实践在IaC中有效，但效率较低。
• 加强有效的方法。
• 设计自己的补偿机制和实践。