Kako preuzeti kontrolu nad vašom mrežnom infrastrukturom. Prvo poglavlje. Čekaj

Ovaj članak je prvi u nizu članaka “Kako preuzeti kontrolu nad svojom mrežnom infrastrukturom”. Sadržaj svih članaka u seriji i linkove možete pronaći ovdje.

U potpunosti priznajem da postoji dovoljan broj kompanija kod kojih zastoj 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. Ali, naravno, mreže su različite, zahtjevi su različiti, pristupi su različiti, a opet, u ovom ili onom obliku, lista ispod u mnogim slučajevima će zapravo biti „obavezna“.

Dakle, početni uslovi.

Nalazite se na novom poslu, dobili ste unapređenje ili ste odlučili da iznova pogledate svoje obaveze. Mreža kompanije je područje vaše odgovornosti. Za vas je ovo na mnogo načina 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 nivo pružene usluge.

Mnogi od dolje opisanih problema mogu se riješiti na različite načine. Namjerno ne pokrećem temu tehničke implementacije, jer... u principu, često nije toliko važno kako ste rešili ovaj ili onaj problem, već je važno kako ga koristite i da li ga uopšte koristite. Na primjer, vaš profesionalno izgrađen sistem za praćenje je od male koristi ako ga ne gledate i ne odgovarate na upozorenja.

Oprema

Prvo morate razumjeti gdje su najveći rizici.

Opet, može biti drugačije. Priznajem da će negdje, na primjer, to biti sigurnosna pitanja, a negdje pitanja vezana za kontinuitet službe, a negdje, možda, nešto drugo. Zašto ne?

Pretpostavimo, da bude jasno, da je to ipak kontinuitet usluge (tako je bilo u svim firmama u kojima sam radio).

Zatim morate početi s opremom. Evo liste tema na koje treba obratiti pažnju:

• klasifikacija opreme po stepenu kritičnosti
• backup kritične opreme
• podrška, licence

Morate razmisliti o mogućim scenarijima kvarova, posebno s opremom na vrhu vaše klasifikacije kritičnosti. Obično se zanemaruje mogućnost dvostrukih problema, inače vaše rješenje i podrška mogu postati neopravdano skupi, ali u slučaju zaista kritičnih mrežnih elemenata čiji bi kvar mogao značajno utjecati na poslovanje, razmislite o tome.

Primjer:

Recimo da govorimo o root prekidaču u data centru.

Pošto smo se složili da je kontinuitet servisa najvažniji kriterijum, razumno je obezbediti „hot“ backup (redundanciju) ove opreme. Ali to nije sve. Također morate odlučiti koliko dugo, ako se prvi prekidač pokvari, da li je prihvatljivo da živite samo sa jednim preostalim prekidačem, jer postoji rizik da će se i on pokvariti.

Bitan! Ne morate sami da odlučujete o ovom pitanju. Morate opisati rizike, moguća rješenja i troškove za menadžment ili menadžment kompanije. Oni moraju donositi odluke.

Dakle, ako je odlučeno da je, s obzirom na malu vjerovatnoću dvostrukog kvara, rad 4 sata na jednom prekidaču u principu prihvatljiv, onda jednostavno možete uzeti odgovarajuću podršku (prema kojoj će oprema biti zamijenjena u roku od 4 sati).

Ali postoji rizik da se ne isporuče. Nažalost, jednom smo se našli u takvoj situaciji. Umesto četiri sata, oprema je putovala nedelju dana!!!

Stoga i o ovom riziku treba razgovarati i možda će vam biti ispravnije kupiti još jedan prekidač (treći) i čuvati ga u paketu rezervnih dijelova („hladna” rezerva) ili ga koristiti u laboratorijske svrhe.

Bitan! Napravite tabelu sve podrške koju imate s datumima isteka i dodajte je u svoj kalendar kako biste dobili e-poruku barem mjesec dana unaprijed da biste trebali početi brinuti o obnavljanju podrške.

Neće vam biti oprošteno ako zaboravite da obnovite svoju podršku i dan nakon što završi vaš hardver se pokvari.

Hitan rad

Šta god da se dešava na vašoj mreži, idealno bi bilo da zadržite pristup vašoj mrežnoj opremi.

Bitan! Morate imati pristup konzoli za svu opremu i taj pristup ne bi trebao ovisiti o funkcionalnosti mreže korisničkih podataka.

Također biste trebali unaprijed predvidjeti moguće negativne scenarije i dokumentirati potrebne radnje. Dostupnost ovog dokumenta je takođe kritična, tako da ga ne treba postaviti samo na zajednički resurs za odeljenje, već i sačuvati lokalno na računarima inženjera.

Mora biti

• informacije potrebne za otvaranje tiketa kod podrške dobavljača ili integratora
• informacije o tome kako doći do bilo koje opreme (konzola, upravljanje)

