Kako preuzeti mrežnu infrastrukturu pod svoju kontrolu. Prvo poglavlje. Održavanje

Ovaj članak je prvi u ciklusu članaka «Kako preuzeti kontrolu nad mrežnom infrastrukturom». Sadržaj svih članaka iz ciklusa i veze mogu se pronaći ovdje.

Sasvim je moguće da postoji dovoljan broj kompanija gdje jednostavna mreža tijekom jednog sata ili čak jednog dana nije kritična. Nažalost ili na sreću, nisam imao priliku raditi u takvim mjestima. No, naravno, mreže su različite, zahtjevi su različiti, pristupi su različiti i ipak, u tom ili onom obliku, dolje navedeni popis u mnogim će slučajevima biti zapravo «must-do».

Dakle, početni uvjeti.

Na novom ste radnom mjestu ili ste dobili unapređenje ili ste odlučili iznova pogledati svoje obaveze. Mreža kompanije je vaša zona odgovornosti. Za vas je to u velikoj mjeri izazov i novo, što donekle opravdava mentorski ton ovog članka :). No, nadam se da članak može biti koristan i bilo kojem mrežnom inženjeru.

Vaš prvi strateški cilj je naučiti se odupirati entropiji i održati razinu pružene usluge.

Mnogi od dolje opisanih zadataka mogu se riješiti različitim sredstvima. Namjerno ne otvaram temu tehničke realizacije, jer u principu često nije toliko važno kako ste riješili taj ili onaj zadatak, nego je važno kako to koristite i koristite li to uopće. Malo koristi, na primjer, od vašeg profesionalno organiziranog sustava za nadzor, ako ne pogledate u njega i ne reagirate na upozorenja.

Oprema

Prvo trebate razumjeti gdje su najveći rizici.

Opet, to može biti različito. Pretpostavljam da negdje, na primjer, to mogu biti pitanja sigurnosti, a negdje pitanja vezana uz kontinuitet usluge, a negdje, možda, nešto drugo. Zašto ne?

Pretpostavimo za određivanje da je to ipak kontinuitet usluge (tako je bilo u svim kompanijama u kojima sam radio).

Tada treba početi s opremom. Evo popisa tema na koje trebate obratiti pažnju:

• klasifikacija opreme prema stupnju kritičnosti
• rezervacija kritične opreme
• podrška, licence

Trebate razmotriti moguće scenarije kvara, posebno s opremom koja se nalazi na vrhu vaše klasifikacije kritičnosti. Obično se zanemaruje vjerojatnost dvostrukih problema, inače vaša rješenja i podrška mogu postati neopravdano skupi, ali u slučaju stvarno kritičnih komponenti mreže čije bi otkazivanje moglo značajno utjecati na poslovanje, trebate razmisliti i o tome.

Primjer

Pretpostavimo da govorimo o glavnom preklopniku u podatkovnom centru.

Budući da smo se dogovorili da je neprekidnost usluge najvažniji kriterij, razborito je osigurati 'vruće' rezerviranje (redundancy) te opreme. No, to nije sve. Također se morate odlučiti koliko dugo, u slučaju kvara prvog preklopnika, za vas je prihvatljivo raditi samo s jednim preostalim preklopnikom, jer postoji rizik da će i on otkazati.

Važno! Ne smijete sami odlučiti o ovom pitanju. Trebate opisati rizike, moguća rješenja i troškove vašem rukovodstvu ili upravi tvrtke. Odluke bi trebali donijeti oni.

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

Ali postoji rizik da ne stignu. Nažalost, jednom smo se našli u takvoj situaciji. Umjesto četiri sata oprema je putovala tjedan dana!!!

Stoga se i taj rizik treba raspraviti i, možda, bilo bi ispravnije za vas kupiti još jedan preklopnik (treći) i držati ga u ZEP-u ('hladno' rezerviranje) ili koristiti u laboratorijske svrhe.

Važno! Napravite popis svih podrški koje imate, s datumima isteka, i dodajte ih u kalendar kako biste barem mjesec dana unaprijed dobili obavijest da se trebate zabrinuti oko produženja podrške.

Neće vam oprostiti ako zaboravite produžiti podršku i sutradan nakon što istekne, vaša oprema se pokvari.

Hitni radovi

Što god se dogodilo u vašoj mreži, idealno, trebate sačuvati pristup vašoj mrežnoj opremi.

Važno! Morate imati konzolni pristup svemu opremi i taj pristup ne smije ovisiti o funkcionalnosti mreže prijenosa korisničkih podataka (data).

Također, trebate unaprijed razmisliti o mogućim negativnim scenarijima i dokumentirati potrebne radnje. Dostupnost ovog dokumenta također je kritična, stoga ga treba ne samo postaviti na zajednički resurs za odjel, već i lokalno pohraniti na računala inženjera.

Obavezno tamo moraju biti

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

