ProHoster > Blog > Administrimi > Si si merrni nën kontroll infrastrukturën rrjetore. Kapitulli i parë. Mbajtja

Si si merrni nën kontroll infrastrukturën rrjetore. Kapitulli i parë. Mbajtja

Ky artikull është i pari në ciklin e artikujve "Si ta merrni nën kontroll infrastrukturën rrjetore". Përmbajtja e të gjitha artikujve në cikël dhe lidhjet e tyre mund të gjenden këtu.

E pranoj se ekzistojnë mjaft kompani ku një rrjet i thjeshtë për një orë ose madje një ditë nuk është kritik. Mua, për fat të keq ose për fat të mirë, nuk më ka rënë rasti të punoj në vende të tilla. Por, natyrisht, rrjetet janë të ndryshme, kërkesat janë të ndryshme, qasjet janë të ndryshme, dhe megjithatë, në një mënyrë ose në një tjetër, lista e mëposhtme do të jetë në shumë raste faktikisht një "must-do".

Pra, kushtet fillestare.

Ju jeni nĂ« njĂ« vend tĂ« ri pune ose keni avancim ose vendosĂ«t ta shihni ndryshe detyrĂ«n tuaj. Rrjeti i kompanisĂ« – kjo Ă«shtĂ« zona juaj e pĂ«rgjegjĂ«sisĂ«. PĂ«r ju, nĂ« masĂ« tĂ« madhe, ky Ă«shtĂ« njĂ« sfidĂ« dhe njĂ« e re, e cila nĂ« njĂ«farĂ« mĂ«nyre justifikon tonin mentorues tĂ« kĂ«tij artikulli :). Por, shpresoj, qĂ« artikulli gjithashtu mund tĂ« jetĂ« i dobishĂ«m pĂ«r çdo inxhinier rrjeti.

Qëllimi juaj i parë strategjik është të mësoni si të përballoni entropinë dhe të mbani nivelin e shërbimit të siguruar.

Shumë nga detyrat e përmendura më poshtë mund të zgjidhen me mjete të ndryshme. Unë qëllimisht nuk përmend temën e realizimit teknik, pasi shpesh nuk ka rëndësi se si e zgjidhni një detyrë të caktuar, por është e rëndësishme se si e përdorni atë dhe nëse e përdorni ndonjëherë. P.sh., pak do të thotë nga sistemi juaj i monitorimit të ndërtuar profesionalisht, nëse nuk e shikoni atë dhe nuk reagoni ndaj alerteve.

Pajisjet

Së pari, duhet të kuptoni se ku janë rreziqet më të mëdha.

Edhe një herë, mund të jetë ndryshe. Pranoj se diku, për shembull, mund të jenë çështjet e sigurisë, diku tjetër mund të jenë çështje të lidhura me vazhdimësinë e shërbimit, e ndoshta dikund tjetër, ndonjë gjë tjetër. Pse jo?

Le të supozojmë për qartësi se është vazhdimësia e shërbimit (ashtu ka qenë në të gjitha kompanitë ku kam punuar).

Atëherë duhet të filloni me pajisjet. Ja lista e temave që duhet të keni parasysh:

  • klasifikimi i pajisjeve sipas rĂ«ndĂ«sisĂ« kritike
  • rezervimi i pajisjeve kritike
  • mbĂ«shtetje, licenca

Duhet të mendoni për mundësitë e mundshme të defekteve, veçanërisht për pajisjet që ndodhen në majë të klasifikimit tuaj të rëndësisë. Zakonisht, nënvlerësohet probabiliteti i problemit të dyfishtë; përndryshe, zgjidhja juaj dhe mbështetja mund të bëhen të paarsyeshme të shtrenjta, por në rastin e elementeve jashtëzakonisht të rëndësishëm të rrjetit, një prishje e të cilëve mund të ndikojë ndjeshëm në biznes, duhet të mendoni edhe për këtë.

Shembuj

Supozoni se po flasim për switch-in rrënjor në qendrën e të dhënave.

Pasi u dakorduam që vazhdimësia e shërbimit është kriteri më i rëndësishëm, është e arsyeshme të sigurohet një rezervim 'i ngrohtë' (redundancy) i kësaj pajisjeje. Por kjo nuk është e gjitha. Ju gjithashtu duhet të vendosni se sa kohë, në rastin e prishjes së switch-it të parë, është e pranueshme për ju të jetoni vetëm me switch-in e mbetur, pasi ekziston rreziku që edhe ai të prishet.

