Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.

DevOps的神鬼奇航

1 516 vues

Publié le

DevOps is not easy to Implementation. If you Work in manufacturing, I think I have some idea for you reference.

Publié dans : Technologie
  • Soyez le premier à commenter

DevOps的神鬼奇航

  1. 1. DevOps的神鬼奇航 講者: 郭家齊 (Edward Kuo)
  2. 2. 關於我 • 現職 Kingston Technology 資訊處 • 前 友達光電 營運資訊處 • 微軟最有價值專家 • Study4.TW社群成員暨講師 • 2017 Microsoft Tech Summit 講師 • 財團法人福榮融合教育推廣基金會 資訊顧問 • 中華大學 Build School 企業導師 熱愛開發程式與追求新技術,近年除技術研究外,也積極實踐敏捷精神, 讓DevOps文化能落地並於企業內實踐,而非只是個目標
  3. 3. 實踐DevOps會發生很多意想不到的事情!
  4. 4. 開始前,先來了解故事背景 製造業IT是一個特殊性職務
  5. 5. • IT人員的編制有一定比例 • IT人員的質量不一 • 大部分企業內的IT是屬於支援單位 • IT穩定服務永遠位居首要 • 可承擔「變」的風險能力較低 • IT人員是技術專精的「魔法師」
  6. 6. • 用少數資源, 「製造」大量系統 • 系統間關係盤根錯節,架構與開發的複雜度,不輸其他產業 • 公司越久越大,系統越多、維護成本越大,開發效率越低 • 很多的解決方案像是拼裝車 • 越短時間能交付需求,才是被大家關心 • 系統會同時佈署不同地區 • @#$%^*)$#@
  7. 7. 偽專案 專案是一個暫時性的組織與努力付出,在一段事先確認的時間 內,運用事先決定的資源,以產出一個獨特的且可以事先定義 的產品、服務或結果
  8. 8. • 專案只有交付日期,沒有終止日期 • 有時候必須交付第一版後,User才能準確說出自己的需求是什麼 • 需求確認的時程,趕不上市場變化 • 需求有優先權,往往會被外界更動 • 專案的範圍大小不固定
  9. 9. Scrum? DevOps? 要選那一個?
  10. 10. 改變(轉型) IT部門要轉型開發模式,大部分是困難的
  11. 11. Waterfall轉換為Scrum 快速迭代 貼近需求 時程可被預估即時反應 Waterfall Scrum
  12. 12. ★ Testing Test Test Test ★ First Release ★ Lead Time ★ Full Requirement ★ Enough Requirement ★ Lead Time★ First Release ★ Full vs. Enough Requirement ★ Testing Process
  13. 13. • 保持高效率,快速反應 • 敏捷開發、小步快跑 • 發現問題,適時檢討與反省 • 貼近使用者/市場需求 • 提升可靠度與品質 • 讓User知道你有在關心的他需求
  14. 14. 團隊,是Scrum的核心 打破部門圍籬、建立虛擬組織
  15. 15. Infra Team
  16. 16. Infra Team Scrum A Scrum B Scrum C POPOPO Develop Develop Develop
  17. 17. Infra Team Scrum A Scrum B Scrum C POPOPO Develop Develop Develop Scrum Master
  18. 18. Scrum是一個方法(框架) 符合企業文化與流程,才能發揮Scrum效益 用敏捷的精神,建立企業自己的Scrum流程
  19. 19. 一切都看似都步上正軌… 專案開發、需求變更和維運在一個Sprint同時發生 Story預估常常不準 Scrum沒有帶來效率
  20. 20. DevOps風潮 Scrum談開發團隊,DevOps談開發+運維團隊
  21. 21. Scrum? DevOps? 一個訓練有素的敏捷開發團隊是成功執行DevOps關鍵
  22. 22. DevOps目的是什麼? 不要為DevOps而DevOps 提升使用者的工作價值
  23. 23. 縮短交付時程 减少重複性工作,降低溝通成本 縮短問題釐清時間,快速交付成果 簡化、自動化的部署程序,增加部署頻率 開發、維運有共同溝通管道
  24. 24. 開發與維運同等重要 「開發」强化企業獲利能力 「運維」穩定企業獲利來源 「開發」和「運維」失衡對企業有極大影響
  25. 25. 開始(進行)DevOps Scrum解決了開發問題,DevOps再強化效率
  26. 26. Scrum & DevOps雙軌 快速迭代 貼近需求 時程可被預估即時反應 Waterfall Scrum 持續整合 持續部署 持續反饋 减少浪費 DevOps
  27. 27. • 坑 : 技術、組織 & 文化 • 減少歷史包袱,降低轉型試驗的風險 • 建立企業的DevOps流水線 • 降低被包袱干擾程度 • 不影響現有開發與營運模式
  28. 28. CI / CD =DevOps? 開發與維運沒有共同目標,就不算做到DevOps
  29. 29. • CI / CD !=DevOps • CI / CD 只是讓工作流程自動化 • DevOps 第一和第二需要被優先建置 3 工具2 流程1 文化
  30. 30. Infra TeamScrum Master Scrum A Scrum B Scrum C POPOPO Develop Develop Develop AS AS AS DevOps
  31. 31. • 管理 • 開發與維運最好是同一個團隊(組織) • 團隊內擁有不同角色,但只對應同一位主管 • 開發人員同時也會是維運人員 • 團隊 • 專業整合,共同找出解決方案 • 溝通管道簡化、資訊透明度高 • 開發與維運的需求(Story)放在同一個看板內管理
  32. 32. CI / CD的推進 重複、繁瑣的任務都自動化
  33. 33. Build & Release 人工先行 用人工方式確保流程可運作
  34. 34. • 只要是程式碼,都要納入版控 • 80%自動化、20%人工作業 • CI / CD的過程都必須被追蹤和警報、資訊必須是透明 • 除正式區環境,盡量在程式碼嵌入後就直接進行CI / CD
  35. 35. 配置與監控 「監控」是DevOps重要的一環
  36. 36. • 監控 • 系統運行必須有Log和健康狀態監控 • 系統訊息必須即時給「開發」和「維運」人員 • 任何的反饋資訊,必須能在同一個溝通平台被討論 • 配置 • 上線流程 : Dev->UAT->Pro • 每個環境對於系統配置是不同 • 系統配置參數,納入CI / CD流程中完成 • 系統化完成配置,降低人為干預
  37. 37. 企業還是會有考核的!? 導入Money Merit機制
  38. 38. • 商業需求 > 團隊 >> 人 • 先評估團隊完成商業價值,再評估個人對團隊貢獻價值 • Money Merit • Merit Money is a reward scheme, where the whole team rewards each other, based on our perception of an individual’s merit during the month. You are given a certain number of merit points each month and you distribute them to your team members. Far removed from your traditional bonus scheme, Merit Money is not set by management and there is no fixed target.
  39. 39. 這條路不好走… 人,是一個很大的阻礙
  40. 40. • 開發與維運如何有效的溝通非常重要 • Infra對於Scrum & DevOps較無感 • 系統架構重新設計,提升CI / CD效益 • 架構最好設計是低耦合性、盡量做到最小單元 • CI / CD建置是很花功夫,最好列入Story或Task • 自動化很爽,壞了也很爽,一定要設計手動模式 • 工具整合是支持開發和維運方面最有幫助的技術 • 開發和維運人員最好是同一個團隊
  41. 41. DevOps是個迭代的過程 找出並消除一切不必要的浪費
  42. 42. • 開發與維運必須是閉環 • 兩者間資訊必須透明化 • 團隊文化建立永遠是最難的 • 流程都確定好,再進行自動化
  43. 43. End Q & A

×