1. 服務級別幫助你定義客戶滿意的程度和標準，以便你在解決性能、可擴展性挑戰等事情與開發內部工具之間做出時間權衡

2. 服務水平指標（SLI）

2.1. 如何衡量客戶是否滿意

3. 服務水平目標（SLO）

3.1. 為了確保客戶滿意，能允許SLI達到的最低限度是多少

3.2. 將特定的SLI視為健康服務的目標範圍

3.2.1. 必須定義為給定時間範圍內的一個具體值，以確保每個人都對SLO的含義保持一致的理解

3.2.2. 如果SLI的指標是服務正常運行的時間，那麼在給定的時間範圍內，運行時間達到幾個9就是SLO

4. 服務水平協議（SLA）

4.1. 我同意的SLO會產生什麼後果

4.1.1. SLA是可選的

4.2. 與一個或多個業務客戶（付費客戶，而非內部利益相關者）簽訂的協議中包含的SLO，如果未滿足該SLA，將受到財務或其他處罰

4.3. 如果團隊沒有達到其承諾的SLO，則不應繼續進行新特性的工作

5. 怎樣才能讓客戶滿意

5.1. 目標是定義確保客戶滿意的最低標準

5.2. 選擇指標和目標的目的是隨時使用客觀指標評估團隊是否能夠利用新功能進行創新，或者穩定性是否有可能降至客戶可接受的水平以下，因此需要更多的關註和資源

5.3. 承諾的“9”越多，就越難實現，團隊為實現這一承諾所花費的工程時間也就越昂貴

5.4. 達到3個9的可用性

5.4.1. 一年中的3個9相當於8個多小時的停機時間

5.4.2. 轉換到一周則只有10分鐘

5.5. 999圖

5.6. 工程時間是有限的資源

5.6.1. 選擇SLO時必須註意不要過於追求完美

5.6.2. 將工程時間花在新功能上

5.6.3. 將時間花在可恢復性和修複問題上

5.7. 不是產品中的所有特性都需要這麼多個9才能讓客戶滿意

5.7.1. 隨著產品特性集的增長，將會有不同的SLI和SLO，具體取決於特定功能的影響或其帶來的收入

5.8. 區分不同用戶的需求，以便可以為他們提供合理的SLI和SLO

5.8.1. 檢測數據集何時成為不同用戶的不同查詢概要文件（query profile）的瓶頸，從而影響性能

6. 有效管理MySQL的一個關鍵點在於對資料庫的健康狀況進行良好的監控

7. 可用性

7.1. 能夠無錯誤地響應客戶的請求

7.1.1. 明確成功的響應

7.1.1.1. 200響應代碼

7.1.2. 成功接受請求並承諾非同步完成相關工作的響應

7.1.2.1. 202已接受

7.2. 沒有要求必須做到100%，因為我們在一個不可避免失敗的世界中運作

7.3. 不應該用一個指標來確定所有要求

7.4. 如果一個供應商的競爭優勢是分析MySQL性能的特定任務，那麼付費是可以給組織帶來回報的

7.4.1. SolarWinds資料庫性能管理工具

7.5. Percona監控和管理工具是一個成熟的開源選項

7.5.1. PMM

7.5.2. 儀錶盤的組織是由Percona社區在監控MySQL性能方面的長期經驗指導的

7.6. 將資料庫慢查詢日誌和MySQL PerformanceSchema的輸出信息發送到一個集中的位置，然後可以使用像pt-query-digest（Percona Toolkit包中的工具）這樣的成熟工具來分析日誌，並更深入地瞭解資料庫實例在哪些方面花費了時間

7.7. 在性能倒退的情況下，花費生產之外的精力去調查“發生了什麼”遠比試圖重新創建一個模擬更大代碼路徑的基準測試套件要具體得多

7.8. 可用性轉換為資料庫架構的SLI和SLO時

7.8.1. 在處理不可避免的災難性故障時，哪些功能是不可協商的，哪些功能是“最好擁有的”

7.8.2. 將哪些類型的失敗定義為“災難性的”

7.8.3. “降級功能”是什麼樣子的

7.8.4. 給定一組可能的故障場景

7.9. 驗證可用性的首選方法是從客戶端或遠程端點來進行訪問

7.10. MySQL中有一個Threads_running狀態計數器可以作為可用性問題的關鍵指標

7.11. Thread_running與max_connections的差距，將此差距作為另一個數據點，以檢查正在進行的工作是否過載

8. 監控查詢延遲

8.1. MySQL引入了許多長期需要的增強功能來跟蹤查詢運行所需的時間

9. 監控報錯

9.1. MySQL客戶端在訪問運行著的服務的過程中出現錯誤並不一定意味著服務遭到破壞

9.2. 間歇性錯誤，通過簡單地重試失敗的查詢就可以解決這些錯誤

9.3. 錯誤發生的頻率可能是潛在問題的關鍵指標

9.3.1. 如果報錯的頻率加快，則是將要出現問題的跡象

9.4. Lock wait timeout

9.4.1. 如果客戶端中該報錯急劇增加，可能是主節點上的行級鎖爭用在不斷擴大，即事務不斷重試但仍然失敗

