DevOps 是繼 Agile、Scrum 和 XP 之后衍生出來，延展到運(yùn)維領(lǐng)域的新興運(yùn)動(dòng)。

大家好，我是京東金融負(fù)責(zé) PE 團(tuán)隊(duì)的負(fù)責(zé)人王超，很多人可能還不太了解 PE 這個(gè)崗位，PE 這個(gè)崗位在雅虎、阿里、Facebook 等多個(gè)互聯(lián)網(wǎng)公司都有，全稱是 Product Engineer（產(chǎn)品運(yùn)維工程師），也有一些公司叫應(yīng)用運(yùn)維。

可以簡單定義為生產(chǎn)環(huán)境的產(chǎn)品的技術(shù)運(yùn)營，在京東金融所有生產(chǎn)環(huán)境的業(yè)務(wù)運(yùn)維、大數(shù)據(jù)及中間件的運(yùn)維都是需要 PE 團(tuán)隊(duì)主導(dǎo)或主要參與。

我過往的經(jīng)歷是在人人網(wǎng)負(fù)責(zé) PE 運(yùn)維團(tuán)隊(duì)，再早的時(shí)候是在一家傳統(tǒng)的大型央企里負(fù)責(zé)應(yīng)用運(yùn)維。

從三個(gè)公司的職業(yè)發(fā)展路線來看，我經(jīng)歷了從傳統(tǒng)行業(yè)到大型互聯(lián)網(wǎng)公司，再到互聯(lián)網(wǎng)金融的幾次轉(zhuǎn)變。不同的經(jīng)歷帶給我不同的思考角度，這也是我希望跟大家分享的內(nèi)容。

運(yùn)維體系四象限

運(yùn)維體系的關(guān)注點(diǎn)主要有這四項(xiàng)：速度、質(zhì)量、成本、安全。

速度

公司里最重要的是如何創(chuàng)造更大的業(yè)務(wù)價(jià)值，產(chǎn)品的發(fā)布要快，技術(shù)的瓶頸不能成為業(yè)務(wù)快速迭代、新產(chǎn)品上線推廣的制約因素。

質(zhì)量

業(yè)務(wù)的快速交付，線上的質(zhì)量仍然需要保證。

成本

人員成本和IT運(yùn)行成本一直是互聯(lián)網(wǎng)公司的兩大項(xiàng)支出，對于大規(guī)模互聯(lián)網(wǎng)公司，服務(wù)器規(guī)模幾萬幾十萬，對資源的優(yōu)化，服務(wù)性能的提升，合理的評估容量水位線，以及預(yù)算制定，成本核算，這些也都是運(yùn)維需要做的工作。

安全

尤其對于金融行業(yè)來說，安全是非常重要的。支付行業(yè)有一個(gè)名詞叫資損，代表資金受到損失。在交易過程中可能會存在重復(fù)發(fā)單、營銷活動(dòng)，比如說給用戶多發(fā)了錢，而且用戶提現(xiàn)了，這筆錢追不回來，就造成了資損。

因?yàn)榧夹g(shù)或業(yè)務(wù)上的問題可能導(dǎo)致的資金損失會達(dá)到上千萬甚至更多，所以作為金融行業(yè)的運(yùn)維人員，一定要重視安全問題。

DevOps介紹

DevOps 是繼 Agile、Scrum 和 XP 之后衍生出來的，延展到運(yùn)維領(lǐng)域中的新興的運(yùn)動(dòng)。

DevOps解決的問題

DevOps 協(xié)調(diào)開發(fā)、QA 測試和技術(shù)運(yùn)維三種角色，加強(qiáng)了相互之間緊密的溝通協(xié)作。

從項(xiàng)目規(guī)劃、代碼開發(fā)、構(gòu)建、測試，再到發(fā)布、部署、運(yùn)營和監(jiān)控，DevOp 是一個(gè)閉合的環(huán)，保持著持續(xù)的不中斷的迭代發(fā)布部署。

而其中的***幾個(gè)環(huán)節(jié)，運(yùn)營監(jiān)控并反饋到需求方，往往是容易被忽視的環(huán)境，而 DevOps 強(qiáng)調(diào)了反饋（Feedback）的重要性，完成了部署以后一定要通知到需求的提出者，讓業(yè)務(wù)方進(jìn)行確認(rèn)，保證結(jié)果得到驗(yàn)證。

