Бұл мақала «Желілік инфрақұрылымды қалай басқаруға болады» мақалалар сериясының біріншісі. Сериядағы барлық мақалалардың мазмұнын және сілтемелерді табуға болады .
Желінің бір сағат немесе тіпті бір күндік тоқтап қалуы маңызды емес компаниялардың жеткілікті саны бар екенін толық мойындаймын. Өкінішке орай, бақытыма қарай ондай жерлерде жұмыс істеуге мүмкіндік болмады. Бірақ, әрине, желілер әр түрлі, талаптар әртүрлі, тәсілдер әртүрлі, бірақ, бір немесе басқа түрде, төмендегі тізім көп жағдайда «міндетті түрде» болады.
Сонымен, бастапқы шарттар.
Сіз жаңа жұмыстасыз, қызметте көтерілдіңіз немесе өз міндеттеріңізге жаңа көзқараспен қарауды шештіңіз. Компания желісі - сіздің жауапкершілік аймағыңыз. Сіз үшін бұл көп жағынан қиын және жаңа, бұл мақаланың тәлімгерлік үнін біршама ақтайды :). Бірақ мақала кез келген желілік инженерге де пайдалы болады деп үміттенемін.
Сіздің бірінші стратегиялық мақсатыңыз - энтропияға қарсы тұруды үйрену және көрсетілетін қызмет деңгейін сақтау.
Төменде сипатталған көптеген мәселелерді әртүрлі әдістермен шешуге болады. Мен техникалық іске асыру тақырыбын әдейі қозғамаймын, өйткені... Негізінде, сіз осы немесе басқа мәселені қалай шешкеніңіз соншалықты маңызды емес, бірақ маңыздысы - сіз оны қалай пайдаланасыз және оны мүлдем пайдаланасыз ба. Мысалы, егер сіз оған қарамасаңыз және ескертулерге жауап бермесеңіз, кәсіби түрде жасалған бақылау жүйеңіздің пайдасы шамалы.
Жабдық
Алдымен сіз ең үлкен тәуекелдердің қай жерде екенін түсінуіңіз керек.
Тағы да, ол басқаша болуы мүмкін. Мен бір жерде, мысалы, бұл қауіпсіздік мәселелері, ал бір жерде қызметтің үздіксіздігіне қатысты мәселелер және бір жерде, мүмкін, басқа нәрсе болатынын мойындаймын. Неге болмасқа?
Түсінікті болу үшін, бұл әлі де қызмет көрсетудің үздіксіздігі деп есептейік (бұл мен жұмыс істеген барлық компанияларда болған).
Содан кейін жабдықтан бастау керек. Мұнда назар аудару керек тақырыптардың тізімі берілген:
- критикалық дәрежесі бойынша жабдықты жіктеу
- маңызды жабдықтың резервтік көшірмесі
- қолдау, лицензиялар
Мүмкін болатын сәтсіздік сценарийлерімен, әсіресе сындық классификацияның жоғарғы жағындағы жабдықпен ойлану керек. Әдетте, қосарланған мәселелердің мүмкіндігі еленбейді, әйтпесе сіздің шешіміңіз бен қолдауыңыз негізсіз қымбатқа түсуі мүмкін, бірақ істен шығуы бизнеске айтарлықтай әсер етуі мүмкін шын мәнінде маңызды желі элементтері болған жағдайда, сіз бұл туралы ойлануыңыз керек.
Мысал:
Деректер орталығындағы түбірлік қосқыш туралы айтып отырмыз делік.
Біз қызметтің үздіксіздігі ең маңызды критерий болып табылатынымен келіскендіктен, бұл жабдықтың «ыстық» резервтік көшірмесін (артықтығын) қамтамасыз ету орынды. Бірақ бұл бәрі емес. Сондай-ақ, егер бірінші қосқыш үзілсе, қалған бір коммутатормен қанша уақыт тұруға болатынын шешу керек, өйткені оның да бұзылу қаупі бар.
Маңызды! Бұл мәселені өзіңіз шешудің қажеті жоқ. Менеджмент немесе компания басшылығына тәуекелдерді, ықтимал шешімдерді және шығындарды сипаттау керек. Олар шешім қабылдауы керек.
Сонымен, егер қос істен шығудың шағын ықтималдығын ескере отырып, бір коммутаторда 4 сағат жұмыс істеу, негізінен, қолайлы деп шешілсе, онда сіз жай ғана тиісті қолдауды ала аласыз (соған сәйкес жабдық 4 сағат ішінде ауыстырылады). сағат).
Бірақ олардың жеткізбеу қаупі бар. Өкінішке орай, бір кездері осындай жағдайға тап болдық. Төрт сағаттың орнына техника бір апта жол жүрді!!!
Сондықтан, бұл тәуекелді де талқылау керек және, мүмкін, сіз үшін басқа коммутаторды (үшінші) сатып алып, оны қосалқы бөлшектер пакетінде («суық» резервтік көшірме) сақтау немесе зертханалық мақсаттарда пайдалану дұрысырақ болады.
Маңызды! Қолдау көрсетудің жарамдылық мерзімі бар барлық қолдаудың электрондық кестесін жасаңыз және оны күнтізбеңізге қосыңыз, осылайша сізге кемінде бір ай бұрын қолдау көрсетуді жаңарту туралы алаңдай бастауыңыз керек электрондық хат аласыз.
Қолдау көрсетуді жаңартуды ұмытып қалсаңыз және ол аппараттық құралдың үзілуі аяқталғаннан кейінгі күні кешірілмейсіз.
Төтенше жұмыс
Желіңізде не болса да, ең дұрысы, желілік жабдыққа қолжетімділікті сақтау керек.
Маңызды! Сізде барлық жабдыққа консольдық қатынас болуы керек және бұл рұқсат пайдаланушы деректер желісінің денсаулығына байланысты болмауы керек.
Сондай-ақ ықтимал теріс сценарийлерді алдын ала болжап, қажетті әрекеттерді құжаттау керек. Бұл құжаттың қолжетімділігі де маңызды, сондықтан оны бөлімнің ортақ ресурсында жариялап қана қоймай, сонымен қатар инженерлердің компьютерлерінде жергілікті түрде сақталуы керек.
Бар болуы керек
- сатушы немесе интегратор қолдауымен билетті ашу үшін қажетті ақпарат
- кез келген жабдыққа қалай жетуге болатыны туралы ақпарат (консоль, басқару)
Әрине, ол сондай-ақ кез келген басқа пайдалы ақпаратты қамтуы мүмкін, мысалы, әртүрлі жабдықты жаңарту процедурасының сипаттамасы және пайдалы диагностикалық пәрмендер.
Серіктестер
Енді серіктестермен байланысты тәуекелдерді бағалау керек. Әдетте бұл
- Интернет-провайдерлер және трафик алмасу нүктелері (IX)
- байланыс арналарының провайдерлері
Өзіңізге қандай сұрақтар қою керек? Жабдықтағы сияқты, әртүрлі төтенше жағдайлар сценарийлері қарастырылуы керек. Мысалы, Интернет-провайдерлер үшін бұл келесідей болуы мүмкін:
- Интернет провайдері X қандай да бір себептермен сізге қызмет көрсетуді тоқтатса не болады?
- Басқа провайдерлердің сізге өткізу қабілеті жеткілікті ме?
- Байланыс қаншалықты жақсы болады?
- Сіздің Интернет-провайдерлеріңіз қаншалықты тәуелсіз және олардың біреуінің үзілісі басқалармен проблемалар туғыза ма?
- деректер орталығына қанша оптикалық кіріс бар?
- кірістердің бірі толығымен жойылса не болады?
Кірістерге келетін болсақ, менің тәжірибемде екі түрлі компанияда, екі түрлі деректер орталығында экскаватор ұңғымаларды бұзды және тек керемет түрде біздің оптикаға әсер етпеді. Бұл сирек кездесетін жағдай емес.
Және, әрине, бұл сұрақтарды қойып қана қоймай, тағы да басшылықтың қолдауымен кез келген жағдайда қолайлы шешімді қамтамасыз ету керек.
Сақтық көшірме
Келесі басымдық жабдық конфигурацияларының сақтық көшірмесі болуы мүмкін. Қалай болғанда да, бұл өте маңызды сәт. Мен конфигурацияны жоғалтуға болатын жағдайларды тізбелеймін, тұрақты сақтық көшірмелерді жасап, бұл туралы ойланбаған дұрыс. Сонымен қатар, тұрақты сақтық көшірмелер өзгерістерді бақылауда өте пайдалы болуы мүмкін.
Маңызды! Күн сайын сақтық көшірме жасаңыз. Бұл үнемдеу үшін деректердің соншалықты үлкен көлемі емес. Таңертең кезекші инженер (немесе сіз) жүйеден резервтік көшірме сәтті болды ма, жоқ па анық көрсетілген есеп алу керек, ал егер резервтік көшірме сәтсіз болса, мәселені шешу керек немесе билет жасау керек ( желі бөлімінің процестерін қараңыз).
Бағдарламалық құрал нұсқалары
Жабдықтың бағдарламалық жасақтамасын жаңарту қажет пе, жоқ па деген сұрақ соншалықты анық емес. Бір жағынан, ескі нұсқалар белгілі қателер мен осалдықтар болып табылады, бірақ екінші жағынан, жаңа бағдарламалық қамтамасыз ету, біріншіден, әрқашан ауыртпалықсыз жаңарту процедурасы емес, екіншіден, жаңа қателер мен осалдықтар.
Мұнда сіз ең жақсы нұсқаны табуыңыз керек. Бірнеше айқын ұсыныстар
- тек тұрақты нұсқаларды орнатыңыз
- Дегенмен, сіз бағдарламалық жасақтаманың өте ескі нұсқаларында өмір сүрмеуіңіз керек
- кейбір бағдарламалық құралдың қай жерде орналасқаны туралы ақпарат бар белгіні жасаңыз
- бағдарламалық қамтамасыз ету нұсқаларындағы осалдықтар мен қателер туралы есептерді мерзімді түрде оқып шығыңыз және маңызды мәселелер туындаған жағдайда жаңарту туралы ойлануыңыз керек.
Осы кезеңде жабдыққа, қолдау туралы ақпаратқа және жаңарту процедурасының сипаттамасына консольдық қол жеткізіп, сіз, негізінен, осы қадамға дайынсыз. Идеал нұсқа - сізде бүкіл процедураны тексеруге болатын зертханалық жабдық болған кезде, бірақ, өкінішке орай, бұл жиі бола бермейді.
Жабдықтың маңызды болған жағдайда, жаңартуға көмектесу үшін жеткізушінің қолдау қызметіне хабарласуға болады.
Билет жүйесі
Енді сіз айналаңызға қарай аласыз. Басқа бөлімдермен және бөлім ішінде өзара әрекеттесу процестерін орнату қажет.
Бұл қажет болмауы мүмкін (мысалы, сіздің компанияңыз шағын болса), бірақ мен барлық сыртқы және ішкі тапсырмалар билет жүйесі арқылы өтетіндей жұмысты ұйымдастыруды ұсынамын.
Билет жүйесі сіздің ішкі және сыртқы байланыстарыңыздың интерфейсі болып табылады және сіз бұл интерфейсті жеткілікті түрде егжей-тегжейлі сипаттауыңыз керек.
Қол жеткізуді ашудың маңызды және ортақ тапсырмасын мысалға алайық. Мен компаниялардың бірінде тамаша жұмыс істеген алгоритмді сипаттаймын.
Мысал:
Кіру тұтынушылары жиі желі инженеріне түсініксіз тілде өз тілектерін тұжырымдайтынынан бастайық, мысалы, қолданба тілінде, мысалы, «маған 1С-ге рұқсат беріңіз».
Сондықтан, біз ешқашан мұндай пайдаланушылардан тікелей сұрауларды қабылдаған емеспіз.
Және бұл бірінші талап болды
- рұқсат сұраулары техникалық бөлімдерден келуі керек (біздің жағдайда бұл unix, windows, анықтамалық инженерлер болды)
Екінші талап – сол
- бұл кіру рұқсаты тіркелуі керек (біз осы сұрауды алған техникалық бөлімше) және сұрау ретінде біз осы тіркелген кіруге сілтеме аламыз
Бұл сұраныстың нысаны бізге түсінікті болуы керек, яғни.
- сұрауда қандай ішкі желіге және қандай ішкі желіге кіру ашық болуы керектігі туралы ақпаратты, сондай-ақ протоколды және (tcp/udp жағдайында) порттарды қамтуы керек.
Оны да сол жерде көрсету керек
- бұл рұқсат неліктен ашылғанының сипаттамасы
- уақытша немесе тұрақты (уақытша болса, қай күнге дейін)
Және өте маңызды сәт - бекітулер
- қол жеткізуді бастаған бөлім басшысынан (мысалы, бухгалтерлік есеп)
- техникалық бөлімнің бастығынан, бұл сұраныс желілік бөлімге қайдан келді (мысалы, анықтама қызметі)
Бұл жағдайда осы рұқсаттың «иесі» кіруді бастаған бөлімнің басшысы болып саналады (біздің мысалдағы есеп) және ол осы бөлімге кіру рұқсаты бар беттің жаңартылған күйінде қалуына жауапты. .
Тіркеу
Бұл сіз батып кетуіңіз мүмкін нәрсе. Бірақ егер сіз проактивті тәсілді жүзеге асырғыңыз келсе, онда бұл деректер тасқынымен қалай күресуге болатынын білуіңіз керек.
Міне, кейбір практикалық ұсыныстар:
- журналдарды күнделікті қарап шығу керек
- жоспарланған тексеру жағдайында (төтенше жағдай емес), сіз өзіңізді 0, 1, 2 ауырлық деңгейлерімен шектей аласыз және қажет деп тапсаңыз, басқа деңгейлерден таңдалған үлгілерді қоса аласыз.
- журналдарды талдайтын және үлгілері елемеу тізіміне қосқан журналдарды елемейтін сценарий жазыңыз
Бұл тәсіл уақыт өте келе сізді қызықтырмайтын журналдардың елемеу тізімін жасауға және сіз шынымен маңызды деп санайтындарды ғана қалдыруға мүмкіндік береді.
Бұл біз үшін тамаша жұмыс істеді.
Бақылау
Компанияда мониторинг жүйесінің болмауы сирек емес. Сіз, мысалы, журналдарға сене аласыз, бірақ жабдық ештеңе «айтуға» уақыт болмай-ақ «өліп қалуы» мүмкін немесе udp syslog протокол пакеті жоғалып, келмеуі мүмкін. Жалпы алғанда, әрине, белсенді мониторинг маңызды және қажет.
Менің тәжірибемдегі ең танымал екі мысал:
- байланыс арналарының, маңызды сілтемелердің жүктемесін бақылау (мысалы, провайдерлерге қосылу). Олар трафикті жоғалтуға байланысты қызметтердің нашарлауының ықтимал проблемасын белсенді түрде көруге және тиісінше оны болдырмауға мүмкіндік береді.
- NetFlow негізіндегі графиктер. Олар трафиктегі ауытқуларды табуды жеңілдетеді және хакерлік шабуылдардың кейбір қарапайым, бірақ маңызды түрлерін анықтау үшін өте пайдалы.
Маңызды! Ең маңызды оқиғалар үшін SMS хабарландыруларын орнатыңыз. Бұл бақылауға да, журналға да қатысты. Егер сізде кезекші ауысым болмаса, смс жұмыс уақытынан тыс уақытта да келуі керек.
Барлық инженерлерді оятпау үшін процесті ойластырыңыз. Бұл үшін бізде кезекші инженер болды.
Басқаруды өзгерту
Менің ойымша, барлық өзгерістерді бақылау қажет емес. Бірақ, кез келген жағдайда, қажет болса, желіде белгілі бір өзгерістерді кім және не үшін жасағанын оңай таба білу керек.
Бірнеше кеңестер:
- сол билетте не жасалғанын егжей-тегжейлі көрсету үшін билет жүйесін пайдаланыңыз, мысалы, билетке қолданылатын конфигурацияны көшіру
- желілік жабдықта түсініктеме мүмкіндіктерін пайдалану (мысалы, Juniper туралы түсініктеме беру). Билет нөмірін жазып аласыз
- конфигурация сақтық көшірмелерінің айырмашылығын пайдаланыңыз
Сіз мұны процесс ретінде енгізе аласыз, өзгерістер үшін күнделікті барлық билеттерді қарап шығыңыз.
Процестер
Сіз өзіңіздің командаңыздағы процестерді ресімдеп, сипаттауыңыз керек. Егер сіз осы нүктеге жеткен болсаңыз, сіздің командаңызда кем дегенде келесі процестер іске қосылуы керек:
Күнделікті процестер:
- билеттермен жұмыс
- журналдармен жұмыс
- басқаруды өзгерту
- күнделікті тексеру парағы
Жылдық процестер:
- кепілдіктерді, лицензияларды ұзарту
Асинхронды процестер:
- әртүрлі төтенше жағдайларға әрекет ету
Бірінші бөлімді қорытындылау
Байқадыңыз ба, мұның бәрі желі конфигурациясы туралы емес, дизайн туралы емес, желілік протоколдар туралы емес, маршруттау туралы емес, қауіпсіздік туралы емес ... Бұл айналадағы нәрсе. Бірақ бұл, мүмкін, скучно болса да, әрине, желілік бөлімше жұмысының өте маңызды элементтері.
Осы уақытқа дейін, көріп отырғаныңыздай, сіз желіде ештеңені жақсартпағансыз. Қауіпсіздік осалдықтары болса, олар қалды, ал нашар дизайн болса, ол қалды. Сіз өзіңіздің дағдыларыңыз бен білімдеріңізді желі инженері ретінде қолданбайінше, оған көп уақытты, күш-жігерді және кейде ақшаны жұмсаған боларсыз. Бірақ алдымен негізді жасау (немесе нығайту), содан кейін құрылысты бастау керек.
Келесі бөліктерде қателерді табу және жою, содан кейін инфрақұрылымды жақсарту жолдары айтылады.
Әрине, бәрін ретімен орындаудың қажеті жоқ. Уақыт сыни болуы мүмкін. Ресурстар рұқсат етсе, мұны параллель орындаңыз.
Және маңызды қосымша. Командаңызбен сөйлесіңіз, сұраңыз, кеңесіңіз. Түптеп келгенде, осының бәрін қолдайтын да, жасайтын да солар.
Ақпарат көзі: www.habr.com