Προειδοποίηση και αντίδραση σε περίπτωση βλάβης
(Τμήμα: Τεχνολογία και Υποδομές)
Σύντομη Περίληψη
Η έντονη προειδοποίηση αποτελεί ένδειξη παραβίασης της αξίας του χρήστη και όχι απλώς «κόκκινη μέτρηση». "Για το iGaming, οι πύλες SLO (καθυστέρηση, διαθεσιμότητα, μετατροπή πληρωμών, Time-to-Wallet), οι κανόνες πολλαπλών εγκαυμάτων, οι σαφείς ρόλοι εφημερίας, κλιμάκωσης, ChatOps και runbooks είναι σημαντικοί. Ο στόχος είναι να δούμε γρήγορα την απόκλιση, να ενημερώσουμε όσους μπορούν να διορθώσουν, και να διορθώσουμε τη γνώση προκειμένου να αντιδράσουμε ακόμα πιο γρήγορα και φθηνότερα την επόμενη φορά.
1) Τα βασικά: Από τη μέτρηση στη δράση
SLI → SLO → Alert - μετρούμενη ποιότητα → επίπεδο-στόχος → όρος «ο προϋπολογισμός είναι».
Σοβαρότητα (SEV): SEV1 - κρίσιμη (έσοδα/GGR σε κίνδυνο), SEV2 - σοβαρή, SEV3 - μέτρια, SEV4 - ήσσονος σημασίας.
Αντίκτυπος/Επείγον: ποιος υποφέρει (όλοι/περιφέρεια/ενοικιαστής/δίαυλος) και πόσο επείγον (TTW↑, p99↑, σφάλμα - rate↑).
Δυνατότητα ενεργοποίησης: για κάθε συναγερμό - ειδική ενέργεια (runbook + ιδιοκτήτης).
2) Ταξινόμηση σημάτων
: p95/p99 καθυστέρηση API, ρυθμός σφάλματος, κορεσμός (CPU/IO/GPU), καθυστέρηση ουράς.
BusinessSLO: μετατροπή πληρωμών (attempt→success), Time-to-Wallet (TTW), επιτυχία στοιχημάτων, έναρξη παιχνιδιού.
Διαδρομές πληρωμής: ειδικές μετρήσεις PSP (χρονικές/φθίνουσες αιχμές).
Εμπρός/κινητό: μετρήσεις RUM (LCP/INP), ρυθμός σύγκρουσης, σενάριο συνθετικών (σύνδεση/κατάθεση/ρυθμός/έξοδος).
3) Πολιτική προειδοποίησης: SLO και ποσοστό καύσης
Παραδείγματα SLI/SLO
Διαθεσιμότητα πληρωμών-api ≥ 99. 9 %/30d p95 '/κατάθεση '≤ 250 ms/30d
Μετατροπή της γραμμής βάσης 'payments_attempt→success ≥ − 0. 3 %/24h
TTW p95 ≤ 3 λεπτά/24h
Multi-window/Multi-burn (идея PromQL)
Γρήγορη καύση: παραβίαση SLO 5-10 × ταχύτερη από την κανονική (σελίδα συναγερμού σε 5-15 λεπτά).
Αργή καύση: αργή εξάντληση του προϋπολογισμού (εισιτήριο + ανάλυση σε 1-3 ώρες).
yaml
API success proxy metric (recording rule in advance)
record: job:http:success_ratio expr:
sum(rate(http_requests_total{status=~"2.. 3.."}[5m]))
/ sum(rate(http_requests_total[5m]))
Fast burn (99. 9% SLO)
alert: PaymentsSLOFastBurn expr: (1 - job:http:success_ratio{job="payments-api"}) > (1 - 0. 999) 14 for: 10m labels: { severity: "page", service: "payments-api" }
annotations:
summary: "SLO fast burn (payments-api)"
runbook: "https://runbooks/payments/slo"
Slow burn alert: PaymentsSLOSlowBurn expr: (1 - job:http:success_ratio{job="payments-api"}) > (1 - 0. 999) 6 for: 1h labels: { severity: "ticket", service: "payments-api" }4) Μείωση θορύβου και ποιότητα σήματος
Η σωστή πηγή της αλήθειας: να αλλάζει με συγκεντρωτικά στοιχεία (κανόνες καταγραφής) και όχι με βαριές «ακατέργαστες» εκφράσεις.
Απεμπλοκή - Ομάδες Alertmanager από την «υπηρεσία/περιφέρεια/σοβαρότητα».
Ιεραρχία: πρώτη προειδοποίηση για τις επιχειρήσεις/SLI, παρακάτω - τεχνικές μετρήσεις ως διαγνωστικά.
Καταστολή: κατά τη διάρκεια προγραμματισμένης συντήρησης/απελευθέρωσης (σχολιασμός), κατά τη διάρκεια συμβάντων προηγούμενου σταδίου.
Καρδινότητα: Μη χρησιμοποιείτε το 'χρήστης _ id/session _ id' στις ετικέτες συναγερμού.
Ειδοποιήσεις δοκιμών: τακτική ενεργοποίηση «κατάρτισης» (κανάλια ελέγχου, ρόλοι, σύνδεσμοι runabook).
5) Δρομολόγηση και κλιμάκωση του συναγερμού
yaml route:
group_by: [service, region]
group_wait: 30s group_interval: 5m repeat_interval: 2h receiver: sre-slack routes:
- matchers: [ severity="page" ]
receiver: pagerduty-sre continue: true
- matchers: [ service="payments-api" ]
receiver: payments-slack
receivers:
- name: pagerduty-sre pagerduty_configs:
- routing_key: <PD_KEY>
severity: "critical"
- name: sre-slack slack_configs:
- channel: "#alerts-sre"
send_resolved: true title: "{{.CommonLabels. service }} {{.CommonLabels. severity }}"
text: "Runbook: {{.CommonAnnotations. runbook }}"
inhibit_rules:
- source_matchers: [ severity="page" ]
target_matchers: [ severity="ticket" ]
equal: [ "service" ]Ιδέα: SEV = σελίδα → PagerDuty/SMS; το υπόλοιπο είναι Slack/εισιτήριο. Η αναστολή καταστέλλει τη «διαφήμιση» των κατώτερων επιπέδων με ενεργό SEV πάνω.
6) Συναγερμός Grafana (ως πρόσθετο στρώμα)
Κεντρικοί κανόνες συναγερμού για τα ταμπλό (Prometheus/Loki/Cloud).
Σημεία επαφής: PagerDuty/Slack/Email, Πολιτικές κοινοποίησης ανά φάκελο.
Σιωπές: προγραμματισμένα έργα, μεταναστεύσεις, ελευθερώσεις.
Στιγμιότυπα με αυτόματο στιγμιότυπο οθόνης του πάνελ στο εισιτήριο.
7) Διαδικασίες εφημερίας και ζωντανές διεργασίες
Εναλλαγή: 1η γραμμή (SRE/πλατφόρμα), 2η γραμμή (ιδιοκτήτης υπηρεσίας), 3η γραμμή (DB/Πληρωμές/Sec).
SLA αντιδράσεις: αναγνώριση ≤ 5 λεπτά (SEV1), διάγνωση ≤ 15 λεπτά, επικοινωνία κάθε 15-30 λεπτά.
Κανάλια υπηρεσίας: '# incident-warroom', '# status-updates' (μόνο γεγονότα).
Runbooks: σύνδεσμος σε κάθε συναγερμό + γρήγορες εντολές ChatOps ('/rollback ', '/freeze', '/scale ').
Συναγερμοί εκπαίδευσης: μηνιαία (έλεγχος ατόμων, κανάλια, συνάφεια με το runabook).
8) Περιστατικά: Κύκλος ζωής
1. Ανίχνευση (συναγερμός/αναφορά/συνθετικά) → αναγνώριση εφημερίας.
2. Triage: προσδιορισμός SEV/επηρεαζόμενη/υπόθεση, ανοικτή αίθουσα πολέμου.
3. Σταθεροποίηση: rolls/rollback/scaling/phicheflags.
4. Ανακοινώσεις: υπόδειγμα κατάστασης (βλέπε κατωτέρω), ΠΩΑ/επόμενα στάδια.
5. Κλείσιμο: επιβεβαίωση ανάκτησης SLO.
6. Επανεξέταση μετά το περιστατικό (RCA): Μετά από 24-72 ώρες, χωρίς χρέωση, στοιχεία δράσης.
- Τι έχει σπάσει/επηρεαστεί (περιοχή/ενοικιαστής/κανάλι)
- Κατά την έναρξη/SEV
- Προσωρινά μέτρα (μετριασμός)
- Επόμενη ενημέρωση κατάστασης σε N λεπτά
- Επικοινωνία (Διαχειριστής συμβάντων)
9) Οι ιδιαιτερότητες του iGaming: ζώνες και προειδοποιήσεις «πόνου»
Πληρωμές/TTW: μερίδιο των χρονοδιαγραμμάτων PSP, αύξηση των αστοχιών κωδικών, TTW p95> 3m.
Κορυφές τουρνουά: p99 API/ώρα έναρξης παιχνιδιού/καθυστέρηση αναμονής; προώθηση ορίων/αυτόματης κλίμακας.
Συμπεράσματα των ταμείων: SLA των ελέγχων backhoe/χειροκίνητων ελέγχων, όρια ανά χώρα.
Πάροχοι παιχνιδιών: διαθεσιμότητα από στούντιο, ώρα έναρξης συνεδρίας, πτώση εκτόξευσης.
RG/Συμμόρφωση: εκρήξεις μεγάλων συνεδριών/» δόγμα», που υπερβαίνουν τα κατώτατα όρια - όχι μια σελίδα, αλλά ένα εισιτήριο + κοινοποίηση στην ομάδα RG.
10) Παραδείγματα κανόνων (προαιρετικά)
Υψηλή καθυστέρηση p95 (API)
promql alert: HighLatencyP95 expr: histogram_quantile(0. 95,
sum by (le, service) (rate(http_request_duration_seconds_bucket{service="api"}[5m]))) > 0. 25 for: 10m labels: { severity: "page", service: "api" }
annotations:
summary: "p95 latency > 250ms"
runbook: "https://runbooks/api/latency"Σειρά αναμονής μολύβδου «on»
promql alert: WithdrawalsQueueLag expr: max_over_time(queue_lag_seconds{queue="withdrawals"}[10m]) > 300 for: 10m labels: { severity: "page", service: "payments-worker" }
annotations:
summary: "Withdrawals lag >5m"
runbook: "https://runbooks/payments/queue"Εμβάπτιση μετατροπής πληρωμών
promql alert: PaymentConversionDrop expr:
(sum(rate(payments_success_total[15m])) / sum(rate(payments_attempt_total[15m])))
< (payment_conv_baseline - 0. 003)
for: 20m labels: { severity: "page", domain: "payments" }
annotations:
summary: "Payment conversion below baseline -0. 3%"
runbook: "https://runbooks/payments/conversion"11) Chatops και αυτοματοποίηση
Αυτόματη ανάρτηση ειδοποιήσεων με κουμπιά δράσης: Stop canary, Rollback, Scale + N.
Συντομογραφίες εντολών: '/έναρξη συμβάντος ', '/ενημέρωση κατάστασης', '/κλήση <ιδιοκτήτη> ', '/grafana '
Οι Bots ενισχύουν το πλαίσιο: το τελευταίο deploi, το γράφημα εξάρτησης, τα υποδειγματικά, τα σχετικά εισιτήρια.
12) Εργασίες μετά το συμβάν (RCA)
Factbox: Χρονοδιάγραμμα, τι είδε/δοκίμασε, τι λειτούργησε.
Αιτία: τεχνικοί και οργανωτικοί λόγοι.
Ανιχνεύσεις & άμυνες: Ποια σήματα βοήθησαν/απέτυχαν.
Στοιχεία δράσης: ειδικά καθήκοντα (SLO/καταχωρίσεις/κωδικοί/όρια/δοκιμές/runabook).
Προθεσμίες και ιδιοκτήτες: όροι και ευθύνες. συνεδρία παρακολούθησης σε 2- 4 εβδομάδες.
13) Κατάλογος ελέγχου εφαρμογής
1. Ορισμός SLI/SLO για τις βασικές ροές (API/Πληρωμές/Παιχνίδια/TTW).
2. Θέσπιση κανόνων καταγραφής και συναγερμών πολλαπλών εγκαυμάτων + δρομολόγηση συναγερμού.
3. Εισάγετε εφημερία με περιστροφή, αντίδραση SLO και κλιμακώσεις.
4. Σύνδεση καταχωρίσεων σε βιβλία δρομολογίων και εντολές ChatOps.
5. Ρύθμιση καταστολής/αθόρυβων παραθύρων, απελευθέρωση/καταγραφές εργασίας.
6. Κάντε συναγερμούς μάθησης και σενάρια ημέρας παιχνιδιού (πτώση PSP, αύξηση p99, αύξηση καθυστέρησης αναμονής).
7. Measure Alert Quality: MTTA/MTTR,% θορυβώδες/ψευδές, κάλυψη από την SLO.
8. Τακτικές RCA και αναθεώρηση κατώτατων ορίων/διαδικασιών.
9. Εισάγετε το καθεστώς επικοινωνίας επιχειρήσεων/υποστήριξης (υποδείγματα).
10. Καταγράψτε τα πάντα ως κωδικό: κανόνες, διαδρομές, συνδέσεις runabook.
14) Αντι-μοτίβα
Η προειδοποίηση από «κάθε μετρικό» συναγερμό-fetig, αγνοεί.
Καμία SLO → δεν είναι σαφές τι είναι «φυσιολογικό» και τι «καίγεται».
Καμία καταστολή/αναστολή → αντιγράφων χιονοστιβάδας.
Σελίδα τη νύχτα για εκδηλώσεις ήσσονος σημασίας (το SEV δεν είναι συγκρίσιμο με το Impact).
Καταχωρίσεις χωρίς εγχειρίδιο/ιδιοκτήτη.
«Χειροκίνητες» δράσεις χωρίς Chatops/έλεγχο.
RCA/Στοιχεία δράσης → επαναλαμβανόμενα συμβάντα.
Περίληψη
Η προειδοποίηση και η ανταπόκριση είναι μια διαδικασία και όχι ένα σύνολο κανόνων. Σύνδεσμος SLO με ειδοποιήσεις πολλαπλών εγκαυμάτων, δημιουργία σαφούς κλιμάκωσης εφημερίας, προσθήκη ChatOps και live runabook, τακτική διεξαγωγή RCA και εκπαιδευτικές συνεδρίες. Τότε τα περιστατικά θα είναι λιγότερο συχνά, μικρότερα και φθηνότερα, και οι κυκλοφορίες θα είναι πιο προβλέψιμες ακόμα και στις ζεστές ώρες του iGaming.