系統管理員和網站可靠性工程師(SRE,下同)對於任何組織來說都很重要。本篇將介紹下二者的不一樣之處。html
在 IT 行業,成爲多面手或是專家的爭議一直存在。99% 的傳統系統管理員都被歸到了多面手這類。網站可靠性工程師(SRE)的角色則更加專精,而且在如 Google 般有着必定規模的頭部公司中對其的需求不斷增長。但總的來講這二者對於跑着應用的基礎設施有着一樣的目標:爲應用的消費者提供良好的體驗。然而二者的出發點卻大相徑庭。linux
系統管理員通常都是從基礎的桌面或網絡支持成長過來的,並一路習得大多數系統管理員都會掌握的普遍的技能。此時這些系統管理員會對他們所負責的系統和應用瞭如指掌。他們會知道一號服務器上的應用每隔一個星期二就須要重啓一次,或是九號服務器週三會靜默的崩潰。他們會對服務器的監視做出微調以忽略可有可無的信息,儘管那個被標記爲致命的錯誤信息每月第三個週日都會顯示。git
總的來說,系統管理員瞭解如何照料那些跑着你核心業務的服務器。這些系統管理員已經成長到開始使用自動化工具去處理全部歸他們管的服務器上的例行任務。他們雖然喜歡使用模板、黃金鏡像、以及標準,但同時也有着足夠的靈活度去修改一個服務器上的參數以解決錯誤,並註釋爲何那個服務器的配置不同凡響。github
儘管系統管理員很偉大,但他們也有着一些怪癖。其中一項就是沒有他們神聖的受權你永遠也獲取不了系統的 root 訪問權限,另外一項則是任何不是出於他們的主意的變動都要在文檔中被記錄爲應用提供方的要求,並仍然須要再次覈對。數據庫
他們所管理的服務器是他們的地盤,沒有人能夠隨意干涉。ruby
與成爲系統管理員的道路相反,從開發背景和從系統管理員背景成長爲 SRE 的可能性相近。SRE 的職位出現的時長與應用開發環境的生命週期相近。服務器
隨着一個組織的發展而引入的相似於持續集成和持續發佈 (CI/CD) 的 DevOps 概念,一般會出現技能空缺,以讓這些不可變的應用部署到多個環境並隨着業務需求進行擴展。這將是 SRE 的舞臺。的確,一個系統管理員能夠學習額外的工具,但大致上成爲一個全職的職位更容易跟的上發展。一個專精的專家更有意義。網絡
SRE 使用如代碼即基礎設施的概念去製做模板,而後調用它們來部署用以運行應用的環境,並以使用一鍵完整重現每一個應用和它們的環境做爲目標。所以會出現這樣的狀況:測試環境中一號服務器裏的一號應用的二進制文件與生產環境中十五號服務器的徹底一致,僅環境相關的變量如密碼和數據庫連接字串有所不一樣。app
SRE 也會在配置發生改變時徹底銷燬一個環境並從新構建它。對於任何系統他們都不帶一點感情。每一個系統只是個被打了標記和安排了生命週期的數字而已,甚至連例行的對服務器打補丁也要從新部署整個應用棧運維
對於一些狀況,尤爲是運維一些大型的基於 DevOps 的環境時,一個 SRE 所能提供的用於處理各類規模的業務的專業技能固然更具優點。但每次他們在運氣很差走入死衚衕時都會去尋求他的系統管理員友人或是 來自地獄的混蛋運維(BOFH) ,獲得他那身經百戰的故障排除技能,和那些用於給組織提供價值的豐富經驗的幫助。
via: opensource.com/article/19/…
做者:Vince Power 選題:lujun9972 譯者:vizv 校對:wxy