Pilot Gating KPI — Fase 4 Akira
Owner: Massimo Bagnoli Riferimento: Fase 4 di
roadmap-v5.16.md(Pilot + import + go-live) Stato: bozza per congelamento in docx v5.16 Data: 2026-05-13
Questo documento definisce i KPI di gating che governano la promozione del pilot Akira da dual-stack a cutover completo, e i criteri di rollback. È il contratto tecnico/operativo che separa la Fase 4 dal go-live reale.
1. Filosofia del gating
Il pilot non è un go/no-go binario. Procede a fasi sequenziali (A→B→C→D), ciascuna con KPI propri. Una fase non avanza se i KPI della precedente non sono nel verde per la durata richiesta consecutivamente (non a spot).
Tre famiglie di KPI:
- Tecnici — qualità segnalazione, media, performance (misurati durante 7gg dual-stack).
- Fatturazione — accuratezza billing rispetto a Stealth (misurati in side-by-side 1 mese).
- Operativi — incident, DR, copertura customer reali.
2. KPI tecnici (7gg dual-stack continuativi)
| KPI | Target MVP | Misura | Tool |
|---|---|---|---|
| ASR delta Akira vs Stealth | ≤ 0.5 pp | (ASR_akira - ASR_stealth) su finestre orarie | report Live Performance + cross-check Stealth |
| ACD delta Akira vs Stealth | ≤ 2 s | diff media ACD ora-per-ora | report Live Performance |
| PDD medio | < 1500 ms | media PDD su tutte le chiamate connesse | benchmark mobile EU |
| PDD p95 | < 3000 ms | 95° percentile PDD | TimescaleDB continuous aggregate |
| CPS sostenuto | 200 CPS senza drop in 5 min benchmark window | sipp scenario cps_burst | sipp + Grafana |
| Concurrent calls peak | ≥ 1000 senza degradation (PDD/ACD stabili) | stress test settimanale | Grafana panel concurrent_active |
| Loss rate | < 0.1 % | (call_failed_5xx + call_timeout) / call_attempted | report Live Performance |
| Recording G.711 | 100 % calls recorded, file readable | spot check 50 file random/giorno | script audit record-integrity.py |
Regola di promozione: 7 giorni consecutivi con tutti gli 8 KPI nel verde. Una violazione resetta il contatore (eccezione: violazione singola con root cause documentata e fix verificato → solo il giorno fault esce dal computo).
3. KPI fatturazione (1 mese side-by-side)
Misurati su 30 giorni consecutivi di traffico passato sia in Akira sia in Stealth.
| KPI | Target | Note |
|---|---|---|
| Delta cost totale (Akira vs Stealth) | ≤ 1 % | aggregato mensile per supplier |
| Delta revenue totale (Akira vs Stealth) | ≤ 1 % | aggregato mensile per customer |
| Customer disputes attribuibili ad Akira | 0 | nessun dispute riconducibile a calcolo Akira |
Procedura di reconciliation:
- Estrazione CDR mensile da Stealth (CSV via export attuale).
- Estrazione CDR mensile da Akira (
/api/v1/reports/cdr/export). - Join su
call_id+ finestra temporale, diff sucost,revenue,duration_billed. - Categorizzazione delta:
tariff_mismatch,rounding,timezone,unknown. - Soglia: aggregato ≤ 1 %, e zero record con delta > 5 % senza categoria nota.
4. KPI operativi
| KPI | Target | Note |
|---|---|---|
| P1 incident senza runbook | 0 | ogni P1 deve avere runbook pre-esistente o, se nuovo, runbook scritto entro 48h dal RCA |
| DR test restore PG+Timescale | RTO < 4h, RPO < 1h | drill eseguito in Fase 1 (F1.6) e ripetuto in Fase 4 (F4.4) |
| Customer reali in dual-stack | ≥ 2 per ≥ 14 gg continui | requisito di copertura, non solo Apex |
| Alerting verde | nessun alert critico aperto > 1h al cutover | Prometheus + Sentry |
| Backup verificato | restore test settimanale | db-02 ephemeral |
5. Procedura pilot
Quattro fasi sequenziali. Ogni fase ha durata minima e KPI specifici.
Phase A — Dual-stack interno (14gg)
- 1 customer interno (candidato: Apex Telecom).
- Traffico replicato su entrambe le piattaforme (Stealth resta source-of-truth per fatturazione).
- Gate uscita: KPI tecnici 7/7gg verde + zero P1 nei restanti 7gg.
Phase B — Cutover #1 (14gg solo-Akira)
- Stesso customer Phase A passa su solo-Akira.
- Stealth in stand-by come fallback (rollback < 30 min).
- Gate uscita: KPI tecnici 14/14gg verde + KPI fatturazione mese verde.
Phase C — Dual-stack 2° customer (14gg)
- 2° customer reale aggiunto in dual-stack.
- Phase B continua in monitor (zero regressioni accettate).
- Gate uscita: KPI tecnici 14/14gg verde sul 2° customer + Phase B ancora verde.
Phase D — Cutover #2 (rolling)
- 2° customer passa solo-Akira.
- Stealth resta operativa per i customer non ancora migrati.
- Definizione di go-live pilot: 2 customer in Phase D per ≥ 30gg con KPI verdi.
Scope pilot
- 2 customer A.Sheep interni (Apex + 1 secondario da definire).
- NO high-volume external in pilot iniziale.
- Customer high-volume entrano post-pilot in piano migrazione separato.
6. Stop & rollback criteria
Trigger automatici/manuali per fermare l'avanzamento o tornare a Stealth.
| Trigger | Azione | Tempo decisione |
|---|---|---|
| ASR drop > 5 pp (vs baseline Stealth o storico Akira) | ROLLBACK immediato a Stealth | ≤ 15 min |
| Loss rate > 1 % sostenuto > 5 min | ROLLBACK | ≤ 15 min |
| Delta billing > 3 % in reconciliation mensile | STOP cutover, investigate, no avanzamento Phase successiva | ≤ 24h |
| 1 P1 incident (signaling down, billing wrong, data loss) | STOP cutover, RCA + remediation + runbook prima di continuare | ≤ 48h per RCA |
| DR restore fallisce RTO/RPO target | STOP cutover fino a fix infra | ≤ 1 settimana |
| Recording corrupted > 1 % file | STOP cutover + investigate FreeSWITCH | ≤ 48h |
Procedura rollback signaling
- Kamailio
staging+prod→ dispatcher weight customer X = 0. - DNS SRV record customer X → puntamento Stealth.
- Stealth riassorbe traffico in < 5 min.
- Akira resta in observe mode (traffico zero ma servizio up).
- RCA entro 48h, runbook scritto, decisione re-attempt cutover.
Procedura rollback billing
- Marcare CDR Akira come
quarantine=trueper finestra contestata. - Fatturazione finale del periodo emessa da Stealth.
- Akira rigenera CDR in shadow per il periodo, diff vs Stealth, fix codice.
- Re-attempt billing in mese successivo solo dopo nuovo side-by-side verde.
7. Reportistica gating
Dashboard Grafana dedicata pilot-gating con:
- 8 panels KPI tecnici (semaforo rosso/giallo/verde su soglia).
- Tabella reconciliation billing rolling 30 giorni.
- Timeline P1 incident con stato runbook.
- Counter giorni consecutivi in verde per fase corrente.
Report settimanale automatico (lunedì 09:00 CET) inviato a:
- Massimo (PM)
- Francesco (UX, per visibilità)
- AgentCore notifier (Telegram canale
akira-pilot).
Formato report: PDF + JSON strutturato (per archivio audit).
8. Sign-off
Il go-live pilot completo richiede sign-off scritto su:
- KPI tecnici 30gg verde post-Phase D.
- KPI fatturazione 1 mese verde post-Phase D.
- KPI operativi tutti raggiunti.
- DR drill superato in Phase D.
- Runbook completo per ogni componente (Kamailio, RTPengine, FreeSWITCH, Postgres, Timescale, Redis, NATS, AgentCore).
Firmatari: Massimo Bagnoli (PM/architetto). In assenza di altri stakeholder formali, l'audit trail è il commit di sign-off su questo file (sezione "Sign-off log" sotto, da popolare al raggiungimento).
Sign-off log
| Data | Fase | Firma | Note |
|---|---|---|---|
| pending | Phase A complete | pending | |
| pending | Phase B complete | pending | |
| pending | Phase C complete | pending | |
| pending | Phase D complete + go-live | pending |
9. Riferimenti
docs/architecture/roadmap-v5.16.md(Fase 4)docs/architecture/signaling-decisions.mddocs/conventions/definition-of-done.mddocs/security/sip-credentials-storage.md- Akira docx v5.16 cap. 47 (Roadmap) e cap. 48 (Telegram + AgentCore)