The DevOps Handbook Essentials

什麼是 DevOps？這個詞彙經常出現，但似乎很難簡短地解釋它。在這場分享裡我們從 DevOps 想解決的問題 (穀倉效應) 談起，中段為《The DevOps Handbook》一書的精要筆記，解釋 DevOps 實踐三部曲 (暢流、回饋、自主學習)，最後輔以其他補充資料，談 DevOps 的四個核心要素 (人文、組織、工具、流程) 與思考 DevOps 精神的取捨。

Transcript

1. 精要 The DevOps Handbook 打造世界級技術組織的實踐指南 Dan Chen 2019/10/02
2. • 這份簡報是經過編修的公開版本 • 移除⼤大部分從書本引述的內⽂文，希望減少智財疑慮
 (內部分享時，公司買了了很多本 The DevOps Handbook) • 因此，看到 Part 2 被遮掉的內⽂文請別覺得奇怪 • 這份簡報希望擔任的⾓角⾊色是導讀，以及補充書上沒提到的資訊 • The DevOps Handbook 寫得很不錯，尤其是案例例分析 • 如果想瞭解 DevOps 的精神與實踐，推薦買書來來讀 • 可以將簡報 Part 2 提供的中⽂文版⾴頁碼當作索引
3. • 這個分享是⼀一種「幫⼤大家讀書」的概念念 • ⽬目的不是來來灌雞湯，也不是來來傳教的 • 先跟風瞭解 DevOps 精神 • 然後想想我們可以做些什什麼 • 也可以檢驗別⼈人在推的 DevOps 是什什麼東⻄西？ • 簡報格式 • 楷體—引述書本內容與中⽂文版⾴頁碼（沒⾴頁碼的來來⾃自其他書）
 範例例：追蹤⼀切是快速⾏動的關鍵 (p.194) • ⿊黑體—我的解讀或是補充
 範例例：DevOps 是⽂文化⽽而不是流程
4. • 什什麼是 DevOps？ • ⼩小黃書上怎麼說？ • 那些書上沒有寫的東⻄西
5. Part 1 什什麼是 DevOps？
6. 很多詞彙被誤解、誤⽤用
7. ⼤大數據
8. ⼤大數據 統計 (⽽而且還是⽤用 Excel)
9. ML/AI
10. ML/AI If-Else 深深深幾許 載入函式庫然後怒 Train ⼀一發再調參參數 (ML/AI = Many Libraries Are Imported)
11. DevOps
12. DevOps 叫 Dev 吃掉 Ops 的⼯工作，很省錢 ⽤用了了之後產品會比較快⽣生出來來 不就是把流程⾃自動化嗎？
13. • 問 10 個⼈人「什什麼是 DevOps」，可能會得到 12 種答案 • DevOps 都是被逼出來來的！ • 系統維護玩不下去了了、產品開發搞不下去了了、… • 覺得不爽 → 發現痛點 → 嘗試解決 • 被實際場景逼出來來的，就是你⾃自⼰己的 DevOps • The DevOps Handbook 給出相對泛⽤用的系統化⽅方案
21. • ⼈人類有意識、無意識地「分類」 • 資訊複雜，分類後才能系統化處理理 • 世界越來來越複雜… • 技術越來來越複雜 → ⾓角⾊色分類 • 公司越來來越複雜 → 部⾨門分類 • 習慣分類 → 穀倉 (silo)
30. • 穀倉效應 (⼭山頭割據) • 資訊不流動 • 責任壁壘壘 (踢⽪皮球、重⼯工) • ⼭山頭利利益 > 整體利利益 • “DevOps” 這個東⻄西 • 名字有點糟，源⾃自於 DevOpsDays 2009 • 包含了了豐富涵義的精神與⽂文化 • 重新「分類」組織來來打破穀倉 • 不過，只是看你從哪個⾓角度來來看……
34. DevOps 不是流程，
 是整個組織的精神與⽂文化 掌握如何建⽴學習型組織、如何加快流程、打造⼀流可靠性和
 安全性的產品、以及如何提升企業競爭⼒和員⼯滿意度 (p.347)
