Come evitare un'interruzione imprevista in fase di aggiornamento
Migrare i sistemi aziendali in cloud offre numerosi vantaggi. Uno dei principali, quando si adotta un servizio gestito, è non dover più mantenere il servizio sull'infrastruttura esistente con risorse tecniche interne e processi operativi consolidati. In cambio di un canone, può contare sulla conoscenza e sull'esperienza collettiva di un servizio gestito. I vantaggi nell'utilizzo di un servizio di gestione database sono molti: sicurezza, allocazione delle risorse e integrazione delle funzionalità, solo per citarne alcuni.
In questo articolo analizzeremo una funzionalità presente in diversi servizi dei cloud provider che, a prima vista, può sembrare una soluzione vincente per la manutenzione ordinaria. In realtà ha un costo che potrebbe rivelarsi devastante per la sua azienda, traducendosi in un'interruzione critica e in uno scenario di disastro per il quale non è preparata, perché le risorse tecniche e le competenze della precedente implementazione self-hosted non sono più a disposizione.
La funzionalità in questione è quella degli aggiornamenti automatici alle versioni minor.
Perché gli aggiornamenti dei prodotti sono importanti?
Ogni organizzazione ha processi e controlli propri, frutto di anni di esperienza, prodotti e strumenti interni costruiti su misura per le proprie attività. Possono essere processi molto solidi, adeguati o fragili. L'utilizzo di un servizio gestito può dare un senso di stabilità e una maggiore capacità operativa, ma non elimina la necessità della componente di test. Cloud, servizi gestiti, automazione, IaC e framework non eliminano la necessità di una corretta gestione dei processi.
Il database è un componente critico in qualsiasi azienda. Non è l'unico, ma in molte organizzazioni l'assenza di un database funzionante è un rischio con un impatto enorme sulla capacità operativa.
Tutti i prodotti, nel tempo, prevedono deprecazioni di funzionalità e sintassi, notifiche di end-of-life e patch di sicurezza. Questi cambiamenti richiedono una manutenzione continua dell'infrastruttura su cui poggiano le sue applicazioni. Gli aggiornamenti dei prodotti si presentano sotto forma di upgrade minor e update major: tratti entrambe le tipologie alla stessa stregua dal punto di vista del rischio aziendale.
Un aggiornamento minor non testato può mandare in tilt il suo sistema di produzione.
Il metodo di aggiornamento predefinito nei servizi gestiti
Molti servizi dei cloud provider mettono a disposizione strumenti e automazioni per gestire le attività ripetitive e di routine, inclusi gli aggiornamenti alle versioni minor.
Vediamo un esempio con AWS RDS. Quando crea un nuovo database tramite la AWS Console, le vengono mostrate diverse decine di opzioni di configurazione, ma non tutte. Selezioni Additional Configuration in fondo alla pagina per visualizzare l'elenco completo delle opzioni di setup.
Scorrendo fino in fondo a questa pagina aggiuntiva troverà la sezione Maintenance, dove l'opzione "Enable auto minor version upgrade" è attiva di default.
Le criticità di questo approccio
Affidarsi a questa impostazione predefinita comporta diversi problemi di fondo:
- Gli aggiornamenti minor vengono applicati nella finestra di manutenzione settimanale, a discrezione di AWS. Possono non essere eseguiti automaticamente nella finestra successiva e talvolta passano diverse settimane prima che vengano applicati.
- AWS non fa distinzione tra ambiente di test e ambiente di produzione. Se ha più ambienti impostati per l'aggiornamento automatico, potrebbero essere aggiornati tutti nella stessa settimana, oppure solo alcuni.
- AWS non dà priorità alle release Long-Term Support (LTS) rispetto agli aggiornamenti minor. La documentazione di AWS RDS afferma esplicitamente: "Si raccomanda di non impostare il parametro AutoMinorVersionUpgrade su true per le versioni LTS. Farlo potrebbe portare all'aggiornamento del cluster DB a una versione non LTS".
- Quando avviene un aggiornamento minor, AWS RDS non crea un punto di ripristino che le permetta di effettuare un rollback in caso di problemi successivi. Può ricorrere alla funzionalità di point-in-time recovery, ma questa non riporterà la versione del database in esecuzione alla versione precedente al ripristino.
- Le finestre di manutenzione sono in genere pianificate negli orari di basso utilizzo del sistema e coincidono di solito con la minima disponibilità di risorse tecniche. Il fatto che un aggiornamento non pianificato venga eseguito proprio in quella finestra rischia di allungare ulteriormente il tempo di interruzione.
Le versioni minor non vengono applicate automaticamente nella finestra di manutenzione successiva.
Un aggiornamento alla versione minor è importante quanto il rilascio di un nuovo prodotto interno. Quando la maggior parte delle sue risorse tecniche non è disponibile, distribuirebbe automaticamente in produzione un rilascio interno mai testato?
La best practice per gli aggiornamenti minor
È molto semplice: testare e verificare.
L'opzione "Enable auto minor version upgrade" è una funzionalità interessante che riduce la dipendenza dalla manutenzione ordinaria, ma alimenta una certa disattenzione verso il controllo dell'esecuzione e delle opzioni di ripristino. Il database è spesso un componente critico dello stack tecnologico. Richiede monitoraggio costante, gestione e manutenzione continua, esattamente come qualsiasi altro componente critico del sistema.
Il rilascio di una nuova versione minor in qualsiasi ambiente dovrebbe seguire un processo controllato e documentato. Questo include il passaggio attraverso i diversi ambienti fino alla produzione, ad esempio dev, test, stage e prod. Un aggiornamento andrebbe eseguito tramite automazione e supervisionato da una persona, anche quando si parla di centinaia o migliaia di server di database. Gli aggiornamenti vanno eseguiti quando le risorse sono online e disponibili: sia quelle operative che gestiscono l'infrastruttura, sia quelle di engineering pronte a intervenire qualora un'operazione imprevista o non testata generi un incidente.
I singoli passaggi del processo di aggiornamento sono specifici di ogni organizzazione. Tale processo dovrebbe sempre includere uno snapshot "pre" upgrade. In generale, il rilascio in produzione dovrebbe avvenire solo dopo un periodo congruo, ad esempio una o più settimane, dal rilascio e dalla verifica negli altri ambienti.
Un database di produzione non dovrebbe mai trovarsi su una versione più recente di quella usata in un ciclo di test di rilascio.
Non è consigliabile far funzionare il database con la point release più datata: questo trasformerebbe l'aggiornamento minor in un elemento sul percorso critico, e AWS non fornisce un calendario per la deprecazione e la rimozione. In genere è sconsigliato anche operare con la point release più recente: la community potrebbe non aver ancora individuato i problemi introdotti nell'ultima release e le risorse online a supporto del triage potrebbero essere limitate.
Come best practice, dovrebbe distribuire ogni point release in un momento adeguato per il business, evitando di combinare più versioni minor in un singolo aggiornamento. Un rollout alla versione più recente potrebbe rendersi necessario per via di un bug noto risolto in una nuova versione: in tal caso non avrà altra scelta se non testare, verificare e aggiornare al di fuori di una policy aziendale nota e documentata.
In sintesi, sia SEMPRE proattivo.
Identificare gli aggiornamenti minor disponibili
Negli ultimi mesi AWS ha introdotto una nuova funzionalità che espone le proprie raccomandazioni tramite AWS CLI e Console. In passato, individuare la disponibilità di nuove versioni richiedeva un processo più articolato: analisi delle Release Notes, monitoraggio delle nuove versioni rese disponibili o degli eventi di altri ambienti in cui questa funzionalità era abilitata.
Oggi può ottenere queste informazioni con il comando describe-db-recommendations. NOTA: il comando è disponibile a partire dalla versione CLI 2.15.3. Per individuare questo recente aggiornamento è necessario leggere il changelog riga per riga. Se non aggiorna spesso la sua CLI, le servirà una versione più recente per utilizzare questo comando.
Output di describe-db-recommendations
$ aws rds describe-db-recommendations
{
"RecommendationId": "",
"TypeId": "config_recommendation::old_minor_version",
"Severity": "informational",
"ResourceArn": "arn:aws:rds:region:123456789:cluster:mydb",
"Status": "active",
"Detection": "**[resource-name]** is not running the latest minor DB engine version",
"Recommendation": "Upgrade to latest engine version",
"Description": "Your database resources aren't running the latest minor DB engine version. The latest minor version contains the latest security fixes and other improvements.",
"RecommendedActions": [\
{\
"ActionId": "",\
"Operation": "modifyDbCluster",\
"Parameters": [\
{\
"Key": "EngineVersion",\
"Value": "8.0.mysql_aurora.3.04.2"\
},\
{\
"Key": "DBClusterIdentifier",\
"Value": "mydb"\
}\
],\
"ApplyModes": [\
"immediately",\
"next-maintenance-window"\
],\
"Status": "ready",\
"ContextAttributes": [\
{\
"Key": "Recommended value",\
"Value": "8.0.mysql_aurora.3.04.2"\
},\
{\
"Key": "Current engine version",\
"Value": "8.0.mysql_aurora.3.04.1"\
}\
]\
}\
```\
### Output della AWS Console\
Utilizzando la AWS Console con il servizio RDS, vedrà la sezione Recommendations evidenziata nel menu a sinistra. Ad esempio:\
\
### **Elenco delle raccomandazioni RDS**\
Dall'elenco delle raccomandazioni potrà visualizzare i server con l'avviso "is not running the latest monitor DB engine version".\
\
### Maggiori dettagli su una raccomandazione specifica\
È inoltre possibile approfondire una raccomandazione per esaminare la configurazione completa della risorsa e i relativi riferimenti alla documentazione applicabile.\
\
Considerazioni finali\
Combinare queste informazioni con un job pianificato a cadenza regolare per raccogliere e condividere le notifiche le consentirà di prepararsi a un aggiornamento minor consigliato. Validazioni aggiuntive e procedure di ripristino predisposte in linea con i requisiti e le risorse della sua azienda aumenteranno sensibilmente la certezza di non subire impatti in produzione durante gli aggiornamenti alle versioni minor.\