DevOps的承諾十分明確。然而,企業構建應用程序的方式變更可能引起團隊之間的反感。
有時候,運維人員認為開發人員坐在自己的象牙塔里,整天寫代碼,希望快點發布程序,無視現實世界的制度約束。開發人員則視運維為災難預言者,一直聲稱IT基礎設施會在新代碼的壓力下崩潰。企業的變革腳步正在加快,創造更大、更復雜的應用,某種程度上,兩者之間的關系愈加緊張。
歸并觀念沖突不容易。企業必須打破這兩個群體之間的隔閡,讓他們以一種更加合作的方式開展工作。此外,運維需要引入必要工具來實現自動化變更管理流程。只有經過這些步驟,DevOps文化才會深入團隊。
聚焦變更管理流程
企業處于不斷變化的恒定狀態。
“通過改變業務流程,產品和用戶服務,公司可以抓住需要立快速響應以及立即采取行動的新機遇,”Bill Claybrook,馬薩諸塞州New River Marketing Research公司總裁說。
DevOps幫助他們實現了這一目標。這種IT文化將開發測試與系統運維緊密的聯系在一起。兩個團隊更緊密的合作并實現自動化部署過程,不需要再關注運維如何辛苦地上線新服務。結果就是新版本能更快也更頻繁地發布。某些情況下,變更幾乎是不間斷產生,例如Amazon Web Services每11.7秒就會部署一次軟件更新。
DevOps的快速步伐會給運維和開發帶來壓力。企業需要持續設計與測試更大規模和更復雜的產品。Microsoft Office 2013 Professional占用約700MB磁盤空間,由數十億行代碼構成。讓一款應用程序中的所有元素很好的協同工作,對開發和運維來說是個充滿挑戰的過程。
超越軟件的變更
除了軟件變更,公司還需要不斷改善,增加新系統,升級現有設備,招聘和解聘員工。
“許多IT部門都在糾結如何讓系統跟上移動、社交和云解決方案的步伐,”企業系統管理軟件公司IDC的研究副總裁Mary Johnston Turner說。
隨著變更次數不斷增加,也會出現類似人為錯誤的可能。DevOps團隊可能會推送1000次變更,其中可能有一個可能會造成干擾引發問題。
公司“近視”威脅到DevOps文化
溝通是系統缺陷的主要原因之一。業務部門、開發和運維都是根據設定的流程進行合作。這就像不同的團隊各自擁有小塊的應用程序拼圖,有時候,近視、誤解與不信任會產生漣漪效應。當團隊從不同角度解決同樣挑戰時,也必然會出現誤傳。存在的問題既浪費精力又徒勞無功,最后會導致所有的后果都推到替罪羊身上。
開發周期越后面出現的問題,造成的創傷性影響也越大。例如在即將推送的更新中,開發人員重寫了幾個運行在New York Stock Exchange上的應用程序shell腳本。
“整個系統崩潰了,幾乎有一小時無法進行交易,”顧問兼軟件工程師Bob Aiello說,結果造成了數百萬美元的損失。(他是《Configuration Management Best Practices: Practical Methods that Work in the Real World》一書的聯合作者。)
嚴苛的業務流程
當系統出現故障時,首先需要通知運維,運維的職責在于維護系統的可用性。員工與企業越來越多的依賴100%可用性的IT服務。面對潛在的宕機風險,運維人員對穩定性的價值十分珍惜,并且對可能導致維護與宕機的變更有抵制,因為執行這類變更往往會導致服務器故障并影響聲譽。更少的變更意味著減少可能出現的故障。此外,故障排除也會隨著系統處于恒定的變更狀態而愈加復雜。
為了保護基礎設施,IT運維團隊經常會為開發者設立近乎苛刻的流程。例如,英國政府支持的Information Technology Infrastructure Library(信息技術基礎設施庫,ITIL)是一套IT服務管理設計最佳實踐,設計用于提供滿足企業需求的IT服務。流程包括如何處理變更管理,但開發人員通常會抱怨說,這些東西十分繁瑣,也不必要。
要培養長期的DevOps企業文化,企業就必須取得平衡。運維必須更有效地應對變化。監控系統變化是個耗時并有挑戰性的工作。今日,系統自動化工具如Puppet Labs Puppet和Chef,已經能夠企業更快更有效的提供IT資源。
開發者需要看到他們的工作對業務的其他方面產生的積極或消極后果。一個辦法是讓他們帶尋呼機,這樣在出現問題時,能實實在在的感受到混亂以及支持人員那種緊張。這種同情會在新版本中潛移默化,讓他們更明智。
DevOps試圖將運維與開發更緊密的結合在一起。從理論上講,引入DevOps文化有助于滿足企業快速變化業務的需求。
投入是值得的。根據Puppet Labs的調查顯示,把開發和運維緊密聯合起來,提高了部署速度并降低了變更事故率的時間以及從故障中恢復的時間。但是,這些好處只有在兩個團隊都意識到需要互相支持,并且公司投資新工具簡化資源配置流程下才能得以實現。