[[196812]]

軟件無處不在。在如今的世界里，每個主流公司/組織都和軟件開發(fā)息息相關(guān)，并且公司需要向軟件一樣運(yùn)作。更快且更敏捷，同時保證安全性和可靠性，這樣的要求***的強(qiáng)烈。這樣的壓力通常體現(xiàn)為項目被取消或者被暫停。這正是DevOps嘗試解決的問題：如何讓企業(yè)內(nèi)部的開發(fā)，運(yùn)維和其他組織協(xié)作，達(dá)成一系列共同的目標(biāo)，更快更可靠地向客戶和終端用戶交付軟件?支持DevOps項目的核心技術(shù)實踐包括讓開發(fā)和運(yùn)維團(tuán)隊為軟件交互標(biāo)準(zhǔn)化一系列常見的敏捷流程和工具。這通常包括：

• 自動化的配置管理，測試和應(yīng)用部署;
• 應(yīng)用程序和基礎(chǔ)架構(gòu)代碼的版本控制，助力協(xié)作和回滾;
• CI(持續(xù)集成)自動化代碼構(gòu)建，并且通過更頻繁，風(fēng)險更低的版本帶來更快的反饋和迭代。

DevOps是文化的轉(zhuǎn)變，是關(guān)于每個人如何以正確的方式參與到工作當(dāng)中。在軟件定義的世界里，出現(xiàn)了一系列問題。

我們?nèi)绾巫屇承〇|西快速進(jìn)入生產(chǎn)環(huán)境?我們怎么知道使用的是***方案呢?我們能多快地使用改進(jìn)和更新?

DevOps試圖通過盡早地在交互型流程里涉及到所有人從而讓大家都參與進(jìn)來。達(dá)到DevOps的成功需要首先理解核心業(yè)務(wù)優(yōu)勢。企業(yè)能夠更快地前進(jìn)，下線時間更短，并且安全問題更少。

Mike Dilowrth，敏捷和DevOps轉(zhuǎn)型***，最近說：

DevOps是一種文化，不是角色!整個公司都需要參與到DevOps里才能成功。

DevOps需要高級領(lǐng)導(dǎo)層的支持，也需要和最終產(chǎn)品相關(guān)的所有人的參與，而不僅僅是開發(fā)和運(yùn)維部門。

我之前讀過一篇Puppet的白皮書，關(guān)于如何構(gòu)建高效的IT團(tuán)隊。其中開始部分就提出了一些有意思的理論和實踐，這里我想分享給大家。

DevOps和行業(yè)，公司規(guī)模以及技術(shù)環(huán)境密切相關(guān)。至少，在企業(yè)中領(lǐng)導(dǎo)過成功DevOps轉(zhuǎn)型的IT經(jīng)理們，總結(jié)時都認(rèn)為，DevOps指的是持續(xù)學(xué)習(xí)和改進(jìn)的過程，而不是某種最終狀態(tài)。

構(gòu)建業(yè)務(wù)用例

和很多IT***一樣，你想要的不僅僅是交付***的多的產(chǎn)品和服務(wù)，而且還要更快更好地交付——并且沒有可靠性和安全性的問題。DevOps看上去確實會有所幫助!但是……在真正開始之前，你就已經(jīng)開始讓團(tuán)隊產(chǎn)生懷疑了。

怎么才能為DevOps制定清晰，令人信服的場景，可以降低擔(dān)憂，并且將懷疑轉(zhuǎn)化為成功呢?

上面的問題是個良好的開始。構(gòu)建業(yè)務(wù)場景是成功的DevOps轉(zhuǎn)型的重要部分(特別是在大型企業(yè)里)。在一場有名的TED演講里，Simon Sinek認(rèn)為偉大***和積極變化的催化劑的共同點(diǎn)是：

讓人們信服的不是***在干什么，而是為什么要這么干。

