Note operative Tecnica

«Disponibilità 99,99%» in capitolato: il taglio del cavo è nel calcolo, o no?

7 min di lettura

Primo piano di un orologio da parete con un fascio di luce diagonale sul quadrante, in bianco e nero
Fra il guasto e il ripristino passa un tempo che ha un nome tecnico, l’MTTR: pochi capitolati dichiarano quale hanno assunto.

«Disponibilità 99,99%» compare in offerte e capitolati come se fosse un fatto. Non lo è: è il risultato di un calcolo, e un calcolo ha ingressi che si possono — anzi si devono — dichiarare. La ITU-T G.911 (04/97), Parameters and calculation methodologies for reliability and availability of fibre optic systems, è la raccomandazione che fissa quei parametri e quel metodo: ha quasi trent’anni e, l’abbiamo verificato sulla pagina ufficiale ITU, risulta ancora in force, mentre l’edizione precedente, del marzo 1993, è superseded. Nessun testo più recente l’ha sostituita. Chi scrive «99,99%» senza dire come ci è arrivato non sta dichiarando un impegno: sta scrivendo un numero.

Un numero è un calcolo, non una promessa

La G.911 definisce l’availability performance così: «The ability of an item to be in a state to perform a required function at a given instant of time or at any instant of time within a given time interval, assuming that the external resources, if required, are provided» — la capacità di un elemento di trovarsi in uno stato che gli consenta di svolgere una funzione richiesta a un dato istante, o in ogni istante di un dato intervallo, assumendo che le risorse esterne, se necessarie, siano fornite (clausola 3.3). La condizione finale non è decorativa: una nota alla stessa definizione lo scrive senza ambiguità — «In the definition of the item, the external resources required must be delineated», le risorse esterne richieste vanno delineate (clausola 3.3, nota 2). La disponibilità non è una proprietà del cavo o dell’apparato: è una proprietà del sistema completo, manutenzione compresa — e il metodo lo mette a fuoco già al primo passo del calcolo. Fra gli ingressi che la norma elenca per lo Step 1 (clausola 6.2.1) ci sono le «repair rates based on MTTRs of the various elements and sub-systems», i tassi di riparazione basati sugli MTTR dei singoli elementi e sotto-sistemi. Tre voci da pretendere, non un numero da accettare: quale MTTR, se il cavo è nel modello, quale architettura di protezione. Una per una.

L’MTTR non è il tempo di sostituzione di una scheda

La definizione della G.911 spiazza chi immagina l’MTTR come il tempo di un intervento tecnico e basta: «mean time to repair (MTTR): The total corrective maintenance time divided by the total number of corrective maintenance actions during a given period of time» — il tempo totale di manutenzione correttiva diviso il numero totale di interventi in un dato periodo (clausola 3.18). E «tempo di manutenzione», nella stessa raccomandazione, chiude ogni scappatoia: «The time interval during which a maintenance action is performed on an item either manually or automatically, including technical delays and logistic delays» — comprende i ritardi tecnici e i ritardi logistici (clausola 3.17). Reperibilità, viaggio verso il pozzetto, permesso di scavo, eventuale lavoro notturno: per la norma stanno dentro l’MTTR, non fuori. Da non confondere con l’MTBF — «mean time between failures (MTBF): The expectation of the time between failures» (clausola 3.6) — che misura quanto spesso un elemento si guasta, non quanto tempo serve a ripararlo: sono due numeri diversi, e la disponibilità dipende da entrambi.

Quanto pesa la differenza fra un MTTR da apparato e uno da cavo lo mostra la stessa raccomandazione nel suo caso di studio sulla rete di accesso (Appendice III, Tabella III.1): il tasso di riparazione dell’OLTM, l’apparato di linea, è 1-2 per day; quello del cavo è 0.5-1 per day. Il testo definisce il tasso di riparazione come l’inverso del tempo medio di riparazione — «repair rate (inverse value of average time taken to repair a failure)» — quindi l’MTTR implicito nell’esempio è 12-24 ore per l’apparato e 24-48 ore per il cavo — la conversione in ore è nostra, la raccomandazione dà i tassi, non le ore: il doppio, e siamo ancora dentro il solo intervento tecnico, prima di contare permessi e reperibilità di un cantiere urbano vero.

Il cavo è nel modello, o è rimasto fuori

