DevOps理念廣受青睞。在現(xiàn)實中，DevOps同樣遭受地盤之爭，而傳統(tǒng)IT也沒有適合的工具提供支持。它同樣給IT帶來不少新挑戰(zhàn)，包括來自同行的孤立與非結(jié)構(gòu)化的部署途徑。

“因為團隊正在嘗試新的流程與工具，沒有什么完美的方案可循，”CommerceHub 的質(zhì)量總監(jiān)Vijaya Kokkili說，該公司為電子商務(wù)零售商提供技術(shù)支持。“我們無意間發(fā)現(xiàn)了一些問題，而且其中一些仍然沒有答案。”

在公司采用DevOps的兩年里，Kokkili看到了轉(zhuǎn)型與新現(xiàn)實的兩個挑戰(zhàn)。

“我們本來希望將許多標(biāo)準(zhǔn)做到位，但事實卻很難正常工作，”她說，“這不是關(guān)于如何使用這些工具的問題，”而是需要溝通與協(xié)作，并重新定義工作方式。

一種新的孤立

曲解原意，很容易讓DevOps結(jié)構(gòu)化的IT組織因壞習(xí)慣而失敗。

像大多數(shù)IT組織，CommerceHub的職能團隊分為開發(fā)、數(shù)據(jù)庫、QA和運維，團隊之間由辦公室物理隔離。當(dāng)他們引入DevOps后，從每個小組中抽調(diào)人員組建跨職能團隊，雖然部門經(jīng)理還保留了對應(yīng)的監(jiān)督職能。然而，跨職能團隊內(nèi)部卻仍舊孤立。將開發(fā)人員、IT運維專家、數(shù)據(jù)庫管理員質(zhì)量保證(QA)測試人員，數(shù)據(jù)庫管理員和項目經(jīng)理放在一個房間里，并不能解決問題。

“QA工程師可能會被開發(fā)人員孤立，因為他們彼此并不理解，或者沒法在同一個頻道上交流，”Kokkili說，而且那里也沒有其他的QA。最終通過培訓(xùn)緩解了這一問題，教育每個成員如何在別人的工作中共享。

一旦解決了溝通障礙，磨合尚淺的IT團隊必須強化所有這些項目的宗旨：以客戶為中心的文化。

俄亥俄州立大學(xué)的IT團隊利用PMP(Project Management Professional)概念實施了ITIL。DevOps是下一個目標(biāo)。如果ITIL是管理IT變更的最佳實踐框架，“DevOps的目標(biāo)在于改變文化，”服務(wù)運營總監(jiān)Bob Gribben說。

同時，DevOps的IT團隊仍然有著部門指標(biāo)。例如IT運維有正常運行時間與利用率等指標(biāo)。這些目標(biāo)并不是跨職能DevOps團隊產(chǎn)品所有者的目標(biāo)。但以用戶和產(chǎn)品為中心的文化并不意味著放棄IT指標(biāo)。

我們分享一切——但那是我的

如果DevOps是關(guān)于分擔(dān)某個應(yīng)用程序的責(zé)任，是否仍然存在界限?舉例來說，如果一個跨職能團隊分擔(dān)事件響應(yīng)，你要如何才能限制代碼開發(fā)人員訪問生產(chǎn)環(huán)境以定位某個問題?你真的試過嗎?

問題的復(fù)雜性在于，不同IT組織對DevOps的看法是不同的。某些組織中，IT運維團隊依然保持著對生產(chǎn)環(huán)境100%的控制。其他情況下，開發(fā)者需要像對待代碼一樣對基礎(chǔ)設(shè)施負(fù)責(zé)并確保每個版本的穩(wěn)定性。

維護網(wǎng)絡(luò)的安全與公司信息安全，意味著成為敏捷、靈活開發(fā)的障礙。因此，安全、數(shù)據(jù)與測試通常是DevOps文化所忽視的部分。

安全，基于角色的訪問控制與加密是DevOps應(yīng)用程序生命周期的重要組成部分，Column Technologies技術(shù)顧問公司的首席DevOps實踐管理師Michael Grant指出。適合的工具能提供可視化的流量監(jiān)控，這也能讓安全團隊同意開放DevOps環(huán)境所需的應(yīng)用程序所有訪問權(quán)限。能夠可視化網(wǎng)絡(luò)與應(yīng)用程序調(diào)用的基礎(chǔ)設(shè)施監(jiān)控工具同樣能夠提高安全性，無論是數(shù)據(jù)中心還是多租戶的云資源上。

