在公司成立之前，我們團隊就已經(jīng)開始應(yīng)用 DevOps 實踐，而我個人，早在十年前，在另一家公司擔(dān)任系統(tǒng)管理員的時候，就第一次接觸到了這種新鮮的思維方式。那個時候，還沒有 DevOps 這種標(biāo)準(zhǔn)說法，但是當(dāng)時實踐的人也自己摸索出了一些相關(guān)的概念與原則。

• 持續(xù)集成；
• 自動交付；
• 每位團隊成員都對產(chǎn)品負(fù)有責(zé)任；
• 與客戶直接溝通；
• 收集并分析業(yè)務(wù) / 應(yīng)用程序指標(biāo)；
• 說明文檔等；

后來證明以上這一切都是對敏捷倡議中各項實踐的邏輯擴展，而催生出這些方法的溫床，則是開發(fā)者不再單純?yōu)楸镜刂鳈C編寫代碼這一基本前提。

Atlassian 提出的 DevOps 原理

由 Atlassian 提出的 DevOps 模式直到今天仍然非常重要。從本質(zhì)上講，其代表著產(chǎn)品開發(fā)與交付的現(xiàn)代化周期，同時涵蓋產(chǎn)品啟動之后的運作流程。

1. 前 DevOps 時代：管理員與開發(fā)者之間的鴻溝

長久以來，產(chǎn)品的運營與開發(fā)工作彼此割裂。這條鴻溝的一端是勤勞樸實的開發(fā)人員，另一端則是開發(fā)者眼中那些如同行尸走肉般的系統(tǒng)管理員。系統(tǒng)管理員不參與開發(fā)，也不會與開發(fā)團隊溝通，他們通常只是直接拿到代碼包，然后嘗試在某個位置加以運行。每一次運行嘗試都痛苦萬分，管理員們需要花幾天時間慢慢查看日志、尋找種種難以理解的錯誤、分析數(shù)據(jù)庫查詢、陷入無窮無盡的 strace 過程等。而很多時候的事實都證明，只需要定義一項新的環(huán)境變量或者添加一個新參數(shù)，問題就能迎刃而解。但遺憾的是，開發(fā)者從來不會、也沒有機會把情況告知管理員，后者唯一了解的就是產(chǎn)品的名稱及其用什么語言編寫而成……

2. 十年前的“DevOps”工作

十年之前，我剛開始在團隊中擔(dān)任管理員，當(dāng)時的公司思維比較靈活，我不像《IT 狂人》的劇情那樣被安排在地下室某個陰暗的小房間里，而是在開發(fā)者當(dāng)中擁有了自己的辦公桌。從那一刻開始，我也踏上了自己的 DevOps 工程師之旅。

在公司的工作中，我很快意識到，雖然知識和技能都很重要，但從溝通及運營角度審視并影響產(chǎn)品的能力更值得關(guān)注。我有權(quán)提出異議、表達(dá)自己的擔(dān)憂，并在距離最終交付還有很久的時候就及時向開發(fā)者傳達(dá)觀點或提醒他們調(diào)整編寫方法。這才是真正的管理員，他們不該被“囚禁”在地下室里！

事實很快證明，將產(chǎn)品的設(shè)計、開發(fā)與運營等元素進(jìn)行綜合審視，確實能夠帶來巨大的收益。只有每一個人都對產(chǎn)品負(fù)責(zé)，并清楚意識到產(chǎn)品將在怎樣的生產(chǎn)環(huán)境中運行時，開發(fā)流程將真正與生產(chǎn)流程融合起來。這一切如今人們習(xí)以為常的思路，在當(dāng)時不啻為一種文化沖擊——開發(fā)者與管理員真正攜起手來，天下再無難事！而這一切，都是被溝通鴻溝所嚴(yán)重割裂的傳統(tǒng)流程所無法實現(xiàn)的。

但如果 DevOps 只是一種敏捷開發(fā)流程，而且在其中引入了開發(fā)階段的概念，那么 DevOps 工程師又是干什么的？DevOps 世界中的核心職責(zé)究竟是什么？這就帶來了另一個重要問題：DevOps 團隊的理想領(lǐng)袖應(yīng)該是誰？