E rëndësishme! Nuk duhet ta zgjidhni këtë çështje vetë. Duhet t'i përshkruani rreziqet, zgjidhjet e mundshme dhe koston drejtorisë tuaj ose udhëheqjes së kompanisë. Ata duhet të marrin vendimet.

Nëse është vendosur që, përkundër probabilitetit të vogël të një dështimi të dyfishtë, të punoni për 4 orë në një switch, në parim, është e pranueshme, atëherë mund të merrni mbështetje përkatëse (në të cilën pajisja do të zëvendësohet brenda 4 orëve).

Por ka rrezik që mos të dërgohet. Fatkeqësisht, një herë ne u gjendëm në një situatë të tillë. Në vend të katër orëve, pajisja udhëtoi për një javë!!!

Prandaj ky rrezik duhet gjithashtu tĂ« diskutohet dhe ndoshta do tĂ« ishte mĂ« e arsyeshme pĂ«r ju tĂ« blini njĂ« switch tjetĂ«r (tĂ« tretĂ«) dhe ta mbani atĂ« nĂ« ZIП («rezervĂ« e ftohtë») ose ta pĂ«rdorni pĂ«r qĂ«llime laboratorike.

E rëndësishme! Përgatitni një tabelë të të gjitha mbështetjeve që keni, me datat e skadimit dhe shtoni ato në kalendar, në mënyrë që të merrni një email të paktën një muaj përpara se të filloni të shqetësoheni për rinovimin e mbështetjes.

Nuk do t'ju falin nëse harroni të rinovoni mbështetje dhe ditën pas skadimit, pajisja juaj dështojnë.

Punë emergjente

ÇfarĂ«do qĂ« ndodhi nĂ« rrjetin tuaj, nĂ« mĂ«nyrĂ« ideale, duhet tĂ« mbani akses nĂ« pajisjet tuaja rrjetuese.

ËshtĂ« e rĂ«ndĂ«sishme! Duhet tĂ« keni akses nĂ« konsolĂ« pĂ«r gjithĂ« pajisjet dhe ky akses nuk duhet tĂ« varet nga funksionimi i rrjetit tĂ« transmetimit tĂ« tĂ« dhĂ«nave.

Gjithashtu, duhet të parashikoni skenarë negativë dhe të dokumentoni veprimet e nevojshme. Disponueshmëria e këtij dokumenti është gjithashtu kritike, prandaj ai duhet të jetë i publikuar në një burim të përbashkët për departamentin, si dhe të ruhet lokal në kompjuterët e inxhinierëve.

Detyrimisht aty duhet të jenë

  • informacione tĂ« nevojshme pĂ«r hapjen e njĂ« kĂ«rkese nĂ« ndihmĂ« nga ofruesi ose integratori
  • informacione se si tĂ« qaseni nĂ« çdo pajisje (konsolĂ«, menaxhim)

Gjithashtu, mund të përmbajë çdo informacion tjetër të dobishëm, siç është përshkrimi i procedurës së përmirësimit të pajisjeve të ndryshme dhe komandat diagnostikuese të dobishme.

Partnerët

Tani duhet të vlerësoni rreziqet e lidhura me partnerët. Zakonisht, këto janë

  • ofruesit e internetit dhe piketat e shkĂ«mbimit tĂ« trafikut (IX)
  • ofruesit e kanaleve tĂ« komunikimit

Cilat pyetje duhet të bëni vetes? Si në rastin e pajisjeve, duhet të shqyrtoni mundësi të ndryshme për situata emergjente. Për shembull, për ofruesit e internetit, kjo mund të jetë diçka si:

  • çfarĂ« do tĂ« ndodhte nĂ«se ofruesi i internetit X ndalon pĂ«r ndonjĂ« arsye ofrimin e shĂ«rbimit tuaj?
  • a do t'ju mjaftojĂ« bandwidth-i i ofruesve tĂ« tjerĂ«?
  • sa e mirĂ« do tĂ« mbetet lidhshmĂ«ria?
  • sa tĂ« pavarur janĂ« ofruesit tuaj tĂ« internetit dhe a do tĂ« çojĂ« njĂ« aksident serioz i njĂ«rit prej tyre nĂ« probleme me tĂ« tjerĂ«t?
  • sa hyrje optike ka qendra juaj tĂ« tĂ« dhĂ«nave?
  • çfarĂ« do tĂ« ndodhte nĂ«se njĂ«ra nga hyrjet do tĂ« shkatĂ«rrohej plotĂ«sisht?

Për sa i përket hyrjeve, në praktikën time në dy kompani të ndryshme, në dy vende të ndryshme, qendrat e të dhënave ekskavatori shkatërronte putkat dhe vetëm një mrekulli na shpëtonte optikën. Nuk është një rast kaq i rarë.

