摘要

DevOps最有趣的地方莫過(guò)于它是一種思想上的"反模式"味赃。一般我們認(rèn)為浦辨，一個(gè)行業(yè)發(fā)展越成熟，它的工種劃分會(huì)越細(xì)致型凳。因此在軟件業(yè)丈冬，開(kāi)發(fā)者Dev和運(yùn)維人員Ops自然而然地被分成兩個(gè)獨(dú)立的部門(mén)。而DevOps則反其道而行之甘畅，它鼓勵(lì)開(kāi)發(fā)者和運(yùn)維坐在同一間辦公室里埂蕊，并對(duì)彼此充分了解往弓。這不僅是為了在服務(wù)掛掉時(shí)方便找人，更是為了Dev和Ops從一開(kāi)始就頻繁溝通蓄氧，精誠(chéng)合作函似。
為什么會(huì)出現(xiàn)這種情況？本文的觀點(diǎn)是匀们，DevOps出現(xiàn)的驅(qū)動(dòng)力是人們的需求缴淋，即用戶(hù)對(duì)軟件有快速開(kāi)發(fā)的需求准给，企業(yè)也對(duì)軟件有快速迭代的需求泄朴。為了應(yīng)對(duì)這種需求，人們將先前的各類(lèi)實(shí)踐進(jìn)行總結(jié)露氮，各類(lèi)問(wèn)題進(jìn)行分析祖灰，提出了DevOps的思想。而在這種思想的指導(dǎo)下畔规，我們開(kāi)發(fā)時(shí)使用的工具局扶，開(kāi)發(fā)流程甚至部門(mén)組織都出現(xiàn)了改變。

1. 工種細(xì)分的好與壞

當(dāng)我們?nèi)ビ^察一個(gè)公司的發(fā)展歷程時(shí)叁扫，會(huì)認(rèn)為工種細(xì)分是天經(jīng)地義的事：創(chuàng)始人團(tuán)隊(duì)往往不超過(guò)十個(gè)人三妈，甚至可能只有一個(gè)人。那時(shí)候人人身兼多職莫绣，技術(shù)人員不僅要會(huì)寫(xiě)代碼畴蒲，也要有必要的PS技巧。CEO不僅需要深諳公司的核心業(yè)務(wù)对室，對(duì)于營(yíng)銷(xiāo)廣告詞也要有巧妙構(gòu)思模燥。隨著公司不斷壯大，研發(fā)組掩宜，運(yùn)營(yíng)組蔫骂，產(chǎn)品組，人事部等等部門(mén)開(kāi)始出現(xiàn)牺汤。以研發(fā)組為例辽旋，隨著人數(shù)的增多，自然就劃分出了開(kāi)發(fā)檐迟，運(yùn)維补胚，測(cè)試，DBA等等工種锅减。不同工種之間掌握著不同的技能鏈糖儡，工作的內(nèi)容也不盡相同。就是這樣的一種體系怔匣，使得大家的責(zé)任更清晰握联，分工更明確桦沉，公司因此大而不倒。

再把情況抽象一下金闽，工種細(xì)分其實(shí)體現(xiàn)了樸素的分而治之的思想纯露。我們把人群分成模塊，模塊之間承擔(dān)不同的職責(zé)代芜，一邊提供功能埠褪，一邊隱藏信息。因此我們可以組織出更大和更復(fù)雜的系統(tǒng)挤庇。

聽(tīng)起來(lái)很美好钞速，可惜現(xiàn)實(shí)是殘酷的。工種細(xì)分同樣帶來(lái)了一系列問(wèn)題嫡秕。

1.1 目標(biāo)沖突

這是職責(zé)劃分帶來(lái)副作用渴语。通常一個(gè)負(fù)責(zé)人的產(chǎn)品經(jīng)理會(huì)不斷研究用戶(hù)群，這會(huì)使得需求產(chǎn)生變更昆咽。而通常一個(gè)負(fù)責(zé)任的程序員會(huì)盡快完成手頭的工作驾凶。所以當(dāng)兩個(gè)負(fù)責(zé)任的人碰面時(shí)，反而產(chǎn)生更猛烈的沖突掷酗。同樣的情況適用于開(kāi)發(fā)者和運(yùn)維调违，開(kāi)發(fā)者想迫不及待地將包含自己心血的代碼交給運(yùn)維，并且在心中默默樹(shù)下一塊里程碑泻轰。但運(yùn)維卻像接到一塊燙手山芋技肩，小心翼翼地把文件推到線上，神色凝重地檢查著CPU和內(nèi)存占用率糕殉。想象一下亩鬼，如果此時(shí)服務(wù)掛掉了，那么運(yùn)維一定會(huì)快步跑上樓阿蝶，拉著剛剛還得意洋洋的開(kāi)發(fā)解決問(wèn)題雳锋。這對(duì)兩個(gè)人的積極性都是一種打擊。

