Recommended
More Related Content
What's hot
What's hot (19)
Similar to DevOps Days Taipei 2018
Similar to DevOps Days Taipei 2018 (20)
DevOps Days Taipei 2018
- 2. 大綱 1. What is DevOps 介紹什麼是DevOps 2. DevOpsDays Review 會以統整後的方式分享這次參與DevOpsDays的收穫 3. Open Space Review 在Open Space討論了什麼議題，以及結論 4. Conclusion 2
- 3. Cobra Chen Title: Backend Engineer Main: PHP (Laravel) E-mail: cobrachen7762@gmail.com Hello！ 3
- 4. What is DevOps ? DevOps是一種合作的文化，而非規則。 1 4
- 6. 程式發佈週期縮短的影響 佈署的速度需要提升 問題能快速被發現與快速止血 為什麼要提倡 DevOps 不同部門的溝通問題 開發：執行效率、功能的完整性 維運：穩定性、安全性、問題處理 市場：更快速提供服務 6 導入DevOps的目的在於 ◉ 透過合作降低開發與維運成本，提高產能 ◉ 降低不同部門痛點不同造成的誤會和爭執
- 8. ◉ 衡量 – DevOps 架構下的人工智慧思維 (Ruddy) ◉ 大型銀行實現 DevOps 的挑戰和關鍵(周紀海) ◉ 微服務的基礎建設 - Service Discovery(吳剛志) ◉ 我們需要 DevOps 嗎?(郭家齊) ◉ 工控產業 DevOps 導入經驗談(王泰翔) ◉ 微軟工程團隊的 DevOps 轉型挑戰、現況與經驗 (胡德民) ◉ The Transformation and Modernization of Line's In-House Legacy Deployment System(洪立遠) ◉ AIOps 思維的 Observability(蔡繼東) ◉ 從緊急事件，談 SRE 應變能力的培養(黃冠元) ◉ Secure or Die，軟體交付的「安全」實踐 (曾凱平) ◉ 沒有度量就沒有管理 --洞察DevOps能力成長模型(劉征) ◉ 91APP 的敏捷實踐之旅(周旺暾) 參加議程 8 議程連結
- 9. 內化後的產物 1. DevOps 導入DevOps的問題、經驗、建議 2. 度量 這是一個靠數據說明的時代，主觀感覺只是幹話 3. Observerbility(可觀測性) 外部觀測的結果是否真的能推論出內部狀態 4. 意外發生的應變處理 先閉上眼睛，深呼吸三十秒 9
- 10. 思維難改變 抗拒變化或學習、只要求速度不要求程式碼質量 溝通的障礙 不同部門的痛點與背景知識不同，在溝通上可能會產生誤解 資訊或認知差異 資訊不對等會造成立基點偏差，討論難以達成共識 見樹不見林(Silo Effect) 開發成員只專注於 Task 而不在乎商業價值(缺乏大局觀) 或是只關注自己的專案，不同團隊之間的協作會有障礙 轉型DevOps遇到的問題 10 這些問題的共通點是什麼？
- 14. 誰來定義 Server 好或不好 以使用者體驗當作標準，包含服務的速度性與正確性 傳統監控的問題 瞬時負載超出警報臨界值，但是下一刻又回到正常值內，警報該不該提醒？ 動態監控的思考方向 Anormaly Detection(異常檢測) Dynamic Time Warping(動態時間校正) Observerbility(可觀測性) 14 警報是真的發生異常才通知 而不是看到黑影就開槍 那會讓使用者麻痺，甚至忽視
- 16. Open Space Review 一個聰明人的問題中已包含著一半答案。 伊本・蓋比魯勒《珍珠的選擇》 3 16 大會 Open Space 共筆連結
- 17. 1. 即興討論區 議題發起人與路人隨意參加，隨意離去，不具備任何強迫性 2. 任何問題都可以被提出 可以當問題提出者，也可以當解惑者，甚至當個聽眾 3. 不一定會有答案 屬於發散式的討論，當前主題可能隨時被新的問題取代 4. 反應業界當前遇到的問題 參予者多是同行，遇到的問題往往類似 什麼是 Open Space 17 可以當討論者、聽眾 甚至只是純路過 選擇自己最舒適的方式參與
- 18. Open Space 主題 1. 探討什麼是 DoD 不是討論怎麼明確寫出DoD，而是在此之前要思考的事情 2. 敏捷團隊需要哪些成員？如何提升只有 RD 的敏捷團隊效率 市場、QA是否需要加入團隊？缺乏成員的情況下該如何提升流暢度？ 3. 純 RD 團隊如何導入 Ops 概念 Ops苦，但Dev不清楚 4. DevOps 遇到瓶頸(人、事、物)該怎麼辦？ 路過看到，很血腥 18
- 19. 探討什麼是 Definition of Done 19 1. 釐清進行 Review 的角色對象 開發、維運、市場團隊的痛點不同，驗收標準也會有不同的考量 決定 Review 的對象，再來考慮驗收標準該如何定義，避免失焦 2. 對產品的階段有共識 先確定這次的 DoD是針對開發、測試，還是包含到佈署上線 不同的時期會影響到實際工作的範圍 在討論DoD前先決定好錨點 先有共識才不會漫無方向
- 20. 敏捷團隊需要哪些成員 20 1. 如何說服不同部門的人加入敏捷團隊？ 從對方的角度來說明一起加入敏捷團隊後能替對方的部門帶來多少的價值 也可以利用工作坊的形式分享敏捷概念給不同部門，讓概念擴散 2. 多部門組成的敏捷團隊會面臨到的問題 User Story 如何撰寫？ Task 如何拆分？ 工時如何預估？ DoD 如何定義？ 不一定適合將所有人都放在同一個敏捷團隊 關鍵還是在於資訊的透明度與溝通的渠道
- 21. 21 1. 事先確認基礎環境 Coding Style、程式結構、開發環境、專有名詞統一...等 降低在新成員加入開發團隊與溝通上的成本 2. 切割不同團隊之間的耦合度 外部原因造成 Task Flows 停滯都需要被標注清楚 PO或SM要針對此部份優先處理，降低 Team 等待的時間 RD經驗與能力影響團隊效率 資訊透明度與溝通能力 則會嚴重影響團隊效率 如何提升只有 RD 的敏捷團隊效率
- 22. 純RD團隊如何導入Ops概念 22 1. 由小團隊導入，做出價值 在小團隊內導入Dev與Ops的概念，透過分工與互相支援來培養合作關係 當價值出現且被觀察到時，概念自會慢慢擴散 2. 痛過就知道 重點是痛過後內化成經驗，避免下次開發又踩到相同的坑 提升程式的品質與穩定度，而不是只想著Copy Paste 自己的坑自己填，培養責任心 不該有干我屁事、卸責心態 Ops很辛苦！
- 23. DevOps遇到瓶頸解決經驗討論 23 1. 簡化 Task 列表 適當的拆分 Task 與狀態的同步更新，可以增加專案進度的透明度 2. 紀錄工作進度 Member 主動說明當前進度是一個非常重要的溝通方式 3. 換人 文化沒有標準答案，只有適合與否 向心力是自組織的一個重要元素 Scrum只是工具，是可以被調整的 找到適合團隊的方式才是最重要的
- 26. Any questions ? 或者可以Email我，雖然我不常看信(笑 ◉ CobraChen7762@gmail.com Thanks! 26