Kuidas võtta enda kontrolli alla oma võrguinfrastruktuur. Peatükk esimene. Hoia

See artikkel on esimene artiklite sarjast „Kuidas oma võrguinfrastruktuuri kontrolli alla võtta”. Sarja kõigi artiklite sisu ja lingid leiate siin.

Möönan täielikult, et on piisavalt palju ettevõtteid, kus ühe tunni või isegi ühepäevane võrguseisak pole kriitiline. Kahjuks või õnneks ei olnud mul võimalust sellistes kohtades töötada. Kuid loomulikult on võrgustikud erinevad, nõuded on erinevad, lähenemisviisid erinevad ja ometi on allolev loetelu ühel või teisel kujul paljudel juhtudel tegelikult kohustuslik.

Niisiis, algtingimused.

Olete uuel töökohal, olete saanud ametikõrgenduse või olete otsustanud oma kohustustele uue pilgu heita. Ettevõtte võrgustik on teie vastutusala. Sinu jaoks on see paljuski väljakutse ja uudne, mis mõneti õigustab selle artikli mentorlustooni :). Kuid ma loodan, et artikkel võib olla kasulik ka igale võrguinsenerile.

Teie esimene strateegiline eesmärk on õppida entroopiale vastu seista ja säilitada pakutava teenuse taset.

Paljusid allpool kirjeldatud probleeme saab lahendada erinevate vahenditega. Tehnilise teostuse teemat ma meelega ei tõstata, sest... põhimõtteliselt pole sageli nii oluline, kuidas sa selle või teise probleemi lahendasid, vaid oluline on see, kuidas sa seda kasutad ja kas sa seda üldse kasutad. Näiteks pole teie professionaalselt loodud jälgimissüsteemist suurt kasu, kui te seda ei vaata ega reageeri hoiatustele.

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

Kõigepealt peate mõistma, kus on suurimad riskid.

Jällegi võib see olla erinev. Möönan, et kuskil on need näiteks turvaprobleemid ja kuskil teenuse järjepidevusega seotud probleemid ja kuskil võib-olla midagi muud. Miks mitte?

Oletame, et see on selge, et see on ikkagi teenuse järjepidevus (see oli nii kõigis ettevõtetes, kus ma töötasin).

Seejärel peate alustama seadmetega. Siin on loetelu teemadest, millele tähelepanu pöörata:

• seadmete klassifitseerimine kriitilisuse astme järgi
• kriitiliste seadmete varundamine
• tugi, litsentsid

Peate läbi mõtlema võimalikud tõrkestsenaariumid, eriti kui seadmed on teie kriitilisuse klassifikatsiooni tipus. Tavaliselt jäetakse topeltprobleemide võimalus tähelepanuta, vastasel juhul võib teie lahendus ja tugi muutuda ebamõistlikult kalliks, kuid tõeliselt kriitiliste võrguelementide puhul, mille rike võib äri oluliselt mõjutada, tuleks sellele mõelda.

Näide

Oletame, et räägime andmekeskuse juurlülitist.

Kuna leppisime kokku, et teenuse järjepidevus on kõige olulisem kriteerium, siis on mõistlik pakkuda sellele seadmele “kuum” varukoopia (liias). Kuid see pole veel kõik. Samuti peate otsustama, kui kaua, kui esimene lüliti läheb katki, kas teil on vastuvõetav elada ainult ühe allesjäänud lülitiga, sest on oht, et ka see puruneb.

Tähtis! Te ei pea seda küsimust ise otsustama. Peate kirjeldama riske, võimalikke lahendusi ja kulusid juhtkonnale või ettevõtte juhtkonnale. Nad peavad tegema otsuseid.

Seega, kui otsustati, et kahekordse tõrke väikese tõenäosuse tõttu on 4-tunnine töötamine ühe lülitiga põhimõtteliselt vastuvõetav, võite lihtsalt võtta sobiva toe (selle kohaselt vahetatakse seadmed 4 tundi).

Kuid on oht, et nad ei jõua kohale. Kahjuks sattusime kunagi sellisesse olukorda. Varustus sõitis nelja tunni asemel nädala!!!

