2018-03-20 10:14:03 來源： OfficialDevOpsDays
正好去年底我看到了Jez Humble在2017年DevOpsDays美國(guó)西雅圖站的演講《Continuous Delivery Sounds Great But It Won’t Work Here》。演講中提到了一些很棒觀點(diǎn)，貫穿的幾個(gè)案例故事也非常有啟發(fā)，于是筆者結(jié)合自己的一些經(jīng)驗(yàn)和思考，整理本文分享跟大家。
Jez Humble一直是我非常關(guān)注的大神級(jí)人物，他在2010年的著作《持續(xù)交付》對(duì)我影響巨大，后來他參與合著的《Lean Enterprise》、《DevOps Handbook》也絕對(duì)是DevOps這一領(lǐng)域的必讀書籍。
DevOps體系中包含很多關(guān)鍵實(shí)踐，而持續(xù)交付可以說是其中相當(dāng)核心的一個(gè)環(huán)節(jié)，也是從工程角度支撐DevOps實(shí)現(xiàn)的關(guān)鍵使能者。
Jez對(duì)持續(xù)交付的定義是："The ability to get changes—features, configuration changes, bug fixes, experiments—into production or into the hands of users safely and quickly in a sustainable way."
也就是說，持續(xù)交付是能夠把所有類型的變更（特性、配置變更、缺陷修復(fù)、實(shí)驗(yàn)等）以安全、快速和可持續(xù)的方式，交付到生產(chǎn)環(huán)境或用戶手中的能力。做的好的話，也許你的項(xiàng)目就能進(jìn)展的一帆風(fēng)順，不用每次為了合并代碼、解決沖突搞到大半夜，不用焦頭爛額地為了一次發(fā)布熬個(gè)通宵，也不用接下來的整個(gè)周末加班只為了解決發(fā)布后的線上問題。一切交付和發(fā)布都是那么平常，你再也不用到處救火，生活和工作終于可以平衡了。
聽起來不錯(cuò)是吧？嗯，我也同意，這個(gè)想法是極好的。但你可能會(huì)說，這在我的企業(yè)中沒法實(shí)現(xiàn)！通常大家反饋無(wú)法實(shí)施DevOps或持續(xù)交付的原因有以下幾點(diǎn)：
我們受到嚴(yán)格監(jiān)管，沒法這么做
我們不是開發(fā)網(wǎng)站，沒法用互聯(lián)網(wǎng)的方法
我們有太多遺留系統(tǒng)，歷史包袱太重
我們的員工太笨了，新方法玩兒不轉(zhuǎn)
Jez也很犀利，他說真實(shí)的原因無(wú)外乎兩條（臺(tái)下一片掌聲）：
我們的架構(gòu)太糟糕了
我們的文化太糟糕了
接下來，讓我們依次來分析一下以上大家反饋的幾點(diǎn)原因，看看DevOps是否真的就無(wú)法開展，并通過一些案例故事幫助大家理解。
在高度監(jiān)管的環(huán)境中，反對(duì)DevOps或持續(xù)交付的聲音有兩種：
使用DevOps的方式可能有風(fēng)險(xiǎn)
監(jiān)管要求與DevOps實(shí)踐相沖突
對(duì)于第一種說法，其實(shí)直接與DevOps或持續(xù)交付運(yùn)動(dòng)的初衷相矛盾。因?yàn)槲覀兲岢乃蟹椒ㄅc實(shí)踐，目標(biāo)之一就是要降低發(fā)布風(fēng)險(xiǎn)。而且統(tǒng)計(jì)數(shù)據(jù)也給出了很好的證據(jù)，連續(xù)四年發(fā)布的《DevOps現(xiàn)狀調(diào)查報(bào)告》顯示，高績(jī)效企業(yè)可以同時(shí)擁有高級(jí)別的吞吐量和穩(wěn)定性，也就是質(zhì)量和效率是可以兼得的。
DevOps或持續(xù)交付使用了大量的自動(dòng)化編譯、自動(dòng)化測(cè)試、自動(dòng)化部署（發(fā)布）等技術(shù)，這與傳統(tǒng)做法中通過大量規(guī)范文檔、檢查單、評(píng)審會(huì)的方式減緩風(fēng)險(xiǎn)不同，但這并不能說明DevOps的模式中風(fēng)險(xiǎn)就沒有控制，反而DevOps這種持續(xù)和自動(dòng)化的、內(nèi)建質(zhì)量的實(shí)踐，其風(fēng)險(xiǎn)控制效果可能更好、效率更高。
對(duì)于第二種說法，企業(yè)中很多為了滿足監(jiān)管要求的設(shè)計(jì)，比如低頻和嚴(yán)格審批的發(fā)布、按階段切分軟件交付生命周期、職責(zé)權(quán)限分離等等，看上去是無(wú)法進(jìn)行快速交付的。而實(shí)際上，大家都聽說過亞馬遜的案例，在2011年就實(shí)現(xiàn)了平均每11.6秒就進(jìn)行一次生產(chǎn)發(fā)布，每個(gè)小時(shí)最多有1079次部署（整個(gè)生產(chǎn)環(huán)境累計(jì)值）。
但亞馬遜實(shí)際上是一個(gè)受到很多監(jiān)管要求限制的企業(yè)，比如著名的薩班斯-奧克斯利法案會(huì)計(jì)實(shí)踐（Sarbanes-Oxley Act regulating accounting practices）以及支付卡行業(yè)數(shù)據(jù)安全標(biāo)準(zhǔn)（PCI DSS）。
與亞馬遜類似，Etsy是一個(gè)DevOps領(lǐng)域常被提及的企業(yè)。Etsy主要業(yè)務(wù)是在線銷售手工制品。Etsy追求創(chuàng)新速度，在其高度信任的文化中，開發(fā)人員經(jīng)常自己將變更通過自動(dòng)化的方式部署到生產(chǎn)環(huán)境上。
然而，由于Etsy要處理信用卡交易，所以必須遵守支付卡行業(yè)數(shù)據(jù)安全標(biāo)準(zhǔn)（PCI DSS），這里面詳細(xì)規(guī)定了持卡人數(shù)據(jù)環(huán)境必須在物理上隔離，而且涉及到持卡人數(shù)據(jù)的人，必須要有職責(zé)分離，對(duì)權(quán)限也有非常嚴(yán)格的控制。那么Etsy是如何同時(shí)滿足合規(guī)要求和快速發(fā)布需求的呢？主要有以下幾點(diǎn)：
最小化合規(guī)要求的影響范圍，區(qū)別對(duì)待。在系統(tǒng)架構(gòu)設(shè)計(jì)上將有關(guān)不同合規(guī)需求的關(guān)注點(diǎn)分離。將安全標(biāo)準(zhǔn)所約束的范圍限制到一個(gè)隔離的區(qū)域，區(qū)別對(duì)待。比如將涉及到應(yīng)用和基礎(chǔ)設(shè)施與其他環(huán)境分離，并由一個(gè)跨職能團(tuán)隊(duì)開發(fā)和運(yùn)營(yíng)，而不擴(kuò)展到其他團(tuán)隊(duì)。
建立機(jī)制來限制合規(guī)框架與法規(guī)對(duì)組織的沖擊。比如安全標(biāo)準(zhǔn)強(qiáng)制要求職責(zé)分離，但并不妨礙這個(gè)團(tuán)隊(duì)在同一地點(diǎn)一起工作。代碼提交到部署過程全部是自動(dòng)化的，而審批活動(dòng)都在本地完成，這樣就可以消除大量的瓶頸和延遲。
采用補(bǔ)償性控制。理解和尊重法律法規(guī)非常重要，但同時(shí)我們也需要認(rèn)識(shí)到有很多變通的方式可以實(shí)現(xiàn)相同的目標(biāo)。比如Etsy就使用部署流水線的方式，提供了一種有效的補(bǔ)償性控制，實(shí)際上是對(duì)職責(zé)分離提供了一種替代方案。
美國(guó)聯(lián)邦政府的IT項(xiàng)目也是被高度監(jiān)管的，與發(fā)布和信息系統(tǒng)運(yùn)行相關(guān)的法律法規(guī)有超過4,000頁(yè)，一個(gè)新系統(tǒng)上線通常需要花費(fèi)數(shù)月進(jìn)行文檔準(zhǔn)備和測(cè)試。大多數(shù)工作的實(shí)施、文檔化和測(cè)試都需要在聯(lián)邦政府風(fēng)險(xiǎn)管理框架的管理下進(jìn)行。一個(gè)中等影響程度的系統(tǒng)，至少有325個(gè)控制項(xiàng)需要實(shí)施。
美國(guó)聯(lián)邦政府中有一個(gè)數(shù)字化服務(wù)機(jī)構(gòu)，他們的任務(wù)就是通過技術(shù)改進(jìn)政府服務(wù)。他們使用開源組件（包括Cloud Foundry）在AWS上搭建了一個(gè)名為Cloud.gov的PaaS平臺(tái)，接管了應(yīng)用開發(fā)、服務(wù)生命周期管理、流量控制、日志、監(jiān)控和報(bào)警等功能。
Cloud.gov平臺(tái)應(yīng)用持續(xù)交付的方式，所有相關(guān)代碼和配置都存儲(chǔ)在Git倉(cāng)庫(kù)中，部署過程全部自動(dòng)化。Cloud.gov平臺(tái)的建設(shè)對(duì)項(xiàng)目交付的效率提升意義重大，因?yàn)樗幚砹?25個(gè)控制項(xiàng)中的269個(gè)，極大降低了滿足合規(guī)所消耗的時(shí)間成本。
有很多DevOps的成功案例都是來自于互聯(lián)網(wǎng)公司，但我們想說的是，其他類型的應(yīng)用系統(tǒng)同樣可以。DevOps與持續(xù)交付的實(shí)踐可以成功運(yùn)用到軟件系統(tǒng)的各種領(lǐng)域中，有很多組織在構(gòu)建移動(dòng)App或嵌入式系統(tǒng)時(shí)也可以做的很好。
這里分析一個(gè)惠普LaserJet固件團(tuán)隊(duì)的案例。這是一個(gè)嵌入式軟件開發(fā)團(tuán)隊(duì)，負(fù)責(zé)開發(fā)他們所有的打印機(jī)、掃描儀和多功能設(shè)備中的固件。團(tuán)隊(duì)由分布在美國(guó)、巴西和印度的400多人構(gòu)成。他們遇到的問題就是：進(jìn)度太慢，多年來一直是新產(chǎn)品發(fā)布的瓶頸，無(wú)法按時(shí)交付新特性，有時(shí)6~12個(gè)月才能交付新需求。
從上圖數(shù)據(jù)可以看出，他們工作中有大量不增值的活動(dòng)，比如在分支之間移植代碼、詳細(xì)的前期規(guī)劃，以及由于質(zhì)量問題導(dǎo)致的大量支持性工作。真正用于”價(jià)值需求”（而非”故障需求”）的工作才占團(tuán)隊(duì)成本的5%。于是團(tuán)隊(duì)進(jìn)行了大膽的改進(jìn)工作：
引入持續(xù)集成實(shí)踐；
大量投資自動(dòng)化測(cè)試；
創(chuàng)建一套硬件模擬器以便測(cè)試可以在虛擬平臺(tái)上運(yùn)行；
在開發(fā)人員工作臺(tái)上可以重現(xiàn)失敗的測(cè)試；
在接下來的三年時(shí)間力，他們創(chuàng)建了幾千個(gè)自動(dòng)化測(cè)試用例，并且建立了完善的持續(xù)部署流水線體系。
如上圖所示，部署流水線共分為四級(jí)（L1到L4），根據(jù)自動(dòng)化測(cè)試結(jié)果遞次晉級(jí)。
不同國(guó)家的開發(fā)者首先把代碼提交到各自獨(dú)立的Github倉(cāng)庫(kù)中，然后由持續(xù)集成系統(tǒng)運(yùn)行L1級(jí)自動(dòng)化測(cè)試；
如果測(cè)試失敗，開發(fā)人員會(huì)得到通知，在本地工作臺(tái)上進(jìn)行Debug；
如果測(cè)試通過，這些滿足了質(zhì)量要求的代碼才能更被合并到主干，并進(jìn)行第二階段的L2級(jí)自動(dòng)化測(cè)試；
以此類推，流水線逐步晉級(jí)到L3級(jí)（每天六次）、L4級(jí)（每天一次），進(jìn)行完整的自動(dòng)化回歸測(cè)試。
這樣，開發(fā)人員在一天內(nèi)就能得到代碼問題的有效反饋，擺脫了原來在發(fā)布前花費(fèi)六周時(shí)間進(jìn)行集成測(cè)試才能發(fā)現(xiàn)問題的困境。這套系統(tǒng)固化了小批量、內(nèi)建質(zhì)量的工作方式。
使用這種方式，這個(gè)擁有1000萬(wàn)行的代碼庫(kù)，每天大致有100次代碼提交，而每天都能產(chǎn)出10到15個(gè)通過L1級(jí)別測(cè)試的可用構(gòu)建，極大的增強(qiáng)了交付的能力。
通過實(shí)施持續(xù)交付、完備的自動(dòng)化測(cè)試和更加敏捷的項(xiàng)目管理方法后，團(tuán)隊(duì)的軟件交付能力得到了很大提升。整體開發(fā)成本降低了約40%，能夠用于創(chuàng)新的資源投入增加了8倍。
這個(gè)案例給我們的啟示中最重要的一點(diǎn)是，只有在團(tuán)隊(duì)大量并持續(xù)投入自動(dòng)化測(cè)試和持續(xù)集成的基礎(chǔ)上，才有可能有如此巨大的成本節(jié)約和生產(chǎn)率提升。
就像Jez說的，”Lean is not about cutting cost, it’s about investing to remove waste, and in the medium and long term, this drive down transaction cost of making changes, so you can move faster!”
很多組織把業(yè)務(wù)關(guān)鍵數(shù)據(jù)保存在十多年前設(shè)計(jì)的系統(tǒng)中，這類系統(tǒng)經(jīng)常被稱為遺留系統(tǒng)。我們要說明的是，DevOps與持續(xù)交付的原則和實(shí)踐同樣也可以應(yīng)用到這類系統(tǒng)中。
澳洲最大的保險(xiǎn)公司Suncorp成功在大型機(jī)系統(tǒng)上實(shí)現(xiàn)持續(xù)交付。他們?cè)谧詣?dòng)化測(cè)試框架上進(jìn)行了大量投入來支持快速的系統(tǒng)開發(fā)、維護(hù)和升級(jí)。針對(duì)使用COBOL的大型機(jī)系統(tǒng)開發(fā)的自動(dòng)化測(cè)試框架，可以對(duì)核心功能進(jìn)行UAT測(cè)試，既支持功能測(cè)試，也支持系統(tǒng)間的集成測(cè)試，能夠覆蓋500到1000個(gè)業(yè)務(wù)邏輯。
一旦端到端的業(yè)務(wù)場(chǎng)景中通過測(cè)試發(fā)現(xiàn)缺陷，必須要在數(shù)小時(shí)或數(shù)天內(nèi)給出對(duì)策并解決，而不是像很多大型企業(yè)通常需要數(shù)周的時(shí)間。下圖是大型機(jī)”綠屏”系統(tǒng)進(jìn)行自動(dòng)化測(cè)試的截圖，出乎意料的是，執(zhí)行速度非?？欤üP者在數(shù)年前也開發(fā)過類似的自動(dòng)化測(cè)試框架）。
很多企業(yè)工作在非常復(fù)雜的環(huán)境中，有成百上千個(gè)系統(tǒng)或服務(wù)需要管理。最大的障礙其實(shí)并不是工作在大型機(jī)系統(tǒng)上，而是進(jìn)行變更的時(shí)候需要一次性部署整個(gè)系統(tǒng)的多個(gè)關(guān)聯(lián)系統(tǒng)。這是實(shí)施DevOps和持續(xù)交付在架構(gòu)上面臨的最大挑戰(zhàn)。
在每年的《DevOps現(xiàn)狀調(diào)查報(bào)告》中，都會(huì)涉及這樣的問題：你能夠獨(dú)立于所依賴的應(yīng)用和服務(wù)進(jìn)行部署或發(fā)布么？你能脫離集成測(cè)試環(huán)境進(jìn)行測(cè)試么？這些就是你需要考慮的架構(gòu)上的約束，在架構(gòu)層面除了經(jīng)?？紤]的可靠性、可擴(kuò)展性、安全性、性能等特性之外，我們需要額外關(guān)注可測(cè)試性和可部署性。
架構(gòu)的可測(cè)試性。開發(fā)可以在他們自己的工作站上運(yùn)行自動(dòng)化測(cè)試發(fā)現(xiàn)大部分缺陷（有關(guān)聯(lián)系統(tǒng)時(shí)可利用Mock），而不需要依賴在復(fù)雜的、集成的環(huán)境上運(yùn)行很多驗(yàn)收和回歸測(cè)試。
架構(gòu)的可部署性。部署特定的系統(tǒng)或服務(wù)可以獨(dú)立、自動(dòng)化的執(zhí)行，不需要進(jìn)行復(fù)雜的編排，這樣的架構(gòu)可以幫助我們實(shí)現(xiàn)零停機(jī)發(fā)布或最小化服務(wù)不可用時(shí)長(zhǎng)。
實(shí)現(xiàn)可測(cè)試性和可部署性，可以從建立產(chǎn)品和服務(wù)的組件化，高度封裝和相互解耦的架構(gòu)開始。為了實(shí)現(xiàn)這個(gè)目標(biāo)，創(chuàng)建版本化的API并實(shí)現(xiàn)向下兼容是非常值得投資的。雖然這樣增加了系統(tǒng)的復(fù)雜度，但是所帶來的部署靈活性的回報(bào)會(huì)數(shù)倍地高于投入成本。
當(dāng)然，現(xiàn)實(shí)世界中很多組織面臨的情況，就是有大量的遺留系統(tǒng)沒有實(shí)現(xiàn)上面所述的可測(cè)試性和可部署性。雖然從短期看，我們可以通過更好的管理、加強(qiáng)協(xié)作解決其中的部分問題，但是中長(zhǎng)期推薦的方案是漸進(jìn)式地對(duì)系統(tǒng)架構(gòu)進(jìn)行重構(gòu)，有時(shí)也描述為”演進(jìn)式架構(gòu)”。
一種演進(jìn)式架構(gòu)的模式被稱為“絞殺者模式”，單體架逐步被很多遵守SOA原則的組件所替換掉，隨著時(shí)間的發(fā)展，越來越多的新功能使用新的架構(gòu)實(shí)現(xiàn)，逐步把老的架構(gòu)替換和”絞殺”。下圖展示了這一模式，更多細(xì)節(jié)可以參考Matin Fowler的博客文章。
關(guān)于絞殺者模式，在《DevOps Handbook》中也提到一些案例可以參考，篇幅原因，我們今天暫不展開。
組織轉(zhuǎn)型中的一個(gè)有意思的案例是美國(guó)新聯(lián)和汽車制造公司（NUMMI）的例子。
NUMMI是通用汽車和豐田的合資子公司，也是加州唯一的汽車制造工廠。在1980年代，這家工廠還屬于通用汽車，當(dāng)時(shí)這個(gè)工廠生產(chǎn)汽車的質(zhì)量是通用汽車中最差的，當(dāng)時(shí)勞工關(guān)系已經(jīng)崩潰，工人們一邊工作一邊酗酒和賭博。所以通用汽車在1982年關(guān)閉了這個(gè)工廠。
但恰逢豐田希望在美國(guó)建立一家汽車工廠，于是與通用公司合資，重新雇傭原來的工人，并把他們送到日本的豐田城學(xué)習(xí)豐田管理系統(tǒng)（TPS）。令人吃驚的是，短短三個(gè)月的時(shí)間，NUMMI就生產(chǎn)出了與豐田一樣的質(zhì)量幾乎完美的汽車，而成本卻比之前低的多。
這個(gè)案例帶給我們啟示的是，員工本身也許并不是問題，工作的方式和系統(tǒng)才是問題。另外一個(gè)業(yè)界的故事，曾擔(dān)任Netflix云架構(gòu)師的Adrian Cockcroft，經(jīng)常被500強(qiáng)公司問起Netflix如何遷移到云，以及這些能力超強(qiáng)的員工是從哪里招聘到的？他的回答非常簡(jiǎn)單：”我是從你們公司招過來的!”
豐田生產(chǎn)系統(tǒng)之所以成功，它是把”質(zhì)量?jī)?nèi)建于產(chǎn)品“作為最高優(yōu)先級(jí)，發(fā)現(xiàn)問題必須馬上解決，而且必須對(duì)系統(tǒng)進(jìn)行改進(jìn)，努力確保同樣的問題不會(huì)再次發(fā)生。比如他們使用著名的”安燈拉繩”機(jī)制，當(dāng)出現(xiàn)問題時(shí)，呼叫管理者過來協(xié)助解決問題，如果問題短時(shí)間無(wú)法解決掉，工人可以停掉整條生產(chǎn)線，直到問題被最終解決。之后，團(tuán)隊(duì)會(huì)進(jìn)行實(shí)驗(yàn)并采取改進(jìn)措施，防止問題再次發(fā)生。這種理念和方式與當(dāng)時(shí)歐美生產(chǎn)制造管理的那種把工作分解為獨(dú)立任務(wù)，然后按照清晰劃分的職能”各管一攤”的方式完全不同。
后來通用汽車想把NUMMI取得的成功復(fù)制到其他工廠，甚至把NUMMI工廠的每一個(gè)角落拍下來精確復(fù)制到其他地方。但結(jié)果是，他們建立起了一座帶有”安燈拉繩”裝置，但卻沒有人去拉的工廠。因?yàn)檫@里對(duì)管理者的激勵(lì)因素是汽車下線的速度（無(wú)論是否可用）。多年后的2009年，通用汽車破產(chǎn)并退出了NUMMI，豐田隨后于2010年關(guān)閉了該工廠。
不過故事的精彩還在繼續(xù)，后來一家公司在工廠的原址上進(jìn)行改造并繼續(xù)生產(chǎn)汽車，也許你已經(jīng)猜到了，這家公司的名字叫做特斯拉。 特斯拉把這個(gè)工廠重新命名為Tesla Factory，生產(chǎn)著名的Tesla Model S轎車。
NUMMI的案例告訴我們，一個(gè)已經(jīng)垮掉的組織在新的領(lǐng)導(dǎo)力和管理范式下得到了再造。要改變文化，首先要去改變的是行動(dòng)方式，而不僅僅是思維方式，文化的改變是行為改變的結(jié)果。試圖改變組織的文化時(shí)，首先需要清晰定義我們期望的行為是怎樣的，接下來提供必要的培訓(xùn)，然后采取措施來強(qiáng)化這些行為。
以上的案例是關(guān)于精益生產(chǎn)的，其實(shí)其中很多實(shí)踐可以直接映射到軟件研發(fā)和交付領(lǐng)域。比如我們經(jīng)常說的持續(xù)集成是否做到位了，有三個(gè)問題可以衡量：
團(tuán)隊(duì)所有的開發(fā)人員是不是每天至少一次將代碼提交到主干？
每次提交到主干的變更是否都會(huì)觸發(fā)一次構(gòu)建過程，包括執(zhí)行自動(dòng)化測(cè)試來發(fā)現(xiàn)回歸問題？
當(dāng)構(gòu)建和測(cè)試過程失敗時(shí)，團(tuán)隊(duì)是否停下手頭工作立即處理，然后在數(shù)分鐘內(nèi)解決掉問題？
這三個(gè)問題直接映射了精益生產(chǎn)中關(guān)于減小批量、內(nèi)建質(zhì)量和安燈拉繩的實(shí)踐，當(dāng)你要求團(tuán)隊(duì)遵循這些實(shí)踐，提供培訓(xùn)并反復(fù)強(qiáng)化這些行為時(shí)，文化的逐步轉(zhuǎn)變就是可期待的了。
本文通過對(duì)實(shí)施DevOps或持續(xù)交付持懷疑態(tài)度的四個(gè)常見問題及其本質(zhì)進(jìn)行了分析，并貫穿了五個(gè)案例故事輔助說明。最終想表達(dá)的觀點(diǎn)是，DevOps和持續(xù)交付在各種場(chǎng)合下都能起到積極作用，只要保持對(duì)改進(jìn)的堅(jiān)定信心，以及最佳實(shí)踐的正確牽引，實(shí)施持續(xù)改善，相信都會(huì)對(duì)IT效能和組織績(jī)效產(chǎn)生巨大的正面影響！《DevOps現(xiàn)狀調(diào)查報(bào)告》中的數(shù)據(jù)也充分證明了這一點(diǎn)。
在高度監(jiān)管的環(huán)境中實(shí)施DevOps：最小化合規(guī)要求的影響范圍（關(guān)注點(diǎn)分離）、建立機(jī)制來限制合規(guī)框架與法規(guī)對(duì)組織的沖擊、采用補(bǔ)償性控制；
DevOps同樣適用于非Web類應(yīng)用：小批量、內(nèi)建質(zhì)量的工作方式，持續(xù)集成實(shí)踐、投資自動(dòng)化測(cè)試、自動(dòng)化部署與發(fā)布；
在遺留系統(tǒng)的基礎(chǔ)上實(shí)施DevOps：增強(qiáng)架構(gòu)的可測(cè)試性和可部署性，從建立系統(tǒng)和服務(wù)的組件化，高度封裝和相互解耦的架構(gòu)開始。架構(gòu)需要持續(xù)演進(jìn)，可采用絞殺者模式；
實(shí)施DevOps強(qiáng)調(diào)發(fā)展員工的能力及文化的因素：員工本身也許并不是問題，工作的方式和系統(tǒng)才是問題。要改變文化，首先要去改變的是行動(dòng)方式，而不僅僅是思維方式，文化的改變是行為改變的結(jié)果。
感謝你看到文章的最后，有這樣一句話：
Don’t Fight Stupid, Make More Awesome，送給專注于通過DevOps等優(yōu)秀的軟件工程實(shí)踐，追求卓越產(chǎn)品和軟件能力的我們，大家共勉 :-)
?
免責(zé)聲明：本網(wǎng)站（http://www.www.gypb.net/）內(nèi)容主要來自原創(chuàng)、合作媒體供稿和第三方投稿，凡在本網(wǎng)站出現(xiàn)的信息，均僅供參考。本網(wǎng)站將盡力確保所提供信息的準(zhǔn)確性及可靠性，但不保證有關(guān)資料的準(zhǔn)確性及可靠性，讀者在使用前請(qǐng)進(jìn)一步核實(shí)，并對(duì)任何自主決定的行為負(fù)責(zé)。本網(wǎng)站對(duì)有關(guān)資料所引致的錯(cuò)誤、不確或遺漏，概不負(fù)任何法律責(zé)任。
本網(wǎng)站刊載的所有內(nèi)容（包括但不僅限文字、圖片、LOGO、音頻、視頻、軟件、程序等）版權(quán)歸原作者所有。任何單位或個(gè)人認(rèn)為本網(wǎng)站中的內(nèi)容可能涉嫌侵犯其知識(shí)產(chǎn)權(quán)或存在不實(shí)內(nèi)容時(shí)，請(qǐng)及時(shí)通知本站，予以刪除。
搶沙發(fā)
