Kontrolní seznam připravenosti na produkci

Překlad článku byl připraven speciálně pro studenty kurzu „DevOps praktiky a nástroje“, který začíná již dnes!

Kontrolní seznam připravenosti na produkci

Uvolnili jste někdy nový službu do produkce? Nebo se snad zabývali udržováním takových služeb? Pokud ano, podle čeho jste se řídili? Co je v produkci dobré, a co špatné? Jak školíte nové členy týmu o vydáních nebo údržbě stávajících služeb?

Většina společností dochází v oblasti praxe průmyslového nasazení k přístupům „Divokého západu“. Každý tým si pomocí pokusů a omylů sám určuje nástroje a nejlepší praxe. To však často ovlivňuje nejen úspěch projektů, ale i inženýry.

Metoda pokusů a omylů vytváří prostředí, ve kterém je běžné hledání vinníka a přenášení odpovědnosti. Při takovém chování se stále obtížněji učí na chybách a je těžší je neopakovat.

Úspěšné organizace:

  • uvědomují si potřebu směrnic pro produkci,
  • studují nejlepší praxe,
  • zahajují diskusi o otázkách připravenosti na produkci při vývoji nových systémů nebo komponentů,
  • zajišťují dodržování pravidel přípravy na produkci.

Příprava na produkci zahrnuje proces „revize“. Revize může mít formu kontrolního seznamu nebo souboru otázek. Revize lze provádět ručně, automaticky nebo oběma způsoby. Místo statických seznamů požadavků lze vytvořit šablony kontrolních seznamů, které se přizpůsobí konkrétním potřebám. Tímto způsobem mohou inženýři získat způsob, jak dědit znalosti a dostatečnou flexibilitu, když je to potřeba.

Kdy kontrolovat službu na připravenost na produkci?

Kontrolu připravenosti na produkci je užitečné provést nejen těsně před vydáním, ale také při předání jiné týmu pro údržbu nebo novému zaměstnanci.

Proveďte kontrolu, když:

  • Uvolňujete novou službu do produkce.
  • Předáváte údržbu produkční služby jinému týmu, jako je SRE.
  • Předáváte údržbu produkční služby novým zaměstnancům.
  • Organizujete technickou podporu.

Kontrolní seznam pro ověření připravenosti na produkci

Nedávno jsem jako příklad vytvořil publikovala kontrolní seznam pro ověření připravenosti na produkci. Ačkoli tento seznam vznikl při práci s klienty Google Cloud, bude užitečný a použitelný i mimo Google Cloud.

Návrh a vývoj

  • Vypracujte reprodukovatelný proces sestavení, který nevyžaduje přístup k externím službám a není závislý na selhání externích systémů.
  • Během návrhu a vývoje určete a stanovte SLO pro vaše služby.
  • Dokumentujte očekávání ohledně dostupnosti externích služeb, na kterých závisíte.
  • Vyhněte se jedinému bodu selhání odstraněním závislosti na jednom globálním zdroji. Replikujte zdroj nebo použijte alternativní možnost, pokud je zdroj nedostupný (např. pevně zakódovaná hodnota).

Správa konfigurace

  • Statickou, malou a nezákladní konfiguraci lze předávat prostřednictvím parametrů příkazového řádku. Pro vše ostatní používejte služby pro ukládání konfigurací.
  • Dynamická konfigurace by měla mít záložní nastavení pro případ, že služba konfigurace nebude dostupná.
  • Konfigurace vývojového prostředí by neměla být spojena s produkční konfigurací. Jinak by to mohlo vést k přístupu z vývojového prostředí k produkčním službám, což může způsobit problémy s ochranou soukromí a úniky dat.
  • Dokumentujte, co může být nastaveno dynamicky, a popište záložní chování, pokud bude systém dodání konfigurace nedostupný.

Správa verzí

  • Podrobně dokumentujte proces vydání. Popište, jak vydání ovlivňují SLO (např. dočasné zvýšení latence v důsledku chyb cache).
  • Dokumentujte kanárkové verze.
  • Vypracujte plán analýzy kanárkových verzí a, když je to možné, mechanismy automatického návratu zpět.
  • Ujistěte se, že zpětné návraty mohou používat stejné procesy jako nasazení.

Sledovatelnost (Observability)

  • Ujistěte se, že se shromažďuje soubor metrik nezbytných pro SLO.
  • Ujistěte se, že můžete rozlišovat mezi klientskými a serverovými daty. To je důležité pro hledání příčin poruch.
  • Nastavte upozornění, aby se snížily náklady na práci. Například odstraňte upozornění způsobená rutinními operacemi.
  • Pokud používáte Stackdriver, zapněte metriky platformy GCP ve svých přehledech. Nastavte upozornění pro závislosti na GCP.
  • Vždy šířte příchozí stopu. I když se neúčastníte sledování, to umožní nižším službám ladit problémy v produkci.

Ochrana a bezpečnost

  • Ujistěte se, že všechna externí připojení jsou šifrována.
  • Ujistěte se, že vaše produkční projekty mají správné nastavení IAM.
  • Používejte sítě k izolaci skupin virtuálních strojů.
  • Používejte VPN pro bezpečné připojení k vzdáleným sítím.
  • Dokumentujte a monitorujte přístup uživatelů k datům. Ujistěte se, že veškerý přístup uživatelů k datům je kontrolován a zaznamenáván.
  • Ujistěte se, že koncové body pro ladění jsou omezeny pomocí ACL.
  • Sanitizujte uživatelský vstup. Nastavte omezení velikosti zátěže pro uživatelský vstup.
  • Ujistěte se, že vaše služba může selektivně blokovat příchozí provoz pro jednotlivé uživatele. To umožní blokovat porušení, aniž by to ovlivnilo ostatní uživatele.
  • Vyhněte se externím koncovým bodům, které iniciují velké množství interních operací.

Plánování kapacity

  • Dokumentujte, jak se vaše služba škáluje. Například: počet uživatelů, velikost příchozí zátěže, počet příchozích zpráv.
  • Dokumentujte požadavky na zdroje pro vaši službu. Například: počet vyhrazených instancí virtuálních strojů, počet instancí Spanner, specializovaný hardware, jako je GPU nebo TPU.
  • Dokumentujte omezení zdrojů: typ zdroje, region atd.
  • Dokumentujte omezení kvót pro vytváření nových zdrojů. Například omezení počtu požadavků GCE API, pokud používáte API pro vytváření nových instancí.
  • Zvažte provedení zátěžových testů k analýze poklesu výkonu.

To je vše. Těšíme se na setkání na přednáškách!

Zdroj: habr.com

Koupit spolehlivý hosting pro webové stránky s ochranou proti DDoS, VPS VDS servery 🔥 Koupit spolehlivý hosting pro webové stránky s ochranou proti DDoS, VPS VDS servery | ProHoster