Как да поемете контрола над вашата мрежова инфраструктура. Глава първа. Задръжте

Тази статия е първата от поредица от статии „Как да поемете контрола над вашата мрежова инфраструктура“. Можете да намерите съдържанието на всички статии от поредицата и връзките тук.

Напълно признавам, че има достатъчен брой компании, при които прекъсване на мрежата от един час или дори един ден не е критично. За съжаление или за щастие нямах възможност да работя на такива места. Но, разбира се, мрежите са различни, изискванията са различни, подходите са различни и все пак, под една или друга форма, списъкът по-долу в много случаи всъщност ще бъде „задължителен“.

И така, първоначалните условия.

Вие сте на нова работа, получили сте повишение или сте решили да погледнете по нов начин на отговорностите си. Фирмената мрежа е вашата зона на отговорност. За вас това в много отношения е предизвикателство и ново, което донякъде оправдава менторския тон на тази статия :). Но се надявам, че статията може да бъде полезна и за всеки мрежов инженер.

Вашата първа стратегическа цел е да се научите да устоявате на ентропията и да поддържате нивото на предлаганите услуги.

Много от описаните по-долу проблеми могат да бъдат разрешени с различни средства. Съзнателно не повдигам темата за техническото изпълнение, т.к. по принцип често не е толкова важно как сте решили този или онзи проблем, а важното е как го използвате и дали изобщо го използвате. Например, вашата професионално изградена система за наблюдение няма голяма полза, ако не я гледате и не отговаряте на сигнали.

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

Първо трябва да разберете къде са най-големите рискове.

Отново може да бъде различно. Признавам, че някъде например това ще бъдат проблеми със сигурността, а някъде проблеми, свързани с непрекъснатостта на услугата, а някъде може би нещо друго. Защо не?

Нека приемем, за да бъде ясно, че това все още е непрекъснатост на услугата (това беше случаят във всички компании, в които съм работил).

След това трябва да започнете с оборудването. Ето списък с теми, на които да обърнете внимание:

• класификация на оборудването по степен на критичност
• архивиране на критично оборудване
• поддръжка, лицензи

Трябва да обмислите възможни сценарии за повреда, особено с оборудване в горната част на вашата класификация по критичност. Обикновено се пренебрегва възможността за двойни проблеми, в противен случай вашето решение и поддръжка може да станат неоправдано скъпи, но в случай на наистина критични мрежови елементи, чиято повреда може значително да повлияе на бизнеса, трябва да помислите за това.

Пример

Да кажем, че говорим за руут суич в център за данни.

Тъй като се съгласихме, че непрекъснатостта на услугата е най-важният критерий, разумно е да се осигури „горещ“ резерв (резервиране) на това оборудване. Но това не е всичко. Трябва също така да решите колко дълго, ако първият ключ се повреди, приемливо ли е да живеете само с един останал ключ, защото има риск и той да се счупи.

важно! Не е нужно да решавате този въпрос сами. Трябва да опишете рисковете, възможните решения и разходите за ръководството или ръководството на компанията. Те трябва да вземат решения.

Така че, ако се реши, че предвид малката вероятност от двойна повреда, работата в продължение на 4 часа на един комутатор е по принцип приемлива, тогава можете просто да вземете подходящата поддръжка (според която оборудването ще бъде сменено в рамките на 4 часа).

Но има риск те да не доставят. За съжаление, веднъж се озовахме в такава ситуация. Вместо четири часа техниката пътува цяла седмица!!!

Следователно този риск също трябва да бъде обсъден и може би ще бъде по-правилно да закупите друг превключвател (трети) и да го съхранявате в пакет с резервни части („студен“ резерв) или да го използвате за лабораторни цели.

важно! Направете електронна таблица на цялата поддръжка, която имате, с дати на изтичане и я добавете към календара си, така че да получите имейл поне месец предварително, че трябва да започнете да се тревожите за подновяване на вашата поддръжка.

Няма да ви бъде простено, ако забравите да подновите поддръжката си и в деня след нейното приключване хардуерът ви се повреди.

Аварийна работа

Каквото и да се случи във вашата мрежа, в идеалния случай трябва да поддържате достъп до вашето мрежово оборудване.

важно! Трябва да имате конзолен достъп до цялото оборудване и този достъп не трябва да зависи от изправността на мрежата за потребителски данни.

Също така трябва предварително да предвидите възможните негативни сценарии и да документирате необходимите действия. Наличието на този документ също е от решаващо значение, така че той трябва не само да бъде публикуван на споделен ресурс за отдела, но и да бъде записан локално на компютрите на инженерите.

