Υποδομές KPI και uptime

Γιατί το χρειάζεστε

Οι ΒΔΕ υποδομής μετατρέπουν τα «συναισθήματα» σχετικά με τη σταθερότητα σε μετρήσιμους στόχους, διαχειρίζονται τον κίνδυνο και εστιάζουν την εργασία. Οι σωστές μετρήσεις συνδέουν τα τεχνικά SLI με τα αποτελέσματα των επιχειρήσεων (μετατροπή, Time-to-Wallet, LTV) και σας επιτρέπουν να προγραμματίσετε την ανάπτυξη, το φορτίο και το μερίδιο της καινοτομίας έναντι της αξιοπιστίας.

Βασικές έννοιες: SLI, SLO, SLA και προϋπολογισμός σφάλματος

SLI (δείκτης επιπέδου υπηρεσίας) - μετρούμενος δείκτης ποιότητας: το ποσοστό των επιτυχών αιτήσεων, p95 καθυστέρηση, uptime ανά διάστημα.
SLO (Στόχος επιπέδου υπηρεσίας) - Στόχος SLI (για παράδειγμα, "επιτυχία ≥ 99. 9% σε 30 ημέρες).
SLA (Συμφωνία) - εξωτερική υπόσχεση με κυρώσεις/πιστώσεις. Παράγεται πάντα από, αλλά όχι από, SLO.
Σφάλμα προϋπολογισμού = '1 − SLO'. Αυτός είναι ο μέγιστος επιτρεπόμενος ρυθμός αστοχίας ανά παράθυρο μέτρησης. Χρησιμοποιείται για τη λήψη αποφάσεων σχετικά με επικίνδυνες εκλύσεις και πειράματα.

• Διαθεσιμότητα SLO 99. 95% σε 30 ημέρες → προϋπολογισμός σφάλματος 0. 05% ≈ 21. 6 λεπτά «αστοχίας» σε ημερολογιακό μήνα.

Τέσσερα σήματα χρυσού και πρόσθετα

1. Καθυστέρηση (p50/p90/p95/p99, η ουρά είναι πιο σημαντική από το μέσο όρο).
2. Σφάλματα (5xx/timeout/επιχειρηματικά σφάλματα).
3. Κυκλοφορία/διακίνηση (RPS/QPS, MBp).
4. Κορεσμός (CPU/RAM/IO/FD/συνδέσεις/GC/ποσοστώσεις).
Επιπλέον: ψυχρή εκκίνηση, ουρές αναμονής/εκκρεμότητες, χρόνος εγκατάστασης, συμμόρφωση SLO.

Μοντέλο SLI για διαφορετικούς τύπους υπηρεσιών

HTTP/API

Διαθεσιμότητα: '(επιτυχής 2xx/3xx − λογικά σφάλματα )/( όλες οι αιτήσεις)'

Καθυστέρηση: 'p95' για επιτυχή ερωτήματα. στόχος σε θερμές διαδρομές.
Ποιότητα: το ποσοστό των αιτήσεων με το «κοινό/πεδίο εφαρμογής» σωστό (χωρίς σφάλματα authz).

Ουρές αναμονής/ασύγχρονες

Χρόνος επεξεργασίας μηνυμάτων: p95 end-to-end ≤ N δευτερόλεπτα

Καθυστέρηση: διάμεση τιμή <X, ουρά p99 <Y.
Σφάλμα παράδοσης: ≤ Z ppm.

DB/Cache

Καθυστέρηση λειτουργίας: p95 get/put/commit.
Κορεσμός: χρήση της δεξαμενής σύνδεσης, λόγος απόκρυψης.
Σφάλματα: χρονοδιαγράμματα, αδιέξοδο, καταιγίδες έξωσης.

CDN/Στατικό

Λόγος επιτυχίας: ≥ επιπέδου στόχου· υποβάθμιση → αύξησης του φορτίου στην προέλευση.
Διαθεσιμότητα POP: Anycast, οι αποτυχίες αποζημιώνονται από τους γείτονες.

Πληρωμές (Business SLI)

Time-to-Wallet p95, επιτυχία καταθέσεων/εξόδου%, ποσοστό αποτυχίας PSP.

Υπολογισμός της διαθεσιμότητας και του χρόνου ανόδου

Διαθεσιμότητα υπηρεσίας = «επιτυχή αιτήματα/όλα τα αιτήματα» (κατά προτίμηση όχι «λεπτά uptime»).
Μια εναλλακτική λύση για τους κόμβους υποδομής είναι ο «χρόνος πράσινου/παραθύρου».
Ημερολογιακό παράθυρο: 28-31 ημέρες, συρόμενο παράθυρο: τελευταίες 30/90 ημέρες.
Ώρες εργασίας/κρίσιμα παράθυρα: για backoffice μπορεί να θεωρηθεί uptime σύμφωνα με το πρόγραμμα (για παράδειγμα, 08: 00-22: 00 τοπική ώρα).

• «Διαθεσιμότητα (A) ≈ Av (B) × Av (C) × Av (A 'B, C)» - είναι σημαντικό να τοποθετηθούν SLO στα όρια.

Παράδειγμα συσκευασίας SLO (δείγμα)

Pateway API: 99 ≥ διαθέσιμα. 95 %/30d; p95 καθυστέρηση ≤ 120 ms· σφάλμα ≤ 0. 2%.
Checkout/Πληρωμές: Επιτυχία καταθέσεων ≥ 98. 5 %/30d· Time-to-Wallet p95 ≤ 90 с, PSP-timeouts ≤ 0. 3%.
Βάση δεδομένων: p95 διαβάστε ≤ 10 ms. p95 γράψτε ≤ 25ms; αντίγραφο lag p95 ≤ 150 мс.
Cache: λόγος επιτυχίας ≥ 85%· καταιγίδες έξωσης = 0/30д.
Πληρωμές: p95 επεξεργασία ≤ 5 λεπτά. θετικά για την απάτη ≤ 0. 3%.

Σφάλμα στον προϋπολογισμό και διαχείριση αλλαγών

Αν ο προϋπολογισμός σφάλματος εξαντληθεί κατά 50% + πριν από τη μέση του παραθύρου, εισάγεται ένα «πάγωμα» των χαρακτηριστικών/απελευθερώσεων, το επίκεντρο είναι η σταθεροποίηση.
Αν ο προϋπολογισμός δαπανάται αργά, μπορείτε να επιταχύνετε τα πειράματα/καναρίνια.
Σύνδεση της κατανάλωσης του προϋπολογισμού με συγκεκριμένες εκλύσεις/περιστατικά μέσω 'release _ id'.

Προειδοποίηση: πώς να μην «καλέσετε τη νύχτα» μάταια

Προειδοποιήσεις μόνο για αποικοδόμηση SLO και ζωτικά συμπτώματα, όχι για κάθε μέτρηση.
Ρυθμός πολλαπλών παραθύρων: σύντομο παράθυρο (5-15 λεπτά) + μακρύ παράθυρο (1-6 ώρες).
Παράδειγμα: «Ρυθμός καύσης 14 × σε 5 λεπτά ΚΑΙ 6 × σε 1 ώρα» → σελίδα εφημερίας.
Ήσυχες ώρες για non-P1 σήματα. δρομολόγηση ιδιοκτησίας.

Ταμπλό και πρακτικές οπτικοποίησης

Πίνακας SLO: συμμόρφωση υπηρεσιών, εναπομένων προϋπολογισμός, χάρτες εξάρτησης.
Πίνακας καθυστέρησης: p50/p90/p95/p99, αποσύνθεση ανά διαδρομή/ενοικιαστές/χώρες/ASN.
Πίνακας σφάλματος: κωδικοί/λόγοι, συσχέτιση με κυκλοφορίες/σημαίες χαρακτηριστικών.
Πίνακας χωρητικότητας: CPU/RAM/IO/δίκτυο/FD/συνδέσεις, τάσεις και προβλέψεις.
Ομάδα επιχειρήσεων: μετατροπή, χρόνος σε πορτοφόλι, καταθέσεις/αναλήψεις, επιπτώσεις της προστασίας (WAF/Anti-Bots).

Περιστατικά, MTTR και νεκροψίες

• MTTD (ανίχνευση), MTTA (αποδοχή), MTTR/MTTC (ανάκτηση/περιορισμός),% περιστατικά χωρίς RCA εγκαίρως.
• Playbooks: ποιος κλιμακώνεται, πώς να ενεργοποιήσει σημαίες/μπλοκ, πώς να γυρίσει πίσω την κυκλοφορία, επικοινωνία με την επιχείρηση.
• Μεταθανάτια (άμεμπτα): γεγονότα, χρονική γραμμή, βασικές αιτίες (αυτές/διαδικασίες), ενέργειες: άμεσες/μακροπρόθεσμες, δοκιμές παλινδρόμησης, επίδραση στην SLO.

Απόδοση, κορεσμός και αποικοδόμηση

Headroom: headroom πόρων-στόχων (π.χ. CPU <70% p95, RAM <75% p95).
Θερμές διαδρομές: κρίσιμες διαδρομές διαμόρφωσης προφίλ. Το «p99» είναι σημαντικότερο από το μέσο όρο.
Τρόποι αποικοδόμησης: μόνο κρυψώνα, μόνο ανάγνωσης, αφαίρεση των ασήμαντων αιτημάτων, «όριο συντελεστή «/ποσόστωση.

Τύποι και παραδείγματα υπολογισμών

1) Διαθεσιμότητα κατά παραγγελία

availability = (total_requests - error_requests) / total_requests

όπου 'error _ request = 5xx + timeouts + επιχειρηματικά σφάλματα (διαμορφώσιμα).

2) Σφάλμα προϋπολογισμού (πρακτικά)

