Kako prevzeti nadzor nad svojo omrežno infrastrukturo. Prvo poglavje. Drži

Ta članek je prvi v nizu člankov »Kako prevzeti nadzor nad svojo omrežno infrastrukturo«. Vsebino vseh člankov v seriji in povezave najdete tukaj.

Popolnoma priznam, da obstaja dovolj podjetij, kjer enourni ali celo enodnevni izpad omrežja ni kritičen. Na žalost ali na srečo nisem imel možnosti delati v takih prostorih. Seveda pa so omrežja drugačna, zahteve so drugačne, pristopi so različni, pa vendar bo spodnji seznam v takšni ali drugačni obliki v mnogih primerih dejansko »must-do«.

Torej, začetni pogoji.

Ste v novi službi, prejeli ste napredovanje ali pa ste se odločili na novo pogledati svoje odgovornosti. Omrežje podjetja je vaše področje odgovornosti. Za vas je to v marsičem izziv in novost, kar nekoliko opravičuje mentorski ton tega članka :). Upam pa, da bo članek lahko koristen tudi kateremu koli mrežnemu inženirju.

Vaš prvi strateški cilj je, da se naučite upreti entropiji in ohraniti raven ponujene storitve.

Veliko spodaj opisanih težav je mogoče rešiti na različne načine. Namenoma ne odpiram teme tehnične izvedbe, ker... načeloma pogosto ni tako pomembno, kako si rešil ta ali oni problem, ampak je pomembno, kako ga uporabljaš in ali ga sploh uporabljaš. Na primer, vaš profesionalno izdelan nadzorni sistem je malo uporaben, če ga ne pogledate in se ne odzovete na opozorila.

Оборудование

Najprej morate razumeti, kje so največja tveganja.

Spet je lahko drugače. Priznam, da bodo nekje to na primer varnostna vprašanja, nekje vprašanja, povezana s kontinuiteto storitve, nekje pa morda kaj drugega. Zakaj ne?

Predpostavimo, da bo jasno, da je to še vedno kontinuiteta storitve (tako je bilo v vseh podjetjih, kjer sem delal).

Potem morate začeti z opremo. Tukaj je seznam tem, na katere morate biti pozorni:

  • razvrstitev opreme po stopnji kritičnosti
  • varnostno kopiranje kritične opreme
  • podpora, licence

Premisliti morate o možnih scenarijih napak, zlasti z opremo na vrhu vaše klasifikacije kritičnosti. Običajno je možnost dvojnih težav zanemarjena, sicer lahko vaša rešitev in podpora postaneta nerazumno draga, a v primeru res kritičnih omrežnih elementov, katerih okvara bi lahko bistveno vplivala na poslovanje, je vredno razmisliti o tem.

Primer

Recimo, da govorimo o korenskem stikalu v podatkovnem centru.

Ker smo se strinjali, da je kontinuiteta storitve najpomembnejši kriterij, je smiselno zagotoviti “hot” backup (redundanco) te opreme. A to še ni vse. Odločiti se morate tudi, koliko časa je sprejemljivo živeti samo z enim preostalim stikalom, če se prvo stikalo pokvari, saj obstaja nevarnost, da se bo pokvarilo tudi to.

Pomembno! O tem vprašanju vam ni treba odločati sami. Vodstvu ali vodstvu podjetja morate opisati tveganja, možne rešitve in stroške. Odločati se morajo.

Torej, če je bilo odločeno, da je glede na majhno verjetnost dvojne okvare delo 4 ure na enem stikalu načeloma sprejemljivo, potem lahko preprosto vzamete ustrezno podporo (v skladu s katero bo oprema zamenjana v 4 ure).

Vendar obstaja tveganje, da ne bodo dosegli. Na žalost smo se enkrat znašli v taki situaciji. Namesto štiri ure je oprema potovala cel teden!!!

