DevOps的價(jià)值觀解析

1、 DevOps的價(jià)值觀解析目 錄 TOC o 1-3 h z u HYPERLINK l _Toc522801687 1.前言 PAGEREF _Toc522801687 h 3 HYPERLINK l _Toc522801688 2.業(yè)務(wù)、架構(gòu)與技術(shù) PAGEREF _Toc522801688 h 4 HYPERLINK l _Toc522801689 3.原則、方法與實(shí)踐 PAGEREF _Toc522801689 h 14 HYPERLINK l _Toc522801690 4.小結(jié) PAGEREF _Toc522801690 h 17前言初創(chuàng)公司，業(yè)務(wù)方向不明確的情況下，如何拆分微服務(wù)

2、，其實(shí)：“架構(gòu)是服務(wù)于業(yè)務(wù)的，太過超前的架構(gòu)是浪費(fèi)”，由此想到架構(gòu)與業(yè)務(wù)其實(shí)也有相似的關(guān)系。參考Nicole的句式，從DevOps涉及到的幾個(gè)維度出發(fā)：業(yè)務(wù)、架構(gòu)與技術(shù)；人、流程與工具；原則，方法與實(shí)踐，于是便有了如下的幾句話:Business mattersArchitecture doesntArchitecture mattersTechnology doesntPeople mattersProcess doesntProcess mattersTool doesntPrinciple mattersMethod doesntMethod mattersPractice doesnt稱

3、之為樸素的DevOps價(jià)值觀。之所以樸素，是因?yàn)檫@只是我的一個(gè)比較原始的想法，并未仔細(xì)推敲與提煉；稱之為價(jià)值觀是因?yàn)榫哂邢喈?dāng)?shù)钠者m性；同時(shí)我也希望，如果有幸真的可以逐漸形成價(jià)值觀，它也應(yīng)該是簡單質(zhì)樸的。業(yè)務(wù)、架構(gòu)與技術(shù)業(yè)務(wù)Business，架構(gòu)Architecture，技術(shù)Technology，縮寫為BAT ?Business mattersArchitecture doesnt架構(gòu)是服務(wù)于業(yè)務(wù)的，關(guān)于初創(chuàng)公司，新型的業(yè)務(wù)，是否需要采納微服務(wù)，回答當(dāng)然是視情況而定的，但通常建議從單體應(yīng)用開始。微服務(wù)的價(jià)值與挑戰(zhàn)一樣明顯，所以Martin Fowler有如下的一幅圖。初創(chuàng)公司，業(yè)務(wù)方向還在不斷探

4、索，服務(wù)的邊界是模糊的，即使對(duì)微服務(wù)的技術(shù)儲(chǔ)備足夠，也不建議此時(shí)就搞微服務(wù)架構(gòu)，用最簡單直接的方法搞定快速變化的業(yè)務(wù)訴求。用貸款買房來類比架構(gòu)投入，自己出的首付款就像是前期在架構(gòu)上的投入，貸款就好比是減少一定的架構(gòu)投入，所需承擔(dān)的技術(shù)債務(wù)：貸款買房，預(yù)期的是未來的房產(chǎn)的增值，貸款的利息相較起來是可以接受的；創(chuàng)業(yè)期也是同樣，此時(shí)承擔(dān)一定的技術(shù)債務(wù)是明智合理的選擇。一味追求全款買房，就會(huì)錯(cuò)過買房的最佳時(shí)間窗口；業(yè)務(wù)的時(shí)間窗口更短，需要不斷的快速試錯(cuò)，期望在架構(gòu)層面一步就位是不現(xiàn)實(shí)的。不能貸款過多，否則無法承擔(dān)月供；架構(gòu)可以一開始簡單些，原始一些，但基本的質(zhì)量和NFR還是需要滿足的；而一旦找對(duì)業(yè)務(wù)方

