系統管理員與網站可靠性工程師（SRE）對比：區別在那兒？

Vince Power發表於2019-07-17

系統管理員和網站可靠性工程師（SRE，下同）對於任何組織來講都很重要。本篇將介紹下兩者的不同之處。

在 IT 行業，成為多面手或是專家的爭議一直存在。99% 的傳統系統管理員都被歸到了多面手這類。網站可靠性工程師site reliability engineer（SRE）的角色則更加專精，並且在如 Google 般有著一定規模的頭部公司中對其的需求不斷增加。但總的來說這兩者對於跑著應用的基礎設施有著同樣的目標：為應用的消費者提供良好的體驗。然而兩者的出發點卻截然不同。

系統管理員：中立善良的化身

系統管理員一般都是從基礎的桌面或網路支援成長過來的，並一路習得大多數系統管理員都會掌握的廣泛的技能。此時這些系統管理員會對他們所負責的系統和應用瞭如指掌。他們會知道一號伺服器上的應用每隔一個星期二就需要重啟一次，或是九號伺服器週三會靜默的崩潰。他們會對伺服器的監視作出微調以忽略無關緊要的資訊，儘管那個被標記為致命fatal的錯誤資訊每個月第三個週日都會顯示。

總的來講，系統管理員瞭解如何照料那些跑著你核心業務的伺服器。這些系統管理員已經成長到開始使用自動化工具去處理所有歸他們管的伺服器上的例行任務。他們雖然喜歡使用模板、黃金映象golden images、以及標準，但同時也有著足夠的靈活度去修改一個伺服器上的引數以解決錯誤，並註釋為什麼那個伺服器的配置與眾不同。

儘管系統管理員很偉大，但他們也有著一些怪癖。其中一項就是沒有他們神聖的授權你永遠也獲取不了系統的 root 訪問許可權，另一項則是任何不是出於他們的主意的變更都要在文件中被記錄為應用提供方的要求，並仍然需要再次核對。

他們所管理的伺服器是他們的地盤，沒有人可以隨意干涉。

SRE：滅霸將為之自豪

與成為系統管理員的道路相反，從開發背景和從系統管理員背景成長為 SRE 的可能性相近。SRE 的職位出現的時長與應用開發環境的生命週期相近。

隨著一個組織的發展而引入的類似於持續整合和持續釋出 (CI/CD) 的 DevOps 概念，通常會出現技能空缺，以讓這些不可變immutable的應用部署到多個環境並隨著業務需求進行擴充套件。這將是 SRE 的舞臺。的確，一個系統管理員可以學習額外的工具，但大體上成為一個全職的職位更容易跟的上發展。一個專精的專家更有意義。

SRE 使用如程式碼即基礎設施infrastructure-as-code的概念去製作模板，然後呼叫它們來部署用以執行應用的環境，並以使用一鍵完整重現每個應用和它們的環境作為目標。因此會出現這樣的情況：測試環境中一號伺服器裡的一號應用的二進位制檔案與生產環境中十五號伺服器的完全一致，僅環境相關的變數如密碼和資料庫連結字串有所不同。

SRE 也會在配置發生改變時完全銷燬一個環境並重新構建它。對於任何系統他們都不帶一點感情。每個系統只是個被打了標記和安排了生命週期的數字而已，甚至連例行的對伺服器打補丁也要重新部署整個應用棧application stack

總結

對於一些情況，尤其是運維一些大型的基於 DevOps 的環境時，一個 SRE 所能提供的用於處理各種規模的業務的專業技能當然更具優勢。但每次他們在運氣不好走入死衚衕時都會去尋求他的系統管理員友人或是來自地獄的混蛋運維（BOFH），得到他那身經百戰的故障排除技能，和那些用於給組織提供價值的豐富經驗的幫助。