服務可靠性工程的文化
這一篇我們來講一個比較high level的SRE文化如何在組織內實行。
傳統上的IT人員基本上由於組織架構與文化的關係在維護自家IT服務時不太在乎組織外部客戶的聲音(甚至是內部客戶也就是User)。憑著自己的認知或所看到的就會說一句"服務沒問題"後，接下來就不在乎後續了。
然而Google 的SRE文化是要公司內部的IT人員正視客戶的意見與觀點，由客戶來告訴你公司提供的IT服務怎麼樣才算是reliable(可靠的)。
傳統上Operation(維運)與Development(開發)是隔一道牆兩邊都不常溝通，而且因為兩個團隊都各自有觀點與認知與任務優先不同，而這樣造成經常相互指責。我們稱它是"穀倉效應"。
會這樣是因為開發團隊經常因為業務需求而要經常對生產環境做變動/更新，而維運團隊希望保持環境運作的一致性(最好都不要有任何變動，但這是不可能的)。而SRE(Site Reliability Engineering)就是在這兩個團隊的目標中求取一個平衡的最佳實踐。在高度變動(帶有風險的)的IT環境中達到IT服務的可靠性(reliability)。而這一套方法可以運用在地端或雲端環境，從大型環境到日常工作。
DevOps / SRE有甚麼不一樣，而它們為什麼存在?
DevOps團隊/角色如上一段說的，這是為了打破開發與維運團隊之間的穀倉而產生的。為的是讓兩個團隊成員能更多相互的理解進而能夠協同作業，簡單來說這麼做就是讓IT部門的效能最大化。Google在Youtube的一段影片有簡單的介紹。DevOps是一種philosophy(學說)，不是一種開發方法或技術。而SRE是為了實踐這種學說而產生的方法論。在這個方法論中，開發人員可以專注在產生源源不絕的程式功能與創新，而維運人員可以專注在IT整體服務的reliability(可靠性) 與consistency(一致性)，SRE的方法論包含了技術與文化的實踐。而DevOps philosophy有5個Pillar(如下圖)
上圖中，每個Pillar的圖示下方文字說明是DevOps，上面文字說明是SRE的方法。
名詞解釋
我們先來看一下一些主要的名詞解釋
SRE主要目標是設定是SLO(Service level objective)，不過這不是技術人員決定的而是組織業務層面所訂出的。SLO是指一段時間(可能是每周或每月)的服務可靠度可能是99.9%之類。錯誤的設定應該是100%服務可靠度，哪是不切實際的Google / Amazon / Microsoft 甚至 NASA他們都有服務失效的時候，這些組織龐大聰明的員工又多。在你為組織設定100%可靠度前捫心自問，我的公司有比這些公司大嗎?有比他們更聰明的員工嗎?
而要達成這個objective 就需要有一堆的指標，SRE者這裡稱SLI(Service level indicator)，是從你的IT服務的最終使用者的角度以量化的方式來量測各項服務的可靠性。
而可靠性(Reliability)是指你的IT服務對最終使用者的好的互動服務與不好的。例如消費者使用了100次該項目服務，90次是滿意而10次是不滿意的。這樣IT服務可靠度就是90%。
Error Budget，指有多少的不好的IT服務是可以忍受的。以上面範例來說假設是業務層面設定一個一千次的交易只能有50次是可以容忍失敗的。哪這50次就是你的Error budget.
Blameless postmortem，這是事故調查報告但報告中絕不針對任何人來檢討。而是從組織的架構流程技術等方面來做。它是怎麼發生的?發生的主因是甚麼?怎麼解決的?事件的過程?如何防止再犯等等。
SRE的任務是 "保護，提供和改進軟體和系統，並始終關注可用性(availability)，延遲(latency)，性能(performance)和容量(capacity)"。了解SRE的慣例與規範將幫助你在開發與維運團隊之間建立共同的語言。並協助組織適應SRE的文化。SRE的第一個心態是接受IT服務會失敗(failure)，而失敗有助於我們在事故調查時防止下次再犯同樣的錯誤，事故調查一樣是專注在系統與流程而非人員。因為這個文化中對於團隊我們是需要給予高度信任的，如果是一個處在沒有安全感與信任感的環境哪麼任何人事情將不會做好，尤其在IT環境中是需要大量思考與高度專注的職業。所以營造高度有著心理上有安全感的公司環境將增進組織人員的學習與創新，而使用SLOs and error budgets這兩項使指標將會讓開發團隊與維運團隊之間產生共同的責任來達這兩項指標。組織在實行SRE文化時應該專注於創建一致的願景，確定協同合作作業應該是甚麼樣子以及在團隊之間共享知識。
DevOps
我們前面說到DevOps是一種學理，沒有特定的方法或技術，端看每個組織怎麼去實現它。而DevOps被人提到最多的應該就是CI/CD流程了。我們這邊來解釋一些在DevOps常聽到的
CI(Continuous integration):
在開發環境中針對code實行Building, integrating, and testing。
CD(Continuous delivery):
經常性的對生產環境做佈署，或是按照business 選擇頻率來佈署。
另一種比較常聽的是Canarying test(金絲雀測試):
指在使用我們的IT服務整體使用者中選擇一小群的人來測試，這些人並不知道系統服務做了改變。從而去觀察這一小群人的反應進而收集資訊來決定我們這個變動下一步該怎麼進行。
Toil(過勞)
這類的日常作業是重複性，無持久價值的服務，或者隨著服務的增長而線性擴展的工作。總地來說就是生產線上的機器一樣的工作。
在DevOps的重點概念有以下這些:
- 有變動是好的，只要這些變動是很小又是頻率高的變動。
- 要有設計思維的五種階段: empathize, define, ideate, prototype, and test。
- 有Prototype文化能夠鼓勵團隊測試更有創意的idea，導致更快的失敗率和更多的成功率。
- 對DevOps(或SRE)角色來說過度勞累(toil)是有毒
- 為了減少Toil，SRE應當專注於減少未來可能產生toil的工作(就是將重複的工作自動化，這是第一步)以及增加IT服務的功能。
- 抵制變革(DevOps or SRE文化)通常是害怕損失(可能是自己的飯碗或是被人指責)。為此我們需要展現的是變革是一個機遇而不是威脅。
- 人們都常會有很多方式來回應變革， IT leader需要了解如何去溝通與support每個影響的團體。
You can’t manage what you can’t measure
很多傳統IT是用直覺維護IT環境，而不是靠數據/資料來決定的。我們需要在我們的心態中移除掉這種無意識的偏見。在IT領域中常見的偏見有
Affinity bias:
跟我們有特徵相似的人，例如種族/性別/社會經濟/教育程度等等，我們在心態上可能就會覺得跟我相似的人應該差不到哪裡去。
Confirmation bias:
人們傾向於尋找支持自己觀點的證據，而忽略了與他們觀點相悖的資訊。當偏見早已形成，人們傾向放大能證明其觀點的「證據」。有這種偏見的人容易選擇性吸納別人的意見。
Selective attention bias:
傾向於關注事物，思想是來自你覺得是大神級的意見的傾向。
Labeling bias:
用人們的外在形象(穿著髮型等)來判定這個人。
上面這麼多直覺式的判斷是在告知我們，系統的維運也絕不可有這些偏誤的心態存在。一切都要靠資料/數據來調整其IT服務。所以衡量IT服務需要訂立良好的SLI，而一個良好的SLI是從使用者的經驗來看的;簡單來說就是使用者使用你的IT服務是是happy的還是不happy。通過識別，選擇合適的度量單位並連續追蹤來測量toil。而"監控"讓你能夠了解整個IT系統，這是判斷IT服務運行狀況並在出現問題時診斷服務的核心要求。故SRE的data-driven decision是一事實數據來說話的包含了數據的目標設定與數據的透明度都包含SRE量測文化。
在你的組織裡運行SRE
在組織裡推行SRE團隊基本上大多是從傳統的IT system admin團隊開始推行。因為Google 所推行的SRE文化是用軟體工程來看待維運的問題，所以傳統的IT system admin最好有一些使用scripts來維運IT環境的經驗，這一些有使用過scripts經驗的工程師再給予軟體程式開發的教育訓練作為第一步的開始。以下介紹幾種SRE團隊種類，這些團隊的類型有好有壞視組織狀況而定來實行
Kitchen Sink/”Everything SRE” team:
這是一種小範圍小規模的Applications與使用者環境下使用專專屬的一個SRE小團隊來實行SRE，此種團隊比較面向code程式碼的SRE。
Infrastructure team:
這種SRE團隊比較負責infra的維運，這一組infra 環境上面搭載了很多產品服務。infrastructure as a code是在此種團隊使用的，大多不會去修改程式碼最多是修改運行環境的configuration.(筆者領導過的SRE團隊也是屬於此種)
Tools team:
這種類型的SRE團隊傾向專注於構建software以幫助其開發人員評估，維護和提高系統可靠性或SRE工作的其他方面（例如capacity planning）。
Product/Application team:
這種類型的SRE團隊致力於提高關鍵應用程序或業務領域的可靠性。組織中基本上要已經實行上述說的三種團隊存在實行起來比較可行。這種團隊是為了將建立高度可靠性的key user-facing application。
Embedded team:
這是在每個開發團隊配備一個專屬的SRE工程師(通常需要資深一點，並且有一些的開發經歷)。這種SRE團隊通常time based or project based的也就是專案結束或時間到就結束。這個SRE engineer是需要動手的，通常是介入一定範圍內code 的更動或是configuration change.
Consulting team:
這個與Embedded team差不多，但是該位SRE不動手只提供顧問等級的諮詢服務，(這種等級的engineer已經是在SRE領域有相當的資歷了)。
具有較高SRE成熟度的組織具有充分記錄和以用戶為中心的SLO，error budget，無可指責的文化以及對Toil的低容忍度。組織的SRE三種階段的成熟度可參考下圖
如果你是打算新建立SRE團隊，哪麼當然可以挑選團隊中的工程師全部都具又SRE的經驗與技能。但若是要從既有IT團隊轉化成SRE團隊哪麼必要的技能提升將是不可避免的，例如
operations and software engineering, monitoring systems, production automation, system architecture, troubleshooting, culture of trust, and incident management等等。
以上就是發展SRE文化的一些要點介紹
