owned this note   changed 3 years ago  
Linked with GitHub

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

歡迎來到 DevOpsDay Taipei 2021 共筆

Image Not Showing Possible Reasons
  • The image file may be corrupted
  • The server hosting the image is unavailable
  • The image path is incorrect
  • The image format is not supported
Learn More →

共筆入口：https://hackmd.io/@DevOpsDay/2021
手機版請點選上方 按鈕展開議程列表。

tags: DevOpsDays Taipei 2021

相關連結

請從這裡開始共筆

超譯開場：
要落落長的說 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。

  1. 不同環境、不同地區會使用到不同的雲端服務、如何使得每個雲端服務都可以正確部署、正確測試？

方法很多，不過我是 infra 大外行… 如果你真的需要跨不同的雲端平台的話，找有能力橫跨這些系統的 IaC 系統來幫你解決吧! 直接採用 kubernetes 是一條路，或是用 terraform 這類的系統是個做法。

  1. 對於不同國家的市場，可能會遇到一個問題，就是經營時間不同，可能先有台灣市場，之後才有海外市場，造成不同市場也許版型或是功能會有差異，此狀況該如何說服 Marketing 的人盡量單純化（使用 i18n 做出多國語戲就好，而不是維護兩套大部分一樣的系統）？

首先，你要先區分 Marketing 的人講的 "需求" 到底是什麼。我自己就碰過客戶說要英文版，有的是指操作介面要英文的 (這個單純 i18n 介面就夠)，有的是指上架的商品內容說明要英文的 (客戶自行輸入的商品資訊要 i18n)，有的是要能做外國人的生意 (要能用美金結帳)，有的是… blah blah…

這些都可能是面對不同國家市場要面對的問題，弄清楚才知道最佳的解方是什麼。也許理解之後，維護兩套系統才是最容易的 (咦?)。這時這問題會回到，你如何把這兩套系統收斂成同一份 code + 不同的 configuration, 不能省下兩套部署，至少省下兩套 code 的開發與維護。

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

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

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

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

  5. 請問有關 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

Select a repo