Toto je objekt systému MBI.

MBI (Management Byznys Informatiky) je portál obsahující zobecněná řešení v řízení provozu a rozvoje IT, resp. podnikové informatiky.

Pokud máte zájem získat více informací o tomto objektu (vazby na další objekty, přílohy, apod.), ale i získat mnoho dalších užitečných materiálů, můžete tak učinit ZDE / (registrace je bezplatná).

Úloha : Řízení uvolnění a nasazení
Řízení uvolnění a nasazení
Kód úlohy

Standardní kód úlohy v MBI.

:
U736A
Autor návrhu úlohy

Jméno a příjmení autora úlohy

:
Lízner, T. (KIT, VŠE)
Předpokládaná pravděpodobnost užití v praxi

Předpokládaná pravděpodobnost užití úlohy v praxi, hodnoty 0 - 1. Např. 0,7 - úlohu lze využít v 7 z 10 podniků. Hodnoty jsou průběžně testovány a upřesňovány na základě anket a průzkumů.

:
0.8
Charakteristiky úlohy

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.