Вполне допускаю, что существует достаточное количество компаний, где простой сети в один час или даже один день не является критичным. Мне, к сожалению или к счастью, не довелось работать в таких местах. Но, конечно, сети бывают разные, требования разные, подходы разные, и все же, в том или ином виде, ниже приведенный список во многих случаях будет фактически «маст-ду».
Итак, начальные условия.
Вы на новом месте работы или у вас повышение или вы решили по-новому взглянуть на свои обязанности. Сеть компании – это ваша зона ответственности. Для вас во многом это челендж и новое, что несколько оправдывает наставнический тон данной статьи :). Но, надеюсь, что статья так же может быть полезна и любому сетевому инженеру.
Ваша первая стратегическая цель – научиться противостоять энтропии и удержать уровень предоставляемого сервиса.
Многие описанные ниже задачи могут быть решены различными средствами. Я намеренно не поднимаю тему технической реализации, т.к. в принципе часто не так важно, как вы решили ту или иную задачу, а важно то, как вы этим пользуетесь и пользуетесь ли вообще. Мало толку, например, от вашей профессионально выстроенной системы мониторинга, если вы туда не смотрите и не реагируете на алерты.
Оборудование
Сначала вам нужно понять, где самые большие риски.
Опять-таки может быть по-разному. Допускаю, что где-то, например, это будут вопросы безопасности, а где-то вопросы, связанные с непрерывностью сервиса, а где-то, может быть, что-то еще. Почему бы нет?
Предположим для определенности, что это все же непрерывность сервиса (так было во всех компаниях, где работал я).
Тогда нужно начинать с оборудования. Вот список тем, на которые нужно обратить внимание:
- классификация оборудования по степени критичности
- резервирование критичного оборудования
- поддержка, лицензии
Вы должны продумать возможные варианты поломок, особенно с оборудованием, находящемся на вершине вашей классификации критичности. Обычно, пренебрегают вероятностью двойных проблем, иначе ваше решение и поддержка могут стать неоправданно дорогими, но в случае действительно критичных элементов сети, выход из строя которых может существенно повлиять на бизнес, вы должны подумать и об этом.
Пример
Предположим, мы говорим о корневом коммутаторе в дата-центре.
Т. к. мы условились, что непрерывность сервиса является наиболее важным критерием, то разумно обеспечить «горячее» резервирование (redundancy) этого оборудования. Но это еще не все. Вы так же должны определиться с тем, сколько времени, в случае поломки первого коммутатора, для вас приемлемо жить только с одним оставшимся коммутатором, ведь есть риск, что и он поломается.
Важно! Вы не должны решать этот вопрос сами. Вы должны описать риски, возможные решения и стоимость вашему руководству или руководству компании. Принимать решения должны они.
Так, если было решено, что, при условии маленькой вероятности двойной поломки, работа в течении 4х часов на одном коммутаторе, в принципе, приемлема, то вы можете просто взять соответствующую поддержку (по которой оборудование будет заменено в течении 4 часов).
Но ведь есть риск, что не доставят. К сожалению, однажды мы оказались в такой ситуации. Вместо четырех часов оборудование ехало неделю!!!
Поэтому этот риск тоже нужно обсудить и, может быть, для вас будет правильнее купить еще один коммутатор (третий) и держать его в ЗИПе («холодное» резервирование) или использовать в лабораторных целях.
Важно! Составьте таблицу всех поддержек, которые у вас есть, с датами окончания и добавьте их в календарь, чтобы как минимум за месяц к вам приходило письмо, что вы должны начинать волноваться о продлении поддержки.
Вам не простят, если вы забудете продлить поддержку и на следующий день после того, как она закончится, ваше оборудование сломается.
Аварийные работы
Чтобы не произошло в вашей сети, в идеале, вы должны сохранить доступ к вашему сетевому оборудованию.
Важно! У вас должен быть консольный доступ ко всему оборудованию и этот доступ не должен зависеть от работоспособности сети передачи пользовательских данных (data).
Так же вы должны заранее предусмотреть возможные негативные сценарии и задокументировать необходимые действия. Доступность этого документа так же критична, поэтому он должен быть не только выложен на общий для отдела ресурс, но так же сохранен локально на компьютеры инженеров.
В обязательном порядке там должны быть
- информация, необходимая для открытия заявки в поддержке вендора или интегратора
- информация, как попасть на любое оборудование (консоль, management)
Так же, конечно, может содержаться любая другая полезная информация, например, описание процедуры апгрейда различного оборудования и полезные диагностические команды.
Партнеры
Теперь вам нужно оценить риски, связанные с партнерами. Обычно это
- интернет-провайдеры и точки обмена трафиком (IX)
- провайдеры каналов связи
Какие вопросы нужно задать себе? Как и в случае с оборудованием, нужно рассмотреть различные варианты аварийных ситуаций. Например, для интернет-провайдеров, это может быть что-то типа:
- что будет если интернет-провайдер X перестанет по какой-то причине предоставлять вам сервис?
- хватит ли вам полосы пропускания остальных провайдеров?
- насколько хорошей останется связность?
- насколько независимы ваши интернет-провайдеры и не приведет ли серьезная авария одного из них к проблемам с другими?
- сколько оптических вводов в ваш дата-центр?
- что будет если один из вводов будет полностью разрушен?
По поводу вводов, в моей практики в двух разных компаниях, в двух разных дата-центрах экскаватор рушил колодцы и лишь чудом наша оптика оказывалась не задетой. Не такой уж это и редкий случай.
Ну и, конечно, вам нужно не просто задать эти вопросы, а, опять-таки, заручившись поддержкой руководства, обеспечить в любой ситуации приемлемое решение.
Бэкап
Следующий по приоритету может быть бэкап конфигураций оборудования. В любом случае это очень важный момент. Не буду перечислять те случаи, когда вы можете потерять конфигурацию, лучше делать регулярно бэкап и не думать об этом. К тому же регулярный бэкап может быть очень полезен при контроле изменений.
Важно! Сделайте бэкап ежедневным. Не такой уж это большой объем данных, чтобы экономить на этом. Утром дежурный инженер (или вы) должен получать отчет от системы, в котором явно указывается успешен или не успешен был бэкап, и в случае неуспешного бэкапа проблема должна быть решена или должен быть создан тикет (см. процессы сетевого отдела).
Версии софта
Вопрос о том, стоит или нет производить апгрейд софта оборудования не так однозначен. С одной стороны, старые версии — это известные баги и уязвимости, но с другой, новый софт это во-первых, не всегда безболезненная процедура апгрейда, а во-вторых новые баги и уязвимости.
Здесь нужно найти оптимальный вариант. Несколько очевидных рекомендации
- ставить только стабильные версии
- все же не стоит жить на совсем старых версиях софта
- составьте табличку с информацией, где какой-софт стоит
- периодически читайте отчеты по уязвимостям и багам в версиях софта, и в случае критических проблем стоит задуматься об апгрейде
На этом этапе, имея консольный доступ к оборудованию, информацию о поддержке и описание процедуры апгрейда, вы, в принципе, готовы к этому шагу. Идеальным является вариант, когда у вас есть лабораторное оборудование, где вы можете проверить всю процедуру, но, к сожалению, такое бывает не часто.
В случае критического оборудования, можно обратиться в поддержку вендора с просьбой помочь вам в проведении апгрейда.
Тикетная система
Теперь вы можете оглядеться по сторонам. Вам нужно наладить процессы взаимодействия с другими подразделениями и внутри отдела.
Возможно, это не является обязательным (например, если ваша компания небольшая), но я бы очень рекомендовал организовать работу таким образом, чтобы все внешние и внутренние задачи проходили через тикетную систему.
Тикетная система — это по сути ваш интерфейс для внутренних и внешних коммуникаций, и вы должны с достаточной степенью детальности описать этот интерфейс.
Давайте для примера рассмотрим важную и часто встречающуюся задачу по открытию доступа. Опишу алгоритм, который отлично работал в одной из компаний.
Пример
Начнем с того, что часто заказчики доступа формулируют свое желанию на непонятном сетевому инженеру языке, а именно, на языке приложения, например, “откройте мне доступ в 1C”.
Поэтому мы никогда не принимали запросы напрямую от таких пользователей.
И это было первое требование
- запросы на предоставление доступов должны приходить от технических отделов (в нашем случае это были unix, windows, helpdesk инженеры)
Вторым требованием является то, что
- этот доступ должен быть запротоколирован (техническим отделом, от которого мы этот запрос получили) и в качестве запроса мы получаем ссылку на этот запротоколированный доступ
Форма этого запроса должна быть понятна нам, то есть
- запрос должен содержать информацию о том, с какой и в какую подсети должен быть открыт доступ, а также о протоколе и (в случае tcp/udp) портах
Так же там должно быть указано
- описание для чего этот доступ открывается
- временный или постоянный (если временный, то до какого числа)
И очень важный пункт это аппрувы
- от руководителя отдела, инициировавшего доступ (например, бухгалтерии)
- от руководителя технического отдела, откуда этот запрос пришел в сетевой отдел (например, helpdesk)
При этом “владельцем” этого доступа считается руководитель отдела, инициировавшего доступ (бухгалтерия в нашем примере), и он ответственен за то, чтобы страничка с запротоколированными доступами для этого отдела оставалась актуальной.
Логирование
Это то, в чем можно утонуть. Но если вы хотите внедрить проактивный подход, то вам нужно научиться справляться с этим потоком данных.
Вот несколько практических рекомендаций:
- просматривать логи нужно ежедневно
- в случае планового просмотра (а не аварийной ситуации) можно ограничиться уровнями критичности (severity) 0, 1, 2 и добавить избранные паттерны из других уровней если считаете нужным
- напишите скрипт, парсящий логи и игнорирующий те логи, паттерны которых вы добавили в игнор-лист
Этот подход позволит со временем составить игнор-лист логов, которые вам не интересны и оставить только те, которые вы по-настоящему считаете важными.
У нас это отлично работало.
Мониторинг
Это не редкость, когда в компании отсутствует система мониторинга. Вы можете, например, понадеяться на логи, но оборудование может просто «умереть», не успев ничего «сказать», или udp пакет syslog протокола может потеряться и не долететь. В общем, конечно, активный мониторинг важен и нужен.
Два наиболее востребованных в моей практике примера:
- мониторинг загрузки каналов связи, критичных линков (например, подключение к провайдерам). Позволяют проактивно увидеть потенциальную проблему деградации сервиса из-за потери трафика и соответственно избежать ее.
- графики, построенные на основе NetFlow. Они позволяют легко находить аномалии в трафике и очень полезны для обнаружения некоторых простых, но существенных видов хакерских атак.
Важно! Настройте sms оповещение для наиболее критичных событий. Это относится, как к мониторингу, так и к логированию. Если у вас нет дежурной смены, то sms так же должны приходить и в нерабочее время.
Продумайте процесс таким образом, чтобы не будить всех инженеров. У нас для этого был дежурный инженер.
Контроль изменений
На мой взгляд не обязательно контролировать все изменения. Но, в любом случае, вы должны иметь возможность при необходимости легко найти кто и почему сделал те или иные изменения в сети.
Несколько советов:
- используйте тикетную систему для подробного описания того, что было сделано в рамках этого тикета, например, копируя примененную конфигурацию в тикет
- используйте возможности комментариев на сетевом оборудовании (например, commit comment на Juniper). Вы можете записать номер тикета
- используйте diff ваших бэкапов конфигурации
Вы можете ввести это как процесс, ежедневно просматривая все тикеты на предмет изменений.
Процессы
Вы должны формализовать и описать процессы в вашей команде. Если вы дошли до этого момента, то в вашей команде уже должны работать как минимум следующие процессы:
Ежедневные процессы:
- работа с тикетами
- работа с логами
- контроль изменений
- ежедневный чек лист
Ежегодные процессы:
- продление гарантий, лицензий
Асинхронные процессы:
- реакция на различные аварийные ситуации
Заключение первой части
Вы обратили внимание на то, что все это пока не о конфигурировании сети, не о дизайне, не о сетевых протоколах, не о маршрутизации, не о безопасности… Это что-то вокруг. Но это, хотя возможно и скучные, но, конечно, очень важные элементы работы сетевого подразделения.
Пока, как вы видите, вы ничего не улучшили в вашей сети. Если были уязвимости в безопасности, то они и остались, если был плохой дизайн, то он остался. Пока вы не применили своих навыков и знаний сетевого инженера, на которое было потрачено скорее всего большое количество времени, усилий, а иногда и денег. Но сначала нужно создать (или укрепить) фундамент, а потом уже заняться строительством.
О том, как искать и устранять ошибки, а потом и улучшать вашу инфраструктуру – об этом следующие части.
Конечно, не обязательно все делать последовательно. Время может быть критично. Делайте параллельно, если позволяют ресурсы.
И важное дополнение. Общайтесь, спрашивайте, советуйтесь с вашей командой. В конце концов именно им все это поддерживать и делать.
Автор: nihole
