我们公司正在组建 SRE 团队。 我是从开发的角度来了解整个故事的。 在此过程中，我提出了一些想法和见解，想与其他开发人员分享。 在这篇反思文章中，我讨论了正在发生的事情、它是如何发生的以及每个人如何继续忍受它。
根据我们内部活动的演讲撰写的一系列文章的延续 :
2. 基础设施即代码。 （你在这里）
3. 使用 C# 模型生成 Typescript 合约。 （进行中...）
4.Raft共识算法介绍。 （进行中...）
...
我们决定创建一个 SRE 团队来实施这些想法 。 他们从自己的开发人员中招募程序员，并派他们接受几个月的培训。
该团队有以下训练任务：
- 描述我们的基础设施，它主要以代码的形式存在于 Microsoft Azure 中（Terraform 和周围的一切）。
- 教开发人员如何使用基础设施。
- 为开发人员做好履行职责的准备。
我们引入基础设施即代码的概念
在世界的通常模型（古典管理）中，有关基础设施的知识位于两个地方：
- 或者以专家头脑中的知识的形式。
- 或者这些信息是在某些打字机上的，其中一些是专家所知道的。 但事实上，外人（以防我们整个团队突然死亡）能够弄清楚什么是有效的以及它是如何工作的。 一台机器上可能有很多信息：配件、定时任务、恐吓（参见。 ）磁盘和可能发生的事情的无穷无尽的列表。 很难理解到底发生了什么。
在这两种情况下，我们都会发现自己陷入了依赖之中：
- 或者来自一个凡人，容易受到疾病、恋爱、情绪波动和平庸的裁员的影响；
- 或者来自物理工作的机器，该机器也会掉落、被盗，并带来意外和不便。
不言而喻，理想情况下所有内容都应该翻译成人类可读、可维护、编写良好的代码。
因此，基础设施即代码（Incfastruct as Code - IaC）是对整个现有基础设施以代码形式的描述，以及用于使用它并从中实现真正基础设施的相关工具。
为什么要把一切都翻译成代码？人不是机器。 他们无法记住一切。 人和机器的反应是不同的。 任何自动化的事情都可能比人类所做的事情更快。 最重要的是单一事实来源。
新的 SRE 工程师从哪里来？因此，我们决定聘请新的 SRE 工程师，但从哪里找他们呢？ 预订正确答案（）告诉我们：来自开发商。 毕竟，它们与代码一起工作，并且您达到了理想的状态。
我们在公司外部的人才市场上寻找了很长一段时间。 但我们不得不承认，我们没有找到符合我们要求的人。 我必须在自己的同胞中寻找。
问题 基础设施即代码
现在让我们看一下如何将基础设施硬编码到代码中的示例。 代码写得很好，质量很高，有注释和缩进。
来自 Terraforma 的示例代码。
来自 Ansible 的示例代码。
先生们，如果事情有这么简单就好了！ 我们身处现实世界，它随时准备着给你惊喜，给你带来惊喜和问题。 这里也离不开他们。
1. 第一个问题是，在大多数情况下，IaC 是某种 dsl。
而 DSL 又是对结构的描述。 更准确地说，你应该拥有：Json、Yaml、一些大公司的修改，这些公司提出了自己的 dsl（HCL 用于 terraform）。
问题是它可能很容易不包含以下熟悉的内容：
- 变量；
- 状况;
- 有些地方没有注释，例如Json，默认情况下不提供注释；
- 功能;
- 我什至不是在谈论诸如类、继承之类的高级事物。
2. 此类代码的第二个问题是，大多数情况下它是异构环境。 通常你会坐下来使用 C#，即使用一种语言、一种堆栈、一种生态系统。 这里有各种各样的技术。
这是一个非常真实的情况，当 bash 使用 python 启动一些插入 Json 的进程时。 您对其进行分析，然后其他生成器会生成另外 30 个文件。 为此，从 Azure Key Vault 接收输入变量，这些变量由用 Go 编写的 Drone.io 插件整合在一起，并且这些变量通过 yaml 传递，而 yaml 是 jsonnet 模板引擎生成的结果。 当您拥有如此多样化的环境时，很难拥有严格且良好描述的代码。
一项任务框架内的传统开发使用一种语言。 在这里，我们使用大量语言。
3.第三个问题是调优。 我们习惯了很酷的编辑器（Ms Visual Studio、Jetbrains Rider）为我们做一切事情。 即使我们很蠢，他们也会说我们错了。 这看起来很正常、很自然。
但附近有 VSCode，其中有一些以某种方式安装、支持或不支持的插件。 新版本发布但不受支持。 实现一个功能（即使它存在）的平庸过渡变成了一个复杂且不平凡的问题。 变量的简单重命名就是在包含十几个文件的项目中重命名。 如果他放置了你需要的东西，你就会很幸运。 当然，到处都有背光，有自动完成，有地方有格式化（尽管它在 Windows 上的 terraform 中对我不起作用）。
在撰写本文时 尽管已经发布了 0.12 个月，但尚未发布支持 3 版本。
是时候忘记...
- 调试。
- 重构工具。
- 自动完成。
- 检测编译期间的错误。
这很有趣，但这也增加了开发时间并增加了不可避免发生的错误数量。
最糟糕的是，我们被迫思考的不是如何设计、将文件组织到文件夹中、分解、使代码可维护、可读等等，而是如何正确地编写这个命令，因为我不知何故写错了它。
作为初学者，您正在尝试学习 terraform，而 IDE 根本无法帮助您。 有文档的话就进去看看。 但如果你输入一种新的编程语言，IDE会告诉你有这样的类型，但实际上并没有这样的东西。 至少在整数或字符串级别。 这通常很有用。
测试怎么样？
你问：“程序员先生们，测试怎么样？” 认真的人会测试生产中的一切，这很困难。 这是网站上 terraform 模块的单元测试示例 .
他们有很好的文档。 我一直喜欢 Microsoft 的文档和培训方法。 但即使您不是 Bob 叔叔，您也能明白这不是完美的代码。 请注意右侧的验证。
单元测试的问题在于你和我可以检查 Json 输出的正确性。 我输入了 5 个参数，得到了一个包含 2000 行的 Json 脚布。 我可以分析这里发生的事情，验证测试结果......
在Go中解析Json是很困难的。 而且您需要用 Go 编写，因为 Go 中的 terraform 是用您编写的语言进行测试的良好实践。 代码本身的组织非常薄弱。 同时，这是最好的测试库。
Microsoft 自己编写其模块，并以这种方式测试它们。 当然它是开源的。 我所说的一切你都可以过来解决。 我可以坐下来在一周内修复所有问题，开源 VS code 插件、terraforms、为骑手制作一个插件。 也许编写几个分析器，添加 linter，贡献一个测试库。 我什么都可以做。 但这不是我应该做的。
最佳实践基础设施即代码
让我们继续。 如果 IaC 中没有测试，IDE 和调优很糟糕，那么至少应该有最佳实践。 我刚刚访问 Google Analytics，比较了两个搜索查询：Terraform 最佳实践和 C# 最佳实践。
我们看到了什么？ 无情的统计数据对我们不利。 材料的量是一样的。 在 C# 开发中，我们有大量的材料，我们有超级最佳实践，有专家写的书，也有其他批评这些书的专家写的书。 大量的官方文档、文章、培训课程，现在还有开源开发。
至于 IaC 请求：这里你试图从 highload 或 HashiConf 报告、官方文档和 Github 上的众多问题中一点一点地收集信息。 一般如何分发这些模块，如何处理它们？ 看来这是一个真正的问题...先生们，有一个社区，对于任何问题，您都会在 Github 上获得 10 条评论。 但事实并非如此。
不幸的是，此时专家才刚刚开始出现。 到目前为止，他们的数量太少了。 而社区本身还处于初级水平。
这一切要去哪里以及该做什么
你可以放下一切，回到 C#，回到骑手的世界。 但不是。 如果你找不到解决方案，为什么还要费力这样做呢？ 下面我提出我的主观结论。 你可以在评论里和我争论，这会很有趣。
就我个人而言，我押注于以下几件事：
- 该领域的发展非常迅速。 以下是 DevOps 请求的时间表。
这个话题可能是炒作，但这个领域正在发展的事实本身就带来了一些希望。如果某件事发展得这么快，那么聪明的人肯定会出现，他们会告诉你什么该做，什么不该做。 受欢迎程度的增加导致这样一个事实：也许有人最终有时间为 vscode 的 jsonnet 添加一个插件，这将允许你继续实现该功能，而不是通过 ctrl+shift+f 搜索它。 随着事物的发展，更多的材料出现。 Google 发布的一本关于 SRE 的书就是一个很好的例子。
- 我们可以在这里成功应用传统开发中的成熟技术和实践。 是的，测试和异构环境存在细微差别，工具不足，但已经积累了大量有用且有帮助的实践。
一个简单的例子：通过结对编程进行协作。 弄清楚它有很大帮助。 当你附近的邻居也试图理解某件事时，你们在一起就会更好地理解。
即使在这种情况下，了解重构是如何完成的也有助于执行重构。 也就是说，你不能一下子改变所有的东西，而是改变命名，然后改变位置，然后你可以突出某些部分，哦，但是这里注释不够。
结论
尽管我的推理可能看起来很悲观，但我对未来充满希望，并真诚地希望我们（和您）一切顺利。
接下来正在准备文章的第二部分。 在其中，我将讨论我们如何尝试使用敏捷开发实践来改进我们的学习过程并使用基础设施。
来源： habr.com