暨研運數(shù)智化技術(shù)峰會2025年6月27-28日

中國

·

北京GOPS

全-XOps

風(fēng)向標(biāo)

北

京

站BizDevOps

承辦單位：指導(dǎo)單位：

品AOPSANNIVER5ARY2015-2025GOPS2025Beijing主辦單位：○開放運維聯(lián)盟0OPSAOpenOPSAllance高效運維社區(qū)GrarOPSCommnitySRE

進化論：運維工程師如何從背鍋俠蛻變?yōu)橄到y(tǒng)守護神■

□

□2025.6.28匯報人

牟禹O

p

s

風(fēng)

向

標(biāo)GOPS2025

BeijingANNIVERSARY2015-2025SRE

與傳統(tǒng)運維的區(qū)別

◎

1SRE

與1-5-

10體系關(guān)系

◎

2SRE

運維工程師實踐路徑

◎3SRE

實踐部分案例分享

◎

4目

錄GOPS2025

BeijingANNIVERSARY2015-2025SRE與傳統(tǒng)運維的區(qū)別X

O

p

s風(fēng)

向

標(biāo)ANNIVERSARY2015-2025GOPS2025BeijingC應(yīng)用運維是SRE

的一部分，

但應(yīng)用運維并不等同于SRE應(yīng)用運維就是SRE嗎?應(yīng)用運維與SRE

的關(guān)系豆包AlANNIVERSARY2015-2025GOPS

2025Beijing特征傳統(tǒng)運維組織SRE組織團隊協(xié)作各部門分工明確，開發(fā)與運維隔離強調(diào)跨職能協(xié)作，項目相關(guān)干系人均需參與自動化程度自動化程度較低，運維工作繁瑣強調(diào)工具平臺的建設(shè)，實現(xiàn)自動化，減少運維瑣事工作重點從運維角度關(guān)注基礎(chǔ)設(shè)施和應(yīng)用本身的穩(wěn)定性從業(yè)務(wù)視角關(guān)注全局業(yè)務(wù)穩(wěn)定性工作模式故障驅(qū)動的被動運維(被動救火)關(guān)注運維效能度量，數(shù)據(jù)驅(qū)動的主動運維服務(wù)級別管理傳統(tǒng)的監(jiān)控與手動管理，沒有SLO目標(biāo)的設(shè)定通過SLI指標(biāo)、SLO目標(biāo)、錯誤預(yù)算進行可量化的服務(wù)級別管理故障處理模式依據(jù)專家經(jīng)驗按部就班的流程處理故障，缺少應(yīng)急預(yù)案追求1-5-10目標(biāo)，優(yōu)先分析故障影響面，對故障快速止損，后查根因，減少故障對業(yè)務(wù)帶來的影響故障責(zé)任歸屬運維對故障基本負(fù)主要責(zé)任，運維成為背鍋俠SRE團隊目標(biāo)一致，共同承擔(dān)系統(tǒng)可靠性責(zé)任傳統(tǒng)運維組織與SRE

組織的區(qū)別ANNIVERSARY2015-2025GOPS

2025Beijing價值在保證IT服務(wù)高質(zhì)量的前提下，尋求技術(shù)創(chuàng)新和業(yè)務(wù)發(fā)展的平衡，推動組織文化向更加注重工程實踐和持續(xù)改進的方向發(fā)展。SRE

體系方法強調(diào)運維工作中采用工程化思維和工具化手段，將運維活動轉(zhuǎn)化為可度量、可決策優(yōu)化的數(shù)據(jù)驅(qū)動過程。SRE提出了服務(wù)級別指標(biāo)(SLI)

、

服務(wù)級別目標(biāo)(SLO),錯誤預(yù)算等一系列方法和工具，為系統(tǒng)穩(wěn)定可靠性提供了科學(xué)的管理和評估方法。實踐SRE

團隊通過在監(jiān)控、告警、容量規(guī)劃、故障恢復(fù)、性能優(yōu)化，跨團隊協(xié)同等方面的工作來解決具體的運維場景挑戰(zhàn)。實踐活動包括運維領(lǐng)域平臺開發(fā)，代碼自動化

運維任務(wù)、推進更可靠的系統(tǒng)架構(gòu)、制定并執(zhí)行SLO(Service

Level

Objectives)等。SRE

價值、方法論、實踐ANNIVERSARY2015-2025GOPS

