Gestionarea incidentelor

(Secțiunea: Tehnologie și infrastructură)

Scurt rezumat

Gestionarea incidentelor este un proces repetabil pentru a restabili rapid valoarea utilizatorului și a minimiza daunele provocate afacerii. Suport - roluri clare (Incident Manager, Tech Lead, Comms), porți SLO, escaladări, procese ChatOps, cărți pregătite și parsare „inofensivă” post-incident cu elemente de acțiune măsurabile.

1) Obiective și principii

Viteza și siguranța: diagnostic rapid → stabilizare sigură → recuperare susținută.
Proprietar unic - Managerul de incidente atribuit (IM) ia decizii de proces.
Comunicarea ca produs: actualizări previzibile pentru părțile interesate și utilizatori.
Date> opinii: SLO/metrica/trasee/jurnale sunt sursa adevărului.
Fără vină: analiza motivelor fără acuzații personale; se concentreze pe îmbunătățirile sistemului.

2) Clasificarea incidentelor (Severitate/Impact/Urgență)

• SEV1 (critică): deteriorarea severă a veniturilor/TTW/plăților,> 20% dintre utilizatori sau regiuni întregi; SLA afectat/amenințare PII.
• SEV2 (ridicat): degradarea parțială a fluxurilor cheie (depozit/pariu/lansarea jocurilor), impact 5-20%.
• SEV3 (mediu): degradarea vizibilă a serviciilor secundare, există un by-pass.
• SEV4 (scăzut): efect minor, limitat, fără efect asupra SLO/SLA.

Impact: cine este afectat (toate/regiune/chiriaș/canal). Urgența: rata de degradare (rapid-arde/lent-arde pe bugetul de eroare).

3) Ciclul de viață incident

1. Detectare - semnal din alerte/SLO/sintetice/rapoarte.
2. Confirmați - de gardă confirmă recepția, atribuie IM.
3. Triaj - Scor SEV/Impact, colectarea ipotezei, descoperirea camerei de război.
4. Atenuare - stabilizare (rollback/comutare traseu/phicheflags/scalare).
5. Comunicați - actualizări regulate de stare (interior/exterior).
6. Recuperare - Recuperare completă SLO/business metrics.
7. Close - înregistrarea cronologiei, colecția de artefacte, PIR (elemente de acțiune RCA +).

4) Roluri și responsabilități (RACI)

Incident Manager (IM) - proprietar de proces, atribuie roluri, monitorizează timpul, ia decizii de proces (R).
Plumb tehnic (TL) - efectuează diagnostice/ipoteze/remedieri, coordonează ingineri (A/R).
Comunicații (Comms) - actualizări de stare, conexiune cu suport/business/PR, pagina de stare (R).
Scribe - protocol (cronologie, decizii luate, link-uri, artefacte) (R).
Părțile interesate - Product/Payments/Gaming Providers/Security (C/I).

Minim pe SEV1: IM + TL + Comms + Scribe. Este permisă combinarea rolurilor pe SEV2.

5) Cameră de război и ChatOps

Canale individuale: '# incident-warroom- <id>' (de lucru), '# incident-stare' (numai actualizări).
Comenzi format: '/incident start ', '/status update', '/call <owner> ', '/rollback', '/freeze ', '/scale + N'.
Bot trage în sus contextul: versiuni recente, tablouri de bord, alerte conexe, exemplare de urme, scheme de dependență.
Reguli de comunicare: pe scurt, pe fapte, un vorbitor (TL), IM moderează.

6) Declanșatoare și porți

Porți SLO: ardere rapidă/lentă, cădere de conversie a plăților, TTW p95> prag, ↑ API p99, cozi de plată sunt pe foc.
Acțiuni auto: stop canar, rollback, permițând modul degrade (limitarea funcțiilor), permițând sintetice de înaltă frecvență.
Congela: toate eliberările/picior migraţii înainte de stabilizare şi PIR.

7) Scenarii tipice (modele de runabook)

A) Plăți: creșterea timpilor/eșecurilor la PSP

1. Opriți promovarea și înghețarea lansărilor de bucle de plată.
2. Comutați traseul PSP la cel standby, ridicați timeout/retray prin politică.
3. Reconcilierea tranzacțiilor incomplete, repetarea cu chei idempotente.
4. Comunicații → suport: lucrați rezervă? ETA.

B) API p99↑ și 5xx după eliberare

1. Rollback (albastru-verde/canar → stabil).
2. Verificați hit-ul cache, adâncimea cozii, hotspot-urile furnizorului de baze de date/jocuri.
3. Scalare temporară, limitarea caracteristicilor grele prin intermediul steagurilor caracteristicilor.

C) Furnizorul de jocuri nu este disponibil

1. Comutați traficul la studiourile/jocurile disponibile, afișați un banner de stare.
2. Porniți controalele sintetice la fiecare 30-60 s.
3. Conveniți asupra compensării/bonusurilor (prin politică) - adăugați la PIR.

D) Scurgeri/suspiciuni de IIP

1. Izolarea componentelor, revocarea cheilor/tokenelor, colectarea jurnalelor (WORM).
2. Comunicare juridică/aliniere de reglementare.
3. Acțiuni post-incident: rotație secretă, mascare, acces.

8) Comunicații (interne/externe)

Frecvența de actualizare: SEV1 - la fiecare 15-30 de minute, SEV2 - 30-60 de minute.

• Ce este rupt: "Depozite prin PSP-X: Rise of Timeouts'.
• Afectat: „TR/BR, ~ 18% din utilizatorii fluxului”.
• Când a început: „12:07 EET, SEV1.”
• Ce facem: „Trecerea la ruta PSP-Y, retrayes/rate capac activat”.
• Următoarea actualizare: „în 20 de minute”.
• Contact: „IM @ duty-im, TL @ oncall-pay”.

