基于DevOps的運(yùn)維與開發(fā)架構(gòu)

1、 基于DevOps的運(yùn)維與開發(fā)架構(gòu)運(yùn)維開發(fā)這個(gè)崗位與普通的業(yè)務(wù)開發(fā)不同，與日常的運(yùn)維工作也不同。要求兼顧開發(fā)與運(yùn)維兩種能力。既要掌握不弱于業(yè)務(wù)開發(fā)的開發(fā)技術(shù)；又要負(fù)責(zé)SRE同學(xué)日常的運(yùn)維能力；上線之前，還要像QA同學(xué)一樣，對(duì)自己的服務(wù)進(jìn)行測(cè)試和分級(jí)變更。多種能力的交叉，造就不一樣的視角：這群人給自己起了一個(gè)很簡(jiǎn)約的名字：DevOps。DevOps按百度百科解釋：DevOps是開發(fā)、技術(shù)運(yùn)營(yíng)和質(zhì)量保障三者的交集。在我看來，DevOps其實(shí)只是一種方法論，從這種綜合的視角出發(fā)，包含一些基本原則和實(shí)踐方法，僅此而已。DevOps從架構(gòu)、開發(fā)、測(cè)試、發(fā)布、運(yùn)維、變更整個(gè)流程來考量，從這種綜合的視角出發(fā)

2、，能將部門之間的溝通隔閡消滅于無形，會(huì)給我們公司和項(xiàng)目注入新的活力。DevOps這個(gè)概念，本文暫不做討論，本文內(nèi)容只針對(duì)運(yùn)維領(lǐng)域自動(dòng)化平臺(tái)開發(fā)的工作進(jìn)行探討。一、前言運(yùn)維開發(fā)的工作，所需能力的復(fù)雜，工作性質(zhì)的交叉，自然會(huì)導(dǎo)致很多同學(xué)在其中會(huì)有些困擾。很多剛畢業(yè)的小同學(xué)，接到運(yùn)維開發(fā)的offer的時(shí)候，很可能是一頭霧水：“運(yùn)維？開發(fā)？到底是運(yùn)維還是開發(fā)？”有很多從業(yè)多年的同學(xué)，拼命的追求技術(shù)與對(duì)底層的探索，卻忽略了產(chǎn)品層面的思考。還有很多整天忙忙碌碌的同學(xué)，在業(yè)務(wù)方各種零碎的需求中修修改改，消耗了大多數(shù)的時(shí)間，最終平臺(tái)卻變得千瘡百孔。本文，我將自己關(guān)于這些問題的思考分享給大家。二、什么樣的平臺(tái)是

3、好的運(yùn)維平臺(tái)？既然我們是在做平臺(tái)，那我們要了解的第一點(diǎn)就是：好的運(yùn)維平臺(tái)是什么樣子的？如果讓我們來從頭設(shè)計(jì)一個(gè)平臺(tái)，我們應(yīng)該如何去考量？1、效率 & 成本的均衡運(yùn)維平臺(tái)是服務(wù)于運(yùn)維的。對(duì)運(yùn)維來說，除了穩(wěn)定性之外，最重要的無非就是效率與成本。如果我們的平臺(tái)可以用更少量的時(shí)間或資源成本來提高更多的效率，那就是一個(gè)非常成功的平臺(tái)了。至于如何量化比較，就因系統(tǒng)而異了。2、體驗(yàn) & 人性化為什么我要把體驗(yàn)放在第二位？因?yàn)橛刑嗟倪\(yùn)維開發(fā)工程師，在開發(fā)的過程中，過多地注重系統(tǒng)的穩(wěn)定性和性能，完全不把體驗(yàn)放在眼里了。我想說的是，有時(shí)候，如果不關(guān)注用戶體驗(yàn)，我們做了再好的功能，沒有人用，那這個(gè)功能意義何在？用

