網絡研討會的音頻質量很差，因此我們已將其轉錄。
我叫梅德韋傑夫·愛德華。 今天我將談談 SRE 是什麼，SRE 是如何出現的，SRE 工程師的工作標準是什麼，一些關於可靠性標準，一些關於它的監控。 我們會走在上面，因為一個小時你說不多，但我會提供材料供額外審查，我們都在等你 . 一月底在莫斯科。
首先，讓我們談談什麼是 SRE——站點可靠性工程。 以及它如何作為一個單獨的位置、一個單獨的方向出現。 這一切都始於這樣一個事實，在傳統的開髮圈中，Dev 和 Ops 是兩個完全不同的團隊，通常有兩個完全不同的目標。 開發團隊的目標是推出新功能並滿足業務需求。 Ops 團隊的目標是確保一切正常，沒有任何中斷。 顯然，這些目標直接相互矛盾：為了一切正常，沒有什麼可以破壞的，盡可能少地推出新功能。 因此，現在稱為 DevOps 的方法試圖解決許多內部衝突。
問題是我們對 DevOps 沒有明確的定義，也沒有明確的 DevOps 實現。 2 年前我在葉卡捷琳堡的一次會議上發言，直到現在 DevOps 部分都以報告“什麼是 DevOps”開始。 2017 年，DevOps 已經快 10 歲了，但我們還在爭論它到底是什麼。 這是谷歌幾年前試圖解決的一個非常奇怪的情況。
2016 年，谷歌發布了一本名為《站點可靠性工程》的書。 事實上，SRE 運動正是從這本書開始的。 SRE 是 DevOps 範式在特定公司的具體實現。 SRE 工程師致力於確保系統可靠運行。 他們大多來自開發人員，有時來自具有強大開發背景的管理員。 他們做系統管理員過去做的事情，但是強大的開發背景和代碼方面的系統知識導致這些人不傾向於日常管理工作，而是傾向於自動化。
事實證明，SRE 團隊中的 DevOps 範式是通過有解決結構性問題的 SRE 工程師來實現的。 這就是人們已經討論了 8 年的 Dev 和 Ops 之間的相同聯繫。 SRE 的角色類似於架構師，因為新人不會成為 SRE。 剛開始職業生涯的人還沒有任何經驗，沒有必要的知識廣度。 因為 SRE 需要非常微妙的知識，知道什麼時候會出錯，什麼時候會出錯。 因此，通常在公司內部和外部都需要一些經驗。
他們詢問是否會描述 SRE 和 devops 之間的區別。 她剛剛被描述過。 我們可以談談 SRE 在組織中的地位。 與這種經典的 DevOps 方法不同，Ops 仍然是一個獨立的部門，SRE 是開發團隊的一部分。 他們參與產品開發。 甚至還有一種方法，其中 SRE 是從一個開發人員傳遞給另一個開發人員的角色。 他們參與代碼審查的方式與 UX 設計師、開發人員本身，有時甚至是產品經理一樣。 SRE 在同一級別工作。 我們需要批准它們，我們需要審查它們，這樣對於每個部署 SRE 都會說：“好的，這個部署，這個產品不會對可靠性產生負面影響。 如果是這樣，那麼在一些可接受的範圍內。 我們也會談到這個。
因此，SRE 擁有更改代碼的否決權。 通常，如果 SRE 實施不正確，這也會導致某種小衝突。 在同一本關於站點可靠性工程的書中，很多部分，甚至沒有一個部分，講述瞭如何避免這些衝突。
他們詢問 SRE 與信息安全有何關係。 SRE 不直接涉及信息安全。 基本上，在大公司，這是由個人、測試人員、分析師完成的。 但是 SRE 也與它們交互，因為一些操作、一些提交、一些影響安全的部署也會影響產品的可用性。 因此，SRE作為一個整體與任何團隊都有交互，包括安全團隊，包括分析師。 因此，SRE 主要是在嘗試實施 DevOps 時需要的，但與此同時，開發人員的負擔也變得過大。 也就是說，開發團隊本身已經無法應對現在他們也需要負責Ops。 還有一個單獨的角色。 該角色已在預算中計劃。 有時這個角色是根據團隊的規模確定的，一個單獨的人出現，有時其中一個開發人員成為它。 團隊中第一個 SRE 就是這樣出現的。
SRE影響系統的複雜性，影響運行可靠性的複雜性，是必然的，也是偶然的。 必要的複雜性是指產品的複雜性增加到新產品功能所需的程度。 隨機複雜度是指系統的複雜度增加，但產品特性和業務需求不會直接影響到這一點。 事實證明，要么開發人員在某處犯了錯誤，要么算法不是最優的，要么引入了一些額外的利益，在沒有特殊需要的情況下增加了產品的複雜性。 一個好的 SRE 應該總是切斷這種情況。 也就是說，任何提交、任何部署、任何拉取請求，如果由於隨機添加而增加了難度，都應該被阻止。
問題是為什麼不直接聘請一名工程師，一名具有豐富知識的系統管理員進入團隊。 我們被告知，擔任工程師角色的開發人員並不是最佳的人員配備解決方案。 擔任工程師角色的開發人員並不總是最好的人員配備解決方案，但這裡的重點是，從事 Ops 的開發人員對自動化的渴望多一點，知識和技能多一點，以便實施這種自動化。 相應地，我們不僅減少了一些特定操作的時間，不僅是常規操作，而且還減少了 MTTR（Mean Time To Recovery，恢復時間）等重要的業務參數。 因此，我們稍後也會談到這一點，我們為組織省錢。
現在我們來談談SRE運作的標準。 首先是關於可靠性。 在小公司、初創公司中，人們經常會認為，如果服務編寫得好，如果產品編寫得好且正確，它就會運行，不會崩潰。 就是這樣，我們編寫好的代碼，所以沒有什麼可以破壞的。 代碼非常簡單，沒有什麼可破解的。 這些都是說我們不需要測試的人，因為，看，這是三種 VPI 方法，為什麼要在這里中斷。
當然，這都是錯誤的。 這些人在實踐中經常被這樣的代碼咬傷，因為事情壞了。 事情有時會以最不可預測的方式破裂。 有時人們會說不，這永遠不會發生。 它一直在發生。 經常發生。 這就是為什麼沒有人會努力爭取 100% 的可用性，因為 100% 的可用性永遠不會發生。 這是常態。 因此，當我們談論服務的可用性時，我們總是談論九。 2 個九，3 個九，4 個九，5 個九。 如果我們將其轉化為停機時間，例如，5 個九，那麼每年的停機時間略多於 5 分鐘，2 個九是 3,5 天的停機時間。
但很明顯，在某些時候 POI 和投資回報率會下降。 從兩個九到三個九意味著停機時間減少了 3 天以上。 從四個九到五個，每年可減少 47 分鐘的停機時間。 事實證明，對於企業而言，這可能並不重要。 而且總的來說，要求的可靠性不是技術問題，首先是業務問題，是產品問題。 產品的用戶可以接受什麼程度的停機時間，他們期望什麼，他們付出多少，例如，他們損失了多少錢，系統損失了多少錢。
這裡的一個重要問題是其餘組件的可靠性如何。 因為 4 個 5 和 2 個 10 之間的區別在具有 8 個 XNUMX 可靠性的智能手機上是不可見的。 粗略地說，如果您服務的智能手機每年發生 XNUMX 次故障，很可能有 XNUMX 次故障發生在操作系統端。 用戶對此習以為常，不會一年多關註一次。 有必要將提高可靠性和增加利潤的代價聯繫起來。
就在關於 SRE 的書中，有一個很好的例子，就是從 4 個 3 增加到 0,1 個 1。 事實證明，可用性的增加略低於 900%。 如果這項服務的收入是每年 900 萬美元，那麼增加的收入就是 900 美元。 如果我們每年花費不到 3 美元來將負擔能力提高 XNUMX，那麼這種增加在經濟上是合理的。 如果一年花費超過XNUMX美元，那就沒有意義了，因為收入的增加根本無法彌補勞動力成本、資源成本。 XNUMX 個九對我們來說就足夠了。
這當然是一個簡化的例子，所有的請求都是平等的。 從 3 個 4 到 2 個 3 很容易，但同時，例如，從 9 個 XNUMX 到 XNUMX，這已經節省了 XNUMX 美元，這在財務上是有意義的。 當然，在現實中，註冊請求失敗比頁面顯示失敗更糟糕，請求有不同的權重。 從業務角度來看，它們可能有完全不同的標準，但無論如何，通常，如果我們不談論某些特定服務，這是一個相當可靠的近似值。
我們收到一個問題，在為服務選擇架構解決方案時，SRE 是否是協調者之一。 比方說在集成到現有基礎架構方面，這樣就不會損失其穩定性。 是的，SRE，就像拉取請求、提交、發布影響架構、引入新服務、微服務、新解決方案的實施一樣。 為什麼之前說要經驗，要資歷。 事實上，SRE 是任何架構和軟件解決方案中的阻礙聲音之一。 因此，作為工程師的SRE，首先不僅要了解，還要了解一些具體的決策會如何影響可靠性、穩定性，了解這與業務需求有什麼關係，從什麼角度來看是可以接受和接受的。哪個不是。
因此，現在我們可以只談可靠性標準，這在 SRE 中傳統定義為 SLA（服務水平協議）。 很可能是一個熟悉的術語。 SLI（服務水平指標）。 SLO（服務水平目標）。 服務水平協議可能是一個像徵性的術語，特別是如果您曾與網絡、供應商和託管合作過。 這是一個總的協議，描述了你整個服務的表現，懲罰，一些錯誤的懲罰，指標，標準。 SLI 本身就是可用性指標。 也就是說，SLI 可以是：來自服務的響應時間，以百分比表示的錯誤數。 如果它是某種文件託管，它可能是帶寬。 在識別算法方面，指標甚至可以是答案的正確性。 SLO（服務水平目標）分別是 SLI 指標、其值和周期的組合。
假設 SLA 可能是這樣的。 該服務全年 99,95% 的時間可用。 或者每季度 99 小時內關閉 3 個關鍵支持工單。 或每月 85% 的查詢將在 1,5 秒內得到響應。 也就是說，我們逐漸明白錯誤和失敗是很正常的。 這是一個可以接受的情況，我們正在計劃，我們甚至在某種程度上指望它。 也就是說，SRE 構建的系統可以犯錯，必須正常響應錯誤，必須將錯誤考慮在內。 並且只要有可能，他們應該以用戶不會注意到或註意到的方式處理錯誤，但是有某種解決方法，因此一切都不會完全崩潰。
比如你上傳一個視頻到YouTube，YouTube不能馬上轉換，如果視頻太大，格式不是最優，那麼請求自然不會超時失敗，YouTube不會給出502錯誤, YouTube 會說：“我們已經創建了一切，您的視頻正在處理中。 它會在大約 10 分鐘內準備好。” 這就是優雅降級的原則，如果你做過前端開發，就很熟悉了。
我們將討論的下一個術語是 MTBF 和 MTTR，它們對於處理可靠性、誤差和期望非常重要。 MTBF 是平均故障間隔時間。 MTTR Mean Time To Recovery，平均恢復時間。 即從發現錯誤的那一刻起，從出現錯誤的那一刻到服務恢復完全正常運行的那一刻，經過了多少時間。 MTBF 主要由代碼質量工作決定。 也就是說，SRE 可以說“不”。 你需要讓整個團隊都明白，當 SRE 說“不”時，他這麼說並不是因為他有害，不是因為他不好，而是因為否則每個人都會受苦。
同樣，有很多文章、很多方法、很多方法，甚至在我經常參考的那本書中，如何確保其他開發人員不會開始討厭 SRE。 另一方面，MTTR 與您的 SLO（服務級別目標）有關。 它主要是自動化。 因為，例如，我們的 SLO 是每季度 4 個九的正常運行時間。 這意味著在 3 個月內我們可以允許 13 分鐘的停機時間。 事實證明，MTTR 不能超過 13 分鐘。 如果我們在 13 分鐘內響應至少 1 次停機，這意味著我們已經用完了該季度的全部預算。 我們正在打破 SLO。 13 分鐘做出反應並修復崩潰對機器來說很長，但對人類來說卻很短。 因為直到一個人收到警報，直到他做出反應，直到他理解錯誤，這已經是幾分鐘了。 直到一個人明白如何修復它，究竟要修復什麼，要做什麼，然後再花幾分鐘。 事實上，即使您只需要重啟服務器（事實證明）或增加一個新節點，那麼手動 MTTR 已經大約需要 7-8 分鐘。 自動化流程時，MTTR 通常達到秒級，有時甚至是毫秒級。 谷歌通常談論毫秒，但實際上，當然，一切都不是那麼好。
理想情況下，SRE 應該幾乎完全自動化其工作，因為這直接影響 MTTR、其指標、整個服務的 SLO，以及相應的業務利潤。 如果超過時間，我們會被問及 SRE 是否有問題。 幸運的是，沒有人應該受到指責。 這是一種獨立的文化，叫做 balmeless postmortem，我們今天不談，但我們會在 Slurm 上分析它。 這是一個非常有趣的話題，可以說很多。 粗略地說，如果每季度超過分配的時間，那麼每個人都有一點責任，這意味著責備每個人是沒有成效的，讓我們相反，也許不責怪任何人，而是糾正這種情況並利用我們現有的工作。 根據我的經驗，這種方法對大多數團隊來說有點陌生，尤其是在俄羅斯，但它很有意義並且效果很好。 因此，我會在文章和文獻的末尾推薦您可以閱讀的有關該主題的文章。 或者來 Slurm SRE。
讓我解釋。 如果超過每季度的 SLO 時間，如果停機時間不是 13 分鐘，而是 15 分鐘，誰能為此負責？ 當然，SRE 可能是罪魁禍首，因為他顯然做出了某種錯誤的提交或部署。 數據中心的管理員可能要為此負責，因為他可能進行了某種計劃外的維護。 如果說這是數據中心管理員的責任，那麼Ops的人就是責任，他在協調SLO時沒有計算維護。 經理、技術總監或簽署了數據中心合同但沒有註意到數據中心的 SLA 不是為所需的停機時間設計的事實是造成這種情況的罪魁禍首。 因此，在這種情況下，所有一點點都是罪魁禍首。 這意味著在這種情況下沒有必要將責任歸咎於任何人。 但當然需要糾正。 這就是為什麼會有驗屍報告。 如果你讀過，例如，GitHub 事後分析，在每個特定案例中，這總是一個非常有趣、小而意想不到的故事，你可以取代沒有人說過這個特定的人是罪魁禍首。 責任總是歸咎於特定的不完善流程。
讓我們繼續下一個問題。 自動化。 當我在其他情況下談論自動化時，我經常參考一個表格，該表格告訴您可以在自動化任務上工作多長時間，而不需要花費比實際節省更多的時間來自動化它。 有一個障礙。 問題在於，當 SRE 自動化一項任務時，他們不僅節省了時間，還節省了資金，因為自動化直接影響 MTTR。 可以說，它們挽救了員工和開發人員的士氣，而這也是一種可以用盡的資源。 他們減少了常規。 所有這一切都對工作產生了積極影響，並因此對業務產生了積極影響，即使自動化似乎在時間成本方面沒有意義。
事實上，它幾乎總是如此，並且在極少數情況下，某些事情不應該在 SRE 的角色中被自動化。 接下來我們講什麼叫error budget，錯誤的預算。 事實上，事實證明，如果一切都比你為自己設定的 SLO 好得多，這也不是很好。 這相當糟糕，因為 SLO 不僅可以作為下限，還可以作為近似上限。 當你給自己設置一個 99% 可用性的 SLO，而事實上你有 99,99%，這表明你有一些空間進行實驗，這根本不會損害業務，因為你自己已經確定了這一切，而且你是這個空間不要用。 你有錯誤的預算，在你的情況下還沒有用完。
我們用它做什麼。 我們幾乎將它用於一切。 用於在生產條件下進行測試、用於推出可能影響性能的新功能、用於發布、用於維護、用於計劃的停機時間。 反向規則也適用：如果預算用盡，我們將無法發布任何新內容，否則我們將超過 SLO。 預算已經用完，如果它對性能產生負面影響，我們就發布了一些東西，也就是說，如果這不是某種本身直接增加 SLO 的修復，那麼我們就會超出預算，這是一個糟糕的情況，需要對其進行分析、事後分析，並可能進行一些流程修復。
也就是說，事實證明，如果服務本身不能很好地工作，並且 SLO 和預算不是花在實驗上，不是花在某些版本上，而是花在它本身上，而不是一些有趣的修復，而不是有趣的功能，而不是有趣的發布。 與任何創造性工作不同，您將不得不處理愚蠢的修復以使預算恢復正常，或者編輯 SLO，這也是一個不應該經常發生的過程。
因此，事實證明，在我們有更多錯誤預算的情況下，每個人都感興趣：SRE 和開發人員。 對於開發人員來說，大量的 bug 預算意味著您可以處理髮布、測試和實驗。 對於 SRE，錯誤預算和輸入該預算意味著他們直接做好了自己的工作。 這會影響某種聯合工作的動機。 如果您以開發人員的身份聽取 SRE 的意見，您將有更多的空間來做好工作，而例行公事會少得多。
事實證明，在大型團隊中，生產中的實驗非常重要，幾乎是 SRE 不可或缺的一部分。 它通常被稱為混沌工程，來自 Netflix 的團隊，該團隊發布了一個名為 Chaos Monkey 的實用程序。
Chaos Monkey 連接到 CI/CD 管道並隨機崩潰生產中的服務器。 同樣，在 SRE 結構中，我們正在談論一個事實，即一台宕機的服務器本身並不壞，這是意料之中的。 如果在預算之內，那是可以接受的，不會損害業務。 當然，Netflix 有足夠多的冗餘服務器，足夠多的複制，所以這一切都可以修復，以至於整個用戶甚至都不會注意到，更不會有人為了任何預算而留下一台服務器。
Netflix 擁有一整套此類實用程序已有一段時間，其中之一 Chaos Gorilla 完全關閉了亞馬遜的一個可用區。 這些事情首先有助於揭示隱藏的依賴關係，當不完全清楚什麼影響什麼，什麼取決於什麼時。 而且，如果您正在使用微服務，並且文檔不是很完善，那麼您可能很熟悉。 同樣，這有助於捕獲代碼中的錯誤，而這些錯誤在分段時無法捕獲，因為任何分段都不是完全精確的模擬，因為負載規模不同，負載模式不同，設備是還有，很可能，其他。 峰值負載也可能是意外和不可預測的。 此類測試同樣不會超出預算，有助於很好地捕獲暫存、自動測試、CI / CD 管道永遠不會捕獲的基礎設施中的錯誤。 只要這一切都包含在你的預算中，你的服務在那裡下降並不重要，雖然這看起來很可怕，服務器下降了，這是一場噩夢。 不，這很正常，這很好，有助於捕獲錯誤。 如果你有預算，那麼你可以花掉它。
Q：可以推薦什麼文學作品？ 名單在最後。 有很多文獻，我會建議一些報告。 它是如何工作的，SRE 在沒有自己的軟件產品或開發最少的公司中是否有效。 例如，在主要活動不是軟件的企業中。 在主要活動不是軟件的企業中，SRE 的工作方式與其他地方完全相同，因為在企業中你也需要使用，即使不是開發的軟件產品，你需要推出更新，你需要改變基礎設施，你需要成長，你需要擴展。 SRE 有助於識別和預測這些流程中可能出現的問題，並在開始增長和業務需求發生變化後控制這些問題。 因為如果您至少有幾台服務器並且預計您至少會有一些增長，那麼絕對沒有必要為了擁有 SRE 而參與軟件開發。
小型項目、小型組織也是如此，因為大公司有預算和空間進行試驗。 但與此同時，所有這些實驗成果都可以在任何地方使用，也就是 SRE，當然出現在 Google、Netflix、Dropbox 中。 但與此同時，小公司和初創公司已經可以閱讀濃縮材料、閱讀書籍、觀看報告。 他們開始更頻繁地聽到它，他們看具體的例子，我覺得沒關係，它真的很有用，我們也需要這個，太棒了。
也就是說，標準化這些流程的所有主要工作都已經為您完成。 您仍然需要確定 SRE 在您公司中的具體角色，並開始實際實施所有這些實踐，這些實踐已經再次描述過。 也就是說，從對小公司有用的原則來看，這始終是 SLA、SLI、SLO 的定義。 如果您不參與軟件，那麼這些將是內部 SLA 和內部 SLO，即錯誤的內部預算。 這幾乎總是會在團隊內部和業務內部引發一些有趣的討論，因為結果可能是你在基礎設施上花費了很多錢，在某種理想流程的組織上，理想的管道遠遠超過了必要。 你在 IT 部門擁有的這 4 個九，你現在並不真正需要它們。 但與此同時，你可以花時間，把錯誤的預算花在其他事情上。
因此，監控和監控組織對於任何規模的公司都是有用的。 總的來說，這種思維方式，錯誤是可以接受的，有預算的，有目標的，它對任何規模的公司都有用，從 3 人的初創公司開始。
最後要討論的技術細微差別是監控。 因為如果我們談論 SLA、SLI、SLO，如果不監控我們是否符合預算、是否符合我們的目標以及我們如何影響最終的 SLA，我們就無法理解。 我見過太多次監控是這樣發生的：有一些值，比如請求服務器的時間，平均時間，或者請求數據庫的次數。 他有一個工程師確定的標準。 如果指標偏離標準，則會收到一封電子郵件。 通常，這完全是無用的，因為它會導致大量警報，大量來自監控的消息，當一個人首先必須每次都解釋它們時，即確定指標的值是否意味著需要採取一些行動。 其次，當他基本上不需要採取任何行動時，他就不再注意到所有這些警報。 這是一個很好的監控規則，實施 SRE 的第一條規則是只有在需要採取行動時才應該發出通知。
在標準情況下，有 3 個級別的事件。 有警報，有票證，有日誌。 警報是需要您立即採取行動的任何事情。 也就是說，一切都壞了，您需要立即修復它。 門票是需要延遲行動的東西。 是的，你需要做一些事情，你需要手動做一些事情，自動化失敗了，但你在接下來的幾分鐘內不必做。 日誌是任何不需要操作的東西，一般來說，如果一切順利，就沒有人會閱讀它們。 回想起來，您只需要閱讀日誌，發現某些東西壞了一段時間，而我們並不知道。 或者你需要做一些研究。 但一般來說，不需要任何操作的所有內容都會進入日誌。
作為所有這一切的副作用，如果我們已經定義了哪些事件需要採取行動並且已經很好地描述了這些行動應該是什麼，這意味著該行動可以自動化。 也就是說，發生了什麼。 我們從警覺中走出來。 讓我們開始行動吧。 我們去描述這個動作。 然後我們轉向自動化。 也就是說，任何自動化都始於對事件的反應。
從監控，我們轉向一個叫做可觀察性的術語。 在過去的幾年裡，圍繞這個詞也有一些炒作。 很少有人能斷章取意地理解它的意思。 但要點是，可觀察性是衡量系統透明度的指標。 如果出現問題，您可以多快確定到底出了什麼問題以及當時系統的狀態。 在代碼方面：哪個功能失敗，哪個服務失敗。 例如，內部變量、配置的狀態是什麼。 在基礎設施方面，這是在哪個可用區發生故障，如果您安裝了任何Kubernetes，那麼故障發生在哪個pod，pod的狀態是什麼。 因此，可觀察性與 MTTR 有直接關係。 服務的 Observability 越高，越容易識別錯誤，越容易修復錯誤，越容易自動化錯誤，MTTR 越低。
再回到小公司，即使是現在，也很常見的問題是如何處理團隊規模，以及小團隊是否需要聘請單獨的 SRE。 之前已經談過這個。 在初創公司或團隊發展的第一階段，這完全沒有必要，因為 SRE 可以充當過渡角色。 這將使團隊恢復活力，因為至少存在一些多樣性。 此外，它會讓人們為這樣一個事實做好準備，即隨著增長，一般來說，SRE 的職責將發生非常顯著的變化。 如果你僱用一個人，那麼，他當然會有一些期望。 而且這些期望不會隨著時間的推移而改變，但是要求會發生很大的變化。 因此，早期如何聘請SRE是相當困難的。 自己種植要容易得多。 但值得思考。
也許唯一的例外是存在非常嚴格和明確定義的增長要求時。 也就是說，在初創公司的情況下，這可能是來自投資者的某種壓力，一次增長的某種預測。 那麼僱傭一個 SRE 基本上是合理的，因為它可以被合理化。 我們有成長的要求，我們需要一個人來負責這樣的成長不會破壞任何東西。
還有一個問題。 當開發人員多次削減一個通過測試的功能，但破壞生產、加載基礎、破壞其他功能時該怎麼辦，實施什麼過程。 因此，在這種情況下，引入了錯誤預算。 還有一些服務，一些功能已經在生產中進行了測試。 它可以是金絲雀，當只有少數用戶，但已經在生產中，部署了一個功能，但已經期望如果出現問題，例如，對於所有用戶的 XNUMX%，它仍然會滿足錯誤預算。 因此，是的，會出現錯誤，對於某些用戶來說一切都會崩潰，但我們已經說過這是正常的。
有一個關於 SRE 工具的問題。 也就是說，是否存在 SRE 會特別使用而其他人不會使用的東西。 事實上，有一些高度專業化的實用程序，例如模擬負載或從事金絲雀 A/B 測試的某種軟件。 但基本上 SRE 工具包是您的開發人員已經在使用的工具包。 因為 SRE 直接與開發團隊交互。 而且，如果您有不同的工具，結果會發現同步需要時間。 特別是如果 SRE 在大型團隊中工作，在可以有多個團隊的大公司中，公司範圍內的標準化將在這裡提供很大幫助，因為如果在 50 個團隊中使用 50 個不同的實用程序，這意味著 SRE 必須了解它們全部。 當然，這永遠不會發生。 並且工作質量，至少部分團隊的控制質量會顯著下降。
我們的網絡研討會即將結束。 我設法講了一些基本的事情。 當然，任何關於 SRE 的東西，一個小時都講不完，也講不明白。 但我希望我設法傳達了這種思維方式，主要要點。 然後，如果有興趣，就可以深入研究這個話題，自己學習，看看其他人、其他公司是如何實施的。 因此，在 XNUMX 月初，請來 Slurm SRE 找我們。
Slurm SRE 是一個為期三天的強化課程，會講我現在講的內容，但深度要深得多，有真實案例，有實踐，整個強化課程都是針對實際工作的。 人們將被分成小組。 你們都將處理真實案例。 因此，我們有 Booking.com 講師 Ivan Kruglov 和 Ben Tyler。 我們有一位來自舊金山的 Google 的出色 Eugene Barabbas。 我也會告訴你一件事。 所以一定要拜訪我們。
所以，參考書目。 SRE 上有參考資料。 在同一本書上，或者更確切地說，在谷歌寫的兩本關於 SRE 的書上。 另一個 ，其中術語及其應用稍微更詳細。 接下來的 3 個是不同公司關於 SRE 的報告。 第一的 - ，這是來自谷歌的 Ben Trainer 的主題演講。 第二 - . 第三個又是 . 第四次報告來自 ，在 5 個國家/地區只有 190 名主要 SRE 員工。 看看這一切是非常有趣的，因為正如 DevOps 對不同的公司甚至不同的團隊意味著非常不同的東西一樣，SRE 有非常不同的責任，即使在類似規模的公司中也是如此。
關於混沌工程原理的另外 2 個鏈接： , . 最後有 3 個來自 Awesome Lists 系列的列表 約 和關於 . SRE 上的列表非常龐大，沒有必要全部看完，大約有 200 篇文章。 我強烈推薦那裡有關容量規劃和無過錯事後分析的文章。
有趣的文章：
謝謝你一直以來都在聽我說話。 希望你學到了一些東西。 希望你有足夠的材料來學習更多。 再見。 希望在二月份。
網絡研討會由 Eduard Medvedev 主持。
PS：對於喜歡閱讀的朋友，Eduard給出了一份參考文獻清單。 喜歡在實踐中了解的朋友歡迎 .
來源： www.habr.com