我們的團隊熱愛實驗。 每一次 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 的角度研究了這些事件。 我們詳細分析了問題——發生的原因、消除的進度。 之後，我們逐一團隊和集體決定如何進一步預防它們：如何改善監控，如何明智地改變架構，如何調整開發和營運方法，如何修正法規。 演講者示範了進行屍檢的做法。
「還有誰願意受折磨！ - 我！”
各隊的成績被嚴格、清楚地記錄在電子記分板上。
對於第一名 - 來自利害關係人的獎金。
來源： www.habr.com