在軟體業界,有個普遍不成文的共識:「星期五不要部署、更版」。大部分是為了避免因為星期五部署影響系統的穩定性,造成週末要加班處理問題,出發點是風險管理。這議題在研討會上,業界專家提出前衛的思考:「Testing in Production, Deploy on Fridays」,隨後引發很多討論。
贊成可以星期五部署的人說:「一個團隊當要能夠在任何時間部署,這跟哪一天沒關係,理由是敏捷團隊應該如何、身為一個開發者應該如何(省略3000字)…」;反對在星期五部署的大部分出發點:「會以風險角度考慮事情,普遍認為時間會影響之後的生活或者士氣(省略30000字)…」。
雙方各有各的立場,各有各的道理,誰也不想退讓,最後變成是非題或比拳頭大小。
典型的現象
這樣的討論反映出一個典型的現象:
「把『能不能』(Can Be)和『應不應該』(Should Be)混在一起談。」
因為這個問題在討論時,負責執行的「主詞」完全不一樣,如立場、觀點、著眼點、背景都不一樣,所以結果當然不一樣。在戲劇與文學裡最常見的說法是:
「每個反派在自己的故事裡,都是英雄。」
體現的是立場不同形成觀點的落差,最後形成衝突,結果就是所謂的「史詩」、「悲愴」。
這樣的現象在「維運」領域中還有其他類似的案例,像是:
1. 資料庫能不能在Internet裸奔?資料庫應不應該在Internet裸奔?
2. 程式碼(輪子)能不能提高可重用性?程式碼(輪子)應不應該高可重用性?
3. 系統架構能不能微服務化?系統架構應不應該微服務化?
4. 上班日能不能在辦公室喝酒?上班日應不應該在辦公室喝酒?
5. 系統能不能有多個認證機制?系統應不應該有多個認證機制?
6. 省略100條…
衝突點
「星期五能不能部署」這樣的問題,贊同者的背景大多是敏捷團隊(團隊不分開發、測試、維運角色)、高階技術主管、團隊管理者、技術傳教士,這些角色大多認為部署時間不能被時間限制,而這些角色大多也能做到這樣,隨時隨地都具備能夠部署的能力,甚至以一天能部署的次數當作關鍵指標,然後因此感到自豪,他們在乎的是「能不能」,理所當然的也就「應該要」。
反對的背景大多都是開發與維運分開的維運團隊,這種狀況的維運團隊在組織裡大多屬於開發流程的下游、承擔風險的那一方、資訊落差很大的一端,更多的是比較缺乏軟體工程能力與專業知識,在這些因素的考量之下,會以降低風險、提高可靠度考量為第一,他們在乎的是「應不應該」,而不是「能不能」。
當雙方的層次不在同一個認知水平線上,加上沒有背景資訊,這個問題很容易陷入筆戰,就像產品團隊與業務團隊也常會有類似的狀況,業務團隊更在乎的是業績目標,產品團隊在乎的是功能交付的價值。
這個現象把理想、現實兩個對立面的問題點出來:
1. 理想派:期待理想能實踐,但忽略現實派長期的感受。
2. 現實派:被困在現實無法突破,對理想失去信心。
雙方的想法則是基於「是與非」的出發點,最後不是你死就是我亡。
觀點與看法
筆者的經驗來看,真實狀況會是比例原則,不是零或一的問題。基於八二法則概念是這樣的:
「儘量(80%)不要在星期五部署,但需要時(20%)團隊也不會擔心,因為團隊有能力駕馭自己負責系統的能力與信心。」
實務經驗也是如此,必要的時候星期五也會部署,依照該次部署功能的範圍、大小,判斷是否需要有額外的配套措施,像是隔天必須加強監控、週末需要有人排班定時回報狀況。
另外,要看團隊運作的模式,例如:成熟的敏捷團隊,「理所當然」就是自己的服務自己部署、自己服務炸鍋自己扛,做好決定、想清楚風險承擔能力就好。因為對於一個成熟的敏捷團隊,往往不只是裡子(能力)問題,更多的是面子(榮譽)問題,因為不能部署代表「不夠敏捷」,那就沒資格叫「敏捷團隊」,所以這是面子問題,背後更深層的是人性問題。
如果團隊運作是傳統的開發、維運分開,通常會選擇儘量避免,因為星期五部署的風險是衝突的來源,而開發團隊不是承擔責任的一方,維運團隊卻要去背負這種責任,累積到最後就是雙方失去信任,結果就是勢不兩立。這種狀況下,因為維運是下游單位,資訊落差與風險往往會造成團隊的壓力鍋,最後人心不定。維運方通常不會有面子問題,基於責任都會默默地吞下,但大多都有長期不平造成的心理壓力問題。
筆者觀察到的現象:「說贊成的人,往往無法體會反對的人長期累積的壓力鍋,累積出來的厭世感。反對的人,也無法了解那種被需求壓著時程,然後學習不完的新技術,卻要如期交付的心理壓力」。
理解彼此
回到一開說的「能不能」與「應不應該」兩個,前者是技能(Skills)問題,像是駕馭某個系統架構、程式熟練等;後者是能力(Ability)問題,更多的是掌握「局勢」的決策與判斷力問題,與時空背景(Timeline)、政策(Policy)與態度(Attitude)有關係。
做軟體設計、架構設計要做到及要滿足的是「能不能」的問題,能不能很有彈性的滿足業務需求、能不能有很高的擴展性、能不能達到安全管理、能不能節省成本?但做設計出來的東西怎麼運用,則是政策問題、階段性問題。架構有很高的擴展性,但是現階段基於成本考量,先不使用;業務發展到下個階段,應該要能高擴展的能力。
「資料庫能不能在Internet裸奔?資料庫應不應該在Internet裸奔?」理論上不應該在Internet裸奔,它會有資安的問題。能不能裸奔?很多開發團隊(特別是剛草創階段的新創團隊)沒有自己的專屬SRE,也沒時間去規劃資訊網路架構,為了讓大家方便存取AWS RDS,都是直接讓RDS裸奔,這是很常見的實際案例。能啊,當然能,應不應該?看狀況。所有的問題都不是零或一這種是非題,問題都需要具備前提與背景,然後依照當下狀況,有最適合的作法。
關於「資料庫能不能裸奔?應不應該裸奔?星期五能不能部署?應不應該部署?」要先問問主詞是誰,並問問時空背景,再來下定論。沒有這些背景資訊(Context)的討論,其實是沒有意義的。
非黑即白的二元論
這問題其實跟「Agile是否一定比Waterfall好」差不多。Agile約莫從2015年開始被廣泛推廣,但總是拿著Waterfall打,推廣一個理念時,找個墊背的也是理所當然的,這是典型的「拿著錘子,看到什麼都是釘子」的現象。但後來發現好像不太對,不能用一套方法論,然後從頭吃到尾,所以這幾年也看到一些敏捷的人說法有所改變。另外,類似的Scrum及看板這兩個方法也是一樣,不能一套從頭吃到尾。
所以,「星期五能不能部署」的問題不應該落入二元論、非黑即白,而是從了解彼此的背景、困難來換位思考,然後相互諒解與學習,這才是「DevOps」要強調的合作精神,不是嗎?
網路上的論點、筆戰很容易以自己環境的背景或自己的立場切入,但是討論時沒有了解彼此的背景與經驗,直接這樣二元論的討論,並不容易找到平衡點,也不太會有交集。再多的列舉與論證,都不會有交集。
「星期五應不應該部署」的問題通常需要從組織結構、團隊運作、系統架構等層次來切入,然後再來討論「是否、應不應該」的問題。(本文摘錄整理自《SRE實踐與開發平台指南》第一章,博碩文化提供)
書名 SRE實踐與開發平台指南
黃冠元(Rick Hwang)/著
博碩文化出版
定價:620元
作者簡介
黃冠元(Rick Hwang)
軟體開發者、音樂愛好者,擁有超過20年專業軟體工程經驗、10年主管經驗,曾任翔威國際駐IBM資深軟體工程師、Oplink SQA Manager / SDET Lead、91APP Operation and Infrastructure Manager / Architect,且2021年獲得AWS授予「Community Hero」榮譽稱號。
專注分散式系統架構設計、系統分析與設計、軟體測試、AWS、DevOps、SRE、經營管理等領域,著有技術部落格「Complete Think」、共同著作《軟體測試實務》、《分散式系統設計》(譯著)。
熱門新聞
2024-10-05
2024-10-07
2024-10-07
2024-10-07
2024-10-07
2024-10-07
2024-10-07