Che cos'è il tempo medio di guasto (MTTF)?
Il tempo medio di guasto (MTTF) è il tempo medio di funzionamento di un sistema o di un asset non riparabile (come una lampadina) prima di subire un guasto che lo rende non disponibile o fuori specifica.
Le aziende usano questo indicatore chiave di prestazione (KPI) di affidabilità per valutare la durata prevista di un componente tecnico o meccanico.
In DevOps, l'MTTF è spesso una misura di quanto tempo un servizio rimane disponibile per gli utenti prima di guasti e tempi di inattività gravi.
Un MTTF basso o in diminuzione avverte sviluppatori e ingegneri dell'affidabilità del sito che infrastrutture, codice o dipendenze sono fragili e richiedono dei miglioramenti per aumentarne l'affidabilità. Un MTTF alto indica che l'ambiente di produzione rimane stabile per periodi più lunghi tra crash e incidenti importanti e quindi un team IT gestisce un'architettura IT robusta e consegna applicazioni software in sicurezza.
Le metriche MTTF, insieme ad altre metriche di manutenzione, come il tempo medio tra i guasti (MTBF), aiutano i team DevOps a migliorare la capacità e la pianificazione del ciclo di vita per una serie di componenti IT (inclusi nodi di rete, container e servizi gestiti), riducendo così la probabilità di interruzioni impreviste.
Queste metriche consentono inoltre alle aziende di monitorare l'affidabilità dell'attrezzatura tra le varie versioni, così da poter stabilire se il codice, l'infrastructure as code (IaC) e le modifiche di configurazione rendono i sistemi più resilienti, invece di renderli solo più veloci nella distribuzione.
MTTF rappresenta il tempo medio di funzionamento fino al guasto per una popolazione di elementi identici. Nella sua forma più semplice, il MTTF divide il tempo operativo totale di tutti gli asset per il numero totale di guasti degli asset.
Dove "ore di funzionamento totali" è la somma della durata di ogni elemento fino al guasto (o fino all'interruzione dell'osservazione) e "numero di guasti" è il numero di elementi effettivamente guasti:
MTTF = Ore totali di funzionamento di tutti gli elementi/Numero totale di guasti
Prendiamo ad esempio un cluster di container.
I container sono istanze effimere che in genere non vengono riparate. Quando un container va in crash o presenta problemi, gli strumenti di orchestrazione dei container (come Kubernetes) semplicemente distruggono il container e ne avviano uno nuovo.
Un team IT che esegue un servizio web senza stato su 50 container applicativi identici può calcolare il valore MTTF misurando quanto a lungo ogni container funziona (dallo sviluppo al guasto) e dividendolo poi per il numero di container guasti. In questa valutazione, il team ha scoperto che il gruppo di 50 container ha funzionato per un totale di 200 ore, con cinque container che si sono guastati nel processo.
MTTF = 200 ore di tempo operativo/5 guasti = 40 ore
Il valore MTTF per i container di questo cluster è di 40 ore.
MTTF non è una formula perfetta o esatta per casi d'uso reali, per cui i team DevOps generalmente lo usano come approssimazione della durabilità dei componenti e nel contesto di altri KPI di gestione degli incidenti, come ad esempio tempo medio di riparazione (MTTR) e MTBF. MTTF in questo caso può aiutare i team a stimare il numero di riavvii che il cluster di container richiederà ogni giorno, in modo da poter assegnare il dimensionamento del cluster e le risorse di scalabilità automatica in modo appropriato.
Tuttavia, quanto più precisi sono i dati dei guasti e di funzionamento e quanti più dati i team includono, tanto più accurati saranno i calcoli dell'MTTF.
Le ultime notizie nel campo della tecnologia, supportate dalle analisi degli esperti
Resta al passo con le tendenze più importanti e interessanti del settore relative ad AI, automazione, dati e oltre con la newsletter Think. Leggi l' Informativa sulla privacy IBM.
Il monitoraggio MTTF consente ai team di quantificare l'affidabilità del sistema e prendere decisioni informate sulla gestione degli asset, incoraggiando una migliore pianificazione e promuovendo progetti e processi più resilienti. Aiuta le aziende a dare priorità a:
MTTF fornisce una visione chiara e numerica della durata di vita di un asset prima del guasto, così che i team possano valutare oggettivamente l'affidabilità invece di affidarsi ad aneddoti.
MTTF isola anche l'affidabilità intrinseca dei componenti o dei servizi da MTTR, che misura la velocità con cui i team eseguono le correzioni dei problemi di sistema quando questi si verificano. Quando il valore MTTF diminuisce per un servizio, spesso segnala problemi di progettazione o dipendenza più profondi (una libreria scadente, ad esempio). I team possono usare questi segnali per avviare la risoluzione dei problemi e individuare la causa principale dei guasti del sistema.
Monitorando le metriche di guasto nel tempo, i team possono individuare i servizi fragili e dare priorità ai miglioramenti per ridurre la frequenza degli incidenti in futuro.
Il monitoraggio MTTF può aiutare le aziende a ottimizzare le pratiche di gestione della manutenzione e ad adottare un approccio più proattivo alla risoluzione dei problemi.
Invece di attività di manutenzione basate sul tempo o ad hoc (come "riavviare il servizio X ogni domenica"), i team possono usare l'MTTF osservato per pianificare la manutenzione prima della tipica finestra di guasto ("riciclare i pod all'80% della loro tipica età di guasto").
Infatti, i responsabili IT e i team di manutenzione possono codificare i runbook, i dettagliati insiemi di istruzioni per completare le attività IT con indicazioni esplicite basate su MTTF. Ad esempio, potrebbero includere un prompt di attività come "Se il servizio X è in esecuzione più a lungo del suo tipico MTTF e mostra segnali di avviso precoce (errori, latenza), disattivalo in modo proattivo e riavvialo, invece di attendere un guasto grave."
Nella gestione degli incidenti, MTTF può rappresentare il tempo medio tra il rilevamento di un difetto e il completo guasto del sistema, indicando per quanto tempo il sistema probabilmente continuerà a funzionare in uno stato degradato o non sicuro. Conoscere questa finestra di degrado aiuta i team a decidere se hanno minuti, ore o giorni per implementare una correzione prima che il componente si spenga completamente.
Contribuisce inoltre a ridurre la gravità degli incidenti. Invece di doversi affannare durante un guasto imprevisto, il personale IT può eseguire sostituzioni o failover pianificati, testati e per i quali ha predisposto le risorse in anticipo.
Incorporare MTTF nei KPI DevOps spinge i team IT a progettare per affidabilità e degrado graduale, invece di concentrarsi solo sulla velocità di consegna. I team possono confrontare l'MTTF tra i componenti per orientare le scelte di architettura, come la sostituzione di componenti poco performanti e la riprogettazione dei servizi.
Osservare MTTF aiuta gli architetti IT a decidere dove sono necessarie le ridondanze. Ad esempio, un servizio critico con un MTTF basso avrà probabilmente bisogno di repliche, cluster di failover o interruttori automatici (che impediscono ai servizi di tentare di ripetere le operazioni non riuscite) per funzionare correttamente.
MTTF fornisce anche agli architetti una metrica guida per la combinazione dei servizi. Se un'applicazione si basa su una catena di dipendenze a basso MTTF (che avrà guasti più spesso), i team DevOps possono scegliere di disaccoppiarle o aggiungere percorsi di riserva per prevenire guasti a cascata tra i servizi.
MTTF aiuta i team DevOps a stabilire le priorità del debito tecnico trasformando vaghi reclami del tipo "sembra fragile" in rischi di affidabilità misurabili che possono essere classificati e sui quali è possibile intervenire. Possono usare i dati MTTF per creare un backlog di affidabilità ordinato da MTTF e impatto sugli incidenti, così che rifattori, riprogettazioni e aggiornamenti delle dipendenze prendano di mira le aree che danneggiano in modo dimostrabile di più la stabilità del sistema.
Inoltre, i dati MTTF consentono alle aziende di collegare il debito tecnico ai risultati aziendali, mostrando la frequenza dei guasti di un servizio e l'entità dei tempi di inattività o dei disservizi causati dagli utenti nel tempo. Questo aiuta gli ingegneri a offrire argomentazioni basate su prove per ripagare il debito. Invece di affidarsi all'intuizione, possono dire che "questo modulo non funziona ogni N giorni e causa l'X% dei nostri incidenti", il che ha maggiore affinità con i team di leadership e di prodotto.
Gli SLO sono gli obiettivi di prestazioni concordati per un particolare servizio in un periodo di tempo specifico. Aiutano a definire lo stato atteso dei servizi e a semplificare il processo decisionale relativo alle modifiche di sistema.
Gli SLO di disponibilità determinano la finestra di tempo di inattività accettabile di un servizio, nota come budget di errore. I budget di errore sono progettati per aiutare le imprese a bilanciare innovazione e stabilità. Se il budget è adeguato, i team possono tranquillamente dare priorità alla distribuzione delle caratteristiche. Se è quasi esaurito, dovrebbero spostare l'attenzione sull'affidabilità.
Un servizio a basso MTTF può rapidamente consumare un budget di errore, segnalando che lo SLO è o irrealistico per l'attuale progettazione o che i team IT devono aumentare l'affidabilità del servizio per aumentare il MTTF.
MTTF e MTBF sono entrambe metriche di affidabilità che descrivono quanto tempo le attrezzature tendono a funzionare ma si applicano a diversi tipi di asset e cicli di vita. Mentre MTTF rappresenta il tempo medio fino al primo guasto di un componente, MTBF rappresenta il tempo medio tra i cicli di guasto.
MTTF stima il tempo medio operativo di un asset non riparabile fino a un guasto permanente, dopo il quale deve essere sostituito. Si presume che un singolo evento di guasto ponga fine alla durata utile di un componente.
MTTF si applica ai componenti hardware che vengono sostituiti completamente, come i dischi di storage, le unità di elaborazione centrali (CPU) e i cavi. Si applica anche a componenti software come container e microservizi, che vengono infine sostituiti da una nuova versione o da un altro servizio invece di essere riparati sul posto.
MTBF misura il tempo medio tra i guasti consecutivi di asset riparabili, inclusi server, componenti di rete e codice software, che vengono riparati e riportati in servizio dopo i guasti. Si presuppone che un'attrezzatura si guasti, venga riparata e poi si guasti di nuovo, quindi la vita utile del sistema comprende diversi cicli "guasto → riparazione".
Insieme, le metriche MTTF e MTBF informano come i team IT affrontano la gestione degli incidenti e dei servizi IT.
In numerose architetture, i componenti non riparabili (tracciati con MTTF) sono integrati in sistemi grandi, complessi e riparabili (tracciati con MTBF), per cui MTTF può aiutare i team a prevedere quando i meccanismi interni causeranno un guasto che contribuisce all'MTBF del sistema più ampio.
Supponiamo che i dati di observability rivelino che un microservizio di elaborazione dei pagamenti all'interno di un'applicazione retail abbia un MTTF di 1.000 ore prima che una perdita di memoria critica lo faccia andare in crash irreversibile. I team DevOps possono programmare e automatizzare i riavvii dei microservizi alle 800 ore per prevenire una catena di guasti che potrebbe far crollare il MTBF dell'applicazione.
Di conseguenza, la sostituzione preventiva del microservizio non riparabile aumenta direttamente l'affidabilità dell'intera applicazione.
Entrambe le metriche sono fondamentali anche per la pianificazione della disponibilità e della manutenzione. MTTF supporta le decisioni sulla gestione dell'inventario e sullo stoccaggio dei pezzi di ricambio, mentre MTBF supporta le decisioni sui programmi di manutenzione preventiva e sulla frequenza prevista delle interruzioni.
Utilizzate insieme alle metriche dei tempi di riparazione, come MTTR, MTTF e MTBF, consentono ai pianificatori di stimare il tempo di attività del sistema, di prevedere il budget per i pezzi di ricambio e di mettere a punto i sistemi IT per ottenere un'affidabilità ottimale.
Il processo per aumentare MTTF di un asset varia ampiamente in base al sistema in questione, alle sue dipendenze, al più ampio ecosistema DevOps in cui opera e agli obiettivi aziendali più ampi. Tuttavia, tende a coinvolgere alcune pratiche chiave, tra cui:
- Monitoraggio costante. Usando strumenti di monitoraggio e observability, i team IT possono monitorare in tempo reale le deviazioni di prestazioni e affidabilità, consentendo loro di implementare contromisure che impediscono che problemi minori accelerino i guasti di sistema.
- Manutenzione preventiva. Effettuare ispezioni regolari e programmare proattivamente la manutenzione del sistema possono aiutare i team a ridurre i tassi di guasto e a prolungare la durata media dei servizi IT.
- Protocolli di test robusti. Pratiche complete e automatizzate di test consentono ai team di individuare difetti software prima dell'implementazione (e prima che influenzino gli utenti finali). La maggior parte delle pipeline e degli strumenti di integrazione continua e distribuzione continua (CI/CD) di alta qualità integrano i test durante tutto il ciclo di vita dello sviluppo del di test.
- Strategie di ridondanza. Numerose aziende si affidano a repliche bilanciate a carico , architetture IT multiregione, strumenti di orchestrazione dei container e processi di data replication per eliminare i singoli punti di guasto e aiutare i team a mitigare l'impatto dei guasti.
Risorse
Sfrutta la potenza dell'AI e dell'automazione per risolvere in modo proattivo i problemi in tutto lo stack di applicazioni.
Utilizza il software e gli strumenti DevOps per creare, implementare e gestire app cloud-native su più dispositivi e ambienti.
Accelera l'agilità e la crescita della tua azienda. Modernizza costantemente le applicazioni su tutte le tue piattaforme usufruendo dei nostri servizi di consulenza per il cloud.