究其原因羡洁，無(wú)非是開(kāi)發(fā)人員追求將需求盡快轉(zhuǎn)化為代碼玷过，而運(yùn)維人員則希望服務(wù)器能安安穩(wěn)穩(wěn)地運(yùn)行。這兩個(gè)目標(biāo)是有沖突之處的筑煮，因?yàn)檐浖徽嬲渴鸬骄€上辛蚊，誰(shuí)都不敢保證它能平穩(wěn)運(yùn)行，而“上線”這個(gè)詞正是讓運(yùn)維頭大的原因真仲。更不用說(shuō)一個(gè)服務(wù)反復(fù)上線袋马，反復(fù)崩潰時(shí)對(duì)士氣的打擊了。

1.2 責(zé)任推諉

將開(kāi)發(fā)和運(yùn)維分開(kāi)秸应，其實(shí)是將代碼的開(kāi)發(fā)調(diào)試階段和代碼的上線階段分給兩撥人去處理虑凛。隱含這一種推卸責(zé)任風(fēng)險(xiǎn)：既然已經(jīng)有人在維護(hù)服務(wù)器的運(yùn)行了碑宴，開(kāi)發(fā)人員再去關(guān)注系統(tǒng)的上線狀態(tài)是不是有些多余呢？舉一個(gè)例子：假設(shè)有一個(gè)服務(wù)出于數(shù)據(jù)一致性的考慮桑谍，無(wú)論用戶(hù)離哪個(gè)機(jī)房比較近延柠，請(qǐng)求都要發(fā)到一個(gè)特定機(jī)房統(tǒng)一處理。

開(kāi)發(fā)人員認(rèn)為：這是服務(wù)上線之后的路由規(guī)則锣披，當(dāng)然是交給運(yùn)維來(lái)負(fù)責(zé)贞间。而且就算我想負(fù)責(zé)，運(yùn)維那一套路由配置我也搞不懂啊雹仿。

運(yùn)維人員認(rèn)為：保障數(shù)據(jù)一致性是開(kāi)發(fā)的需求決定的增热，理應(yīng)由開(kāi)發(fā)來(lái)實(shí)現(xiàn)。我一旦接手維護(hù)了盅粪，不僅破壞我現(xiàn)在路由規(guī)則的一致性钓葫，而且將來(lái)需求變更了可能會(huì)影響到我悄蕾。一個(gè)業(yè)務(wù)規(guī)則的變更居然影響到了運(yùn)維票顾，這太荒謬了。

這種職責(zé)的不明確性還在軟件的其他階段體現(xiàn)出來(lái)帆调。當(dāng)產(chǎn)品和開(kāi)發(fā)確認(rèn)需求時(shí)奠骄，應(yīng)不應(yīng)該叫運(yùn)維來(lái)參加？參加的話番刊，運(yùn)維絲毫不關(guān)心討論過(guò)程中各種需求細(xì)節(jié)含鳞，而不參加的話，運(yùn)維相關(guān)的問(wèn)題可能直到臨上線之前才被發(fā)現(xiàn)芹务，從而付出巨大的代價(jià)蝉绷。開(kāi)發(fā)組織設(shè)計(jì)評(píng)審時(shí)，應(yīng)不應(yīng)該叫運(yùn)維來(lái)參加枣抱？我們發(fā)現(xiàn)上邊的問(wèn)題依舊是存在的熔吗。

1.3 溝通不暢

這是信息隱藏的副作用。因?yàn)殚_(kāi)發(fā)和運(yùn)維分別負(fù)責(zé)軟件生命周期中的不同階段佳晶，這使他們的工作內(nèi)容大相徑庭桅狠。從開(kāi)發(fā)的角度來(lái)說(shuō)，首先他需要對(duì)需求有準(zhǔn)確無(wú)誤的理解轿秧，相比于產(chǎn)品崗中跌，他需要更加細(xì)致和精確的把握軟件的功能。在此之上菇篡，程序邏輯本身將耗費(fèi)他大量的精力：上下游服務(wù)有哪些漩符，依賴(lài)關(guān)系是什么，錯(cuò)誤碼怎么定義驱还，如何分層嗜暴，如何定接口津滞。更不用說(shuō)出于權(quán)衡可用性和一致性的各種復(fù)雜折中了。