Seetõttu tuleb ka see risk läbi rääkida ja võib-olla on õigem osta mõni teine ​​lüliti (kolmas) ja hoida seda varuosade pakendis ("külm" varu) või kasutada seda laboratoorsetel eesmärkidel.

Tähtis! Tehke arvutustabel kõigist teie pakutavatest tugiteenustest koos aegumiskuupäevadega ja lisage see oma kalendrisse, et saaksite vähemalt kuu aega varem meili, et peaksite muretsema oma toe uuendamise pärast.

Teile ei anta andeks, kui unustate oma tuge uuendada ja järgmisel päeval pärast selle lõppu teie riistvara katkeb.

hädaabitööd

Mis iganes teie võrgus ka ei juhtuks, ideaalis peaksite säilitama juurdepääsu oma võrguseadmetele.

Tähtis! Teil peab olema konsoolijuurdepääs kõikidele seadmetele ja see juurdepääs ei tohiks sõltuda kasutaja andmevõrgu seisundist.

Samuti peaksite eelnevalt ette nägema võimalikke negatiivseid stsenaariume ja dokumenteerima vajalikud toimingud. Selle dokumendi kättesaadavus on samuti kriitiline, nii et seda ei tohiks mitte ainult osakonna jagatud ressurssi postitada, vaid ka kohalikult inseneride arvutitesse salvestada.

Seal peab olema

• müüja või integraatori toega pileti avamiseks vajalik teave
• teave selle kohta, kuidas jõuda mis tahes seadmete juurde (konsool, juhtimine)

Loomulikult võib see sisaldada ka muud kasulikku teavet, näiteks erinevate seadmete uuendamise protseduuri kirjeldust ja kasulikke diagnostikakäske.

partnerid

Nüüd tuleb hinnata partneritega seotud riske. Tavaliselt see

• Interneti-teenuse pakkujad ja liikluse vahetuspunktid (IX)
• sidekanalite pakkujad

Milliseid küsimusi peaksite endalt küsima? Nagu seadmete puhul, tuleb arvesse võtta erinevaid hädaolukorra stsenaariume. Näiteks Interneti-teenuse pakkujate jaoks võib see olla midagi sellist:

• mis juhtub, kui Interneti-teenuse pakkuja X lõpetab teile mingil põhjusel teenuse osutamise?
• Kas teistel pakkujatel on teie jaoks piisavalt ribalaiust?
• Kui heaks ühenduvus säilib?
• Kui sõltumatud on teie Interneti-teenuse pakkujad ja kas ühe tõsine katkestus põhjustab probleeme teistega?
• mitu optilist sisendit teie andmekeskuses?
• mis juhtub, kui üks sisenditest täielikult hävib?

Mis puudutab sisendeid, siis minu praktikas kahes erinevas ettevõttes, kahes erinevas andmekeskuses, hävitas ekskavaator kaevud ja ainult ime läbi meie optika ei kannatanud. See pole nii haruldane juhtum.

Ja loomulikult ei pea te mitte ainult neid küsimusi esitama, vaid jällegi juhtkonna toel pakkuma vastuvõetavat lahendust igas olukorras.

varukoopia

Järgmine prioriteet võib olla seadmete konfiguratsioonide varundamine. Igal juhul on see väga oluline punkt. Ma ei loetle neid juhtumeid, kui võite konfiguratsiooni kaotada, parem on teha regulaarselt varukoopiaid ja mitte sellele mõelda. Lisaks võivad regulaarsed varukoopiad olla muudatuste jälgimisel väga kasulikud.

Tähtis! Tehke varukoopiaid iga päev. See pole nii suur andmemaht, et selle pealt kokku hoida. Hommikul peaks valves olev insener (või teie) saama süsteemilt raporti, mis näitab selgelt, kas varundamine õnnestus või mitte ja kui varundamine ebaõnnestus, tuleks probleem lahendada või pilet luua ( vaata võrguosakonna protsesse).

Tarkvara versioonid

