本文探讨了在DevOps环境下的工作思维，强调明确目标和角色的重要性。通过小李的故事，揭示了技术债务和团队间沟通不畅导致的问题，并提出DevOps的三步工作法，以提升交付效率和质量。最后，强调了持续反馈与学习的重要性，以实现团队和公司的共同成长。

1. DEVOPS浪潮下的處事之道
DevOps 傳教士
李權桓

2. 大綱
1. 為什麼要先從處事思維講起
2. DevOps 由一個勵志故事開始…
3. 確立DevOps的目標
4. DevOps三步工作法的背後思維
5. 讓DevOps動起來

3. 1.為什麼要先從處事思維講起

4. 不管要推動什麼，我們都應該要知道我們要解決什麼問題
並定下目標。才不會流於形式。

5. 2.DEVOPS 由一個勵志故事開始…

6. 很久很久以前…
有個胸懷大志的產品經理-小李，他跟老闆許下了一個承諾…
小李 老闆
為了增加業績，
所以我要一個
月內做出超級
厲害的系統A
最近業績平平，
有沒有什麼辦
法可以快速提
升業績啊？

7. 小李興致滿滿的向開發團隊下指示…
小李開發團隊
沒關系，以
後會給你們
時間補
做得出來，
可是會有
技術債！

8. 一個月時間轉眼就過了…
開發團隊 運維工程師小張
開發團隊順利的將系統A交付，并由運維工程師小張部署
系統A

9. 老闆很滿意，所以小李又做了更大的承諾…
小李 老闆
系統A效果很好，
所以接下來我
們要十個月建
立十個系統B到
K
新系統效果不
錯啊！公司的
未來就靠你啦！

10. 打了興奮劑的小李，再度向開發團隊下指示…
開發團隊 小李
說好的修技術
債的時間呢？
現在業績為重
啊。而且上次
不是什麼事都
沒發生嗎？

11. 前九個月順利的過去了，時間來到第十個月…
開發團隊 運維工程師小張
由於技術債積累的關系。十一個系統中有三個系統彼此依賴，而這次的升級開發團隊因為趕時間，
沒有提交升級說明。小張在手忙腳亂下少升級了一個系統，造成系統崩潰。
十一個系統
生產環
境
十個系統

12. 用戶流失，老闆很生氣，後果很嚴重…
小李老闆 開發團隊 運維工程師小張
搞什麼飛機？這件事
到底是誰的錯？

13. 大家各說各話，互相推責…
小李
開發團隊運維工程師小張
我不懂技術啊！碰
都沒碰，所以不是
我的問題！
運維在部署前
應該要主動跟
我們確認部署
的架構啊！
開發提交升級
的時候，並沒
有說明系統間
有依賴關係！

14. 經過一番政治角力…小張被開除了
運維工程師小張
輕輕的，我走
了，正如我輕
輕的來…

15. 新的運維工程師接手…
菜鳥運維工程師小宋
小宋怕的要死，所以導致了升級流程需要更多的審批流程。
咦？系統架構圖呢？
業務流程圖呢？

16. 從此…整個公司開始相愛相殺，過著互不信任的日子…
產品 開發 運維
部門牆 部門牆

17. 隨著時間的推移，問題愈來愈嚴重，惡性循環不斷惡
化
更多技
術債
更不信任
交付期
更長

18. 終於，公司的產品在用戶心中失去了價值…GG了…THE
END

19. 3.確認DEVOPS的目標

20. 究其根源…
其實沒有一個角色在做錯的事！

21. 身為產品經理…
小李
我希望產品能響應市場變
化，提供用戶價值，提升
公司的競爭力！

22. 身為開發團隊…
開發團隊
為了不負產品所託
我希望能快速、高效開發新
功能

23. 身為運維工程師…
運維工程師小張
我希望能安心完成部署工作

24. 有沒有可能…
三個願望，一次滿足

25. 為了讓大家過著幸福快樂的日子…
目標：順暢、高質量的交付有用的用戶價值
《精益思想》

26. 為什麼要叫DEVOPS？
因為要達成目標。Dev和Ops一定要互相合作，
並有一個整體的一體化思維。

27. 為什麼一大堆東西都說自己是DEVOPS？
CI CD
Scrum
Kanban
敏捷精益開發 Gitlab Jenkins
Docker
K8S
Openstack
Ansible分支策略
AIOPS
不問責的
文化
系統性思
維

28. 只要都是為了達成目標而產生的方法、工具都可以叫
DEVOPS

29. 4.該怎麼開始呢？
DevOps三步工作法-談三步工作法的背後思維

30. DEVOPS三步工作法
• 流動：由左向右建立從開發到運維到交付客戶價值的流程
• 反饋：由右向左建立反饋機制
• 持續學習與實驗：建立具有創意及高可信度的企業文化

31. 流動原則?
開發 運維
用戶價
值交付
流程早都建立了，然後呢？

32. 其實是要我們…
看見全貌
產品 開發 運維
用戶反饋 產品設計 需求調研 功能開發 測試 資源分配 功能發佈 監控
知道每個部門的目標、每個人的職責、為什麼要做這個工作、被什麼拖延。讓資訊透明化。
客服 產品經理 項目經理 開發團隊 測試團隊 IT 發佈管理員 運維
看起來好像
看板

33. 反饋原則？
開發中 開發完成 測試中 測試完成 部署中 部署完成
功能L 功能K 功能G 功能B 功能A
功能J 功能F
功能I
功能H
一定是發生了什麼事？

34. 其實是要我們…
發現問題、解決問題

35. 持續學習與實驗原則？
未知的作者 的 此相片 已透過 CC BY-NC 授權

36. 其實是要我們……
經驗分享、共同學習

37. 流動
反饋
持續學習與實
驗
看見全貌
發現問題、解決問題
經驗分享、共同學習
所以我們得到…

38. DEVOPS之輪已經就緒…
看見全貌
發現問題、解
決問題
經驗分享、
共同學習

39. 5.讓輪子動起來
驅動力-漸進式的增加壓力、讓瓶頸出現

40. 如何讓DEVOPS運作起來？
看見全貌
發現問題、解
決問題
經驗分享、
共同學習
漸進式的增加壓力
讓瓶頸自己出現

41. 例：部署的周期漸進式減少
二周部
署一次
一周部
署一次
一天部
署一次
開發人力不足
測試人力不足
運維人力不足
讓瓶頸顯現出來
漸進式增加壓力

42. DEVOPS，其實就是在做這件事情。不要被過多的思想、工具迷
惑。知道自己的問題是什麼，並解決這個問題，這才是最重要的。

43. 最後總結
DevOps的推動，首重看見全貌，透過現象看本質，從本質中發現問題、
解決問題。最後將經驗、知識分享，共同學習。

44. OPEN SPACE