團隊負(fù)責(zé)人的角色可以由中層專業(yè)人士擔(dān)任，而且對職位或背景沒有特別明確的要求（可以是開發(fā)人員、管理員甚至是質(zhì)量保證人員）。DevOps 之所以存在，主要目的就是填補產(chǎn)品在持續(xù)集成、交付以及運行周期中的種種空白。

從個人的主觀角度出發(fā)，我認(rèn)為 DevOps 領(lǐng)導(dǎo)者最好具有管理員背景（而非選擇所謂的「技術(shù)骨干」）。以此為基礎(chǔ)，他 / 她能夠?qū)⑴c數(shù)據(jù)庫升級、配置管理或者一切其他令開發(fā)者分心或煩惱的底層基礎(chǔ)設(shè)施相關(guān)因素剝離出來。這里，我還要提出另一項管理員有更適合擔(dān)任 DevOps 領(lǐng)導(dǎo)工作的觀點：隨著產(chǎn)品的發(fā)展與成熟，DevOps 團隊也將隨之?dāng)U大，因此需要投入的時間及精力會同步增長。如果指定開發(fā)人員領(lǐng)導(dǎo)您的 DevOps 團隊，其將很難全神貫注繼續(xù)處理開發(fā)工作。最后一個理由：管理員更易于上手 DevOps 工作，所以起步速度會更快一些。

3. DevOps 工程師該懂些什么？

DevOps 工程師們應(yīng)該懂點什么，又該會做些什么？本文整理了一份 DevOps 工程師的技能清單，當(dāng)然列舉的可能不完整，只涵蓋工程師們應(yīng)當(dāng)具備的部分核心技能。

敏捷開發(fā)原則

這也是現(xiàn)代開發(fā)世界中最重要的技能之一（特別是在遠(yuǎn)程協(xié)作開發(fā)場景之下）。其中不僅包括區(qū)分 Kanban 與 Scrum 間的差異，同時也要求我們能夠與團隊順暢溝通、了解客戶價值、跟蹤時間進(jìn)度，以及整理出易于理解的工作日志、獨立報告與清晰說明文檔的能力。

自動化 + 萬物即代碼

大家應(yīng)該盡快擺脫手動操作的困擾。時至今日，幾乎一切日常工作都對應(yīng)著自動化工具。如果找不到現(xiàn)成的工具，您也可以使用 Python 及 bash 自行編寫。例如，如果需要創(chuàng)建虛擬機鏡像，請使用 Packer。如果需要配置 10 臺以上的主機，請使用 Ansible。如果您在 Google Cloud Platform 中創(chuàng)建 Kubernertes 集群，或者需要在 Amazon 上使用 CDN，請使用 Terraform 以簡化操作流程?？偠灾瑥耐ㄟ^網(wǎng)絡(luò)加載新的裸機服務(wù)器到在現(xiàn)有集群中部署新容器，一切都應(yīng)以自動化方式進(jìn)行。另外，您編寫的代碼應(yīng)該具有可復(fù)制性與冪等性，提交內(nèi)容必須經(jīng)過跟蹤程序的審核，且嚴(yán)格遵循以上要求。

云與混合架構(gòu)

目前，我們發(fā)現(xiàn)大多數(shù)企業(yè)都不會只使用一家云服務(wù)供應(yīng)商（為了避免供應(yīng)商鎖定問題）。沒錯，一切不該簡單粗暴地交給云方案處理，我們可以將服務(wù)中的不同部分運行在 AWS、Heroku 以及其他 IaaS、PaaS 與 SaaS 之上。請努力找到最理想的解決方案，并保證能夠在特定時段內(nèi)完成不同平臺之間的服務(wù)遷移。另外，也別忘了之前提到的自動化原則，自動化程度越高、遷移難度就越低。

可擴展性與高可用性要求

最重要的是意識到企業(yè)能夠在特定時段內(nèi)承受怎樣的停機與數(shù)據(jù)丟失影響。明確這一點之后，大家會發(fā)現(xiàn)長達(dá) 24 個小時的資源停機假設(shè)將毫無意義。另外，資源哪怕只宕機一個小時，造成的損失就可能高于一整年的完整熱備份服務(wù)使用成本。借助云服務(wù)與容器化技術(shù)，擴大系統(tǒng)規(guī)模變得愈發(fā)輕松。但是，基礎(chǔ)設(shè)施與服務(wù)本身也需要為這種靈活擴展能力做好準(zhǔn)備（這里再次向本地對象存儲開炮，這簡直就是麻煩的終極根源）。