Трябва да има

• информация, необходима за отваряне на билет с поддръжка на доставчик или интегратор
• информация как да стигнете до всяко оборудване (конзола, управление)

Разбира се, той може да съдържа и друга полезна информация, например описание на процедурата за надграждане на различно оборудване и полезни диагностични команди.

партньори

Сега трябва да оцените рисковете, свързани с партньорите. Обикновено това

• Интернет доставчици и точки за обмен на трафик (IX)
• доставчици на комуникационни канали

Какви въпроси трябва да си зададете? Както при оборудването, трябва да се вземат предвид различни аварийни сценарии. Например за интернет доставчиците може да е нещо като:

• какво се случва, ако интернет доставчикът X спре да ви предоставя услуга по някаква причина?
• Други доставчици ще имат ли достатъчна честотна лента за вас?
• Колко добра ще остане свързаността?
• Колко независими са вашите интернет доставчици и сериозно прекъсване на един от тях ще доведе ли до проблеми с останалите?
• колко оптични входа във вашия център за данни?
• какво ще се случи, ако един от входовете бъде напълно унищожен?

Относно входовете, в моята практика в две различни компании, в два различни центъра за данни, багер разруши кладенци и само по чудо нашата оптика не беше засегната. Това не е толкова рядък случай.

И, разбира се, трябва не само да зададете тези въпроси, но, отново, с подкрепата на ръководството, да предоставите приемливо решение във всяка ситуация.

Архивиране

Следващият приоритет може да бъде резервно копие на конфигурациите на оборудването. Във всеки случай това е много важен момент. Няма да изброявам случаите, когато можете да загубите конфигурацията, по-добре е да правите редовни архиви и да не мислите за това. В допълнение, редовното архивиране може да бъде много полезно за наблюдение на промените.

важно! Правете резервни копия ежедневно. Това не е толкова голямо количество данни, за да спестите от това. На сутринта дежурният инженер (или вие) трябва да получите отчет от системата, който ясно показва дали архивирането е било успешно или не, а ако архивирането е неуспешно, проблемът трябва да бъде разрешен или да бъде създаден тикет ( вижте процесите на мрежовия отдел).

Софтуерни версии

Въпросът дали си струва или не да надстроите софтуера на оборудването не е толкова еднозначен. От една страна, старите версии са известни грешки и уязвимости, но от друга страна, новият софтуер е, първо, не винаги безболезнена процедура за надграждане, и второ, нови грешки и уязвимости.

Тук трябва да намерите най-добрия вариант. Няколко очевидни препоръки

• инсталирайте само стабилни версии
• Все пак не трябва да живеете на много стари версии на софтуера
• направете табела с информация за това къде се намира даден софтуер
• периодично четете доклади за уязвимости и грешки във версиите на софтуера и в случай на критични проблеми трябва да помислите за надстройка

На този етап, като имате конзолен достъп до оборудването, информация за поддръжката и описание на процедурата за надграждане, вие по принцип сте готови за тази стъпка. Идеалният вариант е да имате лабораторно оборудване, където можете да проверите цялата процедура, но за съжаление това не се случва често.

В случай на критично оборудване, можете да се свържете с поддръжката на доставчика с молба да ви помогне с надстройката.

Тикет система

Сега можете да се огледате. Трябва да установите процеси за взаимодействие с други отдели и вътре в отдела.

Това може да не е необходимо (например, ако вашата компания е малка), но силно бих препоръчал да организирате работата по такъв начин, че всички външни и вътрешни задачи да минават през тикет системата.

Тикет системата по същество е вашият интерфейс за вътрешни и външни комуникации и трябва да опишете този интерфейс достатъчно подробно.

Нека вземем пример за важна и често срещана задача за отваряне на достъп. Ще опиша алгоритъм, който работи перфектно в една от компаниите.

Пример

Нека започнем с факта, че често клиентите за достъп формулират желанията си на език, неразбираем за мрежовия инженер, а именно на езика на приложението, например „дайте ми достъп до 1C“.

Поради това никога не сме приемали заявки директно от такива потребители.
И това беше първото изискване

• заявките за достъп трябва да идват от техническите отдели (в нашия случай това бяха Unix, Windows, инженери от бюрото за помощ)

Второто изискване е това

• този достъп трябва да бъде регистриран (от техническия отдел, от който получихме тази заявка) и като заявка получаваме връзка към този регистриран достъп

Формата на това искане трябва да е разбираема за нас, т.е.

• заявката трябва да съдържа информация за това коя подмрежа и към коя подмрежа трябва да бъде отворен достъп, както и протокола и (в случай на tcp/udp) портове

