b. google sre指導思想
擁抱風險
服務質量目標
服務質量指標
常見指標
錯誤率系統吞吐量
可用性永續性：資料能夠完整儲存的時間
等等分類
通用的指標：正確性
使用者可見的服務系統：可用性、延遲、吞吐量
儲存系統：延遲、可用性和資料永續性
大資料系統：吞吐量、端到端延遲
彙總平均值：掩蓋分布變化和受長尾效應影響
分布（百分位）
標準化：需要形成sli模板
彙總間隔：每 1 分鐘彙總一次
彙總範圍：集群中的全部任務
度量頻率：每10秒一次
包含哪些請求：從黑盒監控任務發來的 http get請求
資料如何獲取：通過監控系統獲取伺服器端資訊得到
資料訪問延遲：從收到請求到最後乙個位元組被發出
服務質量目標：某個指標的目標值或者目標範圍
目標定義
目標的選擇
不要僅以目前的狀態為基礎選擇目標：例如系統重構會影響到slo等
保持簡單：質量指標盡可能的簡單
避免絕對值：目標以區間為宜，系統在沒有延遲增長的情況下無限擴張或許能夠做到，但是代價也是巨大的
slo越少越好
不要追求完美
案例：chubby：計畫內停機。當chubby的slo遠超預期的時候，會人為地停止服務，從而找出哪些服務對chubby不合理的依賴。
服務質量協議
分布式系統監控
觀點google趨向於使用監看和快速的監控系統配合高效的工具進行事後分析。我們會避免任何「魔法」系統 --- 例如試圖自動學習閾值或者自動檢測故障原因的系統
監控型別
白盒監控
黑盒監控
4個**指標
延遲：處理某個請求所需要的時間
流量：http請求數量，或者網路i/o速率，或者併發會話數
錯誤：有可能是顯示錯誤、隱式錯誤（返回錯誤資訊）、或者策略性錯誤（比如說超過1s返回就算錯）
飽和度：很多服務在資源占用達到100%之前，效能就已經嚴重下降了
長尾問題：例如平均響應時間100ms，但是1%的請求會佔到5s
分位數統計
分組：比如說0~10ms請求數，30~100ms請求數，等等
不同指標採用不同的精度
比如cpu 1分鐘的平均負載，可能措施峰值
年度可用性在99.9%的服務每分鐘檢測1~2次可能過於頻繁
年度可用性在99.9%的服務每分鐘檢測磁碟容量可能過於頻繁
等等戰術
短期可用性和長期可用性之間的衝突和平衡
自動化系統
瑣事手動性
重複性的
可以被自動化的
戰術性的
沒有持久價值
與服務同步線性增長
價值一致性：如果是人工操作，無法保證針對同乙個故障每次操作結果都是一致的
平台性修復速度快
行動速度更快
節省時間
型別指令碼自動化
borg/kubernetes
上線自動化
發布工程
非哥指導思想
關係 思考關聯，所有的資料，函式，其實都是互相關聯的，這乙個函式的輸出，是另外乙個函式的輸入，重點是搞清楚，思考明白 這些函式關係的相互關係是什麼？重點整理清除他們的相互關係。舉例 開炮事件的業務關聯 非哥畫的每一條線，都不是白畫的呀 還有乙個是業務拆分，所有的業務都可以拆解為 輸入 處理了 輸出 ...
設計效能良好系統的指導思想
簡而言之，如果將你的cpu的速度加快一倍，那麼你通常可以獲得接近兩倍的吞吐量。僅僅將網路的容量加倍通常沒有效果，因為瓶頸一般在主機上。每乙個到來的分組都會引發乙個中斷。在現代的流水線方式的處理器上，每個中斷都會打斷cpu流水線 干擾快取的工作 要求改變記憶體管理環境，並且強迫儲存相當數量的cpu暫存...
個人認為，CMMI整體的減法指導思想是錯的
近期，我準備帶領團隊，根據自己的理解做出一些調整。總體感覺，cmmi體系很龐大，在整個軟體開發過程中，對於具體細節的工作有很好的指導意義，但是，我參加整個培訓和經過一段時間的管理實踐，最大的感覺是cmmi整體的指導思想從根本上就是 錯 的，而對於具體工作的研發過程和操作步驟有很好的參考價值，也許從二...