Zato je treba razpravljati tudi o tem tveganju in morda bo bolj pravilno, da kupite drugo stikalo (tretje) in ga hranite v paketu rezervnih delov ("hladna" rezerva) ali ga uporabite za laboratorijske namene.

Pomembno! Naredite preglednico vse podpore, ki jo imate, z datumi poteka in jo dodajte v svoj koledar, tako da boste vsaj mesec dni prej prejeli e-poštno sporočilo, da bi morali začeti skrbeti za podaljšanje podpore.

Ne bo vam odpuščeno, če pozabite obnoviti svojo podporo in dan po njeni prekinitvi vaša strojna oprema poči.

Delo v sili

Karkoli se zgodi v vašem omrežju, bi bilo najbolje, da ohranite dostop do svoje omrežne opreme.

Pomembno! Imeti morate dostop konzole do vse opreme in ta dostop ne sme biti odvisen od zdravja uporabniškega podatkovnega omrežja.

Prav tako morate vnaprej predvideti možne negativne scenarije in dokumentirati potrebne ukrepe. Razpoložljivost tega dokumenta je prav tako ključnega pomena, zato ga ne bi smeli samo objaviti na skupnem viru za oddelek, temveč tudi shraniti lokalno v računalnike inženirjev.

Mora obstajati

  • informacije, potrebne za odpiranje vstopnice pri podpori prodajalca ali integratorja
  • informacije o tem, kako priti do katere koli opreme (konzola, upravljanje)

Seveda lahko vsebuje tudi druge uporabne informacije, na primer opis postopka nadgradnje različne opreme in uporabne diagnostične ukaze.

Partnerji

Zdaj morate oceniti tveganja, povezana s partnerji. Ponavadi to

  • Internetni ponudniki in menjalnice prometa (IX)
  • ponudniki komunikacijskih kanalov

Katera vprašanja si morate zastaviti? Tako kot pri opremi je treba upoštevati različne scenarije v sili. Na primer, za internetne ponudnike je to lahko nekaj takega:

  • kaj se zgodi, če vam internetni ponudnik X iz nekega razloga preneha nuditi storitev?
  • Ali bodo drugi ponudniki imeli dovolj pasovne širine za vas?
  • Kako dobra bo povezljivost ostala?
  • Kako neodvisni so vaši internetni ponudniki in ali bo resen izpad enega od njih povzročil težave pri drugih?
  • koliko optičnih vhodov v vaš podatkovni center?
  • kaj se zgodi, če je eden od vhodov popolnoma uničen?

Glede vložkov, v moji praksi v dveh različnih podjetjih, v dveh različnih podatkovnih centrih, je bager uničil vodnjake in samo po čudežu naša optika ni bila prizadeta. To ni tako redek primer.

In, seveda, ne smete samo postavljati teh vprašanj, ampak spet, s podporo vodstva, zagotoviti sprejemljivo rešitev v vsaki situaciji.

Rezerva

Naslednja prednostna naloga je lahko varnostna kopija konfiguracij opreme. V vsakem primeru je to zelo pomembna točka. Ne bom našteval tistih primerov, ko lahko izgubite konfiguracijo, bolje je, da redno delate varnostne kopije in ne razmišljate o tem. Poleg tega je lahko redno varnostno kopiranje zelo koristno pri spremljanju sprememb.

Pomembno! Vsak dan naredite varnostne kopije. To ni tako velika količina podatkov, da bi pri tem prihranili. Zjutraj bi moral dežurni inženir (ali vi) prejeti poročilo sistema, kjer je jasno razvidno, ali je bila varnostna kopija uspešna ali ne, in če je bila varnostna kopija neuspešna, je treba odpraviti težavo ali ustvariti tiket ( glejte procese omrežnega oddelka).

Različice programske opreme

Vprašanje, ali se splača nadgraditi programsko opremo opreme ali ne, ni tako enoznačno. Po eni strani so stare različice znane napake in ranljivosti, po drugi strani pa nova programska oprema, prvič, ni vedno neboleč postopek nadgradnje, in drugič, nove napake in ranljivosti.

