ProHoster > Blog > Administrim > Si ta kontrolloni infrastrukturën tuaj rrjetore. Kreu i parë. Ruajtja

Si ta kontrolloni infrastrukturën tuaj rrjetore. Kreu i parë. Ruajtja

Ky kjo artikull është i pari në ciklin e artikujve "Si të kontrolloni infrastrukturen e rrjetit tuaj". Përmbajtja e të gjithë artikujve të ciklit dhe lidhjet mund të gjenden këtu.

E pranoj se ekzistojnë mjaft kompani ku një rrjet i thjeshtë për një orë ose edhe një ditë nuk është kritik. Më vjen keq ose me fat, por nuk kam punuar në një vend të tillë. Megjithatë, rrjetet janë të ndryshme, kërkesat janë të ndryshme, qasjet janë të ndryshme, dhe megjithatë, në një formë ose tjetër, lista e mëposhtme në shumë raste do të jetë në fakt "e domosdoshme".

Pra, kushtet fillestare.

Jeni në një vend të ri pune ose keni marrë një ngjitje ose keni vendosur të shikoni ndryshe përgjegjësitë tuaja. Rrjeti i kompanisë është zona juaj e përgjegjësisë. Për ju, kjo është shumë një sfidë dhe një e re, që ndihmon për të justifikuar tonin mentorues të këtij artikulli :). Por, shpresoj se artikulli do të jetë gjithashtu i dobishëm për çdo inxhinier rrjeti.

Objektivi juaj i parë strategjik është të mësoni si t'i bëni ballë entropisë dhe të mbani nivelin e shërbimit të ofruar.

Shumë nga detyrat e përshkruara më poshtë mund të zgjidhen me mjete të ndryshme. Qëllimisht nuk e ngrej temën e implementimit teknik, sepse shpesh nuk ka rëndësi si e zgjidhni një detyrë të caktuar, por rëndësi ka ajo se si e përdorni atë dhe nëse e përdorni fare. Nuk ka asnjë dobi, për shembull, nga sistemi juaj i monitorimit të ndërtuar profesionalisht, nëse nuk e kontrolloni dhe nuk reagoni ndaj alerteve.

Pajisje

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

Përsëri, kjo mund të ndryshojë. Pranoj se diku, për shembull, këto do të jenë çështje sigurie, diku do të jenë çështje të lidhura me vazhdimësinë e shërbimit, dhe diku ndoshta do të jetë diçka tjetër. Pse jo?

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

Atëherë duhet të filloni me pajisjet. Këtu është lista e temave që duhet t'i kushtoni vëmendje:

  • klasifikimi i pajisjeve sipas shkallĂ«s sĂ« kritikĂ«s
  • rezervimi i pajisjeve kritike
  • mbĂ«shtetje, licenca

Duhet të keni parasysh mundësitë për defekte, veçanërisht për pajisjet që janë të vendosura në nivelin më të lartë të klasifikimit të rëndësisë. Zakonisht, nënvlerësohet probabiliteti i problemeve të dyfishta, përndryshe zgjidhja juaj dhe mbështetjeja mund të bëhen të paarsyeshme të shtrenjta, por në rastin e elementeve të vërtetë kritikë të rrjetit, dështimi i të cilëve mund të ndikojë ndjeshëm në biznes, duhet të mendoni edhe për këtë.

Shembulli

Supozoni se po flasim për ndërprerësin rrënjor në qendrën e të dhënave.

Të supozuar se kemi rënë dakord se vazhdimësia e shërbimit është kriteri më i rëndësishëm, atëherë është e arsyeshme të sigurohet rezervimi "në gjendje të ngrohtë" (redundancy) i kësaj pajisjeje. Por kjo nuk është e gjitha. Ju gjithashtu duhet të përcaktoni se sa kohë, në rast se dështimi i ndërprerësit të parë, është e pranueshme për ju për të jetuar vetëm me një tjetër të mbetur, pasi ekziston rreziku që edhe ai të dështojë.

