Λειτουργικά βιβλία αναπαραγωγής

1) Τι είναι ένα βιβλίο παιχνιδιού και πώς διαφέρει από ένα βιβλίο runbook

Το runbook είναι μια γραμμική οδηγία βήμα προς βήμα για μια τυπική λειτουργία/ειδοποίηση («κάντε ένα, δύο, τρία»).
Το Playbook είναι ένα δέντρο αποφάσεων για σενάρια με πιρούνια: διαφορετικά συμπτώματα → διαφορετικές υποθέσεις → διαφορετικούς κλάδους δράσεων. Περιλαμβάνει κριτήρια επιλογής, συνθήκες θύρας και εφεδρικούς κλάδους.
Σκοπός του playbook είναι η μείωση του MTTA/MTTR και του επιπέδου αυτοσχεδιασμού υπό αβεβαιότητα.

2) Πού χρειάζονται πρώτα τα βιβλία παιχνιδιού

Περιστατικά: πτώση SLO (διαθεσιμότητα/καθυστέρηση/επιτυχία), αποτυχία SLI επιχειρήσεων (μετατροπή/επιτυχία πληρωμών).
Αλλαγές: κυκλοφορίες, μεταναστεύσεις, σημαίες χαρακτηριστικών, ρυθμίσεις (καναρίνι/rollback).
Παράθυρα συντήρησης: αναβαθμίσεις βάσης δεδομένων/μεσίτη, περιστροφές πιστοποιητικών.
Πάροχοι: PSP/KYC/CDN/IDP - υποβάθμιση και περιστροφή.
Ασφάλεια: διακυβευόμενη βασική, ύποπτη δραστηριότητα.
DataOps: καθυστερημένη φρεσκάδα, μετατόπιση του κυκλώματος, υποβάθμιση του αγωγού.

3) Πρότυπα playbook (ελάχιστη σύνθεση)

1. Ταυτότητα, έκδοση/ημερομηνία, ιδιοκτήτης (ομάδα/ρόλος), υπηρεσίες/περιφέρειες/ενοικιαστές, συναφείς πολιτικές/πρότυπα.
2. Όροι σκοπού και εκτόξευσης: ποιες SLO/SLI προστατεύουμε, ποιες προειδοποιήσεις/σκανδάλες ισχύουν.
3. Συμπτώματα ↔ Υποθέσεις: πίνακας αντιστοιχίας, πώς να διακόψετε γρήγορα εσφαλμένες υποθέσεις.
4. Δέντρο απόφασης: πιρούνια, πύλες ασφαλείας, κριτήρια στάσης/συνέχισης.
5. Ενέργειες: κλιμακωτά μπλοκ με εντολές/συνδέσμους προς το runbook 'και.
6. Ανακοινώσεις: πρότυπο επικαιροποίησης (Impakt→Diagnostika→Deystviya→Sled. επικαιροποίηση), κανάλια και συχνότητες.
7. Rollback/folback: σαφές σχέδιο backout, όρια και σημαία υποβάθμισης UX.
8. Κριτήρια ολοκλήρωσης: μετρήσεις, χρονοθυρίδες παρατήρησης.
9. Αποδεικτικά στοιχεία: τι να αποθηκεύσετε (αρχεία καταγραφής, γραφήματα, στιγμιότυπα οθόνης, ταυτότητα εισιτηρίου).
10. Ιστορικό αλλαγών: changelog, γνωστοί περιορισμοί.

4) Ταξινόμηση βιβλίων αναπαραγωγής (παράδειγμα καταλόγου)

Περιστατικά (SLO/SLI, πάροχοι, υποδομές).
REL- κυκλοφορίες, rollbacks, ρυθμίσεις/σημαίες.
MW- παράθυρα συντήρησης (DB/σειρά αναμονής/πιστοποιητικό/OS).
SEC- ασφάλεια (πρόσβαση, κλειδιά, ύποπτες ενέργειες).
DATA- - φρεσκάδα/ποιότητα/συστήματα.
PROV- εξωτερικοί πάροχοι (PSP/KYC/CDN/Email/SMS).

