U736A : Řízení uvolnění a nasazení

Kód úlohy:

U736A

Autor návrhu úlohy:

Lízner, T. (KIT, VŠE)

Datum poslední úpravy:

2012-12-19

Předpokládaná pravděpodobnost užití v praxi:

0.8

Charakteristiky úlohy

1. “Řízení uvolnění a nasazení“ – cíl, účel

Úloha navazuje na úlohu Řízení změn , ze které přebírá jako vstup protokol změnových řízení . Účel této úlohy spočívá ve standardizovaném přístupu k řízení uvolnění a nasazení nové verze SW / nového SW s důrazem na klíčové činnosti , které se nesmí opomenout, pokud má být uvolnění a nasazení úspěšné.
Cílem úlohy je:
- minimalizovat negativní dopady a rizika nasazení nové verze do produkčního prostředí,
- minimalizovat čas a náklady potřebné na změnu nových verzí v produkčním prostředí,
- úspěšně uvolnit a nasadit nové verze SW napoprvé.

2. Obsah úlohy

Úloha pokrývá komplex činností spojených s přípravou a realizací uvolnění a nasazení nové verze SW / nového SW do produkčního prostředí. Uvolnění představuje dle (ISO/IEC 20000-1, 3.23) soubor jedné nebo více konfiguračních položek , které jsou nasazovány do provozu jako výsledek jedné nebo více změn.
V rámci úlohy :
- stanovují se pravidla pro plánování uvolnění nových verzí,
- odkazy na již vyřešené žádosti o změny, chyby a problémy při jejich řešení,
- pravidla pro testování změn,
analyzují se incidenty spojené s uvolněním a nasazením změn,
- definují se i pravidla pro řešení neúspěšného uvolnění a nasazení změn.
V rámci řešení úlohy je třeba řešit tyto otázky:
- jaké služby a nové verze budou uvolněny, z čeho se skládají a jaké jsou na ně požadavky,
- kteří uživatelé jsou ovlivněni nasazením, zda potřebují nějaké další speciální školení,
- zda existují nějaké odstávky z provozu nebo jiné přerušení běžné činnosti a jakou úroveň detailu je třeba řešit, např. budova, patro, místnost,
- zda všichni uživatelé a systémy jsou z jednoho místa, nebo jsou vzdálení a jaký to má vliv na logistiku,
- potřebují zaměstnanci service-desku školení, existují přístupové problémy, které je třeba řešit,
- termín nasazení nové verze,
- důvod pro nasazení – řešení problému, implementace nové funkcionality,
- kritické faktory úspěchu nasazení, kdo ho povoluje.
Zvolení metody postupu nasazení je zásadní . Nasazení může být provedeno buď najednou na všechny potřebné systémy v době, kdy se s nimi nepracuje (typicky přes víkend), nebo postupně (např. dočasná současná práce v novém a starém SW). Obecně je metoda typu „Velkého třesku“ zvládnutelnější pro menší instituce, kde není taková hrozba případných nekonzistencí při chybném zavedení na některé z poboček.
U institucí, které mají více poboček, pro zajištění, že všechny koncové stanice mají stejnou verzi, lze využít programových utilit pro správu verzí (tzv. agenty), které mohou buď informovat správce aplikací o zastaralé verzi na konkrétní stanici, nebo mohou samy aplikace provést kontrolu verze na serveru a uživatele vybídnout k aktualizaci, která se poté stáhne ze serveru a nainstaluje (pouze pokud je takto aplikace naprogramována a mají uživatelé dostatečná oprávnění).
Pokud bude instalace prováděna správcem aplikací, nejčastěji se tak děje přes připojení na vzdálenou plochu – není tedy nutno fyzicky navštěvovat příslušné pobočky.
Dalším úkolem je plán migrace dat . Pokud to nasazení nové verze SW / nového SW vyžaduje, je potřeba naplánovat, kdy dojde k migraci stávajících dat do nových databázových systémů jak pro testovací prostředí, tak zároveň kdy se bude realizovat migrace dat pro produkční prostředí.

3. Vstupy úlohy:

Katalog požadavků na IT (D042A ),
Katalog IT služeb (D111A ),
Dokumentace provozu service-desku (D723A ),
RFC, požadavek na změnu (D725A ),
Návrh na změnu kontraktu a SLA (D726A ),
Provozní dokumentace (D711A ),
Technická dokumentace sítě (D712A),
Aplikační architektura (D053A ),
Technologická architektura (D054A ),
Analýza stavu technologické infrastruktury (D233A ),
Plán rozvoje technologické infrastruktury (D235A ).

4. Výstupy úlohy:

Aplikační architektura (D053A ), aktualizovaný,
Technologická architektura (D054A ), aktualizovaný,
Katalog IT služeb (D111A ), aktualizovaný,
Plán rozvoje technologické infrastruktury (D235A ), aktualizovaný.

5. Podmínky úspěšnosti úlohy

Pravidelné provádění automatizovaných regresních testů sníží náklady na pracovníky a napomůže včas odhalit nově vzniklé chyby po provedených úpravách,
Existence service-desk nebo úlohy řízení uživatelských požadavků,
Existence definovaných procesů pro vykonávání konkrétních standardních změn (např. postup s odpovědnostmi za obnovu hesla),
Součástí každé změny by měl být plán její nápravy v případě neúspěchu, podrobnost tohoto plánu závisí na povaze změny (zásadní změna by měla mít plán velmi podrobný, zatímco rutinní stačí hrubý nástin řešení),
Je nezbytné veškeré změny dokumentovat. Není žádoucí, aby znalosti o změnách byly vázány na konkrétní osoby.

6. Doporučené praktiky

Zaměstnanci příslušného uživatelského oddělení a operativních skupin IT musejí být v souladu s definovaným implementačním plánem řádně proškoleni a informováni dříve, než dojde k nasazení do provozního prostředí.
Definovat a vytvořit bezpečné testovací prostředí zastupující plánované provozní prostředí. Definovat vztahy k bezpečnosti, vnitřním kontrolám a provozním praktikám.
Plán konverze a migrace dat a infrastruktury , včetně kontrolních záznamů, rollback a fallback akcí.
Testování změn před samotnou migrací do provozního prostředí. Je potřeba se ujistit, že aplikace odpovídá požadované bezpečnosti, stabilitě a výkonu.
Je potřeba se ujistit, že výsledky procesu testování odpovídají požadavkům tak, jak jsou stanoveny v testovacím plánu. Také je nutno ověřit pomocí sady regresních testů, že dříve objevené závažné chyby jsou odstraněny.
Po testování a předání změněného systému do provozu musí být systém stále v souladu s realizačním plánem . Dále je nutné získat schválení klíčových zainteresovaných stran, jako jsou uživatelé, systémoví vlastníci a operativní management. V případě potřeby, je možné na chvíli systém provozovat paralelně se starým systémem a porovnat jejich chování a výsledky.
Cílem regresního testování je zajistit, aby změny software, jako je přidávání nových funkcí, nebo úpravy stávajících funkcí, neovlivnily nepříznivě funkcionalitu ostatních částí aplikace (aplikací), na které změny nemají mít vliv.
Spojení Integračních i systémových testů je označována jako fáze SIT – System Integration Tests . Po ověření správné integrace aplikace na ostatní systémy nastává ten pravý čas na systémové testování. Během těchto testů je aplikace ověřována jako funkční celek.

7. “Řízení uvolnění a nasazení“ - klíčové aktivity

7.1. Definice plánu nasazení s migračními pokyny a hodnocením po zavedení

Tato činnost je nejvíce komplexní a je jedna z nejdůležitějších . Uvolnění a nasazení nové verze SW / nového SW musí být dopředu důkladně naplánováno .
Cílem je mít naplánováno co, kdy a jak se bude realizovat. To v sobě zahrnuje:
- stanovení data Go-Live (datum ostrého nasazení do provozu),
- datum pro nasazení do testovacího prostředí (kopie reálného prostředí pro testování),
- zvolení metody postupu nasazení (Big Bang, Phased roll-out…),
- plán migrace dat ze stávajících systémů,
- analýza dopadu na ostatní systémy (aplikace, servery, infrastruktura apod.),
- zavedení metrik pro zpětnou vazbu.