Status public (page/social networks) - abreviat, fără PII și detalii inutile, cu ETA și un link către actualizări ulterioare.

9) Colectarea și auditarea artefactelor

Cronologie eveniment (precizie minut), versiuni de serviciu, steaguri caracteristică, modificări de configurare.
Imagini cu tablouri de bord, rute aproximative (trace_id), jurnale „înainte/în timpul/după”.
Link-uri către bilete, PR, lansări, carnete.
Raport de comunicare (când/la/ce).
Totul se adaugă la un card incident.

10) Închiderea și PIR (Revizuirea post-incident)

• Rezumat: ce sa întâmplat, scară, durată, SUV.
• Impact: utilizatori/regiuni, SLO/SLA, Fin. efect.
• Cronologie: în detaliu, pe minut.
• Cauza principală: tehnică + organizațională (de ce nedetectată mai devreme).
• Detectii si aparare: ce a ajutat/esuat (alerte, sintetice, phicheflags).
• Elemente de acțiune: sarcini specifice, proprietari, termene limită (și cum să verificați efectul).
• Lecții învățate: Ce schimbăm în proces/arhitectură/observabilitate.

Reguli: fără taxe, fapte maxime, urmărire obligatorie după 2-4 săptămâni de verificare a elementelor completate.

11) Măsurători de fiabilitate a proceselor

MTTD - Timpul mediu de detectare

MTTA (... Confirmați) - înainte de confirmarea de gardă.
MTTR (... Restaurare) - până când SLO este restaurat.
Modificarea ratei de eșec -% din versiuni care rezultă în incidente.
Rata de incidente de către SUV, distribuția pe domenii (Plăți/Jocuri/Infra).
Alert Quality: Proporția de zgomot/fals, timpul de acțiune după alertă.
Comm-SLA: respectarea frecvenței actualizărilor de stare.

12) Integrarea cu SLO și versiuni

Porți în CD: promovare canar numai cu proxy-uri verde SLO (disponibilitate, p95, suv, TTW).
Înghețați procedurile: când fast-burn/SEV1 - opriți eliberarea înainte de PIR.
Adnotări automate în grafice: versiuni/steaguri/migrații sunt vizibile pe tablouri de bord.

13) Reglementare și conformitate

PII: masking/aliasing in busteni/piste, magazine de audit WORM, control acces.
Regionalitate: Nu luați datele utilizatorilor în afara jurisdicțiilor permise.
Raportare: scrisori/notificări formalizate către autoritățile de reglementare - șabloane și proces de escaladare.

14) Învățare și pregătire (Game-Day)

Exerciții trimestriale: „PSP drop”, „furnizor de jocuri indisponibil”, „p99 val”, „scurgere de chei”.
Cronometre pe MTTA/MTTR, retro pe exercițiu.
Actualizarea cărților și contactelor, verificarea comenzilor ChatOps.

15) Lista de verificare a pregătirii (înainte de incident)

1. Regulile privind SEV și matricea de escaladare au fost de acord.
2. Rotații de gardă atribuite, IM/TL/Comms/Scribe.
3. Runabooks pentru scenarii cheie (plăți, jocuri, baze de date, cache-uri, cozi).
4. SLO card și arde alerte rata, pagina de stare.
5. ChatOps bot: comenzi, auto-context, șabloane de stare.
6. Șabloane PIR și carduri incidente.
7. Revizuirea regulată a zilei de joc și a drepturilor de contact.
8. Politica de înghețare și „butonul roșu” (rollback/kill-switch).

16) Antipattern

Nu există nici un singur IM, „mulțimea conduce” → haos și întârzieri.
Lipsa porților SLO → detectarea târzie, alerte zgomotoase.
Eliberați în timpul unui incident fără îngheț → accidente în cascadă.
Jurnalele și traseele nu sunt suficiente, nu există artefacte → PIR slab.
Cultura acuzatorie → greşeli ascunse, teama de escaladare.
Comunicaţii inspiraţionale → pierderea încrederii în întreprinderi/utilizatori.

17) Șabloane (copiați pe wiki)

A) Cardul incident (YAML)

yaml id: INC-2025-11-005 title: PSP-X timeouts in TR/BR sev: SEV1 start_at: 2025-11-05T12:07:00+02:00 status: active impact: "Deposits via PSP-X failing for ~18% users (TR, BR)"
im: "@oncall-im"
tl: "@oncall-pay"
comms: "@oncall-comms"
scribe: "@oncall-scribe"
mitigations:
- "Reroute to PSP-Y"
- "Enable retries and raise timeouts"
next_update_in: "20m"
links:
grafana: "<dashboard-url>"
traces: "<tempo-link>"
logs: "<loki-query>"
runbook: "payments/psp_timeout"

B) Actualizare de stare (internă)

[12:25] SEV1 PSP-X timeouts — TR/BR
Impact: ~18% deposits affected. SLO fast-burn active.
Mitigation: Rerouting to PSP-Y; retries enabled; release freeze.
ETA next update: 12:45 EET
IM: @oncall-im      TL: @oncall-pay

C) PIR (cap)

Summary, Impact, Timeline, Root Cause (tech+org),
Detections/Defenses, Action Items (owner+due), Lessons Learned.

Rezumat

Managementul puternic al incidentelor este structura + disciplina: roluri pre-agreate, porți SLO, cărți lucrate, comunicații transparente și PIR „inofensiv”. Această buclă reduce MTTA/MTTR, reduce costul timpilor de nefuncționare, construiește încrederea utilizatorilor și vă permite să eliberați mai îndrăzneț - dar în siguranță.