工具鏈上灼伤，開(kāi)發(fā)者的行動(dòng)往往就集中在自己的機(jī)器上或者一個(gè)沙箱環(huán)境中触徐。這里的一切都是為了開(kāi)發(fā)而準(zhǔn)備的：一個(gè)秒級(jí)啟動(dòng)的local web server，直觀自然的windows/Mac圖形界面狐赡，調(diào)用鏈路從頭到尾只有一條撞鹉，沒(méi)有復(fù)雜的負(fù)載均衡或者故障切換策略，請(qǐng)求不會(huì)飄來(lái)飄去颖侄。最令人開(kāi)心的是鸟雏，環(huán)境中的DB和Cache往往都是可以隨時(shí)重啟甚至重裝的。

讓我們來(lái)看看運(yùn)維這邊的情況览祖，幸運(yùn)的是他們往往不需要理解復(fù)雜的需求孝鹊，但不幸的是他們必須面對(duì)殘酷的計(jì)算機(jī)世界。他們要精心照料每一個(gè)服務(wù)展蒂，有的服務(wù)要跨機(jī)房部署又活，有的服務(wù)要同機(jī)房多份部署，有的還要和別的服務(wù)混部锰悼。路由配置文件中寫(xiě)錯(cuò)一個(gè)數(shù)字柳骄，一個(gè)通配符或者一個(gè)注釋號(hào)，后果都是不可預(yù)料的箕般。沒(méi)有圖形界面的環(huán)境中耐薯，一個(gè)進(jìn)程的生死往往是悄無(wú)聲息的，等他們真正發(fā)現(xiàn)時(shí)丝里，只能在好幾個(gè)G的日志中尋找蛛絲馬跡曲初。更不用說(shuō)DB和Cache的健康狀態(tài)的重要性了，任意一個(gè)掛了杯聚，一臺(tái)機(jī)器都可能被瞬間沖垮臼婆。

所以我們就不難理解開(kāi)發(fā)和運(yùn)維之間的日常對(duì)話了：
“不可能啊，這個(gè)在我機(jī)子上運(yùn)行的好好的”
“線上連的是生產(chǎn)數(shù)據(jù)庫(kù)械媒，不能讓你測(cè)試的”
“就修一個(gè)小BUG目锭，你們要兩天后才能全量上線，這效率也太低了”
“你的服務(wù)依賴(lài)的XX版本太高了纷捞，現(xiàn)網(wǎng)沒(méi)法裝的痢虹，回去修改一下吧”
彼此對(duì)對(duì)方的工具不了解，總是會(huì)在意料之外甚至十分詭異的地方出問(wèn)題主儡，開(kāi)發(fā)和運(yùn)維一方面對(duì)自己的環(huán)境十分熟悉奖唯，一方面又對(duì)對(duì)方隱瞞了許多隱喻和默認(rèn)規(guī)定，這使得雙方都陷入了知識(shí)的詛咒糜值，即因?yàn)橐呀?jīng)擁有知識(shí)的人丰捷，不能理解其他人為什么聽(tīng)不懂自己說(shuō)什么坯墨。

2。 唯快不破

現(xiàn)在的軟件市場(chǎng)上病往，任何一個(gè)產(chǎn)品火了捣染，它的競(jìng)爭(zhēng)對(duì)手都會(huì)加班加點(diǎn)趕出一個(gè)產(chǎn)品與之競(jìng)爭(zhēng)，就算是分不走一塊蛋糕停巷，也要搶上一塊奶油耍攘。只需要回想一下今年五顏六色的共享單車(chē)大戰(zhàn)就知道市場(chǎng)競(jìng)爭(zhēng)有多激烈。不僅僅是初創(chuàng)公司畔勤，即使是一個(gè)大型公司的最成熟蕾各、最成功的產(chǎn)品也在馬不停蹄地發(fā)展。支付寶出了一個(gè)新特性庆揪，一兩個(gè)月之內(nèi)微信支付也會(huì)出一個(gè)相同功能式曲。美團(tuán)的界面優(yōu)化一下，不久之后我們也能在餓了么上看到類(lèi)似的痕跡缸榛。

