星期五要不要部署?


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

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


熱門話題:『星期五要不要部署?』

前情提要

在軟體業界,有個普遍不成文的共識:

星期五不要部署、更版

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

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

雙方的說法

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

一個團隊當要能夠在任何時間部署,這跟哪一天沒關係,理由是敏捷團隊應該如何、身為一個開發者應該如何 …. (省略 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) 是能設計架構、能夠管理團隊、有領導力 … 等。『應不應該』則是依照時空背景條件,依照個人經驗、能力、判斷力、組織政策 … ,最後所產生的行動。

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

實然 (is) 不等於 應然 (ought)
來源:X戰警的倫理學:X教授與萬磁王的正義論 Xavier vs. Magneto

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

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

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

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

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


騎士精神、俠之大者

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

你應該,所以你能夠。

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

專業工作者,要具備 騎士精神,也就是:

你應該,所以你能夠。

套在主題:

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

而不是:

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

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


後記

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


延伸閱讀

站內文章

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

參考資料



Comments

  • 全站索引
  • 關於這裏
  • 關於作者
  • 學習法則
  • 思考本質
  • 一些領悟
  • 分類哲學
  • ▲ TOP ▲