36. TL;DR DevOps 矽⾕谷世代公司治理理⽅方案 v2.0
37. TL;DR DevOps 矽⾕谷世代公司治理理⽅方案 v2.0
38. Part 2 ⼩小黃書上怎麼說？
39. • DevOps 應運⽽而⽣生 • 在這個安全漏洞頻發、交付週期不斷縮短、技術⼤規模轉型的時代，技術領 袖們要同時應對安全性、可靠性和靈活性的挑戰 (p.347) • DevOps is an organizational and cultural movement that aims to increase software delivery velocity, improve service reliability, and build shared ownership among software stakeholders. Learn how to improve the speed, stability, availability, and security of your software delivery capability. (Google Cloud) • 以 DevOps 打破惡性循環 (p.xxix) • 科技產業的惡惡性循環：
 忙 & 疏於管理理 → 技術債和 Workaround → 膨風的承諾 → 更更忙 • 理想情況下，⼩型開發團隊獨⽴進⾏功能實作，在類⽣產環境中驗證可⾏ 性，並快速、安全且可靠地將程式碼部署到實際環境 (p.xxix)
40. • DevOps = 精實原則 (Lean Principle) 應⽤於「科技價值流」的成果 (p.3) • 以科技轉化商業構想，向客⼾交付價值所需要的流程 (p.8) • 應⽤程式或服務只有在 production 中按預期正常運作、為客⼾提供服 務，所有的⼯作才產⽣價值 (p.8) • 三步⼯作法 (p.3)：DevOps 轉型的三個階段 • 暢流：讓⼯作順暢地從開發移動到營運，最後交付到消費者⼿⼿上 • 回饋：建⽴更安全的⼯作機制 • 持續學習和實驗：促進⾼度信任的團隊⽂化，⿎勵組織成員以科學⽅法 進⾏改善⽇常⼯作 • 改善形 (Improvement Kata) • 幫助員⼯在⽇常⼯作中培養「改善⼯作」的習慣 (p.6)
41. • 三步⼯作法 (p.6) • 第⼀步：⼯作快速地從左向右流動，從開發 平順過渡到營運，最後交付給消費者 • 第⼆步：在價值流由右向左的每⼀階段套⽤ 快速且持續不斷的⼯作回饋機制 • 第三步：塑造 Generative、⾼度信任的企業 ⽂化，培育充沛活⼒、態度嚴謹、以科學⽅ 法進⾏的實驗環境
42. 轉型第⼀一步：暢流 （⼯工作流⽔水線）
43. • 評估價值流的三項指標 (p.9-11) • 前置時間 (Lead Time)：⼯工作進 queue 到真正完成的時程 • 處理時間 (Process Time)：實際⼯工作時間 • 資訊精準度 (%C/A)：不需獲取額外資訊即可完成⼯工作的比例例 • 價值流中每個步驟的輸出品質：下游端有多少時間接收到「真正可 ⽤」的⼯作，讓他們可以專⼼，不必修復錯誤資訊、補充資訊，或 者釐清那些本該明確清楚的資訊 • 例例：敲進來來的 bug 不需要退回去收 log/dump 就可以修好的比例例 • 前置時間才是客⼾真正體驗到的時間，快速流程的重點放在縮短前置時 間⽽不是處理時間上，亦即縮短⼯作在佇列中的等待時間 (p.11)
46. • 讓⼯作可視化 (p.15) • 科技業的⼯作內容不可⾒，在科技價值流中很難⼀眼發現流程的停滯 點，⽐如：⼯作在哪裡受阻、哪⼀個環節開始積壓⼯作 • 科技⼯作的「轉移」只要點滑⿏就能輕鬆完成，因為操作太容易，不 同團隊之間反⽽可能因為資訊不完整⽽將⼯作踢來踢去 • 對 Kanban 中的每個⼯作中⼼設定在製品 (WIP) 的數量上限 (p.18) • 限制 WIP 數量後，可能發現我們居然無事可做，因為要等其他⼈先 完成⼯作
48. • 持續識別與改善約束點 (p.22) • 在 DevOps 的轉型過程中，若希望前置時間從數⽉或數季，縮短成以 分鐘計算，通常需要依序最佳化下列約束點：環境佈建、程式碼部 署、測試準備和執⾏、過度耦合的組織架構 • 消除價值流中的困境和浪費 (p.24) • 半成品、多餘加⼯／額外功能、任務切換、等待、⼯作轉移、瑕疵、
 ⾮標準化或⼿動作業、救⽕英雄
