Тази статия е първата в серия от статии «Как да поемете контрола върху мрежовата инфраструктура». Съдържанието на всички статии от серията и линкове можете да намерите .
Допускам, че има достатъчно компании, в които обикновената мрежа за един час или дори един ден не представлява критичен проблем. За съжаление или за щастие, не съм работил в такива места. Но, разбира се, мрежите са различни, изискванията варират, подходите също са различни. Все пак, по един или друг начин, списъкът по-долу в много случаи ще бъде практически «маст-ду».
И така, началните условия.
Вие сте на ново работно място, или имате повишение, или просто искате да погледнете на задълженията си по нов начин. Мрежата на компанията е ваша зона на отговорност. Това за вас е предизвикателство и ново, което до известна степен оправдава менторския тон на тази статия :). Но надявам се, че статията може да бъде полезна и на всеки мрежов инженер.
Вашата първа стратегическа цел е да се научите да противостоите на ентропията и да поддържате нивото на предоставяната услуга.
Много от задачите, описани по-долу, могат да бъдат решени по различни начини. Умишлено не повдигам темата за техническата реализация, тъй като често не е толкова важно как решавате определена задача, а е важно как я използвате и дали изобщо я използвате. Например, малко полза от професионално изградена система за мониторинг, ако не я следите и не реагирате на известията.
Оборудване
Първо, трябва да разберете къде са най-големите рискове.
Отново това може да бъде различно. Допускам, че някъде, например, това ще са въпросите, свързани с безопасността, а на други места - въпроси, свързани с непрекъснатостта на услугата, а на трети - може би нещо друго. Защо не?
Допуснете за определеност, че все пак става въпрос за непрекъснатостта на услугата (така беше във всички компании, в които съм работил).
Тогава трябва да започнете от оборудването. Ето списък с теми, на които трябва да обърнете внимание:
- класификация на оборудването по степен на критичност
- резервиране на критично оборудване
- поддръжка, лицензи
Трябва да обмислите възможните варианти за повреди, особено с оборудването, което попада в най-високата категория на критичност. Обикновено се пренебрегва вероятността от двойни проблеми, иначе вашето решение и поддръжка може да станат необосновано скъпи. Но в случай на наистина критични елементи от мрежата, чийто отказ може съществено да повлияе на бизнеса, трябва да помислите и за това.
Пример
Да предположим, че говорим за коренов комутатор в дата центъра.
Тъй като сме се убедили, че непрекъснатостта на услугата е най-важният критерий, разумно е да се осигури "горещо" резервиране (redundancy) на това оборудване. Но това не е всичко. Трябва също да определите колко време, в случай на повреда на първия комутатор, е приемливо за вас да работите само с един оставен комутатор, защото има риск и той да се повреди.
Важно! Не трябва да решавате този въпрос сами. Трябва да опишете рисковете, възможните решения и разходите на вашето ръководство или управлението на компанията. Те трябва да вземат решения.
Ако е решено, че при условие за малка вероятност от двойна повреда, работата в течение на 4 часа с един комутатор е приемлива, можете просто да вземете съответната поддръжка (при която оборудването ще бъде заменено в течение на 4 часа).
Но все пак има риск, че няма да доставят. За съжаление, веднъж се озовахме в такава ситуация. Вместо четири часа, оборудването пристигна за седмица!!!
Затова и този риск трябва да бъде обсъден и, може би, за вас ще е по-добре да закупите още един комутатор (трети) и да го държите в ЗИП («студено» резервиране) или да го използвате за лабораторни цели.
Важно! Създайте таблица на всичките поддръжки, които имате, с дати на изтичане и добавете ги в календара, така че поне месец преди изтичането да получавате имейл, напомнящ ви да започнете да се тревожите за подновяването на поддръжката.
Няма да ви простят, ако забравите да подновите поддръжката и на следващия ден след нейното изтичане, оборудването ви се счупи.
Аварийни работи
Каквото и да се случи в мрежата ви, в идеалния случай трябва да запазите достъпа до вашето мрежово оборудване.
Важно! Трябва да имате конзолен достъп до всичкото оборудване и този достъп не трябва да зависи от работоспособността на мрежата за предаване на данни.
Също така, трябва предварително да предвидите възможни негативни сценарии и да документирате необходимите действия. Достъпността на този документ също е критична, така че той трябва да бъде не само публикуван на общ ресурс за отдела, но и запазен локално на компютрите на инженерите.
Задължително там трябва да има
- информация, необходима за отваряне на заявка за поддръжка от вендора или интегратора
- информация за достъп до всяко оборудване (конзола, управление)
Също така, разбира се, може да съдържа всякаква друга полезна информация, като описание на процедурата по ъпгрейд на различно оборудване и полезни диагностични команди.
Партньори
Сега трябва да оцените рисковете, свързани с партньорите. Обикновено това са
- интернет доставчици и точки за обмяна на трафик (IX)
- доставчици на комуникационни канали
Какви въпроси трябва да си зададете? Както и при оборудването, трябва да разгледате различни сценарии за извънредни ситуации. Например, за интернет доставчиците, това може да бъде нещо като:
- какво ще стане, ако интернет доставчик X спре по някаква причина да ви предоставя услуга?
- достатъчни ли са ви лентите на останалите доставчици?
- колко добре ще остане свързаността?
- колко независими са вашите интернет доставчици и ще доведе ли сериозна авария на един от тях до проблеми с другите?
- колко оптични входа имате в дата центъра си?
- какво ще стане, ако един от входовете бъде напълно разрушен?
По отношение на входовете, в моята практика в две различни компании, в две различни дата центрове екскаватори рушаха шахти и само чудо нашата оптика оставаше незасегната. Не е толкова рядък случай.
И разбира се, не само трябва да си зададете тези въпроси, а, отново, с подкрепата на ръководството, да осигурите приемливи решения в всяка ситуация.
Резервно копие
Следващият по приоритет може да бъде резервно копие на конфигурациите на оборудването. Във всеки случай, това е много важен момент. Не искам да изброявам случаите, когато може да загубите конфигурация, по-добре е да правите редовно резервно копие и да не мислите за това. Освен това, редовното резервно копие може да бъде много полезно при контрол на промените.
Важно! Правете резервно копие всеки ден. Не е толкова голямо количество данни, за да икономисвате от това. Сутрин дежурният инженер (или вие) трябва да получава отчет от системата, в който ясно се посочва дали резервното копие е било успешно или не, и в случай на неуспешно резервно копие, проблемът трябва да бъде решен или трябва да бъде създаден тикет (вижте процесите на мрежовия отдел).
Версии на софтуер
Въпросът дали да се направи ъпгрейд на софтуера на оборудването не е толкова еднозначен. От една страна, старите версии съдържат известни бъгове и уязвимости, но от друга, новият софтуер не винаги е безболезнена процедура за ъпгрейд, а освен това новите бъгове и уязвимости.
Тук трябва да намерите оптимален вариант. Няколко очевидни препоръки
- инсталирайте само стабилни версии
- все пак не трябва да се живее на напълно стари версии на софтуера
- създайте таблица с информация за това кой софтуер къде е инсталиран
- периодично четете отчети за уязвимости и бъгове в версиите на софтуера, и в случай на критични проблеми, обмислете ъпгрейд
На този етап, имайки конзолен достъп до оборудването, информация за поддръжката и описание на процедурата за ъпгрейд, вие по принцип сте готови за тази стъпка. Идеален вариант е, когато имате лабораторно оборудване, където можете да проверите цялата процедура, но за съжаление, такова нещо не се среща често.
В случай на критично оборудване, можете да се свържете с поддръжката на доставчика с молба да ви помогнат с провеждането на ъпгрейда.
Система за тикети
Сега можете да се огледате наоколо. Трябва да установите процесите на взаимодействие с другите отдели и вътре в отдела.
Възможно е това да не е задължително (например, ако вашата компания е малка), но бих силно препоръчал да организирате работата така, че всички външни и вътрешни задачи да минават през тикетна система.
Тикетната система е по същество вашият интерфейс за вътрешни и външни комуникации, и трябва да опишете този интерфейс с достатъчна степен на детайлност.
Нека за пример разгледаме важна и често срещана задача по отваряне на достъп. Ще опиша алгоритъм, който отлично работи в една от компаниите.
Пример
Започваме с това, че често клиентите формулират желанието си на непонятен за мрежовите инженери език, а именно, на езика на приложенията, например, "отворете ми достъп до 1C".
Затова никога не сме приемали заявки директно от такива потребители.
И това беше първото изискване
- заявките за предоставяне на достъпи трябва да идват от техническите отдели (в нашия случай това бяха юникс, уиндос, хелпдеск инженери)
Второто изискване е, че
- този достъп трябва да бъде документиран (от техническия отдел, от който сме получили тази заявка) и като част от заявката получаваме линк към този документиран достъп
Форматът на тази заявка трябва да е разбираем за нас, а именно
- заявката трябва да съдържа информация за това, от коя и в коя подмрежа трябва да бъде отворен достъпът, както и за протокола и (в случай на tcp/udp) портовете
Там трябва също да бъде посочено
- описание защо този достъп се отваря
- временен или постоянен (ако е временен, до коя дата)
И много важен момент е одобрението
- от ръководителя на отдела, инициирал достъпа (например, счетоводството)
- от ръководителя на техническия отдел, от който е дошла заявката до мрежовия отдел (например, хелпдеск)
При това "собственика" на този достъп се счита ръководителя на отдела, инициирал достъпа (счетоводство в нашия пример), и той е отговорен за поддържането на страницата с документирани достъпи за този отдел актуална.
Логиране
Това е нещо, в което може да се утопите. Но ако искате да внедрите проактивен подход, трябва да се научите как да се справяте с този поток от данни.
Ето няколко практични препоръки:
- логовете трябва да се преглеждат ежедневно
- в случай на планов преглед (а не аварийна ситуация) можете да се ограничите до нива на критичност (severity) 0, 1, 2 и да добавите избрани шаблони от други нива, ако смятате за необходимо
- направете скрипт, който парсва логовете и игнорира тези логове, чийто шаблони сте добавили в списъка с игнорирани
Този подход ще ви позволи с времето да съставите списък с логове, които не ви интересуват, и да оставите само тези, които наистина смятате за важни.
При нас това работеше отлично.
Мониторинг
Не е рядкост, когато в компанията липсва система за мониторинг. Можете, например, да разчитате на логовете, но оборудването може просто да „умре“, без да успее да „каже“ нищо, или UDP пакетът на syslog протокола може да се загуби и да не стигне до вас. В общи линии, разбира се, активният мониторинг е важен и необходим.
Два от най-търсените примери в моята практика:
- мониторинг на натоварването на комуникационните канали, критични връзки (например, свързването с доставчиците). Те позволяват проактивно да видите потенциален проблем с деградацията на службата заради загуба на трафик и следователно да го избегнете.
- графики, изградени на базата на NetFlow. Те позволяват лесно откриване на аномалии в трафика и са много полезни за засичане на някои простички, но съществени видове хакерски атаки.
Важно! Настройте SMS известяване за най-критичните събития. Това важи и за мониторинга, и за логването. Ако нямате дежурна смяна, SMS съобщенията трябва да достигат и в извънработно време.
Помислете за процеса така, че да не будите всички инженери. За това при нас имаше дежурен инженер.
Контрол на измененията
Според мен не е задължително да контролирате всички промени. Но, в какъвто и да е случай, трябва да имате възможност при необходимост лесно да откриете кой и защо е направил определени промени в мрежата.
Няколко съвета:
- използвайте система за тикети за подробно описание на това, което е направено в рамките на този тикет, например копирайки използваната конфигурация в тикета
- използвайте възможностите за коментари на мрежовото оборудване (например, commit comment в Juniper). Можете да запишете номера на тикета
- използвайте diff на вашите резервни копия на конфигурации
Можете да въведете това като процес, ежедневно преглеждайки всички тикети за промени.
Процеси
Трябва да формализирате и опишете процесите в екипа си. Ако сте стигнали до този момент, във вашия екип вече трябва да работят поне следните процеси:
Ежедневни процеси:
- работа с тикети
- работа с логове
- контрол на промените
- ежедневен чеклист
Годишни процеси:
- подновяване на гаранции, лицензи
Асинхронни процеси:
- реакция на различни аварийни ситуации
Заключение на първа част
Забелязали ли сте, че всичко тук не е свързано с конфигурирането на мрежата, дизайна, мрежовите протоколи, маршрутизацията или сигурността… Това е нещо около тях. Но това, макар и възможно досадно, е изключително важно за функционирането на мрежовото подразделение.
Както виждате, все още не сте направили никакво подобрение в мрежата си. Ако е имало уязвимости в сигурността, те остават; ако е имало лош дизайн, той остава. Докато не приложите своите умения и знания на мрежови инженер, в които вероятно сте вложили много време, усилия и понякога пари. Но първо трябва да изградите (или укрепите) основата, а след това да се заемете със строителството.
За това как да търсите и отстранявате проблеми, а след това да подобрявате инфраструктурата си — това ще бъде в следващите части.
Разбира се, не е задължително да правите всичко последователно. Времето може да е критично. Правете паралелно, ако ресурсите позволяват.
И важно допълнение. Общувайте, задавайте въпроси, съветвайте се с екипа си. В крайна сметка те ще поддържат и изпълняват всичко това.
Източник: habr.com
