Tornar al Blog

El pla de continuïtat que ningú no ha assajat és un document, no un pla

Sala de servidors amb un equip mig tret sobre les seves guies i els dos cables d'alimentació desendollats penjant

Hi ha una paraula amagada a l'informe anual de caigudes d'Uptime Institute que canvia com cal llegir la part d'error humà. En explicar què provoca les caigudes amb error humà al darrere, l'informe d'aquest any diu que la primera causa continua sent «failures to follow established procedures». Established. Establerts. És a dir: el procediment estava escrit, aprovat i desat en algun lloc. I no es va seguir.

Això descarta la resposta còmoda. Si el problema fos que falta documentació, s'arregla escrivint documentació, i escriure documentació és una tasca que es pot assignar un dijous a la tarda. Però l'informe no diu que falten procediments: diu que els que hi ha no s'executen quan toca. I un procediment que ningú no ha executat mai no és un procediment. És una hipòtesi amb format de document. Ho avisem ja, per no colar el titular per la porta del darrere: això és la nostra lectura i no la conclusió de l'informe, que continua posant l'energia com a primera causa de les caigudes amb impacte. Al matís complet hi arribem en dos minuts.

Les xifres, i el que no diuen

L'informe és l'Annual outage analysis 2026 d'Uptime Institute, publicat el maig de 2026 i signat per Douglas Donnellan, Andy Lawrence i Rose Weinschenk. Aquestes són les tres dades que ens semblen les importants, amb la mida de mostra al costat perquè cal per llegir-les bé:

  • El 87% dels qui van patir una caiguda amb impacte els últims tres anys diu que s'hauria pogut evitar amb millor gestió, processos o configuració. Són n=98, de l'enquesta de 2025, i són set punts més que el 2024. La xifra puja.
  • El 92% diu que l'error humà va contribuir, almenys de manera menor, a la seva última caiguda amb impacte (n=220). Històricament Uptime ho situa entre dos terços i quatre cinquens de les caigudes greus.
  • La primera causa d'aquelles caigudes amb error humà és no seguir procediments establerts (n=199), i l'informe diu que continua sent-ho «com en anys anteriors».

Ara la part incòmoda, que preferim posar abans de construir-hi res a sobre. Aquelles mostres són petites: noranta-vuit, cent noranta-nou, dues-centes vint respostes d'operadors de centre de dades. Són autodeclarades i retrospectives, i una persona que mira enrere la seva pròpia caiguda té tots els incentius del món per veure-la evitable: sap com va acabar. Aquell 87% mesura quants operadors creuen que la seva caiguda era evitable, que és una cosa diferent de quantes ho eren.

I hi ha més matisos que juguen en contra del titular fàcil. Uptime diu explícitament que no compta l'error humà com a causa arrel, sinó com a factor contribuent, i explica per què: una caiguda per una actualització mal configurada pot venir d'un defecte del programari, d'un canvi incorrecte o d'unes proves que no es van fer, i separar aquelles tres coses després és gairebé impossible. La causa que continua liderant les caigudes amb impacte de debò, a la seva enquesta, és l'energia: UPS, commutadors de transferència i generadors. No els procediments.

Dit tot això, la tesi es sosté igual, i és la nostra lectura i no una dada de l'informe: si a la llista de motius d'error humà el primer és saltar-se un procediment que ja existia, aleshores el que falta no és al document. És que ningú no l'ha fet mai amb el rellotge corrent.

Per què se salta un procediment que existeix

Gairebé mai no és per deixadesa. Quan ens toca entrar a ordenar un incident aliè, el que apareix és sempre alguna variant del mateix: el procediment deia una cosa que ja no era veritat.

  • ·La credencial del pas 4 la va canviar algú al març i el document continua amb la vella.
  • ·El pas 7 diu «entra a la consola de gestió», i la consola de gestió és dins d'allò que ha caigut.
  • ·Hi ha dos passos que triguen mitja hora cadascun i el document els posa com si fossin un clic, així que el càlcul de temps amb què es va prometre el servei mai no va ser real.
  • ·Qui va escriure el document ja no hi treballa, i qui està de guàrdia a les tres de la matinada l'està llegint per primera vegada.

Cap d'aquelles quatre fallades no es detecta llegint. Es detecten executant. És el mateix que ja vam explicar quan vam escriure que la teva documentació d'infraestructura et menteix, amb la diferència que allà parlàvem d'inventari i aquí d'instruccions. Un inventari desactualitzat et fa perdre una hora. Un procediment desactualitzat te la fa perdre el dia de l'incident, que és l'únic dia en què el temps costa diners.

El cost, en l'idioma del comitè

El mateix informe posa preu a la conversa. Més de la meitat dels enquestats, el 57%, diu que la seva última caiguda important va costar més de 100.000 dòlars. I per segon any consecutiu, un de cada cinc passa del milió. Uptime ho atribueix menys al fet que hi hagi més fallades i més al fet que cada vegada més serveis depenen, directament o indirectament, d'un sol centre de dades o d'una sola zona de disponibilitat.

