Monitoraggio della farmacia

1) Perché monitor farmacia

Farmacia è la parte di tempo in cui il servizio è disponibile per l'utente. Questa è la prima linea di osservabilità: individuare immediatamente l'indisponibilità, il degrado della rete, il guasto DNS/TLS, problemi di instradamento o CDN. Per i sistemi altamente armati e regolabili (fintech, iGaming), la farmacia influisce direttamente sui ricavi, sull'esecuzione della SLA e sui rischi penali.

2) Termini e formule

SLI di disponibilità: 'SLI = (convalida riuscita/tutte le verifiche) x 100%'.
SLO: disponibilità target per finestra (generalmente 28-30 giorni), ad esempio 99. 9%.
SLA: impegno esterno; Ho sempre ≤ un SLO interno.
MTBF/MTTR: tempo medio tra errori/tempo medio di ripristino.

99. 0%% → 432 minuti di indisponibilità

99. 9% →} 43 min

99. 99% → ~4. 3 min

99. Il 999% della → è di 26 secondi

3) Quali controlli sono necessari (scatola nera)

Vengono avviati da punti esterni (regioni/provider) per vedere il servizio con gli occhi del client.

1. ICMP (ping) - Rete di base/disponibilità del nodo. Veloce, ma non riflette il successo aziendale.
2. Porta TCP connect? Utile per i broker/database/SMTP.
3. HTTP/HTTPS - Codice di stato, intestazioni, dimensioni, reading, tempo fino al primo byte.
4. TLS/certificati - Durata, catena, algoritmi, SNI, protocolli.
5. DNS - A/AAAA/CNAME, salute NS, distribuzione, DNSSEC.
6. gRPC - stato di chiamata, deadline, metadati.
7. WebSocket/SSE - stretta di mano, collegamento, messaggio-eco.
8. Proxy/instradamento/CDN: diverse PoP, prova hash della cache, geo-varianti.
9. Script sintetici transazionali (click/moduli): «login-ricerca-deposito (sabbia)».
10. Heartbeat/cron-monitoraggio - il servizio è obbligato a «pulsare» (un gancio ogni N minuti); nessun segnale, allarme.

• Posizionare i timeout più vicini a un UX reale (ad esempio, TTFB da 300 ms, total da 2 s).
• Controlla i contenuti assert (parola chiave/campo JSON) in modo che «200 OK» non sia considerato un successo.
• Duplicare i controlli tramite provider e reti indipendenti (multi-hop, ASN diversi).

4) La scatola bianca e la salute del servizio

Liveness/Readansaprovini per l'orchestratore (processi vivi? Pronti per il traffico?).
Salute delle dipendenze: database, cash, broker di eventi, API esterne (pagamenti/KYC/AML).
Flag Fiech/degrado - Disattivare i percorsi non critici in caso di problemi.

I campioni bianchi non sostituiscono i controlli esterni: il servizio può essere «sano all'interno», ma non disponibile per l'utente a causa del percorso DNS/TLS.

5) Geografia e multiregionalità

Avvia sintetici dalle regioni chiave del traffico e vicino ai provider di dipendenze critiche.
Quorum: si registra un incidente se le regioni N falliscono (ad esempio 2 su 3) per ritagliare le anomalie locali.
Soglia di coorte: SLI/SLO separati per segmenti importanti (paesi, VIP, operatori di comunicazione).

6) Politica di alert (minimo rumore)

Multi-regione + multi-prova: cercapersone solo in caso di fallimento concordato (ad esempio HTTP e TLS contemporaneamente, 2 regioni).
N fallimenti consecutivi o una finestra di 2-3 minuti prima del cercapersone.

• L1: on-call (servizi di produzione).
• L2: rete/piattaforma/sicurezza a seconda della firma del guasto.
• Chiusura automatica dopo i controlli di successo M stabili.
• Ore/cessioni silenziose: per i servizi interni non critici, solo ticket, senza cercapersone.

7) Stato-pagina e comunicazione

Pagina di stato pubblica (client) e pagina privata (interna).
Incidenti automatici da sintetici + annotazioni manuali.
Modelli di messaggio: rilevata - identificata - impatto - percorso di aggirazione - ETA - deciso - post-faccia.
Finestre pianificate: preannunciare, escludere le eccezioni da SLO.

