Protecție în straturi
ActivProtecție DDoS la edge, cache CDN, limitare atomică în PostgreSQL (120 de cereri / 60 de secunde per identitate tehnică pseudonimizată) și un fallback local observabil când contorul distribuit nu e disponibil.
Operare transparentă
Starea serviciului
Un instrument de transparență trebuie să fie transparent și despre propria funcționare. Publicăm aici țintele de nivel de serviciu (SLO) și postura operațională, onest despre ce este activ acum și ce rămâne o poartă pentru pilot.
Postura curentă
Mod: DemonstrativDate exclusiv fictiveMetodologie v1.0.0
În modul demonstrativ nu există trafic real de producție, deci nu publicăm încă un istoric de disponibilitate. Istoricul real de disponibilitate și incidente va fi publicat odată cu pilotul.
Verifică starea în timp real (format citibil de mașini)Ținte de nivel de serviciu (SLO)
| Indicator | Definiție | Obiectiv |
|---|---|---|
| Disponibilitate | cereri valide la /api/v1 cu status sub 500 (4xx și 429 provocate de client sunt excluse) | ≥ 99,9% |
| Latență la origine (p95) | durata execuției care ajunge la funcție (durationMs) | ≤ 1.000 ms |
| Latență la origine (p99) | aceeași distribuție, percentila 99 | ≤ 2.500 ms |
| Erori interne | răspunsuri 5xx raportate la cererile valide ajunse la origine | ≤ 0,1% |
| Limitare distribuită | cereri evaluate de contorul PostgreSQL, nu de fallback-ul local | ≥ 99,9% |
La 99,9% disponibilitate, bugetul orientativ de eroare este de aproximativ 43,8 minute într-o lună de 30 de zile. Aceste ținte sunt operaționale, nu un SLA contractual, și nu înlocuiesc acceptanța instituțională pentru pilot.
Postura operațională
Canary sintetic la fiecare 30 de minute
ActivVerifică sănătatea aplicației și a bazei de date, discovery, colecțiile JSON/CSV, revalidarea ETag/304, eroarea controlată 400 și antetele standard de limitare, cu un plafon fail-closed de 20 de cereri per rulare.
Evidență SLO pe ferestre mobile
ActivFerestre de 1h, 6h, 24h, 7 zile și 30 de zile, cu alertă de burn multi-fereastră. O probă lipsă devine „incomplete”, niciodată succes — telemetria insuficientă nu pretinde recuperarea.
Backup, PITR și restaurare Storage
Repetat automat în CICopia de siguranță, recuperarea point-in-time și restaurarea Storage sunt repetate automat la fiecare schimbare, cu rapoarte de recovery verificate în integrare continuă.
On-call uman, SLA aprobat și postmortem
Poartă pentru pilot (M5)Pagingul cu oameni, SLA-ul aprobat, rotația on-call și procesul de postmortem sunt o poartă obligatorie pentru pilot; nu sunt încă active în demonstrator.
Istoric de incidente
Niciun incident nu este consemnat în demonstrator. Odată cu pilotul, incidentele reale, comunicarea și analizele post-incident vor fi publicate aici, conform procedurilor de răspuns la incidente.