我們需要 DevOps 嗎?

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

歡迎來到 DevOps Days 2018 共筆

Image Not Showing Possible Reasons
  • The image file may be corrupted
  • The server hosting the image is unavailable
  • The image path is incorrect
  • The image format is not supported
Learn More →

共筆入口：https://hackmd.io/c/DevOpsDays2018
手機版請點選上方 按鈕展開議程列表。

在大會遇到任何問題都可以在下方的問題回報區中留言
大會問題與建議回報區

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

我們需要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 準備好

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

Select a repo