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

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

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

Atlassian 提出的 DevOps 原理

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

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

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

2. 十年前的“DevOps”工作

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

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

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

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

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

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

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

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

敏捷開發(fā)原則

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

自動(dòng)化 + 萬物即代碼

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

云與混合架構(gòu)

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

可擴(kuò)展性與高可用性要求

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

監(jiān)控與警報(bào)

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

安全性

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

4. DevOps 工程師的作用

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

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

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

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

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