監(jiān)控與警報

為了及時做出回顧、預(yù)測與響應(yīng)，我們當(dāng)然有必要收集系統(tǒng)、應(yīng)用程序及業(yè)務(wù)中的一切可用指標(biāo)。這些指標(biāo)就像團隊的眼睛，而且無法通過單一監(jiān)控解決方案全面實現(xiàn)。每種云服務(wù)或平臺都提供自己的一組可用指標(biāo)與警報，但大家還需要結(jié)合需求使用 Librato 或 Datadog 等外部系統(tǒng)，或者在 Prometheus 上構(gòu)建自定義監(jiān)控服務(wù)?？傊?，一切選擇都應(yīng)該以合理的預(yù)算、時間及任務(wù)需求為基礎(chǔ)。

安全性

安全保障確實不是 DevOps 工程師的核心職責(zé)。但是，大家必須掌握相關(guān)安全基礎(chǔ)知識。端點上部署 SSL，策略中沒有 * 號，不存在公開或可寫入的存儲桶、分區(qū)需要進(jìn)行加密，注意部署封閉的防火墻、安全組以及多因素驗證等等。另外，DevOps 還應(yīng)該與安全部門合作，在實現(xiàn)流程自動化的同時快速在服務(wù)中應(yīng)用新的安全策略。

4. DevOps 工程師的作用

不需要 DevOps 工程師，太陽似乎也會照常升起……

如果整個業(yè)務(wù)體系已經(jīng)配置完成并能夠正常工作，還需要 DevOps 專家干嘛？說得沒錯，不少開發(fā)人員已經(jīng)建立起一套完善的環(huán)境，包括良好運行的數(shù)據(jù)庫甚至是自動規(guī)模伸縮組。當(dāng)然，更實際的情況，應(yīng)該是他們在 Heroku 上啟動了相關(guān)應(yīng)用、添加了必要插件，警報和監(jiān)控指標(biāo)已經(jīng)輕松實現(xiàn)，一切看起來都無緣美好。

在這種情況下，仍有以下問題需要解決。

• 所有操作通常只能手動完成，如果您的云服務(wù)供應(yīng)商出了問題，您將無法復(fù)制架構(gòu)或者對架構(gòu)進(jìn)行部分還原。
• 由于缺乏對資源消耗的有效控制，這種方案的運營成本很高。在配置完成后，很多服務(wù)可能根本沒有發(fā)揮作用，但您仍然需要為此付費。一般來講，快速發(fā)布是開發(fā)流程的重中之重，但同時又缺少必要的優(yōu)惠選項及替代方案等成本調(diào)整空間。另外，這類方案大多沒有充分發(fā)揮預(yù)留實例的成本優(yōu)勢。
• 部署流程不夠完善。由于缺少統(tǒng)一的測試方法，集成測試往往只是空談。大部分運行測試只能由開發(fā)人員在本地執(zhí)行。
• 某些奇怪的錯誤只出現(xiàn)在生產(chǎn)環(huán)境中，但卻無法在本地重現(xiàn)。這會影響客戶對于 IT 部門的信任，最終 IT 部門與項目負(fù)責(zé)人將成為不共戴天的死對頭。
• 性能問題時常出現(xiàn)，但原因總不明確。單點故障無處不在，解決與修復(fù)需要耗費大量時間，甚至?xí)M(jìn)一步拖慢已經(jīng)非常緩慢的開發(fā)進(jìn)程。
• 需要將您的服務(wù)遷移至另一平臺，并為快速增長的業(yè)務(wù)做好架構(gòu)層面的準(zhǔn)備。
• 監(jiān)控警報來得太晚，來不及采取行動。開發(fā)團隊很可能是最后一幫意識到出了問題的人。在最極端的情況下，甚至用戶和客戶那邊已經(jīng)怒火中燒，開發(fā)團隊卻仍被蒙在鼓里。

這份清單當(dāng)然不夠完整，我們還可以添加更多問題，其中一些可以通過及時溝通來解決，也有一些需要配合交付與開發(fā)流程層面的優(yōu)化。但要完成這些優(yōu)化，就得探討純粹的技術(shù)技能或者與特定平臺相關(guān)的知識，因此本文暫不討論。