Architettura del livello operativo

1) Attività livello operativo

Lo strato operativo è una piattaforma e una serie di pratiche che garantiscono un funzionamento prevedibile: rilascio rapido, MTTR basso, compliance e costi gestiti. Crea ringhiere per prodotti e infrastrutture: standard, automazione, osservabilità, gestione delle modifiche e accesso sicuro.

2) Modello logico (piani e domini)

┌────────────────────────────────────────────────────────┐
│        Interface Plane (UX)          │← ChatOps/Portals/API
└────────────────────────────────────────────────────────┘
┌────────────────────────────────────────────────────────┐
│ Control Plane: Policy, Orchestration, Identity, CMDB │
└────────────────────────────────────────────────────────┘
┌────────────────────────────────────────────────────────┐
│ Data/Execution Plane: CI/CD, Jobs, IaC, Runtime Ops  │
└────────────────────────────────────────────────────────┘
┌────────────────────────────────────────────────────────┐
│ Telemetry Plane: Logs, Metrics, Traces, SLO Dashboards │
└────────────────────────────────────────────────────────┘
┌────────────────────────────────────────────────────────┐
│ Security & Compliance Plane: Secrets, RBAC, Audit, IR │
└────────────────────────────────────────────────────────┘
┌────────────────────────────────────────────────────────┐
│ Finance/Cost Plane: Usage, Quotas, Budgets, FinOps   │
└────────────────────────────────────────────────────────┘

• Servizi-catalogo/CMDB: un unico registro dei servizi, proprietari, SLO, dipendenze.
• Orchestrazione: pipeline, attività, corone, bacap, DR.
• Policy-as-Code: alert, accessibili, retentions, change-gates.
• Osservabilità: metriche/roulotte/logi, SLI/SLO, alert e status page.
• Disponibili/segreti: JIT/JEA, token, cripto, KMS/Vault.
• Incidenti/modifiche: ITSM/ticket, CAV/RFC, post mortem, simulazioni.
• Contratti dati, freschezza, lineage, qualità.
• FinOps: costi, limiti, quote, ottimizzazione.

3) Flussi di controllo

3. 1 Rilascio (CI/CD )

1. PR con codice/manifesto, test/scan, firma manufatti.
2. Deposito progressivo (canarino/blue-green) con guardrail SLO.
3. Rollback auto in caso di degrado; annotazioni di rilascio nella telemetria.

3. 2 Incidente (Detect → Respond → Recover)

1. Burn-rate/sintomi + quorum → Page + war-room.
2. Diagnostica su tracciati/fogli; playbook.
3. Reimpostazione/folback/limiti AAR/RCA CAPA.

3. 3 Modifica (RFC/CAV)

1. Analisi del rischio + finestra di manutenzione + backout.
2. Alert non ritrici, segnali SLO attivi.
3. Evidence e rapporto, revisione delle politiche.

4) Servizio-directory e CMDB

Attributi: proprietario, SLI/SLO, dipendenze (interne/esterne), dashboard, alert, runbook e, classi di dati (PII/finanza), zone (prod/stage/dave).
Riempimento automatico: da CI/CD, telemetria e repository.
Utilizzo: routing di alert, escalation, calcolo di blast radius, rapporti di maturità.

5) Criteri come codice (Policy-as-Code)

Categorie: disponibilità (RBAC/ABAC), sicurezza (SAST/SCA/DAST), alert/SLO, retenze, change-gates, risorse/quote.
Meccanica: regole dichiarative (YAML/Rego/CEL), convalida in CI, esecuzione obbligatoria in Control Plane.
Esempio di gate: «Il deposito è consentito se tutte le SLO sono verdi, nessun SEC-1 attivo, i test sono stati completati e le firme sono validi».

6) Orchestrazione e esecuzione

CI/CD: build → scan → sign → promote.
Jobs/CronJobs/DAG: backap/rotazione/backfill; deadline e concorrenza (Forbid/Replace).
Idempotenza e ripristini: check-then-act, marcatori di passo, circuito-breaker.
Diritti di avvio: JIT, scope limitati; Un controllo.

7) Osservabilità e qualità dei segnali

SLI/SLO per domini: disponibilità/latitanza/successo delle attività aziendali, freschezza dei dati.
Alert: burn-rate in due finestre, quorum, deadup/rate-limit, runbook e proprietario.
Logi/metriche/trailer sono collegati con trace _ id; canali da grafici a fogli.
Pagina di stato: modelli, frequenze di update, controllo di pubblicazione.

8) Accessibili, segreti, cripto

Archivi segreti (KMS/Vault), rotazioni, proibizione dei segreti nel repo.
JIT/JEA: rilascio dei permessi durante l'operazione/turno.
mTLS/OIDC tra i servizi; Firma immagine/SBOM.
Controllo: registri invariati, WORM per le attività critiche.

9) Incidenti, modifiche, finestre di manutenzione

Incidenti: matrice SEC, IC/TL/Comms/Scribe, modelli di update, AAR→RCA→CAPA.
Modifiche: RFC/CAV, valutazione dei rischi, canarini, backout.
Le finestre di servizio sono la scelta del tempo, della comunicazione, della supplenza di regole, dell'evidence.

10) DataOps nel livello operativo

Contratti dati (schemi, SLA freschezza/completezza).
Test DQ su ogni strato (Bronze/Silver/Gold).
Lineage e directory Quarantena per il matrimonio.
Dati SLO e alert di freschezza/deriva.