Također, naravno, mogu se sadržavati sve druge korisne informacije, poput opisa postupka nadogradnje različite opreme i korisnih dijagnostičkih naredbi.

Partneri

Sada trebate procijeniti rizike povezane s partnerima. Obično su to

• internet provajderi i čvorišta za razmjenu prometa (IX)
• provajderi komunikacijskih kanala

Koja pitanja trebate postaviti sebi? Kao i u slučaju opreme, treba razmotriti različite opcije hitnih situacija. Na primjer, za internet provajdere, to može biti nešto poput:

• što će se dogoditi ako internet provajder X prestane iz nekog razloga pružati vam uslugu?
• hoće li vam biti dovoljno propusnosti preostalih provajdera?
• kakva će ostati povezanost?
• koliko su neovisni vaši internet provajderi i hoće li ozbiljna nesreća jednog od njih dovesti do problema s drugima?
• koliko optičkih ulaza imate u svoj data centar?
• što će se dogoditi ako jedan od ulaza bude potpuno uništen?

Što se tiče ulaza, u mojoj praksi u dvije različite tvrtke, u dvjema različitim data centrima bageri su uništavali šahtove i samo srećom naša optika nije bila pogođena. Nije tako rijetka situacija.

Pa, naravno, ne trebate samo postaviti ova pitanja, već, ponovo osiguravajući podršku vodstva, osigurati prihvatljivo rješenje u svakoj situaciji.

Backup

Sljedeći prioritet može biti izrada sigurnosnih kopija konfiguracija opreme. U svakom slučaju, ovo je vrlo važna točka. Neću nabrajati situacije kada možete izgubiti konfiguraciju, bolje je redovito raditi sigurnosne kopije i ne razmišljati o tome. Osim toga, redovita sigurnosna kopija može biti vrlo korisna pri kontroli promjena.

Važno! Odradite redovito backup. To nije velik volumen podataka da biste štedjeli na tome. Ujutro, inženjer na dežurstvu (ili vi) trebao bi primiti izvještaj iz sustava koji jasno navodi je li backup bio uspješan ili ne, a u slučaju neuspjeha, problem treba riješiti ili otvoriti ticket (vidi procese mrežnog odjela).

Verzije softvera

Pitanje o tome treba li nadograditi softver opreme nije tako jednostavno. S jedne strane, stare verzije predstavljaju poznate greške i ranjivosti, ali s druge strane, novi softver nije uvijek bezbolna procedura nadogradnje, a uz to donosi nove greške i ranjivosti.

Ovdje je potrebno pronaći optimalnu varijantu. Nekoliko očitih preporuka.

• koristite samo stabilne verzije.
• ne biste trebali koristiti posve stare verzije softvera.
• napravite tablicu s informacijama o tome gdje se koji softver koristi.
• povremeno pregledavajte izvještaje o ranjivostima i greškama u verzijama softvera, a u slučaju kritičnih problema razmislite o nadogradnji.

Na ovoj fazi, imajući konzolni pristup opremi, informacije o podršci i opis postupka nadogradnje, u principu ste spremni za ovaj korak. Idealna situacija je kada imate laboratorijsku opremu na kojoj možete testirati cijeli postupak, ali, nažalost, to se rijetko događa.

Za kritičnu opremu možete se obratiti podršci dobavljača sa zahtjevom da vam pomognu u provođenju nadogradnje.

Sistem za prijavu

Sada se možete osvrnuti oko sebe. Trebate uspostaviti procese međusobne komunikacije s drugim odjelima i unutar svog odjela.

Možda to nije obavezno (na primjer, ako je vaša tvrtka mala), ali bih jako preporučio organizirati rad na način da svi vanjski i unutarnji zadaci prolaze kroz sustav ticketinga.

Sustav ticketinga je u suštini vaš sučelje za unutarnju i vanjsku komunikaciju, a trebali biste s dovoljnom razinom detalja opisati ovo sučelje.

Uzmimo kao primjer važan i često zastupljen zadatak otvaranja pristupa. Opisat ću algoritam koji je odlično funkcionirao u jednoj od tvrtki.

Primjer

Prvo ćemo reći da naručitelji često formuliraju svoje zahtjeve na jeziku koji je nejasan mrežnom inženjeru, to jest, na jeziku aplikacije, na primjer, "otvorite mi pristup u 1C".

Zato nikada nismo prihvaćali zahtjeve izravno od takvih korisnika.
I to je bio prvi zahtjev.

• Zahtjevi za pristup trebaju dolaziti od tehničkih odjela (u našem slučaju to su bili unix, windows, helpdesk inženjeri).

Drugi zahtjev je da

• ovaj pristup mora biti zabilježen (od strane tehničkog odjela koji je podnio zahtjev) i kao zahtjev dobivamo poveznicu na ovaj zabilježeni pristup.

Oblik ovog zahtjeva mora biti jasan nama, to jest,