49. • 選擇適當價值流作為切⼊點，別想⼀步轉型整個組織 • 兩位博⼠的研究成果表⽰，企業組織應建⽴專⾨的轉型團隊，令其獨⽴於負責⽇常 運作的部⾨…由轉型團隊的成員專⾨執⾏ DevOps 轉型⼯作 (⽽不是讓他們同時執⾏ 現有任務，並額外多花兩成時間來做 DevOps 轉型) • Nordstorm 成⽴了⼀個⾏動應⽤專⾨團隊，能夠獨⽴開發、測試並向客⼾交付價值， 該團隊不再需要依賴 Nordstorm 內部的其他團隊，也不再需要與他們協作 (p.52) • 謹慎選擇 DevOps 轉型的切⼊點，在組織內某些領域進⾏試驗、學習並創造價值，避 免對整個組織帶來不可逆的後果。可以建⽴穩固的群眾信任基礎，贏得在組織中推 廣 DevOps 轉型的機會，獲得更多⽀持者的認同和感激 (p.59) • 在任何 DevOps 轉型專案中，都需要維持⼩幅度的改善計劃，就像新創企業著⼿產品 開發或客⼾開發的⽅式。我們必須致⼒在數週內 (最差也應在數⽉之內) 取得可供衡 量的改善成果或者可⽤數據 (p.67)
50. 轉型第⼆二步：回饋 （安⼼心的⼯工作環境）
51. • 想要鞏固⼯作的安全性，我們可以在組織和價值流之間，建⽴⼀條快速暢通、頻繁流 動且⾼品質的雙向資訊流，包含回饋 (feedback) 與前饋 (feedforward) 迴圈 (p.27) • 豐⽥安燈索 (p.31) • 產線上的每個⼈ (⼯⼈和經理) 都瞭解，當出現問題時，如零件出現瑕疵、必要零件 不可⽤、或者⼯時超過表定時間等，拉動繩索⽰警 • ⼀旦拉動安燈索，團隊領導者⽴刻著⼿處理問題。若無法在特定時間內 (如 55 秒) 解決問題，則暫停整條⽣產線，動員整個組織蜂擁⽽上 (swarming) 協助處理 • 不再是「當我們有空時」再解決和安排修復作業 • 與常⾒的管理實務有所出⼊，因為我們刻意凸顯局部問題⽽打斷全域作業 • 促進組織不斷學習，避免因時間流逝⽽忘記脈絡，或因環境改變⽽錯失關鍵資訊 • 為科技價值流上的每個⼈提供迅速回饋，幫助我們快速隔離問題與進⾏診斷
52. • 將品質意識推⾄根源 (p.33) • 組織對意外和事故的反應⽅式，可能在無意中強化了⼯作系統的不安全性 • 在複雜系統中，加⼊更多檢查步驟與審核程序反⽽容易增加發⽣故障的可能性 • 認知差距過⼤：「誰應該做某件事」 vs 「誰真正在做某件事」 • 幾個無效品管的例⼦ (p.33) • 要求另⼀個團隊去完成冗⾧單調、容易出錯的⼿動作業，明明可以將作業流程 ⾃動化，依照各團隊的需求⾃主運⾏ • 要求不熟悉⼯作的忙碌主管批准⼯作，逼他們在沒有充分了解⼯作或潛在影響 的情況下做出決策，草率簽核 • ⼤量具有可疑細節的⽂件，在完成撰寫不久後即過時 • 將⼤批⼯作擺在團隊和特別委員會⾯前要求進⾏審核和處理，然後等上⼜等
53. • 回饋機制：建立能發現並解決問題的遙測系統 • 追蹤⼀切是快速⾏動的關鍵，能夠輕鬆不費⼒地追蹤⼀切是唯⼀真理 (p.194) • ⾼績效組織在解決問題⽅⾯訓練有素，他們使⽤⽣產環境中的遙測系統，分析 造成故障的可能因素，⼤幅提升解決問題的可能性。低績效者則不然，他們只 會盲⽬地重啟伺服器 (p.193) • 資訊輻射體 (information radiator) (p.205) • 圖表、圖⽰與其他在團隊辦公室、⾛廊或其他辦公區公開展⽰的資訊，讓所有 看到的⼈能夠知道必要的資訊：⾃動測試化次數、速率、事故報告、持續整合 狀態等 • 將資訊輻射體放在⾮常顯眼的地⽅，我們賦予團隊⼀種責任感，也積極展現下 述價值觀：團隊對觀察者（客⼾、利益相關者等）毫無隱藏；團隊對⾃⼰坦誠 以對，承認並直⾯問題
54. • 建立無所不在的遙測系統 • 整個應⽤程式堆疊中，快速建⽴⽣產環境遙測 (p.207) • 商業層級、應⽤程式層級、基礎架構層級、使⽤者端軟體層級、部署管線層級 • ⽬標是讓所有的指標在商業上「切實可⾏」(actionable) (p.207) • 看看 Netflix 的玩法：把與眾不同的⽜牛宰掉 • ⽜群中的⽜在外觀和⾏為上應該都是⼀樣的，哪⼀頭⽜看起來與眾不同？或者更 具體地說，如果我們有⼀個包含上千節點的無狀態運算叢集，運⾏相同軟體，承 受近似程度的負載量，那麼我們所⾯臨的挑戰就是，找出那些與眾不同的節點 (p.213) • Netflix 以⼀種⾮常簡單的⽅式使⽤異常檢測。⾸先在運算叢集節點總數⼀定的情 況下計算出「⽬前正常值」，然後辨識與之不符的節點 (outliers)，將它們從⽣產 環境中移除 (p.213)
55. • 回饋很重要，但也要建立前饋機制 • 通常執⾏⼯作的⼈員都不太理解⾃⼰的⼯作與價值流⽬標有什麼具體關聯；無法刺 激員⼯的主動性和創造性 (p.79) • 「我之所以要配置這台伺服器，是因為別⼈要我這麼做」 • 如果隸屬營運部⾨的每⼀個職能團隊都要同時服務多個價值流（即多個開發團 隊），那麼問題更是雪上加霜 • 將營運⼯程師嵌⼊服務團隊 (p.97) • 特派營運⼯程師的責任是掌握以下內容：新產品的功能是什麼？為何要開發這個產 品？該功能如何運作？可營運性、可擴展性和可觀察性如何？如何監控和收集指 標？如果確認功能正常運作？此次架構和模式是否與以往做法不同？這樣做的理由 是什麼？是否對基礎架構有額外需求？該功能對基礎架構的影響是什麼？功能的發 佈計劃？
56. 轉型第三步：持續學習和實驗 （將「改善」融入⽇日常）
57. • ⼀般⽣產線上的⼯⼈幾乎無法將改善活動和學習融化他們的⽇常⼯作中，試圖 提出改善建議時會「⼀頭撞上冷漠無情的⾼牆」。這類環境通常瀰漫著恐懼和 低度信任，犯錯的⼯⼈必須接受懲罰，提出建議或指出問題的⼈被認為是打⼩ 報告和刻意找碴 (p.37) • 病態型組織 vs 官僚型組織 vs 賦⽣型組織 (p.39) • ⼤大部分組織應該是 50% 病態 + 50% 官僚僚 • 勇於剷除官僚流程：「執⾏⼀次發佈必須發起的會議次數和⼯單數量」這項衡 量指標應該被好好利⽤並參考，以便⼤幅減輕為完成⼯作並交付給客⼾，⼯程 師所需付出的負擔 (p.266)
59. • 以「快速可靠的⾃自動化測試」來來保障安全性 • 恐懼是⼼靈殺⼿。它使新⼿不敢提交變更，因為他們不了解系統。它也讓⽼ ⼿不敢變更，因為他們太了解系統 (p.122) • 在測試套件中整合效能測試 (p.135) • 不要害怕錯誤，⽽而是：能發現、能快速恢復、下次能避免 • 我們最佳化「平均恢復時間」，⽽不是「平均故障間隔時間」。這是⼀條廣 為⼈知的 DevOps 準則，強調持續提升從故障中快速恢復的能⼒，⽽不是企 圖避免發⽣故障 (p.229) • ⼤規模事故偶爾會發⽣，我們希望「退回前⼀個版本」的操作是很容易的 (p.123)
60. • 舉⾏「不指責的事後分析會議」(blameless postmortem) (p.277) • 為了充分理解問題為何發⽣，需要以下利益關系⼈需要出席會議：參與相關問題 決策的⼈、識別問題的⼈、響應問題的⼈、診斷問題的⼈、受問題影響的⼈、任 何有興趣參加會議的⼈ • 召開不指責的事後分析會議時，⾸要任務是梳理並詳實記錄所有相關事件的時間 表，這包括採取的所有⾏動及其時間 (⽐如 IRC 或 Slack 的聊天記錄)、觀察到的 現象 (理想情況下，根據⽣產環境遙測系統裡的具體監控指標，⽽不僅僅是⼈們 的主觀敘述)、所有調查路徑，以及曾經考慮到的各種解決⽅案 • 在會議和決議的過程中，應該明確禁⽌使⽤「原來應該」或「原本可以」等詞語， 因為這些是「反事實」的陳述，源於⼈類傾向為已發⽣的事件創造可能的選擇 • 「我們正在為未來做準備，那時的我們會和現在⼀樣愚蠢」
61. • Netflix ⽤用 Chaos Monkey 來來「蓄意破壞」production 環境 • Netflix 每個功能和組件都可以⾃⾏降級 (degrade)。⽐⽅說，當流量劇增導致 CPU 使⽤率暴漲時，就不再向使⽤者顯⽰個⼈化電影推薦清單，只顯⽰已經 快取的靜態內容，從⽽減少運算需求 (p.274) • Chaos Monkey 的故事展⽰了學習型組織是如何思考故障、事故和錯誤：將其 視為學習的機遇，⽽不是懲罰的機會 (p.274)
62. • 刻意留留下「改善」的時間 • 為⾮功能性需求預留 20% 改善週期，減少技術債 (p.68) • 在每⼀個開發間隔中安排持續改善週期，或者舉辦「持續改善週」(Kaizen blitzes)，由⼯程師⾃由組隊合作，改善想要解決的問題 (p.40) • ⾮功能性需求：⾃動化⼯作、可維護性、可管理性、可擴張性、可靠性、可 測試性、可部署性和安全性等 • 如果組織連這「20% 的稅」都不願意⽀付，那麼技術債將會持續惡化，最終 消耗組織內所有可⽤資源
63. DevOps 實踐與總結
64. • 建⽴ Peer Review 機制 (p.258) • 同儕評閱的形式，不僅提升變更品質，也變相實施交叉培訓，對互相 學習和技能提升⾮常有好處 • 隨著變更規模增加，針對程式碼變更進⾏有意義評論的能⼒也隨之下 降。「請程式⼯程師來審查⼗⾏程式碼，他會找到⼗個問題。請他審 查五百⾏程式碼，他會說看起來都不錯」 • ⾨禁提交 (gated commits) (p.146) • 部署管線⾸先確認被提交的變更可以成功合併和佈建，並在合併到主 幹前就已經通過了所有⾃動化測試。如果測試失敗，開發⼈員將收到 通知，這樣就可以在不影響價值流中其他⼈的情況下⾃⾏解決問題
65. • eBay 和 Google 都曾把整個架構從頭到尾進⾏五次重構 (p.177)
66. • Netflix ⼯程⼯具總監 Dianne Marsh 說，她的團隊宗旨是：「以⽀援⼯ 程團隊的創新和速度為先。我們不為這些團隊構建、打包或部署任何產 品，也不為他們管理配置。相反，我們為⾃助式服務創造⼯具。他們可 以依賴我們的⼯具，⽽不能依賴我們的勞⼒」(p.96)
67. • 解耦 (decouple) ⽣產環境部署和功能發佈 (p.163) • 基於環境的發佈模式：藍綠部署、⾦絲雀發佈和叢集免疫系統 (⾃動 回滾的⾦絲雀發佈) • 基於應⽤的發佈模式：暗度發佈 (dark launching) • 雖然 Facebook 聊天新功能的 UI 元素對使⽤者來說不可⾒，但瀏覽器還 是會向已部署在⽣產環境中的後台聊天伺服器，發送聊天測試資訊，幫 助開發團隊在整個專案過程中模擬出類⽣產負載，在正式發佈功能之前 找出並解決效能問題 (p.174)
68. • DevOps 的實踐需要新的企業⽂化和管理規範，同時技術實踐和架構也 將煥然⼀新。「跨部⾨協作」⾄關重要，包括管理⾼層、產品管理部 ⾨、開發團隊、品質保證團隊、IT 營運、資訊安全甚⾄⾏銷⼈員在內， 所有部⾨必須⿑⼼協作，才能有效構建⼀個安全的⼯作系統，幫助⼩團 隊快速、⾃主地開發和驗證，並安全地部署與使⽤者服務相關的程式 碼，才有可能有技術創新 (p.347) • 參與變⾰的⼈都明⽩，他們做的事情當然可能會失敗，但無論成敗如 何，他們總要試上⼀試。勇於嘗試的真諦就在於以親⾝實踐來⿎舞他 ⼈。如果不承擔⾵險，那麼絕對不可能成功創新。如果你沒有使某些管 理層不安，那證明你可能還不夠努⼒。不要讓組織的免疫系統阻⽌或動 搖你的改⾰願景 (p.348)
69. Part 3 那些書上沒寫的東⻄西
70. DevOps 會是⼀一個⾓角⾊色嗎？ 看看坊間對 DevOps 存在的腦補幻想
76. 我對 DevOps ⽂文化的總結
77. • DevOps 說穿了了就是幾個重點／⽬目標 • 整個組織從部⾨門劃分到⽂文化上的⾰革新 • 部⾨門的 microservice 化，提升組織擴張性 (scalability) • 最⼩小化流⽔水線中每個步驟之間的溝通成本 (包含客⼾戶) • 追求效率是⼀種穀倉的詛咒，初期有明顯效率，僵化後⾯臨⾵險與錯失機會 • 組織 scaling 與電腦系統相仿：不斷思考能否拿管理 1000 ⼈的那套去管理 10 萬⼈ • DevOps 並不是萬靈丹丹 (silverbullet) • Agile 只是 DevOps ⽂文化中的⼀一部分 • 什什麼是 agile？粗略略來來說就把⼀一件⼯工程切程 10 塊 (iterations) 來來發佈 • 不是⽤用了了 agile/DevOps 就能瞬間完成那件⼯工程 • 如果你的⼯工程不能切 10 件，那還能 agile 嗎？
78. 組織、⼈人⽂文、⼯工具、流程 四個⾯面向，需並進轉型
80. DevOps 轉型案例例 ⼩小黃書裡有 48 個案例例，這裡提點別的
82. • 微軟以前吒吒風雲，員⼯工不認為有改變的必要 • 穀倉催⽣生職員死命保護產品，⽽而成功過的產品更更加穩固穀倉 • 吃老本吃到太爽，沒發現外⾯面的世界早就不⼀一樣了了 • 說直⽩白點就是集體⾃自我欺騙…… • 外頭的競爭對⼿才不管你們內部有什麼問題！
84. Bill Gates Steve Ballmer Satya
 Nadella 1990 Windows 3.0 1992 Windows 3.1 1995 Windows 95 1998 Windows 98 2001 Windows XP 2007 Windows Vista 2009 Windows 7 2015 Windows 10 2011 2012 Windows 8
