你的團隊DevOps了嗎?

Contents

DevOps工程師的名詞在近幾年軟體業徵才職缺中越來越夯, 這是件好事, 表示越來越多公司想要DevOps起來. 但真的請了DevOps工程師, 團隊就會DevOps起來嗎?

最近國外有個聲音, 如果您以為請了DevOps工程師, 把DevOps責任全歸於他, 那肯定就DevOps不起來了. 為什麼呢?

由Oreilly這本DevOps的免費電子書-Building a DevOps Culture-DevOps is as much about culture as it is about tools , 您將可找到答案. 這本書清楚說明DevOps真實的意義. DevOps絕對不只是CI、TDD、 Version Control、Auto Deployment、Auto Testing 這些而已. 在應用這些工具前, 您要問您的團隊文化是否也一起轉變為DevOps了?

我們先來看什麼是DevOps? DevOps是結合多種軟體開發實作讓開發與出貨加速的文化運動. 因為敏捷開發(Agile)與精益(Lean)等方式的改善演進, 以及許多自動化工具越來越純熟, 要加速開發、測試和上線都變得可能. 但作者強調, 您應用了DevOps工具和流程, 讓大家看起來好像在做DevOps, 但如果大家的溝通方式與心態沒有改變, 要DevOps起來仍會困難重重.

您要小心您的團隊是否還在崇拜明星工程師？是否允許沒測試好就能出貨上線? 這都有礙一個團隊DevOps起來.

如何才能轉變組織變得有DevOps的文化呢?

開放的溝通(Open Communication)

傳統的團隊可能還在用取票(ticketing)系統或簽核到上層或由上層來一一調度指揮的方法做溝通, 但DevOps鼓勵整個生命週期從需求、功能、計畫、資源等相關人做多向的溝通討論.

您的stand-up meeting不應該侷限在開發工程師, 應該包含QA工程師、系統管理者. 例如開發單位準備使用某第三方的API做認證的功能, QA需要知道狀況配合寫測試, 系統管理者將會有SLA的問題, 以及如何監控及報告認證失敗的問題.

此外, 建置友善溝通的環境, 讓人人覺得可隨意找另一個人溝通. 友善的環境包含是否容易和任何工作相關的人一對一對話? 本書提倡盡量佈置共事的團隊在容易招手就聊的區域一起工作. (加註: 如果真的沒辦法, 還是有地理環境的距離, 也許您可以考慮Skype、Zoom或Slack這類的工具, 縮短人與人之間的距離.)

讓每個人知道團隊目標、專案計畫的藍圖, 並將開發進度與建置的度量現況公開, 如此大家有清楚的共識, 沒有資訊的落差.

激勵與責任一致(Incentive and Responsibility Alignment）

DevOps的團隊裡, 解決問題的責任絕對不只是落在面對客戶第一線的人員, QA不應該是唯一在寫測試的人. 當問題回報時, 都應回到造成問題源頭的人, 他常常是最了解問題所在的人, 且由他起始解決問題的程序. 工程師不會因為寫很多程式碼被獎勵, 把系統上線營運的人不應該因為系統出錯被怪罪. 團隊的激勵和責任歸屬, 都應該導引至一個目標:讓團隊更有效率地產出更棒的作品.

在推出DevOps時, 先了解目前的狀況, 再訂立可度量的目標, 激勵大家一起達到後再一起慶祝. 這些目標例如

縮短新功能從開發到市場推出的時間
增加產品的整體可用性
縮短部署軟體上線的時間
增加在產品發佈前自行偵測到瑕疵的比率
更有效地使用硬體架構
在更短時間內能提供效能表現與使用者回饋給產品經理

這些目標都有財務上的實質意義. 有的將減少發佈所需要的工時, 有的將因產品早點上市早點獲利, 有的避免瑕疵造成的損失, 有的降低營運成本, 有的幫助更快且正確的決策. 這些目標加上度量數字, 如”縮短部署軟體上線的時間從10小時變成2小時”. 由訂立的目標來設計激勵方案, 並讓激勵與責任一致.

尊重(Respect)

每個團隊成員應彼此認可對方的貢獻與價值. 若發生衝突, 不可針對個人做人身攻擊. 溝通和解時, 應重視每個人的聲音, 且公平對待每個人,要互相尊重的討論與聆聽別人的意見. 在團隊裡, 應該每個人都不用怕分享自己的想法與意見, 不用擔心受到任何形式的霸凌.

信任(Trust)

DevOps的運作需爭取到有實權的高層支持, 讓團隊相信他們現在進行的不是純粹練功而已. 團隊成員應彼此信任對方正在做他們應做的事, 且不會故意找碴(尤其是QA和開發部門間的關係).

組織文化的轉變本來就是件不簡單的事. 相信您有聽過有些公司併購另一家公司後反而引發一場文化衝擊的災難. 當一個組織想做變革, 推行的人要了解組織內什麼樣的人都有, 需要耐心的宣導、評量現狀並衡量有可能帶來的衝擊. 如果您不是最高層的主管, 您需要訂定與財務相關的目標讓上層的人買單. 推行的方式也很難一步到位, 通常採取漸進式的方式, 先由一個不會太大也不會太小的團隊做出典範(太大容易失敗, 太小人家會認為成功是應該的), 當這個團隊做出口碑, 引起其他團隊的好奇, 後續的推導將會水到渠成.

您的DevOps的推行需要找到跨部門的人和專家支持, 幫忙說明與鼓吹. 如果有德高望重的同事或主管幫忙, 將讓您的推行如魚得水. 您的DevOps技術駭客最好不是趾高氣昂的討厭鬼, 這樣您的推行會比較順利.