Jeg deltog i en nylig tråd om OTN-fællesskabet, hvor nogen stillede spørgsmål om nedgradering efter en databaseopgradering. Et af svarene spurgte, hvor mange mennesker der rent faktisk praktiserer databasenedgraderinger. Jeg oprettede denne afstemning for at finde ud af det.
Jeg var overrasket over at finde et bidrag til den tråd, som sagde:
Nu sagde den plakat det ikke eksplicit, men det var næsten, som om vedkommende sagde, at det at praktisere nedgraderinger var spild af tid, fordi de aldrig får brug for det. Jeg vil give plakaten fordelen af tvivlen, og at denne Oracle-medarbejder faktisk ikke sagde dette. Jeg forsøger ikke at vælge denne person. Jeg vil lade denne tråd give mig mulighed for at diskutere emnet fra et mere generisk synspunkt. (Opdatering: plakaten, der fik mig til at skrive dette blogindlæg, er vendt tilbage til tråden i den tid, det tog mig at skrive dette, og sagde, "menede ikke at antyde, at vi ikke skulle 'teste' nedgraderinger." )
Tilbage i juli skrev jeg et blogindlæg om The Data Guardian. I det blogindlæg sagde jeg:
DBA skal beskytte dataene. Det er job #1. Job #2 er for DBA at give effektiv og rettidig adgang til dataene. Hvad nytter det at have dataene, hvis de mennesker, der har brug for adgang til dem, ikke kan komme til dataene? Hvis disse mennesker har en forfærdelig ydeevne, når de interagerer med dataene, kan de lige så godt have ingen adgang.
Som DBA skal vi udføre risikostyring. Vi er nødt til at afgøre, hvilke risici der kan blive til virkelighed. DBA's opgave er at måle disse risici og fastlægge to handlingsplaner. Hvilke skridt kan tages for at undgå, at denne risiko bliver til virkelighed, og hvilke skridt skal jeg tage for at løse problemet, når denne risiko bliver en realitet?
Selv en DBA på juniorniveau vil forstå vigtigheden af backups. Sikkerhedskopier er en risikostyringsstrategi. Hvis data går tabt, kan vi gendanne dataene fra sikkerhedskopien. Og selv en DBA på juniorniveau forstår vigtigheden af at kunne gendanne fra sikkerhedskopien.
I denne OTN-tråd skrev jeg dette:
For mig er dette en slags Murphys lov. Jeg har sagt lignende ting tidligere. Ideen (og det er hele pointen med dette blogindlæg) er, at hvis jeg ikke tager passende risikostyringstrin, så beder jeg bare guderne om at gøre den risiko til virkelighed. Hvis jeg nægter at justere mit bakspejl og bruge det, når jeg bakker mit køretøj, så er det den dag, jeg vender tilbage til noget. Hvis jeg nægter at binde mine snørebånd, så er det den dag, jeg træder på en og tripper. De dag, hvor jeg nægter at bære beskyttende googles, når jeg bruger et elværktøj, er den dag, jeg får noget i øjet. Den dag, jeg går på stranden og nægter at tage solcreme på, er den dag, jeg kommer hjem med en solskoldning. Du forstår ideen.
Nogle læsere tænker måske, at jeg er skør, og at universet ikke har den her masterplan til at skrue på mig, bare fordi jeg er selvtilfreds. Og jeg er enig. Så jeg vil sige det på en anden måde, hvis jeg ikke planlægger at mindske risikoen, så har jeg ikke gjort noget for at forhindre det i at blive en realitet. Chancerne for, at det bliver en realitet, bliver ikke mindre på grund af min passivitet.
Der er to hovedkomponenter til risikostyring. 1) bestemmelse af sandsynligheden for, at det pågældende risikoelement opstår, og 2) bestemmelse af påvirkningen, når denne risiko opstår. De elementer, der har den højeste sandsynlighed af opstået afbødes først. Dette er nemt og noget, som mange, der arbejder med risikostyring, ofte gør. De lægger risikoelementerne i et regneark og udfylder en vis værdi for sandsynligheden for, at den risiko opstår. Når de er færdige, sorterer de på sandsynlighedskolonnen og starter risikoreduktion fra toppen og ned. Mange risikostyringsstrategier trækker en streg et sted i midten af listen og beslutter, at ethvert risikoelement under den linje har for lav sandsynlighed for, at vi ikke vil bekymre os om det risikoelement. Vi kan ikke afbøde alle mulige risici i universet. Der er bare ikke tid nok til at klare det hele. Så vi må trække grænsen et sted.
En af de mangler, jeg hele tiden ser, er, at risikostyring ikke bruger meget tid på at fokusere på påvirkningen af den risiko bliver til virkelighed. Regnearket skal indeholde en lignende kolonne, der giver en vurdering af indvirkningen på virksomheden for det pågældende risikoelement. Risikomanageren skal også sortere regnearket i denne kolonne. Ethvert emne, der har en stor indvirkning, skal have risikobegrænsende aktiviteter, selvom det pågældende emne har en lav sandsynlighed for at forekomme! Desværre undlader alt for mange i risikostyringsbranchen at inkludere dette trin med at vurdere risikopåvirkningen. Igen, når regnearket er sorteret efter indvirkning på virksomheden, trækkes der en linje et eller andet sted.
Man kan opleve, at risici med en HØJ sandsynlighed have en LAV eller endda MEGET LAV påvirkning til virksomheden. Jeg kan godt lide risikostyringsregneark, der indeholder en tredje kolonne, som er "sandsynlighed x effekt". Denne kolonne hjælper med at forstå forholdet mellem de to risikokomponenter.
Lad os gå tilbage til databaseopgraderingsspørgsmålet, der foranledigede dette blogindlæg. Jeg tror, at alle, der læser denne blogartikel, burde være enige om, at opgradering af en Oracle-database er et risikabelt forslag. Der er så mange forskellige ting, der kan gå galt med en Oracle-databaseopgradering. sandsynligheden af en opgraderingsfejl er HØJ. Risikobegrænsende elementer inkluderer ofte, men er ikke begrænset til, at øve opgraderingen på kloner af produktion og sikkerhedskopiere databasen, før opgraderingsprocessen begynder. Hvorfor gør vi dette? Nå virkningen til virksomheden er MEGET HØJ. Hvis vi fejler, når vi opgraderer vores produktionsdatabase, så har vores forretningsbrugere ingen adgang til dataene. Vi er ikke en særlig god Data Guardian, hvis vi ikke kan komme forbi denne fiasko. Hvis vi øver opgraderingen tilstrækkeligt i ikke-produktionsmiljøer, kan vi reducere sandsynligheden for risikoelementet til MIDDEL. Men efter al sandsynlighed kan vi ikke reducere den specifikke risikosandsynlighed til LAV. Derfor tager vi backup, inden opgraderingen begynder. Skulle stadig have problemer, selvom vi har gjort vores bedste for at reducere sandsynligheden af denne risikopost, påvirkningen til virksomheden er stadig MEGET HØJ. Så DBA's risikoafhjælpningsstrategi er at tage noter om, hvor og hvad der forårsagede, at opgraderingen mislykkedes, og at gendanne fra sikkerhedskopien. Databasen er oppe og køre, og vi har elimineret påvirkningen til virksomheden. DBA går derefter tilbage til tegnebrættet for at bestemme, hvordan man løser det, der gik galt. DBA forsøger at reducere sandsynligheden af det problem, der opstår igen, når de vender tilbage på et senere tidspunkt for at udføre opgraderingsprocessen igen.
Så lad os gå tilbage til kommentaren i OTN-tråden, hvor det så ud til at sige, at det ikke er tiden værd at praktisere databasenedgraderinger. Jeg er uenig. Og min uenighed har alt at gøre med påvirkningen til virksomheden. Jeg er enig i den kommentar, som plakaten sagde i deres svar.
Det er jeg 100% enig i. Hvorfor laver vi denne "grundige test"? Det er alt sammen på grund af risikoreduktion. Vi forsøger at reducere sandsynligheden at opgraderingen vil forårsage dårlig ydeevne eller få applikationsfunktionalitet til at gå i stykker. Men selv som plakaten sagde:"Der vil altid være problemer, der dukker op i produktionen efter opgraderingen, fordi det er umuligt at teste 100 % af din applikation." Igen er jeg 100% enig i, hvad denne plakat siger her. Men hvad med virkningen til virksomheden? Jeg kommer til det om et øjeblik, men først er jeg nødt til at fordybe mig lidt i dette næste afsnit...
Jeg har for nylig opgraderet et kritisk produktionssystem fra 11.2.0.4 til 12.1.0.2-versionen. Hvor jeg arbejder, har vi flere ansøgningstest, end jeg nogensinde har set i mine andre job. Vi har et komplet QA-team, der tester for os. Vi har endda et team, der er ansvarlig for vores automatiserede testindsats. Vi har automatiserede robotter, der udøver vores applikationskode hver nat. Oven i det hele har vi en anden automatiseret rutine, som hver gang folk skubber kodeændringer til Test eller Prod, foretager denne rutine en hurtig undersøgelse af kritiske kodestier. Jeg opgraderede udviklingsmiljøer (mere end 15 af dem) til 12.1.0.2 og ventede derefter en måned. Jeg opgraderede derefter Test og ventede 3 uger, før jeg opgraderede produktionen. Der blev fundet og løst problemer, før vi opgraderede produktionen. Men selv efter alt det, havde jeg store problemer, da produktionen blev opgraderet. Du kan besøge mine blogindlæg i midten af oktober til midten af december for at se nogle af disse problemer. Jeg var meget tæt på at nedgradere denne database, men det lykkedes mig at løse problemerne i stedet for. Nu tilbage til det punkt, jeg gjorde...
Når opgraderingen er fuldført, åbnes databasen for erhvervslivet. Applikationsbrugere har nu tilladelse til at bruge applikationen. Hvad sker der inde i databasen på dette tidspunkt? Transaktioner! Og transaktioner betyder dataændringer. På det tidspunkt, hvor DBA åbner databasen for erhvervslivet, efter at en opgradering er fuldført, begynder dataændringer at forekomme. Efter alt dette er det hele pointen med databasen, er det ikke? Indfang dataændringer og gør data tilgængelige for applikationens slutbrugere.
Så hvad sker der, hvis du er i den båd, jeg var sidste efterår med min databaseopgradering? Jeg ramte ting, som vi ikke så i ikke-produktion, selv efter alle vores tests. påvirkningen til virksomheden var HØJ. Jeg har brug for at være i stand til at reducere denne indvirkning på virksomheden. Jeg havde tre muligheder. 1) Løs problemerne én efter én. 2) Gendan fra den backup jeg tog før opgraderingen, så jeg kunne få databasen tilbage til den gamle version. 3) Nedgrader databasen og gå tilbage til tegnebrættet. Jeg valgte den første mulighed. som jeg altid har gjort i min karriere. Men hvad hvis det ikke var tilstrækkeligt? Det kan tage tid at løse problemerne. Nogle virksomheder har simpelthen ikke råd til den slags tid med den negative påvirkning til virksomheden. Hvor mange websteder er blevet forladt, fordi ydeevnen var forfærdelig, eller tingene ikke fungerede korrekt? Og for det store flertal af produktionsdatabaser derude har mulighed 2 en meget forfærdelig virkning til forretningen! Du mister transaktioner, efter at opgraderingen er fuldført! DBA'en vil ikke være i stand til at rulle videre forbi opgraderingen, mens databasen bevares i den gamle version, så data vil gå tabt, og for mange produktionsdatabaser er dette uacceptabelt. Virksomheden har muligvis råd til en times tab af data, men hvor mange mennesker ville trække aftrækkeren på denne handling inden for en time efter opgraderingen? Efter al sandsynlighed vil denne handling blive udført dage efter opgraderingen og påvirkningen til virksomheden for den slags datatab er langt over MEGET HØJ. Så det efterlader mulighed 3 som den mulighed med den laveste påvirkning til virksomheden for at hjælpe med at løse de konsekvenser, virksomheden oplever efter opgraderingen.
Du kan sikkert se fra det sidste afsnit, at jeg føler, at det er vigtigt for Oracle DBA at vide, hvordan man nedgraderer deres database, efter en opgradering er fuldført. Jeg indrømmer, at sandsynligheden af DBA'ens behov for at udføre en nedgradering er MEGET LAVT. Men virkningen ikke at nedgradere kan være katastrofalt for virksomheden. (Der er de to ord igen). Fordi sandsynligheden er lav, praktiserer jeg ikke nedgraderinger ofte, men fordi påvirkningen af ikke at være i stand til at nedgradere er meget høj, jeg øver dem en gang imellem.
Så afslutningsvis vil jeg gå tilbage til Murphys lov-ting igen. Universet konspirerer ikke imod mig, men som Data Guardian skal jeg praktisere gode risikostyringsprincipper. Det betyder at vurdere sandsynligheden for og virkningen af risikoelementer, som min ændring pålægger. Selvom universet og guderne måske ikke får Murphys lov eller dens fætre i gang, vil jeg ikke gøre mig selv nogen tjeneste ved at afbøde risikoelementer. Jeg reducerer ikke sandsynligheden en smule.