Kuidas võtta oma võrguinfrastruktuur kontrolli alla. Eelmine peatükk. Säilitamine

See artikkel on esimene seerias „Kuidas võtta võrgu infrastruktuuri enda kontrolli alla“. Kõikide artiklite sisu ja lingid leiate siit. siit.

Ma usun, et on olemas piisavalt ettevõtteid, kus lihtne võrgu ülesseade ühe tunni või isegi ühe päeva jooksul ei ole kriitiline. Kahjuks või õnneks ei ole ma sellistes kohtades töötanud. Kuid võrgud on erinevad, nõuded on erinevad, lähenemisviisid on erinevad, ja igal juhul on allolev loetelu paljude jaoks tõenäoliselt „hädavajalik“.

Nii et alustavad tingimused.

Olete uues töökohas või olete edutatud või olete otsustanud oma kohustustele uue vaatenurga võtta. Ettevõtte võrgu juhtimine on teie vastutusalas. See on teie jaoks suur väljakutse ja uus, mis mõnevõrra õigustab selle artikli mentorpinda :). Loodan, et artikkel on kasulik ka igale võrguinsenerile.

Teie esimene strateegiline eesmärk on õppida vastupanu pakkuma entropiale ja säilitama teenuse taseme.

Palju allpool kirjeldatud ülesandeid saab lahendada erinevate vahenditega. Ma ei keskendu tehnilistele lahendustele, kuna sageli ei ole oluline, kuidas te teatud ülesande lahendasite, vaid see, kuidas te neid kasutate ja kas te neid üldse kasutate. Näiteks, teie professionaalselt seadistatud jälgimissüsteemist ei ole mõtet, kui te ei vaata sinna ja ei reageeri häiretele.

Seadmed

Esimese sammuna peate mõistma, kus on suurimad riskid.

Põhimõtteliselt võib see olla erinev. Las ma arvan, et kuskil võivad probleemid olla näiteks turvalisusega seotud, teisal aga teenuse järjepidevusega, ja võib-olla on veel midagi. Miks mitte?

Oletame, et selleks on siiski teenuse järjepidevus (nii on olnud kõigis ettevõtetes, kus olen töötanud).

Seega tuleb alustada seadmetest. Siin on nimekiri teemadest, millele tuleks tähelepanu pöörata:

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

Te peaksite arvestama võimalike rikete võimalustega, eriti seadmetega, mis kuuluvad teie kriitilisuse klassifikatsiooni tippu. Üldiselt alahinnatakse kahekordsete probleemide tõenäosust, vastasel juhul võivad teie lahendused ja tugi osutuda põhjendamatult kalliks, kuid juhul, kui tegemist on tõeliselt kriitiliste võrkelementidega, mille rike võib oluliselt mõjutada äri, peaksite ka sellele mõtlema.

Näide

Oletame, et räägime juurkytist andmekeskuses.

Kuna oleme kokku leppinud, et teenuse pidevus on kõige olulisem kriteerium, siis on mõistlik tagada selle seadme "kuum" varundamine (redundancy). Kuid see pole veel kõik. Peate samuti otsustama, kui kaua, juhul kui esimene switch rikki läheb, on teie jaoks vastuvõetav elada vaid ühe järelejäänud switchiga, sest on oht, et ka see rikneb.

Oluline! Te ei tohi seda küsimust ise lahendada. Peate kirjeldama riske, võimalikke lahendusi ja kulusid oma juhtimist või ettevõtte juhtimist. Otsuseid peavad tegema nemad.

Kui on otsustatud, et väikse tõenäosuse korral kahekordsest rikkest, on töö ühe lülitiga nelja tunni jooksul igati lubatav, siis võite lihtsalt valida vastava toe (mille korral varustus vahetatakse nelja tunni jooksul).

Aga risk, et seadmed ei kohaldata. Kahjuks sattusime kord sellisesse olukorda. Nelja tunni asemel sõitis varustus nädal!!!

Seetõttu on vaja arutada ka seda riski ning võib-olla oleks teie jaoks mõistlik osta veel üks lüliti (kolmas) ja hoida seda varus („külm“ varundamine) või kasutada laboratoorsetes eesmärkides.

Oluline! Koostage tabel kõigist teie toetustest koos lõppkuupäevadega ja lisage need kalendrisse, et vähemalt kuu enne saadetaks teile kiri, et peaksite hakkama muretsema toe pikendamise üle.

Te ei saa andestust, kui unustate toe pikendamist ja järgmisel päeval pärast selle lõppemist teie seadmed riknevad.

Hädaolukorrad

Mida iganes teie võrgus ei juhtuks, ideaaljuhul peaksite säilitama juurdepääsu oma võrguseadmetele.

