Účastnil jsem se nedávného vlákna na komunitě OTN, kde se někdo ptal na downgrade po upgradu databáze. Jedna z odpovědí se ptala, kolik lidí skutečně provádí downgrade databáze. Vytvořil jsem toto hlasování, abych to zjistil.
Překvapilo mě, že jsem našel jeden příspěvek do tohoto vlákna, který říkal:
Ten plakát to výslovně neříkal, ale bylo to skoro, jako by ten jedinec říkal, že praktikování downgradu je ztráta času, protože to nikdy nebude potřebovat. Dám plakátu výhodu pochybností a toho, že to tento zaměstnanec Oracle ve skutečnosti neřekl. Nesnažím se vybírat tohoto jedince. Nechám toto vlákno, aby mi poskytlo příležitost diskutovat o tématu z obecnějšího hlediska. (Aktualizace:Plakát, který mě vybídl k napsání tohoto příspěvku do blogu, se vrátil do vlákna za dobu, kterou jsem to napsal, a řekl:„Nechtělo to naznačovat, že bychom neměli ‚testovat‘ downgrady.“ )
V červenci jsem napsal blogový příspěvek o The Data Guardian. V tomto příspěvku na blogu jsem řekl:
DBA potřebuje chránit data. To je práce číslo 1. Úloha č. 2 je pro DBA poskytovat efektivní a včasný přístup k datům. K čemu je dobré mít data, když lidé, kteří k nim potřebují přístup, se k datům nedostanou? Pokud mají tito lidé hrozný výkon při interakci s daty, pak by také nemuseli mít žádný přístup.
Jako DBA musíme provádět řízení rizik. Musíme určit, jaká rizika se mohou stát realitou. Úkolem DBA je měřit tato rizika a stanovit dva akční plány. Jaké kroky lze podniknout, aby se toto riziko nestalo realitou, a jaké kroky musím podniknout, abych problém vyřešil, až se toto riziko stane realitou?
Dokonce i DBA na nižší úrovni pochopí důležitost zálohování. Zálohy jsou strategií řízení rizik. Pokud dojde ke ztrátě dat, můžeme je obnovit ze zálohy. A dokonce i DBA na nižší úrovni chápe důležitost možnosti obnovy ze zálohy.
V tomto vlákně OTN jsem napsal toto:
Pro mě je to něco jako Murphyho zákony. V minulosti jsem říkal podobné věci. Myšlenka (a celý smysl tohoto příspěvku na blogu) je taková, že pokud nepodniknu vhodné kroky k řízení rizik, pak jen žádám bohy, aby toto riziko proměnili ve skutečnost. Pokud si odmítnu seřídit zpětné zrcátko a použít ho, když couvám s autem, je to den, kdy se do něčeho vrátím. Když si odmítnu zavázat tkaničky, tak to je den, kdy na jednu šlápnu a zakopnu. Den, kdy odmítnu nosit ochranné brýle při používání elektrického nářadí, je den, kdy se mi něco dostane do oka. Den, kdy půjdu na pláž a odmítnu se namazat opalovacím krémem, je den, kdy se vrátím domů s úpalem. Máte nápad.
Někteří čtenáři si mohou myslet, že jsem blázen a že vesmír nemá tento mistrovský plán, který by se mnou zahýbal jen proto, že jsem spokojený. A souhlasil bych. Takže to řeknu jinak, pokud neplánuji zmírnit riziko, pak jsem neudělal nic, aby se to nestalo realitou. Šance, že se to stane skutečností, se kvůli mé nečinnosti nesnižují.
Řízení rizik má dvě hlavní složky. 1) určení pravděpodobnosti výskytu dané rizikové položky a 2) určení dopadu, když k tomuto riziku dojde. Položky, které mají nejvyšší pravděpodobnost se nejprve zmírní. To je snadné a často to dělá mnoho lidí pracujících na řízení rizik. Umístí rizikové položky do tabulky a vyplní nějakou hodnotu pravděpodobnosti výskytu tohoto rizika. Po dokončení se seřadí podle sloupce pravděpodobnosti a začnou se zmírňováním rizik shora dolů. Mnoho strategií řízení rizik nakreslí čáru někde uprostřed seznamu a rozhodne, že jakákoli riziková položka pod touto čárou má příliš nízkou pravděpodobnost, že se této rizikové položky nebudeme obávat. Nemůžeme zmírnit všechna možná rizika ve vesmíru. Prostě není dost času to všechno zvládnout. Takže musíme někde nakreslit čáru.
Jedním z nedostatků, které neustále vidím, je to, že řízení rizik nevěnuje mnoho času soustředění se na dopad že se toto riziko stane realitou. Tabulka musí obsahovat podobný sloupec poskytující hodnocení dopadu dané rizikové položky na podnik. Správce rizik musí seřadit tabulku také v tomto sloupci. Všechny položky, které mají velký dopad, musí mít aktivity ke zmírnění rizika, i když je pravděpodobnost výskytu u této položky nízká! Je smutné, že příliš mnoho lidí v oblasti řízení rizik nezahrnuje tento krok hodnocení dopadu rizik. Opět, když je tabulka seřazena podle dopadu na firmu, někde se nakreslí čára.
Možná zjistíte, že rizikové položky s VYSOKOU pravděpodobností mají NÍZKÝ nebo dokonce VELMI NÍZKÝ dopad do podnikání. Líbí se mi tabulky pro řízení rizik, které obsahují třetí sloupec „pravděpodobnost x dopad“. Tento sloupec pomáhá pochopit vztah mezi dvěma rizikovými složkami.
Vraťme se k otázce upgradu databáze, která vyvolala tento blogový příspěvek. Myslím, že každý, kdo čte tento článek na blogu, by měl souhlasit s tím, že upgrade databáze Oracle je riskantní. Existuje tolik různých věcí, které se mohou pokazit při upgradu databáze Oracle. pravděpodobnost selhání upgradu je VYSOKÁ. Položky zmírnění rizik často zahrnují, ale nejsou omezeny na, nácvik upgradu na produkčních klonech a zálohování databáze před zahájením procesu upgradu. Proč to děláme? Tedy dopad k podnikání je VELMI VYSOKÉ. Pokud při upgradu naší produkční databáze selžeme, naši firemní uživatelé nemají k datům přístup. Nejsme moc dobrý ochránce dat, pokud nedokážeme překonat toto selhání. Pokud upgrade dostatečně nacvičíme v neprodukčních prostředích, můžeme snížit pravděpodobnost rizikové položky na STŘEDNÍ. Ale se vší pravděpodobností nemůžeme snížit pravděpodobnost konkrétního rizika na NÍZKOU. Proto před zahájením upgradu provedeme zálohu. Problémy by měly přetrvávat, i když jsme udělali maximum pro snížení pravděpodobnosti této rizikové položky, dopad k podnikání je stále VELMI VYSOKÉ. Strategie nápravy rizik DBA je tedy dělat si poznámky, kde a co způsobilo selhání upgradu, a obnovit ze zálohy. Databáze je v provozu a eliminovali jsme dopad do podnikání. DBA se poté vrátí k rýsovacímu prknu, aby zjistil, jak vyřešit, co se pokazilo. DBA se snaží snížit pravděpodobnost že se tento problém objeví znovu, když se později vrátí, aby provedli proces upgradu znovu.
Vraťme se tedy ke komentáři ve vláknu OTN, kde se zdálo, že procvičování downgradů databáze nestojí za čas. Nesouhlasím. A můj nesouhlas má vše společného s dopadem do podnikání. Souhlasím s komentářem, který autor uvedl ve své odpovědi.
S tím 100% souhlasím. Proč provádíme toto „důkladné testování“? To vše kvůli zmírnění rizik. Snažíme se snížit pravděpodobnost že upgrade způsobí špatný výkon nebo způsobí přerušení funkčnosti aplikace. Ale i když plakát říkal:„Vždy se po upgradu objeví problémy, které se objeví ve výrobě, protože není možné otestovat 100 % vaší aplikace.“ Opět 100% souhlasím s tím, co zde tento plakát říká. Ale co ten dopad do podnikání? Dostanu se k tomu za minutu, ale nejdřív musím trochu odbočit v tomto dalším odstavci…
Nedávno jsem upgradoval důležitý produkční systém z 11.2.0.4 na verzi 12.1.0.2. Tam, kde pracuji, máme více testování aplikací, než jsem kdy viděl ve svých jiných zaměstnáních. Máme kompletní QA tým, který za nás testuje. Máme dokonce tým, který má na starosti naše automatizované testování. Máme automatizované roboty, které provádějí náš aplikační kód každou noc. Navíc k tomu všemu máme další automatizovanou rutinu, která vždy, když lidé zadají změny kódu do Test nebo Prod, tato rutina rychle prozkoumá kritické cesty kódu. Upgradoval jsem vývojová prostředí (více než 15 z nich) na 12.1.0.2 a pak jsem čekal jeden měsíc. Pak jsem upgradoval Test a čekal 3 týdny, než jsem upgradoval produkci. Než jsme upgradovali produkci, byly nalezeny a vyřešeny problémy. Ale i po tom všem jsem měl velké problémy, jakmile byla výroba upgradována. Některé z těchto problémů můžete navštívit od poloviny října do poloviny prosince na mém blogu. Byl jsem velmi blízko downgradu této databáze, ale místo toho se mi podařilo problémy vyřešit. Nyní zpět k tomu, co jsem dělal…
Po dokončení upgradu se databáze otevře pro podnikání. Uživatelé aplikace nyní mohou aplikaci používat. Co se v tomto okamžiku děje uvnitř databáze? Transakce! A transakce znamenají změny dat. V okamžiku, kdy správce databáze otevře databázi pro podnikání po dokončení upgradu, začnou docházet ke změnám dat. Po tom všem je to celý smysl databáze, ne? Zachyťte změny dat a zpřístupněte data koncovým uživatelům aplikace.
Co se tedy stane, když budete na lodi, kterou jsem byl loni na podzim s upgradem databáze? Narážel jsem na věci, které jsme v nevýrobě neviděli ani po všech našich testech. Dopad k podnikání byl VYSOKÝ. Potřebuji být schopen snížit tento dopad na podnikání. Měl jsem tři možnosti. 1) Opravte problémy, jeden po druhém. 2) Obnovit ze zálohy, kterou jsem pořídil před upgradem, abych mohl vrátit databázi zpět do staré verze. 3) Přejděte na nižší verzi databáze a vraťte se na kreslící prkno. Zvolil jsem první možnost. jako vždy během své kariéry. Ale co když to nestačilo? Vyřešení problémů může chvíli trvat. Některé firmy si takový čas s tímto negativním dopadem prostě nemohou dovolit do podnikání. Kolik webových stránek bylo opuštěno, protože výkon byl hrozný nebo věci nefungovaly správně? A pro velkou většinu produkčních databází má možnost 2 velmi hrozný dopad do obchodu! Po dokončení upgradu ztratíte transakce! DBA se nebude moci vrátit po upgradu a zároveň ponechat databázi ve staré verzi, takže data budou ztracena a pro mnoho produkčních databází je to nepřijatelné. Podnik si může dovolit jednu hodinu ztráty dat, ale kolik lidí by zmáčklo spoušť této akce do jedné hodiny po upgradu? S největší pravděpodobností by tato akce byla provedena několik dní po upgradu a dopadu pro tento druh ztráty dat je výrazně vyšší než VELMI VYSOKÉ. To ponechává možnost 3 jako možnost s nejnižším dopadem podniku, aby pomohl vyřešit jakékoli dopady, se kterými se podnik po upgradu potýká.
Z toho posledního odstavce pravděpodobně poznáte, že mám pocit, že je důležité, aby Oracle DBA věděl, jak po dokončení upgradu provést downgrade své databáze. Připouštím, že pravděpodobnost DBA, která potřebuje provést downgrade, je VELMI NÍZKÁ. Ale ten dopad nesnížení ratingu může být pro podnik katastrofální. (Opět jsou tu ta dvě slova). Protože pravděpodobnost je nízká, downgrady nepraktizuji často, ale kvůli dopadu neschopnost downgrade je velmi vysoká, jednou za čas je praktikuji.
Takže na závěr se znovu vrátím k té věci Murphyho zákona. Vesmír se proti mně nespikne, ale jako Data Guardian musím praktikovat dobré zásady řízení rizik. To znamená posouzení pravděpodobnosti a dopadu rizikových položek vyvolaných mou změnou. I když vesmír a bohové možná nepřinutí Murphyho zákon nebo jeho bratrance nastartovat, já se nesnažím zmírňovat rizikové položky. Nesnižuji pravděpodobnost ani o bit.