主要 SRE 準則與實務：良性循環
如果「你所做的事，定義了你是什麼樣的人」這句話在某種意義上屬實，那麼我們已觸及本課程模組的核心。 在本單元中，我們將研究兩種通常會視為 SRE 實務核心的實務。 兩者都源自於務必建立「良性循環」的原則。在此內容中，良性循環是在組織中建置意見反應循環的實務，有助於組織持續變得更好。 正確來說，我們對於這兩種實務將有完整的後續課程模組，所以我們在此只會快速瀏覽每一個課程模組的概觀。
良性循環其一：SLI 和 SLO
稍早在本課程模組中，我們著重在落實「適當的可靠性」。 此章節這正是該概念所在之處。
假設您有一項計畫投入生產的新服務 (已構建的服務，或仍處於規劃程序中的服務)。 作為該程序的一部分，必須先決定它所需的可靠性。 如果您不是自己撰寫所有程式碼，那麼就會與撰寫程式碼的開發人員共同作業來做出這些決定 (這一點十分重要)。
應做出的第一個決定，是要將什麼用作服務健康情況的指標 (服務等級指標或 SLI)？ 另一種提出此問題的方式是「如何知道什麼時候在運作、什麼時候運作良好？」。 有許多方式可以追蹤 SLI，我們稍後會詳細探索某些部分。 但是，這些指標通常是：
- 成功與失敗量值。 服務是否成功完成某個時間百分比的作業？
- 時間的量值。 我們在特定時間閾值內是否傳回應答？
- 輸送量的量值。 我們處理了一定數量的資料嗎？
或者，所有這些量值的某些組合。
舉一個簡單的例子，我們可以說我們服務的 SLI，就是其傳回成功的頻率，以 HTTP 200 程式碼來表示 (對 500 或其他某些程式碼)。
現在我們有清楚的指標，告訴我們服務的運作方式。 我們想要決定預期或想要的可靠性等級。 例如，我們是否預期在一天的期間內會看到服務的失敗率為 20%？ 我們在這裡使用整數和大型數字，因為在開始時較易於理解。 在稍後的課程模組中，我們將增加陳述的複雜度和精確度，像是 (「哪些使用者會看到錯誤率？其中某些？還是大多數？」) 等等。 與服務開發人員共同作業建立的期望，就是服務等級目標 (SLO)。
SLO 需要能夠在您的監視系統中精確測量和表示。 這對於服務的可靠性來說，是客觀、清楚理解的目標：什麼是夠好的數字？ 沒有「嗯，我認為服務在過去一週左右一直沒問題，但又很難說」這種事。 服務是否滿足其 SLO，資料應該要很清楚。 如果服務沒有滿足其 SLO (特別是在一段時間內重複進行)，則代表有問題需要解決。
誤差預算
我們可以了解，如果服務未達到其 SLO，組織可能會立即採取行動。 不過，SRE 會在達到或超過 SLO 的情況下，讓這整個概念有所改善。 某些組織會使用 SLO 來建構其所稱的「誤差預算」。
為了示範這個概念，讓我們使用我們一直在討論的範例服務，及其 80% 成功的 SLO (可以將其視為「80% 的時間都正常運作」)。 由於 SLO 的運作時間為 80%，我們宣告我們服務的運作時間必須達到 80%。 但另外的 20% 呢？ 如果我們的服務在另外的 20% 時間並未正常運作，我們也不會真的「在意」，因為在我們的服務目標中，那額外的 20% 對我們來說並不那麼重要。
那麼，如果我們不在意那段時間發生的事情，我們可以對服務做些什麼呢？ 我們可以做的其中一件事，是透過升級來擾亂正在執行的服務，或許再多一個新增某些功能的新版本。 如果新版本保持運作且不會增加任何停機時間，那就太好了。 如果新版本導致服務不穩定，並且在偵錯時傳回錯誤，佔用了 10% 的時間，仍然可以接受。 我們仍處於允許的不可靠性預算範圍內。
誤差預算是服務的潛在完美可靠性，與其所需可靠性之間的差異 (100%-80%= 20%)。 在這種情況下，誤差預算為我們提供了 20% 不可靠性的資本：對於這 20% 的時間，我們「不在意其是否正常，因為仍然符合規定」。 我們可以用任何我們想要的方式 (或許是更多的版本) 來利用並花費 20% 的時間，直到像任何其他預算一樣耗盡為止。
某些組織也會使用誤差預算來處理不太令人滿意的案例，即不進行 SLO 的情況。 在這種情況下，除了採取「小動作」，您可以選擇實施更嚴格的措施。 假設我們的服務遇到了一些問題，而且先前選擇的 SLI 指出服務只有 60% 的運作時間。 我們沒有達到我們的目標 (SLO)。 我們的服務已耗盡誤差預算。 組織可能會選擇暫停規劃中的版本，因為知道此時進一步擾亂系統可能只會進一步惡化可靠性情況。 誤差預算通常會在一段時間內計算；一個月、一季等等。 如此一來，當服務可靠性改善時，預算就會返回。
在閘道發行期間，組織可能會選擇將一些工程資源從功能開發轉為可靠性工作。 目標是協助發現並改善導致服務未達到其 SLO 的問題根源。
我們之所以在誤差預算方面說「某些組織」是因為他們的實作，特別是在用於閘道發行的情況下，需要一定的機構支援。 在面對發行決策時，如果迄今為止服務的可靠性還沒有達到要求，那麼組織必須願意暫停發行。 該決策並非是所有組織都願意做出的決策。 對耗盡的誤差預算來說，此決策也不是唯一可能的回應，卻是最受關注的。
在個別的課程模組中，我們會更詳細地討論 SLA、SLO 和錯誤預算。 但是，值得在這裡強調這些做法的良性循環層面。 理論上來說，這個層面為組織提供了一種方式，來描述、溝通和採取服務可靠性。 然而這個方式讓每個人都朝著更佳可靠性而努力。 這樣的意見反應循環非常重要。
良性循環其二：不加責備的事後檢討
事後檢討的概念 (對重要但通常不希望發生的事件進行追溯性分析) 對網站可靠性工程來說一點也不特別。 甚至對於作業界來說十分常見。 比較與眾不同的是，SRE 堅持認為事後檢討需要「不加責備」。 需要專注於程序的失敗，或是事件期間的技術，而不是特定人員的動作。 「我們採用的程序中，是什麼讓 X 能夠做出導致失敗的事情？ 在導致那個人做出錯誤結論的那一刻，是因為那個人沒有得到什麼資訊，還是因為得到了什麼過於突出的資訊？ 是否本來應該要具備什麼樣的護欄，才能防止這樣的災難性失敗？ 這些是在不加責備的事後檢討中，應該提出的問題類型。
這些問題的要旨與方向十分重要。 我們應該尋找改善系統或程序的方法，而不是懲罰妥善使用系統或程序卻不慎造成中斷的個人。 重要的是要記住「你無法靠炒魷魚來解決可靠性問題」。 根據我們的經驗，如果組織在每次出現生產事件時就開除員工 (只有少數特例)，組織就無法從這些事件中汲取經驗教訓。 相反地，這會導致離開的員工內心受挫，再也不敢對任何事情做出任何改變。
但是，組織中完善的事後檢討程序會建立一個良性循環。 這會讓組織從中斷中學習並不斷改善其系統 (前提是完成適當的分析和後續工作)。
這種對故障和錯誤的關係 (組織視為學習和改善的機會)，即為網站可靠性工程的核心準則。 建構良性循環以利用這些機會並指導組織提升可靠性，則是另一個核心準則。
讓我們在下一個單元中探索一些其他原則和實務，這些原則和實務專注於 SRE 的人性方面。