我們需要 DevOps 嗎?

tags: DevOpsDays Taipei 2018 9/11 14:20~15:00 Track B

主旨：提供你一個參考方向(其實每個人要走的路都不一樣)

我們需要DevOps嗎？

瞎子摸象圖again

到底什麼是DevOps?

• 開建立高效能團隊?
• 開發速度變快?
• 建立自動化?
• 早下班?
• 老闆說的…
• 潮

DevOps 三個因子

人

• 最重要，但也最不可控
• 開發維運角色心態不同
• 組織大小，歷史包袱
• 行為思想要改變

成功––––––––––>失敗
新創 -> 成長型公司 -> 傳統大型企業
做一個人的 DevOps

流程

• 開發流程
• 維運流程
• 交付行為
• 協同合作

難––––––––-簡單
專案項目 <- 服務 <- 產品

工具

• 工具目的：在於輔助前兩者個實踐
• 不是最重要的
• 可以自選想要的工具

Case

快速交付很困難

• 老闆認為要做好全面的測試，需要花很多時間
• 交付時間長 = 最安全的交付 ？

要快速交付、快速迭代，人的思維要改變

花大量時間全面測試，交付大量需求 -> 花更多時間在部署 <–> 確保系統穩定成本

永遠都在測試，無法交付

• Developer 超過三個月就會忘東忘西
• 要出部署文件
• Developer 不喜歡寫文件
• 文件寫很爛…

DevOps 三個挑戰

政治

• 最困難，要說服開發、維運團隊老闆

成本

技術

• 找不到人，最後還是純手工打包…

學會選擇，學會放棄 (DevOps)

有時候在想，搞DevOps真累，要搞人、搞流程、搞技術…
講者

DevOps 的本質

DevOps 思維

持續交付價值給我們的客戶
縮短發布產品到客戶的週期
發現問題、持續改善

DevOps 原則

系統思維
放大回饋循環
接受失敗和持續學習的文化
* 最困難的也是最重要的，難免會發生，需要公司去接受
* 不可能做到完整測試，難免出問題

7種 DevOps 習慣

1. 自我組織團隊需與企業目標(比較容易說服長官)一致
2. 嚴格管理技術債
3. 專注於客戶/用戶價值流
4. 假設理論、驅動開發
5. 蒐集監控正式系統運作資訊
6. 實戰文化
7. 管理環境架構作為靈活資源

DevOps 循環

• Agile Planning
• Monitor and Learn
  • monitor 很重要，才知道怎麼改善系統
• Build and test
• Release
  • CD
  • Release management

符合特性，進行DevOps改革

可以依照團隊或是組織特性選擇：

• 平台工具
• Release 節奏
• 開發和維運團隊的合作組織
• 測試方法或測試框架
• 自動化程度
• 或是其他軟體開發模式

標準很重要

7 種 DevOps 實踐

DevOps …

文化轉變中，相對應的技術會油然而生
有CI/CD不代表做好DevOps
DevOps 循環中，開發維運心態要改變
通往DevOps 道路需要不斷學習
DevOps 不會限制團隊必須什麼方法或理論進行軟體開發
不強制改變現有團隊的開發行為

DevOps 的實踐

1. 資訊透明度

   • 不管用看板、slack 等所有資訊都要可以讓大家看到

2. Backlog

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

3. Version Control(建議用git)

   • 有效的建立版本控制的分支策略
   • Check in 的程式碼必須要連接工作項目
   • 只要是程式碼就要納入版控，包含 database (table view, 等)
   • infra 設定(IaS) ，需要納入版控 (Infra as Code, Dockerfile …)

4. Testing

   • 自動化是測試的關鍵
   • 單元測試、整合測試、UI測試到負載平衡測試都是屬於持續測試一環
   • 使用增量和迭代方法，讓測試的深度不斷前進
     • 有錯就加測試，總有一天會寫完
   • 別期望一開始就寫好所有的測試案例
   • 最好的測試，就是增量測試

5. 持續整合、持續部署

   • CI / CD 策略定好，再自動化
   • 80%自動化 > 100%自動化
   • 不自動化也能 CI/CD 只是比較累
     • 工人智慧

6. 監控與學習

   • 品質
   • 安全
   • 可靠性
   • 持續提供價值給用戶
   • 了解用戶如何使用系統
     • 通常 bug 有兩種，user 用錯了或是真的系統壞了

7. 量測指標

   • 沒有 Burndown chart, velocity 反正時間都估不準，看這個也沒用
   • 看整個團隊的指標
     • time to build
     • time to release

8. 定義 Story Done

• Story 完成後，到正式上線
• 正式上線後，有第一位使用者開始使用

建立 100% DevOps 精實協作團隊

全都是工程人員 都要開發QA維運

良好的 DevOps 文化團隊

• 團隊每個人一起致力讓系統能夠平穩且有效率
• 資訊共享、互助合作共同承擔成功與失敗
• 團隊每個人互相扶持、相信人人都可以改變
  • 資深人員提攜新進人員
• 每個人努力讓團隊變得更好，不是追求自我成功或是價值
  • 團隊中不能有只想提升自我，不幫助團隊的人

最後 - DevOps Milestone

• Sprint 縮短為一週
  時間縮短人的潛力就出現了 !?(笑)
  奉行不加班，能開發的時間只剩四天，因為其他事務約佔一天
• 重新切分 Story 大小
• Dev + Ops = One Team
• 資訊透明化
• CI / CD
• 類微服務
  • 發現架構太大了，逐步轉換。
• Time to Release / Time to Build
• Container Docker

總結

持續改善完善系統

減少浪費

DevOps 需迭代演進！

Release vs Deploy

• CD 只有到 Release
  • Container Image 準備好

場外聊天室，歡迎在下方喇賽