部門
2016年到2017年有比較明顯的變化度帮，而從2017年到2018年 devops 所占的比例變化不大唧领。
行業(yè)
從2016年開始到2019年焰手，一直都是技術(shù)行業(yè)更多一些逆瑞。
SDO performance 衡量軟件交付和運(yùn)營性能（software delivery and operational performance）
SDO performance能夠帶來的一些優(yōu)勢(shì)荠藤，這些包括提高盈利能力，生產(chǎn)率获高，市場(chǎng)份額哈肖，客戶滿意度以及實(shí)現(xiàn)組織的使命目標(biāo)能力。
SDO performance 四個(gè)指標(biāo)
在DevOps現(xiàn)狀報(bào)告中念秧，證明了組織績效和軟件交付效能之間存在直接關(guān)聯(lián)淤井。只需要四個(gè)關(guān)鍵指標(biāo)就能區(qū)分低績效、中績效和高績效人員：前置時(shí)間摊趾、部署頻率币狠、平均修復(fù)時(shí)間(MTTR)和變更失敗率。通過這四個(gè)指標(biāo)的分析砾层，可幫助領(lǐng)導(dǎo)和團(tuán)隊(duì)改進(jìn)重要的環(huán)節(jié)漩绵。實(shí)施構(gòu)建流水線可以幫助可視化四個(gè)關(guān)鍵指標(biāo)(Four key metrics)，使得軟件交付價(jià)值流可見肛炮。
這四個(gè)指標(biāo)在20期的技術(shù)雷達(dá)中也有體現(xiàn)止吐，技術(shù)維度-采納level宝踪。
速度方面：
-
部署頻率 ：代碼部署到線上的頻率。
性能最高的每年1,460個(gè)部署（4/天x 365天）到性能低的每年7個(gè)部署碍扔。最高的是最低的208倍瘩燥。
image.png -
lead time：代碼從提交到release所花的時(shí)間。
最快的24小時(shí)內(nèi)不同，而最慢的為2555小時(shí)颤芬， 之間差距106倍。和往年對(duì)比套鹅，差距變小的原因可能是因?yàn)閘ead time從不到一個(gè)小時(shí)增加到一個(gè)小時(shí)到一天之間。( 近年來越來越流行的重量級(jí)代碼審查和批準(zhǔn)過程)
image.png
穩(wěn)定性方面：
-
恢復(fù)時(shí)間Mean time to restore（從檢測(cè)到事故到糾正事故所花費(fèi)的時(shí)間）
最快的恢復(fù)時(shí)間少于一小時(shí)汰具，而慢的在一周至一個(gè)月之間卓鹿。統(tǒng)計(jì)下來相差2604倍。
只有40％的受訪者至少每年使用所列一種或多種方法執(zhí)行災(zāi)難恢復(fù)測(cè)試留荔。進(jìn)行災(zāi)難恢復(fù)測(cè)試的組織更有可能具有更高級(jí)別的服務(wù)可用性吟孙，即技術(shù)團(tuán)隊(duì)和組織具有對(duì)所運(yùn)行的軟件產(chǎn)品或服務(wù)作出并保持承諾和主張的能力。
image.png -
更改失敗率（即發(fā)布過程質(zhì)量的度量聚蝶，包含hotfix,rollback等等的頻率）
最低的變更失敗率為0％至15％杰妓，而高的可達(dá)46％至60％。變更失敗率表現(xiàn)好的比差的好七倍碘勉。
image.png
從2016年到2019年巷挥，performance好的比不好的差距如下：
可以看出lead time的差距減小很多，但是恢復(fù)時(shí)間的差距依舊很大验靡。
image.png
Devops一些實(shí)踐
報(bào)告中顯示高效團(tuán)隊(duì)更多的工作量在于新需求的開發(fā)倍宾，而不是在計(jì)劃外的工作和返工、補(bǔ)救安全問題胜嗓、處理最終用戶發(fā)現(xiàn)的缺陷高职、客戶支持等工作上。
如何提高效能呢辞州？
從基礎(chǔ)開始：基本自動(dòng)化（例如版本控制怔锌、自動(dòng)化測(cè)試），Monitor变过，明確的變更批準(zhǔn)流程以及培養(yǎng)良好的文化埃元。 然后確定約束條件來規(guī)劃前進(jìn)的道路， 將資源集中在當(dāng)前的block媚狰，然后進(jìn)行迭代（確定約束條件并選擇下一個(gè)目標(biāo)）亚情。
以下是一些用來提升性能的關(guān)鍵技術(shù)實(shí)踐：
platform as a service （PaaS）
PaaS指的是消費(fèi)者不管理或控制底層云基礎(chǔ)架構(gòu)，包括網(wǎng)絡(luò)哈雏，服務(wù)器楞件，操作系統(tǒng)或存儲(chǔ)衫生，但可以控制已部署的應(yīng)用程序以及應(yīng)用程序托管環(huán)境的配置設(shè)置。
PaaS公司在網(wǎng)上提供各種開發(fā)和分發(fā)應(yīng)用的解決方案土浸，包括網(wǎng)頁應(yīng)用管理罪针，應(yīng)用設(shè)計(jì)，應(yīng)用虛擬主機(jī)黄伊，存儲(chǔ)泪酱，安全以及應(yīng)用開發(fā)協(xié)作工具等。
PaaS的例子有Heroku还最，RedHat OpenShift墓阀，Azure App Service，Google App Engine拓轻， AWS Elastic Beanstalk和Cloud Foundry
cloud-native design practices
云原生應(yīng)用：應(yīng)用系統(tǒng)應(yīng)該與底層物理基礎(chǔ)設(shè)施解耦斯撮；應(yīng)用必須能滿足擴(kuò)展性需求，垂直擴(kuò)展（向上和向下）或水平擴(kuò)展（跨節(jié)點(diǎn)服務(wù)器）扶叉，也就是說云原生應(yīng)用程序必須能夠動(dòng)態(tài)響應(yīng)工作負(fù)載的變化（即彈性）勿锅，并且易于按需部署和管理。
infrastructure as code來管理其云部署
通過版本控制來自動(dòng)復(fù)制或更改環(huán)境狀態(tài)枣氧，而不是手動(dòng)配置基礎(chǔ)結(jié)構(gòu)溢十。這種工作方式適用于云基礎(chǔ)架構(gòu)，在云基礎(chǔ)架構(gòu)中可以通過API設(shè)置和配置資源达吞。
Continuous Testing
連續(xù)測(cè)試包括這些實(shí)踐张弛，并添加了一些重要的補(bǔ)充：
?不斷審查和改進(jìn)測(cè)試套件，以更好地發(fā)現(xiàn)缺陷并控制復(fù)雜性和成本
?允許測(cè)試人員在軟件開發(fā)和交付過程中與開發(fā)人員一起工作
?在整個(gè)交付過程中執(zhí)行手動(dòng)測(cè)試活動(dòng)酪劫，例如探索性測(cè)試乌庶，可用性測(cè)試和驗(yàn)收測(cè)試
?讓開發(fā)人員通過在編寫針對(duì)代碼庫的所有更改的生產(chǎn)代碼之前編寫單元測(cè)試來練習(xí)TDD。
?能夠在不到十分鐘的時(shí)間內(nèi)從本地工作站和CI服務(wù)器上獲得自動(dòng)化測(cè)試的反饋契耿。
2019年報(bào)告中多了 Disaster recovery testing瞒大。
Managing Database Changes
數(shù)據(jù)庫更改通常是執(zhí)行部署時(shí)帶來風(fēng)險(xiǎn)和延遲的主要來源。管理數(shù)據(jù)庫的更改可以避免部署出現(xiàn)問題搪桂。
Loosely coupled architecture透敌，松耦合架構(gòu)對(duì)CD的積極影響。
松耦合架構(gòu)是指交付團(tuán)隊(duì)可以根據(jù)需要獨(dú)立測(cè)試踢械，部署和更改其系統(tǒng)酗电，而無需依賴其他團(tuán)隊(duì)以獲得額外的支持，服務(wù)内列，資源或批準(zhǔn)撵术，來回通信較少。 這使團(tuán)隊(duì)可以快速交付價(jià)值话瞧，但需要更高級(jí)別的編排嫩与。
Clear change process
Code maintainability代碼可維護(hù)性
Continuous integration
Automated testing自動(dòng)化測(cè)試對(duì)CI的積極影響寝姿，CI提高了CD
Deployment automation
Monitoring
Trunk-based development
云平臺(tái)的使用
如何實(shí)施云基礎(chǔ)架構(gòu)至關(guān)重要。云提高了軟件交付性能划滋，利用所有云計(jì)算的基本特征的團(tuán)隊(duì)成為高性能企業(yè)的可能性要高23倍饵筑。
2018年云平臺(tái)的使用情況：
隨著業(yè)務(wù)性質(zhì)的發(fā)展，越來越多的組織正在選擇multi-cloud 多云和hybrid cloud混合云解決方案处坪。 這是因?yàn)檫@些解決方案除了可以提高性能之外根资，還提供了靈活性，控制能力和可用性同窘。2019的報(bào)告對(duì)比2018年玄帕，對(duì)多云和混合云的使用有所增加，但是還不知道這個(gè)現(xiàn)象的意義是什么想邦。
云計(jì)算的五個(gè)基本特征
使用云計(jì)算顯然是按需擴(kuò)展裤纹。利用動(dòng)態(tài)擴(kuò)展的團(tuán)隊(duì)可以使服務(wù)背后的基礎(chǔ)架構(gòu)靈活地響應(yīng)用戶的需求。團(tuán)隊(duì)可以監(jiān)視其服務(wù)并根據(jù)需要自動(dòng)擴(kuò)展其基礎(chǔ)架構(gòu)案狠。
- 按需增長On-demand self-service
消費(fèi)者可以根據(jù)需要自動(dòng)配置計(jì)算資源，而無需提供者進(jìn)行人工干預(yù)钱雷。 - 廣泛的網(wǎng)絡(luò)訪問Broad network access
通過不同的平臺(tái)都可以訪問到骂铁。例如phones, 平板電腦, laptops, and workstations。 - 資源池Resource pooling
提供者資源在多租戶模型中池化罩抗，物理和虛擬資源按需動(dòng)態(tài)分配拉庵。客戶可以指定更高抽象級(jí)別的位置套蒂，例如國家/地區(qū)钞支，州或數(shù)據(jù)中心。 - 快速彈性Rapid elasticity
可以彈性配置和釋放功能操刀，以根據(jù)需要快速向外或向內(nèi)擴(kuò)展烁挟，這似乎是無限的，并且可以隨時(shí)以任何數(shù)量進(jìn)行分配骨坑。 - 實(shí)測(cè)服務(wù)Measured service
云系統(tǒng)會(huì)根據(jù)服務(wù)類型（例如存儲(chǔ)撼嗓，處理，帶寬和活動(dòng)用戶帳戶）自動(dòng)控制欢唾，優(yōu)化和報(bào)告資源使用情況且警。
提高生產(chǎn)率
生產(chǎn)率是指以最小的干擾來完成復(fù)雜，耗時(shí)的任務(wù)的能力礁遣。
文化相關(guān)
高績效團(tuán)隊(duì)具備的文化：信任和心理安全感斑芜，有意義的工作和清晰的角色、計(jì)劃和目標(biāo)認(rèn)知祟霍。這種團(tuán)隊(duì)環(huán)境使成員能夠承擔(dān)有計(jì)劃的和適度的風(fēng)險(xiǎn)杏头，敢于發(fā)表想法并更具創(chuàng)造力盈包。
技術(shù)債管理
技術(shù)債包含腳本、配置管理大州，基礎(chǔ)設(shè)施管理续语。可以通過不斷的重構(gòu)來減少技術(shù)債厦画。
為了減少技術(shù)債就可以思考如何增加code 可維護(hù)性疮茄，如何構(gòu)建松耦合架構(gòu)，如何做Monitor等根暑。
工具
在效能低下的企業(yè)中力试，有著更多的專有軟件，定制化程度高排嫌，但是維護(hù)成本大畸裳。而高效能團(tuán)隊(duì)使用的工具都是開源的，相對(duì)集中的商業(yè)現(xiàn)貨（COTS）軟件淳地，很少進(jìn)行定制怖糊。
高效能團(tuán)隊(duì)幾乎在所有維度上都將工具自動(dòng)化并更頻繁地集成到其工具鏈中。 自動(dòng)化build颇象、自動(dòng)化單元測(cè)試伍伤、自動(dòng)化驗(yàn)收測(cè)試、自動(dòng)化性能測(cè)試遣钳、自動(dòng)化安全測(cè)試扰魂、自動(dòng)配置并部署到測(cè)試環(huán)境、自動(dòng)部署到生產(chǎn)環(huán)境蕴茴、集成chatbots / Slack劝评、生產(chǎn)監(jiān)控和觀察性工具等等。盡管自動(dòng)化可能被認(rèn)為實(shí)施起來過于昂貴倦淀，但自動(dòng)化確實(shí)是一項(xiàng)明智的投資蒋畜。它可以使工程師花費(fèi)更少的時(shí)間 從事手工工作，從而騰出時(shí)間來進(jìn)行其他重要活動(dòng)撞叽，如新開發(fā)百侧，重構(gòu)，設(shè)計(jì)工作和文檔編制能扒。 它還使工程師對(duì)工具鏈更有信心佣渴，從而減輕了推動(dòng)變更的壓力。
內(nèi)部搜索和外部搜索
內(nèi)部搜索：構(gòu)建企業(yè)內(nèi)部的知識(shí)庫初斑，共享知識(shí)可以幫助大家更快的找到問題的答案辛润。
外部搜索：為學(xué)習(xí)和成長提供了強(qiáng)大的社區(qū)，也為公共云和開源工具提供支持
組織相關(guān)
跨職能團(tuán)隊(duì)的重要性
跨職能的團(tuán)隊(duì)具有完成工作所需的全部能力，而無需依賴團(tuán)隊(duì)以外的其他人
精益產(chǎn)品管理
精益產(chǎn)品管理功能對(duì)軟件交付性能砂竖，組織文化和組織績效產(chǎn)生積極影響真椿。
- 團(tuán)隊(duì)將產(chǎn)品和功能切成小批量可以完成的程度，在不到一周的時(shí)間內(nèi)發(fā)布并頻繁發(fā)布乎澄，包括使用最低限度可行的產(chǎn)品（MVP）
- 組織是否定期積極地尋求客戶反饋突硝，并將此反饋納入其產(chǎn)品設(shè)計(jì)中
- 開發(fā)團(tuán)隊(duì)是否有權(quán)在不經(jīng)批準(zhǔn)的情況下創(chuàng)建和更改規(guī)范，并將其作為開發(fā)過程的一部分
報(bào)告：
state-of-devops-2019
state-of-devops-2018
state-of-devops-2017
state-of-devops-2016