只要留心一下手機(jī)上的APP更新提示吝羞，幾乎每過(guò)去一個(gè)月，手機(jī)上的軟件就會(huì)重裝個(gè)遍仔掸，半年之內(nèi)脆贵，連手機(jī)的OS也會(huì)更新。linux內(nèi)核每天會(huì)受到數(shù)千行的patch請(qǐng)求起暮，Tomcat的源碼在筆者查看時(shí)的5分鐘前有更新。連功能十分成熟穩(wěn)定的Github会烙，也在一版一版地更新著開(kāi)發(fā)者接口负懦。

不單單是快能讓企業(yè)獲得更多利潤(rùn)，更多的時(shí)候是只有夠快才能活下去柏腻。留給淘寶雙十一團(tuán)隊(duì)的開(kāi)發(fā)時(shí)間只有1年整纸厉，到期撐不住請(qǐng)求量，公司的財(cái)產(chǎn)和聲譽(yù)都要蒙受損失五嫂。留個(gè)微信紅包團(tuán)隊(duì)的時(shí)間只有各個(gè)節(jié)假日之間的間隙颗品，0點(diǎn)的鐘聲響起，四面八方發(fā)來(lái)的紅包可不會(huì)管你的服務(wù)器吃不吃得消沃缘。更不用說(shuō)群雄割據(jù)的創(chuàng)業(yè)戰(zhàn)場(chǎng)躯枢，產(chǎn)品比別人快一個(gè)月就能收獲大量用戶(hù)。曾經(jīng)移動(dòng)端支付的產(chǎn)品有多達(dá)十幾個(gè)槐臀，個(gè)個(gè)都有強(qiáng)有力的后臺(tái)支撐锄蹂，然而幾年之后留在大家腦海里的就只剩兩個(gè)了。外賣(mài)水慨、直播得糜、電商敬扛、即時(shí)通訊，都經(jīng)歷過(guò)這樣一個(gè)各方爭(zhēng)霸最后只剩幾家進(jìn)入決賽的情況朝抖。

總的來(lái)說(shuō)啥箭，在2B和2C領(lǐng)域，用造教堂的方式來(lái)做軟件的團(tuán)隊(duì)也許早就被時(shí)代的洪流沖走治宣，用造集市甚至是擺地?cái)偟姆绞介_(kāi)發(fā)的團(tuán)隊(duì)才有機(jī)會(huì)站在賽場(chǎng)上捉蚤。快一點(diǎn)炼七，團(tuán)隊(duì)需要從市場(chǎng)的反饋中快速調(diào)整戰(zhàn)略缆巧；快一點(diǎn)，用戶(hù)希望不斷地看到有趣的新功能豌拙；快一點(diǎn)陕悬，以避免被后來(lái)的競(jìng)爭(zhēng)對(duì)手趕上；快一點(diǎn)按傅，別被前邊的領(lǐng)跑者甩開(kāi)捉超。

這給了整個(gè)團(tuán)隊(duì)很大的壓力。如果一切順利當(dāng)然萬(wàn)事大吉唯绍，但是一旦整個(gè)流程中出了問(wèn)題拼岳，公司面臨的損失都是沉重的。而根據(jù)我們?cè)谏衔年P(guān)于開(kāi)發(fā)與運(yùn)維之間矛盾的討論况芒，可以得出以下結(jié)論：開(kāi)發(fā)與運(yùn)維之間存在各種隔閡惜纸，而這種隔閡大大增加了服務(wù)上線時(shí)出故障的概率。而以上問(wèn)題在初創(chuàng)團(tuán)隊(duì)中往往不會(huì)遇到绝骚，原因是初創(chuàng)團(tuán)隊(duì)的軟件規(guī)模還不大耐版，每個(gè)模塊即使手工維護(hù)也照顧的過(guò)來(lái)。另外一個(gè)初創(chuàng)團(tuán)隊(duì)的規(guī)模是小于十個(gè)人压汪，溝通起來(lái)十分順暢粪牲，靠吼也能足夠快的解決問(wèn)題。但當(dāng)團(tuán)隊(duì)規(guī)模不斷擴(kuò)大止剖，溝通成本越來(lái)越大腺阳，組織開(kāi)始分層，分部門(mén)穿香。但是他們必須交付一個(gè)完整的亭引，可運(yùn)作的產(chǎn)品。這使得人員把過(guò)多的時(shí)間和精力耗費(fèi)在溝通扔水，協(xié)作痛侍，控制變更，修改BUG上。

