SLO per strumenti interni: obiettivi di affidabilità semplici ed efficaci

Perché gli strumenti interni hanno bisogno di SLO (anche se li usano solo 20 persone)

Gli strumenti interni sembrano piccoli perché il pubblico è limitato. L'impatto spesso non lo è: se la tua dashboard operativa è giù, gli ordini si bloccano; se la console di supporto è lenta, i clienti aspettano; se il pannello admin si rompe, le correzioni si accumulano.

Senza obiettivi di affidabilità chiari, ogni interruzione diventa una discussione. Una persona sottovaluta un glitch di 10 minuti, un'altra lo considera una crisi. Si perde tempo in chat rumorose, priorità poco chiare e lavoro a sorpresa nei momenti peggiori.

Gli SLO risolvono questo impostando aspettative semplici e misurabili. Rispondono a due domande pratiche: cosa deve funzionare, e quanto bene deve funzionare perché le persone possano fare il loro lavoro.

Il costo nascosto di “lo terremo abbastanza stabile” emerge in fretta. Il lavoro si ferma mentre i team aspettano che uno strumento torni su. I ping del support aumentano perché nessuno sa cosa sia normale. Gli ingegneri vengono trascinati in riparazioni urgenti invece che in miglioramenti pianificati. I product owner smettono di fidarsi del sistema e cominciano a chiedere soluzioni manuali. I problemi minori restano perché non superano mai una soglia chiara.

Non serve un programma di affidabilità completo. Un piccolo team può partire con pochi obiettivi orientati all'utente come “login funziona” o “i risultati di ricerca arrivano velocemente”, più un set piccolo di alert legati ad azioni reali.

Questo vale indipendentemente da come lo strumento è costruito. Se usi AppMaster (appmaster.io) per creare app interne, scegli le azioni su cui le persone fanno affidamento, misura disponibilità e tempi di risposta e allerta solo quando influisce sul lavoro.

SLO, SLI e SLA in parole semplici

Questi tre termini suonano simili, ma sono linguaggi diversi per l'affidabilità. Confonderli è fonte comune di confusione.

Un SLI (Service Level Indicator) è una misurazione. È qualcosa che puoi contare, come “percentuale di richieste riuscite” o “quanto tempo ha impiegato la pagina a caricarsi”. Se non puoi misurarlo in modo affidabile, non è un buon SLI.

Un SLO (Service Level Objective) è l'obiettivo per quella misurazione. Risponde: quale livello è sufficiente per gli utenti la maggior parte del tempo? Gli SLO aiutano a decidere cosa correggere prima e cosa può aspettare.

Un SLA (Service Level Agreement) è una promessa, di solito messa per iscritto, spesso con conseguenze. Molti strumenti interni non hanno bisogno di SLA. Hanno bisogno di obiettivi chiari, non di impegni in stile legale.

Un esempio rapido:

• SLI (uptime): percentuale di minuti in cui lo strumento è raggiungibile.
• SLO (obiettivo uptime): 99,9% di uptime mensile.
• SLI (latency): p95 del tempo di caricamento della dashboard.
• SLO (obiettivo latenza): p95 sotto i 2 secondi durante l'orario lavorativo.

Nota cosa manca: “mai giù” o “sempre veloce”. Gli SLO non mirano alla perfezione. Rendono visibili i compromessi così che un piccolo team possa scegliere tra funzionalità, lavoro di affidabilità ed evitare sforzi inutili.

Una regola pratica: se raggiungere l'obiettivo richiederebbe eroismi, non è un SLO, è desiderio. Parti con qualcosa che il tuo team può mantenere con calma, poi stringilo in seguito se gli utenti sentono ancora dolore.

Scegli le poche azioni utente che contano davvero

Gli strumenti interni falliscono in modi specifici: il pannello admin si carica ma il salvataggio rimane appeso; una dashboard operativa si apre ma i grafici non si aggiornano; un portale funziona tranne che il login si rompe dopo un aggiornamento. Ottieni il massimo concentrandoti sulle azioni che le persone usano tutti i giorni, non su ogni pagina o pulsante.

