Aggiornamenti e finestre di manutenzione: pianificarli senza fermare il lavoro
Un aggiornamento rimandato per paura del fermo spesso diventa un problema più grosso. Ecco come scegliere orari, avvisi e piano di ritorno.
Aggiornamenti e finestre di manutenzione: cosa si decide e quando
Gli aggiornamenti e le finestre di manutenzione funzionano se si sceglie un orario in cui un fermo costa poco, si avvisa chi usa il servizio, si prepara una copia con un piano di ritorno e si verifica il risultato a lavori finiti. Il rinvio a tempo indeterminato non è una strategia.
Chi gestisce un gestionale, un sito o un database sa come finisce di solito. L'aggiornamento viene rimandato perché «adesso non è il momento», passano i mesi, e il giorno in cui diventa indispensabile (una falla, un certificato in scadenza, una versione non più supportata) si fa tutto di corsa, nel momento peggiore.
Perché la finestra di manutenzione non è un lusso
Una finestra di manutenzione è un accordo: in quella fascia il servizio può essere rallentato o interrotto, e tutti lo sanno. Niente di più. Il valore sta nel fatto che il fermo smette di essere una sorpresa.
Senza accordo succede una cosa banale. Qualcuno riavvia un server alle undici del mattino perché «tanto ci vuole un minuto», e in quel minuto una collega perde l'ordine che stava inserendo. Non è un disastro tecnico. È un disastro di fiducia, e dopo due episodi simili nessuno vuole più sentir parlare di aggiornamenti.
Come scegliere l'orario di una finestra di manutenzione
Non esiste un orario giusto in assoluto. Esiste quello in cui l'azienda perde meno, e per scoprirlo bisogna chiedere a chi lavora, non indovinare. La notte non è sempre la risposta: un'azienda che spedisce fino a sera e riceve ordini online dalle sei del mattino ha forse più respiro il sabato pomeriggio.
Qualche domanda da fare ai referenti di ogni reparto:
- In quali giorni e in quali ore il servizio è davvero indispensabile?
- Ci sono scadenze fisse (fatturazione, chiusure contabili, inventari) da evitare?
- Chi deve essere reperibile durante e dopo l'intervento, e chi può dire «va tutto bene»?
- I servizi esterni collegati (pagamenti, posta, integrazioni) hanno propri orari di fermo?
L'ultima domanda è quella che si dimentica più spesso. Un server aggiornato alla perfezione può comunque rompere la sincronizzazione con un altro sistema che nessuno aveva nominato. Per questo l'inventario dei sistemi e delle loro dipendenze viene prima di qualsiasi calendario.
Non tutti gli aggiornamenti hanno la stessa urgenza
Mettere tutto nello stesso calendario è l'errore più comune. Conviene dividere in almeno due corsie.
Nella prima ci sono le correzioni di sicurezza su ciò che è raggiungibile da internet: web server, VPN, firewall. Qui l'attesa ha un costo reale, e si interviene in tempi brevi, anche fuori dal calendario ordinario se serve. Nella seconda c'è il resto: aggiornamenti di funzionalità, cambi di versione di un database, passaggi di sistema operativo. Questi si programmano con calma, si provano prima su una copia dell'ambiente e si applicano nella finestra ordinaria. Le operazioni ordinarie su un server Linux rientrano di solito qui.
Un criterio per decidere quanta prudenza serve: chiedersi se, a cose fatte, si può tornare indietro. L'aggiornamento di un pacchetto si rimette spesso a posto con uno snapshot della macchina virtuale o con la versione precedente. Un salto di versione di PostgreSQL, di MySQL o di SQL Server può invece modificare il formato dei dati, e senza una copia il ritorno può non esistere. Il secondo tipo merita un trattamento a parte, con più tempo e una prova generale.
Cosa preparare prima di toccare qualcosa
Nel nostro modo di lavorare, accessi, documentazione e copie si preparano prima dei cambiamenti, non durante. Sembra ovvio, ma spesso si scopre che il disco non ha spazio per scaricare gli aggiornamenti proprio a metà intervento. Se vi è già successo, come capire cosa occupa il disco di un server è il punto da cui partire.
Prima dell'inizio, la lista minima è questa:
- Una copia recente e, soprattutto, una copia già provata a ripristinare (il metodo è in come verificare che i backup si possano ripristinare).
- Spazio libero sufficiente e un accesso funzionante, con un secondo canale se il primo dipende dal servizio che si sta toccando.
- L'elenco dei servizi che dipendono da quello in aggiornamento, con il nome di chi li usa.
- Un piano di ritorno scritto: cosa si ripristina, in quale ordine, e a che ora si decide di tornare indietro.
Il piano di ritorno ha bisogno di un punto di decisione, per esempio «se alle sei il gestionale non risponde, si torna indietro». Senza quel punto, un intervento che va storto si prolunga per ore perché ciascuno spera di sistemarlo ancora «in cinque minuti». Lo stesso schema, con finestra di intervento e piano di ritorno definiti prima del cambio, è quello che usiamo per le migrazioni.
Avvisare le persone giuste, nel modo giusto
Un buon avviso è breve. Dice che cosa non funzionerà, da quando a quando, cosa fare se serve lavorare comunque, e a chi scrivere in caso di dubbi. Non spiega la tecnica.
Va mandato due volte: qualche giorno prima e il giorno stesso. E va mandato a chi usa il servizio, non solo a chi lo ordina. Il magazziniere che alle sette trova ferma la stampante delle etichette non legge la mail della direzione. Un cartello vicino alla postazione, a volte, funziona meglio di qualunque comunicazione formale.
Per chi segue i sistemi insieme a un fornitore c'è un punto in più: stabilire chi decide. Se la finestra scade e l'intervento non è finito, prosegue il fornitore o il referente interno dice stop? Meglio scriverlo prima.
Dopo la finestra: verificare, non dare per scontato
«Il servizio risponde» non vuol dire «funziona». Un web server può mostrare la pagina iniziale mentre il modulo d'ordine fallisce perché la connessione al database è cambiata. Per questo, a intervento concluso, serve una prova scritta e breve, sempre uguale: accedere, aprire un documento reale, inserire un dato di prova riconoscibile e poi annullarlo, controllare che stampe e integrazioni abbiano risposto.
Poi si guarda il monitoraggio nelle ore successive: disponibilità, uso delle risorse, certificati e scadenze. Alcuni problemi emergono solo dopo, quando parte il primo lavoro notturno che prima funzionava. Infine si annota cosa è stato fatto, con data e versioni. Chi dovrà intervenire fra sei mesi, magari un'altra persona, ne avrà bisogno.
Se questa routine sembra troppo da sostenere insieme al resto del lavoro, è un segnale da prendere sul serio, non una colpa. A quel punto può avere senso affidare la gestione dell'infrastruttura IT a chi segua inventario, finestre e verifiche in modo continuativo, con perimetro e orari concordati per iscritto.
Il punto di partenza
Prendete un solo servizio, il più critico, e scrivete su una pagina: chi lo usa, in quali ore non può fermarsi, da cosa dipende e come si tornerebbe indietro. Con quella pagina in mano, proponete a chi lo usa una fascia di manutenzione e provatela una volta, con un aggiornamento piccolo. Il resto del calendario si costruisce sul primo intervento andato bene. Se volete confrontarvi sul metodo, anche su un'infrastruttura già esistente, potete scrivere a Forgiant.
Domande frequenti
Ogni quanto conviene fare una finestra di manutenzione?
Dipende dai sistemi e da quanto tollerano un fermo. Spesso una finestra ordinaria periodica basta per gli aggiornamenti programmabili, mentre le correzioni di sicurezza urgenti si applicano appena possibile. Frequenza e orari si concordano con chi usa i servizi.
Cosa serve prima di un aggiornamento importante?
Una copia recente già provata a ripristinare, spazio libero, un accesso alternativo e un piano di ritorno scritto con un punto di decisione. Serve anche sapere quali servizi dipendono da quello che si aggiorna.
Si può aggiornare un server senza fermare il lavoro?
A volte sì, se l'architettura prevede più istanze o un riavvio rapido, ma non è la regola. Nella maggior parte delle piccole realtà è più onesto programmare un breve fermo in un orario concordato e avvisare chi lavora.