具體到開(kāi)發(fā)和運(yùn)維主届，他們往往是兩個(gè)比較大的團(tuán)隊(duì)赵哲，這使得一個(gè)產(chǎn)品想要交付必須走過(guò)漫長(zhǎng)的審批流程。預(yù)估君丁，提單枫夺，一層一層的評(píng)審，一層一層的審批绘闷。當(dāng)出了問(wèn)題時(shí)橡庞，又要面臨著人員互相推諉，找不到負(fù)責(zé)任的窘境印蔗。就更不用說(shuō)服務(wù)上線時(shí)可能遇到的各種詭異BUG了扒最。這一切就像是給公司戴上了鐐銬，每人都很忙华嘹，但產(chǎn)品就是慢騰騰地做不出來(lái)吧趣。

3. 借鑒敏捷的思想

讓我們暫時(shí)把目光從開(kāi)發(fā)與運(yùn)維的困境轉(zhuǎn)向另外一個(gè)地方：產(chǎn)品與開(kāi)發(fā)。在很多地方產(chǎn)品與開(kāi)發(fā)面臨相同的局面：產(chǎn)品希望盡可能的滿(mǎn)足客戶(hù)的需求耙厚，并不斷適應(yīng)市場(chǎng)變化强挫，而開(kāi)發(fā)則最希望看到一個(gè)穩(wěn)定的、精確的需求薛躬。而開(kāi)發(fā)也經(jīng)常抱怨這個(gè)產(chǎn)品經(jīng)理什么技術(shù)都不懂俯渤，只會(huì)空口說(shuō)白話，產(chǎn)品也會(huì)認(rèn)為這個(gè)程序員對(duì)需求的理解總是不深入型宝，活在自己的世界中八匠。知識(shí)的詛咒依然生效。

某種程度上诡曙，敏捷軟件開(kāi)發(fā)讓上邊的局面有所好轉(zhuǎn)臀叙。敏捷將關(guān)注點(diǎn)從一份一份長(zhǎng)篇大論的文檔轉(zhuǎn)移到最終可執(zhí)行的代碼上的，相比于傳統(tǒng)的瀑布模型价卤，敏捷最主要的特點(diǎn)就是拋棄繁文縟節(jié)，并且以需求驅(qū)動(dòng)開(kāi)發(fā)渊涝。敏捷之所以盛行慎璧，不是因?yàn)樗鄬?duì)于其他開(kāi)發(fā)模型更優(yōu)越，而是因?yàn)樗m應(yīng)目前的開(kāi)發(fā)環(huán)境跨释，尤其適用于互聯(lián)網(wǎng)這種需求瞬息萬(wàn)變胸私，競(jìng)爭(zhēng)異常激烈的環(huán)境。相比于以文檔來(lái)推動(dòng)開(kāi)發(fā)瀑布模型鳖谈，敏捷更加輕量岁疼，更加便捷。以溝通舉例，敏捷非常注重面對(duì)面交流捷绒，既然大家一起開(kāi)個(gè)會(huì)就能講清楚的事瑰排，何必還要寫(xiě)事無(wú)巨細(xì)的文檔呢。另外以需求為驅(qū)動(dòng)的好處是開(kāi)發(fā)和產(chǎn)品的目標(biāo)一致了暖侨，開(kāi)發(fā)不在以固定不變的需求來(lái)規(guī)劃自己的節(jié)奏椭住，而是從一開(kāi)始就將變更的可能考慮進(jìn)去，他們針對(duì)變更而設(shè)計(jì)字逗。

“敏捷”這個(gè)名字恰如其分的表達(dá)了其方法論的內(nèi)涵京郑，它強(qiáng)調(diào)迅速，強(qiáng)調(diào)變化葫掉，強(qiáng)調(diào)自適應(yīng)些举。正如人月神話中所揭示的：“向進(jìn)度落后的項(xiàng)目中增加人手，只會(huì)使進(jìn)度更加落后”俭厚，敏捷偏愛(ài)短周期户魏，偏愛(ài)小團(tuán)隊(duì)。這看似增加了開(kāi)發(fā)過(guò)程的復(fù)雜性套腹，也減少了人力投入绪抛，但實(shí)際上卻加快了產(chǎn)品的開(kāi)發(fā)速度。

同樣的电禀，即使我們現(xiàn)在不知道DevOps方法幢码，也可以試著借鑒敏捷的思想來(lái)解決開(kāi)發(fā)和運(yùn)維之間矛盾。

3.1 更換目標(biāo)

