我们的团队热爱实验。 每一次 Slurm 都不是之前的静态重复，而是对经验的反思以及从好到更好的过渡。 但与 我们决定采用一种全新的形式——为参与者提供尽可能接近“战斗”的条件。
如果我们简要概述一下我们在强化课程中所做的事情：“我们建造，我们破坏，我们修复，
我们在学习。” SRE 仅仅在理论方面没有什么价值——只有实践、真正的解决方案、真正的问题。
参与者被分成小组，这样激烈的竞争精神就不会让任何人睡着或效仿德米特里·阿纳托利耶维奇（Dmitry Anatolyevich）在 iPhone 上推出“愤怒的小鸟”。
四位导师向参与者提供了问题、故障、错误和任务。 Ivan Kruglov，Booking.com（荷兰）的首席开发人员。 Ben Tyler，Booking.com（美国）首席开发人员。 Eduard Medvedev，Tungsten Labs（德国）首席技术官。 Evgeniy Varavva，Google（旧金山）的总开发人员。
而且，参赛者被分成小组，互相竞争。 有趣的？
比赛开始前，Ivan、Ben、Eduard 和 Evgeniy 用列宁主义的眼神看着可怜的 Slurm SRE 参赛者。
所以任务：
我们是我们的，我们将建立一个新的世界...
有一个电影票聚合网站。 事件是由导师在预先设计的场景中发明的（尽管没有人排除特别复杂和阴险的即兴创作），网站的性能是通过各种指标来描述的。 问题可能非常不同：红磨坊剧院的门票没有加载到数据库中； 电影和表演的海报在10多秒内加载到数据库中； 个别电影的描述冻结； 0,1%的订单已被预订； 支付处理系统有时会崩溃一两分钟。 Slurm SRE 参与者在实际工作中可能会遇到很多很多不愉快的事情。
我们已准备好处理任何事情……以及每个人。
我们长期遭受苦难的网站由多个微服务组成。 它的任务是汇总所有电影院的放映、价格和可用座位的数据；它显示电影公告，允许您选择电影院、放映、大厅和地点、预订和支付门票。 一般来说，一切都是观众只能梦想的。 但用户甚至没有意识到网站内部正在为网站的稳定性和可访问性而进行一场巨大的斗争。
对于密集型站点，我们生成了SLO、SLI、SLA指标，开发了架构和基础设施，部署了站点，设置了监控和警报。 然后我们就出发了。
SLO、SLI、SLA
SLI——服务水平指标。 SLO 是服务级别目标。 SLA——服务水平协议。
SLA 是一个 ITIL 方法术语，表示服务的客户与其供应商之间的正式协议，其中包含服务的描述、双方的权利和义务，以及最重要的是，提供该服务的商定的质量水平。服务。
SLO 是服务级别目标：由 SLI 衡量的服务级别的目标值或值范围。 SLO 的正常值为“SLI ≤ 目标”或“下限 ≤ SLI ≤ 上限”。
SLI 是一种服务水平指标，是对所提供服务水平的某个方面精心定义的定量衡量标准。 对于大多数服务，关键的 SLI 被认为是请求延迟 - 返回请求响应所需的时间。 其他常见的 SLI 包括错误率（通常表示为收到的所有请求的一部分）和系统吞吐量（通常以每秒请求数来衡量）。
首先，我们会破坏飞机，然后是女孩，然后是女孩......
从一开始，内部和外部因素就开始“破坏”SLO。 一切都落在了管理员的头上——开发人员的错误、基础设施故障、访客涌入和 DDoS 攻击。 一切使 SLO 恶化的事情。
“——亲爱的参赛者，我赶紧拜托你们了，你们首先失败的就是……一切！”
一路上，演讲者讨论了稳定性、错误预算、测试实践、中断管理和操作负载。
我们不是司炉，不是木匠……
然后参与者开始解决问题——最重要的是要了解首先要抓住什么。
“——主啊，我从来没有见过它像这样、以这样的形式、以这样的位置破裂过！”
于是，意外发生了。 付款处理服务已关闭。 如何采取行动在最短的时间内恢复功能？
专家们深情地看着参赛者，正在准备另一招。
每个团队组织团队消除事故的工作——让同事参与，通知相关方（利益相关者）。 同时，确定了优先事项。 通过这种方式，参与者训练了在极其有限的时间条件下在压力下工作的能力。
“到底发生了什么恐怖的事情？！”
呼气...然后完成练习
在每个问题得到解决、站点暂时稳定后，团队与主讲人一起从 SRE 的角度研究了这些事件。 我们详细分析了问题——发生的原因、消除的进度。 之后，我们逐个团队和集体决定如何进一步预防它们：如何改进监控，如何明智地改变架构，如何调整开发和运营方法，如何纠正法规。 演讲者演示了进行尸检的做法。
“还有谁愿意受折磨！ - 我！”
各队的成绩被严格、清晰地记录在电子记分牌上。
对于第一名 - 来自利益相关者的奖金。
来源： habr.com