error_budget_minutes = window_minutes (1 - SLO)

Παράδειγμα: 30 ημέρες (43.200 λεπτά), SLO 99. 95% → 21. 6 λεπτά.

3) Ποσοστό καύσης

burn_rate = observed_error_ratio / (1 - SLO)

Εάν SLO 99. 9% (προϋπολογισμός 0. 1%) και σφάλμα 1% → burn_rate = 10 ×.

4) Σύνθετη διαθεσιμότητα

A_total ≈ A_gw × A_auth × A_db × A_psp

Μικρές πτώσεις πολλαπλασιάζονται με το συνολικό A.

Πολιτικές μέτρησης και εξαίρεσης

Μη προγραμματισμένα παράθυρα (συμβάντα) - λαμβάνονται υπόψη.
Σχεδιαζόμενα παράθυρα συντήρησης - λαμβάνονται υπόψη μόνο εάν προβλέπεται ο SLA· για SLO συχνά δεν αφαιρούνται (ή επισημαίνονται χωριστά ως «προγραμματισμένο _ downtime»).
Συνθετικά έναντι πραγματικών χρηστών: είναι χρήσιμο να υπάρχουν και τα δύο κανάλια (RUM + συνθετικοί έλεγχοι).

Παραδείγματα αντικειμένων