產(chǎn)品與開(kāi)發(fā)之間的根本矛盾是尖飞，產(chǎn)品的目標(biāo)是提出更能吸引用戶(hù)症副，解決痛點(diǎn)的需求，而技術(shù)實(shí)現(xiàn)只是過(guò)程之一政基。而開(kāi)發(fā)的目標(biāo)是將各種各樣的需求轉(zhuǎn)化為可以運(yùn)行的代碼贞铣，技術(shù)實(shí)現(xiàn)是結(jié)果，而需求只是過(guò)程沮明≡樱看起來(lái)只是流水線上的兩個(gè)不同步驟而已，但卻帶來(lái)很多問(wèn)題荐健。因?yàn)樘岢鲂枨笙啾扔趯⑺涞貙?shí)現(xiàn)更加簡(jiǎn)單酱畅，因此需求的變化總是快于程序員的預(yù)料，再加上不斷變化的外界環(huán)境和競(jìng)爭(zhēng)產(chǎn)品江场，使得需求變化地更加頻繁纺酸。而敏捷開(kāi)發(fā)通過(guò)改變開(kāi)發(fā)人員的固有觀念來(lái)解決這個(gè)問(wèn)題。開(kāi)發(fā)人員不應(yīng)該期待穩(wěn)定的需求址否，而是應(yīng)該假設(shè)需求在下一個(gè)迭代就會(huì)變化餐蔬。開(kāi)發(fā)人員不應(yīng)該期待做出一個(gè)大而全的，功能豐富的軟件，而是應(yīng)該做出一個(gè)功能簡(jiǎn)陋的軟件樊诺，再一點(diǎn)一點(diǎn)添加新特性仗考。開(kāi)發(fā)人員不應(yīng)該期待能獲得一個(gè)長(zhǎng)時(shí)間的開(kāi)發(fā)周期，而是應(yīng)該小步快跑啄骇，讓軟件每周都能看到變化痴鳄。

同樣的，運(yùn)維人員和開(kāi)發(fā)人員也處在同一條流水線上缸夹，只不過(guò)開(kāi)發(fā)人員希望將開(kāi)發(fā)完的軟件盡快上線痪寻，以檢驗(yàn)自己成果。而運(yùn)維人員則期望能維護(hù)一個(gè)穩(wěn)定的虽惭、不變的軟件橡类，而不是三天兩頭就增加新特性的軟件。這次我們需要改變運(yùn)維人員的固有觀念了芽唇。即運(yùn)維人員不應(yīng)該期待一個(gè)穩(wěn)定不變的軟件顾画，而是從一開(kāi)始就針對(duì)頻繁變更而運(yùn)維，運(yùn)維人員不應(yīng)該期待開(kāi)發(fā)人員把多次修改精心合并成一個(gè)里程碑匆笤，然后一次發(fā)布研侣，而是應(yīng)該接受一個(gè)又一個(gè)的beta甚至alpha版本被推到線上，運(yùn)維人員不應(yīng)該期待自己能有較長(zhǎng)的時(shí)間仔細(xì)檢查環(huán)境配置炮捧，而是要想盡辦法讓運(yùn)維變得快速庶诡，簡(jiǎn)單，自動(dòng)化咆课。

3.2 去除繁文縟節(jié)

傳統(tǒng)的瀑布式開(kāi)發(fā)中末誓，最核心、最繁重的任務(wù)莫過(guò)于文檔的編寫(xiě)和管理书蚪。前景范圍文檔喇澡，用例文檔，需求規(guī)格說(shuō)明殊校，概要設(shè)計(jì)晴玖，詳細(xì)設(shè)計(jì)，部署文檔等等为流。即使是為了描述一個(gè)學(xué)校中的玩具項(xiàng)目窜醉，也需要寫(xiě)十萬(wàn)字左右的文檔，以及幾十張圖艺谆。足夠四個(gè)人全力編寫(xiě)一學(xué)期，五六位助教評(píng)審數(shù)個(gè)小時(shí)拜英。這導(dǎo)致隊(duì)伍中甚至出現(xiàn)全職的文檔編寫(xiě)人員静汤。最糟糕的是這些文檔是有耦合關(guān)系的。一份文檔改變，為了維護(hù)一致性虫给，往往其下游的文檔又要變化藤抡，以致于每次變更都要牽一發(fā)而動(dòng)全身。這使得需求變更被各種繁文縟節(jié)束縛住抹估，寸步難行缠黍。