2025BeijingSRE

與1-5-10體系關(guān)系X

O

p

s風(fēng)

向

標(biāo)ANNIVERSARY2015-2025GOPS2025BeijingC發(fā)生

發(fā)現(xiàn)

定位

恢復(fù)發(fā)現(xiàn)故障

故障定位

故障止損1

5

10定

位

：

定位并不是找到了故障具體根因，而是找到了故障大概位置，了解了故障的影響范圍，然后針對性的啟動應(yīng)急流程進行快速止損止

損

：并不是真正的完全恢復(fù)業(yè)務(wù)，而是通過可以采取的快速預(yù)案的執(zhí)行，減少故障對業(yè)務(wù)帶來的影響。

故障處置流程“1-5-

10”目標(biāo)早發(fā)現(xiàn)早治療追求1-5-

10治未病多預(yù)防追求更長的平均故障間隔時間告警管控故障響應(yīng)可觀測性故障定位應(yīng)急預(yù)案故障止損變更管理混沌工程性能容量穩(wěn)定性準(zhǔn)入測試管理發(fā)布策略1分鐘發(fā)現(xiàn)5分鐘定位10分鐘恢復(fù)運維側(cè)研發(fā)側(cè)實踐工具集可觀測性平臺統(tǒng)一告警平臺應(yīng)急預(yù)案平臺故障管理平臺AIOPS

智能根因定位平臺實踐工具集健康巡檢平臺變更管理平臺混沌工程平臺性能容量平臺部署發(fā)布平臺…平臺健康巡檢復(fù)盤管理持續(xù)運營架構(gòu)評審系統(tǒng)質(zhì)量部署過程SRE體系與1-5-10指標(biāo)關(guān)系穩(wěn)定性體系建設(shè)目標(biāo)SREANNIVERSARY2015-2025GOPS

2025BeijingSRE

運維工程師實踐路徑X

O

p

s風(fēng)

向

標(biāo)ANNIVERSARY2015-2025GOPS2025BeijingCSLO

核心價值：SLO

目標(biāo)不僅僅是運維的目標(biāo)，而是研發(fā)、運維、測試、產(chǎn)品經(jīng)理等相關(guān)干系人，共同制定、認(rèn)可和維護SLO

且

標(biāo)，例如：在一個周期內(nèi)，如果SLO目標(biāo)達標(biāo)，可以發(fā)布更多的新版本提升用戶體驗，如果SLO

目標(biāo)不達標(biāo)，在

相應(yīng)的周期內(nèi)只做安全穩(wěn)定性建設(shè)的變更，盡可能減少業(yè)務(wù)變更等措施來保證系統(tǒng)穩(wěn)定性。常用SLO

目標(biāo)示例：

(金融行業(yè)可以優(yōu)先參考監(jiān)管考核的目標(biāo)，通信行業(yè)可以優(yōu)先參考集團考核的目標(biāo))1、

核心業(yè)務(wù)系統(tǒng)可用性目標(biāo)為99.99%

(業(yè)務(wù))2、核心接口的調(diào)用成功率為99.95%

(接口)3

、關(guān)鍵URL

訪問95分位延遲小于100毫秒成功率為99.95%(應(yīng)用)滿足SLO

用

戶

滿

意

提升業(yè)務(wù)價值

業(yè)務(wù)營收四大黃金指標(biāo)可用性、錯誤率、延遲率、吞吐

量等系統(tǒng)可用性>99.99%(可用性)涉及后果、例如處罰賠償

SLA=SLO+后果SLI

(體現(xiàn)業(yè)務(wù)質(zhì)量的指標(biāo))SLO(業(yè)務(wù)期望達到的質(zhì)量目標(biāo))SLA

(服務(wù)等級協(xié)議)SLO目標(biāo)(業(yè)務(wù)系統(tǒng)穩(wěn)定性度量方法論)95分位延遲<100ms

(延遲)ANNIVERSARY2015-2025GOPS

2025Beijing準(zhǔn)備業(yè)務(wù)

系統(tǒng)確定利益

相關(guān)人定義期望

目標(biāo)開始定期回顧分享SLO

調(diào)整實踐和標(biāo)準(zhǔn)之旅的經(jīng)驗教訓(xùn)

SLO