如果參加過 DevOps Mster 沙盤訓(xùn)練應(yīng)該會對這一點(diǎn)深有體會，DevOps 對業(yè)務(wù)最重要的作用就是保證業(yè)務(wù)戰(zhàn)略快速推進(jìn)和快速回饋。

開發(fā)與運(yùn)維之間往往會存在部門墻，其中一個(gè)原因是，運(yùn)維注重的是安全穩(wěn)定，開發(fā)注重的上線發(fā)布的速度。思考問題的出發(fā)點(diǎn)不同，導(dǎo)致了相互之間理解的不同、溝通的不暢。

運(yùn)維為了保證生產(chǎn)環(huán)境的穩(wěn)定性，可能每周只設(shè)定一個(gè)上線窗口，在每周三晚上上線一次，可能開發(fā)會覺得等不到這么久，因?yàn)闃I(yè)務(wù)的需求很著急上線。

這不僅僅是技術(shù)問題，也涉及到業(yè)務(wù)和組織結(jié)構(gòu)管理的問題。讓我們先從 DevOps 的思想分析一下問題。

DevOps 認(rèn)為更小、更頻繁的變更意味著更少的風(fēng)險(xiǎn)

傳統(tǒng)模式的公司 IT 可能一個(gè)月或一個(gè)季度才發(fā)一個(gè)版，可對于互聯(lián)網(wǎng)公司來說這個(gè)周期就太長了。

比如業(yè)務(wù)上提了一個(gè)緊急需求，要周末辦一個(gè)推廣活動(dòng)，網(wǎng)站要上線新頁面，但運(yùn)維如果說下個(gè)月才能上線，業(yè)務(wù)上就已經(jīng)沒有價(jià)值了。所以技術(shù)上需要支持更快更頻繁的變更。

如果把需求切割成更小的粒度，每次變化的代碼量更少了，意味著這部分的測試也更明確，代碼審核起來也比較快，所以風(fēng)險(xiǎn)可以控制的更低，發(fā)現(xiàn)問題也可以馬上回退解決。

讓開發(fā)人員更多地控制生產(chǎn)環(huán)境

讓開發(fā)人員更多地控制生產(chǎn)環(huán)境，但不是簡單的把運(yùn)維操作權(quán)限交給開發(fā)人員，因?yàn)椴僮鞯娘L(fēng)險(xiǎn)還是要控制。

以京東金融為例，我們的做法是讓開發(fā)人員參與生產(chǎn)和運(yùn)維，但并不是直接登錄到機(jī)器上操作，而是在運(yùn)維平臺上授權(quán)受限制的操作，如應(yīng)用的創(chuàng)建，發(fā)布部署，啟停等。

我們也需要提供相應(yīng)的監(jiān)控系統(tǒng)、日志平臺，可以讓開發(fā)人員在平臺上進(jìn)行查看日志、檢測服務(wù)狀態(tài)等操作，不需要登錄服務(wù)器。

以應(yīng)用程序?yàn)橹行睦斫饣A(chǔ)設(shè)施

應(yīng)用程序?qū)Φ讓迎h(huán)境有沒有依賴，發(fā)布在物理機(jī)還是虛擬機(jī)上，根據(jù)業(yè)務(wù)的需求需要部署多大規(guī)模的服務(wù)節(jié)點(diǎn)。

如果做多機(jī)房部署，這樣類似的問題我們希望在上線前就跟研發(fā)同學(xué)做好溝通，制定好整體的技術(shù)架構(gòu)和部署架構(gòu)，研發(fā)同學(xué)對基礎(chǔ)設(shè)施有更好的理解對整體架構(gòu)的優(yōu)化非常有幫助。

設(shè)計(jì)簡潔明了的流程，盡可能自動(dòng)化

人、流程和技術(shù)，這三者是技術(shù)管理中很重要的三個(gè)因素。人與人之間都存在差異性，思維角度不一樣，而且互聯(lián)網(wǎng)公司人員的流動(dòng)性也很大，所以人其實(shí)是不太好控制的。

而流程雖然重要，但是如果只是靠人的約定去執(zhí)行的流程，得不到好的落地，效果一定不會好。因此我們的做法是依靠平臺，把流程固化到平臺里，在平臺中規(guī)避有風(fēng)險(xiǎn)的操作。