5) Κύκλος ζωής και ιδιοκτησία

1. Έναρξη: με βάση περιστατικό/προσομοίωση/αλλαγή.
2. Σχέδιο: συντάκτης = ιδιοκτήτης υπηρεσίας επανεξέταση: SRE/ασφάλεια/δεδομένα (ανά τομέα).
3. Χειριστής: tabletop/ημέρα παιχνιδιού καταγραφή του χρόνου διέλευσης και των ελαττωμάτων.
4. Έκδοση: σε repo (Docs-as-Code), έκδοση, ετικέτες, σύνδεσμοι με ταμπλό.
5. Ενημέρωση: σύμφωνα με την RCA/CAPA, τουλάχιστον μία φορά το τρίμηνο. Φρεσκάδα SLA.
6. Αρχείο/εξάντληση: σε περίπτωση αντικατάστασης/απώλειας συνάφειας.

6) Ενσωμάτωση με εργαλεία

Συναγερμός → Playbook: Κάθε κανόνας σελίδας αναφέρει ακριβώς ένα βασικό βιβλίο.
ChatOps: '/play start <id> 'ανοίγει την κάρτα, διορθώνει αποδεικτικά στοιχεία, καθορίζει ενημερωμένους χρονοδιακόπτες.
CMDB/κατάλογος: η υπηρεσία έχει μια λίστα με σχετικά βιβλία παιχνιδιών, ιδιοκτήτες, SLO, ταμπλό.
GitOps: playbooks and runbooks live in Git, have PR reviews and linters.

7) Μετρήσεις ποιότητας του βιβλίου παιχνιδιών

Δυνατότητα δράσης: ≥ 90% των διαδρομών καταλήγουν σε συγκεκριμένες ενέργειες χωρίς να κλιμακώνονται εν αγνοία τους.
Χρόνος προς πρώτη δράση: ένα ή δύο λεπτά από το Page στο πρώτο ουσιαστικό βήμα.
Κάλυψη:% ειδοποιήσεις σελίδας που έχουν δεσμευμένο βιβλίο παιχνιδιών (100% στόχος).
Φρεσκάδα: το ποσοστό των βιβλίων είναι πιο φρέσκο από 90 ημέρες.
Ρυθμός ελαττώματος: σχόλια για κριτικές/προσομοιώσεις για 100 βιβλία αναπαραγωγής.
Επαναχρησιμοποίηση: πόσες φορές το βιβλίο παιχνιδιού έχει εφαρμοστεί (και ποια αποτελέσματα οδήγησε).

8) Αντι-μοτίβα

«Playbook Encyclopedia» με 20 σελίδες χωρίς δέντρο απόφασης.
Εντολές χωρίς προσδοκίες από το αποτέλεσμα («εκτέλεση X» - τι πρέπει να αλλάξει;).
Δεν υπάρχει εφεδρικό σχέδιο και όρια - ο κίνδυνος κλιμάκωσης του προβλήματος.
Δεν αναφέρονται δίαυλοι/διαστήματα επικοινωνίας - η αύξηση των κινδύνων δημοσίων σχέσεων.
Playbook χωρίς ημερομηνία ιδιοκτήτη/ενημέρωσης - κανείς δεν πιστεύει στη σημασία του.
Δεκάδες παρόμοια βιβλία αντί για ένα παραμετροποιήσιμο.

9) Playbook mini-template (ιδέα YAML)