E rëndësishme! Ju nuk duhet ta zgjidhni këtë çështje vetëm. Duhet t'i përshkruani rreziqet, zgjidhjet e mundshme dhe kostot drejt menaxhmentit tuaj ose drejt menaxhmentit të kompanisë. Ata duhet të marrin vendime.

Pra, nëse është vendosur që, me kushtin e probabilitetit të vogël të dështimit të dyfishtë, puna për 4 orë me një ndërprerës është, në thelb, e pranueshme, atëherë ju thjesht 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ë mund të mos e dorëzojnë. Fatkeqësisht, njëherë na ndodhi në një situatë të tillë. Në vend të katër orëve, pajisja udhëhoqi për një javë!!!

Prandaj, ky rrezik gjithashtu duhet të diskutohet dhe ndoshta do të ishte më e drejtë për ju të blini një tjetër ndërprerës (të tretë) dhe ta mbani atë në ZIP («rezervimi i ftohtë») ose ta përdorni për qëllime laboratorike.

E rëndësishme! Hartoni 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ështetjen dhe ditën pas skadimit, pajisja juaj do të dështojë.

Punë emergjente

ÇfarĂ«do qĂ« tĂ« ndodhĂ« nĂ« rrjetin tuaj, nĂ« mĂ«nyrĂ« ideale, ju duhet tĂ« ruani qasje nĂ« pajisjet tuaja rrjet.

ËshtĂ« e rĂ«ndĂ«sishme! Ju duhet tĂ« keni qasje nĂ« konsolĂ« nĂ« tĂ« gjithĂ« pajisjet dhe kjo qasje nuk duhet tĂ« varet nga funksionaliteti i rrjetit tĂ« transmetimit tĂ« tĂ« dhĂ«nave (data).

Po ashtu, ju duhet të parashikoni skenarët negativë të mundshëm dhe të dokumentoni veprimet e nevojshme. Disponueshmëria e këtij dokumenti është gjithashtu kritike, prandaj ai duhet të jetë jo vetëm në një burim të përbashkët për sektorin, por gjithashtu të ruhet lokal në kompjuterët e inxhinierëve.

Në mënyrë që të jetë e detyrueshme, atje duhet të ketë

  • informacionin e nevojshĂ«m pĂ«r tĂ« hapur njĂ« kĂ«rkesĂ« nĂ« mbĂ«shtetje nga furnizuesi ose integruesi
  • informacion se si tĂ« aksesoni çdo pajisje (konsolĂ«, menaxhim)

Po ashtu, natyrisht, mund të përfshihet çdo informacion tjetër të dobishëm, për shembull, 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 që lidhen me partnerët. Zakonisht, këto janë

  • furnizuesit e internetit dhe pikĂ«t e kĂ«mbimit tĂ« trafikut (IX)
  • furnizuesit e kanaleve tĂ« komunikimit

Cilat pyetje duhet t'i bëni vetes? Ashtu si në rastin e pajisjeve, duhet të shqyrtoni situata të ndryshme emergjente. Për shembull, për furnizuesit e internetit, mund të jetë e tillë:

  • çfarĂ« do tĂ« ndodhte nĂ«se furnizuesi i internetit X ndalon papritur shĂ«rbimin pĂ«r ndonjĂ« arsye?
  • a do t'ju mjaftojĂ« bandwith-i i furnizuesve tĂ« tjerĂ«?
  • sa e mirĂ« do tĂ« mbetet lidhja?
  • sa tĂ« pavarur janĂ« furnizuesit tuaj tĂ« internetit dhe a do tĂ« shkaktojĂ« njĂ« fatkeqĂ«si e rĂ«ndĂ« e njĂ«rit prej tyre probleme me tĂ« tjerĂ«t?
  • sa shumĂ« hyrje optike ka nĂ« qendrĂ«n tuaj tĂ« tĂ« dhĂ«nave?
  • çfarĂ« do tĂ« ndodhte nĂ«se njĂ« nga hyrjet do tĂ« shkatĂ«rrohej plotĂ«sisht?