目標(biāo)運營實踐路徑與軟件開發(fā)生命周期保持一致傾聽并吸引用戶和利益相關(guān)者響應(yīng)錯誤告警確保數(shù)據(jù)可靠調(diào)

整SLO目標(biāo)基

于SLO洞察運營收集SLI公

開SLO目

標(biāo)執(zhí)行錯誤預(yù)算

政策實現(xiàn)用戶旅程等級服務(wù)依賴分析系統(tǒng)行為觀測發(fā)現(xiàn)定義可實現(xiàn)的SLOs定義期望的SLOs定義有意義的SLIs建立錯誤

預(yù)算設(shè)計通過相關(guān)數(shù)據(jù)統(tǒng)分析，大概70%的生產(chǎn)事故由某種部署的變更而觸發(fā)容量風(fēng)險流量突然增加導(dǎo)致的故障。相對較少，但是影響是全局的，比如重大一些活動，微博的一些熱點事情，

都是容量和流量的變化導(dǎo)致的故障和影響。僉變更風(fēng)險最為常見的也是頻率多就是變更帶來的故障，日常變更多導(dǎo)致了各種各樣的故障。基礎(chǔ)設(shè)施，比如網(wǎng)絡(luò)/DC/DNS

等等這些的故障，這種故障一般非常少，但是影

響是非常重大的。變更管理是故障誘發(fā)的主要因素基礎(chǔ)設(shè)施風(fēng)險ANNIVERSARY2015-2025GOPS

2025Beijing山變更審批流程和執(zhí)行操作平臺化變更審批流程變更審批流程增加數(shù)據(jù)決策支撐，例如業(yè)務(wù)風(fēng)險影響分析，當(dāng)前業(yè)務(wù)SLO目標(biāo)達成情況作為決策依據(jù)，避免審批流程中參與審批的相關(guān)領(lǐng)導(dǎo)為了審批而審批變更執(zhí)行操作流水線發(fā)布變更工藝流程優(yōu)化CICD流水線，實現(xiàn)”一包到底”,確保發(fā)布不能繞過測

試環(huán)境，生產(chǎn)環(huán)境發(fā)布必須經(jīng)過預(yù)設(shè)的安全掃描等基礎(chǔ)設(shè)施變更嚴(yán)格遵循變更審批流程、變更自動與CMDB同步，高度保持CMDB

數(shù)據(jù)的一致性，讓CMDB數(shù)據(jù)成為唯一可信數(shù)據(jù)源數(shù)據(jù)庫及配置變更通過專用工具平臺執(zhí)行，禁止直接在生產(chǎn)環(huán)境執(zhí)行SQL或修改配置

文件，且必須雙人復(fù)核變更管理需要重點關(guān)注的事項ANNIVERSARY2015-2025GOPS

2025

Beijing監(jiān)控模式健康巡檢監(jiān)控是發(fā)生故障或者隱患事后被動通知模式；健康巡檢是主動對業(yè)務(wù)系統(tǒng)進行“體檢”的模式，預(yù)防性為主監(jiān)控是實時的、持續(xù)的數(shù)據(jù)采集與異常告警，如果告警治理

力度不夠，告警風(fēng)暴會覆蓋重要告警信息；時效>健康巡檢是周期性主動進行巡檢，只針對關(guān)注的指標(biāo)或數(shù)據(jù)

進行巡檢，及時發(fā)現(xiàn)業(yè)務(wù)穩(wěn)定性隱患；監(jiān)控更多關(guān)注的是基礎(chǔ)設(shè)施層面的指標(biāo)類監(jiān)控；范圍健康巡檢更多關(guān)注的是從“上帝視角”出發(fā)，更多關(guān)注的是業(yè)務(wù)穩(wěn)定性相關(guān)的關(guān)鍵數(shù)據(jù)和指標(biāo)。健康巡檢對業(yè)務(wù)系統(tǒng)的核心優(yōu)勢主動預(yù)防：通過定期深度檢查(如配置核查、接口可用性探測),提前發(fā)現(xiàn)潛在風(fēng)險，避免被動響應(yīng)；全局視角：

綜合評估系統(tǒng)整體健康度(如資源瓶頸、依賴服務(wù)狀態(tài)),彌補監(jiān)控單點告警的碎片化局限；業(yè)務(wù)連續(xù)性保障：

