Alerta系統容量→操作和管理

1）為什麼需要它

電容變量警告說，在事件發生前很久就接近技術限制：「我們離天花板80%是時候擴大規模了。」對於雜貨商來說，這直接是關於金錢：錯過投註/存款，會話失誤，直播遊戲延遲和提供商拒絕=收入損失，聲譽，罰款和回扣。

• 可以預見的是承受峰值負荷（活動、錦標賽、流媒體、大型活動）。
• 按時打開自動滑板，並計劃容量提升。
• 減少SLO/金錢風險時的噪音並喚醒。
• 通過運行手冊向工程師提供準確的建議。

2）基本概念

容量（Capacity）-最大限度地保持吞吐量（RPS/TPS,連接器,IOPS, throughput）。
Headroom：當前負載和限制之間的余量。
SLO/SLA：目標可用性/響應時間級別；Alertes必須是「SLO-aware」。
Burn-rate：SLO預算「燃燒」錯誤/潛伏的速度。
High/Low Watermark：用於觸發和自動恢復的上層/下層。

3）信號架構和數據源

遠程計量學：度量（Prometheus/OTel），logi（ELK/ClickHouse），跟蹤（OTel/Jaeger）。
分層方法：按層排列（Edge → API →業務服務→隊列/流→ DB/緩存 →文件/對象存儲→外部提供商）。
背景：ficheflagi，發行版，營銷活動，錦標賽，地質布局。
事件總線：Alertmanager/PagerDuty/Opsgenie/Slack；綁定到runbook和升級矩陣。

4）按層劃分的關鍵指標（監視什麼以及為什麼）

Edge / L7

RPS, 95-99-percentile latency, error rate （5xx/4xx）, open connections.

Rate-limits/quotas, drops на CDN/WAF/Firewall.

API-шлюз / Backend-for-Frontend

通過鍛煉者/鍛煉池，查詢隊列，定時到下流。
降解比例（fallbacks，電路斷路器）。

隊列/流媒體（Kafka/Rabbit/Pulsar）

Lag/consumer delay, backlog growth rate, throughput (msg/s, MB/s).

分區skew，重建教堂，ISR（用於Kafka），retrai/祖父。

異步操作員

任務等待時間、隊列長度、逾期任務的SLA百分比。
池中的飽和CPU/內存/FD。

緩存（Redis/Memcached）

Hit ratio, latency, evictions, used memory, 連接的客戶端/ops/s。
群集：插槽/復制副本,failover事件。

БД (PostgreSQL/MySQL/ClickHouse)

Active connections vs max, lock waits, replication lag, buffer/cache hit.

IOPS, read/write latency, checkpoint/flush, bloat/fragmentation.

對象/文件存儲

PUT/GET latency, 4xx/5xx, egress,查詢/秒,提供商限制。

外部提供商（付款/KUS/遊戲提供商）

TPS限制，窗口QPS，error rate/timeout，轉發隊列，「cost per call」。

基礎架構

CPU/Memory/FD/IOPS/在節點/pods/ASG上的網絡設置。
HPA/VPA事件，pending pods，集裝箱OOM/Throttling。

5）電容變量類型

1.靜態閾值

簡單易懂：'db_connections> 80% max'。好像「信號燈塔」。

2.自適應（動態）閾值

基於季節性和趨勢（滾動windows，STL分解）。允許捕獲「每周這個小時/天異常高」。

3.SLO定向（burn-rate）

當X時鐘視野中的SLO受到錯誤預算穿越速度的影響時觸發。

4.預測（預測）

「在當前趨勢下的20分鐘內，隊列將達到90％。」在短窗口上使用線性/Robust/Prophet樣預測。

5.復合（多信號）

結合使用：'queue_lag ↑'+'consumer_cpu 85%'+'autoscaling at max' →「需要手動幹預」。

6）閾值政策與反噪音

High/Low Watermark:

上圖：70-75%的警告，85-90%的克裏特島。向下：滯後5-10個百分點。不要「沖過門檻」。

• 'for： 5 m' for crits, 'for： 10-15 m' for警告。夜間模式：在沒有分頁的聊天中漫遊非關鍵。

• 按服務/集群/地質分組,以免發生事故。

Dependency-aware suppression:

如果KYC提供者出局和API錯誤，則結果是集成所有者而不是所有消費者的分頁。

• 在股票期間，提高了「預期增長」的噪音閾值，但使SLO-Alerta保持不變。

7）規則示例（偽普羅米修斯）

ALERT PostgresConnectionsHigh
IF (pg_stat_activity_active / pg_max_connections) > 0. 85
FOR 5m
LABELS {severity="critical", team="core-db"}
ANNOTATIONS {summary="Postgres connections >85%"}

ALERT StreamBacklogAtRisk
IF (kafka_consumer_lag > 5_000_000 AND rate(kafka_consumer_lag[5m]) > 50_000)
AND (hpa_desired_replicas == hpa_max_replicas)
FOR 10m
LABELS {severity="critical", team="streaming"}

ALERT ApiLatencySLOBurn
IF slo_latency_budget_burnrate{le="300ms"} > 4
FOR 15m
LABELS {severity="page", team="api"}
ANNOTATIONS {runbook="wiki://runbooks/api-latency"}

ALERT RedisEvictions
IF rate(redis_evicted_keys_total[5m]) > 0
AND (redis_used_memory / redis_maxmemory) > 0. 8
FOR 5m
LABELS {severity="warning", team="caching"}

ALERT PSPThroughputLimitNear
IF increase(psp_calls_total[10m]) > 0. 9 psp_rate_limit_window
FOR 5m
LABELS {severity="warning", team="payments", provider="PSP-X"}

