Kuidas võtta võrgu infrastruktuur oma kontrolli alla. Esimene peatükk. Säilitamine

See artikkel on esimene osa artiklite tsüklist "Kuidas võtta oma võrguinfrastruktuur kontrolli alla". Tsükli kõikide artiklite sisu ja lingid leiate siin.

Ma täiesti usun, et on piisavalt ettevõtteid, kus lihtne võrk ei ole tunnis või isegi päevas kriitiline. Kahjuks või õnneks ei ole mul olnud võimalust töötada sellistes kohtades. Kuid siiski, võrgud on erinevad, nõudmised on erinevad, lähenemised on erinevad ning sellegipoolest on allpool toodud loend paljuski peaaegu "peab tegema".

Nii et algtingimused.

Olete uues töökohas või olete tõusnud ametiredelil või olete otsustanud oma kohustustele uut vaatenurka anda. Ettevõtte võrk on teie vastutusala. See on teie jaoks paljuski väljakutse ja uus asi, mis veidi õigustab selle artikli nõustavat tooni :). Kuid loodan, et artikkel on kasulik ka igale võrguinsenerile.

Teie esimene strateegiline eesmärk on õppida vastanduma entropiale ja säilitada teenuse taseme.

Paljusid allpool kirjeldatud ülesandeid saab lahendada erinevate vahenditega. Ma ei tõsta teadlikult üles teemat tehnilisest teostusest, kuna sageli ei ole oluline, kuidas te mingit ülesannet lahendasite, vaid oluline on see, kuidas te seda kasutate ja kas te üldse kasutate. Näiteks ei ole teie professionaalselt üles seatud jälgimissüsteemist suurt kasu, kui te sinna ei vaata ja ei reageeri häiretele.

Varustus

Esmalt peate mõistma, kus on suurimad riskid.

Taaskord võib see olla erinev. Ma usun, et kuskil võivad need olla näiteks turvaküsimused, kuskil teenuse järjepidevusele seotud küsimused ja kuskil võib-olla veel midagi. Miks ka mitte?

Eeldame, et selguse huvides on see siiski teenuse järjepidevuse küsimus (nii oli kõigis ettevõtetes, kus mina töötasin).

Sel juhul tuleb alustada seadmetest. Siin on loetelu teemadest, millele tuleks tähelepanu pöörata:

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

Te peaksite läbi mõtlema võimalikud rikete variandid, eriti kriitilisuse tippklassides olevate seadmete osas. Tavaliselt alahinnatakse kaksteist probleemi, muidu võivad teie lahenduste ja toe kulud muutuda põhjendamatult kõrgeks. Kuid tõeliselt kriitiliste võrkelementide puhul, mille rike võib oluliselt mõjutada äri, peate seda samuti arvesse võtma.

Näide

Oletame, et räägime andmekeskuse juurswitchist.

Kuna oleme kokku leppinud, et teenuse järjepidevus on kõige olulisem kriteerium, on mõistlik tagada selle seadme "kuum" varukoopia (redundantsus). Kuid see ei ole veel kõik. Peate ka kindlaks määrama, kui kaua on vastuvõetav talitada ainult ühe järelejäänud switchiga, kui esimene peaks rikkega silmitsi seisma, arvestades, et on oht, et ka see võib rikki minna.

Oluline! Te ei tohi seda küsimust ise lahendada. Peate kirjeldama riske, võimalikke lahendusi ja kulusid oma juhtkonnale või ettevõtte juhtidele. Otsuste tegemise õigus kuulub neile.

Seega, kui on otsustatud, et väikese kaksteist probleemi tõenäosuse korral töötamine neli tundi ühe switchiga on põhimõtteliselt vastuvõetav, võite lihtsalt võtta vastava toe (mida pakutakse seadmete asendamiseks nelja tunni jooksul).

Kuid on oht, et seade ei pruugi kohale jõuda. Kahjuks oleme kord sellises olukorras olnud. Nelja tunni asemel sõitis seade nädala!!!

