Stavo partecipando a un recente thread sulla community OTN in cui qualcuno poneva domande sul downgrade dopo un aggiornamento del database. Una delle risposte ha chiesto quante persone praticano effettivamente i downgrade del database. Ho creato questo sondaggio per scoprirlo.
Sono stato sorpreso di trovare un contributo a quel thread che diceva:
Ora quel poster non l'ha detto esplicitamente, ma era quasi come se quell'individuo stesse dicendo che praticare i downgrade era una perdita di tempo perché non ne avranno mai bisogno. Darò al poster il beneficio del dubbio e che questo dipendente Oracle non lo stava effettivamente dicendo. Non sto cercando di prendersela con questo individuo. Lascerò che questo thread mi dia l'opportunità di discutere l'argomento da un punto di vista più generico. (Aggiornamento: il poster che mi ha spinto a scrivere questo post del blog è tornato sul thread nel tempo impiegato per scriverlo e ha detto "non intendeva implicare che non dovremmo "testare" i downgrade.")
A luglio, ho scritto un post sul blog su The Data Guardian. In quel post sul blog, ho detto:
Il DBA deve proteggere i dati. Questo è il lavoro n. 1. Il compito n. 2 è per il DBA fornire un accesso efficiente e tempestivo ai dati. A cosa serve avere i dati se le persone che hanno bisogno di accedervi non possono accedervi? Se quelle persone hanno prestazioni terribili quando interagiscono con i dati, allora potrebbero anche non avere accesso.
In qualità di DBA, dobbiamo eseguire la gestione del rischio. Dobbiamo determinare quali rischi potrebbero diventare realtà. Il compito del DBA è misurare quei rischi e determinare due piani d'azione. Quali misure possono essere adottate per evitare che il rischio diventi realtà e quali misure devo intraprendere per risolvere il problema quando tale rischio diventa realtà?
Anche un DBA di livello junior comprenderà l'importanza dei backup. I backup sono una strategia di gestione del rischio. Se i dati vengono persi, possiamo recuperare i dati dal backup. E anche un DBA di livello junior comprende l'importanza di poter eseguire il ripristino dal backup.
In questo thread OTN, ho scritto questo:
Per me, questa è una specie di legge di Murphy. Ho detto cose simili in passato. L'idea (ed è il punto centrale di questo post del blog) è che se non accetto le misure appropriate di gestione del rischio, sto solo chiedendo agli dei di trasformare quel rischio in realtà. Se mi rifiuto di regolare il mio specchietto retrovisore e di usarlo quando sto facendo il backup del mio veicolo, beh, quello è il giorno in cui torno in qualcosa. Se mi rifiuto di allacciarmi i lacci delle scarpe, beh, quello è il giorno in cui ne calpesto uno e inciampo. Il giorno in cui mi rifiuto di indossare occhiali protettivi quando uso un utensile elettrico è il giorno in cui ho qualcosa negli occhi. Il giorno in cui vado in spiaggia e mi rifiuto di mettermi la crema solare è il giorno in cui tornerò a casa con una scottatura solare. Ti sei fatto un'idea.
Alcuni lettori potrebbero pensare che sono pazzo e che l'universo non ha questo piano generale per fregarmi solo perché sono compiacente. E sarei d'accordo. Quindi lo dirò in un altro modo, se non ho intenzione di mitigare il rischio, non ho fatto nulla per impedire che diventi una realtà. Le possibilità che diventi realtà non diminuiscono a causa della mia inazione.
Ci sono due componenti principali per la gestione del rischio. 1) determinare la probabilità che si verifichi tale elemento di rischio e 2) determinare l'impatto quando si verifica tale rischio. Gli elementi che hanno la probabilità più alta prima di tutto vengono mitigati. Questo è facile ed è qualcosa che fanno spesso molti che lavorano sulla gestione del rischio. Mettono gli elementi di rischio in un foglio di calcolo e compilano un valore per la probabilità che si verifichi quel rischio. Una volta completati, ordinano sulla colonna delle probabilità e avviano l'attenuazione del rischio dall'alto verso il basso. Molte strategie di gestione del rischio tracciano una linea da qualche parte nel mezzo dell'elenco e decidono che qualsiasi voce di rischio al di sotto di quella linea ha una probabilità troppo bassa che non ci preoccuperemo di quella voce di rischio. Non possiamo mitigare tutti i possibili rischi nell'universo. Non c'è abbastanza tempo per gestire tutto. Quindi dobbiamo tracciare la linea da qualche parte.
Uno dei difetti che vedo continuamente è che la gestione del rischio non dedica molto tempo a concentrarsi sull'impatto di quel rischio diventi realtà. Il foglio di calcolo deve includere una colonna simile che fornisce una valutazione dell'impatto sull'attività per quell'elemento di rischio. Anche il gestore del rischio deve ordinare il foglio di calcolo in questa colonna. Qualsiasi elemento che ha un grande impatto deve avere attività di mitigazione del rischio anche se quell'elemento ha una bassa probabilità di verificarsi! Purtroppo, troppi nel settore della gestione del rischio non includono questo passaggio di valutazione dell'impatto del rischio. Anche in questo caso, quando il foglio di calcolo viene ordinato in base all'impatto sull'attività, viene tracciata una linea da qualche parte.
Si potrebbe scoprire che oggetti a rischio con una probabilità ELEVATA avere un impatto BASSO o addirittura MOLTO BASSO all'impresa. Mi piacciono i fogli di calcolo per la gestione del rischio che includono una terza colonna che è "probabilità x impatto". Questa colonna aiuta a comprendere la relazione tra le due componenti di rischio.
Torniamo alla domanda sull'aggiornamento del database che ha richiesto questo post sul blog. Penso che tutti coloro che leggono questo articolo del blog dovrebbero concordare sul fatto che l'aggiornamento di un database Oracle è una proposta rischiosa. Ci sono così tante cose diverse che potrebbero andare storte con un aggiornamento del database Oracle. La probabilità di un errore di aggiornamento è ALTO. Gli elementi di mitigazione del rischio spesso includono, ma non sono limitati a, la pratica dell'aggiornamento sui cloni di produzione e il backup del database prima dell'inizio del processo di aggiornamento. Perché lo facciamo? Bene, l'impatto per il business è MOLTO ALTO. Se non riusciamo ad aggiornare il nostro database di produzione, i nostri utenti aziendali non hanno accesso ai dati. Non siamo un buon Data Guardian se non riusciamo a superare questo fallimento. Se pratichiamo sufficientemente l'aggiornamento in ambienti non produttivi, possiamo ridurre la probabilità dell'elemento di rischio a MEDIO. Ma con ogni probabilità, non possiamo ridurre quella specifica probabilità di rischio a BASSA. Ecco perché eseguiamo il backup prima dell'inizio dell'aggiornamento. Dovrebbero esserci ancora problemi anche se abbiamo fatto del nostro meglio per ridurre la probabilità di tale elemento di rischio, l'impatto per il business è ancora MOLTO ALTO. Pertanto, la strategia di correzione del rischio del DBA consiste nel prendere appunti su dove e cosa ha causato il fallimento dell'aggiornamento e nel ripristino dal backup. Il database è attivo e funzionante e abbiamo eliminato l'impatto all'impresa. Il DBA torna quindi al tavolo da disegno per determinare come risolvere ciò che è andato storto. Il DBA sta tentando di ridurre la probabilità di quel problema che si ripresenta quando tornano in un momento successivo per eseguire nuovamente il processo di aggiornamento.
Quindi torniamo al commento nel thread OTN in cui sembrava dire che non valesse la pena esercitarsi con i downgrade del database. Non sono d'accordo. E il mio disaccordo ha tutto a che fare con l'impatto all'impresa. Sono d'accordo con il commento che il poster ha detto nella sua risposta.
Sono d'accordo con quel 100%. Perché eseguiamo questo "test approfondito"? È tutto a causa della mitigazione del rischio. Stiamo tentando di ridurre la probabilità che l'aggiornamento provocherà una riduzione delle prestazioni o l'interruzione della funzionalità dell'applicazione. Ma anche come diceva quel poster, "Ci saranno sempre problemi che si presenteranno in produzione dopo l'aggiornamento perché è impossibile testare il 100% della tua applicazione". Ancora una volta, sono d'accordo al 100% con ciò che questo poster sta dicendo qui. Ma che dire dell'impatto all'impresa? Ci arriverò tra un minuto, ma prima devo divagare un po' nel prossimo paragrafo...
Di recente ho aggiornato un sistema di produzione critico dalla versione 11.2.0.4 alla versione 12.1.0.2. Dove lavoro, abbiamo più test delle applicazioni di quanti ne abbia mai visti negli altri miei lavori. Abbiamo un team QA completo che fa i test per noi. Abbiamo anche un team incaricato dei nostri sforzi di test automatizzati. Abbiamo robot automatizzati che esercitano il nostro codice dell'applicazione ogni notte. Inoltre, abbiamo un'altra routine automatizzata che ogni volta che le persone inviano modifiche al codice a Test o Prod, questa routine esegue un rapido esame dei percorsi di codice critici. Ho aggiornato gli ambienti di sviluppo (più di 15) a 12.1.0.2 e poi ho aspettato un mese. Ho quindi aggiornato Test e ho aspettato 3 settimane prima di aggiornare la produzione. Sono stati rilevati e risolti problemi prima dell'aggiornamento della produzione. Ma anche dopo tutto questo, ho avuto grossi problemi una volta che la produzione è stata aggiornata. Puoi visitare i miei post sul blog da metà ottobre a metà dicembre per vedere alcuni di questi problemi. Ero molto vicino al downgrade di questo database, ma invece sono riuscito a risolvere i problemi. Ora torniamo al punto che stavo facendo...
Al termine dell'aggiornamento, il database viene aperto per l'attività. Gli utenti dell'applicazione possono ora utilizzare l'applicazione. Cosa succede all'interno del database a questo punto? Transazioni! E le transazioni significano modifiche ai dati. Nel momento in cui il DBA apre il database per le aziende dopo il completamento di un aggiornamento, iniziano a verificarsi le modifiche ai dati. Dopo tutto questo è questo il punto centrale del database, vero? Acquisisci le modifiche ai dati e rendi i dati disponibili agli utenti finali dell'applicazione.
Quindi cosa succede se sei sulla barca in cui ero lo scorso autunno con l'aggiornamento del mio database? Stavo colpendo cose che non vedevamo nella non produzione, anche dopo tutti i nostri test. L'impatto per il business era ALTO. Devo essere in grado di ridurre questo impatto sul business. Avevo tre opzioni. 1) Risolvi i problemi, uno per uno. 2) Ripristino dal backup che ho eseguito prima dell'aggiornamento in modo da poter riportare il database alla vecchia versione. 3) Eseguire il downgrade del database e tornare al tavolo da disegno. Ho scelto la prima opzione. come ho sempre fatto durante la mia carriera. Ma se ciò non bastasse? Può volerci del tempo per risolvere i problemi. Alcune aziende semplicemente non possono permettersi quel tipo di tempo con quell'impatto negativo all'impresa. Quanti siti web sono stati abbandonati perché le prestazioni erano pessime o le cose non funzionavano correttamente? E per la stragrande maggioranza dei database di produzione disponibili, l'opzione 2 ha un impatto davvero terribile al business! Perderai le transazioni una volta completato l'aggiornamento! Il DBA non sarà in grado di andare avanti oltre l'aggiornamento mantenendo il database nella versione precedente, quindi i dati andranno persi e per molti database di produzione ciò è inaccettabile. L'azienda può permettersi un'ora di perdita di dati, ma quante persone potrebbero attivare questa azione entro un'ora dall'aggiornamento? Con ogni probabilità, questa azione verrebbe eseguita giorni dopo l'aggiornamento e l'impatto all'azienda per quel tipo di perdita di dati è ben al di sopra di MOLTO ALTO. Quindi rimane l'opzione 3 come l'opzione con l'impatto più basso all'azienda per aiutare a risolvere qualsiasi impatto che l'azienda sta subendo dopo l'aggiornamento.
Probabilmente puoi dire da quell'ultimo paragrafo che ritengo che sia importante per il DBA Oracle sapere come eseguire il downgrade del proprio database al termine di un aggiornamento. Ammetto che la probabilità della necessità di eseguire un downgrade del DBA è MOLTO BASSA. Ma l'impatto il mancato downgrade può essere catastrofico per l'azienda. (Ci sono di nuovo quelle due parole). Perché la probabilità è basso, non pratico spesso i downgrade, ma perché l'impatto di non poter effettuare il downgrade è molto alto, li pratico ogni tanto.
Quindi, in chiusura, tornerò di nuovo su quella cosa della legge di Murphy. L'universo non sta cospirando contro di me, ma come Data Guardian, ho bisogno di mettere in pratica buoni principi di gestione del rischio. Ciò significa valutare la probabilità e l'impatto delle voci di rischio imposte dalla mia modifica. Anche se l'universo e gli dei potrebbero non mettere in moto la legge di Murphy o i suoi cugini, non farò alcun favore a me stesso mitigando gli elementi di rischio. Non sto riducendo la probabilità di un bit.