5、向，又需要快速展開，所以架構(gòu)在初期具備一定的擴(kuò)展能力還是需要的。要定期清理債務(wù)，房貸車貸過多，即使是有力償還，生活質(zhì)量也會(huì)下降，脫離了原始購房改善生活質(zhì)量的初衷；技術(shù)債務(wù)也需要定期償還，定期清理，不能讓因?yàn)榧夹g(shù)債務(wù)產(chǎn)生的額外時(shí)間成本，大于承擔(dān)技術(shù)債務(wù)所帶來的機(jī)會(huì)成本。這其實(shí)是一個(gè)經(jīng)濟(jì)杠桿，用短期或長期的負(fù)債，來換取時(shí)間成本和機(jī)會(huì)成本。所以做架構(gòu)也好，做DevOps也好，需要有經(jīng)濟(jì)的頭腦。SAFe第一條原則Take an economic view，也有這層含義。這是一個(gè)平衡，一場與時(shí)間的賽跑，但總而言之，業(yè)務(wù)訴求高于一切。以上所說的都是因?yàn)闃I(yè)務(wù)戰(zhàn)略需要，主動(dòng)有意識(shí)的承擔(dān)技術(shù)債務(wù)；如果是無意識(shí)的

6、負(fù)債，那個(gè)叫做奢侈浪費(fèi)，原本就應(yīng)該消除。Architecture mattersTechnology doesnt巴別塔：圣經(jīng)舊約創(chuàng)世記第11章記載，當(dāng)時(shí)人類語言相通，同心協(xié)力，聯(lián)合起來興建希望能通往天堂的高塔，“來吧，我們要建造一座城，和一座塔，塔頂通天，為要傳揚(yáng)我們的名，免得我們分散在全地上”。此舉驚動(dòng)了上帝，為了阻止人類的計(jì)劃，于是他悄悄地離開天國來到人間，改變并區(qū)別開了人類的語言，使他們因?yàn)檎Z言不通而分散在各處，那座塔于是半途而廢了。架構(gòu)如此重要，所以一旦業(yè)務(wù)相對(duì)清晰一些，就要根據(jù)業(yè)務(wù)需要，考慮逐漸切換到微服務(wù)架構(gòu)，才不至于堆積太多技術(shù)債務(wù)，對(duì)于可擴(kuò)展性、可規(guī)模化、可部署性等也都至關(guān)重

7、要。優(yōu)雅的良好的架構(gòu)更加重要，不要讓微服務(wù)成為另一座巴別塔。理論上微服務(wù)可以最大化利用各種語言的優(yōu)勢，但如果沒有好的服務(wù)切分與架構(gòu)設(shè)計(jì)，微服務(wù)只會(huì)變成更大的災(zāi)難，只會(huì)是碎片化而不是去中心化。微服務(wù)的目的是更靈活的協(xié)同，如果服務(wù)之間缺少溝通，就背離了微服務(wù)設(shè)計(jì)的初衷。Google內(nèi)部有開發(fā)三大語言C/C+，Python，Java，分別是官方編譯語言，官方腳本語言，和官方UI語言。堅(jiān)持三大語言意味著內(nèi)部溝通的順暢。沒有使用最新的技術(shù)和語言，并不影響，反而有助于Google快速成為世界頂級(jí)的公司。團(tuán)隊(duì)效率高于個(gè)人效率，統(tǒng)一技術(shù)棧帶來的收益，往往大于使用最新技術(shù)棧帶來額外的維護(hù)和溝通成本。Etsy在2

8、010年，決定大量減少生產(chǎn)環(huán)境中的技術(shù)，統(tǒng)一標(biāo)準(zhǔn)化到LAMP棧，“與其說這是一個(gè)技術(shù)決策，不如說是一個(gè)哲學(xué)決策”，這讓所有人，包括開發(fā)和韻味，都能理解整個(gè)技術(shù)棧。另一個(gè)例子，Etsy在2010年引入MongoDB，結(jié)果是“無模式數(shù)據(jù)庫的所有優(yōu)勢都被它們引發(fā)的運(yùn)維問題抵消了”，最終Etsy還是選擇放棄了MongoDB，遷移到MySQL。DevOps也并非只有Web應(yīng)用、SaaS或是開放平臺(tái)才適用，我們聽到太多傳統(tǒng)銀行的轉(zhuǎn)型案例，主機(jī)開發(fā)的案例，技術(shù)并非DevOps的絕對(duì)先決條件，雖然開放平臺(tái)可供選擇的工具會(huì)多一些，后面我們還會(huì)就工具進(jìn)行討論。技術(shù)圈總是喜歡追逐潮流，總是存在各種鄙視鏈。就像前一段