Seetõttu tuleb ka seda riski arutada ja võib-olla oleks mõistlik osta veel üks switch (kolmas) ja hoida seda varus ("külm" varukoopia) või kasutada katsetuste jaoks.

Oluline! Koostage tabel kõigist teie olemasolevatest tugedest, lõpetamise kuupäevadest ja lisage need kalendritesse, et vähemalt kuu enne saaksite teate, et peate hakkama hoolima toe pikendamisest.

Teile ei anta andeks, kui unustate toe pikendada, ja järgmisel päeval pärast selle lõppemist läheb teie seade rikki.

Hädaolukordade tööd

Mida iganes teie võrgus ei juhtuks, oleks ideaalne, et säilitaksite ligipääsu oma võrgu seadmetele.

Oluline! Teil peab olema konsooli juurdepääs kogu seadmedele ja see juurdepääs ei tohi sõltuda andmeedastusvõrgu töökindlusest.

Samuti peate ette nägema võimalikke negatiivseid stsenaariume ja dokumenteerima vajalikud tegevused. Selle dokumendi kättesaadavus on samuti kriitiline, seega peab see olema mitte ainult osakonna ühisel ressursil, vaid ka salvestatud inseneride arvutitesse.

Kindlasti peavad seal olema

• teave, mis on vajalik toega taotluse esitamiseks tarnija või integreerija jaoks
• teave, kuidas pääseda juurde igale seadmele (konsool, haldus)

Samuti võib seal sisalduda ka igasugust muud kasulikku teavet, näiteks erinevate seadmete täiendamise protseduuri kirjeldus ja kasulikud diagnostikakäsud.

Partnerid

Nüüd peate hindama partnereid puudutavaid riske. Üldjuhul on need

• internetiteenuse pakkujad ja liikluse vahetuspunktid (IX)
• sideteenuste pakkujad

Milliseid küsimusi peate endale esitama? Nagu seadmete puhul, peate vaatama erinevaid avariisid. Näiteks internetiteenuse pakkujate puhul võib see olla midagi sellist:

• kuidas, kui internetiteenuse pakkuja X lõpetab mingil põhjusel teie teenuse osutamise?
• kas teil jääb piisavalt ribalaiust ülejäänud pakkujatelt?
• kui hea jääb ühenduvus?
• kui sõltumatud on teie internetiteenuse pakkujad ja kas ühe tõsise hädaolu juhtumine võib põhjustada probleeme teistega?
• kui palju optilisi sisseviike on teie andmekeskuses?
• kuidas, kui üks sisseviik on täielikult hävinud?

Sisseviikide kohta, minu praktikas kahe erineva ettevõtte juures, kahe erineva andmesaalides kaevandaja lõhkus kaevu ja vaid ime läbi ei kahjustatud meie optikat. See pole teabest olles üldse haruldane juhtum.

Ja loomulikult peate mitte ainult esitama need küsimused, vaid taas, jah, tagama juhtkonna toe ning tagama igas olukorras vastuvõetava lahenduse.

Varukoopia

Järgmine prioriteet võiks olla seadmete konfiguratsioonide varundamine. Igatahes on see väga oluline aspekt. Ei hakka loetlema neid juhtumeid, kui võite konfiguratsiooni kaotada, parem on teha regulaarselt varukoopiaid ja mitte selle üle mõelda. Lisaks võib regulaarne varundamine olla väga kasulik muudatuste jälgimisel.

Oluline! Tehke varukoopia iga päev. See pole nii suur andmemaht, et selle pealt säästa. Hommikuti peaks hädaolukorra insener (või teie) saama süsteemilt aruande, kus on selgelt märgitud, kas varukoopia oli edukas või mitte; juhul, kui varukoopia ebaõnnestus, peab probleem olema lahendatud või peab olema loodud pilet (vt võrguosakonna protsesse).

Tarkvaraversioonid

Küsimus, kas tasub tarkvara riistvara uuendada, ei ole sugugi selge. Ühest küljest on vanadel versioonidel teadaolevad vead ja haavatavused, kuid teisest küljest ei ole uue tarkvara uuendamine alati valutuks protseduuriks, ning sellega võivad kaasneda uued vead ja haavatavused.