Inizia nominando il tipo di strumento, perché suggerisce i percorsi critici. I pannelli admin riguardano “cambiare qualcosa in sicurezza”. Le dashboard operativesono su “vedere cosa succede ora”. I portali servono per “entrare, trovare informazioni e inviare una richiesta”.

Poi scrivi i principali user journey in linguaggio semplice. Un buon insieme iniziale:

• Login e accesso alla home
• Ricerca o filtro e risultati restituiti
• Invio di un form (crea/aggiorna) con messaggio di successo
• Caricamento della vista principale della dashboard con dati freschi
• Esportare o scaricare il report usato quotidianamente

Per ogni journey, definisci cosa conta come fallimento. Sii rigoroso e misurabile: un errore 500 è un fallimento, così come un timeout, una pagina che non termina il caricamento o un form che ritorna successo ma i dati sono assenti.

Mantieni lo scope piccolo all'inizio. Scegli 1–3 journey che corrispondono a un dolore reale e a un rischio reale. Se le pagine in on-call sono generalmente “nessuno può loggarsi” e “il pulsante salva si blocca”, inizia con Login e Invio form. Aggiungi la Ricerca più tardi quando ti fidi delle misurazioni e degli alert.

Scegli SLI che puoi davvero misurare

I buoni SLI sono noiosi. Vengono dai dati che hai già e corrispondono a ciò che gli utenti percepiscono quando lo strumento funziona o fallisce. Se ti serve un intero nuovo sistema di monitoraggio solo per misurarli, scegli SLI più semplici.

Inizia con la disponibilità in termini che le persone capiscono: posso aprire lo strumento e finire il compito? Per molti strumenti interni, due SLI coprono la maggior parte del dolore:

• Uptime dello strumento (è raggiungibile e risponde)
• Tasso di successo per 1–3 azioni chiave (login, ricerca, salvataggio, approvazione)

Poi aggiungi la latenza, ma mantienila stretta. Scegli una o due schermate o endpoint che rappresentano l'attesa degli utenti, come il caricamento della dashboard o l'invio di un form. Misurare tutto di solito crea rumore e discussioni.

Decidi la finestra di misura in anticipo. Un rolling di 30 giorni è comune per strumenti stabili; settimanale può funzionare quando rilasci spesso e vuoi feedback rapido. Qualunque scelta fai, mantienila così le tendenze abbiano senso.

Infine, scegli una sola fonte di verità per ogni SLI e scrivila:

• Controlli sintetici (un bot colpisce un health check o esegue un flusso semplice)
• Metriche server (conteggi di richieste, errori, latenza dal backend)
• Log (conteggia eventi “success” vs “failed” per un'azione specifica)

Esempio: se la tua app interna è costruita con AppMaster, puoi misurare l'uptime con un ping sintetico al backend, il tasso di successo dalle risposte API e la latenza dai tempi delle richieste backend. L'importante è la coerenza, non la perfezione.

Imposta SLO di uptime e latenza realistici

Inizia scegliendo un numero di uptime che puoi difendere in una settimana negativa. Per molti strumenti interni, 99,5% è un buon primo SLO. Suona alto, ma lascia spazio per il normale lavoro di cambiamento. Passare subito al 99,9% spesso significa pagine fuori orario e rilasci più lenti.

Per rendere l'uptime concreto, traducilo in tempo. Un mese di 30 giorni ha circa 43.200 minuti:

• 99,5% di uptime permette circa 216 minuti di downtime al mese
• 99,9% di uptime permette circa 43 minuti di downtime al mese

Quel downtime consentito è il tuo error budget. Se lo consumi presto, fermi i cambi rischiosi e ti concentri sull'affidabilità finché non torni in carreggiata.

Per la latenza, evita le medie. Nascondono i momenti lenti che gli utenti ricordano. Usa una percentile (di solito p95) e imposta una soglia chiara legata a un'azione reale. Esempi: “p95 caricamento dashboard sotto 2 secondi” o “p95 Salvataggio sotto 800 ms”.

Un modo semplice per fissare il primo numero è osservare una settimana di traffico reale e scegliere un target leggermente migliore rispetto a oggi ma non fantasioso. Se il p95 è già 1,9s, un SLO a 2,0s è sicuro e utile. Un SLO a 500 ms creerà solo rumore.

Allinea gli SLO alla capacità di supporto. Un piccolo team dovrebbe preferire pochi obiettivi raggiungibili piuttosto che molti severi. Se nessuno può rispondere entro un'ora, non impostare obiettivi che presuppongono risposta rapida.

Rendi visibili i compromessi: costo, rischio e error budget

Un SLO più stretto dà tranquillità, ma ha un costo. Se sposti uno strumento da 99,5% a 99,9% di uptime, stai anche dicendo “accettiamo molto meno tempo di malfunzionamento”, il che di solito significa più pagine e più tempo su affidabilità invece che nuova funzionalità.

Il modo più semplice per rendere tutto questo concreto è parlare in termini di error budget. Con un target del 99,5% mensile puoi “spendere” circa 3,6 ore di downtime in un mese di 30 giorni. Con il 99,9% ne hai solo circa 43 minuti. Questa differenza cambia quanto spesso fermerai il lavoro sulle funzionalità per sistemare l'affidabilità.

Aiuta anche abbinare le aspettative a quando lo strumento viene effettivamente usato. Un target 24/7 è costoso se lo strumento è critico solo dalle 9 alle 18. Puoi impostare uno SLO più severo per l'orario lavorativo e uno più lasco fuori orario così il team può dormire.

La manutenzione programmata non dovrebbe essere conteggiata come fallimento se è comunicata e limitata. Trattala come un'eccezione esplicita (una finestra di manutenzione) invece di ignorare gli alert dopo il fatto.

Scrivi le basi così tutti vedono i compromessi:

• Il numero dello SLO e cosa perde l'utente quando viene mancato
• L'error budget per il mese (in minuti o ore)
• Le regole di paging (chi, quando e per cosa)
• Orario lavorativo vs 24/7, se diverso
• Cosa conta come manutenzione programmata

Dopo 4–6 settimane di dati reali, rivedi il target. Se non consumi mai l'error budget, lo SLO potrebbe essere troppo lasco. Se lo consumi rapidamente e le funzionalità si bloccano, probabilmente è troppo severo.

Mappa gli SLO in alert che il team può sostenere

Gli alert non sono gli SLO. Gli alert sono il segnale “qualcosa non va ora” che protegge lo SLO. Una regola semplice: per ogni SLO crea un alert che conti davvero, e resisti all'aggiunta di altri a meno che non dimostrino di ridurre i tempi di inattività.

Un approccio pratico è alertare su un rapido consumo dell'error budget (quanto velocemente lo stai usando) o su una soglia chiara che corrisponde al dolore dell'utente. Se il tuo SLO di latenza è “p95 sotto 800 ms”, non fare pagine per ogni spike lento. Pagina solo quando è sostenuto.

Una divisione semplice che tiene basso il rumore:

• Pagina urgente: lo strumento è effettivamente rotto e qualcuno deve agire subito.
• Ticket non urgente: qualcosa sta degradando, ma può aspettare l'orario lavorativo.

Soglie concrete (adatta al tuo traffico): se lo SLO di uptime è 99,5% mensile, pagina quando la disponibilità scende sotto 99% per 10 minuti (outage evidente). Crea un ticket quando scende sotto 99,4% per 6 ore (burn lento). Per la latenza, pagina quando il p95 supera 1,5 s per 15 minuti; ticketa quando il p95 supera 1,0 s per 2 ore.

Rendi esplicita la proprietà. Decidi chi è on call (anche se è “una persona questa settimana”), cosa significa acknowledge (ad esempio entro 10 minuti) e quale è la prima azione. Per un piccolo team che gestisce un'app interna costruita con AppMaster, la prima azione può essere: controllare i deploy recenti, guardare gli errori API, poi rollback o redeploy se necessario.

Dopo ogni alert reale, fai un piccolo follow-up: risolvi la causa o affina l'alert così che faccia meno pagine ma continui a catturare l'impatto utente reale.

Errori comuni che creano fatica da alert

La fatica da alert di solito parte da buone intenzioni. Un piccolo team aggiunge “solo qualche” alert, poi ne aggiunge un altro ogni settimana. Presto le persone smettono di fidarsi delle notifiche e i veri outage vengono persi.

Una grande trappola è alertare su ogni spike. Gli strumenti interni spesso hanno traffico a raffiche (elaborazioni payroll, report di fine mese). Se un alert scatta per un blip di 2 minuti, il team impara a ignorarlo. Collega gli alert ai segnali di impatto utente, non al rumore delle metriche.

Un'altra trappola è pensare “più metriche = più sicuro”. Spesso significa più pagine. Attieniti a un piccolo set di segnali che gli utenti percepiscono: login fallisce, pagina troppo lenta, job chiave non completati.

Errori che generano più rumore:

• Pagare sui sintomi (CPU, memoria) invece che sull'impatto utente (errori, latenza)
• Nessun proprietario per un alert, così non viene mai tarato o rimosso
• Nessun runbook, quindi ogni alert diventa un gioco d'ipotesi
• Usare dashboard come sostituto degli alert (le dashboard servono per diagnosticare, gli alert per agire)
• Inventare soglie perché il sistema è poco strumentato

Le dashboard restano utili, ma dovrebbero aiutarti a diagnosticare dopo che un alert è scattato, non sostituire l'alert.

Se non hai misure pulite ancora, non fingere di averle. Aggiungi prima una strumentazione base (tasso di successo, p95 di latenza e un controllo “può un utente completare il task”), poi imposta soglie basate su una o due settimane di dati reali.

Controlli rapidi prima di attivare gli alert

Prima di abilitare gli alert fai un breve pre-flight. La maggior parte della fatica da alert nasce dal saltare uno di questi passaggi e poi cercare di correggerlo sotto pressione.

Una checklist pratica per un piccolo team:

• Conferma 1–3 azioni utente chiave (es.: aprire la dashboard, salvare l'aggiornamento di un ticket, esportare un report).
• Limitati a 2–4 SLI che puoi misurare oggi (disponibilità/tasso di successo, p95 di latenza, tasso di errore per l'endpoint critico).
• Limita il numero totale di alert a 2–4 per lo strumento.
• Metti d'accordo la finestra di misura, incluso cosa significa “male” (ultimi 5 minuti per rilevazione rapida, o ultimi 30–60 minuti per ridurre il rumore).
• Assegna un proprietario (una persona, non “il team”).

Poi assicurati che l'alert possa davvero essere agito. Un alert che scatta quando nessuno è disponibile addestra le persone a ignorarlo.

Decidi questi dettagli operativi prima della prima pagina:

• Orari di paging: solo orario lavorativo o vero 24/7
• Percorso di escalation: chi è il prossimo se il primo non risponde
• Cosa fare per primo: una o due azioni per confermare l'impatto e rollbackare o mitigare
• Una semplice abitudine di revisione mensile: 15 minuti per guardare gli alert scattati, gli incidenti persi e se lo SLO ancora rispecchia l'uso

Se costruisci o cambi lo strumento (incluso in AppMaster), riesegui la checklist. Codice rigenerato e nuovi flussi possono spostare latenza e pattern di errore, e i tuoi alert devono tenere il passo.

Esempio: una piccola dashboard operativa con due SLO e tre alert

Un team operativo di 18 persone usa una dashboard interna tutto il giorno per controllare lo stato degli ordini, reinviare notifiche fallite e approvare rimborsi. Se è giù o lenta, il lavoro si ferma rapidamente.

Scelgono due SLO:

• SLO di uptime: 99,9% di page load riusciti su 30 giorni (circa 43 minuti di “tempo cattivo” al mese)
• SLO di latenza: p95 del caricamento pagina sotto 1,5 secondi durante l'orario lavorativo

Ora aggiungono tre alert che un piccolo team può gestire:

• Hard down (page load falliscono): scatta se il tasso di successo scende sotto il 98% per 5 minuti. Prima azione: controllare deploy recenti, riavviare l'app web, confermare la salute del database.
• Slow dashboard: scatta se il p95 di latenza è sopra 2,5 secondi per 10 minuti. Prima azione: cercare una query lenta o un job bloccato, poi mettere in pausa temporaneamente report pesanti.
• Error budget burn: scatta se sono sulla strada per consumare il 50% dell'error budget mensile nei prossimi 7 giorni. Prima azione: fermare le modifiche non essenziali fino a stabilizzazione.

Quello che conta è cosa succede la settimana dopo. Se l'alert di error budget scatta due volte, il team prende una decisione chiara: posticipare una nuova funzionalità e passare due giorni a correggere la causa principale di latenza (per esempio una scansione di tabella senza indice). Se hanno costruito lo strumento in AppMaster, possono aggiustare il modello dati, rigenerare e redeployare codice pulito invece di accumulare soluzioni rapide.

Come mantenere gli SLO vivi senza trasformarli in un progetto

Gli SLO aiutano solo se restano collegati al lavoro reale. Il trucco è trattarli come una piccola abitudine, non come un nuovo programma.

Usa una cadenza che si adatti a un piccolo team e agganciala a una riunione esistente. Uno sguardo settimanale rapido cattura la deriva, e una regolazione mensile basta una volta che hai dati reali.

Un processo leggero che regge:

• Settimanale (10 minuti): controlla il grafico dello SLO e gli ultimi alert, poi conferma che nulla peggiora silenziosamente.
• Dopo ogni incidente (15 minuti): tagga la causa e annota quale azione utente è stata impattata (login, search, save, export).
• Mensile (30 minuti): rivedi il pattern ricorrente principale e scegli una correzione per il mese successivo.
• Mensile (10 minuti): rimuovi o affina un alert rumoroso.

Mantieni i miglioramenti piccoli e visibili. Se “pagine lente ogni lunedì mattina” appare tre volte, fai un cambiamento concreto (cachare un report, aggiungere un indice, schedulare un job pesante più tardi), poi osserva l'SLI la settimana successiva.

Usa gli SLO per dire no, in modo cortese e chiaro. Quando arriva una richiesta per una funzionalità a basso valore, punta all'error budget corrente e chiedi: “Questa modifica rischia il nostro flusso di salvataggio o approvazione?” Se stai già consumando budget, vince l'affidabilità. Non è blocco, è prioritizzazione.

Tieni la documentazione minima: una pagina per strumento. Includi le azioni utente chiave, i numeri SLO, i pochi alert correlati e il proprietario. Se lo strumento è costruito su AppMaster, aggiungi dove guardi log/metriche e chi può distribuire cambiamenti, poi basta.

Prossimi passi: parti piccolo, poi migliora uno strumento alla volta

Il modo più semplice per rendere l'affidabilità reale è mantenere la prima configurazione minuscola. Scegli uno strumento interno che crea vero dolore quando si rompe (handover on-call, approvazioni ordini, rimborsi, modifiche inventario) e imposta obiettivi attorno alle poche azioni che le persone fanno ogni giorno.

Una configurazione minima funzionante che la maggior parte dei team può copiare:

• Scegli 1 strumento e 2 azioni utente chiave (es.: aprire dashboard e inviare approvazione).
• Definisci 2 SLI che puoi misurare ora: uptime per l'endpoint/pagina e p95 di latenza per l'azione.
• Imposta 2 SLO semplici (es.: 99,5% uptime mensile, p95 sotto 800 ms in orario lavorativo).
• Crea 2–3 alert totali: uno per hard down, uno per latenza sostenuta e uno per consumo rapido dell'error budget.
• Revisiona una volta a settimana per 10 minuti: gli alert hanno aiutato o hanno solo creato rumore?

Una volta stabile, espandi lentamente: aggiungi un'azione in più o uno strumento in più al mese. Se non sai chi sarà proprietario di un alert, non crearlo ancora.

Se stai costruendo o ricostruendo strumenti interni, AppMaster può rendere più sostenibile la manutenzione. Puoi aggiornare modelli dati e logica di business visivamente e rigenerare codice pulito mentre i bisogni cambiano, il che aiuta a mantenere gli SLO allineati con ciò che lo strumento effettivamente fa oggi.

Prova a costruire uno strumento interno e aggiungere SLO di base fin dal giorno uno. Otterrai aspettative più chiare, meno sorprese e alert che il tuo piccolo team può sostenere.