Devops的“定義”
近些年來杠纵，DevOps在我們身邊出現(xiàn)的頻率越來越高了究反，各種大會上經(jīng)常出現(xiàn)DevOps專場慈参，企業(yè)的DevOps轉(zhuǎn)型看起來迫在眉睫推沸，公司內(nèi)部也要設(shè)計和開發(fā)DevOps平臺，這么看來议泵，DevOps無處不在占贫。
那DevOps到底是什么呢， 好像從來沒有人能說清楚先口。
我們先來看看維基百科對DevOps的定義：
DevOps（Development和Operations的組合詞）是一種重視“軟件開發(fā)人員（Dev）”和“IT運維技術(shù)人員（Ops）”之間溝通合作的文化型奥、運動或慣例。透過自動化“軟件交付”和“架構(gòu)變更”的流程碉京，來使得構(gòu)建厢汹、測試、發(fā)布軟件能夠更加地快捷谐宙、頻繁和可靠
其實看了維基百科的定義后烫葬，估計也沒誰能看懂到底是在說什么。
其實凡蜻，DevOps的秘密就來源于他的名字所代表的兩種角色---開發(fā)和運維
這兩種角色之間究竟有什么問題呢搭综？我們從軟件工程誕生以來所經(jīng)歷的三個重要發(fā)展階段說起
瀑布式開發(fā)模式
瀑布式開發(fā)模式將軟件交付過程劃分成幾個階段，從需求到開發(fā)划栓、測試和運維兑巾，它的理念是軟件開發(fā)的規(guī)模越來越大，必須以一種工程管理的方式來定義每個階段忠荞，以及相應(yīng)的交付產(chǎn)物和交付標(biāo)準(zhǔn)蒋歌，以期通過一種重流程，重管控委煤，按照計劃一步步推進(jìn)整個項目的交付過程堂油。
可是咆霜，隨著市場環(huán)境和用戶需求變化的不斷加速，這種按部就班的方式有一個嚴(yán)重的潛在問題伟端。
軟件開發(fā)活動需要在項目一開始就確定項目目標(biāo)夸政、范圍以及實現(xiàn)方式，而這個時間點往往是我們對用戶和市場環(huán)境信息了解最少的時候蛔糯，這樣做出來的決策往往帶有很大的不確定性，很容易導(dǎo)致項目范圍不斷變更，計劃不斷延期计维，交付上線時間不斷推后，最后的結(jié)果是撕予，即便我們投入了大量資源鲫惶，卻難以達(dá)到預(yù)期的效果。
敏捷式開發(fā)模式
敏捷的核心理念是既然我們無法充分了解用戶的真實需求是怎樣的实抡，那么不如將一個大的目標(biāo)不斷拆解欠母，把它變成一個個可交付的小目標(biāo)欢策，然后通過不斷迭代，以小步快跑的方式持續(xù)開發(fā)赏淌。
與此同時踩寇，將測試工作從研發(fā)末端的一個獨立環(huán)節(jié)注入整個開發(fā)活動中，對開發(fā)交付的內(nèi)容進(jìn)行持續(xù)驗證六水，保證每次可交付的都是一個可用的功能集合俺孙，并且由于質(zhì)量內(nèi)建在研發(fā)環(huán)節(jié)中，交付功能的質(zhì)量也是有保障的掷贾。
敏捷是一種更加靈活的研發(fā)模式睛榄，但是并不會直接提升團(tuán)隊的開發(fā)速度，敏捷之所以更快想帅，根本原因在于持續(xù)迭代和驗證節(jié)省了大量不必要的浪費和返工场靴。
DevOps模式
于是，活在墻的另一端的運維團(tuán)隊成了被拉攏的對象博脑。這些在軟件交付最末端的團(tuán)隊始終處于一種“背鍋”的狀態(tài)憎乙，他們也有改變的意愿，所以 DevOps 應(yīng)運而生叉趣，也就是說泞边，DevOps 最開始想要打破的就是開發(fā)和運維之間的對立和隔閡。
該模式強(qiáng)調(diào)一個運維和開發(fā)不斷溝通的能力環(huán)疗杉，在開發(fā)階段我們沿襲敏捷的開發(fā)模式阵谚，在運維階段，我們強(qiáng)調(diào)自動化的運維烟具，并不斷講已經(jīng)上線的產(chǎn)品中的問題反饋給開發(fā)梢什，以進(jìn)行問題修復(fù)。
Develop和Operation的歷史問題
開發(fā)和運維人員素來就被一種叫做部門墻的隱形之墻所隔離朝聋，這種問題由來已久嗡午，
原因1：開發(fā)和運維的目標(biāo)不一致，開發(fā)的目的是不斷的增加新功能冀痕，不斷完善需求荔睹，不斷發(fā)布新版本，總之對于開發(fā)來說言蛇，唯一不變的就是變化僻他，但是，對于運維來說腊尚，首要的問題是要求穩(wěn)吨拗，因為一切問題的來源都是變化。
原因2：兩個角色所在的部門考核標(biāo)準(zhǔn)不一樣，對于開發(fā)來說劝篷，新開發(fā)一個需求考核就遞增一點哨鸭，是個累加的過程；而對于運維來說携龟，即使將發(fā)布工作做的極致兔跌，起點也只是0，因為峡蟋，這本來就是運維應(yīng)該做的坟桅，一旦出了問題，便會從0開始遞減蕊蝗，是個遞減的過程仅乓。
DevOps定義
DevOps 是通過平臺（Platform）、流程（Process）和人（People）的有機(jī)整合蓬戚，以 C（協(xié)作）A（自動化）L（精益）M（度量）S（共享）文化為指引夸楣，旨在建立一種可以快速交付價值并且具有持續(xù)改進(jìn)能力的現(xiàn)代化 IT 組織子漩。
Devops的生命周期
1.Plan
需求階段豫喧，無論該需求來自客戶的新需求還是BUG修改，這是觸發(fā)整個Devops流程的起點幢泼，因此紧显，作為Devops團(tuán)隊，開發(fā)團(tuán)隊需要把運維團(tuán)隊作為首要干系人缕棵，在進(jìn)行開發(fā)之前獲取他們的意見孵班，比如運維人員可能會對日志文件的類型和結(jié)構(gòu)提出建議。
2. build
開發(fā)/構(gòu)建階段招驴，該階段需要開發(fā)人員開發(fā)和運維團(tuán)隊也要保持密切的溝通篙程，對于開發(fā)進(jìn)度，單元測試的執(zhí)行等别厘，構(gòu)建工具的使用虱饿，持續(xù)集成等運維人員也需要有所了解
3. Test
測試階段，測試方案的規(guī)劃触趴，使用什么測試工具氮发，是否使用自動化測試等（有一種新的Taas服務(wù)，將測試作為一種基礎(chǔ)服務(wù)提出）雕蔽，都需要跟開發(fā)和運維溝通折柠。
4. Release
該階段主要是對新版本的上線做的一系列準(zhǔn)備宾娜，例如release之前需要對該版本支持的平臺版本進(jìn)行確認(rèn)批狐，測試結(jié)果進(jìn)行確認(rèn)，安全檢查等報告進(jìn)行核實，確保上線之前最后一套手續(xù)的完整性
5. Deploy
部署階段嚣艇，部署工具的使用承冰，部署方案的制定（A/B部署，金絲雀部署等）食零，以及回滾方案的確認(rèn)困乒，確保在服務(wù)不受影響的情況下贰谣，順利將新版本發(fā)布。
6. Operation / Monitor
運維階段百宇，對于已經(jīng)上線的服務(wù)做一系列的性能監(jiān)控（CPU , Memory等），日志分析秘豹，執(zhí)行系統(tǒng)及軟件的例行審計携御，執(zhí)行備份既绕，對操作系統(tǒng)的更新補丁升級，優(yōu)化系統(tǒng)性能等凄贩，并及時發(fā)現(xiàn)監(jiān)控過程中的問題誓军，以及搜集來自于客戶的問題清單，并將此作為下次版本更新的需求谭企。
總 結(jié)： Devops生命周期是一個環(huán)形結(jié)構(gòu)评肆，它不會以項目上線為終止，而是不斷會搜集來自于客戶的需求盹廷，以對整個軟件服務(wù)做不斷的更新以及優(yōu)化久橙，這種結(jié)構(gòu)就要求Devops整個流程的高效性。
二 Devops實現(xiàn)
一般軟件開發(fā)過程可以分成：持續(xù)開發(fā)淆衷、持續(xù)測試、持續(xù)集成甚带、持續(xù)交付、持續(xù)部署和持續(xù)監(jiān)控等部分
2.1持續(xù)開發(fā)
持續(xù)開發(fā)是DevOps 軟件不斷開發(fā)的階段晴氨。
與瀑布模型不同的是碉输，敏捷開發(fā)中軟件可交付成果被分解為短開發(fā)周期的多個任務(wù)節(jié)點，在很短的時間內(nèi)開發(fā)并交付枝哄。
這個階段包括編碼和構(gòu)建階段阻荒，并使用Git和SVN等工具來維護(hù)不同版本的代碼，打包代碼到可執(zhí)行文件中瘪贱，這些文件可以轉(zhuǎn)發(fā)給自動化測試系統(tǒng)進(jìn)行測試辆毡。
2.2持續(xù)測試
在這個階段，開發(fā)的軟件將被持續(xù)地測試bug球昨。
對于持續(xù)測試眨攘，使用自動化測試工具，如Selenium（wen自動化測試工具）等共螺。這些工具允許質(zhì)量管理系統(tǒng)完全并行地測試多個代碼庫情竹，以確保功能中沒有缺陷。
在這個階段雏蛮，使用Docker容器實時模擬“測試環(huán)境”也是首選阱州。一旦代碼測試通過，它就會不斷地與現(xiàn)有代碼集成犀概。
2.3持續(xù)集成
持續(xù)集成強(qiáng)調(diào)開發(fā)人員提交了新代碼之后，立刻進(jìn)行構(gòu)建阱冶、（單元）測試木蹬。根據(jù)測試結(jié)果若皱，我們可以確定新代碼和原有代碼能否正確地集成在一起
2.4持續(xù)交付
在持續(xù)集成的基礎(chǔ)上，將集成后的代碼部署到預(yù)生產(chǎn)環(huán)境中（production-like environments）晦譬，完成單元測試后互广，把代碼部署到連接數(shù)據(jù)庫的Stanginx環(huán)境中更多的測試，以及時發(fā)現(xiàn)可能產(chǎn)生的問題像樊。如果代碼沒有問題，可以繼續(xù)手動部署到生產(chǎn)環(huán)境中涂滴。
2.5持續(xù)部署
它是將代碼部署到生產(chǎn)環(huán)境的階段柔纵。
在這里首量，我們確保在所有服務(wù)器上正確部署代碼进苍。 如果添加了任何功能或引入了新功能，那么應(yīng)該準(zhǔn)備好迎接更多的網(wǎng)站流量拣宏。 因此杠人，系統(tǒng)運維人員還有責(zé)任擴(kuò)展服務(wù)器以容納更多用戶宋下。
由于新代碼是連續(xù)部署的学歧，因此配置管理工具可以快速各吨，頻繁地執(zhí)行任務(wù)。 Puppet横浑，Chef屉更，SaltStack和Ansible是這個階段使用的一些流行工具瑰谜。容器化工具在部署階段也發(fā)揮著重要作用。 Docker和Vagrant是流行的工具萨脑，有助于在開發(fā)砚哗，測試，登臺和生產(chǎn)環(huán)境中實現(xiàn)一致性提鸟。 除此之外仅淑，它們還有助于輕松擴(kuò)展和縮小實例。
2.5.1部署策略
-
1.藍(lán)/綠部署
藍(lán)綠部署就是為應(yīng)用準(zhǔn)備兩套一模一樣的環(huán)境赡鲜，一套是藍(lán)環(huán)境庐船，一套是綠環(huán)境筐钟，每次只有一套環(huán)境提供線上服務(wù)。這里的藍(lán)和綠篓冲，只是用于區(qū)分兩套環(huán)境的標(biāo)志而已。在新版本上線時嗤攻，先將新版本的應(yīng)用部署到?jīng)]有提供線上服務(wù)的環(huán)境中妇菱，進(jìn)行上線前驗證，驗證通過后就達(dá)到了準(zhǔn)備就緒的狀態(tài)恶耽。在發(fā)布時間點偷俭，只要將原本指向線上環(huán)境的路由切換成另外一套環(huán)境缰盏，整個發(fā)布過程就完成了。一般來說负溪，這種方式的實現(xiàn)成本比較高济炎。因為有兩套一模一樣的環(huán)境，只有一套用于真正地提供線上服務(wù)须尚。為了減少資源浪費，在實際操作中密幔，另外一套環(huán)境可以當(dāng)作預(yù)發(fā)布環(huán)境使用撩轰，用來在上線之前驗證新功能。另外偎箫，在這種模式下皆串，數(shù)據(jù)庫普遍還是采用同一套實例愚战，通過向下兼容的方式支持多個版本的應(yīng)用齐遵。
特點是：全量部署塔插，實現(xiàn)成本比較高
-
2.灰度發(fā)布
灰度發(fā)布想许，也叫金絲雀發(fā)布。與藍(lán)綠部署相比糜烹，灰度發(fā)布更加靈活漱凝，成本也更低，所以愕乎，在企業(yè)中是一種更為普遍的低風(fēng)險發(fā)布方式壁公。
在生產(chǎn)環(huán)境的少量虛擬機(jī)上部署新的服務(wù)，并對特定用戶開放比肄。這些特定用戶可能是隨機(jī)采樣的用戶囊陡，也有可能是開發(fā)的成員等等关斜。我們應(yīng)該嚴(yán)格監(jiān)控金絲雀，一旦發(fā)現(xiàn)錯誤垛膝，則應(yīng)立即回滾丁稀。如果一段時間內(nèi)運行正常，那么可以將其他機(jī)器一并升級為最新版本凿可。
1.為大部分用戶的請求流向
2.為金絲雀數(shù)據(jù)流向
特點是：金絲雀數(shù)目少于提供給Customer的服務(wù)器枯跑。
-
3.暗部署
在生產(chǎn)環(huán)境中部署服務(wù)的兩個不同版本，可能是新舊版本共存粗卜，或者兩個新版本共存纳击，要么呈現(xiàn)了不同的用戶界面，要么呈現(xiàn)了不同的行為纱昧，測試用戶的偏好堡赔。如果某個版本在業(yè)務(wù)量上（比如訪問量等）呈現(xiàn)出更好的行為，那么整個版本就成為發(fā)布版本存璃，另一個版本則作廢雕拼。
特點是：訪問流量數(shù)目相同
總結(jié)：以上這三種低風(fēng)險發(fā)布手段啥寇，如果應(yīng)用規(guī)模整體不大洒扎，藍(lán)綠部署是提升系統(tǒng)可用性的最好手段袍冷，比如各類 Hot-standby 的解決方案，其實就是藍(lán)綠部署的典型應(yīng)用邓线。而對于大規(guī)模系統(tǒng)來說煌恢，考慮到成本和收益，灰度發(fā)布顯然就成了性價比最高的做法你雌。如果想要跑一些線上的測試收集真實用戶反饋二汛，那么拨拓，暗部署是一種不錯的選擇千元。
2.6持續(xù)監(jiān)控
這是DevOps生命周期中非常關(guān)鍵的階段颤绕，旨在通過監(jiān)控軟件的性能來提高軟件的質(zhì)量。這種做法涉及運營團(tuán)隊的參與物独，他們將監(jiān)視用戶活動中的錯誤/系統(tǒng)的任何不正當(dāng)行為氯葬。
監(jiān)控就是一種全量的測試帚称。
常見的線上驗證手段
-1.采用灰度發(fā)布、用戶眾測等方式戏羽，逐步觀察用戶行為并收集用戶數(shù)據(jù)楼吃，以驗證新版本的可用性是否符合預(yù)期。
這里的主要實踐之一就是埋點功能酷宵。在互聯(lián)網(wǎng)產(chǎn)品中躬窜，埋點是一種最常用的產(chǎn)品分析和數(shù)據(jù)采集方法荣挨，也是數(shù)據(jù)驅(qū)動決策的主要依據(jù)之一。它的價值就在于煌抒，根據(jù)預(yù)先設(shè)計的收集和監(jiān)控數(shù)據(jù)的方法厕倍，采集用戶的行為、產(chǎn)品質(zhì)量况既、運營數(shù)據(jù)等多維度的數(shù)據(jù)。大型公司一般都實現(xiàn)了自己的埋點 SDK悲靴，根據(jù)產(chǎn)品設(shè)計需求莫其，可以自動化地采集數(shù)據(jù)乱陡，并配置采集粒度；對于小公司來說胳徽，像友盟這種第三方統(tǒng)計工具爽彤，就可以滿足絕大多數(shù)情況的需求了。
-2. 用戶反饋往核。
除了自動化的采集數(shù)據(jù)之外匙瘪，用戶主動的反饋也是獲取產(chǎn)品信息的第一手資料丹喻。而用戶反饋的渠道有很多翁都，公司里面一般都有用戶運營和輿情監(jiān)控系統(tǒng)，用于按照“關(guān)鍵字”等自動爬取各個主流渠道的產(chǎn)品信息鳍悠。一旦發(fā)現(xiàn)負(fù)面的反饋藏研，就第一時間進(jìn)行止損概行。
3.使用線上流量測試。
- 將線上真實的用戶流量復(fù)制下來业踏，以實時或者離線的方式回放到預(yù)發(fā)布環(huán)境中用于功能測試。
- 使用只讀的查詢內(nèi)容來驗證搜索接口
- 按照倍數(shù)放大和縮小流量腹尖，以達(dá)到服務(wù)壓測目的
- 可以自動比對線上服務(wù)和預(yù)發(fā)布服務(wù)的返回結(jié)果以驗證相同的流量過來時伐脖，兩個版本之間系統(tǒng)的行為是否一致
監(jiān)控工具
這也可以通過使用專用監(jiān)控工具來實現(xiàn)讼庇，該工具將持續(xù)監(jiān)控應(yīng)用程序性能并突出問題。
使用的一些流行工具是Splunk认烁，ELK Stack介汹，Nagios嘹承，NewRelic和Sensu。這些工具可幫助密切監(jiān)視應(yīng)用程序和服務(wù)器撼港，以主動檢查系統(tǒng)的運行狀況骤竹。它們還可以提高生產(chǎn)率并提高系統(tǒng)的可靠性蒙揣，從而降低IT支持成本。
發(fā)現(xiàn)的任何重大問題都可以向開發(fā)團(tuán)隊報告懒震，以便可以在持續(xù)開發(fā)階段進(jìn)行修復(fù)个扰。這些DevOps階段連續(xù)循環(huán)進(jìn)行，直到達(dá)到所需的產(chǎn)品質(zhì)量娘香。
DevOps生命周期工具
Devops的價值
企業(yè)在應(yīng)用了DevOps之后可以得到3個業(yè)務(wù)優(yōu)勢：
產(chǎn)品快速推向市場：縮短開發(fā)周期時間和更高的部署頻率
提高質(zhì)量：提高可用性茅主，提高變更成功率，減少故障响牛，等等
提高組織的有效性：將時間花在價值增加活動中赫段，減少浪費糯笙，同時交付更多的價值至客戶手中