Siin on vaja leida optimaalne lahendus. Mõned ilmselged soovitused

• paigaldada ainult stabiilsed versioonid
• kuid ei tasu elada täiesti vanade tarkvaraversioonide peal
• koostage tabel, kus on infot selle kohta, milline tarkvara kus on
• loetlege aeg-ajalt haavatavuste ja vigade aruandeid tarkvaraversioonides ning äärmuslike probleemide korral tasub mõelda uuendusele

Sellel etapil, olles saanud konsooli juurdepääsu seadmele, teabe toele ja uuendamise protseduuri kirjelduse, olete põhimõtteliselt valmis selle sammuga liikuma. Ideaalne olukord on, kui teil on laboriseade, kus saate kogu protseduuri testida, kuid kahjuks juhtub see harva.

Kriitilise seadme puhul võite pöörduda müüja toe poole palvega aidata teid uuendamise läbiviimisel.

Piletisüsteem

Nüüd võite ümber vaadata. Teil on vaja korraldada sujuvad protsessid koostöös teiste osakondadega ja osakonna sees.

Võib-olla ei ole see kohustuslik (näiteks kui teie ettevõte on väike), kuid ma soovitaksin tungivalt korraldada töö nii, et kõik välised ja sisemised ülesanded läbiksid piletisüsteemi.

Piletisüsteem on põhimõtteliselt teie liides sisemiste ja väliste suhtluste jaoks, ja peate seda liidest piisava detailitasemega kirjeldama.

Võtame näiteks olulise ja sageli esineva ülesande juurdepääsu avamise. Kirjeldan algoritmi, mis töötas väga hästi ühes ettevõttes.

Näide

Alustame sellest, et sageli väljendavad tellijad oma juurdepääsu soove arusaamatus keeles, mis ei ole võrguinsenerile selge, nimelt rakenduse keeles, näiteks: "ava mulle juurdepääs 1C."

Seetõttu ei ole me kunagi võtnud selliseid päringuid otse vastu.
Ja see oli esimene nõue.

• Päringud juurdepääsuteenuste saamiseks peavad tulema tehnilistelt osakondadelt (meie puhul olid need unix, windows, helpdesk insenerid).

Teine nõue on see, et

• see juurdepääs peab olema protokolleeritud (tehnilise osakonna poolt, kellelt me selle päringu saime) ja me saame sellele päringule viitena lingi protokolleeritud juurdepääsule.

Selle päringu vorm peab olema meile arusaadav, st

• päring peab sisaldama teavet selle kohta, millisesse ja millisesse alamvõrku peab juurdepääs avama, samuti protokolli ja (tcp/udp puhul) porte.

Samuti peab seal olema märgitud

• kirjeldus, miks see juurdepääs avatakse.
• ajutine või pidev (kui ajutine, siis kuni millise kuupäevani).

Ja väga oluline punkt on heakskiidud

• osakonna juhilt, kes algatas juurdepääsu (näiteks raamatupidamisest).
• tehnilise osakonna juhilt, kellelt see päring tuli võrguosakonda (näiteks helpdeskist).

Sellega arvestades peetakse selle juurdepääsu "omanikuks" osakonna juhti, kes algatas juurdepääsu (raamatupidamine meie näites), ja ta vastutab selle eest, et selle osakonna protokolleeritud juurdepääsude leht oleks ajakohane.

Logimine

See on see, kuhu võib uppuda. Kuid kui soovite rakendada proaktiivset lähenemist, peate õppima selle andmevooga toime tulema.

Siin on mõned praktilised soovitused:

• logisid tuleks vaadata iga päev.
• plaanilise vaatamise korral (mitte hädaolukorra korral) võib piirduda kriitilisuse (severity) tasemete 0, 1, 2 ja lisada valitud mustrid teistelt tasemetelt, kui arvate, et see on vajalik.
• kirjutage skript, mis analüüsib logisid ja ignoreerib neid logisid, mille mustrid olete lisanud ignoreerimisnimekirja.

