Dodo Pizza在世界13个国家/地区拥有600多家比萨店，而比萨店的大多数流程都由我们编写和支持的Dodo IS信息系统控制。因此，系统的可靠性和稳定性对于生存至关重要。
现在，公司的信息系统的稳定性和可靠性得到了SRE（站点可靠性工程）团队的支持，但情况并非总是如此。
背景：开发人员和基础架构的并行世界
多年以来，我一直是一名典型的全栈开发人员（有点像Scrum大师），从极限编程中学到了编写好的代码，应用程序实践的经验，并努力减少了所涉及项目的WTF数量。但是，在软件开发方面积累的经验越多，我就越意识到可靠的监视系统和跟踪应用程序，高质量的日志，全自动测试以及提供高服务可靠性的机制的重要性。他越来越多地开始对基础架构团队“望而却步”。
我对代码的工作环境了解得越多，我就越惊讶：在软件世界中，对所有事物，CI，频繁发布，安全重构和集体代码所有权的自动测试一直是例行且熟悉的。同时，在“基础设施”的世界中，缺少自动测试，以半手动模式对生产系统进行更改仍然是正常的，并且文档往往只属于个人的头脑，而没有代码中。
这种文化和技术鸿沟不仅造成混乱，而且引起问题：在发展，基础设施和业务的交汇处。由于靠近硬件和相对较差的工具，一些基础结构问题很难解决。但是，如果您开始将所有Ansible剧本和Bash脚本看做一个成熟的软件产品，并对它们应用相同的要求，那么其他产品可能会被击败。
百慕大问题三角
但是，我将从头开始-从所有这些舞蹈需要解决的问题开始。
开发人员问题
两年前，我们意识到大型比萨连锁店如果没有自己的移动应用程序就无法生存，因此决定编写它：
- 组建了一个很酷的团队；
- 我们在六个月内编写了一个方便，美观的应用程序；
- 通过盛大的促销活动来支持盛大的发布会；
- 在第一天就安全地承受了负载
当然，一开始有很多浅滩，但我记得最重要的是。在开发时，在生产环境中部署了一个性能较弱的服务器，几乎是一个计算器，用于处理来自应用程序的请求。在该应用程序公开发布之前，必须对其进行增加-我们生活在Azure中，单击按钮即可解决。
但是没有人按下这个按钮：基础架构团队甚至都不知道今天有一个应用程序正在发布。他们认为，监督“非关键”服务的产生是应用程序团队的责任。后端开发人员（这是他在Dodo的第一个项目）决定，基础架构方面的人正在大型公司中这样做。
那个开发商就是我。然后，我为自己得出了一条显而易见但重要的规则：
, , , . .
现在不难。近年来，出现了许多工具，使程序员能够了解剥削的世界而不会破坏任何东西：Prometheus，Zipkin，Jaeger，ELK stack和Kusto。
但是，许多开发人员仍对基础架构/ DevOps / SRE产生严重的问题。结果，程序员：
依赖于基础架构团队。这会引起痛苦，误解，有时会相互仇恨。
他们设计的系统与现实隔离，并且不考虑代码的执行位置和执行方式。例如，为终身在云中开发而开发的系统的体系结构和设计将与内部托管的系统的设计不同。
他们不了解与代码相关的错误和问题的性质。当问题与负载，查询平衡，网络或硬盘驱动器性能有关时，这一点尤其明显。开发人员并不总是具有这些知识。
无法优化用于维护代码的资金和其他公司资源。根据我们的经验，可能发生的情况是基础架构团队只是用金钱来充斥问题，例如，增加生产中数据库服务器的大小。因此，代码问题通常甚至没有传达给程序员。仅仅是出于某种原因，基础架构开始花费更多。
基础设施问题
“另一端”也存在困难。
没有质量代码，很难管理许多服务和环境。GitHub上有450多个存储库。其中一些不需要操作支持，有些已被保存并保存为历史记录，但是很大一部分包含需要支持的服务。他们需要在某个地方托管，他们需要监视，收集日志，统一的CI / CD管道。
为了管理所有这些，我们最近积极使用了Ansible。我们的Ansible存储库包含：
- 60个角色;
- 102本剧本;
- Python和Bash绑定
- 在Vagrant中进行手动测试。
所有这些都是由一个聪明的人写的，写得很好。但是，一旦其他基础结构开发人员和程序员开始积极使用此代码，事实证明剧本会中断，角色会重复出现并且“长满青苔”。
原因是该代码未使用软件开发领域的许多标准实践。它没有CI / CD管道，并且测试复杂而缓慢，因此每个人都太懒惰或“没有时间”无法手动运行它们，甚至编写新的。如果不止一个人在使用这种代码，那么它注定会失败。
没有代码知识，就很难有效地响应事件。当警报发生在PagerDuty的凌晨3点到达时，您必须寻找可以解释什么以及如何操作的程序员。例如，这些错误500影响用户，而其他错误与辅助服务有关，则最终客户看不到它，您可以这种方式直到早上。但是在凌晨三点，很难唤醒程序员，因此建议您了解支持的代码的工作方式。
许多工具需要嵌入到应用程序代码中。来自基础架构的人员知道要监视什么，如何记录日志以及跟踪时应注意的事项。但是他们通常无法将所有这些嵌入到应用程序代码中。而那些谁不知道嵌入什么以及如何嵌入。
“手机坏了。”第一百次解释什么以及如何监视是不愉快的。编写共享库以传递给程序员以在其应用程序中重用会更容易。但是要做到这一点，您需要能够以与应用程序开发人员所使用的相同的语言，相同的样式和方法来编写代码。
业务问题
业务也有两个大问题需要解决。
系统不稳定带来的直接损失与可靠性和可用性有关。
在2018年，我们发生了51起严重事件，该系统的关键要素总共工作不到20个小时。以货币计算，这是由于未交付和未交付订单造成的2500万卢布直接损失。而且，我们无法计算出我们在员工，客户和加盟商的信任下蒙受的损失，这是没有金钱价值的。
当前的基础架构支持成本。同时，公司为我们设定了2018年的目标：将每个比萨店的基础设施成本降低3倍。但是团队中的程序员和DevOps工程师都无法接近解决这个问题。原因如下：
- , ;
- , operations ( DevOps), ;
- , .
?
如何解决所有这些问题？我们在Google 的站点可靠性工程中找到了该解决方案。当我们阅读它时，我们了解-这就是我们所需要的。
但是有一个警告-为了实现所有这些，需要花费很多年，并且您必须从某个地方开始。考虑我们最初拥有的初始数据。
我们的整个基础架构几乎完全生活在Microsoft Azure中。有几个独立的销售集群分布在不同的大陆：欧洲，美洲和中国。有可以重复生产的负载架，但是它们处于隔离的环境中，并且有数十个用于开发团队的DEV环境。
我们已经拥有良好的SRE实践：
- 监视应用程序和基础架构的机制（破坏者：2018年我们认为它们很好，但现在我们已经重写了所有内容）;
- 24/7 on-call;
- ;
- ;
- CI/CD- ;
- , ;
- SRE .
但是首先要解决的问题是：
基础架构团队超负荷工作。由于当前的操作系统，没有足够的时间和精力进行全局改进。例如，我们想要很长一段时间，但是无法摆脱堆栈中的Elasticsearch，或者为了避免风险而复制了其他云提供商的基础架构（已经尝试过多云的人可能会在这里大笑）。
代码中的混乱。基础结构代码混乱，分散在不同的存储库中，并且未在任何地方进行记录。一切都取决于个人的知识，而不是其他。这是一个巨大的知识管理问题。
“有程序员，有基础设施工程师。”尽管我们拥有相当完善的DevOps文化，但仍然存在这种分离。经历完全不同的两类人说不同的语言并使用不同的工具。他们当然是朋友，并且可以交流，但是由于完全不同的经历，他们常常彼此不了解。
SRE入职团队
为了解决这些问题并以某种方式开始向SRE迈进，我们启动了一个入职项目。只是这不是经典的入职培训-培训新员工（新员工）以将人员添加到当前团队中。这是建立新的基础架构工程师和程序员团队的第一步-迈向成熟的SRE结构的第一步。
我们为该项目分配了4个月的时间，并设定了三个目标：
- 对程序员进行基础架构团队职责和运营活动所必需的知识和技能的培训。
- 编写IaC-代码中对整个基础结构的描述。并且它应该是具有CI / CD，测试功能的成熟软件产品。
- 通过此代码重新创建我们的整个基础结构，而不必再在Azure中使用鼠标手动单击虚拟机。
参与者组成：9人，其中6人来自开发团队，3人来自基础架构。他们不得不离开正常工作四个月，专注于指定的任务。为了维持业务的“生命”，基础架构中还有3个人需要值勤，处理操作系统并覆盖后方。结果，该项目明显被拉长，耗时五个多月（从2019年5月到2019年10月）。
入职培训的两大支柱：学习与实践
入职包括两个部分：以代码形式学习和使用基础架构。
训练。每天至少分配3个小时进行培训：
- 从参考文献列表中阅读文章和书籍：Linux，网络，SRE；
- 在有关特定工具和技术的讲座上；
- 到技术俱乐部（例如Linux），我们在其中分析了复杂的案例和案例。
另一个学习工具是内部演示。这是每周一次的会议，每个人（有话要说）在10分钟内讨论他在本周的代码中实现的技术或概念。例如，Vasya更改了使用Terraform模块的管道，而Petya使用Packer重新编写了图像装配。
演示之后，我们开始在Slack中的每个主题下进行讨论，感兴趣的参与者可以在其中异步地更详细地讨论所有内容。因此，我们避免了10人的长时间会议，但与此同时，团队中的每个人都很好地了解了我们的基础架构正在发生的事情以及我们的前进方向。
实践。入门的第二部分是代码中基础结构的创建/描述。这部分分为几个阶段。
基础架构的逆向工程。这是我们确定其固定位置，工作方式，服务位置，机器及其大小的第一阶段。一切都已完全记录在案。
概念。我们尝试了不同的技术，语言，方法，发现了如何描述我们的基础架构，应使用哪些工具。
拼写代码。这包括编写代码本身，创建CI / CD管道，测试以及围绕所有内容构建流程。我们编写了描述并知道如何从头开始创建我们的处女座基础架构的代码。
重新创建用于负载测试和生产的机架。这是应该在入职后进入的第四阶段，但是到目前为止已经推迟了，因为从中获利的确奇怪的是，它比经常创建/重新创建的处女少得多。
取而代之的是，我们转而从事项目活动：我们分为几个小团队，处理那些从未实现过的全球基础设施项目。当然，我们加入了手表。
我们用于IaC的工具
- Terraform .
- Packer Ansible .
- Jsonnet Python .
- Azure, .
- VS Code — IDE, , , , .
- — , .
基础架构中的极限编程实践
作为程序员，我们带来的主要是在工作中使用的极限编程实践。 XP是一种灵活的软件开发方法，结合了最佳开发方法，实践和价值的紧缩。
没有一个程序员至少没有使用过一些极限编程实践，即使他不知道。同时，在基础架构领域，尽管这些做法与Google SRE的做法在很大程度上重叠，但实际上却被绕开了。
另有一篇文章介绍了我们如何将XP用于基础架构。。简而言之：XP实践适用于基础结构代码，尽管有限制，适应性，但它们仍然有效。如果要在家中应用它们，请邀请有应用这些实践经验的人。在SRE的同一本书中，对这些实践中的大多数进行了一种或多种描述。
一切都可以顺利完成，但事实并非如此。
技术和人为问题
该项目有两种类型的问题：
- 技术方面：“铁”世界的局限性，缺乏知识和必须使用的原始工具，因为没有其他方面。这些是任何程序员的常见问题。
- 人：团队中人的互动。沟通，决策，培训。这样做的后果更糟，因此我们需要更详细地介绍。
我们开始以与其他任何程序员团队相同的方式来开发入门团队。我们预计，按照塔克曼的说法，组建团队的通常阶段是：猛攻，配给，最后我们将进行生产力和生产性工作。因此，我们不必担心，起初在沟通，决策，达成协议上有困难。
两个月过去了，但攻势阶段仍在继续。直到项目结束时，我们才意识到，我们所苦苦挣扎且没有被认为彼此相关的所有问题都是一个共同的根本问题的结果-两组完全不同的人组成了团队：
- 经验丰富的程序员具有多年的经验，他们在工作中发展了自己的方法，习惯和价值观。
- 来自基础设施领域的另一组人有他们自己的经验。他们有不同的颠簸，不同的习惯，他们还认为自己知道如何正确生活。
一个团队的生活存在两种观点上的冲突。我们没有立即看到它，也没有开始使用它，结果我们浪费了很多时间，精力和神经。
但是这种碰撞是无法避免的。如果您召集强大的程序员和弱小的基础架构工程师加入项目，那么您将进行单向知识交流。相反，它也不起作用-有些会吞下其他人，仅此而已。而且，您需要得到某种混合，因此您需要为“打磨”可能非常长的事实做好准备（在我们的情况下，我们只能在一年后稳定团队，同时向技术上最强大的工程师说再见）。
如果您想组建一支如此强大的团队，请不要忘了打电话给一位强大的敏捷教练，Scrum主管或心理治疗师-无论您最喜欢哪个。也许他们会有所帮助。
入职结果
根据入职项目（于2019年10月结束）的结果，我们：
- 他们创建了一个功能完善的软件产品，该软件产品通过自己的CI管道，测试和高质量软件产品的其他属性来管理我们的DEV基础架构。
- 我们将准备值班的人数增加了一倍，减轻了目前团队的负担。又过了六个月，这些人成为了完整的SRE。现在他们可以扑灭市场，咨询NTF程序员团队，或者为开发人员编写自己的库。
- SRE. , , .
- : , , , .
: ,
开发者的一些见解。不要踩踏我们的耙子，拯救自己和周围的人的神经和时间。
基础设施已成为过去。当我在第一年（15年前）开始学习JavaScript时，我有了NotePad ++和Firebug，可以从我的工具进行调试。即使这样，也有必要使用这些工具来完成一些复杂而精美的事情。
现在，当我使用基础架构时，我的感觉差不多。当前的工具刚刚形成，其中许多尚未发布，并且版本为0.12（Hello Terraform），并且其中许多经常破坏与以前版本的向后兼容性。
对我来说，作为企业开发人员，在生产中使用这些东西是荒谬的。但是，根本没有其他人。
阅读文档。作为程序员，我很少去码头。我非常了解我的工具：我最喜欢的编程语言，我最喜欢的框架和数据库。所有其他工具（例如库）通常都是用相同的语言编写的，这意味着您可以始终查看源代码。 IDE会始终告诉您需要哪些参数。即使我犯了一个错误，我也会通过运行快速测试来快速理解这一点。
这在基础架构中不起作用，您需要了解大量不同的技术。但是不可能一无所知，而且很多都是用未知的语言编写的。因此，请仔细阅读（并编写）文档-如果没有这种习惯，他们将不会在这里居住很长时间。
基础结构代码注释是不可避免的。在开发世界中，注释是错误代码的标志。他们很快变得过时并开始撒谎。这表明开发人员无法表达他的想法。在使用基础架构时，注释也是不良代码的标志，但是如果没有它们，您将无法做到。对于彼此之间松散相关但彼此一无所知的零散乐器，必不可少的注释。
通常，在代码下，普通的配置和DSL被隐藏。在这种情况下，所有逻辑都发生在更深的地方，没有访问权限。这极大地改变了编码，测试和使用它的方法。
不要害怕让开发人员进入基础架构。它们可以带来来自软件开发界的有用（且新颖）的实践和方法。使用有关SRE的书中所述的Google的做法和方法，可以受益并感到高兴。
PS: , , , .
PPS: DevOpsConf 2019 . , , : , , DevOps-, .
PPPS: , DevOps-, DevOps Live 2020. : , - . , DevOps-. — « » .
, DevOps Live , , CTO, .