Naravno, može sadržavati i bilo koju drugu korisnu informaciju, na primjer, opis procedure nadogradnje različite opreme i korisne dijagnostičke naredbe.

Naši partneri

Sada morate procijeniti rizike povezane s partnerima. Obično ovo

• Internet provajderi i tačke razmene saobraćaja (IX)
• pružaoci komunikacionih kanala

Koja pitanja treba da postavite sebi? Kao i kod opreme, moraju se uzeti u obzir različiti scenariji za hitne slučajeve. Na primjer, za internet provajdere, to može biti nešto poput:

• šta se dešava ako internet provajder X iz nekog razloga prestane da vam pruža uslugu?
• Hoće li drugi provajderi imati dovoljno propusnog opsega za vas?
• Koliko će dobra veza ostati?
• Koliko su vaši internet provajderi nezavisni i da li će ozbiljan prekid rada jednog od njih izazvati probleme kod ostalih?
• koliko optičkih ulaza u vaš data centar?
• šta će se dogoditi ako se jedan od ulaza potpuno uništi?

Što se tiče inputa, u mojoj praksi u dvije različite kompanije, u dva različita data centra, bager je uništio bunare i samo čudom naša optika nije bila pogođena. Ovo nije tako rijedak slučaj.

I naravno, potrebno je ne samo postaviti ova pitanja, već, opet, uz podršku menadžmenta, pružiti prihvatljivo rješenje u svakoj situaciji.

Backup

Sljedeći prioritet može biti sigurnosna kopija konfiguracija opreme. U svakom slučaju, ovo je veoma važna tačka. Neću nabrajati one slučajeve kada možete izgubiti konfiguraciju, bolje je praviti redovne sigurnosne kopije i ne razmišljati o tome. Osim toga, redovne sigurnosne kopije mogu biti vrlo korisne u praćenju promjena.

Bitan! Svakodnevno pravite sigurnosne kopije. Ovo nije tako velika količina podataka za uštedu na ovome. Ujutro dežurni inženjer (ili vi) treba da dobijete izveštaj od sistema koji jasno pokazuje da li je backup bio uspešan ili ne, a ako bekap nije bio uspešan, problem treba rešiti ili kreirati tiket ( pogledajte procese mrežnog odjela).

Verzije softvera

Pitanje da li se isplati nadograditi softver opreme nije tako jasno. S jedne strane, stare verzije su poznate greške i ranjivosti, ali s druge strane, novi softver, prvo, nije uvijek bezbolna procedura nadogradnje, a drugo, nove greške i ranjivosti.

Ovdje morate pronaći najbolju opciju. Nekoliko očiglednih preporuka

• instalirajte samo stabilne verzije
• Ipak, ne biste trebali živjeti na vrlo starim verzijama softvera
• napravite znak sa informacijama o tome gde se neki softver nalazi
• periodično čitajte izvještaje o ranjivosti i greškama u verzijama softvera, a u slučaju kritičnih problema razmislite o nadogradnji

U ovoj fazi, sa konzolnim pristupom opremi, informacijama o podršci i opisom procedure nadogradnje, u principu ste spremni za ovaj korak. Idealna opcija je kada imate laboratorijsku opremu u kojoj možete provjeriti cijelu proceduru, ali se to, nažalost, ne događa često.

U slučaju kritične opreme, možete kontaktirati podršku dobavljača sa zahtjevom da vam pomogne oko nadogradnje.

Sistem ulaznica

Sada možete pogledati okolo. Morate uspostaviti procese za interakciju sa drugim odjelima i unutar odjeljenja.

Ovo možda nije potrebno (na primjer, ako je vaša kompanija mala), ali bih vam toplo preporučio da se posao organizira na način da svi vanjski i interni zadaci prolaze kroz tiket sistem.

Tiketni sistem je u suštini vaš interfejs za internu i eksternu komunikaciju i trebalo bi da opišete ovo sučelje dovoljno detaljno.

Uzmimo primjer važnog i uobičajenog zadatka otvaranja pristupa. Opisaću algoritam koji je savršeno radio u jednoj od kompanija.

Primjer:

Počnimo s činjenicom da često pristupni korisnici formuliraju svoje želje na jeziku koji je nerazumljiv mrežnom inženjeru, naime, na jeziku aplikacije, na primjer, „daj mi pristup 1C“.

Stoga nikada nismo prihvatali zahtjeve direktno od takvih korisnika.
I to je bio prvi uslov

• zahtjevi za pristup trebaju doći od tehničkih odjela (u našem slučaju to su bili unix, windows, inženjeri helpdesk-a)

Drugi uslov je to

• ovaj pristup mora biti evidentiran (od strane tehničkog odjela od kojeg smo primili ovaj zahtjev) i kao zahtjev dobijamo link do ovog evidentiranog pristupa

Forma ovog zahtjeva nam mora 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

To bi takođe trebalo biti naznačeno tamo

