owned this note   changed a year ago  
Linked with GitHub

DevOps加入Biz 提現DevOps在企業價值定位 - 郭家齊 (Edward Kuo)

歡迎來到 DevOpsDay Taipei 2024 共筆

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/@DevOpsDay/2024
手機版請點選上方 按鈕展開議程列表。

》議程介紹

》填寫議程滿意度問卷｜回饋建言給辛苦的講者

共筆從這開始

回顧 DevOps Days

  • 2022 年，優化 DevOps 流程
    • Biz 模型導入團隊

DevOps 目標

  • 持續交付價值給用戶
    • 和用戶一起創造企業價值
  • 縮短需求交付週期
    • 縮短業務需求校正的時間
  • 發現問題持續改善
    • 改善技術層與業務層的認知差異
    • 很難一步到位
  • 團隊與企業目標一致
  • 專注於客戶與用戶價值流
    • 63.2% IT 的成效和價值未能讓業務部門瞭解和接受

DevOps 突破過去的困境

  • 降低開發和維運的鴻溝
  • 推進 IT 技術的前進
  • 讓團隊更加敏捷
  • 開始擁抱自動化

DevOps 遺漏了什麼

一天可以做到上百次的部署，然後呢？使用者不用，就一點價值都沒有
不管寫得再好，部署出去沒有人用，就是沒有價值的產品
一個小故事：一件事情不斷地傳遞，維運人員可能不知道會有多少流量，後來網站 crashed，有了自動化之後，開發跟維運人員就可以關注在 Business 上面

只做 DevOps，已經無法協助解決企業需求問題了
BizDevOps 可用較短時間驗證業務價值
和用戶一起早期發現邏輯缺失，或快速驗證需求失敗，降低企業風險

敏捷且有效益的完成企業商業目標才是企業需要的高績效團隊

對 BizDevOps 的定義

  • 代入商務跟業務的思維
  • 業務團隊、開發人員、維運人員密切合作和共享知識
  • 把業務目標做為共同目標，解決客戶痛點
  • 如果團隊跟業務是分開的是很嚴重的事情，風險會提高

BizDevOps 目標

  • 溝通層級/團隊越多複雜度越高
  • 業務問題和需求能共同理解，團隊選擇並訂定最準確的解決方案

BizDevOps 實踐

  • 專業知識和軟技能是跨職能的
  • 對於彼此的回饋，保持開放態度，大家可以互相溝通
  • 把實驗移植到業務端的部分，測試業務的邏輯需求是否準確

DORA

  • DF 部署頻率
  • LT 變更提前期
  • MTTR 平均恢復時間
  • CFR

Biz 模型怎樣加入 DevOps

  • 所有 DevOps 團隊是不能複製的，所以只能參考
  • 背景：
    • 高科技製造業的 IT 部門
    • 人力資源是有限制的
    • 舊系統包袱
    • 多系統、多重業務模型
    • 開發維運在同一個團隊
    • 90% 都是 DevOps 工作流
      • 包含資安掃描全部自動化
  • 曾經遇到的困境（美化版本）
    • 對於業務目標不知道，架構疊床架屋，導致開發困難且龐大
    • 市場變化太快
    • 新技術導入，沒辦法和業務目標對齊
    • 技術無法解決問題
  • 曾經遇到的困境（簡單的來說）
    • 只按照需求做事，導致系統架構無法延續改變
    • 開發人員不知道為什麼要這樣做
    • 業務需求和開發維運溝通語言不在一個水平
    • 維運也不了解流程，業務說很慢，實際是 DB 爆掉，但是一直找問題
  • 原本團隊運作流程
    • DevOps Team + Business Owner + User
      • 溝通成本高
  • 團隊加入 Biz 模型
    • Biz + DevOps Team
    • 需求不再只是等待交付後的用戶回饋
    • 每個成員都具備基礎的商業思維
    • 解決真正業務痛點，不一定要寫程式
    • 提現（新）技術對業務的價值
  • 如何切割業務需求粒度大小
    • 最小可執行性、技術、維運三方評估
  • Ship Planning
    • 誰要用這個產品，非常重要
    • 團隊共同討論與編輯與拆解
  • 如何在業務快速推動，維持系統架構和維運品質
    • 所有專案都不能關起門自己做
    • 要開始跟使用者討論
  • 公開所有業務與系統關聯文件
    • 共同撰寫業務需求說明，並公開且能即時更新文件
  • Biz + DevOps 運作流程
    • 生成以下四種文件
      • Prototype
      • 系統功能流程
      • 系統架構圖
      • 行為流程圖
  • 為什麼需要 k8s 架構
    • 不希望 session 斷掉

任何技術計畫，需要獲得全公司應有的可見度和關注，協助解決企業問題

總結

  • 團隊組成
    • 業務、開發、維運三要素組成一個團隊，焦點是交付企業業務流程
  • 自動化流程是很重要的
  • AI 工具縮減開發維運時程
    • AI 工具/Copilot 縮減開發與維運時間
    • Low-Code/None-Code 縮減開發的時間
    • 平台工程的崛起
    • 雲原生的技術興起
  • 高績效團隊的加值
    • 團隊增加軟技能的能力（溝通、耐心
    • 團隊不見得是超強團隊，但會是跨職能團隊，才能夠讓團隊一起前進
  • 有用嗎？
    • 當你了解，就有用了
    • 當你有意識，就會開始改變了
    • 最困難就是人，如果人沒有意識到這件事情，就不會發生改變
    • 發生改變之後，事情就會往正向發展變得更簡單
  • 如果這個技術沒有帶來商業價值是沒用的，除非技術幫助人們完成任務體現商業價值，才是有意義的
tags: DevOpsDays Taipei 2024
Select a repo