通過引導(dǎo)式的流程，完成應(yīng)用立項(xiàng)，應(yīng)用發(fā)布，擴(kuò)容縮容等操作，因?yàn)槊恳徊蕉加休^好的提示，很少出現(xiàn)誤操作的情況。

促成開發(fā)人員與運(yùn)營人員的協(xié)作

DevOps 的***目標(biāo)是建立流水線式的準(zhǔn)時(shí)制（JIT）的業(yè)務(wù)流程，***化業(yè)務(wù)產(chǎn)出。業(yè)務(wù)產(chǎn)出最終的衡量應(yīng)該以業(yè)務(wù)交付完成的指標(biāo)來判斷，也就是說是否準(zhǔn)時(shí)上線了，以及上線后業(yè)務(wù)人員是否認(rèn)可。

康威定律，設(shè)計(jì)系統(tǒng)的組織，其產(chǎn)生的設(shè)計(jì)和架構(gòu)等價(jià)于組織間的溝通結(jié)構(gòu)。反過來，如果你的系統(tǒng)設(shè)計(jì)或架構(gòu)不支持，那就無法成功建立一個(gè)有效的組織。

不同公司的組織架構(gòu)不一樣，往往導(dǎo)致服務(wù)架構(gòu)也不一樣。DevOps 場景下如何設(shè)計(jì)合理的組織架構(gòu)，也是我們需要思考的問題。

組織架構(gòu)設(shè)計(jì)的時(shí)候，比較有意思的一點(diǎn)就是該如何去打造高效的開發(fā)和交付小團(tuán)隊(duì)，就像上圖“雙比薩團(tuán)隊(duì)”說的那樣，如果你不能給一個(gè)團(tuán)隊(duì)提供兩個(gè)比薩餅，那么這個(gè)團(tuán)隊(duì)就太大了。

要想達(dá)成組織結(jié)構(gòu)的高效，***層的小團(tuán)隊(duì)在一塊就需要多溝通、多碰撞，所以怎么設(shè)計(jì)你的更容易溝通的組織結(jié)構(gòu)也很關(guān)鍵 。

如上圖所示，上面是開發(fā)、產(chǎn)品、測試，下面對應(yīng)的是 SA、DBA、運(yùn)維開發(fā)、安全、網(wǎng)絡(luò)部門，PE 的角色起到了相互銜接的作用。

PE 的角色也有點(diǎn)像特種部隊(duì)，特種部隊(duì)經(jīng)常是三人為一組執(zhí)行外勤任務(wù)，這三個(gè)人里可能還有一些分工，有的人偏戰(zhàn)略指揮、有的人負(fù)責(zé)執(zhí)行任務(wù)、有的人負(fù)責(zé)聯(lián)絡(luò)通信。

而在這三個(gè)人后面，往往還有幾百人在做大后方的支持。后勤人員通過特種部隊(duì)的攝像頭等設(shè)備，對回傳信息做數(shù)據(jù)分析，指導(dǎo)特種部隊(duì)行動(dòng)路線，執(zhí)行計(jì)劃等。

作為參考，我覺得我們在運(yùn)維工作中也需要小而靈活的團(tuán)隊(duì)來跟產(chǎn)品、開發(fā)的人進(jìn)行更直接的溝通，了解需求，根據(jù)需求制定解決方案，解決遇到的問題。

所以我負(fù)責(zé)的 PE 團(tuán)隊(duì)也盡量設(shè)定成三四個(gè)人一組跟進(jìn)某些業(yè)務(wù)線，其中每個(gè)人都可以盡量多了解對應(yīng)的業(yè)務(wù)，當(dāng)需要運(yùn)維的其他部門配合時(shí)，再把這些業(yè)務(wù)需求轉(zhuǎn)換成運(yùn)維的術(shù)語，傳遞給運(yùn)維內(nèi)部的其他部門 。

DevOps 的原則

• DevOps 官方的五大原則：
• 文化（Culture）
• 自動(dòng)化（Automation）
• 精益（Lean）
• 數(shù)據(jù)度量（Measurement）
• 分享（Sharing）

重點(diǎn)提一下數(shù)據(jù)度量（Measurement）。

監(jiān)控如果做得不到位，小的問題不容易發(fā)現(xiàn)，一出問題就是業(yè)務(wù)中斷的大問題。

