網站可靠性工程工作手冊

網站可靠性⼯程⼯作⼿冊

• DevOps: ⼀套⼤致的實踐、準則和⽂化

• 別再有穀倉：把運維與開發團隊分離、缺乏協作、獎勵純粹局部優化

• 意外乃兵家常事：專注在加速恢復⽽非預防意外

• 變更應循序漸進：變更少量⽽頻繁

• ⼯具應⽤與⽂化息息相關

• 量測⾄關重要

• SRE : Google 提出, ⼀套實踐的信念

• SRE 類別實作了 DevOps 介⾯
DevOps v.s SRE

• SRE ⼯程師的關鍵！

• 服務可靠性的⽬標⽔準

• 幫助決定何種⼯作之優先順序

• 百分百可靠度是錯誤的⽬標！

• 對客⼾的邊際效益趨近於0 , 例如99.9% 到 99.99％ , 要付出很⼤的
成本但客⼾並不⾒得能夠體會到

• 如果你要達成100% ，將會更加害怕變更

• SLI v.s SLO v.s SLA
SLO 服務⽔準⽬標

• 對苦⼯的定義：

• ⼈⼯

• 重複

• 可⾃動化的

• 非戰略的/被動的

• 缺乏持久價值

• 與其來源成長的⼀樣快
消滅苦⼯

• 識別並測量苦⼯：能夠回本嗎？

• 盡⼒謀劃把苦⼯排出系統

• 利⽤SLO 來減少苦⼯

• 獲得管理階層與同事⽀持

• 從⼩做起然後改善：先⾃動化幾個⾼優先項⽬，不要希冀可以消滅所有苦⼯

• 評估⾃動化中的風險

• 使⽤開源和第三⽅⼯具

• 利⽤回饋來改善
苦⼯管理策略

• 什麼是好的事後檢討報告？
• 內容清晰

• 有之後具體的⾏動項⽬，有負責⼈及追縱的項⽬編號、可測量、
優先順序、預防

• 不究責

• 內容深度：衝擊、根源＆觸發原因、⾔之有物的結論

• 及時性：(要在事故發⽣後⼀週內就寫)
事後檢討的⽂化

• 分享公告

• 跨團隊審查

• 舉辦培訓

• 每週會報與故障停機
公開分享事後檢討報告

• 承認你不想要100%的可靠性

• 設置合理的SLO ⽬標，這SLO應該能量測對使⽤者⽽⾔最重要的可靠
性⾯向

• 協議有助於護衛使⽤者體驗的犯錯預算政策，運⽤犯錯預算以引導

• 戰術⾏動⽅針以緩解故障停機，或管理變更試圖恢復系統到某可靠
狀態

• 確定較長期的⼯作優先順序以使系統更可靠、且消耗更少犯錯預算

• 測量SLO 並承諾遵⾏犯錯預算政策。這項承諾需要公司領導階層同意
沒有SRE⼯程師的SRE實踐

• 從 SRE ⾓度改善舊系統

• https://earou.dev/zh/sre/Improve-Legacy-System-from-SRE-Perspective.html

• 3種CTO要⼩⼼的架構技術債

• https://www.ithome.com.tw/news/116435

• 技術債觀念及實務

• https://www.ithome.com.tw/voice/100462

• 檢討不淪為互相指責

• https://www.gvm.com.tw/article/54562

• 揭開 17LIVE SRE 神秘⾯紗

• https://medium.com/17media-tech/%E6%8F%AD%E9%96%8B-17live-sre-
%E7%A5%9E%E7%A7%98%E9%9D%A2%E7%B4%97-ad8b22f55f2f
補充⽂章

網站可靠性工程工作手冊

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (11)

Similaire à 網站可靠性工程工作手冊

Similaire à 網站可靠性工程工作手冊 (20)

網站可靠性工程工作手冊