See lähenemine võimaldab aja jooksul koostada logide ignoreerimisnimekirja, mis teid ei huvita, ja jätta alles ainult need, mida peate tõeliselt olulisteks.
Meil töötas see suurepäraselt.

Jälgimine

Pole pole on tavaline, et ettevõttes puudub jälgimissüsteem. Võite näiteks loota logidele, kuid seadmed võivad lihtsalt 'sureda', enne kui nad midagi 'ütlevad', või UDP-pakett syslog-protokollis võib kaduma minna ja mitte kohale jõuda. Ühesõnaga, aktiivne jälgimine on oluline ja vajalik.

Kaks kõige nõutumad näidet minu praktikas:

• sidekanalite, kriitiliste linkide määramine (näiteks ühendused teenusepakkujatega). Need võimaldavad proaktiivselt näha potentsiaalset teenuse halvenemise probleemi liikluse kadumise tõttu ja seega selle vältimist.
• grafikud, mis on koostatud NetFlow'i põhjal. Need võimaldavad hõlpsalt leida anomaaliaid liikluses ja on väga kasulikud mõne lihtsa, kuid olulise tüüpi häkkimisrünnete avastamiseks.

Oluline! Seadke SMS-teavitused kõige kriitilisemate sündmuste jaoks. See kehtib nii jälgimise kui ka logimise kohta. Kui teil ei ole valvetöötajat, siis SMS-d peaksid tulema ka töövälisel ajal.

Kavandage protsess nii, et te ei ärataks kõiki insenere. Meil oli selleks valvetöötaja.

Muudatuste kontroll

Minu arvates ei ole vajalik jälgida kõiki muudatusi. Kuid igal juhul peate olema võimeline vajadusel lihtsalt leidma, kes ja miks tegi teatud muudatusi võrgus.

Mõned nõuanded:

• kasutage piletisüsteemi, et detailsemalt kirjeldada, mida selle piletiga seoses tehti, näiteks kandes rakendatud konfiguratsiooni piletisse sisse
• kasutage kommentaarivõimalusi võrguseadmestikus (näiteks commit comment Juniperis). Saate märkida piletinumbri
• kasutage oma konfiguratsiooni varukoopiate diff'i

Saate seda protsessina sisse viia, vaadates igapäevaselt läbi kõik piletid muudatuste osas.

Protsessid

Peate formaliseerima ja kirja panema oma meeskonna protsessid. Kui olete selle kohale jõudnud, peaks teie meeskonnas juba töötama vähemalt järgmised protsessid:

Igapäevased protsessid:

• piletitega töötamine
• logidega töötamine
• muudatuste jälgimine
• iga päev kontrollimeelist

Iga-aastased protsessid:

• garantii ja litsentside pikendamine

Asünkroonsed protsessid:

• reaktsioon erinevatele hädaolukordadele

Esimese osa kokkuvõte

Olete tähele pannud, et kõik see ei ole veel netikonfiguratsioonist, disainist, võrguprotokollidest, suunamisest ega turvalisusest... See on midagi muud. Aga kuigi need võivad tunduda igavad, on need kindlasti väga olulised võrku toetava osakonna töö osad.

Hetkel, nagu näete, ei ole te oma võrgus midagi parandanud. Kui turvahaavad olid olemas, siis need on endiselt seal; kui disain oli halb, siis see on endiselt halb. Te ei ole rakendanud oma oskusi ja teadmisi võrginsenerina, millele on tõenäoliselt kulutatud palju aega, vaeva ja mõnikord ka raha. Aga kõigepealt tuleb luua (või tugevdada) alus, ja siis saate hakata ehitama.

Järgnevates osades räägitakse sellest, kuidas vigu leida ja parandada, ning kuidas oma infrastruktuuri täiustada.

Muidugi ei pea kõike tegema järjest. Aeg võib olla kriitiline. Tehke seda paralleelselt, kui ressursid lubavad.

Ja oluline lisandus. Suhelge, küsige, arutage oma meeskonnaga. Lõppude lõpuks peavad nemad kõike seda toetama ja teostama.

Allikas: habr.com