# 大型團隊落實 CI/CD 的挑戰 - Andrew Wu（吳剛志）│91APP

{%hackmd s5C2l4iTQ7yK8Pg4ASCGvw %}

###### tags: `DevOpsDays Taipei 2021`

### 相關連結

* 簡報下載: https://docs.google.com/presentation/d/1OIfx3BN2ZV7OPwAACk6SwrsPvxtOEuGqH8AWPodmaIk/edit#slide=id.g1017f446193_0_114
* 講者介紹: https://columns.chicken-house.net/about/
* 過去相關的演講 (這場演講有提到的參考內容):
* DevOpsDays 2018: [Service Discovery](https://fb.watch/9t-DmqUnRT/)
* DevOpsDays 2019: [從零開始的 DevOps - 吳剛志（Andrew Wu）](/eQAm5_nrTyuo9R8aL7WEKQ)
* .NET Conf 2019: [大規模微服務導入 - #2 從零開始的微服務 .NET Core 框架設計](https://fb.watch/9t-XRpq7qu/)
* .NET Conf 2020: [非同步系統的服務水準保證 (SLO)](https://columns.chicken-house.net/2021/06/04/slo)

----

> 請從這裡開始共筆

超譯開場：
要落落長的說 CI/CD 其實蠻無聊的
當規模逐漸成長時
你都不知道是架構的問題，還是程式的問題
當規模逐漸成長時你需要面對不太一樣的問題
所以今天我希望帶給各位的是不同面向的部分
脈絡上我會逐漸帶出過去分享的演講
也許大家都能夠從中獲得對自己有收穫的地方

### 大型開發團隊遇到的挑戰：
當你要面對的客戶變多
不只是海外市場
還需要建立服務給客戶使用
是屬於多環境多租戶又有海內外的狀況時
其實遇到的問題完全不同以往

### 誰適合聽這演講：
**會問這問題的人，就是需要聽這演講，不然你不會來**

### 大型團隊面臨的狀況：
- 大家對於 CI/CD 的期待不一樣
- 使用套件不同
- 不同產品不同環境的差異化

### 如何自動化
- 先不要急著自動化
- 先觀察 Container 怎麼解決部屬問題
把 AxBxC 的問題簡化成 A+B+C
- Code / Configuration / IaC
- 如果是不同市場的服務，確保程式碼是不是同一套，如果沒有做成 config，你就會因為你不同市場的不同程式碼付出代價
- Feature toggle

Infra：
- docker: dev
- k8s

Artifact:

組態設定：
- 精簡設定: dev
- 內部環境設定: QA
- 正式設定: production

***不要把環境變數跟application設定混在一起，不能集中管理的都不算***

### 如何讓營運團隊能掌控系統狀況
dashboard
- 對外公開，給外面看服務是否正常
- 內部，更多資訊

### 環境管理的問題
如何測試新服務？
新服務可能有dependancy，無法單獨測試
建置一個全新的環境給這個測試 ($$) / 建置虛擬化的測試環境

如何建置「虛擬化的測試環境」
看似簡單，91app的實作經驗是有點複雜

只靠SRE/devops engineer夠嗎？
投影片中列了各種狀況，如果有遇到哪條路不順，就是要優先改善的

----
以下閒聊：
不愧是 91APP，連共筆的編排都已經替大家設想好，真的完全實踐了 Ruddy 老師說的 DX

DX 感受良好 :D

91APP 的股票我都找不到好的時機買進，每次要買就被拉上去

是說，可以問 91APP 為什麼去國外上市嗎？
不是因為台灣市場太小嗎？
我是聽說台灣上市條件比較嚴苛？91APP 相對多數公司都算是穩定成長或是穩定營收都去國外上市，那應該大部分的公司都不會想在台灣上市了吧（望向 GOGORO）。

----

### 問題提問

請問：
1. 會鼓勵聽眾盡可能去取得 Microsoft MVP 嗎？感覺除了一般開發之外，還要額外有一些貢獻才有辦法取得。
> 答 (2021/11/24 22:12): 因果關係弄反了 XDD, Microsoft MVP 其實是你對社群有貢獻後，Microsoft 給你的獎項而已。他不是證照，也不是個職位，除了一些廠商或 Microsoft 自己贊助的軟體授權或是 azure 額度之外，沒有太特別的優惠了。取得 MVP，只是代表你在社群的貢獻獲得肯定而以。
>
> 把它當作肯定會比較自在一點。你應該盡可能的在社群做出貢獻，自然會有機會取得 MVP；而不是刻意為了去取得 MVP 獎項而去貢獻社群 (划不來的) XDD。

2. 不同環境、不同地區會使用到不同的雲端服務、如何使得每個雲端服務都可以正確部署、正確測試？
> 方法很多，不過我是 infra 大外行... 如果你真的需要跨不同的雲端平台的話，找有能力橫跨這些系統的 IaC 系統來幫你解決吧! 直接採用 kubernetes 是一條路，或是用 terraform 這類的系統是個做法。

3. 對於不同國家的市場，可能會遇到一個問題，就是經營時間不同，可能先有台灣市場，之後才有海外市場，造成不同市場也許版型或是功能會有差異，此狀況該如何說服 Marketing 的人盡量單純化（使用 i18n 做出多國語戲就好，而不是維護兩套大部分一樣的系統）？
> 首先，你要先區分 Marketing 的人講的 "需求" 到底是什麼。我自己就碰過客戶說要英文版，有的是指操作介面要英文的 (這個單純 i18n 介面就夠)，有的是指上架的商品內容說明要英文的 (客戶自行輸入的商品資訊要 i18n)，有的是要能做外國人的生意 (要能用美金結帳)，有的是.... blah blah...
>
> 這些都可能是面對不同國家市場要面對的問題，弄清楚才知道最佳的解方是什麼。也許理解之後，維護兩套系統才是最容易的 (咦?)。這時這問題會回到，你如何把這兩套系統收斂成同一份 code + 不同的 configuration, 不能省下兩套部署，至少省下兩套 code 的開發與維護。

4. config as code通常跑一陣子後，就會有非常龐大的config，看起來無比複雜，會比code還難維護得多，code沒用到的部份IDE會幫你檢查到，但Config沒有，請問怎麼解決這個問題？

5. 多租戶的雲端配置，這樣 private subnet 裡面的 ip 不會不夠用嗎？這樣是如何管理不同租戶的網路？雖然不同使用者使用自己的服務不互相影響，但是總會有個 CI/CD 中台去連接這些服務吧？

6. config as code 及 infra as code 是否有辦法auto testing?

7. 不好意思，問比較細，整個devops建起來就包含監控，若向貴公司這種大型的，需要監控的東西很多，發生問題了就有警示，幾天一個或一天幾個警示都會有人注意、處理，有人在意，但大到一個程度也許是一小時好多個，這樣警示就會被忽略，請問你們是如何解決警示問題？或是如何警示？謝謝

8. 請問有關 Testing in Production with load/stress testing, 貴公司是否有這樣的 practice? 若有的話, 是如何避免將 Production 弄壞 or isolate?
另外有些 case 可能不適合在 Production 上進行, 而會選擇在 like-produciton (maybe stage) 上做測試, 想問貴公司是如何衡量 stage 的測試結果對應到 production 上的 cluster/architecture 規模呢? (e.g. 如何在 stage/prod simulate 雙 11 流量), 謝謝

----

### 簡報內容

##### `P1`

##### `P2`

##### `P3`

##### `P4`

##### `P5`

##### `P6`

##### `P7`

##### `P8`
- 應該先解決為什麼你的情況特殊

##### `P9`

##### `P10`

##### `P11`

##### `P12`

##### `P13`

##### `P14`

##### `P15`

##### `P16`

##### `P17`

##### `P18`

##### `P19`

##### `P20`

##### `P23`

##### `P24`

##### `P25`

##### `P26`

##### `P27`

##### `P28`

##### `P29`

##### `P30`

##### `P31`

##### `P32`

##### `P33`

##### `P34`

##### `P36`

##### `P37`

##### `P38`

##### `P39`

##### `P40`

##### `P41`

##### `P42`