Mbi hyrjet, në praktikën time në dy kompani të ndryshme, në dy të ndryshme qendrat e të dhënave një ekskavator shkatërroi kanale dhe vetëm me fat na u ndihmua optika jonë. Nuk është një rast kaq i rrallë.

Natyrisht, ju duhet jo vetëm të bëni këto pyetje, por që në të njëjtën kohë, me mbështetje nga menaxhmenti, të siguroheni për një zgjidhje të pranueshme në çdo situatë.

Backup

Prioriteti tjetër duhet të jetë backup-i i konfigurimeve të pajisjeve. Në çdo rast, kjo është një çështje shumë e rëndësishme. Nuk do të përmend rastet kur mund të humbni konfigurimin, është më mirë ta bëni backup rregullisht dhe të mos mendoni për këtë. Për më tepër, backup-i i rregullt mund të jetë shumë i dobishëm në kontrollimin e ndryshimeve.

ËshtĂ« e rĂ«ndĂ«sishme! BĂ«ni kopje rezervĂ« çdo ditĂ«. Nuk Ă«shtĂ« njĂ« volum kaq i madh tĂ« dhĂ«nash sa tĂ« kurseni pĂ«r kĂ«tĂ«. NĂ« mĂ«ngjes, inxhinieri nĂ« detyrĂ« (apo ju) duhet tĂ« marrĂ« njĂ« raport nga sistemi, nĂ« tĂ« cilin shprehet qartĂ« nĂ«se kopjimi rezervĂ« ishte i suksesshĂ«m apo jo, dhe nĂ« rastin e njĂ« kopjimi rezervĂ« tĂ« dĂ«shtuar problemi duhet tĂ« zgjidhet ose tĂ« krijohet njĂ« biletĂ« (shihni proceset e departamentit tĂ« rrjetit).

Versionet e softuerit

Pyetja nëse duhet ose jo të përmirësohet softueri i pajisjeve nuk është aq e thjeshtë. Nga njëra anë, versionet e vjetra kanë të njohura defekte dhe vulnerabilitete, por nga ana tjetër, softueri i ri nuk është gjithmonë një procedurë e lehtë për t'u përmirësuar, dhe gjithashtu sjell defekte dhe vulnerabilitete të reja.

Këtu është e nevojshme të gjendet zgjidhja më optimale. Disa rekomandime të dukshme

  • tĂ« instaloni vetĂ«m versionet e stabilizuara
  • nuk duhet tĂ« jetoni pĂ«rgjithmonĂ« nĂ« versionet shumĂ« tĂ« vjetra tĂ« softuerit
  • pĂ«rgatitni njĂ« tabelĂ« me informacionin se ku ndodhet cila-software
  • lexoni periodikisht raportet pĂ«r vulnerabilitetet dhe defektet nĂ« versionet e softuerit dhe nĂ« rast tĂ« problemeve kritike duhet tĂ« mendoni pĂ«r njĂ« pĂ«rmirĂ«sim

Në këtë fazë, duke pasur akses në konsolë të pajisjeve, informacionin për mbështetje dhe përshkrimin e procedurës së përmirësimit, ju jeni, në principe, gati për këtë hap. Opcioni ideal është kur keni pajisje laboratorike ku mund të provoni të gjithë procedurën, por fatkeqësisht, kjo nuk ndodh shpesh.

Në rast të pajisjeve kritike, mund të kontaktoni mbështetjen e ofruesit me kërkesën për ndihmë në zhvillimin e përmirësimit.

Sistemi i biletave

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

Ndoshta kjo nuk është e detyrueshme (për shembull, nëse kompania juaj është e vogël), por unë do të rekomandoja shumë të organizoni punën në një mënyrë që të gjitha detyrat e jashtme dhe të brendshme të kalojnë përmes sistemit të biletave.

Sistemi i biletave është në të vërtetë ndërfaqja juaj për komunikimet e brendshme dhe të jashtme, dhe ju duhet të përshkruani këtë ndërfaqe me një nivel të mjaftueshëm detaji.