9、看到的PHP與其他各種語言的互噴群；還有類似于容器編排技術(shù)，大家一窩蜂的從Swarm、Mesos向K8s遷移。技術(shù)永遠(yuǎn)不是第一位的，最新的未必是最合適的，永遠(yuǎn)追逐最新的技術(shù)，往往喪失了自我的思考和技術(shù)的積累。人、流程與工具人People, 流程Process, 工具Tool，傳說中的PPT模型 ?People mattersProcess doesnt最近敏捷微信群里沸沸揚(yáng)揚(yáng)的CMMI之爭，不去論述誰是誰非。我早先也參加過公司的CMMI 2/3級(jí)評(píng)估，CMMI應(yīng)該是團(tuán)隊(duì)做到一定程度，拿來對(duì)自身進(jìn)行現(xiàn)狀評(píng)估，用以指導(dǎo)下一步改進(jìn)的參照。CMMI模型的初衷是好的，設(shè)置也還算合理，模型事實(shí)上也是在演進(jìn)

10、的，只是被不合理的使用了。所以模型也好，流程也好，使用它們的人，以及用法，才是最重要的。這就好比聚賢莊一站，喬峰用一套太祖長拳，打敗天下英雄。太祖長拳，號(hào)稱三歲孩童都會(huì)的拳法，為何可以在喬峰手里發(fā)揮如此巨大的威力？具體的武功招式，方法流程，并不重要，重要的是看誰來用，如何用。關(guān)于流程的另一個(gè)問題：如果流程是最重要的，那么到底是流程要求的多好，還是流程要求的少好？正如上圖，Henrik Kniberg在Kanban vs/with Scrum里，對(duì)RUP、SCRUM、KANBAN等方法的約束給出了最直觀的感覺：RUP有120多個(gè)要求，XP有13個(gè)，SCRUM是9個(gè)，而KANBAN只有3個(gè)。RUP

11、是最重視流程和方法的，而KANBAN是最不重視的，孰優(yōu)孰劣？很難講，我并不覺得RUP就一定不如KANBAN，RUP在實(shí)際采納時(shí)需要裁剪，只是因?yàn)椴眉舻倪^程對(duì)人的能力要求太高；Henrik說，“Scrum和RUP的主要區(qū)別在于，RUP給你的東西太多了，你得自己把不需要的東西去掉；而Scrum給你的東西太少了，你得自己把需要的東西加進(jìn)來?？窗宓募s束比Scrum少，這樣一來，你就得要考慮更多因素”。一邊是需要裁剪，另一邊是需要增加，所以執(zhí)行到最后，成熟的團(tuán)隊(duì)的研發(fā)流程，大抵都能找到很多相似之處。Process mattersTool doesnt現(xiàn)在一提到DevOps，大家談的比較多的，是如何用工具

12、搭建流水線，如何用工具搭建容器化開發(fā)平臺(tái)，持續(xù)集成應(yīng)該用什么工具，自動(dòng)化測試應(yīng)該用什么工具，諸如此類。我們常見的持續(xù)交付工具圖譜，里面有太多是5年前、10年前甚至更早就推出的工具。如果工具是實(shí)施DevOps的關(guān)鍵，那么十年前就有這些工具，理論上當(dāng)時(shí)我們就應(yīng)該成功實(shí)施了DevOps，實(shí)際上我們又做的如何呢？http:/www.jamesbowman.me/post/continuous-delivery-tool-landscape/工具當(dāng)然是重要的，沒有工具是萬萬不能的。但工具不是萬能的，比工具更重要的是使用工具的方法和流程，當(dāng)然比流程更重要的，是執(zhí)行流程和使用工具的人。簡單如SVN，復(fù)雜如C