• zahtjev treba sadržavati informacije o kojem i u koju podmrežu treba otvoriti pristup, kao i o protokolu i (u slučaju tcp/udp) portovima.

Također treba biti navedeno

• opis zašto se ovaj pristup otvara,
• privremeni ili trajni (ako je privremeni, do kojeg datuma).

I vrlo važna stavka su odobrenja

• od voditelja odjela koji je inicirao pristup (na primjer, računovodstva),
• od voditelja tehničkog odjela, odakle je ovaj zahtjev došao u mrežni odjel (na primjer, helpdesk).

Pri tome, "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 sa zabilježenim pristupima za ovaj odjel ostane ažurna.

Logiranje

To je nešto u čemu se može utonuti. No, ako želite uvesti proaktivan pristup, morate naučiti kako upravljati ovim tokom podataka.

Evo nekoliko praktičnih preporuka:

• logove treba pregledavati svakodnevno.
• u slučaju planiranog pregleda (a ne hitne situacije) možete se ograničiti na razine kritičnosti (severity) 0, 1, 2 i dodati omiljene obrasce iz drugih razina ako smatrate potrebnim.
• napravite skriptu koja analizira logove i ignorira one logove čiji ste obrasce dodali u popis ignoriranja.

Ovaj pristup će s vremenom omogućiti sastavljanje popisa ignoriranih logova koji vas ne zanimaju i ostaviti samo one koje zaista smatrate važnima.
Kod nas je to odlično funkcioniralo.

Monitoring

Nije neuobičajeno da u kompaniji nedostaje sustav nadzora. Možete, na primjer, osloniti se na logove, ali oprema može jednostavno «umrijeti», ne stignuvši ništa «reći», ili UDP paket syslog protokola može se izgubiti i ne stići. U svakom slučaju, aktivni nadzor je važan i potreban.

Dva najtraženija primjera u mojoj praksi:

• nadzor opterećenja komunikacijskih kanala, kritičnih poveznica (na primjer, povezanost s pružateljima usluga). Omogućava proaktivno uočavanje potencijalnih problema degradacije usluge uslijed gubitka prometa i, prema tome, izbjegavanje istih.
• grafikoni temeljeni na NetFlowu. Oni 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čnija događanja. To se odnosi i na nadzor i na logiranje. Ako nemate smjenu, tada bi SMS također trebali dolaziti i izvan radnog vremena.

Isplanirajte proces na način koji neće buditi sve inženjere. Kod nas je za to bio dežurni inženjer.

Kontrola promena

Po mom mišljenju, nije nužno kontrolirati sve promjene. No, u svakom slučaju, trebali biste imati mogućnost lako pronaći tko i zašto je napravio određene promjene u mreži ako je potrebno.

Nekoliko savjeta:

• koristite sustav tiketa za detaljno opisivanje onoga što je učinjeno u okviru tog tiketa, na primjer, kopirajući primijenjenu konfiguraciju u tiket
• koristite mogućnosti komentiranja na mrežnoj opremi (na primjer, commit comment na Juniperu). Možete zabilježiti broj tiketa
• koristite diff vaših sigurnosnih kopija konfiguracije

Možete to uvesti kao proces, svakodnevno pregledavajući sve tikete radi promjena.

Procesi

Trebali biste formalizirati i opisati procese u vašem timu. Ako ste stigli do ovog trenutka, u vašem bi timu već trebali raditi barem sljedeći procesi:

Sv daily procesi:

• rad s tiketima
• rad s logovima
• kontrola promjena
• dnevna kontrolna lista

Godišnji procesi:

• produžavanje garancija, licenci

Asinkroni procesi:

• reakcija na razne hitne situacije

Zaključak prvog dela

Primijetili ste da sve ovo ne govori o konfiguraciji mreže, dizajnu, mrežnim protokolima, usmjeravanju ili sigurnosti... To je nešto izvan toga. Iako se možda čini dosadnim, sigurno su to vrlo važni elementi rada mrežnog odjela.

Dosad, kao što vidite, niste ništa poboljšali u svojoj mreži. Ako su postojale sigurnosne ranjivosti, one su ostale, a ako je dizajn bio loš, i dalje je takav. Dok ne primijenite svoje sposobnosti i znanja mrežnog inženjera, koje je vjerojatno zahtijevalo mnogo vremena, truda, pa čak i novca. No prvo je potrebno izgraditi (ili ojačati) temelj, a tek onda se posvetiti gradnji.

O tome kako tražiti i otklanjati greške, a zatim i unaprijediti vašu infrastrukturu – o tome će biti sljedeći dijelovi.

Naravno, nije potrebno raditi sve redom. Vrijeme može biti kritično. Radite paralelno ako to resursi dopuštaju.

I važna napomena. Komunicirajte, pitajte, savjetujte se sa svojim timom. Na kraju krajeva, oni su ti koji će sve to održavati i provoditi.

Izvor: habr.com