標題是最近 (2020/10) 在 Facebook 上的熱門話題，經過幾天之後，看了很多業界高手、前輩、專家的熱烈討論之後，沈澱了幾天，昨天 (10/17 Sat) 午休睡醒後迷迷糊糊寫下的， 原始文章連結 … 過程中，陸續修補一些想法和參考資料。

Updated 2023/07/19: 本文全文內容收錄在個人著作 《SRE 實踐與開發平台指南》 - 2023/08 上市

熱門話題：『星期五要不要部署？』

前情提要

在軟體業界，有個普遍不成文的共識：

星期五不要部署、更版

大部分是為了避免因為星期五部署影響系統的穩定性，造成週末要加班處理問題，出發點是風險管理。

但這議題在這次 ModernWeb 2020 上，業界專家提出前衛的思考： Testing in Production, Deploy on Fridays，隨後引發很多討論，底下是我看到的討論原始連結整理：

• 10/16: Joey Chen 轉貼到 Scrum Community 的討論
• 10/16: Ant 補充說明，國外的看法
• 10/15: Joey Chen 的討論：一天部署超過10次，但週五不行部署？
• 10/13: DevOps 轉貼 Ant 文章的討論
• 10/13: Ant 在 ModernWeb 的發表預告：《 Testing in Production, Deploy on Fridays 》 (1/3) - ModernWeb2020

雙方的說法

贊成可以星期五部署的說：

一個團隊當要能夠在任何時間部署，這跟哪一天沒關係，理由是敏捷團隊應該如何、身為一個開發者應該如何 …. (省略 3000 字)

反對在星期五部署的說：

大多會以風險角度考慮事情，普遍認為時間會影響之後的生活或者士氣 … (省略 30000 字).

典型的現象

這討論反映出一個典型的現象：

把 能不能 和 應不應該 混在一起談

因為負責執行的『主詞』完全不一樣。立場不一樣，結果當然不一樣。

每個反派，在自己的故事裡，都是英雄。

先舉例其他類似的案例：

• 資料庫能不能在 Internet 裸奔？資料庫應不應該在 Internet 裸奔？
• 程式碼能不能提高可重用性？程式碼應不應該高可重用性？
• 系統架構能不能微服務化？系統架構應不應該微服務化？
• 上班日能不能在辦公室喝酒？上班日應不應該在辦公室喝酒？
• 系統能不能有多個認證機制？系統應不應該有多個認證機制？
• … 可以再列一百條

雙方衝突點

回到『星期五能不能部署』這個案例，贊同者背景大多是敏捷團隊（團隊不分開發、測試、維運角色）、高階主管、團隊管理者、技術傳教士，這些角色大多認為部署時間不能被時間限制，而這些角色大多也的確能做到這樣，他們在乎的是『能不能』，理所當然的也就『也應該要』。

反對的背景大多都是開發與維運分開，大多屬於開發流程的下游、承擔風險的那一方、資訊落差很大的一端，所以會以風險考量為第一，他們在乎的是『應不應該』，而不是『能不能』。

討論議題，雙方的層次如果不在同一個水平線上，加上沒有背景資訊，很容易陷入筆戰。

這個現象把 理想、現實 兩個對立面的問題點出來：

理想派，期待理想能實踐，但忽略現實派長期的感受。
現實派，被困在現實無法突破，對理想失去信心。

我的看法

我的看法呢？先講結論：

兩邊我都不認同（藍的綠的我都不要 XD)

因為經驗告訴我，真實狀況會是比例原則，不是零或一的問題。

盡量 (80%) 不在星期五部署，但需要時 (20%) 團隊也不會擔心，因為團隊有能力駕馭自己的系統。

實務經驗也是如此，必要的時候星期五一樣會部署，但隔天必須加強監控。另外是要看團隊運作的模式，如果是成熟的敏捷團隊，自己的服務自己部署，自己炸鍋自己扛，做好決定就好。對於一個 成熟 的敏捷團隊，不只是能力問題，還有 面子 問題。管理者使用面子果實，使用激將法，就可以達到目的。

如果團隊運作是 傳統的 開發、維運分開 ，通常會選擇盡量避免，因為星期五部署的風險是衝突的來源，累積到最後就是勢不兩立的狀況。對於維運方來講，因為是下游單位，往往是壓力鍋。維運方通常不會有面子問題，基於責任都會默默地吞下，但大多都有長期不平造成的心理壓力問題。

補充觀察到的現象：說贊成的人，我的觀察啦，往往無法體會反對的人長期累積的壓力鍋，累積出來的厭世感。反對的人，也無法了解那種被需求壓著時程，然後學習不完的新技術，卻要如期交付的心理壓力。所以大家才一直有話題可以聊 XD

理解彼此的背景

回到一開說的『能不能』與『應不應該』兩個，前者是能力問題 (Skills / Ability) ，後者與時空背景 (Timeline)、政策 (Policy) 與態度 (Attitude) 有關係。

做 軟體設計、架構設計 要做到的要滿足的是能不能問題，能不能很有彈性的滿足業務需求、能不能有很高的擴展性、能不能達到安全管理、能不能節省成本？但做設計出來的東西怎麼運用，則是政策問題、階段性問題。架構有很高的擴展性，但是現階段基於成本考量，先不使用；業務發展到下個階段，應該要能高擴展的能力。

資料庫能不能在 Internet 裸奔？資料庫應不應該在 Internet 裸奔？理論上不應該在 Internet 裸奔，他會有資安的問題。能不能裸奔？很多開發團隊，特別是剛草創階段的新創團隊，沒有自己的專屬 MIS ，也沒時間去規劃資訊網路架構，為了讓大家方便存取 AWS RDS，都是直接讓 RDS 裸奔，這是很常見的實際案例。能啊，當然能，應不應該？看狀況。