Le të shqyrtojmë për shembull një detyrë të rëndësishme dhe të zakonshme për hapjen e aksesit. Do të përshkruaj algoritmin që ka funksionuar shkëlqyer në një nga kompanitë.

Shembulli

SĂ« pari, shpeshherĂ« klientĂ«t e aksesit e formulojnĂ« dĂ«shirĂ«n e tyre nĂ« njĂ« gjuhĂ« tĂ« paqartĂ« pĂ«r inxhinierĂ«t e rrjetit, konkretisht, nĂ« gjuhĂ«n e aplikacionit, pĂ«r shembull, “mĂ« hapni aksesi nĂ« 1C”.

Prandaj, ne kurrë nuk kemi pranuar kërkesat drejtpërdrejt nga këta përdorues.
Dhe kjo ishte kërkesa e parë.

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

Kërkesa e dytë është se

  • ky akses duhet tĂ« jetĂ« i protokolluar (nga departamenti teknik nga i cili kemi marrĂ« kĂ«tĂ« kĂ«rkesĂ«) dhe si kĂ«rkesĂ« ne marrim njĂ« lidhje nĂ« kĂ«tĂ« akses tĂ« protokolluar.

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

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

Po ashtu, aty duhet të specifikohet

  • pĂ«rshkrimi se pĂ«rse po hapet ky akses.
  • i pĂ«rkohshĂ«m apo i pĂ«rhershĂ«m (nĂ«se Ă«shtĂ« pĂ«rkohshĂ«m, deri nĂ« cilĂ«n datĂ«).

Dhe një pikë shumë e rëndësishme është miratimet

  • nga menaxheri i departamentit qĂ« iniciativĂ« aksesin (pĂ«r shembull, nga llogaritĂ«).
  • nga menaxheri i departamentit teknik, nga ku ka ardhur kjo kĂ«rkesĂ« nĂ« departamentin e rrjetit (pĂ«r shembull, helpdesk).

Në të njëjtën kohë, "pronari" i këtij akses është menaxheri i departamentit që iniciativë aksesin (megjithëse në këtë rast, llogaritë), dhe ai është përgjegjës që faqja me akseset e protokolluara për këtë departament të mbetet e saktë.

Regjistrimi

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 informacioni.