yaml id: INC-PAY-001 name: "Payment Success Down"
version: 2. 4 (2025-10-15)
owner: team-payments@sre scope: [prod, region: eu, tenants: all]
goal: "Restore success_ratio ≥ 98% without violating SLA"
triggers:
- alert: slo. burn. payment_success_ratio
- external_status: psp-a partial outage symptoms:
- "5xx growth in payments-api"
- "p95 latency> 400ms on PSP-A"
decision_tree:
- if: "quorum(eu,us) confirms drop AND PSP-A status=partial"
then:
- action: "Reduce PSP-A weight to 30%"
runbook: rb://payments/traffic-shift guardrails: ["success_ratio improving 10m", "p95<300ms"]
- action: "Enable degrade_payments_ux"
runbook: rb://payments/feature-flags
- action: "Status update (30m) by template"
comms: statuspage://payments else:
- action: "Check database/cache/queue"
runbook: rb://payments/diag-stack fallback:
- action: "Failover на PSP-B 70%"
guardrails: ["fraud_rate stable", "chargeback risk noted"]
rollback:
- condition: "PSP-A green 60m"
- steps:
- "Weight of PSP-A 30→70→80 (every 30 m at green SLI)"
evidence:
- "SLI screenshots, p95/5xx graphs, links to logs/trails"
completion:
- "success_ratio ≥98% during 30 m, no burn in 6 h"

10) Έτοιμα παραδείγματα (θραύσματα)

Α) Πληρωμές: «Ο πάροχος υποβαθμίζεται σε μία περιφέρεια»

Συμπτώματα: μειωμένη success_ratio της ομάδας TR, αυξημένη PSP- A timeouts.
Λύσεις: μείωση του βάρους του PSP-A για TR, δυνατότητα υποβάθμισης του UX, ενίσχυση των retrays με προϋπολογισμό ≤ SLA, προετοιμασία μιας ενημέρωσης πελάτη.
Backout: Ανάκτηση βαρών σε ένα πράσινο SLI 60 λεπτών.

B) DB: «Ανάπτυξη p99 και σφάλματα σύνδεσης»

Συμπτώματα: p99↑, σφάλματα επαναφοράς σύνδεσης, συμβάντα αναμονής ανάπτυξης.
Λύσεις: ενεργοποιήστε σενάρια μόνο ανάγνωσης, περιορίστε το φορτίο εγγραφής, ομαδοποίηση κλίμακας/αντίγραφα, εάν είναι απαραίτητο - θερμή αποτυχία.
Backout: παράμετρος rollback, replica-prime.

Γ) Cache: «Miss rate ↑ → database load»

Συμπτώματα: ποσοστό αστοχίας> 40%, αύξηση της CPU DB.
Λύσεις: πολιτική εξισορρόπησης έξωσης, αύξηση μνήμης/διατμήματος, προσωρινή δυνατότητα ανάγνωσης, περιορισμός RPS σε καυτά κλειδιά.
Οπισθοδρόμηση: επιστροφή της πολιτικής, αναδημιουργία του προβληματικού κομματιού.

Δ) CDN: «Υποβάθμιση περιφερειακού περιεχομένου»

Συμπτώματα: αύξηση της καθυστέρησης/του χρόνου σε μία χώρα, καταγγελίες RUM.
Λύσεις: αλλαγή χάρτη δρομολόγησης/GSLB, παράκαμψη προβληματικών POP, μείωση TTL, δυνατότητα θωράκισης προέλευσης.
Comms: επικαιροποιήσεις της κατάστασης με γεωγραφία επιρροής.

E) KYC: «Αποτυχημένες ταυτοποιήσεις»

Συμπτώματα: μείωση του ρυθμού έγκρισης, vendor_error ανάπτυξη.
Λύσεις: μετάβαση μέρους της κυκλοφορίας σε εναλλακτικό πάροχο, μείωση της αυστηρότητας των κανόνων (στο πλαίσιο της πολιτικής), έναρξη χειροκίνητης επανεξέτασης για VIP.
Συμμόρφωση: καταγραφή όλων των μεταβολών, γνωστοποιήσεις κινδύνου/νομικές κοινοποιήσεις, εάν είναι απαραίτητο.

11) Επικοινωνίες (υπόδειγμα επικαιροποίησης)