Oluline! Teil peab olema konsooli juurdepääs kogu seadmele ning see juurdepääs ei tohi sõltuda andmeside võrgu töövõimest.

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

Kohustuslikult peab seal olema

• teave, mis on vajalik toe küsimise avamiseks müüja või integreerija poole
• teave, kuidas pääseda juurde kõigile seadmetele (konsool, haldus)

Samuti võib seal sisalduda ka muu kasulik teave, näiteks seadmete erinevate uuendamisprotseduuride kirjeldus ja kasulikud diagnostikakomandod.

Partnerid

Nüüd peate hindama partneritega seotud riske. Tavaliselt on need

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

Millised küsimused peaksite endalt küsima? Nagu ka seadmete puhul, tuleks kaaluda erinevaid hädaolukordi. Näiteks interneti teenuse pakkujate jaoks võib see olla midagi sellist:

• kuidas käituda, kui interneti teenusepakkuja X lõpetab mingil põhjusel teie teenuse pakkumise?
• kas teistel teenusepakkujatel on piisavalt ribalaiust?
• kui hea jääb ühendus?
• kui iseseisvad on teie interneti teenusepakkujad ja kas ühe neist tõsine rike toob kaasa probleeme teistele?
• kui palju optilisi sisendeid on teie andmekeskuses?
• kuidas käituda, kui üks sisenditest on täielikult hävitatud?

Sisendite osas, minu praktikates kahes erinevas ettevõttes, kahes erinevas andmekeskustes kaevandusmasin purustas kaevud ja meie optika pääses vaid ime läbi. See ei ole sugugi haruldane juhtum.

Ja loomulikult ei tohiks te mitte ainult neid küsimusi esitada, vaid, taas, kaasates juhtkonna, tagada sobiv lahendus igas olukorras.

Varukoopia

Järgmine prioriteet võib olla seadmete konfiguratsioonide varukoopia. Igal juhul on see väga oluline punkt. Ma ei hakka loetlema neid olukordi, kus te võite konfigureerimise kaotada; parem on regulaarselt varukoopiaid teha ja selle üle mitte mõelda. Regulaarne varukoopia võib olla kasulik ka muudatuste jälgimisel.

Oluline! Tehke varukoopia igapäevaseks. See pole nii suur andmemaht, et selle pealt kokku hoida. Hommikul peaks valves olev insener (või teie) saama süsteemilt aruande, milles on selgelt märgitud, kas varukoopia õnnestus või ei, ning juhul kui varukoopia ei õnnestunud, peab probleem olema lahendatud või peab looma ticketi (vt võrguosakonna protsesse).

Tarkvara versioonid

Küsimus, kas seadmete tarkvara uuendamine on vajalik või mitte, ei ole nii üheselt mõistetav. Ühelt poolt on vanades versioonides tuntud vead ja haavatavused, kuid teisalt ei pruugi uue tarkvara ülesupdate'imine olla alati valutult kulgev protsess, ning uued vead ja haavatavused võivad samuti ilmneda.

Siin tuleb leida optimaalne lahendus. Mitmed ilmnevad soovitused

• kasutada ainult stabiilseid versioone
• mitte elada täiesti vanade tarkvaraversioonide peal
• koosta tabel teabega, kus mis tarkvara asub
• aeg-ajalt lugege tarkvara haavatavuste ja probleemide aruandeid, ning kriitiliste probleemide korral tuleks mõelda uuendamisele

Selles etapis, omades seadmetele konsooli ligipääsu, teavet toe kohta ja uuendamise protseduuri kirjeldust, olete põhimõtteliselt selle sammu jaoks valmis. Ideeaalne on olukord, kus teil on laboriseade, kus saate kogu protseduuri testida, kuid kahjuks juhtub seda harva.

Kriitilise seadme korral võite pöörduda müüja toe poole, paludes neil aidata teid uuendamise protsessis.

Tiketisüsteem

Nüüd saate ringi vaadata. Teil on vaja kehtestada protsessid teiste osakondadega suhtlemiseks ja oma osakonna sees.

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

Piletisüsteem on tegelikult teie liides sise- ja välissuhtluseks, ning peate selle liidese piisava detailsusega kirja panema.

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

Näide

Alustame sellest, et sageli väljendavad juurdepääsu taotlejad oma soove arusaamatul võrguinseneri keeles, nimelt rakenduse keeles, näiteks: 'avan mulle juurdepääsu 1C'.

Seetõttu ei aktsepteerinud me kunagi selliseid soove otse sellistelt kasutajatelt.
Ja see oli esimene nõue.

• Juurdepääsu taotlused peavad tulema tehnilistelt osakondadelt (meie puhul unix, windows, abiteeninduse insenerid).

Teiseks nõudmiseks on see, et