8) Contabilità delle dipendenze esterne

Per ogni provider (pagamenti, KYC, mailing mail, CDN, cloud) sono disponibili controlli da più regioni.
Itinerari Failover: passaggio automatico a un provider alternativo tramite sintetico.
SLO separati a livello di provider e e2e-SLO integrale.
Negozia SLA con i provider (stato-webhoop, priorità di supporto).

9) Dashboard e widget chiave

Mappa del mondo con lo stato dei controlli (per tipo HTTP, DNS, TLS).
Timeline di incidenti con annotazioni di comunicati/bandiere.
P50/P95/P99 TTFB/TTL/latency per regione.
Disponibilità per coorte (paese/provider/dispositivo).
MTTR/MTBF, trend «minuti di inattività» e «burn-down» budget di disponibilità mensile.
Top cause di fallimento (TLS-expiry, DNS-resolving, 5xx, timeouts).

10) Processo di incidente (script veloce)

1. Funziona multi-regione/multi-tipo alert.
2. Il responsabile conferma, blocca il rilascio, avvisa i proprietari.
3. Diagnostica rapida: stato DNS/TLS/CDN, release recenti, grafico degli errori.
4. Giro: cambio di percorso, contenuto folback/provider, attivazione della modalità di degrado.
5. Recupero: verifica sintetica/traffico reale verde.
6. Comunicazione in una pagina di stato; chiusura dell'incidente.
7. RCA e action items: correzioni, test, alert, playbook.

11) Report SLA/SLO

Rapporti mensili: farmacie servizi/regioni, minuti di inattività, MTTR, motivi.
Associazione con SLA: prestiti/compensi, se applicabile.
Ringhiera trimestrale: aggiornamento delle soglie, distribuzione dei sintetici, elenco delle dipendenze.

12) Modelli di controllo (esempio)

• Metodo: «GET/healthz/public» (senza segreti).
• Timeout: 2 s, retry: 1.
• «2xx», titolo «X-App-Variante» presente, campo JSON «status», «ok».

• Tempo> 14 giorni, catena valida, protocolli "TLS 1. 2 + ', SNI corretto.

• Il tempo di risposta è di 100 ms, i record A/AAAA corrispondono al piano, nessun SERVFAIL/REFUSED.

• Webhook '/beat/{ service} 'ogni 5 minuti; assenza di 2 segnali consecutivi - alert L2 (attività di sfondo/ETL).

13) Assegno-foglio di implementazione

• Controlli esterni multi-regionali (HTTP/TCP/DNS/TLS/scenari profondi).
• Provini bianchi readava/liveness per l'orchestratore.
• Separazione dei percorsi critici/non critici, flag fich del degrado.
• Quorum e debouns in alert, escalation e chiusura auto.
• Stato pubblico e interno delle pagine, modelli di messaggio.
• Controlli separati e SLO per provider esterni + failover automatico.
• Dashboard: mappa, timeline, percense, minuti di inattività, MTTR/MTBF.
• Rapporti regolari SLA/SLO e RCA post-incidenti.

14) Errori frequenti

Solo ping/porta senza NTCR/contenuto è verde quando non è effettivamente disponibile.
Un punto di monitoraggio - conclusioni false positive/negative.
Nessun controllo TLS/DNS - interruzioni improvvise dovute a ritardo/misconfig.
Il rumore in eccesso è che gli alert vengono da una sola regione/tipo di controllo.
Nessuna relazione con le modifiche: nessuna annotazione di rilascio o flag nei dashboard.
Dipendenze non registrate - il fornitore di pagamenti è crollato e lo stato generale è verde.

15) Totale

Tracciare una farmacia non è solo «picchiare un URL». Si tratta di un sistema di controlli sintetici provenienti da regioni reali, alert intelligenti senza rumore, comunicazione trasparente attraverso le pagine statali, contabilità delle dipendenze esterne e rigorosi rapporti. Il corretto monitoraggio della farmacia riduce la MTTR, protegge la SLA e mantiene la prevedibilità dell'esperienza utente.