• opis zašto je ovaj pristup otvoren
• privremeno ili trajno (ako je privremeno, do kojeg datuma)

I veoma važna tačka su odobrenja

• od šefa odjela koji je inicirao pristup (na primjer, računovodstvo)
• od šefa 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 šef odjela koji je inicirao pristup (računovodstveni u našem primjeru), a on je odgovoran za to da stranica sa prijavljenim pristupom za ovo odjeljenje ostane ažurna .

Logging

Ovo je nešto u čemu se možete utopiti. Ali ako želite implementirati proaktivan pristup, onda morate naučiti kako se nositi s ovom poplavom podataka.

Evo nekoliko praktičnih preporuka:

• morate svakodnevno pregledavati dnevnike
• u slučaju planiranog pregleda (a ne hitne situacije), možete se ograničiti na nivoe ozbiljnosti 0, 1, 2 i dodati odabrane obrasce sa drugih nivoa ako smatrate da je potrebno
• napišite skriptu koja analizira dnevnike i ignoriše one dnevnike čije ste obrasce dodali na listu ignorisanja

Ovaj pristup će vam omogućiti da s vremenom kreirate listu ignoriranja dnevnika koji vam nisu zanimljivi i ostavite samo one koje zaista smatrate važnima.
Odlično nam je funkcionisalo.

Monitoring

Nije neuobičajeno da kompanija nema sistem praćenja. Možete se, na primjer, osloniti na dnevnike, ali oprema može jednostavno "umrijeti" bez vremena da bilo šta "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 neophodno.

Dva najpopularnija primjera u mojoj praksi:

• praćenje opterećenja komunikacionih kanala, kritičnih veza (na primjer, povezivanje s provajderima). Oni vam omogućavaju da proaktivno sagledate potencijalni problem degradacije usluge zbog gubitka prometa i, shodno tome, izbjegnete ga.
• grafovi zasnovani na NetFlow-u. Oni olakšavaju pronalaženje anomalija u prometu i vrlo su korisni za otkrivanje nekih jednostavnih, ali značajnih vrsta hakerskih napada.

Bitan! Postavite SMS obavještenja za najkritičnije događaje. Ovo se odnosi i na praćenje i na evidentiranje. Ako nemate dežurnu smjenu, sms bi trebao stići i van radnog vremena.

Razmislite o procesu na takav način da ne probudite sve inženjere. Imali smo dežurnog inženjera za ovo.

Promijenite kontrolu

Po mom mišljenju, nije potrebno kontrolisati sve promjene. Ali, u svakom slučaju, trebali biste moći, ako je potrebno, lako pronaći ko je napravio određene promjene na mreži i zašto.

A nekoliko savjeta:

• koristite sistem tiketa da biste detaljno objasnili šta je urađeno na tom tiketu, na primer kopiranjem primenjene konfiguracije u tiket
• koristite mogućnosti komentara na mrežnoj opremi (na primjer, urezivanje komentara na Juniperu). Možete zapisati broj karte
• koristite diff rezervnih kopija vaše konfiguracije

Ovo možete implementirati kao proces, svakodnevno pregledavajući sve tikete za promjene.

Procesi

Morate formalizirati i opisati procese u svom timu. Ako ste dostigli ovu tačku, tada bi vaš tim već trebao imati pokrenute barem sljedeće procese:

Dnevni procesi:

• rad sa kartama
• rad sa trupcima
• kontrolu promjene
• dnevni kontrolni list

Godišnji procesi:

• produženje garancija, licenci

Asinhroni procesi:

• odgovor na razne vanredne situacije

Zaključak prvog dijela

Jeste li primijetili da se sve ovo još ne radi o mrežnoj konfiguraciji, ne o dizajnu, ne o mrežnim protokolima, ni o rutiranju, ni o sigurnosti... Nešto je okolo. Ali ovo, iako možda dosadno, jesu, naravno, vrlo važni elementi rada mrežne divizije.

Do sada, kao što vidite, niste ništa poboljšali u svojoj mreži. Ako je bilo sigurnosnih propusta, onda su one ostale; ako je postojao loš dizajn, onda je ostao. Sve dok ne primenite svoje veštine i znanja kao mrežni inženjer, na šta ste najverovatnije utrošili mnogo vremena, truda, a ponekad i novca. Ali prvo morate stvoriti (ili ojačati) temelj, a zatim započeti izgradnju.

Sljedeći dijelovi će vam reći kako pronaći i ukloniti greške, a zatim poboljšati svoju infrastrukturu.

Naravno, ne morate sve raditi uzastopno. Vrijeme može biti kritično. Uradite to paralelno ako vam resursi dozvoljavaju.

I važan dodatak. Komunicirajte, pitajte, konsultujte se sa svojim timom. Na kraju krajeva, oni su ti koji sve ovo podržavaju i rade.

izvor: www.habr.com