大的互聯(lián)網(wǎng)公司的監(jiān)控工具一般都會對時(shí)延非常的敏感，如內(nèi)部廣泛使用的 APM 應(yīng)用級性能監(jiān)控工具，如果某個(gè)應(yīng)用的服務(wù)接口性能從 100 毫秒變成 120 毫秒，很可能就會觸發(fā)報(bào)警，報(bào)警就會驅(qū)動(dòng)大家去查為什么接口性能慢了、是不是硬件問題、是不是網(wǎng)絡(luò)問題，運(yùn)維會配合開發(fā)進(jìn)行細(xì)致的調(diào)查。

這些細(xì)小的問題驅(qū)動(dòng)了我們在技術(shù)上多去分析思考，也會促進(jìn)我們開發(fā)更細(xì)粒度的監(jiān)控和分析工具排查問題。

DevOps 體系建設(shè)

應(yīng)用全生命周期管理

應(yīng)用從立項(xiàng)到發(fā)布上線、不斷的迭代變更、擴(kuò)容、縮容、遷移以及生命周期結(jié)束后的下線，需要一個(gè)完整的生命周期的管理。

我們做應(yīng)用的全生命周期的管理時(shí)，結(jié)合了內(nèi)部的流程系統(tǒng)、應(yīng)用信息管理系統(tǒng)、自動(dòng)部署系統(tǒng)，并對外提供 API 接口。

應(yīng)用中心類似 CMDB，但 CMDB 偏底層基礎(chǔ)設(shè)施一些，比如管理操作系統(tǒng)、物理機(jī)、網(wǎng)絡(luò)、數(shù)據(jù)中心。但是應(yīng)用生命周期更關(guān)心應(yīng)用本身和周邊關(guān)聯(lián)的系統(tǒng)。

應(yīng)用立項(xiàng)時(shí)需要做很多工作，確定所用資源的套餐，根據(jù)業(yè)務(wù)容量規(guī)劃需要的節(jié)點(diǎn)數(shù)量、基礎(chǔ)組件的版本、網(wǎng)絡(luò)拓?fù)?、網(wǎng)絡(luò)申請、網(wǎng)絡(luò)權(quán)限等，立項(xiàng)以后還會經(jīng)過很多次的信息變更。

如果僅依賴文檔把每次變更做記錄，很容易在人員交接流轉(zhuǎn)的過程中信息遺漏丟失，給后續(xù)接手的人操作帶來風(fēng)險(xiǎn)。通過在系統(tǒng)間自動(dòng)化流轉(zhuǎn)的時(shí)候自動(dòng)記錄下應(yīng)用信息，保證了應(yīng)用信息和生產(chǎn)環(huán)境的一致。

這些信息也作為服務(wù)對外提供接口。舉個(gè)例子，應(yīng)用監(jiān)控的配置如果脫離應(yīng)用系統(tǒng)單獨(dú)維護(hù)，每次應(yīng)用擴(kuò)容縮容都需要通知到監(jiān)控系統(tǒng)進(jìn)行修改，很容易造成應(yīng)用擴(kuò)容或者遷移后監(jiān)控會有遺漏，造成潛在風(fēng)險(xiǎn)。

但是監(jiān)控系統(tǒng)以應(yīng)用中心對外提供的接口數(shù)據(jù)作為基礎(chǔ)信息，就保證了數(shù)據(jù)都是實(shí)時(shí)準(zhǔn)確的，也避免了各個(gè)系統(tǒng)重新配置的工作。

Infrastructure as Code—DevOps的基礎(chǔ)

應(yīng)用部署的工作對基礎(chǔ)環(huán)境的依賴非常大，比如 Python 程序的部署，對 Python 版本的依賴，再底層的 OpenSSL 等文件庫的依賴，以及對操作系統(tǒng)的依賴。

早期的運(yùn)維很多都是通過腳本+配置文件的方式來實(shí)現(xiàn)批量執(zhí)行的，判斷需要的依賴環(huán)境，再進(jìn)行依次安裝，每次執(zhí)行前可能還需要臨時(shí)修改腳本或者配置文件的內(nèi)容，比如要操作的 IP 列表文件。復(fù)雜的任務(wù)以及多人操作的時(shí)候這樣的方式就存在了較大的風(fēng)險(xiǎn)。