4、戶價(jià)值與用戶體驗(yàn)在某些情況下，是會(huì)畫等號(hào)的。3、優(yōu)秀的系統(tǒng)架構(gòu)在業(yè)界，無論是運(yùn)維系統(tǒng)也好，業(yè)務(wù)系統(tǒng)也好，優(yōu)秀系統(tǒng)的架構(gòu)都是大同小異的：穩(wěn)定性：負(fù)載均衡、多活等。擴(kuò)展性：每次增加功能，可以很小的開發(fā)成本實(shí)現(xiàn)，而不是每次都要重構(gòu)。伸縮性：沒有核心的單點(diǎn)，大部分性能瓶頸，都可以通過橫向擴(kuò)展來解決。自我保護(hù)：把可能會(huì)導(dǎo)致性能瓶頸的點(diǎn)都拆解開，用隊(duì)列、限流等手段消除流量突增的高峰帶來的危害，保護(hù)自身。安全性：敏感服務(wù)加入權(quán)限與認(rèn)證，Web服務(wù)避免常見的漏洞如SQL注入、XSS、CSRF等。做好操作記錄方便后續(xù)審計(jì)，盡量不要出現(xiàn)短板。三、如何運(yùn)維自己開發(fā)的平臺(tái)？運(yùn)維開發(fā)在大多數(shù)時(shí)候，要負(fù)責(zé)運(yùn)維自己開發(fā)出來

5、的系統(tǒng)，俗稱吃自己的狗糧；而很多人跳槽之后，第一件事情，也是從運(yùn)維別人的系統(tǒng)開始的。那我們?nèi)绾芜\(yùn)維好一個(gè)平臺(tái)呢？運(yùn)維與開發(fā)的工作，思路其實(shí)不盡相同。雖然都是基于穩(wěn)定性來考量，但可能要想的更多、更廣，任何有可能影響到我們業(yè)務(wù)的穩(wěn)定性的因素，都要考慮在內(nèi)。用我的總監(jiān)的一句話來講，就是：我們運(yùn)維同學(xué)與開發(fā)同學(xué)，最大的不同點(diǎn)，就是穩(wěn)定性的意識(shí)。1、架構(gòu)上的穩(wěn)定性這個(gè)其實(shí)更多的是比如多活、負(fù)載均衡、流量調(diào)度、硬件冗余之類的考量：服務(wù)在實(shí)例掛掉的時(shí)候，如何不影響穩(wěn)定性；專線斷開的時(shí)候，如何仍然正常的提供服務(wù)等等。2、快速地發(fā)現(xiàn)問題無論我們的架構(gòu)多么完善，也很難做到盡善盡美。那么在一些需要人為介入處理的故障

6、中，快速地發(fā)現(xiàn)異常，能直接降低服務(wù)的不可用時(shí)長(zhǎng)。因此，對(duì)于一般的服務(wù)，將報(bào)警配置地更完善是我們能快速定位異常的第一步。還有，對(duì)于監(jiān)控系統(tǒng)，自身的故障不能通過自身的監(jiān)控來發(fā)現(xiàn)，最好還有一套獨(dú)立的自監(jiān)控。3、應(yīng)急預(yù)案&演練在梳理一個(gè)服務(wù)的運(yùn)維工作的時(shí)候，其實(shí)我們能很明確的感知到某個(gè)地方出問題需要人力介入。而除變更之外的一般的故障，我們都是可預(yù)見的。一旦真的出現(xiàn)這種問題，如果我們沒有準(zhǔn)備，即使知道如何去做，也可能會(huì)因?yàn)槭置δ_亂而出錯(cuò)。因此，設(shè)定一些可能發(fā)生情況的應(yīng)急預(yù)案，定時(shí)演練，是一個(gè)可以在故障時(shí)快速恢復(fù)服務(wù)的手段。4、自我保護(hù)一般的系統(tǒng)，都有上游，如何保證上游的數(shù)據(jù)異常對(duì)自身產(chǎn)生影響，也是很重要

7、的一點(diǎn)?？偨Y(jié)起來，總共有三類：過載保護(hù)：上游流量太大，導(dǎo)致自身服務(wù)不堪負(fù)重。這種情況要根據(jù)場(chǎng)景不同，考慮加入消息隊(duì)列，或者限流。臟數(shù)據(jù)保護(hù)：上游來的數(shù)據(jù)，是否應(yīng)該完全信任？是否有臟數(shù)據(jù)會(huì)來影響我內(nèi)部數(shù)據(jù)的準(zhǔn)確性？比如安全掃描的流量，很大程度上就會(huì)對(duì)很多系統(tǒng)產(chǎn)生臟數(shù)據(jù)。這種最好有過濾的規(guī)則的配置，能摘除這部分流量。上游變更保護(hù)：上游的變更，需要及時(shí)知曉和跟進(jìn)。如果上游不夠規(guī)范，很可能會(huì)修改接口或者數(shù)據(jù)格式。即使上游規(guī)范，也要跟進(jìn)上游變更容易造成的影響，人為確認(rèn)沒有問題。5、容量規(guī)劃隨著系統(tǒng)負(fù)載的升高，系統(tǒng)的服務(wù)能力并不是線性下降的。當(dāng)負(fù)載到達(dá)臨界線的時(shí)候，一個(gè)逐漸變慢的系統(tǒng)最終會(huì)停止一切服務(wù)。因

