DevOps和SRE還沒搞清楚，平臺工程又出現了，它會取代DevOps嗎？

DevOps、SRE和平臺工程的概念在不同時期出現，並由不同的個人和組織開發。

DevOps作為一個概念是由Patrick Debois和Andrew Shafer在2009年的敏捷會議上提出的。他們試圖通過促進共同作業文化和在整個軟體開發生命週期中共用責任來彌合軟體開發和操作之間的差距。
SRE，即站點可靠性工程，是谷歌在21世紀初首創的，用於解決管理大型複雜系統的操作挑戰。谷歌開發了SRE實踐和工具，如Borg叢集管理系統和Monarch監控系統，以提高其服務的可靠性和效率。
平臺工程是一個較新的概念，建立在SRE工程的基礎上。平臺工程的確切起源不太清楚，但它通常被理解為DevOps和SRE實踐的擴充套件，重點是為支援整個業務視角的產品開發交付一個全面的平臺。

值得注意的是，雖然這些概念出現在不同的時期。它們都與軟體開發和操作中改進共同作業、自動化和效率的更廣泛趨勢有關。

在過去的十年中，工程和技術組織已經將構建和部署雲原生應用程式的最佳實踐集合在一起。這些最佳實踐包括持續交付、容器化和構建可觀察系統。
與此同時，雲原生組織已經從根本上改變了他們的組織方式，從大型部門(開發、QA、運營、釋出)轉移到較小的獨立開發團隊。這些應用程式開發團隊得到兩個新功能的支援:站點可靠性工程和平臺工程。SRE和平臺工程是傳統運維團隊的精神繼承者，將軟體工程的學科帶入運維的不同方面。

站點可靠性工程和平臺工程

平臺工程團隊應用軟體工程原則來加速軟體交付。平臺工程師確保應用程式開發團隊在軟體交付生命週期的所有方面都是高效的。
站點可靠性工程團隊應用軟體工程原則來提高可靠性。站點可靠性工程師將影響雲應用整體可靠性的故障頻率和影響降到最低。

這兩個團隊經常混淆，這兩個術語有時可以互換使用。事實上，一些組織將SRE和平臺工程合併到相同的功能中。之所以會出現這種情況，是因為這兩個角色都適用一套共同的原則。

平臺即產品。這些團隊應該花時間瞭解他們的內部客戶，制定路線圖，制定釋出節奏計劃，編寫檔案，以及完成軟體產品中的所有事情。
自助服務平臺。這些團隊構建自己的平臺供內部使用。在這些平臺中，對最佳實踐進行了編碼，因此這些平臺的使用者無需擔心——他們只需按下按鈕即可。在Puppet Labs的《2020年DevOps現狀報告》中，Puppet Labs發現，高功能DevOps組織比低功能DevOps組織擁有更多的自助服務基礎設施。
對消除辛勞的持續關注。正如谷歌SRE書中定義的那樣，辛勞是手動的、重複的、自動化的、戰術的工作。最好的SRE和平臺團隊能夠識別並消除辛勞。

平臺工程

平臺工程師不斷地檢查從原始碼到生產的整個軟體開發生命週期。通過這個內省的過程，他們構建了一個工作流，使應用程式開發人員能夠快速編寫和釋出軟體。基本的工作流通常包括與持續整合系統相連線的原始碼控制系統，以及將工件部署到生產環境中的方法。

隨著使用工作流的應用程式開發人員數量的增長，平臺的需求也在變化。不同的應用程式開發團隊需要類似但不同的工作流，因此自助服務基礎設施變得很重要。自助服務的常見平臺工程目標包括CI/CD、警報和部署工作流。

除了自助服務，教育和共同作業也成為挑戰。平臺工程師發現，他們花越來越多的時間培訓應用程式開發人員，讓他們瞭解最佳實踐和如何最好地使用平臺。應用程式開發人員還發現他們依賴於其他應用程式開發人員團隊，並期望平臺工程團隊為他們提供與不同團隊高效共同作業的工具。

站點可靠性工程

站點可靠性工程師建立和改進系統，以自動可靠地執行應用程式。站點可靠性工程的概念起源於谷歌，詳細記錄在谷歌SRE手冊中。谷歌公司負責技術運維的高階副總裁Ben Treynor Sloss將SRE描述為「當你要求軟體工程師設計運維團隊時發生的事情」。

SRE定義服務水平目標，並構建系統來幫助服務實現這些目標。這些系統發展成為一個平臺和工作流程，包括監控、事件管理、消除單點故障、故障緩解等。

SRE文化的一個關鍵部分是將每一個故障視為可靠性系統中的一個故障。嚴格的事後分析對於識別故障的根本原因至關重要，並將糾正措施引入自動化系統以繼續提高可靠性。

New Relic的SRE和平臺工程

我們中的一個人(Bjorn Freeman-Benson)一直管理著New Relic的工程組織，直到2015年，它從少數客戶發展到成千上萬的客戶，所有客戶每秒都向雲端傳送數百萬個請求。New Relic有獨立的SRE和平臺工程團隊，他們遵循上述一般原則。

這些團隊被分開建立的原因之一是，在這些角色中取得成功的人是不同的。雖然sre和平臺工程師除了需要經典的程式設計技能外，還需要強大的系統工程技能，但這些角色決定了非常不同的性格型別。sre傾向於享受危機管理，並在排除故障時獲得腎上腺素飆升。SRE經理能在巨大的壓力下茁壯成長，擅長招募和管理想法相似的人。另一方面，平臺工程師是更典型的軟體工程師，他們更喜歡不間斷地工作在大而複雜的問題上。平臺工程經理更喜歡按照一致的節奏進行操作。

DevOps和GitOps

在過去的十年中，DevOps已經成為描述這些實踐的一個流行術語。最近，GitOps也成為了一個流行術語。DevOps和GitOps與平臺和SRE團隊有什麼關係?
DevOps和GitOps都是一套關於如何管理基礎設施不同方面的鬆散編碼原則。這兩種哲學的核心原則——自動化、基礎設施作為程式碼、軟體工程的應用——非常相似。
DevOps是一場廣泛的運動，它專注於消除開發和運維之間的傳統豎井。隨著時間的推移，基礎設施自動化和考慮運維的工程應用等策略已經被廣泛接受，成為更好地構建高可靠性應用程式的方法。
GitOps是一種應用程式交付方法。在GitOps中，宣告性設定用於在任何時刻編碼應用程式的所需狀態。這個設定在版本化的原始碼控制系統中作為唯一的真實資料來源進行管理。這確保了可審計性、可再現性和設定的一致性。
簡而言之:DevOps是SRE的一套指導原則，而GitOps是平臺工程的一套指導原則。

解鎖應用程式開發效率

站點可靠性工程和平臺工程是優化構建雲原生應用的工程組織的兩個關鍵功能。SRE團隊致力於為高可靠的應用程式交付基礎架構，而平臺工程團隊致力於為快速的應用程式開發交付基礎架構。這兩個團隊共同提高了應用程式開發團隊的生產力。

參考：