在構(gòu)建企業(yè)對DevOps轉(zhuǎn)型的認(rèn)同方面，也是同樣的道理。簡單宣布“我們要做DevOps”并不會讓大家真正開始。相反，你需要令人信服地回答這樣的問題“為什么?為什么是現(xiàn)在?”。你的所有客戶都希望速度更快并且不犧牲系統(tǒng)的可靠性和穩(wěn)定性——在傳統(tǒng)企業(yè)里這個目標(biāo)直接自相沖突。開發(fā)人員的任務(wù)是盡可能快地讓新特性上生產(chǎn)環(huán)境。同時，衡量運(yùn)維團(tuán)隊的指標(biāo)是在線時間和系統(tǒng)性能。因此這讓團(tuán)隊之間變得對立而不是并肩作戰(zhàn)。因此，生產(chǎn)環(huán)境的部署一直被延遲和錯誤所困擾，部署發(fā)生的頻率比業(yè)務(wù)實際需要的頻率低很多。

讓Dev支持DevOps

更快的部署和反饋回路正是開發(fā)人員想要的：代碼可以更快地從他們的筆記本交付到用戶手里，持續(xù)交付帶來快速的迭代和改進(jìn)。在早期pilot項目里跟蹤變更時間的改進(jìn)是個不錯的開始：

• 代碼從開發(fā)的筆記本到生產(chǎn)環(huán)境需要多久?
• 跟之前的時間相比，有什么改進(jìn)么?(你是不是自動化了更多的構(gòu)建流程?你有沒有降低需要部署的ticket數(shù)量?)
• 現(xiàn)在和以前相比多久需要一次部署?
• 部署有沒有變得更為容易并且更快了呢?

讓Ops支持DevOps

當(dāng)開發(fā)人員和運(yùn)維人員緊密工作時，運(yùn)維人員會受益。可以從同意使用通用的工具鏈開始，讓兩個組的人采用相同的工具一起工作，在開發(fā)中集成，測試和部署基礎(chǔ)架構(gòu)代碼。這樣可以讓開發(fā)人員更為積極地參與到部署和問題定位中，進(jìn)一步打破以前的障礙，同時提高速度和可靠性。跟蹤運(yùn)維團(tuán)隊關(guān)心的度量矩陣將給整個團(tuán)隊帶來好處——包括Dev和QA：

• 在線/下線時間：是不是能夠更好地達(dá)到服務(wù)級別的要求?下線時間減少了么?
• 變更失敗率：故障是不是變少了?
• 恢復(fù)的平均時間：故障發(fā)生時，回滾到已知的最近的好狀態(tài)，這樣的回滾時間是不是減少了?

從小處著手，持續(xù)成長

那么，如何開始度量這些DevOps的影響，并且支持自己的業(yè)務(wù)場景呢?從有特定任務(wù)和項目的小地方開始。Terri Potts (Raytheon的杰出工程師&軟件技術(shù)總監(jiān))認(rèn)為這樣的方案非常高效。

你無法一下子改變整個程序，但是可以讓一些子團(tuán)隊開始嘗試正確的方向。從外部引入一些人來自動化一些測試或者build，會很有用，同時給團(tuán)隊一些實際的例子。

Raytheon讓他的一個團(tuán)隊從每個月兩次集成轉(zhuǎn)變?yōu)橐粋€晚上運(yùn)行27次，這是自動化了build后的結(jié)果。在單個項目里這是一個很大的成功，這也成為了Portts如何在企業(yè)內(nèi)孵化DevOps的典型示例。

從小處開始，文化轉(zhuǎn)型也要跟上——不要期望一開始就能讓所有人都信服DevOps。實際中，在特定項目的小型組織內(nèi)贏得大家的支持，就贏得了會在公司其他地方幫助宣傳DevOps的大使們，這會帶來乘數(shù)效應(yīng)。隨著業(yè)務(wù)場景的構(gòu)建，還需要清醒認(rèn)識到要達(dá)成長期DevOps成功的可能會遇到的障礙。