Ja disa rekomandime praktike:

  • duhet tĂ« shikoni logĂ«t çdo ditĂ«.
  • nĂ« rastin e njĂ« shqyrtimi tĂ« planifikuar (dhe jo situatave 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 gjykoni tĂ« nevojshme.
  • shkruani njĂ« skript, qĂ« analizojnĂ« logĂ«t dhe injorojnĂ« ato logĂ«, modelet e tĂ« cilave i keni shtuar nĂ« listĂ«n e injorimit.

Ky qasje do të lejojë me kalimin e kohës të krijoni një listë injorimi të logëve që nuk ju interesojnë dhe të mbani vetëm ato që vërtet i konsideroni të rëndësishme.
Kjo ka funksionuar shkëlqyeshëm për ne.

Monitorimi

Nuk është çudi kur një kompani nuk ka një sistem monitorimi. Ju mund të shpresoni, për shembull, në log-et, por aparatura mund të "vdekur", pa arritur të "thotë" ndonjë gjë, 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 shembujt më të kërkuar në praktiken time:

  • monitorimi i ngarkesĂ«s sĂ« lidhjeve tĂ« komunikacionit, lidhjet kritike (pĂ«r shembull, lidhjet me ofruesit). KĂ«to lejojnĂ« qĂ« tĂ« shihni proaktivisht njĂ« problem tĂ« mundshĂ«m tĂ« degradimit tĂ« shĂ«rbimit pĂ«r shkak tĂ« humbjes sĂ« trafikut dhe pĂ«r pasojĂ«, ta shmangni atĂ«.
  • grafiket e ndĂ«rtuara nĂ« bazĂ« tĂ« NetFlow. Ato lejojnĂ« tĂ« gjeni lehtĂ«sisht anomalitĂ« nĂ« trafik dhe janĂ« shumĂ« tĂ« dobishme pĂ«r zbulesĂ«n e disa llojeve tĂ« thjeshta, por thelbĂ«sore tĂ« sulmeve kibernetike.

ËshtĂ« e rĂ«ndĂ«sishme! Konfiguroni njoftimet SMS pĂ«r ngjarjet mĂ« kritike. Kjo vlen si pĂ«r monitorimin ashtu edhe pĂ«r regjistrimin. NĂ«se nuk keni njĂ« ekip roje, atĂ«herĂ« SMS-tĂ« gjithashtu duhet tĂ« vijnĂ« edhe gjatĂ« orĂ«ve tĂ« natĂ«s.

Mendoni procesin në mënyrë që të mos zgjoheni të gjithë inxhinierët. Ne patëm një inxhinier në roje për këtë.

Kontrolli i ndryshimeve

Sipas mendimit tim, nuk është e nevojshme të kontrolloni të gjitha ndryshimet. Por, në çdo rast, duhet të keni mundësinë që lehtësisht të gjeni kush dhe përse bëri këto ose ato ndryshime në rrjet.

Disa këshilla:

  • pĂ«rdorni sistemin e biletave pĂ«r pĂ«rshkrimin e detajuar tĂ« asaj qĂ« u bĂ« 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 e rrjetit (pĂ«r shembull, commit comment nĂ« Juniper). Mund tĂ« shkruani numrin e biletĂ«s
  • pĂ«rdorni differencĂ«n e backup-eve tuaja tĂ« konfigurimit

Mund ta futni këtë si proces, duke kontrolluar çdo ditë të gjitha biletat për ndryshime.

Proceset

Duhet të formalizoni dhe përshkruani proceset në ekipin tuaj. Nëse keni arritur në këtë moment, atëherë në ekipin tuaj tashmë duhet të funksionojnë të paktën proceset e mëposhtme:

Proceset e përditshme:

  • punimi me biletat
  • punimi me log-et
  • kontrolli i ndryshimeve
  • kontrolli i pĂ«rditshĂ«m

Proceset vjetore:

  • riparimi i garancive, licencave

Proceset asinkrone:

  • reaksioni ndaj situatave tĂ« ndryshme emergjente

Përfundimi i pjesës së parë

A keni vĂ«nĂ« re se tĂ« gjitha kĂ«to nuk janĂ« pĂ«r konfigurimin e rrjetit, as pĂ«r dizajnin, as pĂ«r protokollet e rrjetit, as pĂ«r rrugĂ«zimin, as pĂ«r sigurinë  ËshtĂ« diçka pĂ«rreth. Por kĂ«to, ndonĂ«se ndoshta tĂ« mĂ«rzitshme, janĂ« padyshim elemente shumĂ« tĂ« rĂ«ndĂ«sishme tĂ« funksionimit tĂ« njĂ« njĂ«sie rrjeti.

Derisa, siç e shihni, nuk keni përmirësuar asgjë në rrjetin tuaj. Nëse kishte dobësi në siguri, ato janë ende aty, nëse kishte një dizajn të dobët, ai është ende aty. Derisa nuk keni aplikuar aftësitë dhe njohuritë tuaja si inxhiner rrjeti, për të cilat ndoshta keni shpenzuar shumë kohë, përpjekje, dhe ndonjëherë edhe para. Por fillimisht duhet krijuar (ose forcuar) themeli, e pastaj mund të filloni me ndërtimin.

Rreth mĂ«nyrĂ«s sĂ« kĂ«rkimit dhe zgjidhjes sĂ« gabimeve, dhe mĂ« pas pĂ«r pĂ«rmirĂ«simin e infrastrukturĂ«s tuaj – pĂ«r kĂ«tĂ« do tĂ« flasim nĂ« pjesĂ«t e ardhshme.

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

Dhe një shtesë e rëndësishme. Komunikoni, pyesni, konsultohuni me ekipin tuaj. Në fund të fundit, ata janë ata që do ta mbajnë dhe do ta zbatojnë gjithë këtë.

Burimi: habr.com

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