識別監(jiān)控盲區(qū)(如合規(guī)性、邏輯錯誤),降低“監(jiān)控正常但業(yè)務(wù)不可用”的風(fēng)險；健康巡檢與監(jiān)控的區(qū)別健康巡檢對業(yè)務(wù)系統(tǒng)穩(wěn)定性保障的優(yōu)勢ANNIVERSARY2015-2025GOPS

2025Beijing在分布式時代，系統(tǒng)規(guī)模呈指數(shù)級上升，故障發(fā)生的頻率變高。關(guān)于系統(tǒng)穩(wěn)定性，業(yè)界專家積累了很多正向建設(shè)的經(jīng)驗和原則，但缺乏有效的反向驗證手段，混沌工程主動注入故障就是典型的反向驗證手段。風(fēng)險到事故的”海因里希法則”1

嚴(yán)重事故29

輕微事故

實際的故障數(shù)量很少，導(dǎo)致“工程師

得不到訓(xùn)練”300

潛在風(fēng)險

大部分的風(fēng)險不會轉(zhuǎn)化成故障，導(dǎo)

致“僥幸心理”內(nèi)容摘自《商業(yè)銀行混沌工程研究和實踐白皮書》為什么需要引入混沌工程ANNIVERSARY2015-2025GOPS

2025Beijing系統(tǒng)架構(gòu)驗證

技術(shù)架構(gòu)韌性

應(yīng)用架構(gòu)韌性應(yīng)急預(yù)案驗證應(yīng)急預(yù)案完備性

應(yīng)急預(yù)案保鮮度

應(yīng)急協(xié)同能力監(jiān)控是否覆蓋系統(tǒng)健壯性限流降級負(fù)載過高內(nèi)存溢出容器重啟POD不啟動CPU

負(fù)載內(nèi)存負(fù)載告警是否及時容器實驗主機實驗大請求發(fā)送代理超時容器移除Pod刪除進程殺死

DNS

異常監(jiān)控告警驗證業(yè)務(wù)系統(tǒng)演練微服務(wù)

演練場景容器云

演練場景硬件服務(wù)器

演練場景數(shù)據(jù)庫切換中間件重啟Node關(guān)機Node污點主機資源枯竭SDN

服務(wù)異常網(wǎng)絡(luò)異常流量超限Node重啟POD

擴容網(wǎng)絡(luò)亂序

網(wǎng)絡(luò)延遲告警是否準(zhǔn)確啟停順序容量評估混沌工程故障場景故

障

分

層

覆

蓋

及

驗

證ANNIVERSARY2015-2025GOPS

2025Beijing混沌工程在企業(yè)的實踐路徑測試環(huán)境

類生產(chǎn)環(huán)境

灰度發(fā)布環(huán)境

生產(chǎn)環(huán)境●企業(yè)進行混沌演練，建議根據(jù)測試環(huán)境、類生產(chǎn)環(huán)境、灰度發(fā)布環(huán)境到生產(chǎn)環(huán)境循序漸進的推進；●

根據(jù)行業(yè)情況和特性，并不是必須要在生產(chǎn)環(huán)境演練，但是在類生產(chǎn)環(huán)境或者灰度發(fā)布環(huán)境演練時，建議系

統(tǒng)架構(gòu)、監(jiān)控配置、應(yīng)急預(yù)案均和生產(chǎn)環(huán)境保持一致，而

且

在類生產(chǎn)環(huán)境中發(fā)現(xiàn)的故障和隱患，要視作生產(chǎn)

環(huán)境的故障和隱患進行處理；●

建議成立專業(yè)混沌工程小組，鼓勵多發(fā)現(xiàn)故障隱患，對于業(yè)務(wù)未發(fā)生故障之前，提前發(fā)現(xiàn)的隱患進行鼓勵。單次混沌實驗步驟參考

混沌工程實踐流程故障注入場景、爆炸半徑的設(shè)計對系統(tǒng)架構(gòu)進行故障場景分析演練準(zhǔn)備及周知時間計劃演練報告及改進建議改進閉環(huán)管理執(zhí)行演練可

觀

測

性

實

踐

建

議

：●

采

用OpenTelemetry標(biāo)準(zhǔn)：統(tǒng)一指標(biāo)、日志和鏈路追蹤的數(shù)據(jù)收集●實現(xiàn)上下文關(guān)聯(lián)：指標(biāo)、鏈路、日志所有數(shù)據(jù)可關(guān)聯(lián)、可探索●關(guān)注黃金信號：可用性(系統(tǒng)可用時間率)、延遲(處理請求所需時間)、錯誤率(請求失敗的比例)、吞吐量