而敏捷恰恰相反，它強(qiáng)調(diào)：個(gè)體與互動(dòng)高于流程和工具药蜻， 工作的軟件重于詳盡的文檔瓷式。它從來(lái)不指望軟件能像流水線上的汽車(chē)一樣，每個(gè)人悶頭在流水線上干自己的事语泽，最后軟件就像變魔術(shù)一樣出現(xiàn)了贸典。它強(qiáng)調(diào)大家從一開(kāi)始就頻繁溝通，雖然分工合作踱卵，但有充分合作廊驼，不對(duì)彼此隱瞞信息。

之所以瀑布式開(kāi)發(fā)如此強(qiáng)調(diào)文檔惋砂，如此恪守規(guī)范妒挎，我想是出于一種“流程神話”，即它相信足夠優(yōu)秀詳盡的流程西饵，一定能導(dǎo)致令人滿(mǎn)意的成果酝掩。這個(gè)觀點(diǎn)在制造業(yè)或者硬件行業(yè)體現(xiàn)得很好，一套完善的流水線或者一套精密的機(jī)械罗标，能源源不斷地制造出高質(zhì)量的產(chǎn)品庸队。然而這招在軟件業(yè)卻不怎么奏效：沒(méi)有任何一種流程能避免需求變更，沒(méi)有任何一種流程能替代人與人之間直接的交流闯割。流程再怎么嚴(yán)格彻消，文檔再怎么詳盡，也沒(méi)有辦法避免需求變動(dòng)和人本身的錯(cuò)誤造成的返工宙拉。

既然如此宾尚，不如直接去除這些繁文縟節(jié)。能用紙條說(shuō)清楚的需求谢澈，就不要填十幾個(gè)字段的表格煌贴，能在白板上講明白的設(shè)計(jì)，就去畫(huà)不要去畫(huà)各種各樣的設(shè)計(jì)圖了。

同樣的画髓，為什么想要發(fā)布一個(gè)服務(wù)需要一層一層的評(píng)審和審批纵顾，為什么想要部署一下變更需要提前多少天就提單，然后進(jìn)行漫長(zhǎng)的等待淹朋，為什么運(yùn)維不能整裝待發(fā)笙各，早早就像部署前的一切工作準(zhǔn)備好，等待新的模塊開(kāi)發(fā)完成就立刻上線呢础芍？過(guò)于嚴(yán)苛的流程看似保障了結(jié)果的正確性杈抢，但它實(shí)際上限制了整個(gè)團(tuán)隊(duì)的生產(chǎn)力。

4. 自動(dòng)化偏執(zhí)

與產(chǎn)品崗不一樣的是仑性，開(kāi)發(fā)和運(yùn)維都是專(zhuān)業(yè)的技術(shù)人員惶楼，所從事的工作都是技術(shù)性的。而技術(shù)性通常意味著有自動(dòng)化的空間诊杆。開(kāi)發(fā)和運(yùn)維之間有多少人力操作呢歼捐？ 提單，審批刽辙，編譯窥岩，部署，檢查環(huán)境宰缤，檢查配置颂翼，分配機(jī)器，部署文件慨灭，上線觀察朦乏。在人手工操作的情況下，每一項(xiàng)都非常消耗精力氧骤，更不用說(shuō)把這些操作全部來(lái)一遍了呻疹。

正如Perl語(yǔ)言的發(fā)明人Larry Wall所說(shuō)，程序員有三大美德： 懶惰筹陵、急躁和傲慢（Laziness, Impatience and hubris）刽锤。懶惰使得程序員討厭重復(fù)勞動(dòng)，不斷追求一勞永逸朦佩。急躁使得程序員討厭細(xì)碎繁瑣而又機(jī)械化的工作并思，希望能快速，省力地得到反饋语稠。傲慢使得程序員對(duì)于工作追求極致宋彼，追求完美。

顯然仙畦，運(yùn)維所面臨的困境使得程序員的美德蕩然無(wú)存输涕，無(wú)窮無(wú)盡的人力操作限制了開(kāi)發(fā)團(tuán)隊(duì)的生產(chǎn)力。因此慨畸，我們需要新的技術(shù)和新的工具讓運(yùn)維敏捷化莱坎。