Tukaj morate najti najboljšo možnost. Nekaj ​​očitnih priporočil

  • namestite samo stabilne različice
  • Kljub temu ne bi smeli živeti na zelo starih različicah programske opreme
  • naredite znak z informacijami o tem, kje se nahaja določena programska oprema
  • občasno preberite poročila o ranljivostih in napakah v različicah programske opreme, v primeru kritičnih težav pa razmislite o nadgradnji

Na tej stopnji ste s konzolnim dostopom do opreme, informacijami o podpori in opisom postopka nadgradnje načeloma pripravljeni na ta korak. Idealna možnost je, če imate laboratorijsko opremo, kjer lahko preverite celoten postopek, vendar se to žal ne zgodi pogosto.

V primeru kritične opreme se lahko obrnete na podporo prodajalca s prošnjo za pomoč pri nadgradnji.

Sistem vstopnic

Zdaj se lahko ozrete naokoli. Vzpostaviti morate procese za interakcijo z drugimi oddelki in znotraj oddelka.

To morda ni potrebno (na primer, če je vaše podjetje majhno), vendar bi toplo priporočal, da delo organizirate tako, da gredo vse zunanje in notranje naloge skozi sistem vstopnic.

Sistem vozovnic je v bistvu vaš vmesnik za notranjo in zunanjo komunikacijo, zato bi morali ta vmesnik opisati dovolj podrobno.

Vzemimo primer pomembne in pogoste naloge odpiranja dostopa. Opisal bom algoritem, ki je v enem od podjetij odlično deloval.

Primer

Začnimo z dejstvom, da stranke dostopa pogosto oblikujejo svoje želje v jeziku, ki ga omrežni inženir ne razume, in sicer v jeziku aplikacije, na primer "daj mi dostop do 1C."

Zato nikoli nismo sprejemali zahtev neposredno od takih uporabnikov.
In to je bila prva zahteva

  • zahteve za dostop morajo prihajati iz tehničnih oddelkov (v našem primeru so bili to unix, windows, inženirji službe za pomoč uporabnikom)

Druga zahteva je ta

  • ta dostop mora biti zabeležen (tehnični oddelek, od katerega smo prejeli to zahtevo) in kot zahtevo prejmemo povezavo do tega zabeleženega dostopa

Oblika te zahteve nam mora biti razumljiva, tj.

  • zahteva mora vsebovati informacije o tem, katero podomrežje in do katerega podomrežja mora biti dostop odprt, ter protokol in (v primeru tcp/udp) vrata

Tam naj bo tudi navedeno

  • opis zakaj je ta dostop odprt
  • začasno ali trajno (če je začasno, do katerega datuma)

In zelo pomembna točka so odobritve

  • od vodje službe, ki je sprožila dostop (npr. računovodstvo)
  • od vodje tehničnega oddelka, od koder je ta zahteva prišla v omrežni oddelek (na primer služba za pomoč uporabnikom)

V tem primeru se za “lastnika” tega dostopa šteje vodja oddelka, ki je dostop sprožil (v našem primeru računovodstvo), in je odgovoren za to, da stran z evidentiranim dostopom za ta oddelek ostane posodobljena. .

Sečnja

To je nekaj, v čemer se lahko utopiš. Toda če želite uvesti proaktiven pristop, se morate naučiti, kako se soočiti s to poplavo podatkov.

Tukaj je nekaj praktičnih priporočil:

  • dnevno morate pregledovati dnevnike
  • v primeru načrtovanega pregleda (in ne nujne situacije) se lahko omejite na stopnje resnosti 0, 1, 2 in dodate izbrane vzorce iz drugih stopenj, če menite, da je potrebno
  • napišite skript, ki razčlenjuje dnevnike in ignorira tiste dnevnike, katerih vzorce ste dodali na seznam prezrtih