8、此，要在系統(tǒng)瓶頸到來之前，預(yù)估未來一段時(shí)間內(nèi)服務(wù)的量級(jí)，在量級(jí)到來之前，做好應(yīng)對(duì)措施。筆者公司目前有一個(gè)Topic，就是全鏈路壓測(cè)。運(yùn)維團(tuán)隊(duì)與所有業(yè)務(wù)團(tuán)隊(duì)一起建設(shè)，壓測(cè)常態(tài)化，每時(shí)每刻對(duì)系統(tǒng)全鏈路各個(gè)環(huán)節(jié)的瓶頸都了如指掌。其實(shí)也是在做這件事情。6、變更管理SRE的經(jīng)驗(yàn)告訴我們，大概70%的生產(chǎn)事故都是由某種部署的變更而觸發(fā)。因此要管理好我們的變更的機(jī)制：采用分級(jí)發(fā)布機(jī)制：先pre、再小流量、再中流量、再全量。制定全面CheckList：保證變更部分所有功能都有測(cè)試可以覆蓋，能快速發(fā)現(xiàn)問題，第一時(shí)間回滾。出現(xiàn)問題，先回滾，再定位：這個(gè)不用多說，先止損，再慢慢查問題。四、除了開發(fā)與運(yùn)維，我們還要做

9、什么？運(yùn)維開發(fā)的定位，注定要比業(yè)務(wù)開發(fā)承擔(dān)更多的責(zé)任。因?yàn)檫@群人除了是自己的RD，還要自己做自己的PM、OP、QA。因此，我們要考量的，還有產(chǎn)品和需求層面的東西：1、需求管理作為開發(fā)，尤其是沒有正經(jīng)PM的開發(fā)，管理好需求可以讓我們把精力放在最重要的地方，解放我們的精力、提高產(chǎn)出。流程閉環(huán)：從用戶每次提一個(gè)需求開始，一直到這個(gè)需求跟進(jìn)結(jié)束，或者需求被討論后打回，都要有一個(gè)詳細(xì)的流程管理工具，筆者公司用的是JIRA。有了這個(gè)工具，就可以很好的看到需求的狀態(tài)，便于跟進(jìn)和統(tǒng)計(jì)，真正解放我們的筆記本。把控好優(yōu)先級(jí)：根據(jù)項(xiàng)目的定位，來劃分需求的優(yōu)先級(jí)。比如，對(duì)于一個(gè)運(yùn)維平臺(tái)項(xiàng)目，一般來講用戶比較固定，針對(duì)

10、的是一群高玩SRE，那優(yōu)先級(jí)考量是：穩(wěn)定性 性能 功能 體驗(yàn)。對(duì)于優(yōu)先級(jí)的考量，要經(jīng)常與自己的上級(jí)溝通。由于觀點(diǎn)和視野的不同，個(gè)人考慮的優(yōu)先級(jí)會(huì)與小組或者部門的優(yōu)先級(jí)有所偏離，此時(shí)與上級(jí)及時(shí)的溝通，可以將個(gè)人的目標(biāo)與團(tuán)隊(duì)的目標(biāo)對(duì)齊，爭(zhēng)取產(chǎn)出最大化。產(chǎn)品視角 & 抽象能力：我們管理好了需求，確認(rèn)好了優(yōu)先級(jí)，是不是按照我們的優(yōu)先級(jí)埋頭苦干就行了呢？答案當(dāng)然是否定的。視角、見解不同的用戶們提出一堆細(xì)碎的需求，如果我們從頭來實(shí)現(xiàn)一遍，并不能真正讓這些用戶滿意，卻只會(huì)讓系統(tǒng)越來越爛。筆者之前就經(jīng)手維護(hù)過這樣的系統(tǒng)，勤勞的工程師兢兢業(yè)業(yè)，滿足了一個(gè)又一個(gè)的需求，各種各樣的高級(jí)功能。后來，卻由于系統(tǒng)過于復(fù)雜

