DevOps轉(zhuǎn)型的動(dòng)機(jī)
我們的客戶是一家海外本土最大的金融保險(xiǎn)集團(tuán)瓢阴，他們在發(fā)展到一定規(guī)模以后咐蚯，意識(shí)到自己就像一頭笨重的大象，舉步維艱苛让，通過對整個(gè)交付流程的思考和分析沟蔑，發(fā)現(xiàn)了以下一些嚴(yán)重影響交付速度的問題：
- 一些好的關(guān)于產(chǎn)品改善和創(chuàng)新的想法很難落地湿诊。涉及到一些遺留系統(tǒng)的配合：調(diào)整、部署瘦材、擴(kuò)展等厅须，使團(tuán)隊(duì)對發(fā)布沒有信心。新的服務(wù)或者應(yīng)用的構(gòu)建食棕，很難快速上線朗和，被卡在了生產(chǎn)環(huán)境部署階段。
- 各種不同種類的應(yīng)用宣蠕、服務(wù)的部署方式和流程不一致例隆。運(yùn)維部門作為一個(gè)支持部門，很難為大量團(tuán)隊(duì)提供快速反應(yīng)抢蚀。運(yùn)維人員對于需要部署和運(yùn)營環(huán)境之上的產(chǎn)品也不夠了
解镀层。 - 微服務(wù)運(yùn)營過程中，交付團(tuán)隊(duì)難以做到快速集成和部署皿曲。運(yùn)維團(tuán)隊(duì)對微服務(wù)的部署運(yùn)維方式不理解唱逢，依舊老瓶裝新藥，很難適配新架構(gòu)下的交付模式屋休。開發(fā)團(tuán)隊(duì)大多關(guān)注代碼和架構(gòu)坞古，對于產(chǎn)品如何能在生產(chǎn)環(huán)境穩(wěn)定運(yùn)行、需要考慮哪些安全性和可持續(xù)性的因素并不是很了解劫樟。
問題分析和挑戰(zhàn)
通過對這些問題和各個(gè)團(tuán)隊(duì)反饋的深入分析痪枫，發(fā)現(xiàn)其中最大的瓶頸在于交付團(tuán)隊(duì)與運(yùn)維部門之間的各種依賴和溝通浪費(fèi)，而這個(gè)瓶頸又是解決大多數(shù)問題的前提叠艳。
我們將瓶頸具象化后（如圖上圖）奶陈，可以看到兩種團(tuán)隊(duì)之間其實(shí)是存在一堵墻的，一是因?yàn)閭鹘y(tǒng)的部署流程非常繁瑣和低效附较。二是因?yàn)閮煞N角色關(guān)注點(diǎn)和目標(biāo)的不一致吃粒。
如果在這樣的情況下，想實(shí)現(xiàn)微服務(wù)架構(gòu)轉(zhuǎn)型拒课，實(shí)現(xiàn)更快速和安全的交付徐勃，只會(huì)更快的暴露出這堵墻引起的各種問題。開發(fā)階段早像，系統(tǒng)的架構(gòu)和依賴環(huán)境都是Developer說了算僻肖，對生產(chǎn)環(huán)境的關(guān)注度不高。部署卢鹦、發(fā)布階段檐涝，Operations會(huì)考慮如何構(gòu)建一套穩(wěn)定的基礎(chǔ)設(shè)施，又如何去部署和運(yùn)維開發(fā)的產(chǎn)物，但是往往對于產(chǎn)物的了解不充分谁榜，對于產(chǎn)物的周邊生態(tài)和與它們關(guān)系的了解也不夠幅聘。
那么引入DevOps文化，消除開發(fā)與運(yùn)維之間的壁壘窃植，逐步打造更高效的交付流程就成為我們破局的關(guān)鍵帝蒿，那我們應(yīng)該怎么做呢？
改革之初巷怜，我們發(fā)現(xiàn)并去嘗試了Bimodel(雙模IT)葛超， 我們看看它是否能解決我們的問題：
先簡單介紹一下什么是雙模IT:
它將IT系統(tǒng)分成了兩種模式:
- 一種是新型的數(shù)字化、高市場適應(yīng)性的IT延塑，這部分業(yè)務(wù)聚焦企業(yè)新市場和業(yè)務(wù)的開拓绣张，創(chuàng)新和發(fā)展，強(qiáng)調(diào)IT自身對于市場的高適應(yīng)力关带。
- 另外一種模式下侥涵，我們則需要穩(wěn)固發(fā)展，對于傳統(tǒng)模式我們傾向于更加嚴(yán)謹(jǐn)和標(biāo)準(zhǔn)的流程去保護(hù)現(xiàn)有業(yè)務(wù)宋雏，穩(wěn)定性比速度更加重要芜飘。
我們從采用這樣一種模式的實(shí)踐案例中發(fā)現(xiàn)：組織內(nèi)部會(huì)出現(xiàn)連兩種速度的交付流程，好的情況可能是采用敏捷開發(fā)流程的交付線磨总，有著快速的交付能力嗦明，相反，對于繼續(xù)采用傳統(tǒng)開發(fā)流程和運(yùn)維方式的團(tuán)隊(duì)蚪燕，保持著穩(wěn)定但低效的交付能力娶牌。
從業(yè)界很多公司的現(xiàn)狀和發(fā)展趨勢來看，雙模IT確實(shí)是很多組織存在的現(xiàn)狀或是必然經(jīng)歷的過程馆纳，但不是一個(gè)好的模式诗良，從實(shí)際的交付過程來看，存在4點(diǎn)問題：
- 雙模IT的劃分方式更多是基于軟件系統(tǒng)厕诡，而不是從業(yè)務(wù)活動(dòng)出發(fā)進(jìn)行的累榜，所有軟件系統(tǒng)的交付都應(yīng)該是面向業(yè)務(wù)價(jià)值的营勤。
- 雙模IT會(huì)讓我們誤以為速度的提升會(huì)引起質(zhì)量的下降灵嫌，但是對于我們在ThoughtWorks的很多敏捷實(shí)踐中學(xué)到的：隨著交付的推進(jìn)，質(zhì)量內(nèi)建是團(tuán)隊(duì)共同負(fù)責(zé)和持續(xù)改進(jìn)的重點(diǎn)葛作。交付速度的提升寿羞，往往都伴隨著質(zhì)量的保障，而不是忽視質(zhì)量赂蠢。
- 實(shí)際生產(chǎn)中绪穆，一個(gè)新的產(chǎn)品或者功能往往會(huì)依賴很多遺留系統(tǒng)提供的服務(wù)，如果它們僅僅只能達(dá)到穩(wěn)定和低效的交付，對企業(yè)來說對市場整體的響應(yīng)能力也會(huì)越來越低玖院。
- 企業(yè)的創(chuàng)新不僅僅只是從零創(chuàng)造一個(gè)新的產(chǎn)品菠红，還有很多機(jī)遇現(xiàn)有的資源。一個(gè)新的系統(tǒng)和功能往往不僅會(huì)既涉及到新服務(wù)难菌、應(yīng)用的創(chuàng)建试溯，也會(huì)涉及到遺留系統(tǒng)的修改，調(diào)整和改造郊酒。
由此可見雙模IT是在以一種試圖掩蓋問題的方式來逃避目前最重要的問題：開發(fā)和運(yùn)維之間的壁壘遇绞。感覺像是一個(gè)病人先是放棄治療，然后又努力的尋找延長壽命的方法燎窘，有些隱患終會(huì)爆發(fā)摹闽。
打造自服務(wù)持續(xù)交付
緊接著，我們開始采用了一種看似不可行的方式開啟了DevOps轉(zhuǎn)型褐健，建立公有DevOps團(tuán)隊(duì)付鹿。有很多人可能會(huì)說這是一種反模式，怎么可能會(huì)建立一個(gè)團(tuán)隊(duì)專做DevOps相關(guān)的事情铝量，那和以前的運(yùn)維部門又有什么區(qū)別倘屹？DevOps提倡的Dev與Ops高頻度合作的文化是不是就無法大面積傳播了？
因此我們需要很明確的定義我們對這個(gè)團(tuán)隊(duì)的期望和它的職責(zé)是什么慢叨，它是怎樣和交付團(tuán)隊(duì)合作纽匙，影響交付團(tuán)隊(duì)，最終能讓DevOps的文化可以大面積傳播拍谐。這個(gè)團(tuán)隊(duì)的目標(biāo)是要像杠桿一樣烛缔，翹起更大面積的DevOps變革。
所以我們認(rèn)為公有DevOps團(tuán)隊(duì)?wèi)?yīng)該與其它的端到端交付團(tuán)隊(duì)的人員構(gòu)成是一樣的轩拨。不同的只是目標(biāo)和價(jià)值践瓷，主要體現(xiàn)在幫助更多的團(tuán)隊(duì)植入DevOps文化、優(yōu)化持續(xù)交付流程亡蓉。最終達(dá)到的目標(biāo)是每個(gè)團(tuán)隊(duì)都可以自治晕翠，每個(gè)團(tuán)隊(duì)都可以進(jìn)行端到端的開發(fā)、測試和部署砍濒，并可以自驅(qū)動(dòng)的持續(xù)改進(jìn)淋肾。與此同時(shí)，這個(gè)團(tuán)隊(duì)不僅僅只是為交付團(tuán)隊(duì)提供更多涉及基礎(chǔ)設(shè)施爸邢、持續(xù)交付流水線樊卓、部署等活動(dòng)所需要的自動(dòng)化能力，還會(huì)支撐交付團(tuán)隊(duì)根據(jù)自身的上下文去定制和規(guī)劃自己的持續(xù)交付流程和部署策略等杠河。
（圖片來自：http://t.cn/R9jnzHR）
現(xiàn)在碌尔，相比于DevOps團(tuán)隊(duì)的叫法浇辜，我們更愿意稱呼這個(gè)團(tuán)隊(duì)為Platform團(tuán)隊(duì)，一個(gè)原因是我之前所說的避免被錯(cuò)誤理解唾戚，另一個(gè)原因是隨著各個(gè)交付團(tuán)隊(duì)逐步實(shí)現(xiàn)自服務(wù)持續(xù)交付柳洋，這個(gè)專有團(tuán)隊(duì)也有了更高的目標(biāo)：持續(xù)打造和優(yōu)化一個(gè)能夠支持各交付團(tuán)隊(duì)快速交付的平臺(tái)。
當(dāng)時(shí)叹坦，我們首先為團(tuán)隊(duì)定義了新的工作方式：以自服務(wù)膳灶，自動(dòng)化和協(xié)作 作為核心文化，希望團(tuán)隊(duì)通過提供便捷的基礎(chǔ)服務(wù)立由，讓交付團(tuán)隊(duì)擁有自動(dòng)化的交付流水線轧钓，并通過更多的溝通協(xié)作，盡可能讓每個(gè)交付團(tuán)隊(duì)都能夠獨(dú)立自主的設(shè)計(jì)锐膜、創(chuàng)建和更改自己的基礎(chǔ)設(shè)施毕箍。然后再根據(jù)各個(gè)交付團(tuán)隊(duì)的實(shí)施情況和結(jié)果來對流程和服務(wù)持續(xù)改進(jìn)。
所以第一件事道盏，我們首先設(shè)計(jì)了一個(gè)高效的持續(xù)交付流水線而柑，讓Platform團(tuán)隊(duì)和交付團(tuán)隊(duì)建立觸點(diǎn)：
如下圖所示，藍(lán)色的基因鏈為交付團(tuán)隊(duì)的持續(xù)交付環(huán)荷逞，紅色的基因鏈為平臺(tái)團(tuán)隊(duì)的持續(xù)交付環(huán)媒咳。兩種團(tuán)隊(duì)以某種低耦合的弱連接進(jìn)行全程協(xié)作，Platform團(tuán)隊(duì)在整個(gè)端到端的交付過程中都要能盡量通過構(gòu)建自動(dòng)化能力來支撐交付團(tuán)隊(duì)能夠快速种远、安全的進(jìn)行持續(xù)集成涩澡、部署等活動(dòng)。這樣的合作方式也給我們提供了優(yōu)化觸點(diǎn)的可能性坠敷，也能夠通過優(yōu)化和改進(jìn)妙同，縮小這個(gè)持續(xù)交付周期，讓交付更高效膝迎。
實(shí)踐過程
下圖是我們?yōu)閳F(tuán)隊(duì)設(shè)計(jì)的持續(xù)交付流水線粥帚，目的是能讓Platform團(tuán)隊(duì)和交付團(tuán)隊(duì)之間的觸點(diǎn)能夠被融入到持續(xù)交付流水線中，并且以基礎(chǔ)設(shè)施代碼作為協(xié)同媒介限次，通過自動(dòng)化的方式實(shí)現(xiàn)開發(fā)與運(yùn)維（即基礎(chǔ)設(shè)施與軟件系統(tǒng)）的無縫對接芒涡。
我們來看看我們給持續(xù)交付流水線賦予了哪些能力：
- 站在交付團(tuán)隊(duì)的視角，我們決定將基礎(chǔ)設(shè)施構(gòu)建卖漫，流水線構(gòu)建费尽，部署等活動(dòng)都代碼化，與應(yīng)用代碼放在同一個(gè)代碼倉庫中懊亡。
- 交付團(tuán)隊(duì)通過提交我們的基礎(chǔ)設(shè)施代碼到倉庫后依啰，自動(dòng)觸發(fā)持續(xù)交付工具創(chuàng)建或更新流水線乎串。
- 接著會(huì)自動(dòng)觸發(fā)構(gòu)建店枣，靜態(tài)檢查速警，測試覆蓋率校測，代碼規(guī)范驗(yàn)證等任務(wù)鸯两，最終輸出構(gòu)建產(chǎn)物并將構(gòu)建產(chǎn)物推送到倉庫闷旧。
- 然后會(huì)根據(jù)交付團(tuán)隊(duì)對基礎(chǔ)設(shè)施和環(huán)境的定義到當(dāng)前要部署的網(wǎng)絡(luò)環(huán)境中去創(chuàng)建或更改虛擬機(jī)、網(wǎng)絡(luò)钧唐、存儲(chǔ)方式等
- 最后忙灼，當(dāng)基礎(chǔ)設(shè)施創(chuàng)建成功以后，就會(huì)去倉庫下載指定版本的構(gòu)建產(chǎn)物進(jìn)行最終的部署活動(dòng)钝侠。
但需要注意的是：
- 為了持續(xù)優(yōu)化交付流程该园，我們對開發(fā)的許多活動(dòng)進(jìn)行的數(shù)據(jù)收集和分析，以報(bào)表的形式去分析展示代碼提交頻率帅韧，系統(tǒng)和代碼的質(zhì)量情況里初，缺陷和構(gòu)建情況等，幫助團(tuán)隊(duì)找到自己的瓶頸或問題忽舟。
- 幫助團(tuán)隊(duì)能夠?qū)崟r(shí)監(jiān)控自己應(yīng)用的運(yùn)行狀態(tài)双妨，設(shè)計(jì)和查看不同緯度的日志總匯等。
那我們來看看通過什么技術(shù)可以實(shí)現(xiàn)這樣的持續(xù)交付流程：
我們選擇了一種輕量級(jí)叮阅、低耦合的技術(shù)組合Ansible+Jenkins+AWS刁品。我認(rèn)為其核心是Ansible。
下面我們來看看Ansible可以幫助我們做些什么：
- 創(chuàng)建和更改AWS中的資源
- 自動(dòng)化部署和基礎(chǔ)設(shè)施測試
- 建立開發(fā)與平臺(tái)團(tuán)隊(duì)之間的溝通體系
考慮到基于yaml語法的Ansible配置簡潔且易讀浩姥，所以我們選擇直接用它作為提供給交付團(tuán)隊(duì)的公有DSL模板挑随，利用Ansible Playbook的模塊化思想將開發(fā)團(tuán)隊(duì)的職責(zé)和平臺(tái)團(tuán)隊(duì)的職責(zé)很清晰的分離，平臺(tái)團(tuán)隊(duì)關(guān)注Ansible提供給交付團(tuán)隊(duì)的服務(wù)是否滿足需求和DSL模板是否易用勒叠，而交付團(tuán)隊(duì)只用關(guān)注如何基于公有DSL去定制自己的基礎(chǔ)設(shè)施镀裤，環(huán)境依賴和部署等。
于此同時(shí)也滿足了很多開發(fā)對于Ansible和AWS的興趣和熱情缴饭，更使得之后在交付團(tuán)隊(duì)落地變得更容易暑劝。
接下來通過一個(gè)實(shí)例來看看：
左邊是Platform團(tuán)隊(duì)的倉庫，這個(gè)倉庫里面包含了創(chuàng)建基礎(chǔ)設(shè)施颗搂、環(huán)境配置和部署的實(shí)現(xiàn)担猛。
右邊是交付團(tuán)隊(duì)的倉庫，其中deployment目錄下丢氢，是公有的DSL模板傅联，其中包含多種環(huán)境（開發(fā)、測試疚察、預(yù)生產(chǎn)環(huán)境等的獨(dú)立配置）蒸走，以及一套基于DSL的代碼模板，其中包含創(chuàng)建基礎(chǔ)設(shè)施和部署應(yīng)用這兩部分DSL代碼模板貌嫡。
接下來比驻，我們來看看它們配合與集成的方式：
他們會(huì)在持續(xù)集成流水線中被動(dòng)態(tài)組合到一起：
- 在創(chuàng)建基礎(chǔ)設(shè)施和部署的時(shí)候會(huì)分別拉取基礎(chǔ)設(shè)施代碼庫和應(yīng)用代碼庫该溯。
- 此時(shí)應(yīng)用代碼為調(diào)用入庫，公有基礎(chǔ)設(shè)施為功能框架庫别惦，兩者配合狈茉，完成環(huán)境的創(chuàng)建和應(yīng)用部署。
在做微服務(wù)的團(tuán)隊(duì)掸掸，接受度非常高氯庆，能夠快速上手，而且甚至有團(tuán)隊(duì)因?yàn)樽陨淼囊恍┬枨笕鸥叮约喝懸恍〢nsible模塊堤撵，然后向我們發(fā)起pull request。
當(dāng)然羽莺，我們在推廣這套流程的過程中發(fā)現(xiàn)粒督，一些實(shí)踐能夠幫助我們更快速落地：
- DevOps團(tuán)隊(duì)的成員由各交付團(tuán)隊(duì)和原運(yùn)維團(tuán)隊(duì)組成，這樣的組成方式禽翼，能夠保證團(tuán)隊(duì)的視角可以關(guān)注到整個(gè)持續(xù)交付過程的每個(gè)環(huán)節(jié)屠橄。
- 交付團(tuán)隊(duì)成員與DevOps團(tuán)隊(duì)成員定期輪崗制，DevOps小組中的文化（如自動(dòng)化優(yōu)先）可以蔓延開闰挡，讓交付團(tuán)隊(duì)更快適應(yīng)锐墙。
- 結(jié)對、Showcase和培訓(xùn)长酗，主要目的是知識(shí)的傳遞溪北，讓更多地團(tuán)隊(duì)逐步采用新的交付模式，得到更多改進(jìn)中的反饋夺脾。
- 提供給交付團(tuán)隊(duì)的自服務(wù)代碼倉庫對每個(gè)人開放之拨，交付團(tuán)隊(duì)被授權(quán)優(yōu)化、新增基礎(chǔ)設(shè)施咧叭，讓DevOps文化和職責(zé)落地到交付流程中蚀乔。
現(xiàn)在來看，集中式菲茬、審批式吉挣、被動(dòng)響應(yīng)請求的中央運(yùn)維團(tuán)隊(duì)不再是整個(gè)交付流程中的依賴和瓶頸，已基本轉(zhuǎn)向帶自服務(wù)化婉弹、審查式睬魂、主動(dòng)優(yōu)化的去中心化交付團(tuán)隊(duì)：
我們通過技術(shù)驅(qū)動(dòng)改進(jìn)，讓團(tuán)隊(duì)之間的合作方式發(fā)生了巨大改變镀赌，開發(fā)與運(yùn)維之間的那道墻也漸漸消失氯哮，以前被動(dòng)響應(yīng)請求中央運(yùn)維團(tuán)隊(duì)逐步被平臺(tái)團(tuán)隊(duì)所替代，平臺(tái)團(tuán)隊(duì)中一部分人會(huì)負(fù)責(zé)基礎(chǔ)設(shè)施平臺(tái)的發(fā)展商佛，負(fù)責(zé)公有云與企業(yè)內(nèi)部系統(tǒng)的對接喉钢、完善安全姆打、災(zāi)備、提供基礎(chǔ)設(shè)施的自服務(wù)機(jī)制出牧，另一部分人會(huì)為產(chǎn)品團(tuán)隊(duì)提供可定制的工作、平臺(tái)歇盼、并為產(chǎn)品團(tuán)隊(duì)賦能舔痕。這時(shí)交付團(tuán)隊(duì)開始管理自己的環(huán)境、維護(hù)流水線豹缀、負(fù)責(zé)生產(chǎn)環(huán)境變更伯复。
在推廣和落地自服務(wù)持續(xù)交付流程的過程中，我們也遇到了很多遺留系統(tǒng)和復(fù)雜部署應(yīng)用的交付團(tuán)隊(duì)邢笙，他們無法直接對接這套交付流程啸如。
例如有一個(gè)40-50人的團(tuán)隊(duì)，它是基于AEM開發(fā)整個(gè)公司所有的前端門戶氮惯，AEM是Adobe公司的CMS系統(tǒng)叮雳，其安裝和部署很復(fù)雜，以前都是通過手工安裝和拷貝的方式進(jìn)行部署妇汗，而且他們在開發(fā)-》測試-》部署階段可能會(huì)動(dòng)態(tài)擴(kuò)張多套環(huán)境來支持帘不，且每次代碼變更的提交都會(huì)對已經(jīng)安裝的AEM進(jìn)行修改、配置杨箭、重啟等操作寞焙。
整個(gè)開發(fā)和測試流程都很復(fù)雜，而且效率很低互婿，出現(xiàn)問題和故障的風(fēng)險(xiǎn)也很大捣郊，如果我們直接利用Ansible把AEM的安裝和部署過程都自動(dòng)化，由于AEM本身部署的復(fù)雜性慈参，可以預(yù)見以后這部分更新和維護(hù)的工作還是很難交由交付團(tuán)隊(duì)自治呛牲。所以我們第一步要做的就是為其設(shè)計(jì)新的持續(xù)交付流水線，然后在這個(gè)流程中去定義和識(shí)別兩個(gè)團(tuán)隊(duì)的職責(zé)和關(guān)注重心驮配，最后再通過打造高效的自服務(wù)使整個(gè)交付流程得到改進(jìn)侈净。
首先我們根據(jù)校服團(tuán)隊(duì)提交變更的平率，從低到高依次定義了三條持續(xù)集成流水線(如下圖)：
- 創(chuàng)建和測試基礎(chǔ)設(shè)施資源
- 配置基礎(chǔ)設(shè)施資源和環(huán)境
- 部署應(yīng)用程
因?yàn)锳EM安裝和更新很復(fù)雜僧凤，所以我們引入了鏡像技術(shù)畜侦。基礎(chǔ)設(shè)施和基礎(chǔ)設(shè)施配置兩條流水線的產(chǎn)物為一個(gè)image躯保，應(yīng)用流水線在部署階段會(huì)去檢查是否存在新的環(huán)境鏡像旋膳，如果存在，就會(huì)基于快速創(chuàng)建一個(gè)新的AEM環(huán)境途事，然后進(jìn)行應(yīng)用代碼的部署验懊。
通過新的自動(dòng)化持續(xù)交付流水線大大加速了AEM團(tuán)隊(duì)的開發(fā)和測試速度擅羞，也使得整個(gè)環(huán)境更加可控和易維護(hù)。對于交付團(tuán)隊(duì)來說义图，他們可以自己去維護(hù)包括基礎(chǔ)設(shè)施减俏、環(huán)境變更和應(yīng)用部署等全生命周期交付活動(dòng)。對于Platform團(tuán)隊(duì)來說碱工，只用去考慮鏡像的生命周期管理宙址，如何去優(yōu)化鏡像的創(chuàng)建速度等幢踏，這些可以幫助到更多其它團(tuán)隊(duì)解決類似問題的領(lǐng)域。對于這種特殊情況，我們盡管引入很多與大多數(shù)團(tuán)隊(duì)不同的交付流程和技術(shù)厦瓢，但所有的工作和優(yōu)化都是基于之前打造的自服務(wù)持續(xù)交付流程杀捻、協(xié)議和工具平臺(tái)之上的古沥，保證了不同的交付團(tuán)隊(duì)與Platform的配合方式的一致性彩扔。
實(shí)踐啟示
通過在大量交付團(tuán)隊(duì)落地基于自服務(wù)的持續(xù)交付流程，兩種團(tuán)隊(duì)的職責(zé)更加清晰了：
所有好的實(shí)踐都必須考慮規(guī)恼舯裕化的問題春弥，如果無法大規(guī)模的被接受和落地，再好的實(shí)踐也沒用叠荠。對于咱們這個(gè)轉(zhuǎn)型的過程惕稻，我也給出一個(gè)套路：（如下圖）
有了套路，接下來總結(jié)一下應(yīng)用這個(gè)套路進(jìn)行DevOps轉(zhuǎn)型過程中的一些經(jīng)驗(yàn)和思考：
- 易用的通用DSL模板設(shè)計(jì)蝙叛，提供交付與Platform團(tuán)隊(duì)統(tǒng)一的DSL模板(build and update anything)俺祠。
- 構(gòu)建通用持續(xù)交付流水框架，提供給交付團(tuán)隊(duì)定制化流水線的能力借帘，使流水線主要關(guān)注點(diǎn)始終在產(chǎn)品的成功交付蜘渣。
- 以技術(shù)驅(qū)動(dòng)DevOps文化大面積傳播，讓Platform團(tuán)隊(duì)成員走入交付團(tuán)隊(duì)肺然，協(xié)作改進(jìn)蔫缸、知識(shí)傳遞，確保實(shí)踐落地际起。
- 將一切自動(dòng)化拾碌、自服務(wù)化。交付團(tuán)隊(duì)?wèi)?yīng)該被授權(quán)優(yōu)化街望、新增基礎(chǔ)設(shè)施服務(wù)校翔，讓DevOps能力和職責(zé)在交付團(tuán)隊(duì)落地生根。
最后灾前，我提取了5點(diǎn)對我們來說非常重要的策略或是推進(jìn)方法：
- 小步快跑防症，在有大方向的基礎(chǔ)上，需要將每一步改變都設(shè)計(jì)得足夠小，這樣才能足夠快的去改進(jìn)蔫敲。
- 交付團(tuán)隊(duì)賦能饲嗽，給每個(gè)人都留一扇門，在他意識(shí)到要做些事情的時(shí)候奈嘿，可以很快付諸行動(dòng)貌虾。
- 逐步用基礎(chǔ)設(shè)施自服務(wù)化替代運(yùn)維部門的審批流程。
建立持續(xù)反饋和改進(jìn)機(jī)制裙犹。 - 以DevOps團(tuán)隊(duì)為杠桿尽狠，撬動(dòng)更大范圍自服務(wù)交付。