Ta pristop vam bo omogočil, da sčasoma ustvarite seznam prezrtih dnevnikov, ki vam niso zanimivi, in pustite samo tiste, ki se vam resnično zdijo pomembni.
Odlično nam je uspelo.

Spremljanje

Ni nenavadno, da podjetje nima nadzornega sistema. Lahko se na primer zanesete na dnevnike, vendar lahko oprema preprosto "umre", ne da bi imela čas "povedati" karkoli, ali pa se paket protokola udp syslog izgubi in ne prispe. Na splošno je seveda aktivno spremljanje pomembno in potrebno.

Dva najbolj priljubljena primera v moji praksi:

  • spremljanje obremenjenosti komunikacijskih kanalov, kritičnih povezav (na primer povezovanje s ponudniki). Omogočajo vam, da proaktivno vidite potencialni problem degradacije storitve zaradi izgube prometa in se temu ustrezno izognete.
  • grafi, ki temeljijo na NetFlow. Omogočajo enostavno iskanje nepravilnosti v prometu in so zelo uporabni za odkrivanje nekaterih preprostih, a pomembnih vrst hekerskih napadov.

Pomembno! Nastavite SMS obveščanje za najbolj kritične dogodke. To velja tako za spremljanje kot za beleženje. Če nimate dežurstva, naj sms pride tudi izven delovnega časa.

Premislite o procesu tako, da ne boste prebudili vseh inženirjev. Za to smo imeli dežurnega inženirja.

Nadzor sprememb

Po mojem mnenju ni treba nadzorovati vseh sprememb. V vsakem primeru pa bi morali imeti možnost, če je potrebno, enostavno ugotoviti, kdo je naredil določene spremembe v omrežju in zakaj.

Nekaj ​​nasvetov:

  • uporabite sistem vozovnic za podrobnosti, kaj je bilo narejeno na tej vstopnici, na primer s kopiranjem uporabljene konfiguracije v vstopnico
  • uporaba zmožnosti komentiranja na omrežni opremi (na primer potrditev komentarja na Juniper). Lahko si zapišete številko vstopnice
  • uporabite diff vaših konfiguracijskih varnostnih kopij

To lahko izvedete kot postopek in dnevno pregledujete vse vstopnice za morebitne spremembe.

Procesi

Morate formalizirati in opisati procese v vaši ekipi. Če ste dosegli to točko, bi morala vaša ekipa že izvajati vsaj naslednje procese:

Dnevni procesi:

  • delo z vstopnicami
  • delo s hlodi
  • nadzor sprememb
  • dnevni kontrolni list

Letni procesi:

  • podaljšanje garancij, licenc

Asinhroni procesi:

  • odziv na različne izredne razmere

Zaključek prvega dela

Ali ste opazili, da pri vsem tem še ne gre za konfiguracijo omrežja, ne za načrtovanje, ne za omrežne protokole, ne za usmerjanje, ne za varnost ... Nekaj ​​je okoli. A to so, čeprav morda dolgočasni, seveda zelo pomembni elementi dela mrežnega oddelka.

Doslej, kot vidite, v svojem omrežju niste izboljšali ničesar. Če so bile varnostne ranljivosti, potem so ostale; če je bil slab dizajn, potem je ostal. Dokler niste uporabili svojih sposobnosti in znanja kot omrežni inženir, za kar ste najverjetneje porabili veliko časa, truda in včasih tudi denarja. Toda najprej morate ustvariti (ali okrepiti) temelje in nato začeti graditi.

Naslednji deli vam bodo povedali, kako najti in odpraviti napake ter nato izboljšati svojo infrastrukturo.

Seveda vam ni treba narediti vsega zaporedno. Čas je lahko kritičen. Naredite to vzporedno, če sredstva dopuščajo.

In pomemben dodatek. Komunicirajte, sprašujte, posvetujte se s svojo ekipo. Na koncu so oni tisti, ki vse to podpirajo in delajo.

Vir: www.habr.com

Dodaj komentar