最近我開始用 Go Live 取代 Production 這個詞。

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

定義

Go Live 不代表只有 Production，也包含內部使用的環境：In-House。

• Go Production：指的是對外的環境
  • 像是：Staging、Canary、Sandbox、Production
  • 開放給外面試用的 Field / Sandbox ….
  • Production 另一個維度：DR Site (災難還原)
  • 多資料中心的 Production，例如業務範圍屬於東南亞，Production 實際上有三個 Data Center 服務同一個區。
• In-House：指的是內部開發過程中的各種用途，
  • 測試用：包含功能性測試 (Functional)、系統性測試 (System)、整合性測試 (Integration) … 等。依照測試目的性而建置環境，詳細參閱：淺談軟體測試的階段與策略
  • 可以是實驗用環境 (Lab)：架構師、新創服務團隊做實驗用

只關注 Production 很容易忽略其他地方，能動就好 是很多公司都有的問題，特別是測試環境。測試環境的可部署性、可測性決定未來 Production 配置的靈活與敏捷性。而 Proudction 的問題，必須要能夠在 In-House 能夠重現，如果只能線上修，風險就會很難控制，特別是有些效能屬於 嚴重、但不緊急 的。

!!! 大問題都是從小問題累積的 !!!

不管是 In-House 還是 Go Production，都要面對底下四個問題：

1. Artifact Management
2. Resource Provisioning: 建置環境，分成 Infra-Level、VM-Level
3. Config Management: 配置管理
4. Deployment: 部署策略, 不管是 Direct Overwrite、Staging、Canary、B/G、A/B …
   • 前提是：1), 2), 3) 要具備
   • 跨區部署，多資料中心的 Production

Resource Provisioning

文章：Resource Provisioning and DevOps 整理過基礎概念，實際上 Resource Provisioning 範圍可大可小，單一台機器 (VM-Level) 來看，如下圖：

如果是一個架構，那麼 Provisioning 就要包含架構的部分。所以實際上 Resource Provisioning 分成兩個層級：

• Infra-Level: 包含整個網路架構、相關依賴的服務，在 AWS 上來講：
  • Network-Level: VPC
  • Service-Level: ElastiCache、ELB、DynamoDB、S3、CloudFront …
• VM-Level: 主要就是 EC2 裡面的東西，包含中介軟體 (Middleware)、應用程式自己
  • 如果有用 Container，這就算是了。

底下這張圖是我在 DevOpsDays Taipei 2018 演講的 Slide，重點在於看到整個抽象架構的樣貌，了解了這個全貌，所謂的 Infra as Code 才能做出有彈性、且快速的建置。

Live Music!

Live 對樂手來講就是 現場，現場 不管是兩萬人的大場子、還是只有一個聽眾 + 3 個員工的小 Pub、還是在安靜到連血液流動聲都聽得到的錄音室，都是現場，面對的態度應該都是一樣，但是做法會有差異。

• 大場子：越大的場子，干擾因素越多，意外狀況越多，不管是天氣、團員、燈光、音響設備、樂手的問題、售票的問題。。。
• 小場子：干擾就不多？站上舞台發現台下只有三個人，一個人是聽眾，一個人是服務生，另一個是老闆。。。團員有五個人。。。這干擾壓力也很大。。。
• 錄音室：安靜到不像話，沒有干擾？製作人、錄音師、弦的味道、耳機、椅子的高度、空氣的流動聲。。。錄了兩百次還錄不好 …..

樂手面對不同的環境，就可以有不同作法，像是：

• 大場子當然火力全開，舞台百個三十個音箱陣列 (Stack)，吉他擺個十把當裝飾，各種金屬裝飾都往身上帶。。。
• 小 Pub 音量可以開小一點、燈光可以不用那麼炫、效果器不用開那麼重，但是音樂表達的內容依舊是 awesome!

完整描述請參閱： 簡單、複雜

一個專業樂手，或者有經驗的樂團，什麼環境都可以感到自在，且處之泰然。

談現場

Back to the Code

所以用 Go Live 表示，只要變成現場要用的東西，都很重要，從小地方就要做到好，而且要能知道取捨。無法 快速蓋起環境，就:

• 不容易找架構性問題
  • 無法看到全貌
  • 頭痛醫頭，腳痛醫腳
  • 最後變成癌細胞
• 不容易自動化測試
  • 回歸測試只是夢, 參考經驗談 Designing Test Architecture and Framework
  • 自動化很脆弱
• 不容易找效能問題
• 不容易監測
• 成本會越來越難估算
• 生意來了吃不起
  • 沒那個屁股
  • 用再好的 Cloud 都是白搭
  • 因為環境根本建不起來
• DevOps 只是一種神話、鬼話、幹話

有人會問說，我們沒做你說的這些東西，Production 都跑得好好的，也賺很多錢啊！問題不會發生在這 一個 Production，但是一定會發生在下一個 Production。如果你覺得沒差，那這個環境一定不是你負責建置的。信不信，你下次搬家時，就會發現家裡很多東西不知道怎麼搬。

我就是很龜毛。。。妥協要學習，但這是原則，這就是軟體工程要知道的。

延伸閱讀

• Resource Provisioning and DevOps
• 淺談軟體測試的階段與策略
• Software QA 的職能條件
• Emergency Response
• Designing Test Architecture and Framework
• Artifact Management
• 演講：從緊急事件 談 SRE 應變能力的培養
• 個人著作《SRE 實踐與開發平台指南》 (2023/08 上市)

參考資料

• 簡單、複雜