不能將碰運(yùn)氣當(dāng)成戰(zhàn)略. —— SRe俗語
SRE：Site Reliability Engineering;專注于整個(gè)軟件系統(tǒng)的生命周期管理烛愧，goole將此職位稱為站點(diǎn)可靠性工程師(SRE);
1.SRE是工程師澈歉，SRE使用計(jì)算機(jī)科學(xué)和軟件工程手段來設(shè)計(jì)和研發(fā)大型草戈、分布式計(jì)算機(jī)軟件系統(tǒng)台颠。
2.SRE的關(guān)注焦點(diǎn)在于可靠性定嗓】莶溃可靠性應(yīng)該是任何產(chǎn)品設(shè)計(jì)中最基本的概念:任何一個(gè)系統(tǒng)如果沒有人能夠穩(wěn)定的使用注整，就沒有存在的意義。SRE專注于對(duì)其負(fù)責(zé)的軟件系統(tǒng)架構(gòu)設(shè)計(jì)度硝、運(yùn)維流程的不斷優(yōu)化肿轨，讓大型軟件系統(tǒng)運(yùn)行的更可靠，擴(kuò)展性更好蕊程，能更有效的利用資源椒袍。
3.SRE的主要工作是運(yùn)維在分布式集群管理系統(tǒng)上運(yùn)行的具體業(yè)務(wù)服務(wù)，不論是儲(chǔ)存服務(wù)藻茂、web搜索服務(wù)驹暑、E-mail服務(wù)。
SRE職責(zé)：
可用性改進(jìn)辨赐、延遲優(yōu)化优俘、性能優(yōu)化、效率優(yōu)化掀序、變更管理帆焕、監(jiān)控、緊急事務(wù)處理不恭、容量規(guī)劃與管理
SRE準(zhǔn)則：
1.在每8-12小時(shí)的on-call輪值期間最多只處理兩個(gè)緊急事件叶雹，事后撰寫事后報(bào)告。
2.如果一個(gè)產(chǎn)品事故沒有觸發(fā)警報(bào)县袱，事后總結(jié)意義更大，因?yàn)樗梢越沂颈O(jiān)控系統(tǒng)中的漏洞佑力。
3.事故報(bào)告：事故發(fā)生式散、發(fā)現(xiàn)、解決的全過程打颤、事故根本原因
產(chǎn)品預(yù)算- 研發(fā)團(tuán)隊(duì)與SRE團(tuán)隊(duì)
- 基于用戶的使用習(xí)慣暴拄，服務(wù)可靠性要達(dá)到什么程度用戶才會(huì)滿意？
- 如果這項(xiàng)服務(wù)的可靠程度不夠编饺，用戶是否有其它的替代選擇乖篷？
- 服務(wù)的可靠程度是否會(huì)影響用戶對(duì)這項(xiàng)服務(wù)的使用模式？
監(jiān)控系統(tǒng)
監(jiān)控系統(tǒng)是SRE團(tuán)隊(duì)監(jiān)控服務(wù)質(zhì)量和可用性的一個(gè)主要手段透且。
最普遍的和傳統(tǒng)的報(bào)警策略是針對(duì)某個(gè)特定的情況或者監(jiān)控值撕蔼，一旦出現(xiàn)情況或者監(jiān)控超過閥值就觸發(fā)E-mai警報(bào)豁鲤。但是這樣的報(bào)警策略并不是非常有效：一個(gè)需要人工閱讀郵件和分析警報(bào)來決定目前是否需要采取某種行動(dòng)的系統(tǒng)從本質(zhì)上就是錯(cuò)誤的。監(jiān)控系統(tǒng)不應(yīng)該依賴人來分析警報(bào)信息鲸沮，而是應(yīng)該由系統(tǒng)自動(dòng)分析琳骡，僅當(dāng)需要用戶執(zhí)行某種操作時(shí)，才需要通知用戶讼溺。
一個(gè)監(jiān)控系統(tǒng)應(yīng)該有三類輸出：
- 緊急警報(bào)（意味著收到警報(bào)的用戶需要立即執(zhí)行某種操作楣号，目標(biāo)是解決某種已經(jīng)發(fā)生的問題或者避免即將發(fā)生的問題）
- 工單（意味著接受工單的用戶應(yīng)該執(zhí)行某種操作，但是并非立即執(zhí)行怒坯。系統(tǒng)并不能自動(dòng)解決目前的情況炫狱，但是如果一個(gè)用戶在幾天內(nèi)執(zhí)行這項(xiàng)操作，系統(tǒng)不會(huì)受到任何影響）
- 日志（平時(shí)沒有人需要關(guān)注日志信息剔猿，但是日志信息依然被收集起來以備調(diào)試和事后分析時(shí)使用视译。正確的做法是平時(shí)沒人會(huì)去主動(dòng)閱讀日志，除非有特殊需要）
應(yīng)急事件處理
一個(gè)可以自動(dòng)恢復(fù)的系統(tǒng)即使有更多的故障發(fā)生艳馒，也要比事事都需要人工干預(yù)的系統(tǒng)可用性更高憎亚。
通過事先預(yù)案并且將最佳方法記錄在“運(yùn)維手冊(cè)”上通常可以使MTTR（平均恢復(fù)時(shí)間）降低3倍以上弄慰。
變更管理
大概70%的生產(chǎn)事故由某種部署的變更而觸發(fā)第美。變更管理的最佳實(shí)踐是使用自動(dòng)化來完成以下幾個(gè)項(xiàng)目：
- 采用漸進(jìn)式發(fā)布機(jī)制
- 迅速而準(zhǔn)確的檢測(cè)到問題的發(fā)生
- 當(dāng)出現(xiàn)問題時(shí)，安全迅速的退回改動(dòng)
需求預(yù)測(cè)和容量規(guī)劃
需求預(yù)測(cè)和容量規(guī)劃就是保障一個(gè)業(yè)務(wù)有足夠的容量和冗余度去服務(wù)預(yù)測(cè)中的未來需求陆爽。一個(gè)業(yè)務(wù)容量的規(guī)劃什往，不僅要包含自然增長(zhǎng)（隨著用戶使用量上升，資源用量也上升）慌闭，也需要包括一些非自然增長(zhǎng)的因素（新功能發(fā)布别威、商業(yè)推廣、以及其它商業(yè)因素）
容量規(guī)劃的步驟：
- 必須有一個(gè)準(zhǔn)確的自然增長(zhǎng)需求預(yù)測(cè)模型驴剔，需求預(yù)測(cè)的時(shí)間應(yīng)該超過資源獲取的時(shí)間
- 規(guī)劃中必須有準(zhǔn)確的非自然增長(zhǎng)的需求來源的統(tǒng)計(jì)
- 必須有周期性壓力測(cè)試省古，以便準(zhǔn)確的將系統(tǒng)原始資源信息與業(yè)務(wù)容量對(duì)應(yīng)起來
1.概覽
物理服務(wù)器（machine）：
代表具體的硬件（有時(shí)候也代表一個(gè)VM虛擬機(jī)）
軟件服務(wù)器（server）：
代表一個(gè)對(duì)外提供服務(wù)的軟件系統(tǒng)。
2.分布式系統(tǒng)的監(jiān)控
監(jiān)控
收集丧失、處理豺妓、匯總、并且顯示關(guān)于某個(gè)系統(tǒng)的實(shí)時(shí)量化數(shù)據(jù)布讹，例如請(qǐng)求的數(shù)量和類型琳拭，錯(cuò)誤的數(shù)量和類型，以及處理用時(shí)描验，應(yīng)用服務(wù)器的存活時(shí)間等白嘁。
白盒監(jiān)控：
依靠系統(tǒng)內(nèi)部暴露的一些性能指標(biāo)進(jìn)行監(jiān)控。包括日志分析膘流、Java虛擬機(jī)提供的監(jiān)控接口絮缅、或者一個(gè)列出內(nèi)部統(tǒng)計(jì)數(shù)據(jù)的HTTP接口進(jìn)行監(jiān)控鲁沥。
黑盒監(jiān)控：
通過測(cè)試某種外部用戶可見的系統(tǒng)行為進(jìn)行監(jiān)控演顾。
控制臺(tái)頁面：
提供某個(gè)服務(wù)核心指標(biāo)一覽服務(wù)的應(yīng)用程序（一般基于Web）陈轿。該應(yīng)用程序可能會(huì)提供過濾功能它褪、選擇功能等扩淀，但是最主要的功能是用來顯示系統(tǒng)最重要的指標(biāo)桑寨。該程序同時(shí)可以顯示相應(yīng)團(tuán)隊(duì)的一些信息碉钠，包括目前工單的數(shù)量驳糯、高優(yōu)先級(jí)的Bug列表吼鳞、目前on-call工程師和最近進(jìn)行的生產(chǎn)發(fā)布等奄抽。
警報(bào)：
目標(biāo)對(duì)象是某個(gè)人向發(fā)向某個(gè)系統(tǒng)地址的一個(gè)通知蔼两。目的地可以包括工單系統(tǒng)、E-mail地址逞度，或者某個(gè)傳呼機(jī)额划。
根源問題：
指系統(tǒng)中的某種缺陷。這個(gè)缺陷如果被修復(fù)档泽，就可以保證這種問題不會(huì)再以同樣的方式發(fā)生俊戳。某一故障情況可能同時(shí)具有多個(gè)根源問題，如有可能自動(dòng)化程度不夠馆匿，軟件在異常輸入下崩潰抑胎，以及對(duì)生成配置文件的腳本測(cè)試不足等。這里每一個(gè)因素都是一個(gè)根源問題渐北，并且每一個(gè)都需要被修復(fù)阿逃。
監(jiān)控系統(tǒng)指標(biāo)
延遲：
服務(wù)處理某個(gè)請(qǐng)求所需要的時(shí)間。這里區(qū)分成功請(qǐng)求和失敗請(qǐng)求很重要赃蛛。
流量：
使用系統(tǒng)中的某個(gè)高層次的指標(biāo)針對(duì)系統(tǒng)負(fù)載需求所進(jìn)行的度量恃锉。對(duì)Web服務(wù)器來說，指標(biāo)通常是每秒HTTP請(qǐng)求數(shù)量呕臂，同時(shí)可能按請(qǐng)求類型分類（靜態(tài)請(qǐng)求與動(dòng)態(tài)請(qǐng)求）破托。針對(duì)音頻流媒體系統(tǒng)來說，這個(gè)指標(biāo)可能是網(wǎng)絡(luò)I/O速率歧蒋，或者并發(fā)會(huì)話數(shù)量土砂。針對(duì)鍵值對(duì)儲(chǔ)存系統(tǒng)來說，指標(biāo)可能是每秒交易數(shù)量疏尿，或每秒的讀取操作數(shù)量瘟芝。
錯(cuò)誤：
請(qǐng)求失敗的速率易桃，要么是顯示失斎焖觥（例如HTTP500），要么是隱式失斘钪！（例如HTTP200回復(fù)中包含了錯(cuò)誤內(nèi)容）敌呈，或者是策略原因?qū)е碌氖贸宏。ɡ缛绻蠡貜?fù)在1s內(nèi)發(fā)出，任何超過1s的請(qǐng)求就是失敗請(qǐng)求）磕洪。當(dāng)協(xié)議內(nèi)部的錯(cuò)誤代碼無法表達(dá)全部失敗情況時(shí)吭练，可以利用其他信息，如內(nèi)部協(xié)議析显，來跟蹤一部分特定故障情況鲫咽。監(jiān)控方式也非常不一樣：在負(fù)載均衡器上檢測(cè)HTTP500請(qǐng)求可能足夠抓住所有的完全失敗的請(qǐng)求，但是只有端到端的系統(tǒng)才能檢測(cè)到返回錯(cuò)誤內(nèi)容這種故障類型谷异。
飽和度：
服務(wù)容量有多“滿”分尸。通常是系統(tǒng)中目前最為受限的某種資源的某個(gè)具體指標(biāo)的度量。（在內(nèi)存受限的系統(tǒng)中歹嘹，即為內(nèi)存箩绍；在I/O受限的系統(tǒng)中，即為I/O）尺上。注意材蛛，很多系統(tǒng)在達(dá)到100%利用率之前性能會(huì)嚴(yán)重下降，增加一個(gè)利用率目標(biāo)也是很重要的怎抛。
長(zhǎng)尾問題
構(gòu)建監(jiān)控系統(tǒng)時(shí)卑吭，很多人都傾向于采用某種量化指標(biāo)的平均值：延遲平均值、節(jié)點(diǎn)的平均CPU利用率抽诉、數(shù)據(jù)庫(kù)容量的平均值等陨簇。由于CPU和數(shù)據(jù)庫(kù)等利用率可能波動(dòng)很大，根據(jù)其實(shí)際使用波動(dòng)取其值迹淌。
設(shè)計(jì)原則
簡(jiǎn)化：
- 那些最能反映真實(shí)故障等規(guī)則應(yīng)該越簡(jiǎn)單越好河绽，可預(yù)測(cè)性強(qiáng)，非嘲η裕可靠
- 那些不常用的數(shù)據(jù)收集耙饰、匯總，以及警報(bào)配置應(yīng)該定時(shí)刪除
- 收集到的信息纹份，但是沒有暴露給任何監(jiān)控臺(tái)苟跪，或者被任何警報(bào)規(guī)則使用的應(yīng)該定時(shí)刪除
SRE參與模型
- 系統(tǒng)的體系結(jié)構(gòu)和跨服務(wù)依賴
- 指標(biāo)的選擇、度量和監(jiān)控
- 緊急事件處理
- 容量規(guī)劃
- 變更管理
- 性能：可用性蔓涧、延遲和資源效率
事后總結(jié)
- 究竟發(fā)生了什么件已？
- 響應(yīng)的有效程度
- 下次是否可以采用其它方案解決問題
- 如何確保這次故障不會(huì)再次發(fā)生
3.數(shù)據(jù)完整性：讀寫一致
大數(shù)據(jù)云計(jì)算應(yīng)用都是優(yōu)化以下5項(xiàng)的某種組合：在線時(shí)間、延遲元暴、規(guī)模篷扩、創(chuàng)新速度和隱私。
在線時(shí)間：
經(jīng)常也用“可用率”指代茉盏，代表某個(gè)服務(wù)可以被用戶使用的時(shí)間比率鉴未。
延遲：
服務(wù)對(duì)用戶的相應(yīng)時(shí)間枢冤。
規(guī)模：
某個(gè)服務(wù)的用戶數(shù)量，以及能夠維持正常服務(wù)水平的最高負(fù)載
創(chuàng)新速度：
某個(gè)服務(wù)能夠在合理成本下铜秆，為用戶提供更好的服務(wù)的創(chuàng)新速度淹真。
隱私：
這個(gè)名詞的定義比較復(fù)雜。簡(jiǎn)單來說连茧，用戶刪除服務(wù)中的數(shù)據(jù)后核蘸，數(shù)據(jù)必須在合理時(shí)間內(nèi)真正被摧毀。
云計(jì)算環(huán)境下的需求
云計(jì)算環(huán)境引入的技術(shù)難點(diǎn)：
- 如果該環(huán)境使用了混合交易型和非交易型的備份和恢復(fù)方案啸驯，那么最終恢復(fù)的數(shù)據(jù)不一定是正確的
- 如果某個(gè)服務(wù)必須在不停機(jī)的情況下更新值纱，那么不同版本的邏輯可能同時(shí)并行操作數(shù)據(jù)
- 如果所有其他有交互關(guān)系的服務(wù)不是同步更新的，那么在更新過程中各服務(wù)的不同版本之間可能會(huì)有多種組合坯汤，那么就更加增大了數(shù)據(jù)意外丟失和損壞發(fā)生的概率虐唠。
擴(kuò)展API特性：
- 數(shù)據(jù)本地性和緩存
- 本地和全局的數(shù)據(jù)分布
- 強(qiáng)一致性/或最終一致性
- 數(shù)據(jù)持久性，備份于災(zāi)難恢復(fù)
數(shù)據(jù)完整性是手段惰聂，數(shù)據(jù)可用性是目標(biāo)
維護(hù)數(shù)據(jù)完整性：
- 全量疆偿、增量以及相互競(jìng)爭(zhēng)的備份和恢復(fù)機(jī)制
- 保留期 - 數(shù)據(jù)備份保存時(shí)間
- 確保數(shù)據(jù)恢復(fù)策略正常運(yùn)行
交付一個(gè)恢復(fù)系統(tǒng)，而非備份系統(tǒng)
造成數(shù)據(jù)丟失的事故類型
根源問題：
某種無法恢復(fù)的用戶數(shù)據(jù)丟失是由以下幾個(gè)因素造成的：用戶行為搓幌、管理員的錯(cuò)誤杆故、應(yīng)用程序的Bug、基礎(chǔ)設(shè)施中的問題溉愁、硬件故障和部署去的大型事故处铛。
影響范圍：
有些數(shù)據(jù)丟失是大規(guī)模的，同時(shí)影響很多實(shí)體拐揭。有些數(shù)據(jù)丟失是非常有針對(duì)性的撤蟆，僅僅是一小部分用戶的數(shù)據(jù)損壞或者丟失。
發(fā)生速度：
有些數(shù)據(jù)丟失失一瞬間造成的堂污，而有些數(shù)據(jù)丟失是緩慢持續(xù)進(jìn)行的家肯。
4.產(chǎn)品發(fā)布
發(fā)布流程
輕量級(jí)：
占用很少的開發(fā)時(shí)間。
魯棒性：
能夠最大限度的避免簡(jiǎn)單的錯(cuò)誤盟猖。
完整性：
完整的讨衣、一致的在各個(gè)環(huán)節(jié)內(nèi)跟蹤重要的細(xì)節(jié)問題。
可擴(kuò)展性：
可以應(yīng)用在很多簡(jiǎn)單的發(fā)布上式镐，也可以用在復(fù)雜的發(fā)布過程中反镇。
適應(yīng)性：
可以適用于大多數(shù)常見的發(fā)布，以及可以適用全新的發(fā)布類型娘汞。
發(fā)布檢查列表
檢查列表可以用來減少失敗歹茶，并且在多個(gè)職能部門之間保證一致性和完整性。
- 問題
- 待辦事項(xiàng)
原則：
- 每個(gè)問題的重要性必須非常高，理想情況下辆亏，都必須有之前發(fā)布的經(jīng)驗(yàn)教訓(xùn)來證明
- 每個(gè)指令必須非常具體、可行鳖目，開發(fā)者可以在合理的時(shí)間內(nèi)完成
架構(gòu)與依賴
依賴列表可以用來保證該服務(wù)的相關(guān)依賴都有足夠的容量扮叨。
示例問題：
- 從用戶到前端再到后端，請(qǐng)求流到順序是什么樣的领迈？
- 是否存在不同延遲要求的請(qǐng)求類型彻磁？
特辦事項(xiàng)：
- 將非用戶請(qǐng)求與用戶請(qǐng)求進(jìn)行隔離
- 確認(rèn)預(yù)計(jì)的請(qǐng)求數(shù)量。單個(gè)頁面請(qǐng)求可能造成后端多個(gè)請(qǐng)求狸捅。
集成
- 給服務(wù)建立一個(gè)新的DNS
- 微服務(wù)配置負(fù)載均衡系統(tǒng)
- 為服務(wù)配置監(jiān)控系統(tǒng)
容量規(guī)劃
- 新功能通常會(huì)在發(fā)布之初代來臨時(shí)的用量增長(zhǎng)衷蜓，在幾天內(nèi)會(huì)消除。這種尖峰式的負(fù)載或流量分布可能與穩(wěn)定狀態(tài)下有顯著區(qū)別尘喝，之前的壓力測(cè)試可能失效磁浇。
示例問題：
- 本次發(fā)布是否與新聞發(fā)布會(huì)、廣告朽褪、博客文章或者其他類型的推廣活動(dòng)有關(guān)置吓？
- 發(fā)布過程中和之后預(yù)計(jì)的流量和增速是多少？
- 是否已經(jīng)獲取到該服務(wù)需要的全部計(jì)算資源
故障模式
針對(duì)新服務(wù)進(jìn)行系統(tǒng)性的故障模式分析可以確保發(fā)布時(shí)服務(wù)器的可靠性缔赠。
客戶端行為
客戶端的濫用行為很容易影響到服務(wù)器的穩(wěn)定性衍锚。
示例問題：
- 該服務(wù)是否實(shí)現(xiàn)了自動(dòng)保存/自動(dòng)完成（完成框）/心跳等功能？
待辦事項(xiàng)：
- 確编脱撸客戶端在請(qǐng)求失敗之后按指數(shù)型增加重試延時(shí)
- 保證在自動(dòng)請(qǐng)求中實(shí)現(xiàn)隨機(jī)延時(shí)抖動(dòng)
流程與自動(dòng)化
使用標(biāo)準(zhǔn)工具來自動(dòng)化一些常見流程踢匣。
示例問題：
- 維持服務(wù)運(yùn)行是否需要某些手動(dòng)執(zhí)行等流程？
待辦事項(xiàng)：
- 將所有需要手動(dòng)執(zhí)行等流程文檔化
- 將遷移到另外一個(gè)數(shù)據(jù)中新的流程化文檔
- 將構(gòu)建和發(fā)布新版本的流程自動(dòng)化
開發(fā)流程
待辦事項(xiàng)：
- 將所有的代碼和配置文件都存放到版本控制系統(tǒng)中
- 為每個(gè)發(fā)布版本創(chuàng)建一個(gè)新的發(fā)布分支
外部依賴
示例問題：
- 這次發(fā)布依賴哪些第三方代碼模闲，數(shù)據(jù)、服務(wù)橄浓、或者事件？
- 是否有任何合作伙伴依賴于你的服務(wù)？發(fā)布時(shí)是否需要通知他們？
- 當(dāng)我們或者第三方提供商無法在指定截止日期前完成工作時(shí)，會(huì)發(fā)生什么陌兑？
發(fā)布計(jì)劃
在大型分布式系統(tǒng)中，很少有能夠瞬間完成的事件锭亏。就算能夠做到，為了保障可靠性锅减，這樣快速發(fā)布也并不一定是好主意糖儡。復(fù)雜的發(fā)布過程可能需要在不同子系統(tǒng)上單獨(dú)啟動(dòng)各個(gè)功能，每個(gè)配置更新都可能需要數(shù)小時(shí)才能完成怔匣。在測(cè)試實(shí)例中可以工作的配置文件并不能夠保障一次性被推送到生產(chǎn)實(shí)例上握联。有時(shí)候?yàn)榱顺晒Πl(fā)布，可能要進(jìn)行一個(gè)復(fù)雜的操作過程或者編寫特殊的代碼來保障流程的正確性。
待辦事項(xiàng)：
- 為該服務(wù)發(fā)布制定一個(gè)發(fā)布計(jì)劃金闽，將其中每一項(xiàng)任務(wù)對(duì)應(yīng)到具體的人
- 針對(duì)發(fā)布計(jì)劃中的每一步分析危險(xiǎn)性纯露，并制定對(duì)應(yīng)的備用方案
