走過 DevOps 風雨的下一步… - 郭家齊（Edward Kuo）

各家講者出來分享自己的經驗多少都有些公司內規和公關要求的限制，有些不方便分享的地方（例如：不要張貼簡報截圖）還請大家多多包涵喔（不然就更多人不敢出來分享了）
DevOpsDays Taipei 2022

從這開始

tags: DevOpsDays Taipei 2022

9:40-50 Opening
在過去DevOps求快求效率，現在開始更要思考如何提供更安全及高品質的服務

What is DevOps

自動化做到後來只是自動化，什麼都沒有改變，會遇到瓶頸，講者更希望來的人是主管，後期可能需要改變的是想法

DevOps是什麼？

• 文化
• 流程
• 工具

每個人都知道，但做了什麼呢？

• 購買工具
• 換工具
• 再換工具
  這就是目前devops的現狀
  然後一些廠商例如微軟，就一直賣工具，好像買了工具就devops了

大部分可能只解決自動化問題

What is DevOps

https://theagileadmin.com/what-is-devops/

DevOps是敏捷的延伸

敏捷的商業需求
敏捷的系統開發
敏捷的日常維運

DevOps的荊棘之路

轉得慢外在淘汰
轉得快會被公司內部鬥爭幹掉

導入git?
沒人有正式環境真正的source code
大家手上都自己有一份，要以誰的為準？
一直發生互相把其他人程式蓋掉的事情，在製造業天天發生

製造業IT的原罪

• IT只是"支援單位"，編制有限
  • IT人員只佔全部員工的3%，而其中開發人員又只佔一小部分
• 過去經驗太成功，不願改變
• 即便願意改變，能承擔改變的風險能力較低
• 學習與試錯文化相對不盛行
• 對硬體花費的成本是投資，對人花費學習的成本是浪費

欲練神功，必先改變
ex: 試著去版控

• 改變工作流程
• 改變工作習慣
• 改變思考模式
• 改變組織結構
• 改變軟體開發流程

導入DevOps常被問到:

• 怎樣算是導入成功?
• 能讓我們更快完成專案嗎?
• 推薦好用的DevOps工具?
• 能在短期內看到導入成效或是KPI嗎?
• 沒資源、沒方向
• 沒有好的/強的團隊或開發人員
• 可不可以減少員工

主要原因是DevOps並沒有明確的告訴你該怎麼做

大多數人停留在KPI思維，習慣量化
所以最後就變成工具是第一順位，導入工具就有KPI

• 能用錢解決、快又有效
• 有量化指標，有指標有績效
• 門檻最低最沒有風險
• 不需要調整組織、團隊或流程
• 確保每個人都有事做，老闆才會覺得你們很忙，不是在休息

最後其實還是在用waterfall + 隕石開發
並不是敏捷，但敏捷是DevOps的基礎核心

責任不應該隸屬一人

•團隊(部門）負責系統數量平均是20~30個以上
• Devops重視是一種高效率的協同合作模式
•管理者應該考慮團隊效率而非單一（開發者）效率
•管理者不該產生另類的穀倉效應
•高績效團隊具有快速處理危機與反應變化的能力
•高績效團隊能致力讓系統穩定且交付有效率

DevOps並不是只有自動化

只完成自動化，會如同薄冰

軟體不是只有build, release, deplo要聚焦於系統生命週期的平衡流動

就變成

1. 需求卡住，一次一大堆需求丟進來
2. code卡住，因為寫不完
   還是快不起來
   code寫不快的原因常常是前面的需求管理沒做好

因此即使做了自動化，也只是感覺很快，還是有瓶頸

Dev+Ops = One Team

• 開發與維運合成一個團隊是好事嗎？
  • 應該是彼此有對方的思維
• 維運者往開發靠，還是開發往維運靠?
• 一個人或許不需要十八般武藝都會，但團隊需要
• 團隊能共享整個軟體開發和維運生命週期的所有權
• DevOps重視分工而不是角色

賽道理論
有看過賽車或是玩賽車的人都知道
賽車走的是最快路徑而不是最短路徑
一昧追求走最短路徑
會很容易在其他地方卡住

三者密不可分

• Agile：文化
• DevOps：流程
• SRE：工程指標

Database's DevOps
很難！
92% 數據顯示 DB 佈署是 DevOps 瓶頸
大多數系統修改，DB是會修改

Ops 外的另一個門檻

• 多數 DevOps 團隊，認為資料庫的持續部屬相當困難

思維 & 工程障礙

• DBA 團隊將他們的領域和專業視為工作保障
• 非 DBA 團隊成員被推離資料庫禮遇，造成穀倉效應
• 資料本身具有慣性
• 需要修改資料結構時，需要遷移？

開發人員對自己負責的DB不熟，他可能沒有商業思維，不知道自己的資料是怎樣的
DB 的變更有 Best Practice 嗎？
有的，不過基本做不到
除非主管或是大老闆來推這件事情
所以 RDBMS 本身幾乎是做不到自動化
還有一個可能，程式都寫在store procedure裡面，那就做不到自動化

現實是殘酷的

• 大型系統/套裝系統的資料庫架構（ERP、MES）
  • 變更往往取決於別人或是廠商
• 檔案過大

對DB的管控不妨做些改變

• store procedure很難寫unit test
• 盡可能抽到API層級
• 資料庫納入版本控制

持續整合 & 佈署

• 持續整合
  • Code Scan，符合 SQL 開發規範
  • 資料庫程式封裝
• 持續佈署
  • 執行 SQL 程式自動化佈署會產生的差異化 Script
• 程式以版控為主**

做了一件很不人道的事情
所有資料庫內的程式一率要版控，沒版控的會全部被砍掉

讚
如果部門大老闆不支持，這樣會被 AP 或是開發團隊幹死
Mark_Mew

期初避免下列幾點

• 一次性的資料庫屬性設定
• 大型資料表的索引新增修刪
• 修改資料表的名稱或欄位

API First Ruddy 老師也提過
Mark_Mew

API First 思維

• 降低資料庫程式的耦合性
• 增加商業邏輯的可被測試性
• 增加商業邏輯的易讀性
• 降地資料庫瓶頸的可能性

AP與資料庫程式部署時程接近
避免DB程式有遺漏部署

更多細節: Database in DevOps

處處都是 Dev N Ops
你會發現近年來 N 越來越多
N = Sec, ML, …

你無法複製任何（團隊）人的模式
只能學習並不斷嘗試，然後不斷改進

之前遇到這樣的老闆和公司
真的覺得他們都在哭
Mark_Mew

商業需求跟工程需求是同等重要

• 大多數管理者會忽略工程需求
• 80%商業需求與20%技術需求同時存在
• 長期忽略工程需求，將會降低團隊彈性與動能
• 技術債不可能被清零，但必須要被有效管理
• 我們每天都被商業需求壓垮了
• 建議80,20法則，要有20%時間做改善
• 在看板管理中，放一塊技術債管理，讓它有效的被管理

有的老闆會要求，你不能用上班時間來改善工程需求

https://profile.edwardkuo.dev