在公司成立之前，我們團隊就已經開始應用 DevOps 實踐，而我個人，早在十年前，在另一家公司擔任系統管理員的時候，就第一次接觸到了這種新鮮的思維方式。那個時候，還沒有 DevOps 這種標準說法，但是當時實踐的人也自己摸索出了一些相關的概念與原則。
- 持續集成；
- 自動交付；
- 每位團隊成員都對產品負有責任；
- 與客戶直接溝通；
- 收集並分析業務 / 應用程序指標；
- 說明文檔等；
後來證明以上這一切都是對敏捷倡議中各項實踐的邏輯擴展，而催生出這些方法的溫牀，則是開發者不再單純爲本地主機編寫代碼這一基本前提。
由 Atlassian 提出的 DevOps 模式直到今天仍然非常重要。從本質上講，其代表着產品開發與交付的現代化週期，同時涵蓋產品啓動之後的運作流程。
前 DevOps 時代：管理員與開發者之間的鴻溝
長久以來，產品的運營與開發工作彼此割裂。這條鴻溝的一端是勤勞樸實的開發人員，另一端則是開發者眼中那些如同行屍走肉般的系統管理員。系統管理員不參與開發，也不會與開發團隊溝通，他們通常只是直接拿到代碼包，然後嘗試在某個位置加以運行。每一次運行嘗試都痛苦萬分，管理員們需要花幾天時間慢慢查看日誌、尋找種種難以理解的錯誤、分析數據庫查詢、陷入無窮無盡的 strace 過程等。而很多時候的事實都證明，只需要定義一項新的環境變量或者添加一個新參數，問題就能迎刃而解。但遺憾的是，開發者從來不會、也沒有機會把情況告知管理員，後者唯一瞭解的就是產品的名稱及其用什麼語言編寫而成……
十年前的“DevOps”工作
十年之前，我剛開始在團隊中擔任管理員，當時的公司思維比較靈活，我不像《IT 狂人》的劇情那樣被安排在地下室某個陰暗的小房間裏，而是在開發者當中擁有了自己的辦公桌。從那一刻開始，我也踏上了自己的 DevOps 工程師之旅。
在公司的工作中，我很快意識到，雖然知識和技能都很重要，但從溝通及運營角度審視並影響產品的能力更值得關注。我有權提出異議、表達自己的擔憂，並在距離最終交付還有很久的時候就及時向開發者傳達觀點或提醒他們調整編寫方法。這纔是真正的管理員，他們不該被“囚禁”在地下室裏！
事實很快證明，將產品的設計、開發與運營等元素進行綜合審視，確實能夠帶來巨大的收益。只有每一個人都對產品負責，並清楚意識到產品將在怎樣的生產環境中運行時，開發流程將真正與生產流程融合起來。這一切如今人們習以爲常的思路，在當時不啻爲一種文化衝擊——開發者與管理員真正攜起手來，天下再無難事！而這一切，都是被溝通鴻溝所嚴重割裂的傳統流程所無法實現的。
但如果 DevOps 只是一種敏捷開發流程，而且在其中引入了開發階段的概念，那麼 DevOps 工程師又是幹什麼的？DevOps 世界中的核心職責究竟是什麼？這就帶來了另一個重要問題：DevOps 團隊的理想領袖應該是誰？
團隊負責人的角色可以由中層專業人士擔任，而且對職位或背景沒有特別明確的要求（可以是開發人員、管理員甚至是質量保證人員）。DevOps 之所以存在，主要目的就是填補產品在持續集成、交付以及運行週期中的種種空白。
從個人的主觀角度出發，我認爲 DevOps 領導者最好具有管理員背景（而非選擇所謂的「技術骨幹」）。以此爲基礎，他 / 她能夠將與數據庫升級、配置管理或者一切其他令開發者分心或煩惱的底層基礎設施相關因素剝離出來。這裏，我還要提出另一項管理員有更適合擔任 DevOps 領導工作的觀點：隨着產品的發展與成熟，DevOps 團隊也將隨之擴大，因此需要投入的時間及精力會同步增長。如果指定開發人員領導您的 DevOps 團隊，其將很難全神貫注繼續處理開發工作。最後一個理由：管理員更易於上手 DevOps 工作，所以起步速度會更快一些。
DevOps 工程師該懂些什麼？
DevOps 工程師們應該懂點什麼，又該會做些什麼？本文整理了一份 DevOps 工程師的技能清單，當然列舉的可能不完整，只涵蓋工程師們應當具備的部分核心技能。
敏捷開發原則
這也是現代開發世界中最重要的技能之一（特別是在遠程協作開發場景之下）。其中不僅包括區分 Kanban 與 Scrum 間的差異，同時也要求我們能夠與團隊順暢溝通、瞭解客戶價值、跟蹤時間進度，以及整理出易於理解的工作日誌、獨立報告與清晰說明文檔的能力。
自動化 + 萬物即代碼
大家應該儘快擺脫手動操作的困擾。時至今日，幾乎一切日常工作都對應着自動化工具。如果找不到現成的工具，您也可以使用 Python 及 bash 自行編寫。例如，如果需要創建虛擬機鏡像，請使用 Packer。如果需要配置 10 臺以上的主機，請使用 Ansible。如果您在 Google Cloud Platform 中創建 Kubernertes 集羣，或者需要在 Amazon 上使用 CDN，請使用 Terraform 以簡化操作流程。總而言之，從通過網絡加載新的裸機服務器到在現有集羣中部署新容器，一切都應以自動化方式進行。另外，您編寫的代碼應該具有可複製性與冪等性，提交內容必須經過跟蹤程序的審覈，且嚴格遵循以上要求。
雲與混合架構
目前，我們發現大多數企業都不會只使用一家雲服務供應商（爲了避免供應商鎖定問題）。沒錯，一切不該簡單粗暴地交給雲方案處理，我們可以將服務中的不同部分運行在 AWS、Heroku 以及其他 IaaS、PaaS 與 SaaS 之上。請努力找到最理想的解決方案，並保證能夠在特定時段內完成不同平臺之間的服務遷移。另外，也別忘了之前提到的自動化原則，自動化程度越高、遷移難度就越低。
可擴展性與高可用性要求
最重要的是意識到企業能夠在特定時段內承受怎樣的停機與數據丟失影響。明確這一點之後，大家會發現長達 24 個小時的資源停機假設將毫無意義。另外，資源哪怕只宕機一個小時，造成的損失就可能高於一整年的完整熱備份服務使用成本。藉助雲服務與容器化技術，擴大系統規模變得愈發輕鬆。但是，基礎設施與服務本身也需要爲這種靈活擴展能力做好準備（這裏再次向本地對象存儲開炮，這簡直就是麻煩的終極根源）。
監控與警報
爲了及時做出回顧、預測與響應，我們當然有必要收集系統、應用程序及業務中的一切可用指標。這些指標就像團隊的眼睛，而且無法通過單一監控解決方案全面實現。每種雲服務或平臺都提供自己的一組可用指標與警報，但大家還需要結合需求使用 Librato 或 Datadog 等外部系統，或者在 Prometheus 上構建自定義監控服務。總之，一切選擇都應該以合理的預算、時間及任務需求爲基礎。
安全性
安全保障確實不是 DevOps 工程師的核心職責。但是，大家必須掌握相關安全基礎知識。端點上部署 SSL，策略中沒有 * 號，不存在公開或可寫入的存儲桶、分區需要進行加密，注意部署封閉的防火牆、安全組以及多因素驗證等等。另外，DevOps 還應該與安全部門合作，在實現流程自動化的同時快速在服務中應用新的安全策略。
DevOps 工程師的作用
不需要 DevOps 工程師，太陽似乎也會照常升起……
如果整個業務體系已經配置完成並能夠正常工作，還需要 DevOps 專家幹嘛？說得沒錯，不少開發人員已經建立起一套完善的環境，包括良好運行的數據庫甚至是自動規模伸縮組。當然，更實際的情況，應該是他們在 Heroku 上啓動了相關應用、添加了必要插件，警報和監控指標已經輕鬆實現，一切看起來都無緣美好。
在這種情況下，仍有以下問題需要解決。
- 所有操作通常只能手動完成，如果您的雲服務供應商出了問題，您將無法複製架構或者對架構進行部分還原。
- 由於缺乏對資源消耗的有效控制，這種方案的運營成本很高。在配置完成後，很多服務可能根本沒有發揮作用，但您仍然需要爲此付費。一般來講，快速發佈是開發流程的重中之重，但同時又缺少必要的優惠選項及替代方案等成本調整空間。另外，這類方案大多沒有充分發揮預留實例的成本優勢。
- 部署流程不夠完善。由於缺少統一的測試方法，集成測試往往只是空談。大部分運行測試只能由開發人員在本地執行。
- 某些奇怪的錯誤只出現在生產環境中，但卻無法在本地重現。這會影響客戶對於 IT 部門的信任，最終 IT 部門與項目負責人將成爲不共戴天的死對頭。
- 性能問題時常出現，但原因總不明確。單點故障無處不在，解決與修復需要耗費大量時間，甚至會進一步拖慢已經非常緩慢的開發進程。
- 需要將您的服務遷移至另一平臺，併爲快速增長的業務做好架構層面的準備。
- 監控警報來得太晚，來不及採取行動。開發團隊很可能是最後一幫意識到出了問題的人。在最極端的情況下，甚至用戶和客戶那邊已經怒火中燒，開發團隊卻仍被矇在鼓裏。
這份清單當然不夠完整，我們還可以添加更多問題，其中一些可以通過及時溝通來解決，也有一些需要配合交付與開發流程層面的優化。但要完成這些優化，就得探討純粹的技術技能或者與特定平臺相關的知識，因此本文暫不討論。
原文鏈接：
https://blog.maddevs.io/devops-engineers-in-mad-devs-449ded5221b6