![[Agile Tour Hsinchu 2019] Our practice in the DevOps Process for Manufacture ...](https://cdn.slidesharecdn.com/ss_thumbnails/devopsmanufacture-191214052228-thumbnail.jpg?width=560&fit=bounds)
![[2021 .NET Conf]善用 Azure Monitor 服務打造 DevOps 監控一環](https://cdn.slidesharecdn.com/ss_thumbnails/azuremonitorlite-211219130844-thumbnail.jpg?width=560&fit=bounds)
![[2018 .NET Conf].NET Core與Azure DevOps應用於企業開發](https://cdn.slidesharecdn.com/ss_thumbnails/random-180929054552-thumbnail.jpg?width=560&fit=bounds)
![[2020 .NET Conf] 企業Azure DevOps Service 實際應用架構與秘辛](https://cdn.slidesharecdn.com/ss_thumbnails/azuredevopsservicelite-201221005403-thumbnail.jpg?width=560&fit=bounds)
More Related Content
What's hot (20)
Similar to Ops X Serverless (GCPUG.TW meetup 20180627) (20)
Ops X Serverless (GCPUG.TW meetup 20180627)
- 1. Earou Huang 黃一樓 現職 91app，開發&運維人員 ● Eclipse IDE plugin 開發 ● JMeter plugin 開發 ● 自動化測試框架設計 ● Socket-base Service 效能測試 ● Nginx in AWS 整合效能測試 ● 滑雪教練
- 2. Ops ? Serverless 讓 SRE 更輕鬆維運
- 3. Ops X Serverless (这个标题就只是一个干话)
- 4. 做什麼？ 怎麼做？
- 6. CICD Jeckins
- 8. 現實理想 Ops 為產品需求 Ops 是托嬰中心 線上問題 Feedback 給開發 線上問題 緊急處理後被遺忘 服務獨立性 鬼之相依性 部署流水線 指定倖存者 分析 Root Cause 都市傳說，呂布治百病 技術變產品 永遠的 60 分
- 9. SR ”Engineering” 1. 想做一些有 “價值” 的東西 2. 沒有人會開需求給你 3. 開需求給自己 （老闆會不知道你在忙什麼）
- 10. 小小 SRE 做什麼？評估的幾個面向 提供價值 降低 學習曲線 安全管理 减轻压力
- 11. 提供價值 識別重要的雜事 Workaround 需要被監控 User Story + Infra Monitoring
- 12. Taiwa n Service A VPC VM VM VM Service B VM VM VM Service C Cloud Platform (Tokyo) Main User Story 1
- 13. Main User Story 2 Taiwa n Cloud Platform (Tokyo) Service A VPC VM VM VM Service C Service B VM VM VM
- 14. 客戶 我的東西爛掉了 第一線人員需要知道... DNS 解析問題 海纜問題 服務對外配置問題 Cloud Platform 問題 CDN 問題 產品本身問題
- 15. Alarm
- 17. 經驗 + 對系統的熟悉程度
- 19. 經驗 + 對系統的熟悉程度
- 20. Taiwa n Service A VPC VM VM VM Service B VM VM VM Service C Cloud Platform (Tokyo) 如果有一個這樣的東西
- 22. 前端的問題 ● 空的 HTML ● 一張圖 ● div 標記 搞定！！！
- 26. Storage Checks ts ts ts ts ts ts Function Function Function Function Function Function update update update update update update Schedule 需不需要每個 Health Check Function 發 Alarm?
- 29. 我們解決了什麼問題... ● 將 Health Check 依照 User Story 分群 ○ 避免重複的過多的 Alarm ● 降低問題分析的技術門檻 ○ 看見全貌，第一線人員不需要再把問題往後丟 ● 節省不必要的溝通成本、時間成本 ○ 大海撈針，大家都懷疑可能是自己負責的部分出問題 (還記得鬼之相依性嗎) ○ 越大規模的公司越需要，尤其是新創轉成熟期
Editor's Notes
- #5: #避免累積更多醜陋的東西 #利用 Cloud Native 的優勢，創造 SRE 價值
- #9: 很多動不了的舊服務，因為新功能比較重要 很多 workaround，例如每週要跑特定 script 整理/sync 資料庫，否則服務會爛掉 或是過一陣子需要人工去清理某台機器的 memory，或重啟服務 鬼之相依性，一個重要的服務依賴一個不 HA 的邊緣服務 舉個例子(非真實案例)，一個頁面的推薦功能讀取失敗，整個頁面 Crash 以上的事情都順利完成，而你只有 60 分～～ 通常，來到這個場子的都不會是老闆，沒辦法給你什麼架構性的改變 如何由上往下的影響團隊
- #11: 價值面，數據再多，老闆也不一定認為有價值 (有價值的事 vs 沒價值的事) 把雜事變得有價值 例行性雜事數據化 (有沒有一些雜事是，一個月不做，就會影響很大的) workaround 需要被監控 Workaround 就像一個剛被假釋的犯人，需要被監控 技術面，用到的 Tech Stack，直接影響到可使用的人力資源多寡 安全層面，Ops 的權限控管 心態面，24 小時的壓力，增加壓力，減少壓力