Küsimus, kas seadmete tarkvara tasub uuendada või mitte, pole nii selge. Ühest küljest on vanad versioonid teadaolevad vead ja haavatavused, kuid teisest küljest ei ole uus tarkvara esiteks alati valutu uuendamise protseduur, teiseks aga uued vead ja haavatavused.

Siin peate leidma parima võimaluse. Mõned ilmsed soovitused

• installige ainult stabiilsed versioonid
• Siiski ei tohiks te elada tarkvara väga vanade versioonide peal
• tehke silt teabega selle kohta, kus mõni tarkvara asub
• lugege perioodiliselt aruandeid tarkvaraversioonide haavatavuste ja vigade kohta ning kriitiliste probleemide korral peaksite mõtlema uuendamisele

Selles etapis, kui teil on konsooljuurdepääs seadmetele, teave toe kohta ja versiooniuuendusprotseduuri kirjeldus, olete põhimõtteliselt selleks sammuks valmis. Ideaalne variant on see, kui teil on laborivarustus, kus saate kogu protseduuri kontrollida, kuid kahjuks ei juhtu seda sageli.

Kriitilise varustuse korral võite võtta ühendust müüja toega ja paluda teid uuendamisel aidata.

Piletisüsteem

Nüüd saate ringi vaadata. Peate looma protsessid suhtlemiseks teiste osakondadega ja osakonna sees.

See ei pruugi olla vajalik (näiteks kui teie ettevõte on väike), kuid soovitan soojalt korraldada töö nii, et kõik välised ja sisemised ülesanded käiksid läbi piletisüsteemi.

Piletisüsteem on sisuliselt teie liides sise- ja välissuhtluseks ning te peaksite seda liidest piisavalt üksikasjalikult kirjeldama.

Võtame näiteks ühe olulise ja ühise juurdepääsu avamise ülesande. Kirjeldan algoritmi, mis ühes ettevõttes ideaalselt töötas.

Näide

Alustame sellest, et sageli sõnastavad juurdepääsukliendid oma soovid võrguinsenerile arusaamatus keeles, nimelt rakenduse keeles näiteks “anna juurdepääs 1C-le”.

Seetõttu pole me kunagi sellistelt kasutajatelt päringuid vastu võtnud.
Ja see oli esimene nõue

• juurdepääsutaotlused peaksid tulema tehnilistelt osakondadelt (meie puhul olid need unix, aknad, kasutajatoe insenerid)

Teine nõue on see

• see juurdepääs peab olema logitud (tehnilise osakonna poolt, kust selle taotluse saime) ja taotlusena saame lingi sellele logitud juurdepääsule

Selle päringu vorm peab olema meile arusaadav, s.t.

• päring peab sisaldama teavet selle kohta, milline alamvõrk ja millisele alamvõrgule peaks olema juurdepääs, samuti protokoll ja (tcp/udp puhul) pordid

Seal tuleks ka see ära näidata

• kirjeldus, miks see juurdepääs on avatud
• ajutine või alaline (kui ajutine, siis mis kuupäevani)

Ja väga oluline punkt on kooskõlastused

• juurdepääsu algatanud osakonna juhatajalt (näiteks raamatupidamine)
• tehnilise osakonna juhatajalt, kust see päring võrguosakonda tuli (näiteks kasutajatoele)

Sellisel juhul loetakse juurdepääsu "omanikuks" juurdepääsu algatanud osakonna juhataja (meie näites raamatupidamisarvestus) ja ta vastutab selle eest, et selle osakonna logitud juurdepääsuga leht oleks ajakohane. .

Logimine

See on midagi, millesse võite uppuda. Kuid kui soovite rakendada ennetavat lähenemisviisi, peate õppima, kuidas selle andmete üleujutusega toime tulla.

Siin on mõned praktilised soovitused:

• peate logisid iga päev üle vaatama
• planeeritud ülevaatuse (ja mitte hädaolukorra) korral saate piirduda raskusastmetega 0, 1, 2 ja lisada valitud mustreid teistelt tasemetelt, kui peate seda vajalikuks
• kirjutage skript, mis analüüsib logisid ja ignoreerib neid logisid, mille mustrid lisasite ignoreerimisloendisse