數(shù)據(jù)是每個企業(yè)的支柱，因此它也應(yīng)該是DevOps流程的一個主要部分。但數(shù)據(jù)庫管理員在DevOps的持續(xù)反饋回路中并沒有原生位置。數(shù)據(jù)即服務(wù)是DevOps的下一環(huán)節(jié)，Grant說。數(shù)據(jù)安全作為一種服務(wù)，能夠讓QA在代碼部署到生產(chǎn)環(huán)境之前更精確的測試負(fù)載——不至于壓壞數(shù)據(jù)庫團隊的基礎(chǔ)設(shè)施。

測試更難被DevOps實踐者接受，他們總是看不到質(zhì)量保證與測試專業(yè)知識的價值。

“我們某個產(chǎn)品團隊，沒有QA——這樣就需要假設(shè)開發(fā)能夠做測試的活，” Kokkili說，“但沒有專業(yè)知識，測試環(huán)節(jié)積累了不少技術(shù)債務(wù)并最終導(dǎo)致生產(chǎn)環(huán)境問題。”

相比之下，將測試與質(zhì)量保證工程師加入DevOps團隊可以防止和一次性修復(fù)代碼問題，避免DevOps在線上進行首次修復(fù)的思維定勢。

當(dāng)你手里只有一把錘子時

工具是任何DevOps環(huán)境的重要組成部分，但對于如此重要的問題，工具選擇卻是DevOps的結(jié)癥所在。

“某個團隊使用SalesForce來跟蹤問題，另外一個組使用Trello，還有的團隊在使用Jira——但這些都是為了解決相同應(yīng)用程序的問題，”Kokkili說，“高級別的可視性十分困難。”

開發(fā)人員習(xí)慣于采用順手的工具，無論工具是否適合公司的合規(guī)性，報表或運維可視性要求，F(xiàn)ixate IO的DevOps分析師Chris Riley指出。DevOps團隊的目標(biāo)是在不限制團隊成員創(chuàng)造力的情況下實現(xiàn)標(biāo)準(zhǔn)化，而且還處于尋找滿足跨職能協(xié)作常用工具的掙扎中。

采用DevOps工具的企業(yè)IT部門往往會權(quán)衡開源軟件與能提供全面支持的企業(yè)套件，結(jié)果通常會更偏向于企業(yè)套件，某專注DevOps的IT顧問指出。這是因為企業(yè)希望能獲得專業(yè)的支持、穩(wěn)定與可用功能，如圖形用戶界面，而很多開源工具通常都不具備這些。與此同時，傳統(tǒng)基礎(chǔ)設(shè)施管理與監(jiān)控工具廠商如CA與BMC真在開發(fā)DevOps產(chǎn)品，但好壞參半。折衷的方案是采用類似Puppet，遵循Linux開源模式，并通過上游社區(qū)借鑒控制、產(chǎn)品支持的經(jīng)驗。

我們離成功還有多遠(yuǎn)?

成功需要不斷改進和完善，而不是對特定變更發(fā)起一次推動，卻沒有整體規(guī)劃。DevOps，很像之前的ITIL，一直在推廣反饋回路，但更多時候，IT部門更喜歡直接到達終點，Tedder Consulting公司首席顧問Doug Tedder說。

我們看到與ITIL IT服務(wù)管理(ITSM)實現(xiàn)相同的模式。人們引入了事件管理和基本的變更管理流程，但并不理解如何交互或達到目標(biāo)，Tedder說。“有些人過度設(shè)計了ITSM流程，這就不是ITIL，而是如何建設(shè)流程了。”

“改變需要努力，”Ohio State University的Gribben說。例如“需要每周花上5小時來進行新工具的培訓(xùn)，目的是為了之后每周能節(jié)約25小時。”

他同時還指出人的本性是專注不同工具、或更多的工具，而不是注重流程。

“高管們會說‘等一下，我們已經(jīng)買了一款工具，為什么還需要一個又一個的新購?’，而且似乎什么產(chǎn)出都沒有，”Tedder說。如果IT部門沒有針對業(yè)務(wù)進行持續(xù)改善，沒有工具或工作組能夠?qū)⑺麄儚挠白覫T和外包結(jié)局中拯救。

CommerceHub的Kokkili倡導(dǎo)像他們那樣進行DevOps實踐，第一年只引入一個產(chǎn)品團隊，并且通過培訓(xùn)、講解和出席會議建立與接受這一文化。“快速失敗”可能是應(yīng)用程序更新的口頭禪——沒有那么多人參與。