采用SRE思維方式

隨著云原生方法論的采用，S R E的職責也在增加。如果想讓數據基礎設施融合，那么SRE需要學習新的技能并付諸實踐。以下是維基百科對SRE的定義（見網址列表條目[14]）：

SRE將理論和實踐相結合，不僅涵蓋軟件工程的各個方面，還涉及在數據基礎設施上應用和操作軟件的問題。主要目標是創建可伸縮、高可用的軟件系統。SRE和DevOps密切相關，DevOps是一套結合軟件開發和信息運營的實踐體系，SRE也被稱為DevOps的具體實現。

過去在部署數據基礎設施時，主要將注意力集中在部署的特定組件上。例如，你可能只關注規模部署的MySQL或用于分析大量數據的Spark。采用SRE思維方式則意味著除了應關注部署什么，還應關注如何部署，即讓各部分協同工作來實現應用的功能。整體而言，組件的部署應當考慮交互方式、訪問權限（包括安全性），以及確保滿足服務等級的各方面的可觀測性。

如果你的主要或次要角色是數據庫管理員（DBA），那么現在正是轉變的時候。據LinkedIn統計顯示，DBA的數量每年都在減少（見網址列表條目[15]），而SRE的數量卻在大幅度攀升。掌握運行關鍵數據基礎設施的SRE，可以將這部分技能轉化為管理云原生數據的基本能力，包括：

? 可用性

? 延遲

? 變更管理

? 應急響應

? 能力管理

為了適應并承擔更多職責，SRE還需要掌握以下幾項新技能：

CI/CD管道

將代碼從代碼庫部署到生產環境中是大勢所趨。在軟件開發組織中，CI/CD（持續集成/持續部署）管道是能加速應用開發非常好的選擇。持續集成（CI）能夠在應用技術棧中編譯新代碼并進行完整的自動化測試，保障質量。持續部署（CD）能將經過充分測試和認證的編譯版本自動部署到生產環境中。將二者結合起來（管道），開發組織能夠顯著提升開發速度和生產力。

可觀測

DevOps從業者喜歡將問題劃分為“什么”（所部署的具體服務）和“如何”（部署該服務的方法）兩個環節。你如果接觸過數據基礎設施，就一定不會對監控感到陌生。在DevOps中的“什么”環節，可以了解部署的服務是否健康并獲取診斷問題所需的信息。在DevOps中的“如何”環節，則更進一步將一切視為一個整體，你可以了解到應用是如何出現問題的。例如，在高度分布式應用中，通過分析數據在每一跳的延遲來追蹤整個系統的延遲來源。

理解代碼

大型分布式應用出現的故障通常不是由某個線程造成的，多數是因為代碼或細微的實現過程出現BUG導致的。為了對應用的整體健康負責，你需要理解運行在指定環境中的代碼。正確實施可觀測性（包含軟件儀表）有助于發現問題。SRE和開發人員需要定期進行明確的溝通，代碼是溝通的共同基礎。

擁抱分布式計算

通過Kubernetes部署應用意味著要擁抱分布式計算的方方面面。如果習慣了以往的單一系統模式，那么要實現這種轉變可能有些艱難，主要在于需要轉變預期想法并理解問題是在哪里出現的。例如，由于單一系統中包含了數據處理的所有步驟，因此延遲幾乎為零。相比人為因素，CPU和內存才是主要癥結。20世紀90年代，Sun Microsystems曾在不斷發展的分布式計算領域中領先，下面列舉了8個常見的錯誤觀點（見網址列表條目[16]）：

? 網絡是可靠的

? 延遲為零

? 帶寬是無限的

? 網絡是安全的

? 拓撲結構不會改變

? 肯定有至少一名管理員

? 傳輸成本為零

? 網絡類型是相同的

這些錯誤觀點都是通過一條條教訓歸納出來的。但凡對其中的一個錯誤觀點抱有幻想，結局都會令人失望，不但結果不盡如人意，而且會浪費大量查找問題的時間。從長遠來看，分布式方法論值得青睞。在今后很長一段時間內，它將是部署大規模應用的手段。它就像一座高山，山頂的美景值得我們這群“登山愛好者”發起挑戰，每天朝著前方樂此不疲地探索。Kubernetes應用自帶分布式屬性，將一一測試上述錯誤觀點。在規劃應用部署時，建議提前考慮數據轉移的傳輸成本及影響延遲的因素，這樣能節省時間，并避免重新規劃。