Hi ha una segona dada que a nosaltres ens preocupa més que els diners: la durada. La majoria de les caigudes públiques es resol en menys de dotze hores (el 55%), però la proporció de les que passen de 48 hores ha crescut per segon any consecutiu. Uptime ho relaciona en part amb els talls de fibra i de cable submarí, que el 2025 es van donar a més del doble de la seva mitjana històrica i que triguen més perquè cal anar-hi físicament a reparar-los i coordinar diverses parts. És exactament l'argument pel qual insistim que la redundància contractual no és diversitat de ruta física: dos operadors a la mateixa rasa són un sol operador el dia de l'excavadora.

I per traduir-ho a l'únic format que entén un comitè, l'aritmètica de la disponibilitat no admet discussió. Un 99% de disponibilitat són 87,6 hores l'any a fosques: més de dues setmanes laborals. Un 99,9% són 8,76 hores. Un 99,99%, 52,6 minuts. Cada nou extra no es compra amb sort; es compra amb arquitectura i amb procediment. Si encara no has posat xifres a això, la part avorrida i necessària és a RTO i RPO sense fum.

Un dimarts a les deu, no un dissabte a les tres

La conclusió operativa és incòmoda però simple: cal apagar alguna cosa a propòsit, amb gent al davant, en horari d'oficina. Els hyperscalers ho fan des de fa anys i li van posar nom —chaos engineering, el Chaos Monkey de Netflix—, però la versió d'una pime no és un bitxo automàtic que mata màquines a l'atzar. És una cita al calendari, un cop per trimestre, i una llista d'allò que es trenca.

Així ho fem nosaltres, i així ho muntem per a clients:

  1. S'avisa. Un assaig sorpresa mesura el pànic de la gent, no la qualitat del sistema, i crema la confiança que necessites per fer el següent. Data, hora i abast per escrit.
  2. Una peça, i s'apaga de debò. No «se simula que»: es desendolla el node, es para el servei, es talla l'enllaç. Si l'assaig és una reunió parlant del que passaria, el resultat és una reunió.
  3. El condueix qui NO va escriure el procediment. Aquest és el punt que més gent es salta i el que més troba. Qui el va escriure omple els buits de cap sense adonar-se'n; algú nou hi topa.
  4. Es cronometren cinc coses. Quan apareix el primer símptoma, quan salta la primera alerta, quan se n'assabenta la primera persona, quan es pren la decisió i quan el servei torna sencer. La distància entre el primer símptoma i la primera alerta és la teva telemetria; la distància entre la decisió i el retorn és el teu procediment.
  5. S'apunta el que va faltar, no el que va sortir bé. L'acta útil d'un assaig és una llista de deures amb amo i data, no un paràgraf dient que l'equip va respondre molt bé.
  6. El trimestre següent es repeteix amb la peça que va sortir pitjor. Si sempre assages el que ja et surt, estàs mesurant la teva zona de confort.

El nostre últim assaig de recuperació completa va acabar en 14 minuts. Ho diem amb l'advertiment posat: és una dada interna nostra, sobre la nostra infraestructura i el nostre procediment, i no és una garantia contractual ni és el teu número. Serveix per a una sola cosa, que és la que importa: és un número que existeix perquè algú va apagar alguna cosa i va mirar el rellotge. El teu, mentre no el mesuris, es queda en desconegut, i desconegut és la categoria perillosa: no el pots prometre, no el pots pressupostar i no saps si et cap en la jornada.

Quan NO hauries de fer un assaig

Aquí és on ens separem de la versió de fullet d'aquesta idea. Sense unes condicions prèvies, apagar alguna cosa a propòsit és jugar-se una caiguda de debò per escriure un informe bonic. Són quatre, i si te'n falta una, l'assaig no és el teu següent pas.

  • Si mai no has restaurat una còpia. Aquell és l'assaig anterior a aquest, i és més barat. Restaurar de debò, cronòmetre a la mà, no comprovar que el panell està en verd. És la primera cosa que provem quan muntem còpia gestionada. Vam escriure sobre la diferència a restaurar no és recuperar.
  • Si no tens manera de tornar enrere en un clic. Sense rollback, apagar una peça deixa de ser un experiment controlat i passa a ser una caiguda amb testimonis. Comença per la tornada enrere, com quan vam explicar per què desplegar sobre «latest» et treu la marxa enrere.
  • Si no hi ha telemetria. Sense mètriques no mesures res: només t'assabentes que alguna cosa anava mal quan algú crida. L'assaig sense telemetria produeix una anècdota, no un número.
  • Si l'única persona que coneix el sistema està de vacances, o si és tancament de mes, o campanya. Un assaig és una despesa d'atenció planificada. Es fa quan hi ha atenció de sobres, i per això el dimarts al matí guanya sempre.

