Šis straipsnis yra pirmasis iš straipsnių serijos „Kaip valdyti tinklo infrastruktūrą“. Galima rasti visų serijos straipsnių turinį ir nuorodas .
Pilnai pripažįstu, kad yra pakankamai daug įmonių, kuriose vienos valandos ar net vienos dienos tinklo prastovos nėra kritinės. Deja ar laimei, aš neturėjau galimybės dirbti tokiose vietose. Tačiau, žinoma, tinklai yra skirtingi, reikalavimai skiriasi, požiūriai skiriasi, tačiau vienaip ar kitaip toliau pateiktas sąrašas daugeliu atvejų iš tikrųjų bus „būtina padaryti“.
Taigi, pradinės sąlygos.
Esate naujame darbe, esate paaukštintas arba nusprendėte naujai pažvelgti į savo pareigas. Įmonės tinklas yra jūsų atsakomybės sritis. Jums tai daugeliu atžvilgių iššūkis ir naujiena, kas šiek tiek pateisina šio straipsnio mentorystės toną :). Tačiau tikiuosi, kad straipsnis taip pat gali būti naudingas bet kuriam tinklo inžinieriui.
Jūsų pirmasis strateginis tikslas – išmokti atsispirti entropijai ir išlaikyti teikiamų paslaugų lygį.
Daugelį toliau aprašytų problemų galima išspręsti įvairiomis priemonėmis. Techninio įgyvendinimo temos sąmoningai nekeliau, nes... iš principo dažnai ne taip svarbu kaip išsprendei tą ar kitą problemą, o svarbu kaip tu naudojiesi ir ar išvis naudoji. Pavyzdžiui, jūsų profesionaliai sukurta stebėjimo sistema yra mažai naudinga, jei į ją nežiūrite ir nereaguojate į įspėjimus.
įranga
Pirmiausia turite suprasti, kur yra didžiausia rizika.
Vėlgi, gali būti kitaip. Pripažįstu, kad kai kur, pavyzdžiui, tai bus saugumo klausimai, o kai kur – su paslaugos tęstinumu susiję klausimai, o kažkur – galbūt, dar kažkas. Kodėl gi ne?
Tarkime, kad būtų aišku, kad tai vis dar yra paslaugų tęstinumas (taip buvo visose įmonėse, kuriose dirbau).
Tada reikia pradėti nuo įrangos. Čia yra temų, į kurias reikia atkreipti dėmesį, sąrašas:
- įrangos klasifikavimas pagal kritiškumo laipsnį
- svarbios įrangos atsarginė kopija
- palaikymas, licencijos
Turite apgalvoti galimus gedimų scenarijus, ypač kai įranga yra jūsų kritiškumo klasifikacijos viršuje. Dažniausiai dvigubų problemų galimybė yra nepaisoma, kitu atveju jūsų sprendimas ir palaikymas gali nepagrįstai brangti, tačiau esant tikrai kritiniams tinklo elementams, kurių gedimas gali reikšmingai paveikti verslą, reikėtų apie tai pagalvoti.
Pavyzdys
Tarkime, kad kalbame apie šakninį jungiklį duomenų centre.
Kadangi sutarėme, kad paslaugų tęstinumas yra svarbiausias kriterijus, tikslinga užtikrinti „karštą“ šios įrangos atsarginę kopiją (redundanciją). Bet tai dar ne viskas. Taip pat turite nuspręsti, kiek laiko, sugedus pirmam jungikliui, jums priimtina gyventi tik su vienu likusiu jungikliu, nes yra rizika, kad suges ir jis.
Svarbu! Jūs neturite patys spręsti šio klausimo. Turite aprašyti rizikas, galimus sprendimus ir išlaidas vadovybei ar įmonės vadovybei. Jie turi priimti sprendimus.
Taigi, jei buvo nuspręsta, kad, atsižvelgiant į nedidelę dvigubo gedimo tikimybę, dirbti 4 valandas vienu jungikliu iš principo yra priimtina, galite tiesiog imtis atitinkamos paramos (pagal kurią įranga bus pakeista per 4 valandos).
Tačiau yra rizika, kad jie nepristatys. Deja, kartą atsidūrėme tokioje situacijoje. Vietoj keturių valandų technika keliavo savaitę!!!
Todėl ir šią riziką reikia aptarti ir, ko gero, būtų teisingiau įsigyti kitą jungiklį (trečią) ir laikyti jį atsarginių dalių pakuotėje („šalta“ atsarginė kopija) arba naudoti laboratorijos reikmėms.
Svarbu! Sukurkite visos turimos paramos skaičiuoklę su galiojimo datomis ir įtraukite ją į savo kalendorių, kad bent prieš mėnesį gautumėte el. laišką, kad turėtumėte pradėti nerimauti dėl paramos atnaujinimo.
Jums nebus atleista, jei pamiršite atnaujinti savo palaikymą ir kitą dieną po jo pabaigos jūsų aparatinė įranga nutrūks.
Avarinis darbas
Kad ir kas nutiktų jūsų tinkle, idealiu atveju turėtumėte išlaikyti prieigą prie tinklo įrangos.
Svarbu! Turite turėti konsolinę prieigą prie visos įrangos ir ši prieiga neturėtų priklausyti nuo vartotojo duomenų tinklo būklės.
Taip pat turėtumėte iš anksto numatyti galimus neigiamus scenarijus ir dokumentuoti būtinus veiksmus. Šio dokumento prieinamumas taip pat yra labai svarbus, todėl jis turėtų būti ne tik paskelbtas bendrame skyriaus šaltinyje, bet ir išsaugotas vietoje inžinierių kompiuteriuose.
Čia turi būti
- informacija, reikalinga norint atidaryti bilietą su pardavėjo arba integratoriaus palaikymu
- informacija apie tai, kaip pasiekti bet kokią įrangą (konsolę, valdymą)
Žinoma, jame gali būti ir kitos naudingos informacijos, pavyzdžiui, įvairios įrangos atnaujinimo procedūros aprašymas ir naudingos diagnostinės komandos.
partneriai
Dabar reikia įvertinti su partneriais susijusią riziką. Paprastai tai
- Interneto tiekėjai ir srauto mainų taškai (IX)
- ryšio kanalų teikėjai
Kokius klausimus turėtum užduoti sau? Kaip ir naudojant įrangą, reikia atsižvelgti į įvairius avarinius scenarijus. Pavyzdžiui, interneto tiekėjams tai gali būti kažkas panašaus:
- kas atsitiks, jei interneto tiekėjas X dėl kokių nors priežasčių nustos teikti jums paslaugą?
- Ar kiti paslaugų teikėjai turės jums pakankamai pralaidumo?
- Ar geras ryšys išliks?
- Kiek nepriklausomi yra jūsų interneto tiekėjai ir ar rimtas vieno iš jų gedimas sukels problemų su kitais?
- kiek optinių įėjimų jūsų duomenų centre?
- kas atsitiks, jei viena iš įėjimų bus visiškai sunaikinta?
Kalbant apie įvestis, mano praktikoje dviejose skirtingose įmonėse, dviejuose skirtinguose duomenų centruose, ekskavatorius sunaikino šulinius ir tik per stebuklą mūsų optika nenukentėjo. Tai nėra toks retas atvejis.
Ir, žinoma, reikia ne tik užduoti šiuos klausimus, bet, vėlgi, padedant vadovybei, pateikti priimtiną sprendimą bet kurioje situacijoje.
Atsarginė kopija
Kitas prioritetas gali būti įrangos konfigūracijų atsarginė kopija. Bet kokiu atveju tai labai svarbus momentas. Neišvardinsiu tų atvejų, kai galite prarasti konfigūraciją, geriau daryti atsargines kopijas ir apie tai negalvoti. Be to, reguliarios atsarginės kopijos gali būti labai naudingos stebint pokyčius.
Svarbu! Kasdien kurkite atsargines kopijas. Tai nėra toks didelis duomenų kiekis, kad būtų galima sutaupyti. Ryte budintis inžinierius (ar jūs) turėtų gauti iš sistemos ataskaitą, kurioje būtų aiškiai nurodyta, ar atsarginė kopija buvo sėkminga, ar ne, o jei atsarginė kopija buvo nesėkminga, reikia išspręsti problemą arba sukurti bilietą ( žr. tinklo skyriaus procesus).
Programinės įrangos versijos
Klausimas, ar verta atnaujinti įrangos programinę įrangą, nėra toks aiškus. Viena vertus, senos versijos yra žinomos klaidos ir pažeidžiamumai, tačiau, kita vertus, nauja programinė įranga, pirma, ne visada neskausminga atnaujinimo procedūra, antra, naujos klaidos ir pažeidžiamumai.
Čia reikia rasti geriausią variantą. Keletas akivaizdžių rekomendacijų
- įdiegti tik stabilias versijas
- Vis dėlto neturėtumėte gyventi su labai senomis programinės įrangos versijomis
- padarykite ženklą su informacija apie tai, kur yra tam tikra programinė įranga
- periodiškai skaitykite ataskaitas apie programinės įrangos versijų pažeidžiamumą ir klaidas, o iškilus kritinėms problemoms turėtumėte pagalvoti apie atnaujinimą
Šiame etape, turėdami konsolinę prieigą prie įrangos, informacijos apie palaikymą ir atnaujinimo procedūros aprašymą, iš esmės esate pasiruošę šiam veiksmui. Idealus variantas yra tada, kai turite laboratorinę įrangą, kurioje galite patikrinti visą procedūrą, bet, deja, tai neįvyksta dažnai.
Esant kritinei įrangai, galite susisiekti su pardavėjo palaikymo komanda ir paprašyti padėti jums atnaujinti.
Bilietų sistema
Dabar galite apsižvalgyti. Turite nustatyti sąveikos su kitais padaliniais ir skyriaus viduje procesus.
Galbūt to ir nereikia (pavyzdžiui, jei jūsų įmonė nedidelė), tačiau labai rekomenduočiau darbą organizuoti taip, kad visos išorinės ir vidinės užduotys eitų per bilietų sistemą.
Bilietų sistema iš esmės yra jūsų vidinio ir išorinio ryšio sąsaja, todėl šią sąsają turėtumėte aprašyti pakankamai išsamiai.
Paimkime svarbios ir bendros prieigos atidarymo užduoties pavyzdį. Aprašysiu algoritmą, kuris puikiai veikė vienoje iš įmonių.
Pavyzdys
Pradėkime nuo to, kad dažnai prieigos klientai savo norus suformuluoja tinklo inžinieriui nesuprantama kalba, būtent, programos kalba, pavyzdžiui, „duokite man prieigą prie 1C“.
Todėl mes niekada nepriėmėme užklausų tiesiogiai iš tokių vartotojų.
Ir tai buvo pirmasis reikalavimas
- prieigos prašymai turėtų būti gaunami iš techninių skyrių (mūsų atveju tai buvo „Unix“, „Windows“, pagalbos tarnybos inžinieriai)
Antrasis reikalavimas yra tas
- ši prieiga turi būti užregistruota (techninio skyriaus, iš kurio gavome šį prašymą), ir kaip užklausą gauname nuorodą į šią užregistruotą prieigą
Šio prašymo forma turi būti mums suprantama, t.y.
- užklausoje turi būti informacija apie tai, kuris potinklis ir prie kurio prieiga turi būti atidaryta, taip pat protokolas ir (tcp/udp atveju) prievadai
Ten taip pat turėtų būti nurodyta
- aprašymas, kodėl ši prieiga atidaryta
- laikina ar nuolatinė (jei laikina, iki kokios datos)
Ir labai svarbus momentas yra patvirtinimai
- iš skyriaus vedėjo, kuris inicijavo prieigą (pavyzdžiui, buhalteriją)
- iš techninio skyriaus vadovo, iš kur šis prašymas atėjo į tinklo skyrių (pavyzdžiui, pagalbos tarnybai)
Šiuo atveju šios prieigos „savininku“ laikomas prieigą inicijavusio skyriaus vadovas (mūsų pavyzdyje apskaita), ir jis yra atsakingas už tai, kad puslapis su prisijungusia prieiga prie šio skyriaus būtų atnaujintas. .
Miško ruoša
Tai yra kažkas, kuriame galite paskęsti. Bet jei norite įgyvendinti iniciatyvų požiūrį, turite išmokti susidoroti su šiuo duomenų antplūdžiu.
Štai keletas praktinių rekomendacijų:
- žurnalus reikia peržiūrėti kasdien
- planuojamos peržiūros (o ne kritinės situacijos) atveju galite apsiriboti 0, 1, 2 sunkumo lygiais ir pridėti pasirinktus modelius iš kitų lygių, jei manote, kad tai būtina.
- parašyti scenarijų, kuris analizuoja žurnalus ir ignoruoja tuos žurnalus, kurių šablonus įtraukėte į ignoravimo sąrašą
Šis metodas leis laikui bėgant sudaryti jums neįdomių žurnalų ignoruojamą sąrašą ir palikti tik tuos, kuriuos tikrai laikote svarbiais.
Mums tai puikiai pasiteisino.
Stebėjimas
Neretai įmonėje trūksta stebėjimo sistemos. Pavyzdžiui, galite pasikliauti žurnalais, tačiau įranga gali tiesiog „numirti“, nespėjusi nieko „pasakyti“, arba udp syslog protokolo paketas gali būti prarastas ir neatvykti. Apskritai, žinoma, aktyvus stebėjimas yra svarbus ir būtinas.
Du populiariausi mano praktikoje pavyzdžiai:
- ryšio kanalų, kritinių nuorodų apkrovos stebėjimas (pavyzdžiui, prisijungimas prie tiekėjų). Jie leidžia aktyviai pamatyti galimą paslaugų pablogėjimo problemą dėl srauto praradimo ir atitinkamai jos išvengti.
- Grafikai, pagrįsti NetFlow. Jie leidžia lengvai aptikti eismo anomalijas ir yra labai naudingi aptinkant kai kuriuos paprastus, bet reikšmingus įsilaužėlių atakų tipus.
Svarbu! Nustatykite SMS pranešimus apie svarbiausius įvykius. Tai taikoma ir stebėjimui, ir registravimui. Jei neturite budinčios pamainos, tuomet sms turėtų atvykti ir ne darbo valandomis.
Apsvarstykite procesą taip, kad nepažadintumėte visų inžinierių. Tam budėjo inžinierius.
Keisti valdymą
Mano nuomone, nebūtina kontroliuoti visų pokyčių. Bet bet kuriuo atveju, jei reikia, turėtumėte lengvai rasti, kas tinkle atliko tam tikrus pakeitimus ir kodėl.
Keli patarimai:
- naudokite bilietų sistemą, kad sužinotumėte, kas buvo padaryta su tuo bilietu, pavyzdžiui, nukopijuokite taikomą konfigūraciją į bilietą
- naudoti tinklo įrangos komentavimo galimybes (pavyzdžiui, komentuoti Juniper). Galite užsirašyti bilieto numerį
- naudokite savo konfigūracijos atsargines kopijas diff
Galite tai įgyvendinti kaip procesą, kasdien peržiūrėdami visus bilietus, ar nėra pakeitimų.
Procesai
Turite formalizuoti ir aprašyti procesus savo komandoje. Jei pasiekėte šį tašką, jūsų komandoje jau turėtų veikti bent šie procesai:
Kasdieniai procesai:
- darbas su bilietais
- darbas su rąstais
- pakeisti valdymą
- dienos čekio lapas
Metiniai procesai:
- garantijų, licencijų pratęsimas
Asinchroniniai procesai:
- reaguoti į įvairias avarines situacijas
Pirmosios dalies išvada
Ar pastebėjote, kad visa tai dar ne apie tinklo konfigūraciją, ne apie dizainą, ne apie tinklo protokolus, ne apie maršrutą, ne apie saugumą... Tai kažkas aplinkui. Bet tai, nors galbūt ir nuobodu, bet, žinoma, yra labai svarbūs tinklo padalinio darbo elementai.
Kol kas, kaip matote, nieko nepatobulinote savo tinkle. Jei buvo saugumo spragų, tai jos išliko, jei buvo blogas dizainas, tai išliko. Kol nepritaikėte savo, kaip tinklo inžinieriaus, įgūdžių ir žinių, kurioms greičiausiai išleidote daug laiko, pastangų, o kartais ir pinigų. Bet pirmiausia reikia sukurti (arba sustiprinti) pamatą, o tada pradėti statyti.
Toliau pateiktose dalyse bus paaiškinta, kaip rasti ir pašalinti klaidas bei patobulinti infrastruktūrą.
Žinoma, nereikia visko daryti iš eilės. Laikas gali būti kritiškas. Atlikite tai lygiagrečiai, jei leidžia ištekliai.
Ir svarbus papildymas. Bendraukite, klauskite, pasitarkite su savo komanda. Galų gale jie yra tie, kurie visa tai palaiko ir daro.
Šaltinis: www.habr.com