Natyrisht, ju duhet jo vetëm të bëni këto pyetje, por, përsëri, pas mbështetjes nga menaxhmenti, të siguroheni se ka një zgjidhje të pranueshme në çdo situatë.

Backup

Prioriteti më i lartë mund të jetë backup-i i konfigurimeve të pajisjeve. Në çdo rast, ky është një moment shumë i rëndësishëm. Nuk do t'i përmend rastet kur mund të humbisni konfigurimin, është më mirë të bëni backup rregullisht dhe të mos mendoni për të. Ndërkohë, një backup i rregullt mund të jetë shumë i dobishëm për kontrollin e ndryshimeve.

ËshtĂ« e rĂ«ndĂ«sishme! BĂ«ni backup çdo ditĂ«. Nuk Ă«shtĂ« njĂ« sasi kaq e madhe tĂ« dhĂ«nash pĂ«r tĂ« kursyer nĂ« kĂ«tĂ«. NĂ« mĂ«ngjes, inxhinieri i shĂ«rbimit (ose ju) duhet tĂ« marrĂ« njĂ« rapor nga sistemi, i cili shpreh qartĂ« nĂ«se backup-i ishte i suksesshĂ«m apo jo, dhe nĂ« rast se backup-i nuk ishte i suksesshĂ«m, problemi duhet tĂ« zgjidhet ose njĂ« biletĂ« duhet tĂ« krijohet (shihni proceset e departamentit rrjetit).

Versionet e software-it

Pyetja se a duhet ose jo të kryhet përmirësimi i software-it të pajisjeve nuk është aq e qartë. Nga njëra anë, versionet e vjetra kanë bugs dhe vulnerabilitete të njohura, por nga ana tjetër, software-i i ri nuk është gjithmonë një procedurë pa dhimbje, dhe gjithashtu hyn në lojë bugs dhe vulnerabilitete të reja.

Këtu duhet të gjendet opsioni optimal. Disa rekomandime të qarta

  • vini vetĂ«m versione stabile
  • nuk duhet tĂ« jetoni nĂ« versione shumĂ« tĂ« vjetra tĂ« software-it
  • krijoni njĂ« tabelĂ« me informacionin se ku ndodhet cilido softuer
  • lexoni rregullisht raportet pĂ«r dobĂ«sitĂ« dhe defektet nĂ« versionet e softuerit, dhe nĂ« rast tĂ« problemeve kritike, Ă«shtĂ« e arsyeshme tĂ« mendoni pĂ«r njĂ« pĂ«rmirĂ«sim

Në këtë fazë, duke pasur akses në konsolën e pajisjeve, informacion mbi mbështetje dhe përshkrime të procesit të përmirësimit, në parim, jeni gati për këtë hap. Një variant ideal është kur keni pajisje laboratorike, ku mund të provoni të gjithë procedurën, por, për fat të keq, kjo ndodh rrallë.

Në rast të pajisjeve kritike, mund të kontaktoni mbështetje nga shitësi për t'ju ndihmuar në realizimin e përmirësimit.

Sistemi i tiketave

Tani mund të shikoni rreth. Ju nevojitet të organizoni proceset e bashkëpunimit me departamente të tjera dhe brenda departamentit tuaj.

Ndoshta kjo nuk është e detyrueshme (p.sh., nëse kompania juaj është e vogël), por do t'ju rekomandoja fort të organizoni punën në një mënyrë që të gjitha detyrat e jashtme dhe të brendshme kalojnë përmes sistemit të tiketave.

Sistemi i biletave është në thelb interfaci juaj për komunikimet e brendshme dhe të jashtme, dhe ju duhet ta përshkruani këtë interfaci me një shkallë të mjaftueshme detaji.

Le të shqyrtojmë për shembull një detyrë të rëndësishme dhe shpesh të hasur për hapjen e aksesit. Do ta përshkruaj algoritmin që ka funksionuar shumë mirë në një nga kompanitë.

Shembuj

Të fillojmë me faktin se shpesh kërkuesit e aksesit e formulojnë dëshirën e tyre në një gjuhë të paqartë për inxhinierët e rrjetit, domethënë, në gjuhën e aplikacionit, për shembull, "më hapni akses në 1C".

Prandaj, ne kurrë nuk pranuam kërkesa drejtpërdrejt nga këta përdorues.
Dhe ky ishte kërkesa e parë.

  • KĂ«rkesat pĂ«r ofrimin e aksesit duhet tĂ« vijnĂ« nga departamentet teknike (nĂ« rastin tonĂ« kĂ«to ishin inxhinierĂ«t e unix, windows, dhe helpdesk).