Там също трябва да се посочи

• описание защо е отворен този достъп
• временно или постоянно (ако е временно, до коя дата)

И много важен момент са одобренията

• от ръководителя на отдела, който е инициирал достъп (например счетоводство)
• от ръководителя на техническия отдел, откъдето тази заявка дойде до мрежовия отдел (например бюро за помощ)

В този случай „собственикът“ на този достъп се счита за ръководител на отдела, който е инициирал достъпа (счетоводство в нашия пример), и той е отговорен да гарантира, че страницата с регистриран достъп за този отдел остава актуална .

Сеч

Това е нещо, в което можеш да се удавиш. Но ако искате да приложите проактивен подход, тогава трябва да се научите как да се справяте с този поток от данни.

Ето някои практически препоръки:

• трябва да преглеждате регистрационните файлове всеки ден
• в случай на планиран преглед (а не спешна ситуация), можете да се ограничите до нива на тежест 0, 1, 2 и да добавите избрани модели от други нива, ако сметнете за необходимо
• напишете скрипт, който анализира регистрационни файлове и игнорира тези регистрационни файлове, чиито модели сте добавили към списъка за игнориране

Този подход ще ви позволи с течение на времето да създадете списък за игнориране на регистрационни файлове, които не са ви интересни, и да оставите само онези, които наистина смятате за важни.
Подейства страхотно за нас.

мониторинг

Не е необичайно една компания да няма система за мониторинг. Можете, например, да разчитате на регистрационни файлове, но оборудването може просто да „умре“, без да има време да „каже“ нещо, или пакетът на протокола udp syslog може да бъде изгубен и да не пристигне. Като цяло, разбира се, активното наблюдение е важно и необходимо.

Двата най-популярни примера в моята практика:

• наблюдение на натоварването на комуникационните канали, критични връзки (например свързване с доставчици). Те ви позволяват проактивно да видите потенциалния проблем с влошаване на услугата поради загуба на трафик и съответно да го избегнете.
• графики, базирани на NetFlow. Те улесняват намирането на аномалии в трафика и са много полезни за откриване на някои прости, но значими видове хакерски атаки.

важно! Настройте SMS известия за най-критичните събития. Това се отнася както за наблюдение, така и за регистриране. Ако нямате дежурна смяна, тогава sms-ите трябва да пристигат и извън работно време.

Обмислете процеса по такъв начин, че да не събудите всички инженери. Имахме дежурен инженер за това.

Контрол на промените

Според мен не е необходимо да се контролират всички промени. Но във всеки случай трябва да можете, ако е необходимо, лесно да намерите кой е направил определени промени в мрежата и защо.

Няколко съвета:

• използвайте тикет система, за да описвате подробно какво е направено с този тикет, например чрез копиране на приложената конфигурация в тикета
• използвайте възможностите за коментар на мрежово оборудване (например, ангажирайте коментар на Juniper). Можете да запишете номера на билета
• използвайте diff на резервните си копия на конфигурацията

Можете да приложите това като процес, преглеждайки всички билети ежедневно за промени.

процеси

Трябва да формализирате и опишете процесите във вашия екип. Ако сте достигнали тази точка, вашият екип вече трябва да има поне следните процеси:

Ежедневни процеси:

• работа с билети
• работа с трупи
• контрол на промяната
• дневен контролен лист

Годишни процеси:

• удължаване на гаранции, лицензи

Асинхронни процеси:

• реакция при различни извънредни ситуации

Заключение на първата част

Забелязали ли сте, че всичко това все още не е свързано с мрежова конфигурация, не с дизайн, не с мрежови протоколи, не с маршрутизиране, не със сигурност... Това е нещо наоколо. Но това, макар и може би скучни, разбира се, са много важни елементи от работата на мрежовия отдел.

Досега, както виждате, не сте подобрили нищо във вашата мрежа. Ако имаше уязвимости в сигурността, тогава те останаха; ако имаше лош дизайн, тогава той остана. Докато не приложите уменията и знанията си като мрежов инженер, за което най-вероятно сте похарчили много време, усилия, а понякога и пари. Но първо трябва да създадете (или укрепите) основата и след това да започнете строителството.

Следващите части ще ви кажат как да намерите и премахнете грешки и след това да подобрите вашата инфраструктура.

Разбира се, не е нужно да правите всичко последователно. Времето може да бъде критично. Правете го паралелно, ако ресурсите позволяват.

И важно допълнение. Комуникирайте, питайте, консултирайте се с вашия екип. В крайна сметка те са тези, които поддържат и правят всичко това.

Източник: www.habr.com