Ik nam deel aan een recente thread op de OTN-gemeenschap waar iemand vragen stelde over downgraden na een database-upgrade. Een van de reacties vroeg hoeveel mensen daadwerkelijk database-downgrades toepassen. Ik heb deze poll gemaakt om erachter te komen.
Ik was verrast om één bijdrage aan die thread te vinden die zei:
Nu zei die poster het niet expliciet, maar het was bijna alsof die persoon zei dat het oefenen van downgrades tijdverspilling was omdat ze het nooit nodig zullen hebben. Ik zal de poster het voordeel van de twijfel geven en dat deze Oracle-medewerker dit niet echt zei. Ik probeer deze persoon niet aan te vallen. Ik laat deze draad me de mogelijkheid bieden om het onderwerp vanuit een meer generiek gezichtspunt te bespreken. (Update: de poster die me ertoe aanzette dit blogbericht te schrijven, is teruggekeerd naar de thread in de tijd die ik nodig had om dit te schrijven en zei:"bedoelde niet dat we downgrades niet moesten 'testen'.")
In juli schreef ik een blogpost over The Data Guardian. In die blogpost zei ik:
De DBA moet de gegevens beschermen. Dat is baan #1. Taak #2 is voor de DBA om efficiënte en tijdige toegang tot de gegevens te bieden. Wat heb je aan de gegevens als de mensen die er toegang toe nodig hebben, niet bij de gegevens kunnen komen? Als die mensen slechte prestaties leveren bij het omgaan met de gegevens, kunnen ze net zo goed geen toegang hebben.
Als DBA moeten we risicobeheer uitvoeren. We moeten bepalen welke risico's werkelijkheid kunnen worden. Het is de taak van de DBA om die risico's te meten en twee actieplannen vast te stellen. Welke stappen kunnen worden genomen om te voorkomen dat dat risico werkelijkheid wordt en welke stappen moet ik nemen om het probleem op te lossen wanneer dat risico werkelijkheid wordt?
Zelfs een DBA op junior niveau begrijpt het belang van back-ups. Back-ups zijn een strategie voor risicobeheer. Als er gegevens verloren gaan, kunnen we de gegevens herstellen vanaf de back-up. En zelfs een DBA op juniorniveau begrijpt hoe belangrijk het is om vanaf de back-up te kunnen herstellen.
In deze OTN-thread schreef ik dit:
Voor mij is dit een soort wet van Murphy. Ik heb in het verleden soortgelijke dingen gezegd. Het idee (en het hele punt van dit blogbericht) is dat als ik niet de juiste stappen voor risicobeheer onderneem, ik de goden gewoon vraag om dat risico om te zetten in realiteit. Als ik weiger mijn achteruitkijkspiegel af te stellen en deze te gebruiken wanneer ik achteruit rijd met mijn voertuig, dan is dat de dag dat ik ergens tegenaan loop. Als ik weiger mijn schoenveters te strikken, dan is dat de dag dat ik op een schoen stap en struikel. De dag dat ik weiger om beschermende googles te dragen wanneer ik een elektrisch gereedschap gebruik, is de dag dat ik iets in mijn oog krijg. De dag dat ik naar het strand ga en weiger zonnebrandcrème op te doen, is de dag dat ik thuiskom met zonnebrand. Je snapt het idee.
Sommige lezers denken misschien dat ik gek ben en dat het universum dit masterplan niet heeft om me te belazeren, alleen maar omdat ik zelfgenoegzaam ben. En ik zou het ermee eens zijn. Dus ik zal het op een andere manier zeggen, als ik niet van plan ben het risico te verkleinen, dan heb ik niets gedaan om te voorkomen dat het werkelijkheid wordt. De kans dat het werkelijkheid wordt, neemt niet af door mijn passiviteit.
Risicobeheer bestaat uit twee belangrijke componenten. 1) het bepalen van de waarschijnlijkheid dat dat risico-item zich voordoet en 2) het bepalen van de impact wanneer dat risico zich voordoet. De items met de hoogste waarschijnlijkheid optreden, worden eerst beperkt. Dit is eenvoudig en iets dat velen die aan risicobeheer werken vaak doen. Ze zetten de risico-items in een spreadsheet en vullen een waarde in voor de kans dat dat risico zich voordoet. Als ze klaar zijn, sorteren ze op de waarschijnlijkheidskolom en beginnen ze van boven naar beneden met risicobeperking. Veel strategieën voor risicobeheer trekken ergens in het midden van de lijst een lijn en besluiten dat elk risico-item onder die lijn een te lage kans heeft dat we ons geen zorgen maken over dat risico-item. We kunnen niet alle mogelijke risico's in het universum beperken. Er is gewoon niet genoeg tijd om alles te verwerken. We moeten dus ergens een grens trekken.
Een van de tekortkomingen die ik de hele tijd zie, is dat risicobeheer niet veel tijd besteedt aan het focussen op de impact dat het risico werkelijkheid wordt. De spreadsheet moet een vergelijkbare kolom bevatten die een beoordeling geeft van de impact op het bedrijf voor dat risico-item. De risicomanager moet de spreadsheet ook in deze kolom sorteren. Alle items die een grote impact hebben, moeten risicobeperkende activiteiten hebben, zelfs als dat item een lage kans heeft dat ze zich voordoen! Helaas nemen te veel mensen in de risicobeheersector deze stap van het beoordelen van de risico-impact niet op. Nogmaals, wanneer de spreadsheet wordt gesorteerd op impact op het bedrijf, wordt ergens een lijn getrokken.
Het kan zijn dat risico-items met een HOGE waarschijnlijkheid een LAGE of zelfs ZEER LAGE impact . hebben naar het bedrijf. Ik hou van spreadsheets voor risicobeheer die een derde kolom bevatten die 'waarschijnlijkheid x impact' is. Deze kolom helpt de relatie tussen de twee risicocomponenten te begrijpen.
Laten we teruggaan naar de vraag over de database-upgrade die aanleiding gaf tot deze blogpost. Ik denk dat iedereen die dit blogartikel leest het ermee eens moet zijn dat het upgraden van een Oracle-database een riskante aangelegenheid is. Er zijn zoveel verschillende dingen die mis kunnen gaan met een Oracle-database-upgrade. De waarschijnlijkheid van een upgradefout is HOOG. Risicobeperkende items omvatten vaak, maar zijn niet beperkt tot, het oefenen van de upgrade op productieklonen en het maken van een back-up van de database voordat het upgradeproces begint. Waarom doen we dit? Nou, de impact voor het bedrijf is ZEER HOOG. Als we falen bij het upgraden van onze productiedatabase, hebben onze zakelijke gebruikers geen toegang tot de gegevens. We zijn geen erg goede Data Guardian als we niet voorbij deze mislukking kunnen komen. Als we de upgrade voldoende oefenen in niet-productieomgevingen, kunnen we de kans op het risico-item terugbrengen tot MEDIUM. Maar naar alle waarschijnlijkheid kunnen we die specifieke risicokans niet terugbrengen tot LAAG. Daarom maken we de back-up voordat de upgrade begint. Mochten er nog steeds problemen zijn, ook al hebben we ons best gedaan om de waarschijnlijkheid . te verkleinen van dat risico-item, de impact voor het bedrijf is nog steeds ZEER HOOG. De risicoherstelstrategie van de DBA is dus om aantekeningen te maken over waar en waardoor de upgrade is mislukt, en om te herstellen vanaf de back-up. De database is actief en we hebben de impact . geëlimineerd naar het bedrijf. De DBA gaat vervolgens terug naar de tekentafel om te bepalen hoe de fout kan worden opgelost. De DBA probeert de waarschijnlijkheid . te verkleinen dat het probleem zich opnieuw voordoet wanneer ze op een later tijdstip terugkomen om het upgradeproces opnieuw uit te voeren.
Dus laten we teruggaan naar de opmerking in de OTN-thread waar het leek te zeggen dat het oefenen van database-downgrades de tijd niet waard is. Ben ik het niet mee eens. En mijn meningsverschil heeft alles te maken met de impact naar het bedrijf. Ik ben het eens met de opmerking die de poster in zijn antwoord zei.
Daar ben ik het 100% mee eens. Waarom doen we deze "grondige test"? Het is allemaal vanwege risicobeperking. We proberen de waarschijnlijkheid . te verkleinen dat de upgrade slechte prestaties zal veroorzaken of ervoor zal zorgen dat de functionaliteit van de applicatie kapot gaat. Maar zelfs zoals die poster zei:"Er zullen altijd problemen zijn die in productie verschijnen na de upgrade, omdat het onmogelijk is om 100% van je applicatie te testen." Nogmaals, ik ben het 100% eens met wat deze poster hier zegt. Maar hoe zit het met de impact aan het bedrijf? Ik kom daar zo op terug, maar eerst moet ik een beetje afdwalen in deze volgende paragraaf...
Ik heb onlangs een kritiek productiesysteem geüpgraded van 11.2.0.4 naar de 12.1.0.2-versie. Waar ik werk, hebben we meer toepassingstests dan ik ooit heb gezien in mijn andere banen. We hebben een volledig QA-team dat tests voor ons uitvoert. We hebben zelfs een team dat verantwoordelijk is voor onze geautomatiseerde testinspanningen. We hebben geautomatiseerde robots die elke nacht onze applicatiecode gebruiken. Bovendien hebben we nog een geautomatiseerde routine die elke keer dat mensen codewijzigingen naar Test of Prod pushen, deze routine een snel onderzoek doet naar kritieke codepaden. Ik heb ontwikkelomgevingen (meer dan 15) geüpgraded naar 12.1.0.2 en heb toen een maand gewacht. Ik heb toen Test geüpgraded en 3 weken gewacht voordat ik de productie opwaardeerde. Er zijn problemen gevonden en opgelost voordat we de productie hebben geüpgraded. Maar zelfs na dat alles had ik grote problemen toen de productie eenmaal was opgewaardeerd. U kunt half oktober tot half december mijn blogposts bezoeken om enkele van die problemen te bekijken. Ik stond op het punt om deze database te downgraden, maar in plaats daarvan slaagde ik erin om de problemen op te lossen. Nu terug naar het punt dat ik aan het maken was...
Nadat de upgrade is voltooid, wordt de database voor bedrijven geopend. Applicatiegebruikers mogen de applicatie nu gebruiken. Wat gebeurt er op dit moment in de database? Transacties! En transacties betekenen gegevenswijzigingen. Op het moment dat de DBA de database voor bedrijven opent nadat een upgrade is voltooid, beginnen gegevensveranderingen plaats te vinden. Na dit alles is dat het hele punt van de database, nietwaar? Leg gegevenswijzigingen vast en maak gegevens beschikbaar voor de eindgebruikers van de applicatie.
Dus wat gebeurt er als je in de boot zit waarin ik afgelopen herfst zat met mijn database-upgrade? Ik raakte dingen die we niet zagen in niet-productie, zelfs niet na al onze tests. De impact voor het bedrijf was HOOG. Ik moet deze impact op het bedrijf kunnen verminderen. Ik had drie opties. 1) Los de problemen één voor één op. 2) Herstel vanaf de back-up die ik vóór de upgrade heb gemaakt, zodat ik de database terug kon krijgen naar de oude versie. 3) Downgrade de database en ga terug naar de tekentafel. Ik koos voor de eerste optie. zoals ik altijd heb gedaan tijdens mijn carrière. Maar wat als dat niet voldoende was? Het kan even duren voordat de problemen zijn opgelost. Sommige bedrijven kunnen zich dat soort tijd gewoonweg niet veroorloven met die negatieve impact naar het bedrijf. Hoeveel websites zijn verlaten omdat de prestaties slecht waren of omdat dingen niet correct werkten? En voor de overgrote meerderheid van de productiedatabases die er zijn, heeft optie 2 een zeer verschrikkelijke impact naar het bedrijf! U verliest transacties nadat de upgrade is voltooid! De DBA zal niet verder kunnen gaan dan de upgrade terwijl de database in de oude versie blijft, dus gegevens gaan verloren en voor veel productiedatabases is dit onaanvaardbaar. Het bedrijf kan zich misschien een uur gegevensverlies veroorloven, maar hoeveel mensen zouden binnen een uur na de upgrade de trekker overhalen om deze actie te ondernemen? Naar alle waarschijnlijkheid zou deze actie dagen na de upgrade en de impact . worden uitgevoerd voor het bedrijf voor dat soort gegevensverlies is ruim boven ZEER HOOG. Dus dat laat optie 3 over als de optie met de laagste impact aan het bedrijf om te helpen bij het oplossen van de gevolgen die het bedrijf ondervindt na de upgrade.
Uit die laatste alinea kun je waarschijnlijk opmaken dat ik het belangrijk vind dat de Oracle DBA weet hoe ze hun database moeten downgraden nadat een upgrade is voltooid. Ik geef toe dat de waarschijnlijkheid van de DBA die nodig is om een downgrade uit te voeren, ZEER LAAG is. Maar de impact van het niet downgraden kan catastrofaal zijn voor het bedrijf. (Daar zijn die twee woorden weer). Omdat de waarschijnlijkheid laag is, doe ik niet vaak aan downgrades, maar omdat de impact van niet kunnen downgraden is erg hoog, ik oefen ze af en toe.
Dus tot slot ga ik nog een keer terug naar dat ding van Murphy's Law. Het universum spant niet tegen mij samen, maar als Data Guardian moet ik goede principes voor risicobeheer toepassen. Dat betekent het beoordelen van de waarschijnlijkheid en de impact van risico-items die door mijn wijziging worden opgelegd. Hoewel het universum en de goden Murphy's Law of zijn neven en nichten misschien niet in gang zetten, doe ik mezelf geen plezier door risico-items te verminderen. Ik verklein de kans niet een beetje.