資料庫能不能裸奔？應不應該裸奔？星期五能不能部署？應不應該部署？

先問問主詞是誰，問問時空背景，再來下定論。沒有這些背景資訊的討論，其實就是在交朋友 XD

零或一、二元論、非黑即白

這題目其實跟『 Agile 是否一定比 Waterfall 好』差不多 XD

Agile 這幾年一堆人在推廣，幾年前都會拿著 Waterfall 打，推廣一個理念，找個墊背的也是理所當然的。這是典型的 拿著錘子，看到什麼都是釘子 的現象。但後來發現好像不太對，不能用一套方法論，然後從夠吃到尾，所以這幾年也看到一些敏捷的人說法有所改變。另外類似的 Scrum 跟看板也是一樣，也不是一套吃到尾的。

類似議題參閱：Infra 團隊適合 Scrum？

所以『星期五能不能部署』不希望大家落入 二元論、非黑即白，而是從 了解彼此的背景、彼此的困難、換位思考，然後 相互諒解與學習，這才是 “DevOps” 該要強調的合作精神，不是嗎？

網路上筆戰，很容易以自己環境的背景、或者自己的立場切入，但是討論時 沒了解彼此的背景與經驗，直接這樣二元論的討論，不容易找到平衡點，也不太會有交集。再多的列舉與論證，都不會有交集。

層次問題：Should Be, Can be、談武論俠

另外我認為 能不能 (Can be)、應不應該 (Should Be) 本質上，是不同層次的議題。

『能不能』強調的是技能 (Skills) 或者能力 (Ability)，技能是會 C#、Java、Golang … 這種東西；能力 (Ability) 是能設計架構、能夠管理團隊、有領導力 … 等。『應不應該』則是依照時空背景條件，依照個人經驗、能力、判斷力、組織政策 … ，最後所產生的行動。

• 『能不能』當主管，跟『應不應該』當主管是兩個層次：應該當主管，那你就要學習如何讓自己能夠做好管理工作；能夠當主管，不代表應該就要去當主管。
• 能夠星期五部署，在沒有背景環境因素的前提之下，討論應不應該一定要在星期五部署 … 不會有結論。
• 女生能生小孩，不管怎樣都抓去當作生產機器，沒有人會同這種做法的。

來源：X戰警的倫理學：X教授與萬磁王的正義論 Xavier vs. Magneto

類似的 … 自己列舉生活中的例子 … 太多了，像是：

• 女生能生小孩，所以女生一定要生小孩。
• 男生能承擔，所以不能哭
• 工程師能寫程式，所以應該會修電腦
• 薩諾斯可以彈指之間消滅宇宙一半的生命，所以他應該要做 …
• …

『星期五應不應該部署？』的問題，通常需要從組織結構、團隊運作、系統架構等層次切入，然後再來討論是否應不應該的問題。類似議題的探討，可以參閱我以下的文章的探討，內容都不是在談技術如何能不能，而是應不應該如何：

• 需要專職的 Release Engineer？
• 事件管理的維度
• 系統發生異常時，第一時間如何快速止血？
• 軟體交付的三體問題
• 導讀持續交付 2.0 - 談當代軟體交付之虛實融合

這兩個層次本質上是不一樣的，不同層次沒沒相對應的背景資訊，是很難找到交集的。

我這場演講 Monitoring Tools 大亂鬥 - AWS CloudWatch 開場用 談武、論俠 當開場，其實本質也是在討論 Should Be, Can Be 的問題，這題目最後的答案會是：俠之大者。

騎士精神、俠之大者

整篇文章的思慮與脈絡是用 騎士精神 貫穿，也就是：

你應該，所以你能夠。

如果你所處的環境是『應該』在星期五也能部署，那麼團隊就要具備『能夠』在星期五部署承擔風險的能力 (Skills / Ability) 。如果你處在的環境覺得『不應該』，那麼身為一個專業的工作者，面子很重要，你也要讓自己能夠有在任何時間部署的能力 (Skills)

專業工作者，要具備 騎士精神，也就是：

你應該，所以你能夠。

套在主題：

你的團隊應該能隨時部署，所以即使是星期五團隊也能夠部署。

而不是：

你能夠，所以你應該。
你的團隊能夠星期五部署，所以以後應該星期五部署。

類似的概念，在金庸小說裡，就是 俠之大者。

後記

我建議大家看看這段很有深度的電影分析，裡面的 騎士精神 就是我整個思緒脈絡的源頭，因為生活中很常看到類似的現象：

延伸閱讀

站內文章

• 個人著作《SRE 實踐與開發平台指南》 (2023/08 上市)
• Infra 團隊適合 Scrum？
• 演講：Monitoring Tools 大亂鬥 - AWS CloudWatch
• 需要專職的 Release Engineer？
• 事件管理的維度
• 系統發生異常時，第一時間如何快速止血？
• 軟體交付的三體問題
• 導讀持續交付 2.0 - 談當代軟體交付之虛實融合

相關討論整理 (懶人包？)

• 10/16: Joey Chen 轉貼到 Scrum Community 的討論
• 10/16: Ant 補充說明，國外的看法
• 10/15: Joey Chen 的討論：一天部署超過10次，但週五不行部署？
• 10/13: DevOps 轉貼 Ant 文章的討論
• 10/13: Ant ModernWeb 的發表預告：《 Testing in Production, Deploy on Fridays 》 (1/3) - ModernWeb2020

參考資料

• X戰警的倫理學：X教授與萬磁王的正義論 Xavier vs. Magneto