9.4.2. 可能是無法寫入的前兆

9.5. Aborted connections

9.5.1. 如果客戶端中該報錯突然激增，可能表明客戶端和資料庫實例之間的某個訪問層出現了問題

9.5.2. 跟蹤這一點會導致大量客戶端重試，這會消耗資源

9.6. too many connections

9.7. 操作系統級別的“cannot create new thread

9.8. 應用程式創建和打開的連接數超過了資料庫伺服器配置中允許的連接數，這個限制可能來自伺服器的max_connections變數或者MySQL進程被允許打開的線程數

10. 主動監控

10.1. 不要將所有精力都集中在顯示事故發生的指標上，而是應花一些時間來監控可以幫助預防事故的事情

10.2. 磁碟空間使用率增長

10.2.1. 設置多個閾值，其中較低的警告可以設置為僅在工作時間觸發，而較高的、更嚴重的值則作為對非工作時間隨叫隨到的告警

10.3. 連接數增長

10.3.1. 流量不斷增長時，資料庫伺服器可以支持有限的連接池，這被配置為伺服器參數max_connections

10.3.2. 應用程式層打開了大量未使用的連接，導致產生了毫無理由的連接過多的風險

10.3.2.1. 連接的線程數（threads_connected）很高，但運行的線程數（threads_running）仍然很低

10.3.3. 應用程式層正在積極地使用大量的連接，並有導致資料庫過載的風險

10.3.3.1. 連接的線程數（threads_connected）和運行的線程數（threads_running）都處於高值並持續增加

10.4. 複製延遲

10.4.1. 能夠被視為一種重要的SLI指標，它能引起異常事故

10.4.2. 複製延遲可能會使數據看起來不一致

10.4.3. 即使複製延遲從未達到影響客戶體驗的程度，如果偶然出現，這仍然是一個比較明顯的跡象，說明當前配置下源節點寫入設備的性能要強於副本節點，這可能預示系統寫容量出現不足

10.5. I/O使用率

10.5.1. “儘可能多地在記憶體中工作，因為這樣更快”

10.5.1.1. 資料庫工程師不斷努力的目標之一

10.5.2. 不要從磁碟讀取太多的數據，否則查詢就只能等待那些寶貴的I/O周期

10.5.3. iostat這樣的工具可以監控I/O等待

10.5.4. 如果資料庫伺服器有很多線程位於IOwait狀態，則需要監控發出告警，這表示它們正在隊列中等待某些磁碟資源可用

10.6. 自增鍵空間

10.6.1. 自動遞增主鍵在預設情況下被創建為有符號整數，並且可能會耗盡鍵空間

10.6.2. 為所有使用自增主鍵的表監控剩餘整數空間是一個簡單的操作，但幾乎可以肯定的一點是，它會在將來為你避免一些重大事故，因為可以提前預測需要更大的鍵空間

10.6.3. 使用了PMM及其Prometheus導出器（exporter），那麼已經自帶監控方法，你需要做的就是開啟collect.auto_increment.columns設置

10.7. 創建備份/恢復時間

10.7.1. 監控將備份從文件恢復到運行的資料庫（該資料庫自創建備份以來還一直在複製所有更改）需要多長時間

10.7.2. 功能分片（Functional sharding）是指將服務於特定業務功能的特定表分割到一個專用的集群中，以便單獨管理該數據集的正常運行時間、性能甚至訪問控制

10.7.3. 水平分片（Horizontal sharding）是指當數據集的大小超過了可以在單個集群中可靠地提供服務的規模時，將它拆分為多個集群，並從多個節點提供數據，這依賴於某種查找機制來定位所需的數據子集

11. 長期性能

11.1. 業務節奏

11.1.1. 業務節奏可能意味著峰值流量時間比“平均值”大幾個數量級，如果資料庫基礎架構沒有準備好，將產生很多不良結果

11.1.2. 業務周期可能會因業務所滿足的客戶需求而大不相同

11.1.3. 瞭解業務周期以及對業務收入、聲譽的影響至關重要

11.2. 業務的長期規劃

11.2.1. 為未來的容量做規劃

11.2.2. 預見何時需要重大改進，何時增量修改就夠了

11.2.3. 為運行基礎架構增加的成本做規劃

11.3. 提高透明度，重點是跟蹤結果而不是輸出

11.4. 對平均值說不

11.4.1. 平均值的數據點圖很可能會讓你產生錯誤的安全感

11.5. 與百分位為友

11.5.1. 百分位依賴於在給定的時間範圍內對數據點進行排序，並根據目標百分位移除最高值的數據點（例如，如果要尋找95百分位，則移除最頂端的5%）

11.6. 使用SLO來指導整體架構

11.6.1. 在業務增長的同時保持良好一致的客戶體驗不是一件容易的事

11.6.2. 隨著業務規模的增長，保持相同的SLO都將變得越來越困難，更不用說制定更雄心勃勃的SLO了

11.6.3. 你希望實現的SLO越嚴格，工作成本就越高，因為每秒的資料庫事務數峰值或數據量也會呈數量級的方式增長