techone --pruvodce=sprava-cloudu
Jak nastavit správu cloudu a serverů
Správa funguje, když má každé upozornění, změna i incident svého vlastníka. Před převzetím prostředí proto vyjasníme odpovědnosti, eskalace a oprávnění k zásahům.
Ve zkratce
- Co zmapovat
- Systémy, závislosti, vlastníky, přístupy, dokumentaci, kritičnost a známá provozní rizika.
- Co dohodnout
- Rozsah odpovědnosti, dobu pokrytí, závažnost incidentů, eskalace a oprávnění ke změnám.
- Jak pracovat s monitoringem
- Každé důležité upozornění potřebuje hranici, prioritu, vlastníka a navazující postup.
- Co musí obsahovat předání
- Ověřené přístupy, aktuální dokumentaci, otevřená rizika a potvrzené rozdělení provozních rolí.
- Rozsah převzetí
- Můžeme převzít celé prostředí, infrastrukturu pod aplikací nebo vybranou část provozu vedle interního týmu.
Začněte mapou systémů a odpovědností
Před převzetím správy je potřeba vědět, co firma skutečně provozuje a na čem jednotlivé služby závisejí. Seznam serverů nebo cloudových prostředků nestačí. Provoz může ovlivnit databáze, síť, identity, certifikáty, externí rozhraní i aplikace spravovaná jiným dodavatelem.
Ke každé důležité části prostředí přiřaďte vlastníka. Musí být jasné, kdo rozhoduje o změně, kdo ověřuje dopad incidentu a kdo komunikuje stav uživatelům nebo vedení.
Systémy a závislosti
Sepište produkční služby, databáze, úložiště, síťové vazby, identity, certifikáty, integrační body a externí dodavatele. U každé položky určete, které procesy na ní závisejí.
Kritičnost provozu
Rozlište, co může počkat do pracovního dne a co zastaví objednávky, výrobu nebo práci uživatelů. Kritičnost určuje potřebné pokrytí, eskalaci i způsob obnovy.
Přístupy a oprávnění
Ověřte administrátorské účty, servisní identity, nouzové přístupy a způsob jejich předávání. U každého účtu zaznamenejte vlastníka a použití, aby přístupy zůstaly dohledatelné.
Dokumentace a otevřená rizika
Zaznamenejte současnou architekturu, provozní postupy, známé výjimky a nevyřešené problémy. Výsledkem má být společná mapa prostředí, ne několik oddělených seznamů.
Mapa prostředí určuje rozsah správy. Bez ní se odpovědnost snadno rozdělí podle technologií, ale některé závislosti zůstanou bez vlastníka.
Co musí obsahovat provozní model
Provozní model nemusí být dlouhý. Musí však u každé důležité oblasti určit vlastníka, rozhodovací pravomoc a výstup, podle kterého lze postup zpětně doložit.
| Oblast | Co musí být určeno | Jaký výstup má vzniknout |
|---|---|---|
| Monitoring | Sledované signály, hranice, závažnost a vlastník | Seznam upozornění a navazujících reakcí |
| Incidenty | Doba pokrytí, klasifikace, kontakty a eskalace | Incidentní postup a smluvené SLA |
| Změny a aktualizace | Schválení, servisní okno, ověření a návrat | Dohledatelný záznam každé změny |
| Zálohy a obnova | Chráněná data, přijatelná ztráta a doba obnovy | Zálohovací a obnovovací plán |
| Dokumentace | Místo uložení, vlastník a způsob aktualizace | Aktuální provozní dokumentace dostupná klientovi |
posuňte pro zobrazení celé tabulky
Monitoring musí vést ke konkrétní reakci
Monitoring může sledovat dostupnost, výkon, kapacitu, latenci, chybovost, stav certifikátů nebo průběh záloh. Je užitečný ve chvíli, kdy tým pozná stav vyžadující zásah a má domluvený další krok.
Reakční doba vychází ze závažnosti incidentu, doby pokrytí a smluveného SLA. Stejná metrika může mít jinou hranici a prioritu v účetním systému a jinou u veřejné aplikace.
Upozornění má jasný účel
U každé metriky stanovte, jaký problém má odhalit, kdy má upozornění vzniknout a kdo ho převezme. Bez vlastníka se z alertu stává další nepřečtená zpráva.
Dopad se nejdřív ověří
Překročená hranice ještě nemusí znamenat výpadek. První krok ověří skutečný stav služby, dotčené uživatele a související změny.
Zásah má určené oprávnění
Provozní postup rozlišuje, co může správce provést ihned, co vyžaduje schválení a kdy se zapojuje dodavatel aplikace nebo interní tým.
Výsledek zůstane dohledatelný
Záznam incidentu obsahuje příčinu, provedený zásah, výsledek a případný další úkol. Opakovaný problém se tak neřeší pokaždé od začátku.
Změny, aktualizace a dokumentace patří do jednoho režimu
Aktualizace operačního systému, databáze nebo aplikace může odstranit bezpečnostní riziko a současně ovlivnit kompatibilitu. Proto se neřídí jedním univerzálním kalendářem. Rozhoduje závažnost opravy, podporovaná verze, závislosti a dostupné servisní okno.
Stejný postup platí pro změnu konfigurace, velikosti prostředku nebo síťového pravidla. Každá změna potřebuje důvod, rozsah, schválení, způsob ověření a přiměřený plán návratu.
Plánované změny
Změna se připraví s očekávaným dopadem, termínem a odpovědnou osobou. U kritického systému se předem určí i způsob návratu.
Naléhavé zásahy
Pro mimořádnou situaci stanovte, kdo může zasáhnout bez předchozího schválení a kdo musí být informován. Po stabilizaci se zásah doplní do evidence.
Pravidelné kontroly
Kontrolní plán může zahrnout aktualizace, konfiguraci, kapacitu, certifikáty, stav záloh a otevřená rizika. Frekvence vychází z kritičnosti a rychlosti změn prostředí.
Předatelná dokumentace
Dokumentace zůstává přístupná klientovi a průběžně se upravuje podle skutečného stavu. Musí pomoci při incidentu, auditu i budoucím předání.
Zálohy a obnova se navrhují společně
Nejdřív určete, která data a konfigurace je potřeba chránit, jaká ztráta je přijatelná a jak rychle musí být daná služba obnovená. Teprve z těchto požadavků vychází frekvence záloh, doba uchování, umístění kopií a rozsah ověřování obnovy.
Úspěšně dokončený zálohovací úkol potvrzuje vytvoření kopie. Nepotvrzuje, že obsahuje všechna potřebná data ani že z ní tým dokáže obnovit službu v požadovaném čase.
Rozsah chráněných dat
Vedle databáze mohou být pro obnovu nutné soubory, konfigurace, tajné klíče, integrační nastavení nebo infrastruktura popsaná jako kód.
Uchování a umístění kopií
Retence a oddělení kopií vycházejí z provozních, bezpečnostních, právních a auditních požadavků konkrétního systému.
Postup obnovy
Dokument stanoví pořadí kroků, potřebné přístupy, odpovědné osoby a způsob ověření výsledku. Musí počítat i se závislostmi na dalších službách.
Ověření podle kritičnosti
Rozsah a frekvence ověření mohou sahat od obnovy vybraných dat po kontrolu celého provozního scénáře. Volba patří do dohodnutého plánu.
Jak prostředí přebíráme
Převzetí začínáme kontrolou skutečného stavu prostředí. Ověříme systémy, závislosti, přístupy a dokumentaci. Na základě toho připravíme provozní model a převezmeme oprávnění k dohodnutým zásahům.
Zmapujeme prostředí
Sepíšeme systémy, závislosti, vlastníky, dodavatele, kritičnost a otevřená provozní rizika.
Ověříme přístupy a dokumentaci
Prověříme administrátorské a nouzové přístupy, dostupnost záloh, architekturu a používané provozní postupy.
Rozdělíme odpovědnost
S klientem určíme dobu pokrytí, klasifikaci incidentů, eskalace, oprávnění ke změnám a hranice mezi zapojenými týmy.
Nastavíme kontroly a reakce
Upravíme monitoring, kontrolní plán, změnový režim a postupy zálohování a obnovy podle skutečného prostředí.
Převezmeme dohodnutý provoz
Při řízeném předání ověříme s dosavadním správcem provozní postupy a otevřené úkoly. Potom převezmeme dohodnuté role, oprávnění a odpovědnosti.
Jakou část provozu můžeme převzít
Můžeme převzít celé prostředí, jen infrastrukturu pod aplikací nebo vybrané provozní činnosti vedle interního týmu. Rozsah určíme podle rolí a znalostí, které už jsou spolehlivě pokryté.
Dlouhodobá správa
Převezmeme průběžnou odpovědnost za monitoring, incidenty, změny a pravidelné kontroly v dohodnutém režimu.
Spolupráce s interním týmem
Převezmeme vybranou platformu, dobu pokrytí nebo odbornou oblast. Provozní model přesně určí předávání incidentů a změn mezi týmy.
Vstupní audit a náprava
Samostatný audit zmapuje stav a rizika. Na jeho závěry může navázat náprava prostředí nebo doplnění konkrétní odbornosti přes projektový tým.
Návaznost po migraci
Po dokončené migraci do cloudu převezmeme dohodnutou část provozu a navážeme na znalosti získané během projektu.
Dlouhodobý provoz systému Helvetia
U systému Helvetia jsme po přepisu a migraci do Azure pokračovali provozní podporou, monitoringem, upozorňováním na problémy, optimalizací výkonu a dalším rozvojem pro sedm trhů. Dlouhodobá odpovědnost tak navázala přímo na předání řešení.
Často kladené otázky
Co musí být připravené před převzetím správy?
Potřebujeme seznam systémů a závislostí, jejich vlastníky, dostupnou dokumentaci, administrátorské přístupy, současný monitoring, stav záloh a přehled otevřených rizik. Pokud některý podklad chybí, doplní se během vstupního mapování. Rozdělení odpovědnosti se potvrdí před převzetím operativních zásahů.
Lze rozdělit odpovědnost mezi interní a externí tým?
Ano. Můžeme převzít vybranou platformu, infrastrukturu pod aplikací, pravidelné kontroly nebo určitou dobu pokrytí. Provozní model musí přesně určit hranice, eskalace a způsob předávání incidentů a změn mezi týmy.
Jak se určuje frekvence kontrol?
Podle kritičnosti systému, rychlosti změn prostředí, požadavků na aktualizace a rizik, která je potřeba sledovat. Některé signály se vyhodnocují průběžně, jiné v dohodnutém intervalu. Jedna měsíční frekvence proto není vhodná pro každou oblast.
Jak se stanoví reakční doba na incident?
Vychází ze závažnosti incidentu, požadované doby pokrytí, komunikačního a eskalačního postupu a smluveného SLA. Konkrétní reakční časy lze určit až po zmapování prostředí a provozních požadavků.
Jak se ověřují zálohy a obnova?
Pro každý systém se určí chráněná data, přijatelná ztráta, požadovaná doba obnovy a odpovědné osoby. Podle toho vznikne plán záloh a ověřování obnovy. Rozsah může být od obnovy vybraných dat po kontrolu celého provozního scénáře.
Jak se určuje rozsah a cena správy?
Rozhoduje počet a členitost systémů, jejich závislosti, požadovaná doba pokrytí, rozsah pravidelných kontrol, reakční model a oprávnění k provádění změn. Po vstupním zmapování připravíme konkrétní rozsah odpovědnosti a nabídku.
Související témata
Správa cloudu a infrastruktury
Převzetí prostředí, monitoring, správa změn, zálohy a provozní podpora.
Migrace do cloudu (průvodce)
Jak zvolit způsob migrace podle aplikace, dat, závislostí a provozních požadavků.
Migrace aplikací do cloudu
Analýza prostředí, cílová architektura, přesun dat a řízený přechod do provozu.
Převezmeme dohodnutou část provozu.
Na úvodní konzultaci projdeme prostředí, závislosti a současné role. Potom připravíme provozní model a rozsah převzetí.