I un advertiment més, perquè ens l'hem trobat: l'assaig no substitueix la governança del canvi. Que sàpigues recuperar-te d'una caiguda no redueix la probabilitat de provocar-la el proper divendres amb un canvi sense revisar. Són dues feines diferents: entorn de proves semblant al de producció, desplegament per parts i algú que revisa abans de tocar. L'estudi clàssic que va posar xifres al pes de l'error humà als grans serveis d'internet és de fa més de vint anys —Oppenheimer, Ganapathi i Patterson, USENIX 2003— i ja aleshores situava el maquinari a la cua de la llista. L'informe d'Uptime no diu el mateix amb les mateixes dades, però apunta en la mateixa direcció.

Les tres preguntes que ho revelen en cinc minuts

No cal una auditoria per saber per on vas. Aquestes tres preguntes, fetes en veu alta en una reunió de direcció, donen el diagnòstic complet per la cara que fa la gent:

  1. Què passa avui si mor una màquina qualsevol del sistema?
  2. Quan vau restaurar una còpia per última vegada? Restaurar de debò, no «tenir-la».
  3. Qui revisa el proper canvi abans que toqui producció?

Si les tres respostes comencen per «doncs hauria» o per «ho tenim documentat», ja saps a quin grup ets. Res d'això no és un retret: la majoria de les empreses amb les quals treballem van arribar a nosaltres justament allà, i arribar-hi és el normal quan el negoci creix més ràpid que la infraestructura. El que no és normal és quedar-s'hi.

La fallada és inevitable; l'avaria és una decisió

Un disc es trenca: això és una fallada, i passarà. Que per aquell disc el web deixi de vendre, el magatzem no tregui comandes i els comercials miren una pantalla congelada: això és una avaria, i això es va decidir abans, quan algú va triar on vivien les dades. Mateixa trencadissa, resultat oposat.

L'informe d'Uptime acaba, pel seu compte i sense que ningú li pregunti, al mateix lloc: diu que les proves regulars, la formació del personal i una gestió del canvi més disciplinada continuaran sent de les mesures «most effective — and cost-efficient» per reduir el risc de caiguda. És la frase més útil de tot l'informe, i no parla de comprar res. Parla d'assajar.

Nosaltres això ho muntem com a part de la feina de compliment i continuïtat: el calendari d'assajos, qui els condueix, què es cronometra i què s'arregla després. La foto prèvia —quines dependències tens de debò i quines no aguanten una prova— la traiem a consultoria, i la part de tornar a aixecar-ho, a disaster recovery. Cap de les tres coses no comença comprant ferro. Comença apagant alguna cosa un dimarts.

Fonts (verificades el 3 de setembre de 2026): el 87% amb millor gestió/processos/configuració i la seva pujada de set punts respecte al 2024 (n=98, enquesta de 2025), el 92% que assenyala l'error humà com a contribuent almenys menor (n=220, Data Center Resiliency Survey 2026), «failures to follow established procedures» com a primera causa de les caigudes amb error humà (n=199), el tractament de l'error humà com a factor contribuent i no com a causa arrel, el rang històric de dos terços a quatre cinquens, l'energia com a primera causa de les caigudes amb impacte, el 57% per damunt de 100.000 dòlars i un de cada cinc per damunt del milió, totes dues del Global Data Center Survey 2025 (al qual el mateix informe es refereix també com la seva enquesta anual de 2025), el 55% resolt en menys de dotze hores i la pujada per segon any de les caigudes de més de 48 hores, els talls de fibra i cable submarí al doble de la seva mitjana històrica el 2025 i la frase sobre proves regulars i gestió del canvi — Uptime Institute, «Annual outage analysis 2026» (UII Keynote Report 201, maig de 2026; Douglas Donnellan, Andy Lawrence i Rose Weinschenk). El pes de l'error humà en grans serveis d'internet — D. Oppenheimer, A. Ganapathi i D. Patterson, «Why Do Internet Services Fail, and What Can Be Done About It?», USENIX 2003. L'aritmètica dels nous és càlcul directe sobre 8.760 hores l'any. L'assaig de 14 minuts és una dada interna d'everyWAN sobre la nostra pròpia infraestructura: és una prova realitzada, no una garantia de servei.

Quant trigaries a tornar? Posa-hi un número

Muntem l'assaig, el conduïm nosaltres i t'entreguem els cinc temps i la llista d'allò que cal arreglar. Un dimarts al matí.

Parlar amb everyWAN

Etiquetes:

Compartir:

Subscriu-te al nostre butlletí

Per rebre històries del món IT, novetats d'everyWAN i ofertes exclusives per a subscriptors, dona't d'alta a la nostra llista de correu

everyWAN
everyWAN