90. • 成功的案例例很香，失敗的案例例當然也⼤大有⼈人在 • 組織⽂文化、⼈人員、流程、⼯工具，缺⼀一不可 • 想吃 DevOps ⾃自助餐？那就試試看啊…
93. DevOps 的取捨
94. • ⽤用 DevOps 打造偉⼤大的世界級組織？ • ⾦金金字塔和長城是偉⼤大的⼯工程，修建它們的勞⼯工們卻不⼀一定過得好 • DevOps 玩得好，員⼯工不⼀一定比較快樂… • 從組織架構改變⼈人員的分類 → 對⼈人員的要求變⾼高 • 重新界定職能／⾓角⾊色，不再是單⼀一技能組了了 • ⾝身上擔負的責任變多了了 • 共事的隊友不⼀一樣了了 • …離開舒適圈了了…
95. • DevOps 就跟哈密瓜⼀一樣，有些⼈人喜歡、有些⼈人不喜歡～ • 不想／無法學太多東⻄西 • 不想思考⾃自⼰己該做什什麼 (隨波逐流、習慣接到任務指派) • 不想檢驗⾃自⼰己做得對不對 (反正我東⻄西給了了，會有⼈人看吧) • 做事⾃自由度變⾼高了了 • 不需要東等⻄西等、綁⼿手綁腳 • 產出比較健康 (有遙測指標佐證) • 跟著隊友⼀一起成長 • 不管老闆想不想⾯面對，DevOps 比較花錢 • 安全疑慮 (好像可以部署到⽣生產環境的⾓角⾊色變多了了) • …
96. • 「⾝身為做了了⼀一輩⼦子維運的⼈人來來說，DevOps 讓我們的⼯工作更更⼈人性 化。在過去，我每個假⽇日都在⼯工作，我的⽣生⽇日、我太太的⽣生⽇日、甚 ⾄至是我兒⼦子出⽣生的那天」 • 「作為⼀一名開發者，什什麼是我職業中最滿意的時刻？就是當我寫完 程式碼，⼀一鍵部署，然後看著各種指標、看看應⽤用程式在⽣生產環境 中是否正常運⾏行行，如果失敗了了，就修復它，然後再部署」
97. 原來來，我們早就在 DevOps
99. RD QA
102. Key Takeaways
103. • DevOps 不是流程、⾓角⾊色、萬靈丹丹，它是⼀一種新世代的公司治理理⽅方案 • 被逼出來來解決痛點：產品不符市場需求、產品發佈需時太長 • ⽬目標：將「業務需求→上線產品」迴圈操到最快，天下武功，唯快不破 • 精義：組織架構與⽂文化的轉型 (⼀一步⼀一腳印)，重新分類職能與⾓角⾊色 • 教條：精實、敏捷開發 (⼩小⽽而頻繁的發佈)、打破穀倉 (部⾨門壁壘壘)、互信 • 實踐：價值流視覺化 (Kanban) 與最佳化、⾼高度⾃自動化、各級遙測指標、
 　　　不指責的事後分析、解耦部署與功能發佈、持續改善、⾃自主學習…
104. 什什麼！DevOps 旁邊還有 NoOps, ITOps, CloudOps, AIOps,
 BizDevOps, DevSecOps, … 希望經過這份簡報之後
 我們能去檢驗這些 buzzwords
 想表達的是精神、想解決的問題
105. Fin. 感謝參參與 接下來來是討論時間