Kërkesa e dytë është që

  • ky akses duhet tĂ« jetĂ« i dokumentuar (nga departamenti teknik, nga i cili kemi marrĂ« kĂ«tĂ« kĂ«rkesĂ«) dhe si kĂ«rkesĂ« marrim njĂ« lidhje pĂ«r kĂ«tĂ« akses tĂ« dokumentuar.

Forma e kësaj kërkese duhet të jetë e kuptueshme për ne, domethënë

  • kĂ«rkesa duhet tĂ« pĂ«rmbajĂ« informacion mbi se nga cila dhe nĂ« cilĂ«n nĂ«ndelesĂ« duhet tĂ« hapet akses, si dhe mbi protokollin dhe (nĂ« rastin e tcp/udp) portet

Po ashtu duhet të tregoni

  • pĂ«rshkrimin e arsyes pse ky akses hapet
  • pĂ«rkohshĂ«m ose pĂ«rherĂ« (nĂ«se Ă«shtĂ« pĂ«rkohĂ«sore, deri nĂ« cilĂ«n datĂ«)

Dhe një pikë shumë e rëndësishme janë aprovat

  • nga drejtori i departamentit qĂ« e iniciuar aksesin (p.sh., financat)
  • nga drejtori i departamentit teknik nga ku ka ardhur kjo kĂ«rkesĂ« nĂ« departamentin rrjetĂ« (p.sh., helpdesk)

NĂ« kĂ«tĂ« rast, ‘pronari’ i kĂ«tij aksesi Ă«shtĂ« drejtori i departamentit qĂ« e iniciuar aksesin (financat nĂ« shembullin tonĂ«), dhe ai Ă«shtĂ« pĂ«rgjegjĂ«s pĂ«r sigurimin qĂ« faqja me ekspozitat e dokumentuara pĂ«r kĂ«tĂ« departament tĂ« mbetet aktuale.

Logimi

Kjo është ajo në të cilën mund të mbytemi. Por nëse dëshironi të implementoni një qasje proaktive, duhet të mësoni si të menaxhoni këtë fluks të dhënash.

Këtu janë disa rekomandime praktike:

  • tĂ« shqyrtoni logjet duhet tĂ« bĂ«het çdo ditĂ«
  • nĂ« rastin e njĂ« shqyrtimi tĂ« planifikuar (dhe jo situatĂ« emergjente) mund tĂ« kufizoheni nĂ« nivelet e rĂ«ndĂ«sisĂ« (severity) 0, 1, 2 dhe tĂ« shtoni modele tĂ« preferuara nga nivele tĂ« tjera nĂ«se e konsideroni tĂ« nevojshme
  • shkruani njĂ« skript qĂ« analizon log-et dhe injoron ato log-e, modelet e tĂ« cilave keni shtuar nĂ« listĂ«n e injorimit

Ky qasje do t'ju lejojë me kalimin e kohës të përgatisni një listë injorimi të log-eve që nuk ju interesojnë dhe të lini vetëm ato që vërtet i konsideroni të rëndësishme.
Kjo ka funksionuar shkëlqyer për ne.

Monitorimi

Nuk është e pazakontë që në kompani mungon një sistem monitorimi. Mund të shpresoni, për shembull, në log-et, por pajisjet mund të 'vdesin' thjesht pa pasur mundësinë të 'flasin', ose paketa UDP e protokollit syslog mund të humbasë dhe të mos arrijë. Në përgjithësi, sigurisht, monitorimi aktiv është i rëndësishëm dhe i nevojshëm.

Dy shembuj më të kërkuar në praktikën time:

  • monitorimi i ngarkesĂ«s sĂ« kanaleve tĂ« komunikimit, lidhjeve kritike (p.sh., lidhje me ofruesit). Lejon tĂ« shihni pĂ«r herĂ« tĂ« parĂ« njĂ« problem tĂ« mundshĂ«m tĂ« degradimit tĂ« shĂ«rbimit pĂ«r shkak tĂ« humbjes sĂ« trafik e pĂ«r rrjedhojĂ« ta shmangni atĂ«.
  • grafikĂ«t, tĂ« ndĂ«rtuar mbi bazĂ«n e NetFlow. Ato lejojnĂ« qĂ« tĂ« gjenden lehtĂ«sisht anomalitĂ« nĂ« trafik dhe janĂ« shumĂ« tĂ« dobishme pĂ«r tĂ« zbuluar disa lloje tĂ« thjeshta, por thelbĂ«sore tĂ« sulmeve tĂ« hacker-Ă«ve.

