Tento článek je první v sérii článků „Jak převzít kontrolu nad síťovou infrastrukturou“. Obsah všech článků v sérii a odkazy naleznete .
Sice předpokládám, že existuje dostatečné množství společností, kde jednoduchá síť na hodinu nebo dokonce jeden den není kritická. Mně, bohužel nebo naštěstí, se nikdy nepodařilo pracovat v takových místech. Ale samozřejmě, sítě jsou různé, požadavky různé, přístupy jsou různé, a přesto v mnoha případech bude níže uvedený seznam prakticky nutný.
Takže počáteční podmínky.
Nyní jste na novém pracovním místě, nebo jste dostali povýšení, nebo chcete nově nahlédnout na své povinnosti. Síť společnosti je vaší zónou odpovědnosti. Pro vás je to do značné míry výzva a nové, což do jisté míry omlouvá mentorský tón tohoto článku :). Ale doufám, že článek může být užitečný i jakémukoli síťovému inženýrovi.
Vaším prvním strategickým cílem je naučit se čelit entropii a udržet úroveň poskytovaných služeb.
Mnohé níže uvedené úkoly mohou být vyřešeny různými prostředky. Záměrně nenaznačuji technickou realizaci, protože často není tak důležité, jak jste vyřešili daný úkol, ale důležité je, jak tímto způsobem využíváte a zda vůbec používáte. Je zbytečné mít například profesionálně vybudovaný systém monitorování, pokud se na něj nedíváte a nereagujete na upozornění.
Hardware
Nejprve musíte pochopit, kde jsou největší rizika.
Znovu platí, že to může být různé. Předpokládám, že někde by to mohly být otázky zabezpečení, jinde otázky spojené s kontinuitou služby, nebo možná něco jiného. Proč ne?
Předpokládejme pro konkrétnost, že to přece jen je kontinuita služby (tak tomu bylo ve všech společnostech, kde jsem pracoval).
Pak je nutné začít s vybavením. Zde je seznam témat, na která byste se měli zaměřit:
- klasifikace vybavení podle úrovně kritičnosti
- zálohování kritického vybavení
- podpora, licence
Musíte zvážit možné varianty poruch, zejména u zařízení, které je na vrcholu vaší kritičnosti. Obvykle je opomíjena pravděpodobnost dvojitých problémů, jinak by vaše řešení a podpora mohla být neoprávněně drahá, ale v případě skutečně kritických prvků sítě, jejichž selhání by mohlo zásadně ovlivnit podnikání, byste o tom měli také přemýšlet.
Příklad
Předpokládejme, že mluvíme o kořenovém switchi v datovém centru.
Protože jsme se dohodli, že kontinuita služby je nejdůležitějším kriteriem, je rozumné zajistit 'horké' zálohování (redundanci) tohoto zařízení. Ale to není vše. Musíte také určit, jak dlouho, v případě poruchy prvního switche, je pro vás přijatelné žít pouze s jedním zbývajícím switchem, protože existuje riziko, že i ten selže.
Důležité! Tento problém byste neměli řešit sami. Musíte popsat rizika, možná řešení a náklady vašemu vedení nebo vedení firmy. Rozhodnutí by mělo učinit ono.
Pokud tedy bylo rozhodnuto, že za předpokladu malé pravděpodobnosti dvojité poruchy je práce po dobu 4 hodin na jednom switchi v zásadě přijatelná, můžete jednoduše zvolit odpovídající podporu (která zajistí, že zařízení bude vyměněno do 4 hodin).
Ale existuje riziko, že nedodají. Bohužel, jednou jsme se ocitli v takové situaci. Místo čtyř hodin zařízení jelo týden!!!
Proto je potřeba toto riziko také diskutovat a možná by pro vás bylo rozumnější zakoupit další switch (třetí) a držet ho v záloze ('studenná' redundance) nebo použít pro laboratorní účely.
Důležité! Sestavte tabulku všech podpor, které máte, s daty vypršení platnosti a přidejte je do kalendáře, aby vám minimálně měsíc předem přišlo upozornění, že byste se měli začít obávat o prodloužení podpory.
Neprominou vám, pokud zapomenete prodloužit podporu, a druhý den po jejím vypršení vám selže zařízení.
Nouzové práce
Ať se stane cokoliv ve vaší síti, ideálně byste měli zachovat přístup k vašemu síťovému zařízení.
Důležité! Musíte mít konzolový přístup ke všemu zařízení a tento přístup nesmí záviset na funkčnosti sítě pro přenos uživatelských dat.
Také byste měli předem zvážit možné negativní scénáře a zdokumentovat nezbytné akce. Dostupnost tohoto dokumentu je také kritická, proto by měl být nejen umístěn na veřejně přístupném zdroji v oddělení, ale také uložen lokálně na počítačích inženýrů.
Povinně by tam měly být
- informace potřebné pro otevření žádosti o podporu u dodavatele nebo integrátora
- informace, jak se dostat k jakémukoli zařízení (konzolový, manažerský)
Také samozřejmě může obsahovat jakékoli další užitečné informace, například popis postupu upgradu různých zařízení a užitečné diagnostické příkazy.
Partneři
Nyní musíte posoudit rizika spojená s partnery. Obvykle to jsou
- internetoví poskytovatelé a místa výměny provozu (IX)
- poskytovatelé komunikačních kanálů
Jaké otázky byste si měli klást? Stejně jako v případě zařízení, měli byste zvážit různé možnosti havarijních situací. Například pro internetové poskytovatele by to mohlo být něco jako:
- co se stane, pokud internetový poskytovatel X z nějakého důvodu přestane poskytovat služby?
- bude vám stačit šířka pásma ostatních poskytovatelů?
- jak dobrá zůstane konektivita?
- jak nezávislí jsou vaši internetoví poskytovatelé a nezpůsobí vážná havárie jednoho z nich problémy s ostatními?
- kolik optických vstupů má váš datový centrum?
- co se stane, pokud bude jeden z vstupů zcela zničen?
Pokud jde o vstupy, v mé praxi ve dvou různých společnostech, v dvou různých datacentrech bagrech zničil studny a jen zázrakem naše optika nebyla zasažena. Není to tak vzácný případ.
A samozřejmě, je třeba nejen tyto otázky položit, ale opět, s podporou vedení, zajistit přijatelné řešení v jakékoli situaci.
Záloha
Další prioritou může být záloha konfigurací zařízení. V každém případě je to velmi důležitý aspekt. Nebudu vypisovat situace, kdy můžete ztratit konfiguraci, lepší je provádět zálohy pravidelně a o tom vůbec nepřemýšlet. Kromě toho může pravidelná záloha být velmi užitečná při kontrole změn.
Důležité! Vytvářejte zálohu denně. Není to tak velký objem dat, abyste na tom šetřili. Ráno by měl pověřený inženýr (nebo vy) dostávat zprávu od systému, která jasně uvádí, zda byla záloha úspěšná nebo neúspěšná, a v případě neúspěšné zálohy by měl být problém vyřešen nebo by měl být vytvořen tiket (viz procesy síťového oddělení).
Verze softwaru
Otázka, zda provádět upgrade softwaru hardwaru, není jednoznačná. Na jedné straně staré verze obsahují známé chyby a zranitelnosti, ale na druhé straně nový software není vždy bezproblémový proces upgradu a navíc přináší nové chyby a zranitelnosti.
Je třeba najít optimální variantu. Několik zřejmých doporučení
- instalujte pouze stabilní verze
- přesto není dobré žít na úplně starých verzích softwaru
- sestavte tabulku s informacemi, kde jaký software je nainstalován
- pravidelně čtěte zprávy o zranitelnostech a chybách v verzích softwaru a v případě kritických problémů zvažte upgrade
V této fázi, s konzolovým přístupem k zařízení, informacemi o podpoře a popisem postupu upgradu, jste v zásadě připraveni na tento krok. Ideální je, když máte laboratorní zařízení, kde můžete otestovat celý postup, ale bohužel to není časté.
V případě kritického zařízení se můžete obrátit na podporu dodavatele s žádostí o pomoc při provádění upgradu.
Tiketový systém
Nyní se můžete rozhlédnout kolem. Musíte nastavit procesy interakce s jinými odděleními a uvnitř oddělení.
Možná to není povinné (například pokud je vaše firma malá), ale velmi doporučuji organizovat práci tak, aby všechny externí a interní úkoly procházely tiketovým systémem.
Tiketový systém je v podstatě váš rozhraní pro interní a externí komunikaci a měli byste dostatečně detailně popsat toto rozhraní.
Pojďme si pro příklad vzít důležitý a často se vyskytující úkol otevření přístupu. Popíšu algoritmus, který výborně fungoval v jedné z firem.
Příklad
Začneme s tím, že často klienti formulují svá přání nepochopitelným jazykem pro síťového inženýra, konkrétně jazykem aplikace, například: „otevřete mi přístup do 1C“.
Proto nikdy nepřijímáme žádosti přímo od takových uživatelů.
A to bylo první požadavek.
- Žádosti o poskytnutí přístupů musí přicházet od technických oddělení (v našem případě to byli unix, windows a helpdesk inženýři).
Druhým požadavkem je, že
- tento přístup musí být zdokumentován (technickým oddělením, od kterého jsme obdrželi tuto žádost) a jako žádost dostaneme odkaz na tento zdokumentovaný přístup.
Forma této žádosti by měla být nám jasná, tedy
- žádost by měla obsahovat informace o tom, z jaké a do jaké podsítě by měl být přístup otevřen, stejně jako o protokolu a (v případě tcp/udp) portech.
Také by mělo být uvedeno
- popis pro co je tento přístup otevírán,
- dočasný nebo trvalý (pokud je dočasný, tak do jakého data).
A velmi důležitý bod jsou schválení
- od vedoucího oddělení, které iniciovalo přístup (například účetnictví),
- od vedoucího technického oddělení, odkud tato žádost přišla do síťového oddělení (například helpdesk).
Přitom "majitelem" tohoto přístupu je vedoucí oddělení, které přístup iniciovalo (účetnictví v našem příkladu), a je zodpovědný za to, aby stránka se zdokumentovanými přístupy pro toto oddělení zůstala aktuální.
Logování
To je něco, v čem se můžete utopit. Ale pokud chcete implementovat proaktivní přístup, musíte se naučit vyrovnat se s tímto tokem dat.
Zde je několik praktických doporučení:
- logy je třeba kontrolovat denně.
- v případě plánovaného prohlížení (a nikoli havarijní situace) se může omezit na úrovně závažnosti (severity) 0, 1, 2 a přidat vybrané vzory z jiných úrovní, pokud to považujete za nutné.
- napište skript, který parsuje logy a ignoruje ty logy, jejichž vzory jste přidali do ignorovacího seznamu.
Tento přístup vám v průběhu času umožní sestavit ignorovací seznam logů, které vás nezajímají, a ponechat pouze ty, které považujete za opravdu důležité.
U nás to výborně fungovalo.
Monitoring
Není neobvyklé, když ve společnosti chybí systém monitorování. Můžete například spoléhat na protokoly, ale zařízení může jednoduše "zemřít", aniž by se stačilo "vyjádřit", nebo se může ztratit UDP paket protokolu syslog a nedorazit. Obecně platí, že aktivní monitorování je důležité a potřebné.
Dva nejžádanější příklady z mé praxe:
- monitorování zatížení komunikačních kanálů, kritických spojení (například připojení k poskytovatelům). Umožňují proaktivně vidět potenciální problém degradace služby kvůli ztrátě provozu a tím se mu vyhnout.
- grafy, vytvořené na základě NetFlow. Umožňují snadno nalézt anomálie v provozu a jsou velmi užitečné při odhalování některých jednoduchých, ale zásadních typů hackerských útoků.
Důležité! Nastavte SMS oznámení pro nejkritičtější události. Týká se to jak monitorování, tak logování. Pokud nemáte pohotovostní směnu, SMS by měly také chodit i po pracovní době.
Promyslete proces tak, aby nebudil všechny inženýry. U nás pro to byl pohotovostní inženýr.
Kontrola změn
Podle mého názoru není nutné kontrolovat všechny změny. Ale v každém případě byste měli mít možnost snadno zjistit, kdo a proč provedl určité změny v síti, pokud je to potřeba.
Několik tipů:
- používejte ticketový systém pro podrobné popisování toho, co bylo uděláno v rámci tohoto ticketu, například kopírováním aplikované konfigurace do ticketu
- využijte možnosti komentářů na síťovém zařízení (například commit comment na Juniper). Můžete zapsat číslo ticketu
- používejte diff vašich záloh konfigurací
Můžete to zavést jako proces, když každý den prohlížíte všechny tickety na změny.
Procesy
Musíte formalizovat a popsat procesy ve vašem týmu. Pokud jste se dostali až sem, ve vašem týmu by již měly fungovat minimálně následující procesy:
Denní procesy:
- práce s tickety
- práce s logy
- kontrola změn
- denní checklist
Roční procesy:
- prodloužení záruk, licencí
Asynchronní procesy:
- reakce na různé nouzové situace
Závěr první části
Nějak jste si nevšimli, že tohle všechno není o konfiguraci sítě, designu, síťových protokolech, routování ani bezpečnosti... Je to něco kolem. Ačkoliv to může být nudné, jsou to samozřejmě velmi důležité prvky fungování síťového oddělení.
Zatím, jak vidíte, jste ve své síti nic nevylepšili. Pokud existovaly bezpečnostní zranitelnosti, zůstaly tam, pokud byl design špatný, zůstal špatný. Dokud neuplatníte své dovednosti a znalosti síťového inženýra, na které pravděpodobně padlo velké množství času, úsilí a někdy i peněz. Ale nejprve je třeba vytvořit (nebo posílit) základ, a pak se teprve pustit do stavby.
O tom, jak hledat a odstraňovat chyby, a posléze zlepšovat vaši infrastrukturu – o tom budou následující části.
Samozřejmě není nutné dělat vše postupně. Čas může být kritický. Dělejte to paralelně, pokud to zdroje dovolí.
A důležité upozornění. Komunikujte, ptejte se, poraďte se se svým týmem. Koneckonců, oni to všechno budou udržovat a dělat.
Zdroj: habr.com