13、learcase，我都看到過在此基礎(chǔ)上，實(shí)施持續(xù)集成非常成功的企業(yè)。Martin Fowler對(duì)CI的定義和建議，從2006年至今，居然未曾修改過:/articles/continuousIntegration.html即使到現(xiàn)在，又有幾個(gè)人敢拍著胸脯說，真正能把CI這些實(shí)踐做到的？所以流程也好，工具也罷，最重要的是執(zhí)行的人，而對(duì)人而言，關(guān)鍵的是思維模式Mindset，用今年的熱詞，我稱之為原則Principle。原則、方法與實(shí)踐原則Principle，方法Method，實(shí)踐Practice，縮寫為PMP ?Principle mattersMethod doesnt敏捷的方法有很多，講了很多

14、年也還任重道遠(yuǎn)；豐田TPS被各大車企學(xué)習(xí)了30年，沒有哪家能學(xué)到真經(jīng)的；有人說，豐田生產(chǎn)模式，最重要的是背后的KATA，即豐田套路，如何使得改善和提高適應(yīng)性成為組織日常工作的一部分，而KATA的書出版到現(xiàn)在也快10年了，好像依然沒有多大改觀。敏捷的方法有很多，SCRUM，精益看板等，SAFe是大規(guī)模的敏捷，DevOps也有很多種模型。比模型更重要的是背后的原則，雖然這些模型從表象上相差甚遠(yuǎn)，但其背后的原則卻十分相似，比如敏捷宣言的十二條原則，SAFe的九大原則，以及DevOps的CALMS原則。方法論的表現(xiàn)形式有很多，具體落地執(zhí)行又根據(jù)不同企業(yè)千變?nèi)f化，但不變的，相通的，是背后的原則。好比張三

15、豐教張無忌自己新創(chuàng)的太極劍，張三豐教的快，每次的招式還都不同，張無忌學(xué)的快，忘的更快，“不壞，不壞！忘的真快”，武功招式始終是下乘的，心法精髓才是上乘，守住了心法，招式就可以隨時(shí)創(chuàng)新，不必拘泥。Method mattersPractice doesnt雷神3里的橋段，奧丁的女兒海拉輕易的就捏爆了雷神之錘，索爾靈魂出竅，一時(shí)仿佛看到他已故的父親奧丁。他向他的父親求助。奧?。核鳡?，你是錘子之神嗎？那錘子，是為了讓你控制你的力量，讓你更專注，它不是你的力量的來源，你才是。我們經(jīng)常會(huì)得到錘子，錘子很重要，它是個(gè)開始。錘子又不重要，當(dāng)你能夠控制你的力量的時(shí)候。（部分截取自歐蘭輝朋友圈的一段話）DevOp

16、s原本就是偏實(shí)踐層面的，有很多實(shí)踐歸納，比如下圖的Gartner的DevOps模式和實(shí)踐圖，還有DevOps地鐵圖。但這些實(shí)踐都只見樹木不見森林，缺少彼此之間的關(guān)聯(lián)和依賴，需要方法將其串起來。這也是為什么一套辟邪劍法的劍招，缺了葵花寶典的心法，就稀疏平常淪為三流一樣。從Practice，到Method，到Principle；也是從Doing，到Thinking，到Being的過程。Being DevOps并非一蹴而就的事情，需要從實(shí)踐做起，心里要有方法論，過程中始終嚴(yán)守原則。又不能固守著那把實(shí)體的錘子，方法也好，實(shí)踐也好，都只是達(dá)成目標(biāo)的途徑，而原則才是指南針。小結(jié)我的樸素的DevOps價(jià)值觀首先，業(yè)務(wù)、架構(gòu)、技術(shù)，人、流程、工具，原則、方法、實(shí)踐，這九大元素不能孤立的來看，原本就是相輔相成，密切相關(guān)的。Principle背后，其實(shí)是人的Mindset思維模式，而一堆人遵循同樣的Principle，就演化成了文化Culture。方法Method也好，流程Process也好，最終都由實(shí)踐Practice通過工具Tool落地。DevOps、微服務(wù)和容器的三劍客，也是方法、架構(gòu)與技術(shù)與工具的極佳結(jié)合。其次，所有這些元素都重要，缺一不可；但不要舍本逐末，需要了解什么是根因，什么