11、，導(dǎo)致最基本、最常用的功能都要找半天。最終不得不重構(gòu)。因此，去深度思考用戶真正需要的是什么東西，而不是被業(yè)務(wù)推著走。將用戶細(xì)碎的需求，真正抽象成平臺(tái)要建設(shè)的一個(gè)一個(gè)的功能。經(jīng)常思考一下：用戶雖然提了這個(gè)需求，但是他真正的痛點(diǎn)在哪里；多個(gè)類似需求之間會(huì)不會(huì)有什么共通點(diǎn)；是否可以抽象出一個(gè)公用的模型，用一個(gè)功能來滿足多個(gè)需求。2、量化If You Cant Measure It，You Cant Improve It。量化是優(yōu)化的前提。量化有很多方面，比如說量級(jí)、延遲、成本，都可以量化。把所有的點(diǎn)量化完之后，我們做事情就不會(huì)蒙著頭亂撞，所做的事情、所維護(hù)的服務(wù)，也不再是一個(gè)黑盒。我們可以對(duì)它的上下

12、游關(guān)系、自身的穩(wěn)定性作出宏觀、統(tǒng)籌的分析。進(jìn)一步的壓測(cè)及SLA均要依賴量化。3、制定SLA簡(jiǎn)言之，SLA就是在一定的限制條件下我們服務(wù)可以保證的質(zhì)量；是服務(wù)的維護(hù)者完全的了解了自己的系統(tǒng)，對(duì)系統(tǒng)的瓶頸有了深刻的理解之后，所給出的服務(wù)質(zhì)量的保證；同時(shí)也是我們服務(wù)自身能力的一種說明。一個(gè)系統(tǒng)性能再好，也總會(huì)有瓶頸。而把瓶頸和風(fēng)險(xiǎn)讓用戶知曉，是我們的義務(wù)。對(duì)服務(wù)的維護(hù)者來說，在提供服務(wù)之時(shí)，約定好服務(wù)的SLA，既能從一定程度上規(guī)范使用者的行為，也能在出現(xiàn)問題的時(shí)候保護(hù)自己。五、除了做這些，我們還要思考什么？1、制定規(guī)范，并讓規(guī)范在平臺(tái)落地規(guī)范的制定是一個(gè)比較宏觀的事情，一般情況是由穩(wěn)定性負(fù)責(zé)部門向全

13、公司整體給出的建議。約束的可能是全公司的變更的規(guī)則、以及平臺(tái)的使用方式等。規(guī)范的落地，不能僅僅依靠各方業(yè)務(wù)的自覺性，也要在平臺(tái)做好限制與引導(dǎo)。我們做平臺(tái)，最終產(chǎn)出的仍然應(yīng)該是業(yè)務(wù)的價(jià)值：比如效率的提高、成本的降低、穩(wěn)定性的提高等。規(guī)則在平臺(tái)的落地，可以產(chǎn)生直接的業(yè)務(wù)價(jià)值。具體的實(shí)施方式可以考慮限制和引導(dǎo)兩種手段：限制：上線窗口的規(guī)范，非上線窗口必須走緊急流程由部門一級(jí)管理者審批；監(jiān)控單臺(tái)機(jī)器上報(bào)指標(biāo)數(shù)的quota，都是使用的限制的手段。引導(dǎo)：通過一些方式，讓用戶自覺的依照我們的規(guī)則來執(zhí)行?？梢允褂锚?jiǎng)勵(lì)、通報(bào)的一些方式。比如筆者公司的變更信用分、監(jiān)控健康分都是此類手段。2、協(xié)調(diào)開發(fā)與答疑運(yùn)維開發(fā)

14、的同學(xué)們，除了要做自己的PM和QA之外，有趣的是，還要擔(dān)任自己的客服。日常工作中，經(jīng)典的答疑主要分為兩類：使用方式、對(duì)平臺(tái)的質(zhì)疑。使用方式的日常咨詢，首先可以完善用戶手冊(cè)，把所有的使用方式和常見Q&A都寫好。其次可以考慮機(jī)器人答疑，目前筆者負(fù)責(zé)的系統(tǒng)都接入了機(jī)器人自動(dòng)答疑，把一些常見的問題以及文檔都加入到知識(shí)庫(kù)里，基本問題都可以解答出來。除了日常使用的答疑之外，也會(huì)有很多的“高玩”來Challenge我們的系統(tǒng)。這些人基本分為兩類：一類是對(duì)運(yùn)維平臺(tái)有深度思考的人，Chanllenge的同時(shí)會(huì)帶來很多建設(shè)性的意見和建議；另一類就是單純的小白用戶，對(duì)系統(tǒng)思考不太深入，喜歡無腦Chanllenge。我們也要同時(shí)思考如何與這類用戶說明，提高小白用戶的體驗(yàn)。因此