對(duì)于代碼，我們需要完善的版本控制工具寸士，來(lái)讓我們?cè)跁r(shí)間線中進(jìn)退自如型奥。對(duì)于構(gòu)建瞳收，我們需要持續(xù)集成服務(wù)器來(lái)保證代碼時(shí)刻可以運(yùn)行。對(duì)于測(cè)試厢汹，我們需要完善的沙箱環(huán)境，是之既可以隨便破壞谐宙，也盡量與實(shí)際環(huán)境相符烫葬。對(duì)于上線發(fā)布，我們要將復(fù)雜的機(jī)器操作和配置管理自動(dòng)化凡蜻，一鍵上線搭综，一鍵回退。對(duì)于監(jiān)控划栓，我們應(yīng)該把它變成基礎(chǔ)設(shè)施兑巾，只要登錄一個(gè)網(wǎng)頁(yè)，就能看到各個(gè)機(jī)器的各項(xiàng)信息忠荞。

如果只是這些蒋歌，那還沒(méi)有到“偏執(zhí)”的程度，真正的偏執(zhí)是希望一切能自動(dòng)化委煤。難道每次縮擴(kuò)容都要去機(jī)房搬機(jī)器嗎堂油？不，硬件應(yīng)該抽象成可配置的資源碧绞，底層的資源分配和隔離全部自動(dòng)化府框。難道每次拿到新資源都要把環(huán)境配一遍嗎？不讥邻，基礎(chǔ)設(shè)施不過(guò)是一段代碼迫靖，運(yùn)行即可。甚至在有了docker之后兴使，環(huán)境就像積木一樣系宜，可以整塊搬運(yùn)，相互堆疊鲫惶。

既不是devops創(chuàng)造了各種工具蜈首，也不是各種工具創(chuàng)造出了devops。畢竟在devops提出之前欠母，很多工具已經(jīng)出現(xiàn)了欢策。我認(rèn)為應(yīng)該是devops的方法論和價(jià)值觀，使得這些工具被組合在一起赏淌，并促進(jìn)了新工具的出現(xiàn)踩寇。

5. 總結(jié)

就像是高級(jí)語(yǔ)言必然出現(xiàn)，面向?qū)ο蟊厝怀霈F(xiàn)或者分布式系統(tǒng)必然出現(xiàn)一樣六水，devops方法是必然出現(xiàn)的俺孙。它出現(xiàn)的邏輯是：一方面辣卒，隨著業(yè)務(wù)復(fù)雜化和人員的增加，開(kāi)發(fā)人員和運(yùn)維人員逐漸演化成兩個(gè)獨(dú)立的部門(mén)睛榄，他們工作地點(diǎn)分離荣茫，工具鏈不同，業(yè)務(wù)目標(biāo)也有差異场靴，這使得他們之間出現(xiàn)一條鴻溝啡莉。而發(fā)布軟件就是將一個(gè)軟件想從鴻溝的這邊送去那邊，這之中困難重重旨剥。另一方面咧欣，行業(yè)競(jìng)爭(zhēng)更加激烈，無(wú)論是客戶(hù)還是公司自身轨帜，都要求軟件能快速發(fā)布魄咕，頻繁修改，而上邊所說(shuō)的這種隔閡蚌父，阻礙了開(kāi)發(fā)團(tuán)隊(duì)的生產(chǎn)力哮兰，成了企業(yè)亟待解決的難題。

因此梢什，devops提出了解決問(wèn)題的辦法：它提倡軟件持續(xù)交付奠蹬，頻繁部署。它力圖填平開(kāi)發(fā)和運(yùn)維之間的鴻溝嗡午，他們應(yīng)該拋棄各種繁文縟節(jié)囤躁，頻繁溝通，密切協(xié)作荔睹。但只有觀念和組織結(jié)構(gòu)上的改變是不夠的狸演，一切必須建立在自動(dòng)化的基礎(chǔ)上。devops熱忱的追求自動(dòng)化和工具鏈僻他，硬件資源應(yīng)該觸手可及宵距，環(huán)境與配置應(yīng)該可以隨意復(fù)制，修改和回退吨拗，開(kāi)發(fā)和運(yùn)維的流程應(yīng)該便捷满哪，省力，甚至一鍵完成劝篷。

有人認(rèn)為devops之所以能提高效率哨鸭，是因?yàn)樗岢隽艘环N新的流程，或者引入了新的工具娇妓，但我認(rèn)為流程像鸡，工具都不是devops的本質(zhì)，它的本質(zhì)是倡導(dǎo)開(kāi)發(fā)團(tuán)隊(duì)擰成一股繩哈恰，緊密合作只估，頻繁溝通志群，流程和工具只不過(guò)是大家合作得更充分，更廣泛蛔钙。將人的地位放在技術(shù)之前锌云，將交流與溝通放在流程之上，才是devops提高生產(chǎn)力的原因夸楣。