知識星球
作者 | Kevin Casey
譯者 | qhwdw ? ? ? ? ? 共計翻譯：116 篇 貢獻時間：210 天
專家們權衡了 DevOps 團隊最近會有何期望。
“DevOps” 一詞通常認為是來源於 這篇 2008 年關於敏捷基礎設施和運營的講演中[1]。現在的 IT 詞彙中，它無處不在，這個“混搭”的詞彙出現還不到 10 年：我們還在研究它在 IT 中更現代化的工作方法。
誠然，多年來一直在 “從事 DevOps” 的人積累了豐富的知識。但是大多數的 DevOps 環境 —— 人與 文化[2] 、流程與方法、工具與技術的融合 —— 還遠遠沒有成熟。
更多的變化即將到來。Robert Reeves 說 “DevOps 是一個過程，一種演演算法”，他是 Datical[3] 的 CTO， “它的絕對標的就是隨著時間進行改變和演進”，這就是重點。
那我們預計接下來會發生什麼呢？這裡有一些專家們觀察到的重要趨勢。
1、 預計 DevOps、容器、以及微服務之間的相互依賴會增強
驅動 DevOps 發展的文化本身可能會演進。當然，DevOps 仍然將在根本上摧毀傳統的 IT 孤島和瓶頸，但這樣做的理由可能會變得更加急迫。證據 A & B： 對容器和微服務的興趣[4] 與日俱增。這個技術組合很強大、可連續擴充套件、與規劃和 持續進行的管理[5]配合最佳。
Arvind Soni 說 “影響 DevOps 的其中一個主要因素是向微服務轉變”，他是 Netsil[6] 的產品副總裁，補充道，容器和業務流程，使開發者打包和交付的速度越來越快。DevOps 團隊的任務可能是幫助去加速打包並管理越來越複雜的微服務彈性架構。
2、 預計 ”安全網“ 更少
DevOps 使團隊可以更快更敏捷地去構建軟體，部署速度也更快更頻繁、同時還能提升軟體質量和穩定性。但是好的 IT 領導通常都不會忽視管理風險，因此，早期大量的 DevOps 迭代都是使用了安全防護 —— 從後備的不重要業務開始的。為了實現更快的速度和敏捷性，越來越多的團隊將拋棄他們的 ”輔助輪“（LCTT 譯註：意思說減少了安全防護措施）。
Nic Grange 說 “隨著團隊的成熟，他們決定不再需要一些早期增加的安全 ‘防護欄’ 了”，他是 Retriever Communications[7] 的 CTO。Grange 給出了一個階段展示的伺服器的示例：隨著 DevOps 團隊的成熟，他們決定不再需要階段展示的伺服器了，尤其是他們很少在試生產環境中發現問題。（Grange 指出，這一舉措對於缺乏 DevOps 經驗的團隊來說，不可輕易效仿）
Grange 說 “這個團隊可能在監視和發現並解決生產系統中出現的問題的能力上有足夠的信心”，“部署過程和測試階段，如果沒有任何證據證明它的價值，那麼它可能會把整個進度拖慢”。
3、 預計 DevOps 將在其它領域大面積展開
DevOps 將兩個傳統的 IT 部門（開發和運營）結合的更緊密。越來越多的公司看到了這種結合的好處，這種文化可能會傳播開來。這種情況在一些組織中已經出現，在 “DevSecOps” 一詞越來越多出現的情況下，它反映出了在軟體開發週期中有意地、越來越早地包含了安全性。
Derek Weeks 說 “DevSecOps 不僅是一個工具，它是將安全思維更早地整合到開發實踐中”，它是 Sonatype[8] 的副總裁和 DevOps 擁擠者。
Red Hat[9] 的安全策略師 Kirsten Newcomer 說，這種做法並不是一個技術挑戰，而是一個文化挑戰。
Newcomer 說 “從歷史來看，安全團隊都是從開發團隊中分離出來的 —— 每個團隊在它們不同的 IT 領域中形成了各自的專長” ，“它並不需要這種方法。每個關心安全性的企業也關心他們透過軟體快速交付業務價值的能力，這些企業正在尋找方法，將安全放進應用程式的開發週期中。它們採用 DevSecOps 透過 CI/CD 流水線去整合安全實踐、工具和自動化。為了做的更好，他們整合他們的團隊 —— 將安全專家整合到應用程式開發團隊中，參與到從設計到產品部署的全過程中。這種做法使雙方都看到了價值 —— 每個團隊都擴充了它們的技能和知識，使他們成為更有價值的技術專家。DevOps 做對了 —— 或者說是 DevSecOps —— 提升了 IT 安全性。”
除了安全以外，還可以讓 DevOps 擴充套件到其它領域，比如資料庫團隊、QA，甚至是 IT 以外的潛在領域。
Datical 的 Reeves 說 “這是一件非常 DevOps 化的事情：發現相互掣肘的地方並解決它們”，“對於以前採用 DevOps 的企業來說，安全和資料庫是他們面臨的最大瓶頸。”
4、 預計 ROI 將會增加
Eric Schabell 說，“由於公司深入推進他們的 DevOps 工作，IT 團隊在方法、流程、容器和微服務方面的投資將得到更多的回報。” 他是 Red Hat 的全球技術傳播總監，Schabell 說 “‘聖杯’將移動的更快、完成的更多、並且變得更靈活。由於這些元件找到了更寬闊的天地，組織在應用程式中更有歸屬感時，結果就會出現。”
“每當新興技術獲得我們的關註時，任何事都有一個令人興奮的學習曲線，但當認識到它應用很困難的時候，同時也會經歷一個從興奮到幻滅的低谷。最終，我們將開始看到從低谷中爬出來，並收穫到應用 DevOps、容器、和微服務的好處。”
5、 預計成功的指標將持續演進
Mike Kail 說 “我相信 DevOps 文化的兩個核心原則 —— 自動化和可衡量是從來不會變的”，它是 CYBRIC[10] 的 CTO，也是 Yahoo 前 CIO。“總是有辦法去自動化一個任務，或者提升一個已經自動化的解決方案，而隨著時間的推移，重要的事情是測量可能的變化和擴充套件。這個成熟的過程是一個永不停步的旅行，而不是一個目的地或者已完成的任務。”
在 DevOps 的精神中，成熟和學習也與協作者和分享精神有關。Kail 認為，對於敏捷方法和 DevOps 文化來說，它仍然為時尚早，這意味著它們還有足夠的增長空間。
Kail 說 “隨著越來越多的成熟組織持續去測量可控指標，我相信（希望） —— 這些經驗應該被廣泛的分享，以便我們去學習並改善它們。”
作為 Red Hat 技術傳播專家，Gordon Haff[11] 最近註意到，組織使用業務成果相關的因素去改善他們的 DevOps 指標的工作越來越困難。 Haff 寫道[12] “你或許並不真正關心你的開發者寫了多少行程式碼、伺服器是否在一夜之間出現了硬體故障、或者你的測試改寫面是否全面”。事實上，你可能並不直接關心你的網站的響應速度和更新快慢。但是你要註意的是，這些指標可能與消費者放棄購物車或者轉到你的競爭對手那裡有關。”
與業務成果相關的一些 DevOps 指標的例子包括，消費者交易金額（作為消費者花銷統計的指標）和凈推薦值（消費者推薦公司產品和服務的意願）。關於這個主題更多的內容，請檢視這篇完整的文章—— DevOps 指標：你是否測量了重要的東西[12]。
唯一不變的就是改變
順利說一句，如果你希望這件事一蹴而就，那你就要倒黴了。
Reeves 說 “如果你認為今天釋出非常快，那你就什麼也沒有看到”，“這就是為什麼要讓相關者包括資料庫團隊進入到 DevOps 中的重要原因。因為今天這兩組人員的衝突會隨著釋出速度的提升而呈指數級增長。”
via: https://enterprisersproject.com/article/2017/10/what-s-next-devops-5-trends-watch
作者：Kevin Casey[14] 譯者：qhwdw 校對：wxy
本文由 LCTT 原創編譯，Linux中國 榮譽推出