Il metodo di previsione dei guasti della G.911 (clausola 4) è un «parts count» applicato all’hardware: la norma lo dichiara senza margini — «The scope is limited to hardware-related failures under steady-state conditions», lo scopo è limitato ai guasti legati all’hardware in condizioni stazionarie (clausola 4.1). È un metodo pulito, pensato per apparati ed elettronica. Il cavo segue una logica diversa, e la G.911 lo scrive in apertura dei propri parametri di affidabilità per fibra e cavo: «Extrinsic failure modes, such as cable dig-ups or installation/maintenance errors, dominate the overall reliability» — i guasti di origine esterna, come gli scavi che tranciano il cavo o gli errori di posa, dominano l’affidabilità complessiva; i guasti intrinseci, come la fatica della fibra, ne restano una piccola frazione (clausola 2.4). Un calcolo che applica il solo parts-count agli apparati descrive con cura un guasto secondario e ignora quello che, per ammissione della stessa raccomandazione, pesa di più. Non è un dettaglio da posa urbana qualunque: la G.911 lo scrive a proposito della rete di accesso in generale, dove — «users do not have alternate path connections via another central office» — l’utente non ha percorsi alternativi verso un’altra centrale, a differenza dei collegamenti fra centrali. È per questo che la stessa appendice apre parlando della «need for line terminals and cable redundancy to reduce service interruptions in the event of cable cut or line equipment failure»: la necessità di ridondanza sui terminali di linea e sul cavo, per il taglio del cavo tanto quanto per il guasto dell’apparato.

Quale protezione, e se il percorso di riserva condivide la tratta

Il motivo per cui si progetta la ridondanza, la G.911 lo scrive in una riga: «the net availability performance obtained by cascading large numbers of network elements is incompatible with the expectations of many customers» — la disponibilità netta ottenuta mettendo in cascata molti elementi di rete non basta alle aspettative dei clienti (clausola 6.1). Ma il calcolo di una rete protetta regge solo se un’ipotesi è vera: che i guasti sui due percorsi siano eventi indipendenti. La stessa Appendice III lo scrive a proposito della ridondanza di cavo: «Cable redundancy assumes an alternate path is provided via a physically diverse route» — la ridondanza di cavo presuppone che il percorso alternativo sia fornito tramite un tracciato fisicamente diverso; e, descrivendo la protezione con cavo, aggiunge: «This alternative assumes that working and protection fibres follow physically separate paths to the same CO» — le fibre di lavoro e di protezione seguono percorsi fisicamente separati verso la stessa centrale. «Assumes»: è un’ipotesi del modello, non una descrizione automatica del cantiere. Se il percorso di riserva condivide lo stesso cavidotto, lo stesso ponte o lo stesso pozzetto del percorso primario — come abbiamo scritto a proposito dei cavi sottomarini — un solo scavo interrompe entrambi insieme, l’indipendenza cade, e il numero calcolato con quell’ipotesi non descrive più la rete che è stata davvero posata.

Applicato al capitolato

La disponibilità dichiarata entra in capitolato con i suoi tre ingressi, esattamente come si pretende il calcolo dietro un budget ottico invece di una classe dichiarata: l’MTTR assunto e la sua composizione — apparato o cavo, con o senza reperibilità e permessi —, la presenza del taglio del cavo accanto al guasto dell’apparato, il tipo di protezione e l’indipendenza fisica dichiarata dei due percorsi. In accettazione si verifica che quell’indipendenza sia reale: tracciato del percorso di riserva sul terreno, non solo sullo schema di progetto. E ogni guasto successivo — data, causa, tempo effettivo di ripristino, tratta interessata — alimenta l’MTTR misurato, che nel tempo prende il posto di quello assunto in gara, dentro la stessa mappa su cui si progetta la rete: un’AI segnala dove la disponibilità promessa non regge e quale tratta la fa cadere, e la squadra — la nostra, insieme a CSIDIA — interviene. Sempre nel perimetro del cliente: su macchine autonome on-premise, che non richiedono integrazione profonda nella rete esistente, oppure in cloud dedicato con data center in Italia; sempre con gestione condivisa.

Dovete scrivere una clausola di disponibilità in un capitolato, o verificare una che vi hanno consegnato senza i suoi ingressi? Parlatene con un tecnico: la prima sessione è senza costi, e l’MTTR assunto si scrive in una riga prima di firmare.

Fonti