Perché riavviamo i server

Una domanda che si ripresenta con regolarità è se i server debbano essere riavviati di routine, per esempio una volta a settimana, oppure se vada loro consentito di restare in funzione il più a lungo possibile per ottenere il massimo «uptime». Per me la risposta è semplice: salvo rare eccezioni, i riavvii regolari sono la scelta più appropriata per i server.

Come per ogni regola, ci sono casi in cui non si applica. Per esempio, alcune aziende che gestiscono sistemi critici non hanno alcun margine per i tempi di inattività e devono essere disponibili 24 ore su 24, 7 giorni su 7. Ovviamente sistemi del genere non possono essere semplicemente riavviati in modo routinario. Tuttavia, se un sistema è così critico da non poter mai essere messo offline, questa situazione dovrebbe far scattare un campanello d'allarme: questo sistema è un punto di guasto e forse occorrerebbe avviare una riflessione su come gestire i tempi di inattività, siano essi pianificati o non pianificati.

Un'altra eccezione è che alcuni sistemi AIX necessitano di un uptime considerevole, superiore a qualche settimana, per raggiungere la massima efficienza, poiché il sistema si auto-ottimizza e ha bisogno di tempo per raccogliere informazioni sull'utilizzo e regolarsi di conseguenza. Questo tende a limitarsi a grandi server di database che cambiano di rado e a scenari d'uso analoghi, meno comuni rispetto ad altre piattaforme.

Nell'IT veneriamo spesso il concetto di «uptime», ossia per quanto tempo un sistema può funzionare senza necessità di riavvio. Ma l'«uptime» non è un concetto che porta valore all'azienda, e l'IT deve tenere costantemente presenti le esigenze dell'azienda anziché concentrarsi su metriche artificiali. All'azienda non interessa per quanto tempo un server sia riuscito a restare online senza riavviarsi: interessa soltanto che il server sia disponibile e pronto quando serve per i processi aziendali. Si tratta di concetti molto diversi.

Per quasi ogni normale server aziendale esiste una finestra in cui il server deve essere disponibile per scopi aziendali e una finestra in cui non è necessario. Queste finestre possono essere giornaliere, settimanali o mensili, ma è raro il server che sia effettivamente in uso 24 ore su 24 senza eccezioni.

Sento spesso affermare che, poiché si esegue il sistema operativo X anziché Y, non è più necessario riavviare, ma ciò semplicemente non è vero. Ci sono due ragioni principali per riavviare regolarmente: verificare la capacità del server di riavviarsi correttamente e applicare le patch che non possono essere applicate senza un riavvio.

L'applicazione delle patch è il motivo per cui la maggior parte delle aziende riavvia. Quasi tutti i sistemi operativi ricevono aggiornamenti regolari che richiedono un riavvio per avere effetto. Poiché la maggior parte delle patch viene rilasciata per finalità di sicurezza e stabilità, specialmente quelle che richiedono un riavvio, l'importanza di applicarle è piuttosto elevata. Rendere un server inutilmente vulnerabile solo per mantenere l'uptime non è saggio.

Verificare la capacità di un server di riavviarsi correttamente è ciò che spesso viene trascurato. Alla maggior parte dei server vengono applicate modifiche con regolarità. Le modifiche possono essere patch, nuove applicazioni, cambiamenti di configurazione, aggiornamenti o simili. Qualsiasi modifica introduce un rischio. Il fatto che un server sia integro subito dopo l'applicazione di una modifica non significa che il server, né le applicazioni in esecuzione su di esso, si avvieranno come previsto al riavvio.

Se il server non viene mai riavviato, allora non sapremo mai se è in grado di riavviarsi correttamente. Con il tempo, il numero di modifiche applicate dall'ultimo riavvio aumenterà. Questo è molto pericoloso. Ciò che temiamo è che sia stato apportato un gran numero di modifiche, magari molte delle quali non documentate, e che un riavvio fallisca a quel punto. In tal caso, individuare quale modifica stia causando il malfunzionamento del sistema potrebbe rivelarsi un'impresa insormontabile. Nessuna singola modifica da annullare, nessun percorso noto verso il ripristino. È a questo punto che subentra il panico. Naturalmente, una macchina che non viene mai riavviata intenzionalmente è più soggetta a riavviarsi involontariamente, il che significa che la probabilità di un riavvio fallito è sia più alta, sia più probabile che si verifichi durante l'uso attivo.

Sebbene i riavvii regolari non abbiano lo scopo di ridurre la frequenza dei riavvii falliti, anzi ne aumentino di fatto l'occorrenza, il loro fine è rendere quei fallimenti facilmente gestibili da un punto di vista di «modifica nota» e, cosa ancora più importante, controllare quando avvengono quei riavvii, così da garantire che si verifichino in un momento in cui il server è designato come disponibile per la manutenzione ed è progettato per essere sottoposto a stress, in modo che i problemi vengano individuati in un momento in cui possono essere mitigati senza impatto sull'azienda.

Ho sentito molti amministratori di sistema affermare di evitare i riavvii nel fine settimana perché non vogliono ritrovarsi a lavorare la domenica a causa di server che non si riaccendono dopo un riavvio. Anche io sono stato chiamato molte domeniche mattina per un riavvio fallito, ma ogni volta che ricevo quella chiamata provo un senso di sollievo. So che abbiamo appena individuato un problema in un momento in cui l'azienda non subisce un impatto finanziario. Se quel server non fosse stato riavviato durante le ore non lavorative, si sarebbe forse scoperto che era «non avviabile» solo dopo che si era guastato durante l'orario di lavoro attivo, causando una perdita di fatturato.

Grazie ai riavvii regolari nel fine settimana, possiamo individuare i disastri incombenti in modo sicuro e, grazie alla consapevolezza di avere da indagare solo una settimana di modifiche, siamo regolarmente in grado di risolvere i problemi con uno sforzo generalmente minimo e con grande sicurezza di comprendere quali modifiche fossero state apportate prima del guasto.

I riavvii regolari servono a proteggere l'azienda da interruzioni e tempi di inattività che possono essere mitigati attraverso processi molto semplici e affidabili.