(系統(tǒng)資源的使用程度)通過系統(tǒng)輸出來理解內(nèi)部狀態(tài)的能力，無需預(yù)先定義所有可能

的故障模式，能夠探索未知、未預(yù)期的系統(tǒng)行為。強調(diào)多維度數(shù)據(jù)聚合展示及分析：指標(biāo)(Metrics)

、

日志(Logs)

、鏈路(Traces)

、

事件(Eve

nts),提升故障快速定位能能力。依賴專家經(jīng)驗預(yù)設(shè)的數(shù)據(jù)源(如指標(biāo)、日志),對已知的、預(yù)期的故障模式進行檢測，且各監(jiān)控平臺比較割裂，排查故

障需要在各平臺來回切換。監(jiān)控是可觀測性的一種實現(xiàn)手段，而可觀測性提供了更全面的系統(tǒng)理解能力。可觀測性與監(jiān)控的區(qū)別可觀測ANNIVERSARY2015-2025GOPS

2025Beijing監(jiān)

控應(yīng)急預(yù)案設(shè)計

平臺化實現(xiàn)

常態(tài)化演練

預(yù)案迭代更新全年演練計劃故障復(fù)盤更新演練周知演練執(zhí)行●應(yīng)急預(yù)案是集故障預(yù)防、應(yīng)急協(xié)同處置與快速止損于一體的系統(tǒng)性最佳實踐方案?！窠ㄗh建設(shè)應(yīng)急預(yù)案平臺，提升應(yīng)急預(yù)案快速止損能力，

當(dāng)發(fā)生故障時，參與應(yīng)急預(yù)案編寫的人員處理故障時基本不用看應(yīng)急預(yù)案文

檔，需要看應(yīng)急預(yù)案文檔的人員進行故障處理時，會影響故障止損的速度?！?/p>

應(yīng)急預(yù)案需要定期進行演練，保證應(yīng)急預(yù)案的保鮮度和提升人員對故障處理的協(xié)同能力。平臺化應(yīng)急預(yù)案全流程參考預(yù)案流程編排原子庫開發(fā)操作可視化切流限流降級

熔斷回滾等常規(guī)故障處理

流程梳理應(yīng)急預(yù)案實現(xiàn)故障快速協(xié)同及止損預(yù)案定期評審ANNIVERSARY2015-2025GOPS

2025

BeijingSRE實踐部分案例分享X

O

p

s風(fēng)

向

標(biāo)ANNIVERSARY2015-2025GOPS2025BeijingC100%80%60%40%20%0%1

日2

日3

日4

日5

日6

日7

日8

日

9

日

1

0

日

1

1

日100%80%60%40%20%0%1日

2日

3日

4日

5日

6日

7日

8

日

9

日1

0日1

1日100%80%60%40%20%0%100%80%60%40%20%0%還款成功率②100%本月成功率考核目標(biāo)≥99.99%詳情20000剩余允許錯誤數(shù)量考核目標(biāo)≤20000SRE

案例：SLO

運營穩(wěn)定性可觀測大屏原型圖展示1

日

2

日

3

日

4

日

5

日

6

日

7

日

8

日9

日

1

0

日

1

1

日某某API接口調(diào)用成功率②

詳情100%本月成功率考核目標(biāo)≥99.99%20000剩余允許錯誤數(shù)量

考核目標(biāo)≤20000100%本月成功率考核目標(biāo)≥99.99%20000剩余允許錯誤數(shù)量

考核目標(biāo)≤20000100%本月成功率考核目標(biāo)≥99.99%20000剩余允許錯誤數(shù)量

考核目標(biāo)≤20000100%本月成功率考核目標(biāo)≥99.99%20000剩余允許錯誤數(shù)量

考核目標(biāo)≤20000100%本月成功率考核目標(biāo)≥99.99%20000剩余允許錯誤數(shù)量

考核目標(biāo)≤0000重點業(yè)務(wù)SLO目標(biāo)可觀測大屏某某應(yīng)用請求成功率②

詳情用戶注冊成功率?

詳情提款成功率②

詳情授信成功率②

詳情100%80%60%40%20%0%100%80%60%40%20%0%1

