《中小企業(yè) DevOps 從 0 到 1》要點(diǎn):
本文介紹了中小企業(yè) DevOps 從 0 到 1,希望對您有用。如果有疑問,可以聯(lián)系我們。
作者簡介:
中國?SaltStack?用戶組發(fā)起人
江湖人稱:趙班長,曾在武警某部負(fù)責(zé)指揮自動(dòng)化的架構(gòu)和運(yùn)維工作,2008年退役后一直從事互聯(lián)網(wǎng)運(yùn)維工作,歷任運(yùn)維工程師、運(yùn)維經(jīng)理、運(yùn)維架構(gòu)師、運(yùn)維總監(jiān).《SaltStack技術(shù)入門與實(shí)站》作者,《運(yùn)維知識(shí)體系》作者,GOPS金牌講師.
之所以叫趙班長,是因?yàn)樵瓉碓谖渚筷?duì)做運(yùn)維,身邊的朋友都這么稱呼,外號就這樣來了.
今天主要有四個(gè)課題:
DevOps 我相信大家都已經(jīng)不陌生了,這類的分享很多,DevOps 的1.0版本我認(rèn)為是怎么做持續(xù)交付,上圖右側(cè)的是一個(gè)持續(xù)交付環(huán).
DevOps2.0 就是構(gòu)建IT服務(wù)供應(yīng)鏈,有人問我學(xué) DevOps 應(yīng)該學(xué)什么?按照這些來學(xué),敏捷、精益、持續(xù)交付和IT服務(wù)管理,想做好運(yùn)維工作必須精通持續(xù)交付和IT服務(wù)管理,現(xiàn)在想成為一個(gè) DevOps 工程師,敏捷和精益也是必需要去學(xué)的.
DevOps?的?CALMS 文化,我個(gè)人總結(jié)了一個(gè)運(yùn)維的文化,稱之為”運(yùn)維的批評與自我批評”,下面這張圖是我們武警部隊(duì)的例會(huì),一般在每周二開的“民主生活會(huì)”,以班為單位,目的就是做批評與自我批評.
主要內(nèi)容是每個(gè)人都發(fā)言,指出我們班在哪些方面做的不夠好以及自身存在的問題.我認(rèn)為批評與自我批評是一種非常棒的模式,值得推廣.我個(gè)人做運(yùn)維經(jīng)理、總監(jiān)的時(shí)候,我從來不會(huì)給團(tuán)隊(duì)成員說你想漲工資的話要努力工作,好好學(xué)習(xí)這些鼓勵(lì)的話,我主要的激勵(lì)方式是靠打擊.
我之前有一個(gè)理論是“鼓勵(lì)”員工跳槽.你埋怨工資低,為什么不跳槽?.很多時(shí)候工資低不是企業(yè)的問題,是個(gè)人能力問題.
完整的文章,請?jiān)L問下面鏈接:
《我為什么“鼓勵(lì)”員工離職?》
我相信大家對這個(gè)話題都有自己的理解,我先說一下我的理解,在說之前我先發(fā)一個(gè)警告,我這個(gè)話題比較偏激,因?yàn)槲乙眠@種相對“偏激”的話術(shù)來影響身邊的朋友,不一定是對的,但是可以引起大家的一些思考.
這就是我的運(yùn)維“能力不行”論,其實(shí)總結(jié)起來就是要先從自身找原因,能讓你快速的強(qiáng)大起來,所有的原因可能都是自身能力不足導(dǎo)致的.
舉個(gè)例子,之前我在推動(dòng)自動(dòng)化部署落地時(shí)遇到很大的阻力,因?yàn)樯婕暗介_發(fā)、測試、運(yùn)維,很難推動(dòng).當(dāng)時(shí)第一感覺是,隊(duì)友是傻X.后來慢慢醒悟(因?yàn)槲叶ㄆ跁?huì)做自我批評).反思這個(gè)事情為什么會(huì)推行不下去,原因很簡單,我的溝通能力不行!
大家認(rèn)為成為一個(gè)更高級的工程師,拿更多的薪資是因?yàn)槟愕募夹g(shù)嗎?大部分都不是,你拿多少錢不在于你技術(shù)的高低,而在于你能給公司帶來多大的價(jià)值.有人覺得自己技術(shù)很牛,為什么工資沒有那么高.你技術(shù)確實(shí)很厲害,但是沒有給公司創(chuàng)造價(jià)值,這是切實(shí)的問題.這可能是你除技術(shù)外其它能力不行!
自動(dòng)部署這個(gè)事情,我后來天天請做開發(fā)的哥們兒吃飯,大家覺得很奇怪,怎么用這樣的手段?我天天找他,把關(guān)系處的很好,之后跟他說“兄弟,我現(xiàn)在要推自動(dòng)化部署,怎么辦?”找他協(xié)助,這也是一種能力,誰說人際交往能力不是我們工作必備的能力呢?當(dāng)然其實(shí)后來我找了他四次之后這個(gè)事情才落地.
可能有人認(rèn)為在第一次協(xié)商失敗之后,就認(rèn)為這個(gè)哥們兒不配合,不支持自己的工作.其實(shí)不是的,因?yàn)槊總€(gè)人都有自己的事情,你覺得重要的事情,別人未必覺得,千萬不要先入為主!這是我的經(jīng)驗(yàn).
很多時(shí)候我們總是認(rèn)為別人有問題,其實(shí)真正是自己能力的問題.不管是什么原因,要記住,溝通也是運(yùn)維必備技能之一,并不是掌握各種技術(shù),很多時(shí)候軟技能反而起很重要的作用.
我希望大家不要把運(yùn)維能力局限于技術(shù)能力,盡量的把往外延伸.技術(shù)是成長的必備條件,但不是唯一條件.
大家過年回家有沒有跟家人介紹自己的工作,什么是運(yùn)維?,前些年,我在家里就遇到過這個(gè)問題,我認(rèn)真的回答后,有一個(gè)做Java開發(fā)的弟弟,想了半天,說他知道,就是網(wǎng)管.
這說明大多數(shù)人都小看運(yùn)維了,所以我根據(jù)自己的一些經(jīng)歷,編寫了運(yùn)維知識(shí)體系,就是要告訴他人,不要小看運(yùn)維,運(yùn)維掌握的知識(shí)并不比其它職位少,甚至要多很多.
整體是按照一個(gè)HTTP請求從客戶端發(fā)出到服務(wù)端所經(jīng)歷的層和涉及到的技術(shù),并沒有嚴(yán)格意義上的上下關(guān)系.
存儲(chǔ)層并沒有按照文件存儲(chǔ)、塊存儲(chǔ)、對象存儲(chǔ)這樣的方式來進(jìn)行劃分,而是統(tǒng)稱為文件存儲(chǔ)和數(shù)據(jù)存儲(chǔ).
基礎(chǔ)服務(wù)和容器層,操作系統(tǒng)層列舉了運(yùn)維必備的基礎(chǔ)知識(shí).
基礎(chǔ)服務(wù)層,我們在做運(yùn)維的時(shí)候有很多運(yùn)維工具,自動(dòng)化部署系統(tǒng)、監(jiān)控系統(tǒng)都是我們做運(yùn)維要做的,包括系統(tǒng)相關(guān)的如堡壘機(jī)這些.
最后面我放了自己對運(yùn)維產(chǎn)品化和服務(wù)化的一些理解.
運(yùn)維工作內(nèi)容,這里只是做了一個(gè)典型的案例,在你們的公司可能不是這么劃分的.不同的層面做的事是不一樣.現(xiàn)在做運(yùn)維其實(shí)開始場景化了.例如在招聘的時(shí)候,舉個(gè)例子,我是做 CDN 的,我招人的時(shí)候肯定想招一個(gè)做 CDN 運(yùn)維的.
做電商運(yùn)維的,到另一家做電商的公司,發(fā)現(xiàn)薪資各方面都好談.但是到一家做游戲的就不好談,之前做電商的經(jīng)驗(yàn)?zāi)玫接螒虍?dāng)中可能就不好使,或者不能發(fā)揮最大的價(jià)值.因?yàn)椴煌臉I(yè)務(wù)對應(yīng)不同的運(yùn)維場景,需要的技術(shù)可能會(huì)有一些不同的傾向性.
運(yùn)維的技術(shù)層次,我做了一個(gè)發(fā)展的概述.
第一,搭建服務(wù),這是我們運(yùn)維最早做的時(shí)候,把服務(wù)搭建起來了,就會(huì)覺得很棒,很有成就感.
第二,如何才能成為一個(gè)高級工程師呢,就是用好服務(wù),想要用好服務(wù)那就需要深入了解一個(gè)服務(wù)的底層知識(shí),能夠進(jìn)行對應(yīng)的性能調(diào)優(yōu),才能把服務(wù)用好.
第三,讓服務(wù)戀愛,到這個(gè)級別我稱之為架構(gòu)師級別,可以讓不同的服務(wù)根據(jù)不同的方式結(jié)合起來,完成對應(yīng)的工作.
第四,讓服務(wù)生孩子,就是產(chǎn)品化,這次大會(huì)咱們外面有很多展商,很多是面向運(yùn)維的,運(yùn)維的很多地方如監(jiān)控、日志、作業(yè)平臺(tái)、CMDB等等都可以做成一個(gè)產(chǎn)品來創(chuàng)業(yè).
之前有人問我運(yùn)維的職業(yè)發(fā)展,未來怎么樣發(fā)展,覺得很迷茫.
這里我做了一個(gè)選擇題,架構(gòu)師、運(yùn)維總監(jiān)、某個(gè)領(lǐng)域的技術(shù)專家,云解決架構(gòu)師、業(yè)務(wù)運(yùn)維專家,培訓(xùn)講師、DevOps 專家等等.可以看到未來的方向有很多,可橫向(解決方案)、可縱向(某一個(gè)領(lǐng)域?qū)<?等.
就像我剛才做的一個(gè)運(yùn)維知識(shí)體系是用來讓運(yùn)維人員找準(zhǔn)運(yùn)維的邊界,做好運(yùn)維要掌握的知識(shí)很多,但是需要給自己劃一個(gè)邊界,剛才所說的所有關(guān)健詞,只要掌握一個(gè)就可以夠研究一輩子了,每一個(gè)領(lǐng)域深入下去會(huì)走的很深.
中小企業(yè)基于開源 Web 的架構(gòu)演變,這個(gè)部分盡量加速略過.因?yàn)榉窒頃r(shí)間有限,我用了很多圖來更直觀的展示:單機(jī)、機(jī)群、文件、緩存、數(shù)據(jù)、異地災(zāi)備.
單機(jī)時(shí)代在Web架構(gòu)上非常簡單,單機(jī)時(shí)代我們關(guān)注的是單機(jī)的性能優(yōu)化,這是很多人忽略的問題.
組建分離,我們的圖片要使用獨(dú)立的頂級域名.比如說我之前是做電商的,需要寫很多cookie到用戶瀏覽器,如果都在一個(gè)頂級下,由于Cookie作用域的關(guān)系,別人訪問圖片的時(shí)候?yàn)g覽器也會(huì)發(fā)送cookie 到圖片服務(wù)器,這完全沒有必要,可以使用獨(dú)立的頂級應(yīng)用來避免Cookie提交.
單機(jī)時(shí)代主要關(guān)注的是 Web 性能,咱們做運(yùn)維的,尤其是想面試高級工程師,現(xiàn)在到公司面試問的全都是基礎(chǔ)問題.原因很簡單,會(huì)基礎(chǔ)了,其他的不會(huì)沒關(guān)系,只要基礎(chǔ)扎實(shí)就可以很快掌握,但是基礎(chǔ)知識(shí)不會(huì),遇到問題就很難快速定位和解決.
session 的處理方案總結(jié)起來有三種:一是會(huì)話保持,一個(gè)IP進(jìn)來的可以固定訪問到集群中的某一臺(tái)后端機(jī)器上.還有就是 session 復(fù)制,基本上不建議使用,曾經(jīng)6個(gè)節(jié)點(diǎn)的 Tomcat 集群做 Session 復(fù)制就會(huì)出現(xiàn)各種問題.最后 session 共享是終極解決方案.
很多人會(huì)被文檔把思想固化住,要記住別人寫的東西未必是正確的,我可以說我今天講的也未必是正確的,一定要學(xué)會(huì)分析,然后沉淀成自己的東西.就像網(wǎng)上有一種文檔,就是你照著做,一定不會(huì)成功.
阿里開源的?Dubbo?是一個(gè)成功的開源?SOA?框架,幫助了很多公司,不過現(xiàn)在我司的一些服務(wù)正在從?Dubbo?框架遷移到Spring Cloud.這里不討論孰優(yōu)孰劣,真的是看具體需求了.
架構(gòu)再往下發(fā)展就涉及到分布式部署,看看騰訊的分享,它們在這方面會(huì)做的比較好.
存儲(chǔ)層面:0.tmpFS,最早玩?Squid?的時(shí)候,直接是掛載一個(gè)?tmpfs?文件存儲(chǔ),性能特別的快,因?yàn)?tmpfs?是占用系統(tǒng)的共享內(nèi)存.
1.?本地硬盤
2.DAS?存儲(chǔ)
3.SAN?存儲(chǔ)都是塊存儲(chǔ)類型.
在做Web架構(gòu)的時(shí)候,除了塊存儲(chǔ)用的最多的就是文件存儲(chǔ).在集群架構(gòu)中,文件存儲(chǔ)可以使用例如?NFS?的共享存儲(chǔ),還可以使用文件的分發(fā)和同步.還可以進(jìn)行多級的分發(fā).
我司是在標(biāo)準(zhǔn)化的原則上,統(tǒng)一用分布式的文件系統(tǒng)?Glusterfs?來做,早期圖片是用的MooseFS .還有一個(gè)系統(tǒng)是用 FASTDFS,對于做小視頻或聽書類的服務(wù),每個(gè)文件大概是5M-20M左右,用 FASTDFS 特別合適.
講完集群和存儲(chǔ),就到了Web架構(gòu)中的緩存,我編寫了一個(gè)《Web 緩存知識(shí)體系》,因?yàn)槲以趯W(xué)習(xí)緩存的時(shí)候發(fā)現(xiàn)所有人的文章都是一個(gè)點(diǎn),想把整個(gè)面都串起來的文章找不到,所以就自己把緩存的體系串聯(lián)起來.我們通常所的緩存,會(huì)包括讀緩存Cache和寫緩沖Buffer.這里只聊讀緩存 Cache.
DNS 緩存,瀏覽器的 DNS 緩存,比如說 firefox 默認(rèn)緩存60秒,操作系統(tǒng)DNS 緩存,DNS 緩存服務(wù)器,應(yīng)用程序 DNS 緩存.瀏覽器是分發(fā)在千家萬戶的緩存代理,用好會(huì)非常的方便,所以瀏覽器緩存協(xié)商的三種方式是運(yùn)維必會(huì)的,基于最后修改時(shí)間、Etag和過期時(shí)間.
代理層的緩存,反向代理反存,包括Web緩存,包括 Opcache 緩存.我之前在項(xiàng)目做過一個(gè)實(shí)驗(yàn),我們是 PHP5.5,我開了 Opcahe 之后,我們的用戶態(tài)CPU使用率從70%下降了40%左右.
做電商的對頁面靜態(tài)化比較了解,一般我們會(huì)有一個(gè)CMS系統(tǒng),從后端服務(wù)集群獲取到產(chǎn)品詳細(xì)頁、列表頁等這些需要靜態(tài)化的服務(wù),然后將獲取到的HTML本地緩存進(jìn)行對應(yīng)的修改后,直接使用Nginx發(fā)布出去.
聊完緩存在Web架構(gòu)中,比較重要的就是數(shù)據(jù)庫了
拿 MySQL?的主從復(fù)制做例,目前我們用的最多的是主主復(fù)制,單寫,因?yàn)殡p寫有很多雙寫的問題,所以用單寫的方式來做.
目前使用最多的方案就是 MHA 了,之前使用 MySQL MMM 問題很多.
MySQL Proxy 的方案之前試用過 MySQL Proxy 和 Atlas,這個(gè)要看具體的需求,我不直接推薦.
MySQL PXC是我推薦的一個(gè)方案,當(dāng)然和 Atlas 解決的問題不同.
如果從 DAL 層的觀點(diǎn)出發(fā),MyCAT 目前應(yīng)用案例相對比較多一些
但是真的要把 MyCAT 玩明白需要一個(gè)團(tuán)隊(duì),中小企業(yè)成本有限,很多使用客戶端分片不僅保險(xiǎn),而且成本低.當(dāng)然運(yùn)維成本就高了.
最后推薦一下 Tidb,底層是分布式 KV系統(tǒng),在 Tidb 這層實(shí)現(xiàn)了 MySQL 協(xié)議,訪問它幾乎就像訪問 MySQL 一樣.
最后聊聊異地災(zāi)備:
創(chuàng)業(yè)公司倒閉機(jī)房著火哪個(gè)機(jī)率大?很多人會(huì)回答是創(chuàng)業(yè)公司,但是!說一個(gè)真實(shí)的案例,天津塘沽事故的時(shí)候,我們的服務(wù)器在托管在天津塘沽機(jī)房,當(dāng)時(shí)我們啟動(dòng)了臨時(shí)緊急災(zāi)備,把數(shù)據(jù)全部往其它機(jī)房都做了備份.
對于很多互聯(lián)網(wǎng)公司來說,不管公司市值多少個(gè)億,要是機(jī)房真的沒了,整個(gè)公司就沒了,一點(diǎn)都不夸張.所以我強(qiáng)烈建議,不要考慮幾率,災(zāi)備必須做,可以實(shí)現(xiàn)低等級的災(zāi)備,但是有勝于無.
根據(jù)災(zāi)備國家標(biāo)準(zhǔn)六個(gè)等級七個(gè)要素,我們做了一個(gè)分層、分階段的建設(shè),先有后完善.
我們當(dāng)時(shí)的原則是先有,后完善,非對稱配置.徘徊在”冷備”和”雙活”之間,例如在 Nginx 上根據(jù) IP 地址做分流,分一些量到災(zāi)備機(jī)房,保證備用機(jī)房的服務(wù)是真正可用的,然后定期做這樣的測試.基本上是用了最低的成本做好了運(yùn)維最后的防線.所以不要說自己是中小企業(yè)沒錢,沒錢有沒錢的做法,但是不能不做.
自動(dòng)化運(yùn)維發(fā)展歷程,做自動(dòng)化運(yùn)維可能需要需要經(jīng)歷標(biāo)準(zhǔn)化、工具化、Web化、平臺(tái)化、服務(wù)化、智能化.所有不以解決運(yùn)維痛點(diǎn)的自動(dòng)化運(yùn)維都是耍流氓,現(xiàn)在很多公司都在做自動(dòng)化運(yùn)維平臺(tái).我這里有一個(gè)痛點(diǎn)案例:
我們有一個(gè)oracle數(shù)據(jù)庫要升級打補(bǔ)丁,涉及到停庫,先停備庫打補(bǔ)丁,未來再停主庫打補(bǔ)丁.需求是查找所有業(yè)務(wù)系統(tǒng)中03:00-06:00的所有定時(shí)任務(wù)(我們很多操作數(shù)據(jù)庫的定時(shí)任務(wù)是crontab管理的),確定哪些定時(shí)任務(wù)連接需要停機(jī)數(shù)據(jù)庫.如果你有上千臺(tái)服務(wù)器,自殺的心都有了.
雖然最后是解決了,但是告訴我們只有標(biāo)準(zhǔn)化、工具化是解決不了問題的,所以要往Web化發(fā)展,后來我們做了一個(gè)作業(yè)平臺(tái),把定時(shí)作業(yè)全部通過作業(yè)平臺(tái)管理起來.想加一個(gè)定時(shí)任務(wù),提交工單,工單把所有任務(wù)記錄下來,然后可以做查詢.
所以要分析自身情況,找準(zhǔn)痛點(diǎn),不要盲目的做.
基于開源的全鏈路自動(dòng)化運(yùn)維體系是按照一個(gè)項(xiàng)目上線的流程來整理的.從傳統(tǒng)的角度來說:
最后所有的數(shù)據(jù)庫放在 CMDB.所以說這是一個(gè)全鏈路的自動(dòng)化體系.
從幾個(gè)層面介紹一下,一個(gè)是 OpenStack,我們兩個(gè)版本,一個(gè)I版,一個(gè)M版,做的多區(qū)域.
像上圖的架構(gòu)是可以用?SaltStack?進(jìn)行自動(dòng)化的配置管理.
基于 Jenkins 的持續(xù)交付.做自動(dòng)運(yùn)維要做一個(gè)體系,要解決全鏈路的問題,而不是做某一個(gè)層面,要把整個(gè)方面全考慮到位.
上圖是我們基于 ELK 做的日志數(shù)據(jù)分析平臺(tái),我們這個(gè)有大數(shù)據(jù)的部分,會(huì)把數(shù)據(jù)全部寫在 Kafka 里面,然后從 Kafka讀出來,一部分寫在 ES 里面,一部分寫在 Hadoop 里面.
然后基于 Hadoop 做數(shù)據(jù)分析和處理. ES 主要是用于搜索和運(yùn)維.這里想強(qiáng)調(diào)一點(diǎn),如果你的業(yè)務(wù)也用ES的話,你要把運(yùn)維的 ES 和業(yè)務(wù)的 ES 分開.
我做了一套基于全開源的智能化擴(kuò)容的實(shí)現(xiàn).例如 Zabbix 觸發(fā)擴(kuò)容,調(diào)用 Salt-Cloud 創(chuàng)建 OpenStack 虛擬機(jī),將信息寫入到 etcd,然后調(diào)用 SaltStack 進(jìn)行環(huán)境部署,調(diào)用 Jenkins 進(jìn)行代碼部署,調(diào)用自動(dòng)化測試進(jìn)行測試.
最后 SaltStack 管理 Haproxy 的配置文件,進(jìn)行自動(dòng)重載,完成擴(kuò)容工作.當(dāng)然這只是一個(gè)簡圖,有 CMDB 的話,可以直接替換掉 etcd.
下一步怎么走?剛才講的做運(yùn)維是標(biāo)準(zhǔn)化、工具化、平臺(tái)化、服務(wù)化、智能化,下一步是產(chǎn)品化,對于一些運(yùn)維老司機(jī),在運(yùn)維行業(yè)深耕多年,找準(zhǔn)機(jī)會(huì)就可以創(chuàng)業(yè)去了.
下一步怎么走?剛才講的做運(yùn)維是標(biāo)準(zhǔn)化、工具化、平臺(tái)化、服務(wù)化、智能化,下一步是產(chǎn)品化,對于一些運(yùn)維老司機(jī),在運(yùn)維行業(yè)深耕多年,找準(zhǔn)機(jī)會(huì)就可以創(chuàng)業(yè)去了.
文章來自微信公眾號:高效運(yùn)維
轉(zhuǎn)載請注明本頁網(wǎng)址:
http://www.fzlkiss.com/jiaocheng/3747.html