研發（dev）與運維（ops）分離導致的問題
直接成本：
隨著產品及專案增多，相應人員線性增加。間接成本：
研發與運維團隊背景各異，技術能力與工具使用習慣存在差距，工作目標不同；
研發與運維團隊對產品可靠程度要求不同，具體執行某項操作的危險程度評估與技術防範措施不同。
以上逐漸演變成目標與方向上的分歧及形成溝通問題，容易出現信任、尊重等問題
如何減少更新故障—以下兩點均不是最優
運維：給研發制定嚴格上線流程；
研發：不再大規模更新，而是轉為功能開關調整、增量更新、補丁等方式繞過各種流程。
sre方**：
sre團隊承擔以下幾類原則：
- 可用性改進
- 延遲優化
- 效能優化
- 效率優化
- 變更管理
- 監控
- 緊急事務處理
- 容量規劃與管理
針對以上內容制定一套完整的溝通準則和行事規範
事後總結
所有產品事故都應該有事後總結，無論有沒有觸發告警；
如果乙個產品事故沒有觸發警報，它的總結意義更大
它揭示監控系統存在漏洞，事故總結應該包括：事故發生、發現、解決的全過程，事故的根本原因，預防或者優化的解決方案。
服務可靠性目標需要考慮的方面
監控系統
監控系統是sre團隊監控服務質量和可靠性的乙個主要手段
乙個監控系統應該有三類輸出：
- 緊急警報 alert 必須立即處理
- 工單 ticket 可延後處理
- 日誌 logging 僅收集相關資訊
應急事件處理
mttf：平均失敗時間
mttr：平均恢復時間
任何需要人工操作的事情都只會延長恢復時間，儘量減少人工干預，通過事先預案並且將最佳方法記錄在運維手冊。
變更管理
變更管理的最佳實踐是使用自動化完成以下專案：
1. 採用漸進式發布機制
2. 迅速而準確檢測到問題的發生
3. 安全迅速的回退改動
效率與效能
高效的資源利用率需要：使用者需求、可用容量、軟體資源使用率來驅動
SRE Google運維解密 心得
在乙個執行的系統中，出現風險是不可能避免的，而運維工程師的存著便是控制並解決風險。書中提到構建百分百可靠的服務是不可取的，因為乙個服務面向使用者的不止是可靠，還有創新。當可靠性達到一定的數量級後，再花費大量的成本在可靠性上而忽略服務的創新，這種方式得不償失。書中還提到可用性為多少個 9 這個概念 上...
讀SRE Google運維解密有感 二
這是讀 sre google運維解密 有感第二篇，第一篇參見 這本書最近又讀了幾章，結合自己的經歷，有些地方真的能感同身受，有些地方也驚嘆sre充滿辯證的思想，總之sre是好一本好書，會給你很大的啟發。本書主要是講通過sre思想進行運維體系的構建，除了技術層面以外，我更關注sre內在充滿辯證的思想。...
運維第一次作業
kiosk foudation7 desktop date h m s time.txt kiosk foudation7 desktop cat etc passwd head n 18 tail n 3 systemd network x 998 996 systemd network mana...