日

2

日

3

日

4

日

!5

日

6

日

7

日

8

日9

日

1

0

日

1

1

日1

日

2

日

3

日

4

日

5

日

6

日

7

日

8

日

9

日

1

0

日

1

1

日1

日

2

日

3

日

4

日

5

日

6

日

7

日8

日

9

日

1

0

日

1

1

日ANNIVERSARY2015-2025GOPS

2025Beijing志錯誤數(shù)

基礎(chǔ)設(shè)施狀態(tài)

網(wǎng)絡(luò)質(zhì)量狀態(tài)K8s事件狀態(tài)

末次部客或重啟時間test-y?kld2025-05-2209:3532ecs-backend-core-service-yjzh-test-rzakm?/ecs-backenservice/commandCenter/getComman

dCenterByOrgldGET

/ecs-backend-core-service/commandCenter/getSelfAndC

hildlistGET

/ecs-backend-core-service/commandCenter/queryByCen

terCodeGET

/ecs-backend-core-service/userlnfo/getUserlnfoByUserld自

身自

身自

身自

身日同尼周同比6.67ms日同比周同比6.34ms日同比周同比29.76ms日同比周同比日同

比周同比0%日同比周同比1.6次/日同周同比0.2次/分日同比周同比2025-05-22093727更多總計2條數(shù)據(jù)服務(wù)概覽命名空間：刷新于14小時前⑥

Last5minutesSRE

案例：可觀測性根據(jù)業(yè)務(wù)接口或告警信息進行下鉆告警管理日志檢素鏈路追蹤全局資源基礎(chǔ)設(shè)施應(yīng)用指標(biāo)中間件工。接入中心配中心系統(tǒng)管理C服務(wù)概覽ANNIVERSARY2015-2025GOPS

2025

BeijingC

admin告警分析

免費公測

刷新于14小時前

Last

5

minutes