See lähenemine võimaldab teil aja jooksul luua eiramisloendi logidest, mis ei ole teile huvitavad, ja jätta ainult need, mida peate tõeliselt oluliseks.
See töötas meil suurepäraselt.

Jälgimine

Ei ole harvad juhud, kui ettevõttel puudub seiresüsteem. Võite näiteks tugineda logidele, kuid seadmed võivad lihtsalt "sureda", ilma et neil oleks aega midagi "ütelda", või udp syslogi protokolli pakett võib kaduda ega jõua kohale. Üldiselt on aktiivne jälgimine muidugi oluline ja vajalik.

Kaks kõige populaarsemat näidet minu praktikas:

• sidekanalite, kriitiliste linkide koormuse jälgimine (näiteks pakkujatega ühenduse loomine). Need võimaldavad teil ennetavalt näha liikluse kadumisest tulenevat võimalikku teenuse halvenemise probleemi ja vastavalt sellele seda vältida.
• graafikud, mis põhinevad NetFlow'l. Need muudavad liikluses anomaaliate leidmise lihtsaks ja on väga kasulikud mõningate lihtsate, kuid oluliste häkkerirünnakute tuvastamiseks.

Tähtis! Seadistage SMS-teavitused kõige kriitilisemate sündmuste jaoks. See kehtib nii seire kui logimise kohta. Kui sul ei ole valves vahetust, siis sms peaks saabuma ka väljaspool tööaega.

Mõelge protsess läbi nii, et mitte kõiki insenere üles äratada. Meil oli selleks valves insener.

Muuda juhtimist

Minu arvates ei ole vaja kõiki muudatusi kontrollida. Kuid igal juhul peaksite vajadusel saama hõlpsalt teada, kes ja miks võrgus teatud muudatusi tegi.

Mõned nõuanded:

• kasutage piletisüsteemi, et täpsustada, mida selle piletiga tehti, näiteks kopeerides rakendatud konfiguratsiooni piletisse
• kasutada võrguseadmetes kommenteerimisvõimalusi (näiteks kommenteerida Juniperis). Saate pileti numbri üles kirjutada
• kasutage oma konfiguratsiooni varukoopiate diff

Saate seda rakendada protsessina, vaadates iga päev kõiki pileteid muudatuste osas.

Protsessid

Peate oma meeskonnas protsessid vormistama ja kirjeldama. Kui olete selle punktini jõudnud, peaksid teie meeskonnas juba töötama vähemalt järgmised protsessid:

Igapäevased protsessid:

• piletitega töötamine
• palkidega töötamine
• muuta juhtimist
• igapäevane kontrollleht

Iga-aastased protsessid:

• garantiide pikendamine, litsentsid

Asünkroonsed protsessid:

• reageerimine erinevatele hädaolukordadele

Esimese osa kokkuvõte

Kas olete märganud, et see kõik ei puuduta veel võrgu konfiguratsiooni, mitte disaini, mitte võrguprotokolle, mitte marsruutimist ega turvalisust... See on midagi ümber. Kuid need, ehkki võib-olla igavad, on loomulikult võrgudivisjoni töö väga olulised elemendid.

Siiani, nagu näete, pole te oma võrgus midagi parandanud. Kui oli turvaauke, siis need jäid, kui halb disain, siis see jäi. Kuni olete rakendanud oma oskusi ja teadmisi võrguinsenerina, millele olete suure tõenäosusega kulutanud palju aega, vaeva ja mõnikord ka raha. Kuid kõigepealt peate looma (või tugevdama) vundamendi ja seejärel hakkama ehitama.

Järgmistes osades kirjeldatakse, kuidas vigu leida ja kõrvaldada ning seejärel oma infrastruktuuri täiustada.

Muidugi ei pea kõike järjestikku tegema. Aeg võib olla kriitiline. Kui ressursid võimaldavad, tehke seda paralleelselt.

Ja oluline täiendus. Suhtle, küsi, konsulteeri oma meeskonnaga. Lõpuks on nemad need, kes seda kõike toetavad ja teevad.

Allikas: www.habr.com