[DevOpsDays] 硬體產業的DevOps導入與實踐 - 以工控產業為例

timwang.work@gmail.com 11
工控軟體部門的
DevOps 導入與實踐經驗
Tim Wang
2018/09/11
DevOpsDays
T P E
2018

王泰翔 (Tim)
來自凌華科技 (工業電腦)
軟體研發兼課長
近年熱衷於改善流程與提升價值

Outline
- 為何工控產業需要 DevOps？
- 痛點、解決方案與實踐
- 實踐 DevOps 帶來的成效
- 有坑別踩

Topic 1:
為何工控產業需要 DevOps？

「工業」，相對於「消費性」
高毛利？鐵飯碗？系統廠？製造業？

標準認證
自動控制
系統平台
機器視覺
訊號量測
馬
達
監
診
光
學
檢
測
橋
樑
監
控
手
機
測
試
無
人
產
線
智
慧
工
廠
工
業
需
求
應用場域
特殊協定
防塵耐候
需
求
/
機
會
/
客
製
化
應
用

20年
產品維護生命期
115款
多樣化硬體產品
>700個
底層控制函式
單看量測產品…
Continuous!

客戶選定的電腦平台
Functional API (C/C++) & Examples
Kernel Driver
OO API (Python/C#) / Algorithm / Protocol
Eco-system Adaptor
PoC Application
Hardware
Products
客戶選定的作業系統
Solution Stack
Scenario
研發產物與用戶型態

新產品開發
通常是硬體產品…
舊產品維護
即便是硬體有問題
能只改軟體就不改硬體
可行性研究
AI, Big Data, Cloud, …
舊產品改版
產品硬體料件漲價/停產得換料
軟體得改但不能影響到使用情境
軟體需求的來源？
運維？！

給自己的運維一點定義吧
確保一系列產品能夠長期穩定運作 20 年
加新需求必須做好實作隔離及測試
確保軟體發佈能夠快速上線及可靠穩定
其實跟軟體服務業的運維目的性非常類似…
十分有理由
結合CI/CD

硬體產業的 PLC (PLM)
提案（P1）
計畫（P2）
設計（P3）
原型（P4）
試產（P5）
量產（P6）
有沒有針對SDLC定義?
長生命期? 工作分解? 迭代?
長週期
甘特圖
瀑布式

需求規格
散亂不清
變更
難以追溯
沉重的
歷史資產
散亂多變
的工具鏈
測試牽涉
硬體組態
多樣的
釋出組合
訊息遲滯
透明不足
需求多變
長期交付
品質穩定
理想上，有SDLC就好了

軟體人的價值與機會
開發 & 運維滿足速度、品質、不浪費，
同時能發揮硬體優勢找到新戰場！
忙都快忙死了！怎麼辦？

硬體優勢是什麼？

數據化、標準化
省成本、速度快、品質好
人、機、料、法、環

Toyota Production System (TPS)
Just-In-Time Production (JIT)
成本(少浪費)、快、標準化
做太多
等待
輸送
加工
庫存
動作
不良品
產能太低的工人

Six Sigma
品質、去變異(少浪費)、經驗/統計
https://en.wikipedia.org/wiki/Six_Sigma

ISO 9000
數據化、流程化、全力發揮(人)
https://en.wikipedia.org/wiki/Six_Sigma
超越客戶期望
完全投入達成組織目標
為了組織利益完全投入貢獻所能
流程化管理持續改善是持續性目標
以資料/資訊做決策

timwang.work@gmail.com 1919https://dotblogs.com.tw/jimmyyu/archive/2015/08/30/how-to-earn-the-respect.aspx

Topic 2:
痛點、解決方案與實踐

先舉個關於「協作」的案例

過去常見的景象
一包 Legacy Code 他的版控長這樣
好心的前輩寫的
Readme.txt

共通點？
1. 過程蓋很久
2. 擺著沒處理
(或因故處理不了)
3. 等到要拆很麻煩
4. 面臨時間壓力
糟了，是世界奇觀

推動 Collaboration 的阻礙有很多
DevOps 要怎麼推下去？

痛點主要影響引入對策
需求規格散亂不清知識/溝通知識管理
變更難以追溯知識/溝通原始碼版控
任務/缺陷追蹤
訊息遲滯透明不足溝通/效率任務/缺陷追蹤
看板
團隊溝通工具
沉重的歷史資產效率/品質原始碼版控
持續整合
散亂多變的工具鏈效率/品質持續整合
多樣的釋出組合效率/品質持續整合
持續交付
測試牽涉硬體組態效率/品質持續部署

版控一切該版控的產物
“軟體開發的本質：獲取及保存知識” by Terry Yin
追溯變更
知識資產管理

需求分析文件
追蹤進度/變更
變更透明易分享
需求統整管理
追溯變更
透明共享
(Fig. 1)
在 Confluence 上將專案需求、設計圖進
行文件控管及分享
(Fig. 2)
所有的工作分解後記錄在 JIRA 上，並且可
以透過付費 plug-in 把版本控制連結到
JIRA 上，每個工作內有多少變更一目了然
(Fig. 3)
承上，在 JIRA 介面中可以輕易看到類似
Git 的 diff 畫面，可以進行很輕量、快速的
分享與討論

進版前相互把關
看板帶來數字感
看板進度透明化
追溯變更
透明共享
(Fig. 1)
在 Merge branch 前會透過 peer-review
的機制進行相互確認，讓「進版」這件事更
加正式且透明。
(Fig. 2)
工作分解記錄在 JIRA 上後，可以透過內建
看板快速呈現工作的狀況，跨團隊成員可以
輕易地知道整個專案的全貌及現況，不需要
等到例行會議才同步狀況。
(Fig. 3)
看板除了呈現狀態，也可以呈現數字感，不
管是「當下」的狀態分布，或是「按區間」
抓出時間分布，可以看到一些趨勢。

人
案
週報系統化
數據趨勢透明化
專案分配透明化
透明共享

改變溝通工具
工作規劃透明化
透明共享
(Fig. 1)
日常透過便利貼進行一些活動，例如讓成員
對於一個大需求(epic)提出自己的想法、如
何拆解工作？避免像 Ruddy 老師也提到的
跑 Scrum 跑到不知道 Story 的全貌是什麼。
也會在需求完成後做回顧會議，了解過程中
做的好或不好的地方，給予鼓勵或協助。
(Fig. 2)
日常聯絡工具使用 Hipchat/Slack 這類協
作工具平台，不使用 Line / 微信，避免與
私人訊息混雜在一起，公私分離。每天上班
第一件事是在固定的頻道上發表「昨天做什
麼、今天預計做、以及可能需要的協助」，
可以幫助大家做自我計畫、事後回查及增加
內部透明度，彼此提供協助。

靜態掃描
歷史資產管理
透明共享
[目的]
掌握 Duplications
避免 Memory Leak

Build/Unit .Test
Kernel Driver
Build/Unit Test
API DLL
Release Signing
(non-Win10)
Pack cabinet
file (*.cab)
EV Signing
(Win10)
Submit to MS
HW Dev Center
等待回應
Generate
hash log
Pack runtime
components
(*.msi)
Build/Pack
utilities (*.msi)
Pack samples
(*.msi)
Pack installer
(exe)
Submit to
VirusTotal
等待回應
第一代pipeline
工具鏈整合
釋出組態管理
[目的]
自動化所有須常態釋出
的交付組態(包含M$的
attestation signing)
[成果]
視實際狀況可在 30 分
鐘左右產出交付檔案
節省前置作業及等待時
間約30分鐘

任何人都可以輕易取
得最新的可執行檔
(展示/測試/知道進度)

Kernel
Driver
Unit test Build
Release
Signing
(Attestation
signing)
Pack
cabinet file
Local EV
Signing
MS HDC
(傳送並等待)
API DLL Unit test Build Smoke Test
Middleware
Utility
Unit test Build Smoke Test
Component
(msi)
Generate
hash log
Pack
runtime
Pack
utilities
Installer
(exe)
連結
需要的元件
VirusTotal
(傳送並等待)
主動通知
業務單位
第二代pipeline
工具鏈整合
釋出組態管理
[改進點]
- 沒彈性
- Artifacts 重複產生
- Artifacts 不易取得
[成果]
視實際狀況可在 2 ~ 16
分鐘內產出交付檔案

取得掃毒報告
檔案指紋存檔
系統通知/紀錄
釋出管理與安全把關

16 歲的產品配最新最快的電腦？
10 歲的產品說要加功能？
OS 改版了，軟硬產品全要重測？
（人工測試？工人測試！）
持續部署做什麼？情境模擬…

Artifact Repository
Infra. Automation
待測平台 (IoT) 待測平台 (PC-based)
從交付到部署
[成效]
- 自動化設定平台組態
- 自動化測試腳本的遞
送與執行
- 整合測試帶來高信任
Continuous Delivery
Cont. Deploy
組態自動化
簡化硬體測試

套件管理標準化
全自動迴歸測試
組態自動化
簡化硬體測試

導入平台虛擬化
效能監控與通知

測試環境
Intranet
Internet
DevOps 內部服務平台

Topic 3:
實踐 DevOps 帶來的成效

省下了很多…
前置準備時間
操作時間
等待時間

需求
設計
開發
驗證
封裝
交付
整合
確認
回饋
分享
建立開發流程

timwang.work@gmail.com 4444Ref: <The Nature of Software Development>, Ron Jeffries
大道至簡：「價值」

省下時間然後呢？
抽象化，Functional 改 OO
學需求分析、架構設計
學系統工程、實驗設計
學商業思維，拉高視角

老闆
Sales / BD
主管 / PM
基層 / RD
商機 / 價值
方案 / 需求
設計 / 架構
自動化省時
正向循環負向循環

DevOps 在硬體產業是可行的
先找到痛點，再用工具輔助

對應CALMS

Topic 4:
有坑別踩

聽完這兩天的議程
手刀跑去找老闆提案？

Collaboration
Automation
LEAN
Measurement
Sharing
Common Pool
工廠自動化？有啊
快+好+省對吧？超懂！
KPA、KRA、KPI、BSC
週報、月報、離職交接
突然談起 DevOps Culture…

DevOps
LEAN
Software
Development
LEAN
Manufacturing

少說多做，用行動引領思維

少說 – Buzzword

敏捷是潮流
敏捷都不寫文件
軟體才有未來
軟體生意是空中樓閣
有DevOps就夠了
DevOps是IT的玩意
瀑布式就是效率差
CMMI 才紮實
做硬體只是代工
賣硬體才有真實感
敏捷太抽象沒成效
製造業有LEAN就好
對立與誤解

多做 – 小步快跑PDCA

我很想 DevOps，但 IT 不幫我…

年輕！
熱情！
手腳快！
（看似廢話，容易嗎？XD）
成員怎麼挑？

如果挑錯人可能會引發受害者循環
↓
自動化是不是要裁員？
透明化會不會被找碴？
長週期的品質比較好！

CI/CD 實施涵蓋率
commit 的頻率與次數
WBS 拆得愈多愈好
一篇能寫完的分享要寫三篇
透明化後萬物皆指標？

Key Takeaways
1. 建立訊息透明化的共識
2. 版控做紮實再講自動化
3. 紀錄一切值得紀錄的變更
4. 自動化一切值得自動化的工作
5. 持續觀察流程並調整
6. 讓數據變助力不要變壓力
7. 把硬體當資產，不要當負擔

“Be the change you want to
see in the world.”
—Mahatma Gandhi

DevOps Taipei Community
https://www.facebook.com/groups/DevOpsTaiwan/
Agile Community in Taiwan
https://www.facebook.com/AgileCommunity.tw/

[DevOpsDays] 硬體產業的DevOps導入與實踐 - 以工控產業為例

More Related Content

What's hot

Similar to [DevOpsDays] 硬體產業的DevOps導入與實踐 - 以工控產業為例

[DevOpsDays] 硬體產業的DevOps導入與實踐 - 以工控產業為例