KQL/PromQL (ιδέες)

promql sum(rate(http_requests_total{status=~"5..    timeout"}[5m]))
/
sum(rate(http_requests_total[5m]))

promql histogram_quantile(0. 95, sum(rate(http_request_duration_seconds_bucket[5m])) by (le, route))

promql
(
sum(rate(errors_total[5m])) / sum(rate(requests_total[5m]))
) / (1 - 0. 999)

SQL (Επιχείρηση πληρωμών SLI)

sql
SELECT date_trunc('minute', finished_at) AS ts,
100. 0 sum((status='SUCCESS')::int)::float / count() AS payment_success_pct,
percentile_cont(0. 95) WITHIN GROUP (ORDER BY EXTRACT(EPOCH FROM (finished_at - started_at))) AS ttw_p95_sec
FROM payments
WHERE finished_at > now() - interval '30 days'
GROUP BY 1 ORDER BY 1;

Διαχείριση εξαρτήσεων και καταρρακτών

Συμβάσεις SLO μεταξύ ομάδων: gateway↔auth↔wallet↔PSP.
Πολιτικές υποβάθμισης: όταν μειώνεται η εξάρτηση, η υπηρεσία πηγαίνει σε «απλοποιημένο τρόπο».
Σημαίες χαρακτηριστικών: απενεργοποίηση μη κρίσιμων λειτουργιών, «απελευθέρωση γκρι» για τη μείωση των ουρών της καθυστέρησης.

Προγραμματισμός και προβλέψεις χωρητικότητας

Schomes. πρόβλεψη RPS/MBp από τάσεις και εκδηλώσεις (τουρνουά, αγώνες, προαγωγές).
Δοκιμή φορτίου με «χρυσές διαδρομές», ξεχωριστές δοκιμές για PSP/πληρωμές.
Απόθεμα στην κορυφή: συντελεστής στόχος 1. 3 × -2. 0 × του αναμενόμενου φορτίου.

Κατάλογος ελέγχου εφαρμογής SLO/KPI