8） SLO方法和業務優先級

從信號到業務影響：容量差異應引用風險到SLO（特定遊戲/地理/GGR度量，存款轉換）。
分層：呼叫服務警告；克裏特島-域所有者的頁面；SLO跌落是主要事件和命令「合並」頻道。
Ficheflagi降解：自動減少負載（部分只讀負載，減少重型眼鏡，降低頭獎流浪者的頻率，在實時遊戲中關閉「重型」動畫）。

9）自動滑冰和「正確」觸發器

HPA/VPA：目標不僅通過CPU/Memory，而且通過業務指標（RPS，queue lag，p99 latency）。
Warm-up計時：考慮冷啟動和供應商限制（ASG分拆,集裝箱售票員,緩存加熱）。
Guardrails：雪崩狀錯誤生長的停止條件；防護「滑板問題」。
Capacity-playbooks：在何處以及如何添加shard/party/復制副本,如何按區域重新分配流量。

10）過程： 從設計到操作

1.限制映射：收集每個層（max conns、IOPS、TPS、quotas提供商）的「真實」瓶頸限制。
2.預測指標的選擇：早於所有人指示哪些信號「在N分鐘內打擾」。
3.閾值設計：高/低+SLO-burn+復合。
4.每個克裏特島的運行手冊：診斷步驟（「打開什麼」，「哪些命令」，「升級到哪裏」），三個操作選項：快速繞過，縮放，退化。
5.測試：載荷模擬（chaos/game days），「幹啟動」警報器，防噪聲檢查。
6.咆哮和收養：信號所有者=服務所有者。沒有主人-沒有頁面。
7.回顧和調整：每周分析虛假/遺漏的內容；度量標準「MTTA （ack）、MTTD、MTTR、Noise/Signal ratio」。

11）反模式

CPU> 90% ⇒恐慌：與latency/queues沒有關聯可以正常。
「每個人的一個閾值」：不同的區域/超時區域是不同的流量配置文件。
Alert沒有運行手冊：沒有明確操作的頁面會耗盡呼叫。
對提供商的盲目性：外部配額/限額通常是第一個「打破」腳本（PSP，KYC，antifrod，遊戲提供商）。
沒有滯後：80％/79％的邊界處的「鋸齒」。

12） iGaming/finplatform功能

日程安排：黃金時段，錦標賽決賽，主要比賽；提前升級目標復制副本並填充緩存。
現場直播和頭獎：廣播節目激增→經紀人/網站的限制。
付款和KYC：提供商窗口，反欺詐得分；保留備用路線和存款的「寬限期」。
地理平衡：提供商的本地故障-將流量帶到有頭頂的鄰近地區。

責任： 如果風險的利率/頭獎損失是即時分頁域命令+業務警報.

13）Dashbords（最低設置）

Capacity Overview：按層、前3個風險區、燃燒式SLO排序的頭部。

Stream & Queues: lag, backlog growth, consumer saturation, HPA state.

DB&Cache： connects, repl-lag, p95/p99 latency, hit ratio, evictions.

提供者：TPS/窗口/配額，timeouts/errors，呼叫成本。
Release/Feature context： 曲線旁的版本/ficheflagi。

14）實施支票

• 「真實」限制和所有者列表。
• 預測指標映射+層之間的鏈接。
• 靜態閾值+滯後。
• SLO-burn-alerta進入關鍵路徑（押金，投註，推出現場遊戲）。
• 在隊列/流/連接上預測異位。
• 窗口支持/維護；反政治噪音。
• Runbook"以及團隊，圖表，ficheflags降解。
• 每周分析誤報和調整。
• 記錄營銷活動和活動日歷。

15）示例runbook模式（縮寫）

信號： 「StreamBacklogAtRisk」

目的：防止長度>1000萬和延遲處理>5分鐘。

1.檢查「hpa_desired/max」, throttle/oom在pod中。

2.查看「rate（lag）」，按批次分配（skew）。

3.驗證經紀人（ISR, under-replicated, network）。

• 在+N上增加consumer-replicas，提升飛行中的最大值。
• 在「關鍵拓撲」中啟用優先池。
• 暫時降低輔助處理/恢復的頻率。
• 如果「ASG at max」-要求在雲端臨時加載；並行-包括重函數的降解。
• 回滾：在'lag <100萬'15分鐘後返回到「常規流量」配置文件。
• 升級：集群所有者Kafka，然後是SRE平臺。

16） KPI和信號質量

Coverage：電容過濾器封閉的關鍵路徑的百分比。
Noise/Signal：每周/每周不超過1個假分頁。
MTTD/MTTR：在SLO撞擊前≤5分鐘檢測出電容性事件。
實現性保護：在預防事件中（按事後分列）。

17）快速啟動（保守違約）

DB： 75% 連接器警告/IOPS/lat；克裏特島85%，滯後8-10 p.p.

緩存：'hit <0。9'和'evictions> 0'>5 min-警告；'used_mem> 85%'-克裏特島。
隊列：「lag」身高>3 σ，平均每30 d+'hpa at max'-克裏特島。

API: `p99 > SLO1.3'10 min-警告；'burn-rate> 4'15 min-crit.

提供者：「throughput> 90%配額」-警告；「timeouts> 5%」-克裏特島。

18) FAQ

問：為什麼不簡單地區分「CPU> 80%」？
答：沒有後綴/隊列上下文是噪音。CPU本身並不等於風險。

問：需要適應性閾值嗎？
答：是的，對於每天/每周的季節性-減少假陽性。

問：如何考慮營銷/活動？
答：活動日歷→圖表上的註釋+反噪聲的時間調整，但SLO-Alerta不觸摸。