Ovaj je članak prvi u nizu članaka “Kako preuzeti kontrolu nad svojom mrežnom infrastrukturom.” Sadržaj svih članaka u seriji i poveznice možete pronaći .
Potpuno priznajem da postoji dovoljan broj tvrtki kojima prekid mreže od sat vremena ili čak jedan dan nije kritičan. Nažalost ili na sreću, nisam imao priliku raditi na takvim mjestima. No, naravno, mreže su različite, zahtjevi su drugačiji, pristupi su drugačiji, a opet, u ovom ili onom obliku, popis u nastavku će u mnogim slučajevima zapravo biti "must-do".
Dakle, početni uvjeti.
Na novom ste poslu, napredovali ste ili ste odlučili iznova sagledati svoje odgovornosti. Mreža tvrtke je vaše područje odgovornosti. Za vas je ovo u mnogočemu izazov i novost, što donekle opravdava mentorski ton ovog članka :). Ali nadam se da članak može biti koristan i svakom mrežnom inženjeru.
Vaš prvi strateški cilj je naučiti se oduprijeti entropiji i održati razinu pružene usluge.
Mnogi od dolje opisanih problema mogu se riješiti na različite načine. Namjerno ne pokrećem temu tehničke izvedbe, jer... u principu, često nije toliko važno kako si riješio ovaj ili onaj problem, već je bitno kako ga koristiš i da li ga uopće koristiš. Na primjer, vaš profesionalno izgrađen sustav nadzora je od male koristi ako ga ne pogledate i ne odgovorite na upozorenja.
Оборудование
Prvo morate shvatiti gdje su najveći rizici.
Opet, može biti drugačije. Priznajem da će to negdje, primjerice, biti sigurnosna pitanja, negdje pitanja vezana uz kontinuitet usluge, a negdje možda nešto drugo. Zašto ne?
Pretpostavimo, da bude jasno, da je to još uvijek kontinuitet usluge (to je bio slučaj u svim tvrtkama u kojima sam radio).
Zatim morate početi s opremom. Evo popisa tema na koje treba obratiti pozornost:
- klasifikacija opreme prema stupnju kritičnosti
- sigurnosna kopija kritične opreme
- podrška, licence
Morate razmisliti o mogućim scenarijima neuspjeha, posebno s opremom koja je na vrhu vaše klasifikacije kritičnosti. Obično se zanemaruje mogućnost dvostrukih problema jer u protivnom vaše rješenje i podrška mogu postati neopravdano skupi, ali u slučaju doista kritičnih mrežnih elemenata čiji bi kvarovi mogli značajno utjecati na poslovanje, o tome treba razmisliti.
Primjer
Recimo da govorimo o root switchu u podatkovnom centru.
Budući da smo se složili da je kontinuitet usluge najvažniji kriterij, razumno je osigurati “hot” backup (redundanciju) ove opreme. Ali to nije sve. Također morate odlučiti koliko je dugo, ako se prvi prekidač pokvari, prihvatljivo da živite sa samo jednim preostalim prekidačem, jer postoji rizik da će se i on pokvariti.
Važno! Ne morate sami odlučiti o ovom pitanju. Upravi ili upravi tvrtke morate opisati rizike, moguća rješenja i troškove. Oni moraju donositi odluke.
Dakle, ako je odlučeno da je, s obzirom na malu vjerojatnost dvostrukog kvara, rad od 4 sata na jednom prekidaču načelno prihvatljiv, tada možete jednostavno uzeti odgovarajuću podršku (prema kojoj će oprema biti zamijenjena unutar 4 sati).
Ali postoji rizik da neće isporučiti. Nažalost, jednom smo se našli u takvoj situaciji. Umjesto četiri sata, oprema je putovala tjedan dana!!!
Stoga o ovom riziku također treba razgovarati i možda bi bilo ispravnije kupiti još jedan prekidač (treći) i držati ga u paketu rezervnih dijelova ("hladna" rezerva) ili ga koristiti u laboratorijske svrhe.
Važno! Napravite proračunsku tablicu sve podrške koju imate s datumima isteka i dodajte je u svoj kalendar kako biste barem mjesec dana unaprijed dobili e-poruku da biste trebali početi brinuti o obnavljanju podrške.
Neće vam biti oprošteno ako zaboravite obnoviti svoju podršku i dan nakon njenog završetka vaš hardver stane.
Hitni rad
Što god se dogodilo na vašoj mreži, idealno bi bilo da zadržite pristup mrežnoj opremi.
Važno! Morate imati konzolni pristup svoj opremi i taj pristup ne bi trebao ovisiti o ispravnosti korisničke podatkovne mreže.
Također biste trebali unaprijed predvidjeti moguće negativne scenarije i dokumentirati potrebne radnje. Dostupnost ovog dokumenta također je kritična, stoga ga ne treba samo objaviti na zajedničkom resursu za odjel, već i spremiti lokalno na računala inženjera.
Mora biti
- informacije potrebne za otvaranje tiketa s podrškom dobavljača ili integratora
- informacije kako doći do bilo koje opreme (konzola, upravljanje)
Naravno, može sadržavati i bilo koju drugu korisnu informaciju, na primjer, opis postupka nadogradnje različite opreme i korisne dijagnostičke naredbe.
Povezana
Sada morate procijeniti rizike povezane s partnerima. Obično ovo
- Internet provideri i točke razmjene prometa (IX)
- pružatelji komunikacijskih kanala
Koja si pitanja trebate postaviti? Kao i kod opreme, moraju se uzeti u obzir različiti scenariji za hitne slučajeve. Na primjer, za pružatelje internetskih usluga, to bi moglo biti nešto poput:
- što se događa ako vam pružatelj internetskih usluga X prestane pružati uslugu iz nekog razloga?
- Hoće li drugi pružatelji imati dovoljnu propusnost za vas?
- Koliko će dobra povezanost ostati?
- Koliko su vaši internet provajderi neovisni i hoće li ozbiljan prekid jednog od njih uzrokovati probleme ostalima?
- koliko optičkih ulaza u vaš podatkovni centar?
- što će se dogoditi ako se jedan od ulaza potpuno uništi?
Što se tiče inputa, u mojoj praksi u dvije različite tvrtke, u dva različita podatkovna centra, bager je uništio bunare i samo čudom naša optika nije bila pogođena. Ovo i nije tako rijedak slučaj.
I, naravno, ne trebate samo postavljati ova pitanja, već, opet, uz podršku menadžmenta, pružiti prihvatljivo rješenje u svakoj situaciji.
Sigurnosna kopija
Sljedeći prioritet može biti sigurnosna kopija konfiguracije opreme. U svakom slučaju, ovo je vrlo važna točka. Neću navoditi one slučajeve kada možete izgubiti konfiguraciju, bolje je napraviti redovite sigurnosne kopije i ne razmišljati o tome. Osim toga, redovito sigurnosno kopiranje može biti vrlo korisno u praćenju promjena.
Važno! Svakodnevno pravite sigurnosne kopije. Ovo nije tako velika količina podataka da bi se na tome štedjelo. Ujutro bi dežurni inženjer (ili vi) trebali dobiti izvještaj od sustava u kojem je jasno naznačeno da li je backup bio uspješan ili ne, a ako je backup bio neuspješan treba riješiti problem ili kreirati tiket ( vidi procese mrežnog odjela).
Verzije softvera
Pitanje isplati li se ili ne nadograditi softver opreme nije tako jasno. S jedne strane, stare verzije su poznati bugovi i ranjivosti, ali s druge strane, novi softver je, prvo, nije uvijek bezbolan postupak nadogradnje, a drugo, novi bugovi i ranjivosti.
Ovdje morate pronaći najbolju opciju. Nekoliko očitih preporuka
- instalirajte samo stabilne verzije
- Ipak, ne biste trebali živjeti na jako starim verzijama softvera
- napraviti znak s informacijama o tome gdje se neki softver nalazi
- povremeno pročitajte izvješća o ranjivostima i greškama u verzijama softvera, au slučaju kritičnih problema razmislite o nadogradnji
U ovoj fazi, s konzolnim pristupom opremi, informacijama o podršci i opisom postupka nadogradnje, u načelu ste spremni za ovaj korak. Idealna opcija je kada imate laboratorijsku opremu u kojoj možete provjeriti cijeli postupak, ali to se, nažalost, ne događa često.
U slučaju kritične opreme, možete kontaktirati podršku dobavljača sa zahtjevom da vam pomogne s nadogradnjom.
Tiket sustav
Sada možete pogledati okolo. Morate uspostaviti procese za interakciju s drugim odjelima i unutar odjela.
Ovo možda nije potrebno (na primjer, ako je vaša tvrtka mala), ali toplo bih preporučio organizaciju posla na takav način da svi vanjski i interni zadaci prolaze kroz sustav ulaznica.
Sustav ulaznica je u biti vaše sučelje za unutarnju i vanjsku komunikaciju i trebali biste to sučelje opisati dovoljno detaljno.
Uzmimo primjer važnog i uobičajenog zadatka otvaranja pristupa. Opisat ću algoritam koji je savršeno radio u jednoj od tvrtki.
Primjer
Počnimo s činjenicom da korisnici pristupa često formuliraju svoje želje na jeziku nerazumljivom mrežnom inženjeru, naime, na jeziku aplikacije, na primjer, "dajte mi pristup 1C."
Stoga nikada nismo prihvaćali zahtjeve izravno od takvih korisnika.
I to je bio prvi uvjet
- zahtjevi za pristup trebaju doći iz tehničkih odjela (u našem slučaju to su bili unix, windows, inženjeri službe za pomoć)
Drugi zahtjev je taj
- ovaj pristup mora biti evidentiran (od strane tehničkog odjela od kojeg smo primili ovaj zahtjev) i kao zahtjev dobivamo poveznicu na ovaj prijavljeni pristup
Forma ovog zahtjeva mora nam biti razumljiva, tj.
- zahtjev mora sadržavati informacije o tome kojoj podmreži i kojoj podmreži pristup treba biti otvoren, kao i protokol i (u slučaju tcp/udp) portove
Tamo također treba biti naznačeno
- opis zašto je ovaj pristup otvoren
- privremeno ili trajno (ako je privremeno, do kojeg datuma)
I vrlo važna točka su odobrenja
- od voditelja odjela koji je inicirao pristup (npr. računovodstvo)
- od voditelja tehničkog odjela, odakle je ovaj zahtjev došao u mrežni odjel (na primjer, helpdesk)
U ovom slučaju, “vlasnikom” ovog pristupa smatra se voditelj odjela koji je inicirao pristup (računovodstvo u našem primjeru) i on je odgovoran za to da stranica s evidentiranim pristupom za ovaj odjel ostane ažurna .
Sječa drva
Ovo je nešto u čemu se možete utopiti. Ali ako želite primijeniti proaktivan pristup, tada morate naučiti kako se nositi s ovom poplavom podataka.
Evo nekoliko praktičnih preporuka:
- morate svakodnevno pregledavati zapisnike
- u slučaju planiranog pregleda (a ne hitne situacije), možete se ograničiti na razine ozbiljnosti 0, 1, 2 i dodati odabrane uzorke s drugih razina ako smatrate potrebnim
- napišite skriptu koja analizira zapise i zanemaruje one zapise čije ste uzorke dodali na popis za zanemarivanje
Ovakav pristup omogućit će vam da s vremenom napravite popis zanemarenih zapisa koji vam nisu zanimljivi i ostavite samo one koje doista smatrate važnima.
Nama je super uspjelo.
nadgledanje
Nije neuobičajeno da tvrtka nema sustav nadzora. Možete se, na primjer, osloniti na zapise, ali oprema može jednostavno "umrijeti" bez vremena da bilo što "kaže", ili se paket protokola udp syslog može izgubiti i ne stići. Općenito, naravno, aktivno praćenje je važno i potrebno.
Dva najpopularnija primjera u mojoj praksi:
- praćenje opterećenja komunikacijskih kanala, kritičnih veza (na primjer, povezivanje s pružateljima). Omogućuju vam proaktivno sagledavanje potencijalnog problema degradacije usluge zbog gubitka prometa i, sukladno tome, njegovo izbjegavanje.
- grafovi temeljeni na NetFlowu. Olakšavaju pronalaženje anomalija u prometu i vrlo su korisni za otkrivanje nekih jednostavnih, ali značajnih vrsta hakerskih napada.
Važno! Postavite SMS obavijesti za najkritičnije događaje. Ovo se odnosi i na praćenje i na bilježenje. Ako nemate dežurstva, onda sms treba stići i izvan radnog vremena.
Razmislite o procesu na takav način da ne probudite sve inženjere. Za to smo imali dežurnog inženjera.
Promjena kontrole
Po mom mišljenju, nije potrebno kontrolirati sve promjene. Ali, u svakom slučaju, trebali biste moći, ako je potrebno, lako pronaći tko je napravio određene promjene na mreži i zašto.
Nekoliko savjeta:
- koristite sustav ulaznica za detalje što je učinjeno na toj ulaznici, na primjer kopiranjem primijenjene konfiguracije u kartu
- koristiti mogućnosti komentiranja na mrežnoj opremi (na primjer, predati komentar na Juniperu). Možete zapisati broj karte
- koristite diff svojih sigurnosnih kopija konfiguracije
Ovo možete implementirati kao proces, svakodnevno pregledavajući sve ulaznice radi promjena.
procesi
Morate formalizirati i opisati procese u svom timu. Ako ste došli do ove točke, tada bi vaš tim već trebao pokrenuti barem sljedeće procese:
Dnevni procesi:
- rad s ulaznicama
- rad s trupcima
- kontrola promjena
- dnevni kontrolni list
Godišnji procesi:
- produženje jamstava, licenci
Asinkroni procesi:
- odgovor na razne izvanredne situacije
Zaključak prvog dijela
Jeste li primijetili da se sve ovo još ne odnosi na konfiguraciju mreže, ne na dizajn, ne na mrežne protokole, ne na usmjeravanje, ne na sigurnost... Nešto je okolo. Ali to su, iako možda dosadni, dakako vrlo važni elementi rada mrežnog odjela.
Do sada, kao što vidite, niste ništa poboljšali u svojoj mreži. Ako je bilo sigurnosnih propusta, onda su ostali; ako je postojao loš dizajn, onda je ostao. Sve dok ne primijenite svoje vještine i znanja mrežnog inženjera, na što ste najvjerojatnije potrošili dosta vremena, truda, a ponekad i novca. Ali prvo morate stvoriti (ili ojačati) temelje, a zatim početi graditi.
Sljedeći dijelovi će vam reći kako pronaći i ukloniti pogreške, a zatim poboljšati svoju infrastrukturu.
Naravno, ne morate raditi sve redom. Vrijeme može biti kritično. Učinite to paralelno ako resursi dopuštaju.
I važan dodatak. Komunicirajte, pitajte, savjetujte se sa svojim timom. Na kraju krajeva, oni su ti koji sve ovo podržavaju i rade.
Izvor: www.habr.com