1. Προσδιορίστε κρίσιμες διαδρομές χρηστών και διαπραγματευθείτε SLI «από την οπτική γωνία του πελάτη».
2. Επιλογή στόχων και παραθύρου SLO (30/90 ημέρες). υπολογίζει τον προϋπολογισμό σφάλματος.
3. Κατασκευή μετρικής συλλογής σε πύλες/υπηρεσίες, κανονικοποίηση κωδικών/λόγων.
4. Ρύθμιση ειδοποιήσεων ταχύτητας καύσης (κοντό + μακρύ παράθυρο), δρομολόγηση και εφημερία.
5. Απεικόνιση συμμόρφωσης SLO, συσχετισμός με εκδόσεις/σημαίες χαρακτηριστικών.
6. Δημιουργία ενός προϋπολογισμού κατά της πολιτικής αλλαγής και μιας διαδικασίας παγώματος.
7. Αναδρομικά και RCA σε κάθε δοκιμή περίσσειας, παλινδρόμησης.
8. Τριμηνιαία επανεξέταση των SLO για την πραγματική χρήση του προϋπολογισμού και τους επιχειρηματικούς στόχους.

Κοινά σφάλματα

Μετρήστε το «uptime by ping», αγνοώντας τα σφάλματα εφαρμογής.
Οι SLO ορίζονται «σε αποθεματικό» (99. 999%), αλλά ανέφικτο και δεν λύνει τίποτα.
Προειδοποιήσεις για χαμηλού επιπέδου μετρήσεις αντί των συμπτωμάτων του χρήστη.
Δεν υπάρχει χάρτης εξάρτησης → δεν είναι σαφές πού καίγεται.
Δεν υπάρχει σύνδεση μεταξύ SLO και αποδεσμεύσεων → δεν είναι σαφές ποιος «έφαγε» τον προϋπολογισμό.
Αγνοήστε p99 ουρές → καλό μέσο όρο αλλά κακοί χρήστες UX VIP.

iGaming/fintech special

Προγραμματισμένες κορυφές: αγώνες/εκδηλώσεις/προαγωγές - αύξηση χωρητικότητας εκ των προτέρων, προθέρμανση μνήμης/CDN, περιλαμβάνουν ειδικά οριακά προφίλ.
Business SLI: Time-to-Wallet, επιτυχία κατάθεσης/απόσυρσης, «ταχύτητα πληρωμής» p95; στη ρίζα των ταμπλό.
PSP/εταίροι: μεμονωμένα SLO/ταμπλό ανά πάροχο, αυτόματη αλλαγή διαδρομής.
Αντιτρομοκρατική/καταπολέμηση της απάτης: δεν θα πρέπει να υπάρχει προϋπολογισμός για σφάλματα - χωριστά «νόμιμα τμήματα» από «τεχνικά σφάλματα».
Κανονιστική ρύθμιση: καταγραφή αποθήκευσης, αναπαραγωγιμότητα υπολογισμών SLO/SLA, αναφορές συμβάντων.

ΣΥΧΝΈΣ ΕΡΩΤΉΣΕΙΣ

Πρέπει να αφαιρέσω το προγραμματισμένο έργο από την SLO

Συνήθως όχι: το SLO αντανακλά την εμπειρία του χρήστη. Μπορείτε να προσδιορίσετε εξαιρέσεις για τις SLA.

Γιατί p95, όχι μέσος όρος

Το μεσαίο κρύβει τις ουρές? Το UX ορίζει τις ουρές (p95/p99).

Μπορώ να έχω ένα SLO για ολόκληρο το προϊόν

Χρειάζεστε ένα δέντρο SLO: το σύνολο ανά προϊόν και ανά παιδί από κρίσιμες διαδρομές/συστατικά στοιχεία.

Σύνολο

Ένα ισχυρό σύστημα υποδομής KPI είναι προσαρμοσμένα SLI, ρεαλιστικά SLO, προϋπολογισμός σφάλματος ως μοχλός ελέγχου αλλαγών, έξυπνη πειθαρχία συναγερμού και συμβάντων, και RCAs. Σύνδεση τεχνικών δεικτών με επιχειρηματικές μετρήσεις, αυτοματοποιημένη συλλογή και απεικόνιση - και η υποδομή θα καταστεί προβλέψιμη, και ο χρόνος αιχμής θα ελέγχεται ακόμη και σε σενάρια αιχμής.