# 臺灣企業 DevOps 能力大公開 - 王宏仁

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

###### tags: `DevOpsDays Taipei 2022`
[DORA指標](https://www.devops-research.com/research.html)
主要有四個指標衡量關鍵系統：部署頻率、更新準備時間/改版交付時間、平均恢復時間、變更失敗率（指標要全部一起看，並非單一一項好就是好）

14.2%企業強化DevOps迎戰新常態

2022 年 CIO 年度 Top 目標

IT 預算占營收企業營收的比例
平均只占 2.48%，以政府和金融最多

以金融 6.2 % 為例
如果知道預算
其實可以回推公司的的營收
或是從公開資料中透過營收計算企業用在 IT 預算的金額

大型企業IT預算3.3%用於DevOps

資料來源: iThome 2022 CIO大調查
https://www.ithome.com.tw/article/152581

### iThome 2022 CIO大調查 系列文
* [【iThome 2022 CIO大調查(上)】企業永續新常態下一步](https://www.ithome.com.tw/article/152321)
* [【iThome 2022 CIO大調查(中)】企業IT新戰力](https://www.ithome.com.tw/article/152585)
* [【iThome 2022 CIO大調查(下)】各產業數位轉型加速，IT大步邁向雲原生](https://www.ithome.com.tw/article/152873)
* [2022年度CIO大調查報告下載](https://www.cio.com.tw/annual-cio-survey-report-2022-pdf-download/)

[Google Search Result](https://www.google.com/search?q=ithome+2022+cio%E5%A4%A7%E8%AA%BF%E6%9F%A5&rlz=1C5CHFA_enTW1013TW1013&oq=ithome+2022+CIO&aqs=chrome.0.0i512j69i57j0i512.5009j0j7&sourceid=chrome&ie=UTF-8)

Cloud也是影響DevOps成功與否很重要的因素之一，評估預算時可一起考量

今年醫療開始上雲

台灣IT從業人數10萬人，開發人數6萬人

製造業開始提高開發人力比重

案例:星展銀行約3萬人，有1萬是IT,他們認為在這個環境下IT應該要佔多數才有足夠的戰力

[Google State of DevOps 2021報告下載](https://cloud.google.com/devops/state-of-devops)

## DORA 指標績效
團隊開發速度：
- 部署頻率：自評關鍵AP更新程式碼後部署到正式
- 更新準備時間/改版交付時間：從程式碼 committing 後到正式運行 running 所需要的時間

> 個人倒是很好奇，能做到按需部署，於 1 小時內更新準備，有多少是有落實資安合規？
> [name=Kehao]
> 落實資安合規其實有一些討論空間，比如說連線資訊怎麼存放
>
> 這一小時是否包含事前的測試與內部表單放行?
>
> 以釋出流程來說，可能需要爲了 ISO27001 合規，加入需求代表、資訊代表的人工審核流程以留下審核記錄。如果是金融業，PCI DSS 合規又有更多流程規章
> [name=Kehao]
>
> 看到一銀希望成為自主學習組織，正在導入 DevSecOps，我覺得還蠻可笑的（?），我記得進去的人不是都只想要養老嗎？
>
> 敝公司也是有蠻多同仁是來養老的，但還是有在做事的同仁。根據經典的懶螞蟻效應，每一間公司總是會有一定比例的冗員
> [name=Kehao]
>
> 之前待過幾間公司的感覺
> 一小時內更新準備而且要合規
> 基本上還是辦得到的
> 只是底層基礎架構到自動化工具需要一點時間調整
> 不過這些只是開始
> 需要同仁對於系統的更新和變更是有在線上
> 基礎的安全有認知，至少不會有共用帳號、Credential的問題
> 接著還需要主管有在協調實行
> 個方便搭配的好其實才有機會快又合規
> 可以理解成 F1 賽車換輪胎的那種感覺

軟體品質與穩定性：
- 平均復原時間(MTTR)：自評關鍵AP改版發生當機或事故而停擺，到恢復運作的時間
- 變更失敗率：自評正式環境中的關鍵AP更新或改版結果不如預期而需補救的比例，如緊急修補、退回前版、重新發布或修補程式。

※ Google 調查時未針對國家和地區，而是全球性的調查。

[谷歌 DORA DEVOPS报告 2021](https://www.continuousdelivery20.com/blog/dora-2021-report-detail/)

據統計採用SRE可取得兩倍的DevOps績效

[【iThome 2022 CIO大調查(中)｜新興技術熱門趨勢】](https://www.ithome.com.tw/article/152583)