admin服務(wù)概覽(

/服務(wù)詳情es-backend-core-service-yizh-test-rzakm?的所有依賴視圖(包括所有遞歸依賴)依賴節(jié)點延時曲線全覽對比圖依賴節(jié)點延時曲線相似度排序ecs-backend-core-service-yjzh-test-zakm8(GET/ecs-backend-core-service/commandCenter/getCommandCenterByOrgld)SELECT

ecs.ecs_sys_region25.37.69.144:13306(SELECTecs.ecs

sys

region)25.37.69.169:16379(HGED)service-yjzh-test-25.37.69.169:16379HGETe/commandCenter/getComma18:04

18:052應(yīng)用指標(biāo)入口應(yīng)用名稱

命名空間

入口服務(wù)端點延時主要來源(自身/依賴/未知平均響應(yīng)時間錯誤率

日志錯誤數(shù)

基礎(chǔ)設(shè)施狀態(tài)網(wǎng)絡(luò)質(zhì)量狀態(tài)

K8s事件狀態(tài)

啟時間ecs-backend-core-default

service-yjzh-test-rzakm8GET

/ecs-backend-core-service/commandCenter/getCommandCenterByOrgld4次/分總計1條數(shù)據(jù)SRE

案例：下鉆到對應(yīng)接口的鏈路圖及影響面分析es-backend-core-service-yizh-test-zakm8的告警事件ecs-backend-core-service

yizh-test-zakm8的服務(wù)端點實例ecs-backend-core-service-yjzh-test-zakm8

的

k8s事

件可能受該接口影響的所有服務(wù)入口分

析，其中“服務(wù)入口”是指業(yè)務(wù)被訪問

時調(diào)用的第一個服務(wù)端點，是調(diào)用鏈

路中的最上游。ecs-backend-core-service-yizh-test-zakm?的直接上下游依賴關(guān)系圖服務(wù)端點：GET/ecs-backend-core-service/commandCenter/getCommandCenterByOrgld2中向件T接入中心中配置中心系統(tǒng)管理rzakm8GET

/ecs-backend-core-servicecs-backend-core-service-yjzh-test-zakm8的

影

響

面

分

析日志檢索己鏈路追蹤25.37.69.144:1330618:01

18:02

18:03ecs-backend-core-GOPS2025BeijingANNIVERSARY2015-2025ndCenterByOrgld查著更多下游依賴服務(wù)概覽基礎(chǔ)設(shè)施告警管理全同資源1068配置中心潦系統(tǒng)管理目ecs-backend-core-service-yjzh-test-rzakm8的數(shù)據(jù)庫調(diào)用數(shù)據(jù)庫連接

數(shù)據(jù)庫操作

數(shù)據(jù)庫名

平均響應(yīng)時間

錯誤率吞吐量

數(shù)據(jù)庫源25.37.69.169:16379

HGET

日同比周同比日同比周同比0.8次/分日同比同同比25.37.69.169:16379

PING

同比

日同比周同比

樂2次/分日同比周同比實例名平均響應(yīng)時間日志錯誤數(shù)量基礎(chǔ)設(shè)施狀態(tài)絡(luò)質(zhì)量狀態(tài)主機節(jié)點信息末次部署或重啟時間ecs-backend-core-service-yjzh-test-rzakm8-7b7dc?d6cf-nbpqh7.27ms日同比周同比日同比周同比主機名：

25.37.659.158

主機UP:25.37.69.1582025-05-2209:37:27Pulled

Pulling

Scheduled

Started

SuccessfulCreate次數(shù)(7天：0

次數(shù)(7天):0次數(shù)(30天):2

次數(shù)(30天):2總計1條數(shù)據(jù)全局資源SRE

案例：下鉆到服務(wù)端點實例、

K8S

事件、數(shù)據(jù)庫調(diào)用關(guān)系基礎(chǔ)設(shè)施應(yīng)用指標(biāo)中間件工。接入中心中服務(wù)概覽ecs-backend-core-service-yjzh~告警分析

免費公測eCS-UacKend-core-service-yjzh-te刷新于14小時前

Last

5minutes

admin告警管理日志檢索己鏈路追蹤ecs-backend-core-service-yjzh-test-rzakm8的k?s事件es-backend-core-service-yizh-test-zakm?的錯誤實例ANNIVERSARY2015-2025GOPS2025

Beijing錯誤率

故障現(xiàn)場Trace18:0318:0318:04

18:05暫無數(shù)據(jù)18:03

18:04

18:0518:0018:0118.0218:0318:0318:0418:05暫無數(shù)據(jù)18.03

18.04

18:05日志錯誤數(shù)量

響應(yīng)時間90分位數(shù)

錯誤率

故障現(xiàn)場日志842018:02

18:0318:04

18:05

18:01ecs-backend-core-service-yjzh-test-rzakm8-7b7dc?d6cf-nbpqh18:01

18:0218:03

18:04

18:0510862018:01

18:02

18:03

18:04

18:05鏈路追蹤實例名日志錯誤數(shù)量鳴應(yīng)時間90分位數(shù)SRE

案例：下鉆到故障現(xiàn)場日志和鏈路0.80.60.40.2018:05ecs-backend-core-rzakm8-7b7dc6d6cf-nbpqh18.01日志檢素基礎(chǔ)設(shè)施應(yīng)用指標(biāo)中問件接入中心中配置中心系統(tǒng)管理0.80.60.40.2018:0118:02刷新于14小時前

Last

5

minutes

admin服務(wù)18:02

18:03

1804ANNIVERSARY2015-2025GOPS

2025

Beijing總計1條數(shù)據(jù)總計1條數(shù)據(jù)告警管理18:0218.01故障演練階段計劃參考階段階段內(nèi)容具體內(nèi)容各階段參與人員各階段時間計劃第一階段對所選業(yè)務(wù)進行故障風(fēng)險調(diào)研對所選的業(yè)務(wù)系統(tǒng)進行故障風(fēng)險調(diào)研，展開故障場景分析(包括數(shù)據(jù)流、請求調(diào)用關(guān)系

、系統(tǒng)架構(gòu)、技術(shù)架構(gòu)、部署架構(gòu)等)混沌小組、系統(tǒng)架構(gòu)師、研發(fā)、運維、業(yè)務(wù)等第二階段制定具體演練項并跨部門評審基于深度調(diào)研結(jié)果，制定所選業(yè)務(wù)系統(tǒng)的故障演練方案和爆炸半徑，涵蓋核心鏈路潛在

的故障點，同時對于制定的演練項進行跨部門評審混沌小組、系統(tǒng)架構(gòu)師、研發(fā)、運維、業(yè)務(wù)等第三階段演練準(zhǔn)備及周知提前給需要演練的相關(guān)服務(wù)器安裝混沌工程Agent,并配置好相關(guān)演練項，同時周知相關(guān)人員做好演練準(zhǔn)備混沌小組、運維第四階段演練執(zhí)行根據(jù)制定的演練計劃，實施正式演練，演練過程對演練是否符合預(yù)期、應(yīng)急預(yù)案、監(jiān)控圖表、告警等信息進行記錄，必要時可以錄

屏混沌小組、系統(tǒng)架構(gòu)師、研發(fā)、運維、業(yè)務(wù)等第五階段編寫混沌演練報告編寫故障演練報告及未來改進規(guī)劃，包括：故障演練原始報告、故障演練數(shù)據(jù)分析、業(yè)務(wù)系統(tǒng)故障風(fēng)險及影響、運維相關(guān)故障風(fēng)險及影響，以及故障演練的未來改進規(guī)劃，輸出故障演練報告及未來改進規(guī)劃混沌小組第六階段故障演練復(fù)盤對演練過程和演練報告進行復(fù)盤及分析，優(yōu)化演練規(guī)范，適配并推廣到其他業(yè)務(wù)演練場

景，以達到常態(tài)化演練，提升各系統(tǒng)的應(yīng)急

響應(yīng)能力?；煦缧〗M、系統(tǒng)架構(gòu)師、研發(fā)、運維、業(yè)務(wù)等SRE

案例：混沌工程故障演練階段計劃參考ANNIVERSARY2015-2025GOPS

2025Beijing故障演練項制定及演練記錄模板演練前整理演練時記錄產(chǎn)品或服務(wù)微服務(wù)功能故障注入設(shè)計該故障會造成什么業(yè)務(wù)影響應(yīng)急預(yù)案目標(biāo)RTO(分鐘)目標(biāo)RPO(分鐘)演練實際效果應(yīng)急預(yù)案架構(gòu)容錯性監(jiān)控及告警實驗RTO(分鐘)實驗RPO(分鐘)信用卡快捷支付銀聯(lián)快支付銀聯(lián)快捷退貨選擇qpay服務(wù)的一個

pod,注入網(wǎng)絡(luò)中斷

故障有冗余措施，單點故障不會

造成業(yè)務(wù)影響通過容器集群管理機制自動檢測服務(wù)狀態(tài)，自動隔離故障節(jié)點并

重建新容器20業(yè)務(wù)基本無影響達標(biāo)達標(biāo)達標(biāo)10信用卡快捷支付銀聯(lián)快支付銀聯(lián)快捷退貨同城容災(zāi)：停止單個

機房的qpay服務(wù)50%的客戶交易失敗持續(xù)2分

鐘通過容災(zāi)的方式切換到同城數(shù)據(jù)

中心2050%的客戶交易失

敗在2分鐘內(nèi)恢復(fù)達標(biāo)達標(biāo)達標(biāo)20信用卡快捷支付銀聯(lián)快支付銀聯(lián)快捷退貨異地容災(zāi)：停止同城

兩個機房的qpay服務(wù)100%的客戶交易失敗持續(xù)10分鐘通過容災(zāi)的方式切換到異地數(shù)據(jù)

中心100100%的客戶交易失

敗持續(xù)6分鐘達標(biāo)達標(biāo)達標(biāo)60SRE

案例：混沌工程演練項制定參考ANNIVERSARY2015-2025GOPS

2025BeijingChaosBlade

English中

文t應(yīng)用高可用服務(wù)應(yīng)用高可用服務(wù)/故障演練/我的空間

default

□我的空間概覽我的空間演練場景演練經(jīng)驗應(yīng)用管理探針管理數(shù)據(jù)管理

□經(jīng)驗庫管理●執(zhí)行過的演練

21

口失敗：2

口運行中：0

□成功:19

●未執(zhí)行的演練

11

●總演練數(shù)

32新建演練口全部停止請選擇狀態(tài)

□

已選0個標(biāo)簽

口

口請輸入演練名稱

□只看定時演練

應(yīng)用接入演練名稱

標(biāo)簽

場果

創(chuàng)建時間定時任務(wù)最近運行狀態(tài)

最近運行時間操作haproy01-kepalived進程殺死P

2025-05-2217:39:58□成功

2025-05-2217:40:02演練拷貝

刪除haproy01-haproy)進程殺死

2025-05-2217:30:57

□成功

2025-05-2217:34:49