關(guān)鍵詞： SRE恩沽，運營阱冶，可靠性顽冶， 故障剖析

對運維而言采驻，相比較英文單詞 operation 與 site reliability engineering （SRE）, SRE 將運維劃分為一種工程和開發(fā)任務(wù)宝当，從一個側(cè)面調(diào)節(jié)了開發(fā)人員與運維的矛盾视事。 SRE的起源來自于Google。 這種實踐幫助優(yōu)化了下面幾個方面:?

????a.? 運維自動化

????b. 雙方高效溝通

????c. 促使開發(fā)人員編寫更高效的系統(tǒng)方便運維

????d. 解決運維需要維持系統(tǒng)穩(wěn)定庆揩，與開發(fā)需要上線新功能的天生矛盾

針對網(wǎng)站而言俐东，以下幾個實踐可能是非常有效的。

1. SRE 必須會編程订晌， 且最多允許50%的苦力勞動

? ? ? ? a.?可以有感知且實現(xiàn)自動化: SRE 人員應(yīng)該能夠用編碼解決復(fù)雜問題虏辫。當(dāng)執(zhí)行重復(fù)的任務(wù)多次時，他們應(yīng)該有感知的自發(fā)其開發(fā)自動化方式去實現(xiàn)任務(wù)锈拨。在實踐中砌庄，這種感知往往更加重要。很多人可能做了很多次重復(fù)的工作奕枢，但都沒有把其進行自動化的想法鹤耍。

? ? ? ? 另外一個限制條件是只允許SRE 存在最多50%的需手工進行的苦力勞動。這從另一個側(cè)面促使他們進行更好的自動化验辞。

? ? ? ? 優(yōu)先自動化的工作是所需工作量最小稿黄，但能帶來最大效益的

? ??? ?b.?有足夠的開發(fā)知識: SRE 人員應(yīng)該可以理解和鑒別開發(fā)人員的工作。能無障礙的與他們進行溝通跌造。能理解什么樣的方式是可行的杆怕，什么樣的方式是不可行的。

2. SRE 和開發(fā)人員來自同樣的候選人群

? ? ? ? 一個目的是為了滿足 1 中我們所說的需求壳贪，另一個目的是我們可以為一個項目分配一定數(shù)量的工程師陵珍，當(dāng)我們增加了SRE的數(shù)量的時候，我們就不得不減少開發(fā)工程師的數(shù)量违施。這從而促使開發(fā)人員編寫更高效的系統(tǒng)方便運維互纯，以減小SRE人員的需求

3. 過度的運營需求將成為開發(fā)團隊的需求， 且開發(fā)團隊承擔(dān)5%的運維工作

? ? ? ?這都是為了讓開發(fā)團隊能夠更好的感知運維的需求磕蒲，開發(fā)更高效的系統(tǒng)留潦。

????????可采用８／２法則，新版本迭代分為大的辣往，和小的發(fā)行版本：在大的發(fā)行版本中花２０％的時間在運維需求上兔院，其他時間在重要的新功能上；而在小的版本中包含一兩個高優(yōu)先的功能站削，其他８０％的時間在ｂｕｇ修復(fù)和穩(wěn)定性維護上.?

4. 使用錯誤預(yù)算（Error Budgets)?

????一般的網(wǎng)站的穩(wěn)定性需求都為4個9 （99.99%）坊萝。Wifi 一般的可用性都低于99%，? 所以一般來講4個9的穩(wěn)定性就足夠了。在這種情形下十偶，我們可以刻意的在每個季度預(yù)留一些不穩(wěn)定（約13分鐘）的時間做為新功能測試的代價菩鲜。?

? ? 每個季度，當(dāng)這個13分鐘的預(yù)留時間沒有耗盡的時候惦积，開發(fā)人員可以自由發(fā)布新的功能睦袖。當(dāng)預(yù)留時間因為新功能的bug 而被耗盡則所有發(fā)布終止。這從另一個側(cè)面促使開發(fā)人員開發(fā)更穩(wěn)定的系統(tǒng)荣刑。也讓運維部門不再需要費心的阻止新功能的發(fā)布以維持系統(tǒng)的穩(wěn)定度。

? ? 在軟件開發(fā)的Estimation time 中伦乔，也應(yīng)專門預(yù)估一些時間在系統(tǒng)穩(wěn)定性的改善上面

5. 每個值班最多處理兩個故障

? ? 為減輕運維負荷厉亏，達到更高效的運維，把每個運維的值班時間烈和，縮短為最多需要處理兩個故障爱只。

6. 制定SLA，并根據(jù)其計量和報告性能

開發(fā)人員和SRE都對SLA負責(zé)招刹，也都有及時交付功能的職責(zé)恬试。這樣保持開發(fā)與ＳＲＥ的目標是一致的。而非只有ＳＲＥ對ＳＬＡ負責(zé)疯暑，但對及時交付沒有責(zé)任训柴。

7. 任務(wù)分配：不應(yīng)該所有人的優(yōu)先級都為緊急故障

? ? 一名SRE的最高優(yōu)先級應(yīng)為緊急故障。一名SRE的優(yōu)先級應(yīng)為常規(guī)ticket. 一名SRE的優(yōu)先級應(yīng)為運維優(yōu)化妇拯。這三個優(yōu)先級可以一人專注于一周幻馁。這樣保證整個團隊不會疲于奔命而無法做運維優(yōu)化。運維優(yōu)化應(yīng)該是團隊最為重要的任務(wù)越锈。

8. 執(zhí)行軟啟動(Soft Launch)仗嗦，金絲雀( canary) / 灰度測試

????軟啟動：不公開通告新功能的啟動。這樣避免流量爆增甘凭，可以提供一些緩沖在大多數(shù)用戶發(fā)現(xiàn)問題前修復(fù)問題稀拐。

９. 進行故障的事后剖析，分析過程而非職責(zé)人

? ? 對事故的剖析必須執(zhí)行丹弱，隱瞞事故只會導(dǎo)致同樣的悲劇再次重演德撬。

????對故障進行事后剖析，重點在于故障過程和如何阻止下次再發(fā)生躲胳。即使是人為因素導(dǎo)致的故障也應(yīng)該重點放在如何從制度上避免發(fā)生砰逻，而非強調(diào)個體的失誤。最近比較出名的 餓了嗎 運維事故中就可以看出泛鸟，其實我們可以通過從（1）自動化角度避免需要重復(fù)這樣機械的勞動蝠咆； （2）當(dāng)操作生產(chǎn)環(huán)境時加入二次確認和授權(quán)機制來保證事故不會重現(xiàn)；（3）減輕工作量，避免疲勞操作刚操，而不是倚賴于人不會犯錯闸翅，如犯錯就要遭受解雇上面。

事故剖析中菊霜， 應(yīng)使用第一人稱嗦锐，表露對事故發(fā)生的懊惱與愧疚，而不是采用新聞官腔纹坐。盡量避免使用“可能”等詞語淡化事故造成的影響偎痛。如果沒有影響，那你也就不會發(fā)布剖析報告了不是构捡？

簡單的內(nèi)部剖析報告應(yīng)包含以下內(nèi)容：

標題:?

報告狀態(tài)：（故障是否修復(fù)）

概述：∫耗稀（發(fā)生的情況，受影響的用戶勾徽，及避免再次發(fā)生的關(guān)鍵建議／需要領(lǐng)導(dǎo)批準的部分）

事故描述：』埂（詳細描述）含操作與時間軸

受影響用戶：

解決方案：（感謝在其中提供幫助的人員列表）

歸因分析：

未來建議：（應(yīng)該是可計量的）