Puppet、Ansible、Chef 這些配置管理工具很好的解決了這個(gè)問題，這些工具指導(dǎo)我們更多的通過配置管理的方式，如把軟件部署的依賴關(guān)系通過 Ansible Playbook 來定義，通過角色分組嚴(yán)格的控制執(zhí)行的目標(biāo)狀態(tài)，操作可以重復(fù)執(zhí)行，哪個(gè)環(huán)節(jié)出現(xiàn)問題也可以準(zhǔn)確定位，結(jié)果得到了更好的保障。

而容器時(shí)期的到來，首先是更好的解決了環(huán)境的一致性的問題，通過鏡像封裝的方式將基礎(chǔ)環(huán)境打包到了容器鏡像中，保證了從開發(fā)、測試、到生產(chǎn)的環(huán)境一致性。

Mesos、Kubernetes 等流程編排工具更好的解決了部署的問題，只需要關(guān)注應(yīng)用本身的信息以及部署的規(guī)模，平臺已經(jīng)解決掉了大部分的問題。

熟悉技術(shù)架構(gòu)

運(yùn)維跟開發(fā)人員一樣，需要多了解技術(shù)架構(gòu)和業(yè)務(wù)架構(gòu)。

多了解技術(shù)架構(gòu)和業(yè)務(wù)架構(gòu)，才能在生產(chǎn)遇到問題時(shí)更好的理解和處理問題，在理解研發(fā)提出的需求時(shí)更好地理解問題，甚至提出更好的解決方案。

Platform as Code

業(yè)務(wù)架構(gòu)中主要用的一些基礎(chǔ)組件 ：

• GSLB
• 網(wǎng)關(guān)
• 服務(wù)化組件
• 消息中間件
• 緩存
• 配置管理平臺
• 分布式調(diào)度
• APM
• 日志平臺

未來展望

數(shù)據(jù)化運(yùn)維

運(yùn)維行業(yè)也會細(xì)分，業(yè)務(wù)運(yùn)維的角色會越來越像數(shù)據(jù)化的運(yùn)營，從應(yīng)用的整個(gè)生命周期持續(xù)的跟進(jìn)和優(yōu)化，關(guān)注更快的迭代、更高的訪問質(zhì)量、安全的威脅，關(guān)注成本的分析，這些問題也促進(jìn)我們不斷的深耕技術(shù)，為業(yè)務(wù)提供價(jià)值。

為了更好的質(zhì)量，我們需要做好以下的數(shù)據(jù)監(jiān)控：

• 基礎(chǔ)服務(wù)監(jiān)控（網(wǎng)絡(luò)、OS、DNS 等）
• 數(shù)據(jù)服務(wù)監(jiān)控（DB、緩存、消息等）
• 應(yīng)用性能監(jiān)控
• 分布式調(diào)用跟蹤和監(jiān)控
• 日志監(jiān)控
• 業(yè)務(wù)指標(biāo)監(jiān)控

智能運(yùn)維——AIOps

現(xiàn)在 AIOps 也是很熱門的研究方向，分享幾個(gè)主要思考點(diǎn)：

• 采集數(shù)據(jù)是基礎(chǔ)，事件信息匯總、對數(shù)據(jù)需要打標(biāo)簽；
• 報(bào)警關(guān)聯(lián)分析，找根本原因；
• 自動(dòng)報(bào)警降級或升級；
• 容量水位線預(yù)估與自動(dòng)擴(kuò)容；
• 從人工規(guī)則向機(jī)器學(xué)習(xí)過渡。

希望后面再找時(shí)間詳細(xì)地展開分享。

[[239196]]

王超，京東金融資深技術(shù)架構(gòu)師、應(yīng)用運(yùn)維團(tuán)隊(duì)負(fù)責(zé)人（PE 團(tuán)隊(duì)），也曾負(fù)責(zé)人人網(wǎng) PE 團(tuán)隊(duì)。經(jīng)歷了京東金融運(yùn)維體系從 0 到 N 的過程、數(shù)次 618 和雙十一大促的考驗(yàn)。目前主要關(guān)注 DevOps、運(yùn)維與架構(gòu)的融合、業(yè)務(wù)可用性保障、運(yùn)維平臺建設(shè)和團(tuán)隊(duì)管理。