1.
協辦 特別贊助

2.
關於我
 Kingston Technology 資訊處 經理
 前 友達光電 營運資訊處 副理
 前 精密設備機械 CIM處 課長
 2013~2018 微軟最有價值專家
 台中 Study4.TW 成員暨講師
 2018 DOIS DevOps 深圳 講師
 2018 DevOps Day Taipei 講師
 2017 Microsoft Global Tech Summit 北京站 講師
 2017 Agile Tour Hsinchu 講師
 2017 製造管理新智慧 講師

3.
Agenda
DevOps 引
DevOps 團隊文化
DevOps 流程
DevOps 技術架構

4.
Dev & Ops
Scrum & DevOps落地於製造業難不難?

5.
DevOps
製造業不適合完全複製資訊產業模式

6.
極度仰賴IT的產業
新產品規劃
採購製造出貨
ERP
客戶關係 人力資源 財務管理
供應鏈管理
後勤管理
研發管理
客戶 & 銷售
供應商

7.
IT協助企業數位轉型
企業神經中樞，串聯所有資訊
聯繫企業內、外資料的紐帶
IT 效率影響企業的市場競爭力
協助企業數位轉型的關鍵之一
敏捷的IT團隊，才能替公司獲利
企業創新的驅動力之一

8.
大部分製造業IT的現狀
系統眾多、維護成本高，間接影響開發時程
交付需求的時程，趕不上市場變化
開發與維運的溝通成本高，系統修復時間長短
IT人員有一定的編制比例
IT人員的品質、能力不一
承受「失敗」風險的較低

9.
開發特性
製造業的IT是需求開發，非產品開發
專案需求只有交付日期，維運卻沒有終止日期
常見的場景:
交付第一版需求後，用戶才能準確說出自己的需求
確認完整的需求時程，趕不上市場變化
需求優先權，變化莫測
需求範圍大小，無法一開始就說明

10.
開發與維運
「開發」強化企業獲利能力
「維運」穩定企業獲利來源
「開發」和「維運」失衡對於企業營運有極大影響
「維運成本」＞＞ 「開發成本」

11.
DevOps 團隊文化

12.
養成 DevOps 思維
持續交付價值給我們的用戶
縮短發佈到用戶的週期
持續發現問題、持續改善

13.
遵循DevOps原則
系統思維
放大回饋機制與循環
接受失敗和持續學習的文化

14.
建立DevOps的七種習慣
自我組織團隊的目標須與企業目標一致
嚴格管理技術債
專注客戶/用戶的價值流
假設理論、驅動開發
監控正式環境中系統運作資訊
實戰文化
管理 Infrastructure Resource為靈活資源

15.
改變!
習慣改變對於製造業是難度高且風險高

16.
雙軌理論
快速反覆
運算
貼近需求 時程預估維持適應
持續整合 持續部署持續反饋 減少浪費
Waterfall Scrum
DevOps

17.
One Team
開發團隊

18.
DevOps團隊文化
團隊每個人一起致力讓系統能夠平穩且有效率
資訊透明、互助合作，共同承擔成功與失敗
團隊每個人互相扶持、相信人人都可以改變
每個人努力讓團隊變得更好，不是追求自我成功或是價值

19.
DevOps 流程

20.
需求
80
20
工程需求
建構Infrastructure、系統的改善或
重構項目。 須放在同一個Backlog
被追蹤和完成，不可以被排除
用戶需求
來自商業需要的功能或是使用
者需求

21.
版本管控
建立有效的版本管控與分支策略
簽入的程式碼必須有相對應到工作項目
只要是程式碼，一併都要納入版控
基礎結構即代碼，環境的需求變更也需要被管理

22.
持續整合、持續發佈

23.
製造業真的適合每日、每小時的頻繁佈署嗎?

24.
Release vs. Deploy

25.
測試
自動化是測試的關鍵
單元測試、整合測試、UI測試到負載平衡測試都是屬於持續測試一環
使用增量和反覆運算方式，讓測試的深度不斷前進
別期望一開始就寫好所有測試案例
最好的測試，就是增量測試

26.
監控與學習
提升品質
提高安全
增加可靠性
持續提供價值給用戶
瞭解使用者如何使用系統

27.
團隊的量測指標
不特別關注
Task預估完成時間
Task總共花多久完成
代碼行數
在一個Sprint每個成員的Capacity有多高
User

28.
團隊的量測指標

29.
DevOps 技術線

30.
DevOps 循環
Agile Planning
Delivery plans
Dashboard
Kanban boards
Build and Test
Git source control
Continuous integration
Security scanning
Open source compliance
Cloud-based device testing
Release
Continuous delivery
Functional testing
Release management
Monitor and Learn
App performance monitoring
Infra & platform monitoring
Diagnostics & debugging
Log analytics
Usage analytics
Mobile crash reporting
Plan +
Track
Monitor + Learn
DevOps
Release
Develop + Test
DevOps

31.
工具鏈抉擇
企業團隊需要確保不同團隊使用的工具是可以整合
工具間整合不夠完善，會導致許多團隊發生碰撞
有效的整合工具，是支持開發和運維方面最有幫助的技術
減少人員對工具開發和運維的成本
即時因應市場變化，即時應對
工具目的在於將時間花在商業目的，而不是工具技術過程

32.
DevOps架構推進
從新專案、新系統，或新團隊開始導入DevOps思維
系統架構必須是低耦合，所以，系統架構最好能重新設計
100%自動化是理想，不實際 ; 80% 自動化，20% 人工作業較為理想

33.
自動化好處
讓人可以不必執行重複性且單調的工作，並減少人工錯誤
讓人有更多時間，創造公司的商業價值
自動化比手工更高效率
自動化可以提高發佈的品質。 因為佈署的步驟標準化， 並能在確保的環
境與流程中，預期後續產生的結果
從中長期來看，自動化可以降低整體成本

34.
我們DevOps 流程
團隊
雲與端DevOps
應用程式
Check in Code
整合
部署
部署
部署

35.
我們DevOps 之容器化流程
團隊
雲與端DevOps
應用程式
Check in Code
整合
部署
部署
部署

36.
為何使用容器化技術
減少程式佈署，造成的服務停止時間
確保測試環境與上線環境是標準化且固定
降低系統內部的耦合程度、降低維運複雜度
快速發佈新功能

37.
容器化的持續整合
集成 容器化代碼
Docker Store
應用程式
設定腳本
注入
持續整合
容器化 部署測試環境
部署正式環境
運行環境
設定腳本
運行環境
設定腳本
注入 注入
持續部署
Approve
環境遷移

38.
「監控」是 DevOps重要的一環
製造業推行DevOps中，監控是最需要優先被導入
隨時隨地可接收問題的即時反饋
開發與維運人員能即時共同討論解決方案
訊息必須公開透明
「監控」要點
系統任何錯誤資訊皆須回饋
系統效能監控
節點進出資訊必須監控
監控資料必須被分析

39.
循序推進
從小團隊開始推進、解決問題思路優先

40.
DevOps需持續反覆迭代
找出合適團隊方法與流程，即時改善

41.
DevOps 起手式
第一步: 消除浪費
溝通浪費
人工浪費
找問題的浪費
任何對團隊造成影響的浪費
DevOps 究極 = 一個高效的協同合作團隊

42.
製造業適合用DevOps嗎?
人的心態因素永遠是影響最大
被｢舊｣系統永遠羈絆著
部門間的政治問題
先建立起敏捷的｢精神｣、再有敏捷的｢流程｣
DevOps不會讓專案加速完成、有時候反而變慢
Top-Down & Bottom-Up 最好都要有