DevOps還(hái)未徹底發展成熟。如果用(yòng)人(rén)的(de)一生來(lái)比喻，那麽DevOps還(hái)隻是位少年——雖然早已脫離襁褓，但遠(yuǎn)沒有長(cháng)大(dà)成人(rén)。就在這(zhè)時(shí)，曆史性的(de)挑戰突然出現，要求其在COVID-19疫情的(de)沖擊之下(xià)，快(kuài)速發展爲加快(kuài)軟件開發工作的(de)全面實施方案。

 

作爲一名“少年”，DevOps在核心要素方面當然無需含糊——協作爲王、自動化(huà)至上以及全面實現“持續”特性，包括持續集成、部署、測試以及改進。

 

而持續改進的(de)一大(dà)重要組成部分(fēn)，就是主動找出當前阻礙獲得(de)成功的(de)錯誤，進而努力避免這(zhè)些錯誤。縱觀衆多(duō)全球财富兩千強企業，都能發現其中不少都在三大(dà)DevOps錯誤中折戟沉沙。下(xià)面來(lái)看如何有效避免。

 

開發人(rén)員(yuán)負擔過重

 

随著(zhe)數字化(huà)轉型在2021年成爲全體CIO的(de)首要工作，企業自然希望以創紀錄的(de)速度交付足以改變遊戲規則的(de)強大(dà)功能，借此迅速擊敗競争對(duì)手。

 

這(zhè)當然需要整個(gè)團隊的(de)共同努力，包括開發人(rén)員(yuán)、産品負責人(rén)、測試人(rén)員(yuán)、運營以及網站可(kě)靠性工程師(SRE)等。但是，每當有某些功能或方案未能及時(shí)交付，鍋該由誰來(lái)背?幾乎永遠(yuǎn)是開發者。另一個(gè)殘酷的(de)現實在于，絕大(dà)多(duō)數企業很難吸引到一流的(de)開發人(rén)員(yuán)，留住少數頂尖人(rén)才就成爲一項長(cháng)期而艱難的(de)挑戰。

 

總之，企業萬萬不可(kě)對(duì)開發人(rén)員(yuán)予取予求。隻有爲開發者們留下(xià)充足的(de)空間，他(tā)們才能承擔起測試與安全保護等職責。

 

當然，質量保證與安全工作并不能隻靠開發者的(de)自覺，而應在項目之初就以制度性形式存在。要強調的(de)是，千萬不要讓這(zhè)樣的(de)工作流程進一步加大(dà)本就十分(fēn)沉重的(de)開發者負擔。否則，頂尖開發人(rén)才很可(kě)能投入其他(tā)企業組織的(de)懷抱。

 

用(yòng)統一要求衡量每一位開發者

 

每個(gè)組織以及每位團隊成員(yuán)都可(kě)以通(tōng)過正确的(de)方式得(de)到适當的(de)培訓與支持，進而爲DevOps成功做(zuò)出貢獻。但是，不同成員(yuán)做(zuò)出貢獻的(de)方式也(yě)有所區(qū)别，不應統一要求。

 

任何行動、流程或技術的(de)早期采用(yòng)者，往往正是組織内最爲耀眼的(de)超級巨星、業務骨幹。他(tā)們對(duì)自己的(de)工作内容充滿熱(rè)情，關注領域内的(de)各類新興趨勢，而且總有強大(dà)的(de)内驅力在工作上做(zuò)出種種嘗試。無論是不斷修改當前解決方案、還(hái)是尋找新的(de)可(kě)行方法、再到爲廣泛社區(qū)做(zuò)出貢獻，他(tā)們始終參與其中。沒錯，這(zhè)些都是非常重要的(de)習(xí)慣，也(yě)必然會帶來(lái)令人(rén)印象深刻的(de)成果。

 

但千萬别把這(zhè)些當成普适性的(de)評判标準。大(dà)多(duō)數應用(yòng)交付人(rén)員(yuán)并不是這(zhè)麽工作的(de)，或者說并不一定具有這(zhè)種冒險意識以及将新事物(wù)帶入生活的(de)原始沖動。他(tā)們投入了(le)數年甚至數十年不斷完善自己掌握的(de)技巧，希望以最高(gāo)效、最順暢的(de)“老辦法”持續處理(lǐ)問題。

 

此外，不同的(de)團隊往往具有不同的(de)技能、舒适區(qū)、優先級，而且很可(kě)能需要面對(duì)不同的(de)應用(yòng)棧與合規性/治理(lǐ)要求。具體來(lái)講，初創團隊往往更關注DevOps方法與工具集，而負責後端的(de)團隊則更多(duō)偏向傳統SAP。非要以統一的(de)要求衡量雙方，隻會徒增煩惱。

 

當然，DevOps本身也(yě)是一項需要全面規劃的(de)事務。

 

如果希望在整個(gè)企業之内加速創新，那麽每位員(yuán)工都應該在DevOps當中扮演自己的(de)角色，包括堅持貫徹DevOps提出的(de)核心理(lǐ)念、在工具集與實踐方面提供其他(tā)員(yuán)工友好型選項、在涉及不同系統及項目的(de)各小組中引入可(kě)見性與治理(lǐ)層。

 

未充分(fēn)了(le)解整體用(yòng)戶體驗

 

如今的(de)用(yòng)戶對(duì)于功能往往抱有極高(gāo)期望，但對(duì)問題的(de)容忍度卻極低。Forrester最近發現，單是在客戶體驗層面的(de)改進也(yě)足以爲企業帶來(lái)巨大(dà)的(de)利潤影(yǐng)響。他(tā)們估計，客戶體驗系數每增加1點(0到100)，年收入即可(kě)實現顯著提升——汽車行業爲11億美(měi)元、零售行業爲4.96億美(měi)元，電信行業爲3.88億美(měi)元。反之，如果客戶體驗有所下(xià)降，也(yě)必定引發相應的(de)收入損失。

 

當然，團隊中的(de)每位成員(yuán)都希望打造并推出用(yòng)戶喜愛(ài)的(de)軟件。但是，不同的(de)職能角色往往抱持著(zhe)不同的(de)觀點、個(gè)人(rén)優勢與短闆。從規劃、測試、發布再到監控，我們需要真正全面地了(le)解業務，并通(tōng)過每一位團隊成員(yuán)的(de)參與有力捍衛整體用(yòng)戶體驗。

 

不少DevOps團隊目前仍在依靠底層技術，例如在單元測試中，來(lái)确定候選發布版本是否可(kě)以安全推出。遺憾的(de)是，這(zhè)樣的(de)測試往往隻能發現編碼錯誤，卻無法保證卓越的(de)産品體驗。要達成體驗改進的(de)目标，需要做(zuò)到如下(xià)三點：

 

第一，采取基于風險的(de)測試，借此快(kuài)速判斷是否需要根據某些測試結果叫停項目發布。

第二，對(duì)事務進行端到端功能測試，例如從移動端到API、SAP與Salesforce等打包應用(yòng)，乃至自定義應用(yòng)程序與大(dà)型機等。

第三，通(tōng)過負載/性能測試保證應用(yòng)程序能夠及時(shí)擴展并應對(duì)需求激增。

以上三大(dà)誤區(qū)在任何組織内都很常見。畢竟DevOps還(hái)是少年，有時(shí)難免帶來(lái)一些麻煩——但隻要悉心陪伴它的(de)成長(cháng)，相信DevOps終将成爲企業發展道路上的(de)強大(dà)助力。