7.2. Definice plánu testování

Než se přejde na nasazení do reálného prostředí, je nutno novou verzi SW / nový SW plně otestovat v testovacím prostředí, které plně odpovídá prostředí produkčnímu. Tím se předejde neuváženému nasazení, které by mohlo obsahovat nějaké chyby. V tomto prostředí je nutno otestovat bezproblémovou funkcionalitu aplikace a její případnou integraci s ostatními systémy. Definice plánu testování obsahuje :
- Stanovení oblastí pro otestování a jejich priorit (které části a funkcionality aplikace je nutno otestovat),
- Stanovení typů a četností testů (automatizované regresní testy, testy SIT, manuální testy,…).
Testuje se integrace aplikace v prostředí, které plně odpovídá reálnému provoznímu prostředí , neřeší se vzhled sestav, texty chybových hlášení, testy UAT apod. (tyto testy musejí být provedeny už během a v závěru fáze vývoje aplikace).

7.3. Definování pravidel pro případ řešení neúspěšného uvolnění a nasazení změn (Roll Back)

Může se stát, že i přes všechnu snahu se nová verze SW/ nový SW nepovede nasadit podle plánu . Z tohoto důvodu je nutné definovat pro tuto situaci postupy .
Jednou z možností je (pokud to lze) provoz starého a nového systému současně do té doby, než se chyby odstraní . Je však potřeba zajistit datovou integritu .
Další možnost je odstavení nového systému a dočasné pokračování na stabilní verzi současného SW.

7.4. Příprava testovacího prostředí

Příprava testovacího prostředí v sobě zahrnuje všechny činnosti nutné k jeho přípravě pro nasazení, jako jsou:
- zajištění HW prostředků (servery apod.),
- instalace ZSW a jiného SW nutného pro běh nové verze SW / nového SW,
- instalace testovacích databází (pokud je vyžadováno),
- integrace do interní sítě organizace (propojení s intranetem, zpřístupnění přes internet, propojení s jinými servery… – pouze pokud je vyžadováno).

7.5. Nasazení do testovacího prostředí

Jakmile je připraveno testovací prostředí, nainstaluje se na něj nová verze SW / nový SW, která je určena k nasazení. Poté je potřeba zajistit propojení s databází a migrovat do databáze testovací data odpovídající datům z produkčního prostředí (pokud je vyžadováno) a provést jiná nezbytná nastavení, která uvedou novou verzi SW / nový SW do stavu, který odpovídá stavu finálnímu pro reálné prostředí.

7.6. Testování

Testování nové verze v testovacím prostředí s reálnými daty. Testování probíhá dle definovaného plánu z bodu 3.
V případě, že d ojde k nějakému incidentu a jsou nalezeny závažné chyby , je nutno tento incident zaevidovat a vyřešit. Po vyřešení a opravě chyby je nutno provést opětovné otestování .

7.7. Příprava provozního prostředí, nasazení do produkčního prostředí

Pokud proběhne testování na testovacím prostředí v pořádku a je odsouhlaseno nasazení do produkčního prostředí, další fází je samotné nasazení nové verze SW /nového SW do produkčního prostředí podle definovaného plánu nasazení z bodu 1. Pokud to lze, často se z testovacího prostředí stane prostředí produkční (např. u aplikací, ke kterým se přistupuje skrz webový prohlížeč, či přes jiného tenkého klienta). Definují se práva a přístupy pro současné zaměstnance, zablokují se přístupy pro testování a koncové stanice se nakonfigurují na tuto změnu.

7.8. Analýza po nasazení

Součástí analýzy je kontrola všech koncových stanic, kterých se změna týká.
Dále se během provozu nové verze můžou objevit různé odchylky, rizika apod. Ty je potřeba a nalyzovat, zadokumentovat a tyto nedostatky (pokud je třeba) odstranit a aplikovat pravidla pro neúspěšné nasazení uvedené v bodě 3. V této fázi také dochází k vyhodnocení metrik.