• see juurdepääs peab olema protokollitud (tehnilise osakonna poolt, kellelt me selle taotluse saime) ja saame selle taotlusena lingi sellele protokollitud juurdepääsule.

Selle taotluse vorm peab olema meile arusaadav, see tähendab

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

Samuti peab olema märgitud

• kirjeldus, milleks see juurdepääs avatakse
• ajutine või püsiv (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 helpdesk)

Sel juhul loetakse selle juurdepääsu "omanikuks" osakonna juht, kes juurdepääsu algatas (raamatupidamine meie näites) ja ta vastutab selle eest, et selle osakonna juurdepääsude protokollimiseks mõeldud leht jääks ajakohaseks.

Logimine

See on midagi, milles 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 igapäevaselt
• planeeritud vaatluse (mitte hädaolukorra) korral võib piirduda kriitilisuse (severity) tasemete 0, 1, 2 kasutamisega ning lisada soovitud mustrid teistest tasemetest.
• kirjutage skript, mis analüüsib logisid ja ignoreerib neid logisid, mille mustrid olete ignoreerimisloendisse lisanud.

See lähenemine võimaldab aja jooksul koostada ignoreerimisloendi logidest, mis teid ei huvi, ja jätta alles ainult need, mida peate tõeliselt oluliseks.
Meil töötas see suurepäraselt.

Jälgimine

Pole harv nähtus, et ettevõttel puudub jälgimissüsteem. Võite, näiteks, loota logidele, kuid seadmed võivad lihtsalt "sureda", ilma et nad midagi "ütleksid", või UDP-pakett Syslog protokollis võib kaduda ja mitte kohale jõuda. Üldiselt on aktiivne jälgimine loomulikult oluline ja vajalik.

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

• sideteede, kriitiliste linkide koormuse jälgimine (näiteks ühendus teenusepakkujatega). Need võimaldavad proaktiivselt näha võimalikke probleemide tekkimist teenuse halvenemise tõttu liikluse kadumise tõttu ja vastavalt sellele ära hoida.
• NetFlow'i põhjal koostatud graafikud. Need võimaldavad hõlpsasti tuvastada liikluses esinevaid anomaaliaid ja on väga kasulikud mõnede lihtsate, kuid oluliste häkkerirünnakute avastamiseks.

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

Mõelge protsessile nii, et te ei ärataks kõiki insenere. Meil oli selleks olemas vahetuse insener.

Muutuste kontroll

Minu arvates ei ole kohustuslik kontrollida kõiki muutusi. Kuid igal juhul peaksite olema võimeline vajadusel hõlpsasti leidma, kes ja miks võrku muudatusi tegi.

Mõned nõuanded:

• kasutage piletisüsteemi selle üksikasjalikuks kirjelduseks, mis on selle pileti raames tehtud, näiteks kopeerides rakendatud seadistuse piletisse
• kasutage võimalusi täiendavate märkuste tegemiseks võrgu seadmetes (näiteks commit comment Juniperil). Saate märkida pileti numbri
• kasutage oma konfiguratsiooni varukoopiate diff'i

Saate selle sisestada protsessina, iga päev vaadates kõiki toimetusi muudatuste osas.

Protsessid

Te peate oma meeskonnas protsesse vormistama ja kirjeldama. Kui olete jõudnud sellesse etappi, peavad teie meeskonnas juba toimima vähemalt järgmised protsessid:

Iga päev toimuvad protsessid:

• toimetuste haldamine
• logide haldamine
• muudatuste jälgimine
• igal päeval kontrollnimekiri

Aastased protsessid:

• garantiide ja litsentside pikendamine

Asünkroonsed protsessid:

• reaktsioon erinevatele hädaolukordadele

Esimese osa kokkuvõte

Olete tähele pannud, et kõik see ei puuduta veel võrgukonfiguratsiooni, disaini, võrguprotokolle, suunamist ega turvalisust... See on midagi muud. Kuid need, kuigi võib-olla igavad, on kindlasti väga olulised elemendid võrguosakonna töös.

Nagu näete, ei ole te oma võrgus midagi parandanud. Kui turvaprobleeme oli, jäävad need alles; kui disain oli halb, jääb see samuti. Kuni te ei kasuta oma teadmisi ja oskusi võrguinsenerina, millele olete tõenäoliselt kulutanud palju aega, vaeva ja mõnikord ka raha. Kuid kõigepealt on vaja luua (või tugevdada) alus, ja alles seejärel hakata ehitama.

Kuidas vigu otsida ja kõrvaldada ning seejärel oma infrastruktuuri parandada – sellest räägivad järgmised osad.

Muidugi ei pea te kõike järjestikku tegema. Aeg võib olla kriitilise tähtsusega. Tehke paralleelselt, kui ressursid võimaldavad.

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

Allikas: habr.com