Tento článok je prvý v sérii článkov „Ako mať sieťovú infraštruktúru pod kontrolou“. Obsah všetkých článkov série a odkazy nájdete .
Celkom pripúšťam, že existuje dostatočné množstvo spoločností, kde jednoduchá sieť nie je kritická ani za hodinu ani za jeden deň. Mne, žiaľ alebo našťastie, sa nepodarilo pracovať v takýchto miestach. Ale určite sú siete rôzne, požiadavky rôzne, prístupy rôzne a predsa, v jednom alebo inom ohľade, nižšie uvedený zoznam bude vo veľa prípadoch prakticky „must-do“.
Takže, počiatočné podmienky.
Ste na novom pracovisku, alebo máte povýšenie, alebo ste sa rozhodli inak pozrieť na svoje povinnosti. Sieť spoločnosti – to je vaša zóna zodpovednosti. Pre vás je to v mnohých ohľadoch výzva a niečo nové, čo do značnej miery ospravedlňuje mentorujúci tón tohto článku :). Ale dúfam, že článok môže byť užitočný aj pre každého sieťového inžiniera.
Váš prvý strategický cieľ je naučiť sa odolávať entropii a udržiavať úroveň poskytovaných služieb.
Mnohé nižšie popísané úlohy môžu byť riešené rôznymi prostriedkami. Úmyselne sa nezameriavam na tému technickej realizácie, pretože vo väčšine prípadov nie je až tak dôležité, ako ste vyriešili danú úlohu, ale skôr to, ako to využívate a či to vôbec využívate. Málo osohu, napríklad, z vašej profesionálne vybudovanej monitorovacej sústavy, ak sa na ňu nedívate a nereagujete na upozornenia.
Zariadenie
Na začiatku musíte porozumieť, kde sú najväčšie riziká.
Opäť sa to môže líšiť. Pripúšťam, že niekde môžu byť otázky bezpečnosti, inde otázky súvisiace s pokračovaním služieb, a niekde, možno, niečo iné. Prečo nie?
Predpokladajme pre určenie, že to stále bude pokračovanie služieb (tak to bolo vo všetkých spoločnostiach, kde som pracoval).
Potom treba začať s hardvérom. Tu je zoznam tém, na ktoré sa treba zamerať:
- kategorizácia hardvéru podľa miery kritickosti
- zálohovanie kritického hardvéru
- podpora, licencie
Musíte zvážiť možné poruchy, najmä s hardvérom, ktorý patrí do najvyššej kategórie kritickosti. Zvyčajne sa prehliada pravdepodobnosť dvojitých problémov, inak môžu byť vaše riešenia a podpora zbytočne drahé, no v prípade naozaj kritických prvkov siete, ktorých výpadok môže mať značný vplyv na podnikanie, by ste o tom mali premýšľať.
Príklad
Predpokladajme, že hovoríme o hlavnom prepínači v dátovom centre.
Keďže sme sa dohodli, že kontinuita služby je najdôležitejším kritériom, rozumné je zabezpečiť „horúcu“ redundanciu tohto zariadenia. Ale to nie je všetko. Musíte tiež rozhodnúť, koľko času, v prípade poruchy prvého prepínača, je pre vás prijateľné fungovať len s jedným zostávajúcim prepínačom, veď existuje riziko, že aj ten sa pokazí.
Dôležité! Nemali by ste túto otázku riešiť sami. Musíte opísať riziká, možné riešenia a náklady svojmu vedeniu alebo vedeniu spoločnosti. Rozhodovať by mali oni.
Takže, ak bolo rozhodnuté, že pri malej pravdepodobnosti dvojitej poruchy je prevádzka na jednom prepínači počas 4 hodín v zásade prijateľná, môžete si jednoducho objednať príslušnú podporu (podľa ktorej bude zariadenie vymenené do 4 hodín).
Ale je tu riziko, že dodávka nebude. Bohužiaľ, raz sme sa ocitli v takej situácii. Namiesto štyroch hodín zariadenie cestovalo týždeň!!!
Preto je potrebné diskutovať aj o tomto riziku a, možno, pre vás bude rozumnejšie kúpiť ešte jeden prepínač (tretí) a mať ho v ZIP-e („studená“ redundancia) alebo ho používať na laboratórne účely.
Dôležité! Vypracujte tabuľku všetkých podpor, ktoré máte, s dátumami skončenia, a pridajte ich do kalendára, aby ste minimálne mesiac pred uplynutím dostali e-mail o tom, že by ste mali začať zháňať predĺženie podpory.
Neodpustia vám, ak zabudnete predĺžiť podporu a na druhý deň po jej skončení sa vaše zariadenie pokazí.
Havarijné práce
Nezáleží na tom, čo sa vo vašej sieti stane, ideálne by ste mali zachovať prístup k vášmu sieťovému zariadeniu.
Dôležité! Musíte mať konzolový prístup k celému vybaveniu a tento prístup nesmie závisieť od funkčnosti siete prenosu používateľských údajov (data).
Rovnako by ste mali vopred predpokladať možné negatívne scenáre a zdokumentovať potrebné kroky. Dostupnosť tohto dokumentu je tiež kritická, takže by mal byť nielen zverejnený na spoločnom zdroji oddelenia, ale mal by byť aj uložený lokálne na počítačoch inžinierov.
Povinne tam musia byť
- informácie potrebné na otvorenie žiadosti o podporu u dodávateľa alebo integrátora
- informácie o tom, ako sa dostať k akémukoľvek vybaveniu (konzola, správa)
Samozrejme, môže tam byť aj akékoľvek iné užitočné informácie, ako napríklad popis postupov aktualizácie rôzneho vybavenia a užitočné diagnostické príkazy.
Partneri
Teraz by ste mali zhodnotiť riziká spojené s partnermi. Zvyčajne sú to
- internetoví poskytovatelia a body výmeny prevádzky (IX)
- poskytovatelia komunikačných kanálov
Aké otázky si musíte položiť? Rovnako ako v prípade vybavenia je potrebné zvážiť rôzne varianty havarijných situácií. Napríklad pre internetových poskytovateľov, to môže byť niečo ako:
- čo sa stane, ak internetový poskytovateľ X z nejakého dôvodu prestane poskytovať služby?
- Bude vám stačiť šírka pásma ostatných poskytovateľov?
- Aká dobrá zostane konektivita?
- Akí nezávislí sú vaši internetoví poskytovatelia a spôsobí vážna havária jedného z nich problémy s ostatnými?
- Koľko optických vstupov má váš dátové centrum?
- Čo sa stane, ak bude jeden z vstupov úplne zničený?
Pokiaľ ide o vstupy, vo svojej praxi som v dvoch rôznych spoločnostiach zažil, že dátových centrách bager zničil šachty a len zázrakom naša optika ostala nenarušená. Nie je to až taký zriedkavý prípad.
A samozrejme, musíte si nielen položiť tieto otázky, ale, opäť s podporou vedenia, zabezpečiť akceptovateľné riešenie v každej situácii.
Zálohovanie
Nasledujúca priorita môže byť záloha konfigurácií vybavenia. V každom prípade je to veľmi dôležitý moment. Nebudem uvádzať prípady, keď môžete stratiť konfiguráciu, lepšie je pravidelne robiť zálohu a nemyslieť na to. Okrem toho môže byť pravidelná záloha veľmi užitočná pri kontrole zmien.
Dôležité! Robte každý deň zálohu. Nie je to tak veľký objem dát, aby ste na tom šetrili. Ráno by mal pohotovostný inžinier (alebo vy) dostávať správu od systému, ktorá jasne uvádza, či bola záloha úspešná alebo nie, a v prípade neúspešnej zálohy by sa mal problém vyriešiť alebo by mal byť vytvorený tiket (pozri procesy sieťového oddelenia).
Verzie softvéru
Otázka, či je potrebné vykonať upgrade softvéru zariadenia, nie je jednoznačná. Na jednej strane, staré verzie majú známe chyby a zraniteľnosti, ale na druhej strane, nový softvér je predovšetkým, nie vždy bezbolestný proces upgradu, a po druhé, nové chyby a zraniteľnosti.
Tu je potrebné nájsť optimálnu variantu. Niekoľko zrejmých odporúčaní:
- inštalujte iba stabilné verzie.
- je predsa len lepšie nemať úplne staré verzie softvéru.
- vytvorte tabuľku s informáciami, kde je aký softvér nainštalovaný.
- pravidelne čítajte správy o zraniteľnostiach a chybách vo verziách softvéru, a v prípade kritických problémov by ste mali zvážiť upgrade.
V tejto fáze, having console access to the equipment, information about support, and a description of the upgrade procedure, you are basically ready for this step. The ideal situation is when you have lab equipment where you can test the entire procedure, but unfortunately, such cases are rare.
V prípade kritického zariadenia sa môžete obrátiť na podporu dodávateľa s požiadavkou na pomoc pri vykonaní upgradu.
Ticketový systém
Teraz sa môžete obzrieť okolo seba. Musíte zorganizovať procesy interakcie s inými oddeleniami a v rámci vášho oddelenia.
Možno to nie je povinné (napríklad ak je vaša spoločnosť malá), ale veľmi by som odporúčal usporiadať prácu tak, aby všetky externé a interné úlohy prechádzali cez tiketový systém.
Tiketový systém je vlastne váš rozhranie pre internú a externú komunikáciu, a mali by ste s dostatočnou podrobnosťou opísať toto rozhranie.
Dajte sa ako príklad pozrieme na dôležitú a často sa vyskytujúcu úlohu otvárania prístupu. Opíšem algoritmus, ktorý výborne fungoval v jednej z firiem.
Príklad
Začneme tým, že zákazníci často formulujú svoje požiadavky nezrozumiteľným jazykom pre sieťových inžinierov, najmä jazykom aplikácií, napríklad „otvorte mi prístup do 1C“.
Preto nikdy neprijímame požiadavky priamo od takých používateľov.
A to bola prvá požiadavka.
- Požiadavky na poskytnutie prístupov by mali prichádzať od technických oddelení (v našom prípade to boli unix, windows, helpdesk inžinieri).
Druhá požiadavka je, že
- tento prístup musí byť zaevidovaný (technickým oddelením, od ktorého sme prijali túto požiadavku) a ako požiadavku dostávame odkaz na tento zaevidovaný prístup.
Forma tejto požiadavky by mala byť pre nás zrozumiteľná, to jest,
- požiadavka by mala obsahovať informácie o tom, z akej a do akej podsiete by mal byť prístup otvorený, ako aj o protokole a (v prípade tcp/udp) portoch.
Takisto by tam malo byť uvedené,
- popis, na čo sa tento prístup otvára,
- dočasný alebo trvalý (ak dočasný, tak do akého dátumu).
A veľmi dôležitý bod sú schválenia.
- od vedúceho oddelenia, ktoré iniciovalo prístup (napríklad účtovníctva),
- od vedúceho technického oddelenia, odkiaľ táto požiadavka prišla do sieťového oddelenia (napríklad helpdesk).
V tomto prípade je „vlastníkom“ tohto prístupu vedúci oddelenia, ktoré prístup iniciovalo (účtovníctvo v našom príklade), a je zodpovedný za to, aby stránka so zaevidovanými prístupmi pre toto oddelenie zostala aktuálna.
Logovanie
To je niečo, v čom sa dá utopiť. Ale ak chcete zaviesť proaktívny prístup, musíte sa naučiť zvládať tento tok dát.
Tu je niekoľko praktických odporúčaní:
- prezerajte logy každý deň.
- V prípade plánovaného prezerania (a nie havarijnej situácie) sa môžete obmedziť na úrovne kritickosti (severity) 0, 1, 2 a pridať obľúbené vzory z iných úrovní, ak to považujete za potrebné.
- Napíšte skript, ktorý analyzuje logy a ignoruje tie logy, ktorých vzory ste pridali do zoznamu ignorovaných.
Tento prístup časom umožní vytvoriť zoznam ignorovaných logov, ktoré vás nezaujímajú, a nechať len tie, ktoré považujete za naozaj dôležité.
U nás to skvele fungovalo.
Monitorovanie
Nie je nezvyčajné, keď v spoločnosti chýba systém monitorovania. Môžete sa napríklad spoliehať na logy, ale hardvér môže jednoducho „zomrieť“, aniž by stihol „povedať“ niečo, alebo môže dôjsť k strate udp paketov syslog protokolu a tieto sa nedostanú na cieľ. V každom prípade je aktívne monitorovanie dôležité a potrebné.
Dva najžiadanejšie príklady z mojej praxe:
- monitorovanie zaťaženia komunikačných kanálov, kritických liniek (napríklad pripojenie k poskytovateľom). Umožňujú proaktívne odhaliť potenciálny problém degradácie služby z dôvodu straty prevádzky a tým sa mu vyhnúť.
- grafy vytvorené na základe NetFlow. Umožňujú ľahko nájsť anomálie v prevádzke a sú veľmi užitočné pri odhaľovaní určitých jednoduchých, ale významných typov hackerských útokov.
Dôležité! Nastavte sms upozornenia pre najkritickejšie udalosti. To platí ako pre monitorovanie, tak aj pre logovanie. Ak nemáte pohotovostnú zmenu, mali by sms správy prichádzať aj mimo pracovného času.
Premyslite proces tak, aby nebudiť všetkých inžinierov. U nás bol na tento účel pohotovostný inžinier.
Kontrola zmien
Podľa môjho názoru nie je nevyhnutné kontrolovať všetky zmeny. No v každom prípade by ste mali mať možnosť ľahko zistiť, kto a prečo vykonal určité zmeny v sieti, ak to bude potrebné.
Niekoľko rád:
- použite ticketový systém na podrobné opísanie toho, čo bolo urobené v rámci tohto ticketa, napríklad skopírovaním použitej konfigurácie do ticketa
- využite možnosti komentárov na sieťovom zariadení (napríklad commit comment na Juniper). Môžete zaznamenať číslo ticketa
- využite diff záloh vašich konfigurácií
Môžete to zaradiť ako proces, každý deň prehliadajúc všetky tickety na zmeny.
Procesy
Musíte formalizovať a popísať procesy vo vašom tíme. Ak ste sa dostali do tejto fázy, vo vašom tíme by mali už fungovať aspoň nasledujúce procesy:
Denné procesy:
- práca s tiketmi
- práca s logmi
- kontrola zmien
- denný kontrolný zoznam
Ročné procesy:
- predlžovanie záruk, licencií
Asynchrónne procesy:
- reakcia na rôzne havarijné situácie
Zhrnutie prvej časti
Všimli ste si, že zatiaľ ide o niečo, čo sa netýka konfigurácie siete, dizajnu, sieťových protokolov, smerovania ani bezpečnosti... Je to niečo okolo. Ale sú to možno nudné, no určite veľmi dôležité prvky fungovania sieťového oddelenia.
Kým, ako vidíte, ste vo svojej sieti nič nezlepšili. Ak boli zraniteľnosti v bezpečnosti, tak zostali, ak bol zlý dizajn, tak ten zostal. Kým ste nevyužili svoje zručnosti a vedomosti sieťového inžiniera, na ktoré ste pravdepodobne vynaložili veľa času, úsilia a niekedy aj peňazí. Ale najprv je potrebné vytvoriť (alebo posilniť) základ a potom sa pustiť do výstavby.
O tom, ako hľadať a odstraňovať chyby, a potom aj zlepšovať vašu infraštruktúru – o tom budú nasledujúce časti.
Samozrejme, nie je potrebné všetko robiť postupne. Čas môže byť kritický. Robte to paralelne, ak to umožňujú zdroje.
A dôležitá poznámka. Komunikujte, pýtajte sa, radte sa so svojím tímom. Koniec koncov, práve oni to všetko budú podporovať a robiť.
Zdroj: habr.com