ËshtĂ« e rĂ«ndĂ«sishme! Konfiguroni njoftimet SMS pĂ«r ngjarjet mĂ« kritike. Kjo pĂ«rfshin, si monitorimin ashtu dhe regjistrimin. NĂ«se nuk keni njĂ« turn tĂ« caktuar, njoftimet SMS gjithashtu duhet tĂ« arrijnĂ« edhe gjatĂ« orĂ«ve tĂ« pushimit.

Mendoni procesin në mënyrë që të mos zgjoni të gjithë inxhinierët. Ne kishim një inxhinier në turn për këtë.

Kontrolli i ndryshimeve

Sipër mendimit tim, nuk është domosdoshmëri të kontrolloni të gjitha ndryshimet. Por, me çdo rast, duhet të keni mundësinë të gjeni lehtësisht kush dhe pse bëri ndryshime të tilla në rrjet, nëse është e nevojshme.

Disa këshilla:

  • pĂ«rdorni sistemin e biletave pĂ«r pĂ«rshkrimin e detajuar tĂ« asaj qĂ« Ă«shtĂ« bĂ«rĂ« nĂ« kuadĂ«r tĂ« kĂ«saj bilete, pĂ«r shembull, duke kopjuar konfigurimin e aplikuar nĂ« biletĂ«
  • pĂ«rdorni mundĂ«sitĂ« e komenteve nĂ« pajisjet rrjeti (pĂ«r shembull, komenti i angazhimit nĂ« Juniper). Mund tĂ« shkruani numrin e biletĂ«s
  • pĂ«rdorni diff tĂ« backup-eve tuaj tĂ« konfigurimit

Ju mund ta pranoni këtë si një proces, duke i shqyrtuar çdo ditë të gjitha biletat për ndryshime.

Proceset

Ju duhet ta formalizoni dhe ta përshkruani proceset në ekipin tuaj. Nëse keni arritur në këtë pikë, ekipi juaj duhet të ketë tashmë të paktën proceset e mëposhtme:

Proceset e përditshme:

  • punimi me biletat
  • punimi me logĂ«t
  • kontrolli i ndryshimeve
  • lista e kontrollit tĂ« pĂ«rditshĂ«m

Proceset vjetore:

  • rinovimi i garancive, licencave

Proceset asinkrone:

  • reaksioni ndaj situatave tĂ« ndryshme emergjente

Përfundimi i pjesës së parë

Po ju vjen nĂ« mendje se e gjitha kjo nuk ka tĂ« bĂ«jĂ« me konfigurimin e rrjetit, dizenjimin, protokollet e rrjetit, drejtimin, apo sigurinë  Kjo Ă«shtĂ« diçka pĂ«rreth. Por kĂ«to, edhe pse ndoshta janĂ« tĂ« mĂ«rzitshme, janĂ« sigurisht elemente shumĂ« tĂ« rĂ«ndĂ«sishme tĂ« punĂ«s sĂ« njĂ« njĂ«sie rrjeti.

Si, si e shihni, nuk keni përmirësuar asgjë në rrjetin tuaj. Nëse kishte të dobëta në siguri, ato kanë mbetur, nëse kishte dizajn të keq, ai ka mbetur po ashtu. Deri sa të aplikoni aftësitë dhe njohuritë tuaja si inxhinier rrjeti, për të cilat ka kosto të konsiderueshme në kohë, përpjekje, dhe ndonjëherë edhe para. Por fillimisht duhet të krijoni (ose të forconi) themelin dhe pastaj të filloni ndërtimin.

PĂ«r mĂ«nyrĂ«n se si tĂ« kĂ«rkoni dhe tĂ« eliminoni gabimet, dhe pastaj tĂ« pĂ«rmirĂ«soni infrastrukturĂ«n tuaj – pĂ«r kĂ«tĂ« janĂ« pjesĂ«t e ardhshme.

Sigurisht, nuk është e nevojshme të bëni gjithçka radhazi. Koha mund të jetë kritike. Bëni paralelisht, nëse burimet lejojnë.

Dhe një shtesë e rëndësishme. Komunikoni, pyesni, këshillohuni me ekipin tuaj. Së fundi, ata janë ata që do e mbajnë dhe do ta realizojnë këtë.

Burimi: habr.com

Bleni hostim tĂ« besueshĂ«m pĂ«r faqe me mbrojtje nga DDoS, serverĂ« VPS VDS đŸ”„ Bleni hostim tĂ« besueshĂ«m pĂ«r faqe me mbrojtje nga DDoS, serverĂ« VPS VDS | ProHoster