星期五不應該部署？

在軟體業界，有個普遍不成文的共識：「星期五不要部署、更版」。大部分是為了避免因為星期五部署影響系統的穩定性，造成週末要加班處理問題，出發點是風險管理。這議題在研討會上，業界專家提出前衛的思考：「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元

圖片來源_AWS

 作者簡介 

黃冠元（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」、共同著作《軟體測試實務》、《分散式系統設計》（譯著）。