11) FinOps e costo

Unit Economy: $/1k richieste, $/transazione riuscita, , $/SLO-voce.
Quote/limiti: egress, volumi logici, durata delle attività.
Ottimizzazioni: partiture/cache/materiali/archivi (hot-warm-cold).
I rapporti sono servizi/richieste a basso costo, gli alert di sovraccarico.

12) Interfacce: ChatOps/Portals/API

Portale della piattaforma: catalogo dei servizi, pulsanti «deposito/rimborso», stato SLO, slot finestre, regole.
ChatOps: `/deploy`, `/handover start`, `/mw create`, `/status update` — с аудитом и evidence.
API per l'integrazione con ITSM/HR/bollo/provider.

13) Modello di responsabilità (RACI)

Platform/SRE - Piano di riferimento, criteri, osservabilità, rotazioni.
Servizi SLO, rilasci, playbook.
Sicurezza, segreti, vulnerabilità, IR.
Data/Analytics: DataOps, SLA freschezza/qualità.
Compliance/Legale - Regolazione, conservazione evidence.
Supporto/Comms - Pagina di stato, messaggi client.

14) Metriche di maturità del livello operativo

SLO coverage:% di servizi con determinati SLI/SLO e burn-rate.
Alert hygiene: actionable ≥80%, FP ≤5%, alerts/on-call-hour (p95).
DORA: frequenza di deploy, lead time, MTTR, change-failure-rate.
Cambio governance:% di modifiche RFC,% finestre on-time, ripristinazioni.
Tempo medio di rotazione dei segreti/certificati, chiusura delle vulnerabilità.
: $/unità e il% di risparmio.
Docs: rivestimento runbook/SOP, freschezza (≤90 giorni).

15) Foglio di assegno «livello operativo minimo resistente (MVP)»

• Servizio-catalogo/CMDB con proprietari, SLO, dipendenze e dashboard.
• CI/CD + GitOps, firma degli artefatti, rilascio progressivo, reimpostazione automatica.
• Telemetria combinata (fogli/metriche/roulotte) con trace _ id e alert SLO (doppie finestre, quorum).
• Policy-as-Code - Disponibilità, alert, retenze, change-gates.
• Deposito di segreti, JIT/JEA, mTLS/SSO, controllo immutabile.
• ITSM/incidenti: matrice SEC, playbook, pagina di stato, modelli di update.
• Finestre di servizio: calendario, modelli RFC, piani backout, evidence.
• FinOps: visibilità dei costi, quote/limiti, report.
• Documentazione (Docs-as-Code), modelli SOP/Runbook, assegno-foglio pronto per il provino.

16) Anti-pattern

Piattaforma = set di script senza piano di controllo o criteri.
Monitoraggio «da tutto» valanga di alert, alert fatige.
Modifiche prode manuali senza GitOps/controllo.
Segreti nelle variabili di ambiente senza archiviazione o rotazione.
La mancanza di SLO è una discussione sui sentimenti, non sugli obiettivi di qualità.
Le cartelle/tabelle separate dei proprietari mostrano le escalation perse.
Nessuna modifica del piano backout per High-risk.
I loghi, senza struttura o correlazione, hanno condotto lunghe indagini.

17) Mini modelli

17. 1 Scheda di servizio (catalogo)

Service: checkout-api
Owner: @team-checkout
SLO: availability 99. 9% (28d), p95 latency ≤ 250 ms
Dependencies: payments-api, auth, redis, psp-a
Dashboards: SLO, errors, latency, capacity
Runbooks: rb://checkout/5xx, rb://checkout/rollout
Data: PII masked; retention 30d logs, 365d audit
Change gates: canary 1/5/25%, auto-rollback on burn-rate breach

17. 2 Politica alert (idea)

yaml id: checkout-latency-burn type: burn_rate sli: http_latency_p99 windows:
short: {duration: 1h, threshold: 5%}
long: {duration: 6h, threshold: 2%}
quorum: [ "synthetic:eu,us", "rum:checkout" ]
owner: team-checkout runbook: rb://checkout/latency routing: page:oncall-checkout controls: {dedup_key: "svc=checkout,region={{region}}", rate_limit: "1/15m"}

17. 3 Gate deploy (pseudo)

yaml allow_deploy_when:
tests: passed signatures: valid active_sev: none_of [SEV-0, SEV-1]
slo_guardrails: green_last_30m rollback_plan: present

18) Road map di implementazione (8-12 settimane)

1. Ned. 1-2: inventario dei servizi → catalogo/CMDB SLI/SLO di base e dashboard.
2. Ned. 3-4: GitOps + release progressive; Policy-as-Code (alert/retenze).
3. Ned. 5-6: una sola telemetria e uno stato-pagina; burn-rate con quorum; rivestimento runbook.
4. Ned. 7-8: segreti/JIT, controllo immutabile; RFC/finestre di servizio.
5. Ned. 9-10: rendicontazione, quote/limiti; Ottimizzazione dei cavi e dello storage.
6. Ned. 11-12 - simulazioni di incidenti/DR; metriche di maturità; Un piano di miglioramento continuo.

19) Totale

L'architettura di un livello operativo è un piano di controllo più pratiche standardizzate che rendono l'operatività un processo ripetibile, misurabile e sicuro. Servizi-catalogo, GitOps, telemetria, politiche, disponibilità sicure e modifiche gestite offrono rilasci sostenibili, ripristino rapido e costi trasparenti, ovvero prevedibilità operativa per le aziende.