Impact: EU payment success drop (-3. 1% to SLO, 25 min).
Diagnosis: confirmed by quorum; PSP-A partial outage; p95 = 420ms.
Action: PSP-A weight reduced to 30%, degrade-UX included; next update 18:30 UTC.

12) Λίστα ελέγχου συγγραφέα βιβλίου παιχνιδιών

• Καθορισμός στόχων, ιδιοκτητών, SLO/SLI και ενεργοποιητών.
• Υπάρχει ένας πίνακας «Συμπτώματα ↔ Υποθέσεις» και ένα δέντρο αποφάσεων.
• Εκτελέσιμα βήματα με αναμενόμενα αποτελέσματα και πύλες ασφαλείας.
• Περιγράφονται οι συνθήκες οπισθοδρόμησης/οπισθοδρόμησης και επιστροφής.
• Υπόδειγμα επικοινωνίας και συχνότητα επικαιροποίησης.
• Σύνδεσμοι με ταμπλό/καταχωρίσεις/αναζητήσεις/μονοπάτια καταγραφής.
• Απαιτούμενο τμήμα αποδεικτικών στοιχείων και κριτήρια ολοκλήρωσης.
• Έκδοση, ημερομηνία, φρεσκάδα SLA, αλλαγή ιστορίας.

13) Κατάλογος ελέγχου

• Playbook είναι playable σε tabletop/παιχνίδι-ημέρα.
• Τα βήματα είναι ασφαλή (όρια/καναρίνι/αυτόματη ανατροπή), τα μυστικά δεν αποκαλύπτονται.
• Οι ρόλοι και οι κλιμακώσεις είναι σαφείς. Ενδείκνυται IC/Comms.
• Καμία επικάλυψη με παρακείμενα βιβλία αναπαραγωγής. αφαιρούνται οι παράμετροι.
• Είναι σαφές πότε να σταματήσεις και να πας πίσω/πίσω.
• Το έγγραφο διατίθεται από την καταχώριση σε 1 κλικ.

14) Παραμετροποίηση και επαναχρησιμοποίηση

Διενέργεια μεταβλητών (περιφέρεια, πάροχος, κατώτατα όρια) σε «αξίες». '.
Γενικά στάδια (π.χ. «μείωση του βάρους του παρόχου», «δυνατότητα υποβάθμισης του UX») θα πρέπει να εκδίδονται σε ξεχωριστά εγχειρίδια.
Γεννήτριες υποστήριξης από πρότυπα: 'plb new --type = INC -- service = πληρωμές'.

15) Χάρτης πορείας για την εφαρμογή (4-6 εβδομάδες)

1. Μια απογραφή των ειδοποιήσεων Page → χάρτη σε κάθε βασικό βιβλίο παιχνιδιών.
2. Υποδείγματα: έγκριση της δομής YAML/Markdown, των καταλόγων ελέγχου και των γραμμών.
3. Top 5 σενάρια (πληρωμές/DB/CDN/KYC/cache) → εγγραφή/επιστροφή στο tabletop.
4. Ενσωμάτωση: σύνδεσμοι από ειδοποιήσεις, εντολές ChatOps, αποδεικτικά στοιχεία.
5. τρυπάνι: εβδομαδιαίο μίνι τρυπάνι ένα βιβλίο παιχνιδιού κάθε φορά. .
6. SLA φρεσκάδας και τριμηνιαίες επισκοπήσεις· έκθεση μέτρησης της ποιότητας.

16) Η τελική γραμμή

Τα playbooks είναι λειτουργικά σενάρια με πιρούνια και κιγκλιδώματα που μεταφράζουν το χάος του «τι να κάνεις;!» σε μια προβλέψιμη ακολουθία αποφάσεων. Όταν τα playbooks είναι τυποποιημένα, ενσωματωμένα με ειδοποιήσεις και τακτικά εκπαιδευμένα, η ομάδα ανταποκρίνεται γρηγορότερα, οι κίνδυνοι ελέγχονται και η επιχείρηση βλέπει τη σταθερότητα και την ωριμότητα της εκμετάλλευσης.