---

---
# 多雲整合企業應用平台 DevOps SRE 落地實踐 - 胡君怡

{%hackmd @DevOpsDay/BymyqYaeo %}

> 各家講者出來分享自己的經驗多少都有些公司內規和公關要求的限制，有些不方便分享的地方（例如：不要張貼簡報截圖）還請大家多多包涵喔（不然就更多人不敢出來分享了）
> [name=DevOpsDays Taipei 2022]

> 從這開始

###### tags: `DevOpsDays Taipei 2022`

- 全球營運
- 數位轉型
- IT彈性與效能

Revenue Growth for 11 consecutive years:
- Digital Tranformation drivers: Innovation Speed, Business Growth, Operation Efficiency

## IT產品藍圖
- 晶圓廠自動化，良率分析，生產力，研發：製程良率分析，品質管理，廠房設施，智慧化生產製造系統，整合製程控制，機台自動化與優化，數位化運營平台，高階運算架構，現代數據與安全平台
- 數位商務：客戶協作平台(CRM)，技術與產品管理(PLM)，財務與物流管理(ERP)，供應鏈規劃與管理(SCMP)，人力資源管理(HCM)，數位員工工作流程和服務(Digi Work)

### Fab Runs on Code
> 「The Fab Runs on Code」（跑在程式碼上的晶圓廠）這句話是台積電用來形容IT軟體開發的重要性，一座晶圓廠需要仰賴許多IT團隊開發的軟體產品。台積電IT開發的軟體產品（台積習慣以IT產品來形容自建系統），可以分成兩大類，一類是工廠相關，如MES系統、Fab自動化、良率分析相關的軟體產品，另一類則是與業務部門、商業管理相關的產品。前者包括與製程良率分析（Process Yield Analysis）、品質管理、廠務（Facility）、MES、設備控制、設備自動化、IT維運平臺、資安、資料等相關系統，後者則像是CRM、ERP、eBusiness、Product Data Master、供應鏈、人資、供應商管理等。
>
> Source : [台積電數位轉型的下一步，靠AI推動全面轉型](https://www.ithome.com.tw/news/142463)

IT人數2304人，全球員工人數67475

## IT & Digital Business DevOps Journey
### 2019

* VM 搬遷
* 推動容器化
* 私有雲 K8S 建置
* Pilot Scrum/DevOps
* 文化

> 2019 開始做 K8S 然後推廣容器化技術
> 2021 推雲原生
> 這速度效率真的很快耶
> [name=Mark_Mew]
> 只要有專屬團隊部署維運 K8s cluster，需求團隊/開發團隊僅需要當個使用者，推動雲原生其實不會有太多阻礙。個人目前遇到的問題是公司內部沒有專屬團隊建立 K8s 平臺，各個開發團隊自行建立維護，那推行起來就比較多障礙與工作要做，還好後來改使用公雲代管 K8s 事情就少了蠻多
> [name=Kehao]
> 怕是怕在早期系統或是服務開發的...習慣不好，把 AP、DB 都塞在 VM 裡面，API、Portal、Job 也都在同一台上，沒有把握每次變更架構都些微調整，最後這服務會不太好容器化，也不好做 HA（對啦，這是我們公司很多部門遇到的狀況，這兩年才做數位轉型）
> [name=Mark_Mew]

### 2021
- 開始試做agile, scrum，導入devops
- 私有雲走向混合雲架構
- 不是一朝一夕就能改的，並不是改了部門名字就馬上大家都會了
- 前面都是文化的部分，此時才開始走向bussiness
- 走向microservice，做架構上的轉型

## IT Infra and Development Strategy
- 十年前開始有VM
- 2018開始用container，private k8s
- 2021開始用tsmc k8s，自己建，避免vendor lock

## Global tsmc
台灣的data center服務全球客戶，速度非常不理想
上公有雲，資料庫都在地端，有資安疑慮，必須有架構上的改變

一個文件下載，在沒推上公有雲之前，大約要32小時
放到公有雲之後，約3小時

## CI/CD pipeline development
> []

好的團隊跟差的團隊的差異是，他的manager有沒有自己參與在裡面做開發

- 上了雲之後，所有的build code都是在雲端上發生，不會允許工程師在自己的電腦上build code
- small set的code review
- unit test的compulsory指標(UT >= 70%)，推動下去之後讓開發品質更好

## CI/CD for Multi-Cloud Architecture
混合雲的架構已經是確定

## Adopt CI/CD for Legacy or Commercial systems
單體式架構其實最精華的關鍵都是寫在store procedure，非常難處理
要慢慢拔掉 stored procedure
Key transaction 還是存在 Legacy DB
**把單體裡面藏有變動的流程，拆解出去變成microservice
舊的單體盡量不動，把需要動的抽出來，才有機會**

## DevSecOps
掃到弱點，但是schedule已經確定明天要上線，怎麼辦？ --> 只能裝作沒看到，下次再改
時間久了就堆積很多這種問題未解

> 但的確有些需求是配合活動需要準時上線，如果 CVE 突然公佈某個 library 有重大漏洞，要麼開發團隊緊急更新修正，要麼看是否能透過 WAF 撰寫規則做補償，印着頭皮先上線了
> [name=Kehao]

## CI/CD落實在大型團隊
- 大型團隊一定要有各種指標，才能有效推行
- code review有一個新指標，只看新專案的推行率。避免legacy專案造成這個指標數值低落，讓大家不想做

## Shift Business IT from Project to Product
一直被刪掉，可能是不能寫這些
不能寫的話要說，不是一直刪掉，這樣讓寫的人會很不開心的
查

> 才剛離開一下，原來剛剛發生了一些事情
> [name=Mark_Mew]

> 各家講者出來分享自己的經驗多少都有些公司內規和公關要求的限制，有些不方便分享的地方（例如：不要張貼簡報截圖）還請大家多多包涵喔（不然就更多人不敢出來分享了）
> [name=DevOpsDays Taipei 2022]




# Summary
- Plan the corresponding changes on the approach and on the people
- Modernize IT Engagement & Execution Model
- Real-time performance data for CI/CD automation
- Modernize IT techonlogy