Блог компании linxdatacenter

Как обновить сетевое оборудование на крупном предприятии без остановки производства? О масштабном проекте в режиме операции на открытом сердце рассказывает менеджер по управлению проектами Linxdatacenter Олег Федоров.

В последние несколько лет мы отмечаем повышенный спрос заказчиков на услуги, связанные с сетевым компонентом ИТ-инфраструктуры. Потребность в связности ИТ-систем, сервисов, приложений, задачи мониторинга и операционного управления бизнесом практически в любой сфере вынуждают сегодня компании уделять сетям повышенное внимание.

Диапазон запросов от обеспечения отказоустойчивости сети до создания и управления клиентской автономной системой с приобретением блока IP-адресов, настройкой протоколов маршрутизации и управлением трафиком согласно политикам организаций.

Также растет спрос на комплексные решения по построению и обслуживанию сетевой инфраструктуры, в первую очередь со стороны заказчиков, сетевая инфраструктура которых создается с нуля или же морально устарела, требуя серьезной модификации.

Данный тренд по времени совпал с периодом развития и усложнения собственной сетевой инфраструктуры Linxdatacenter. Мы расширили географию своего присутствия в Европе за счет подключения к удаленным площадкам, что в свою очередь потребовало и совершенствования инфраструктуры сети.

Компания запустила новый сервис для клиентов, Network-as-a-Service: решение всех сетевых задач клиентов мы берем на себя, позволяя им сосредоточиться на основном бизнесе.

Летом 2020 года завершился первый большой проект в этом направлении, о котором хотелось бы рассказать.

На старте

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

Последняя модернизация оборудования на предприятии проходила около 10 лет назад. Новое руководство предприятия решило улучшить связность, начав с обновления инфраструктуры на самом базовом, физическом уровне.

Проект был разделен на две части: апгрейд серверного парка и сетевого оборудования. Мы отвечали за вторую часть.

Базовые требования к работам включали в себя минимизирование простоев производственных линий предприятия во время выполнения работ (а на некоторых участках и полное исключение простоев). Любая остановка прямые денежные потери клиента, чего не должно было произойти ни при каких обстоятельствах. В связи с режимом работы объекта 24х7х365, а также с учетом полного отсутствия периодов плановых простоев в практике предприятия, перед нами была поставлена задача, по сути, выполнить операцию на открытом сердце. Это и стало главной отличительной чертой проекта.

Поехали

Работы планировались по принципу движения от удаленных от ядра узлов сети к более близким, а также от менее влияющих на работу производственных линий к влияющим на эту работу непосредственно.

К примеру, если брать узел сети в отделе продаж, то перебой со связью в результате работ в данном отделе никак не затронет производство. При этом такой инцидент поможет нам как подрядчику проверить правильность выбранного подхода к работе по таким узлам и, скорректировав действия, работать на следующих этапах проекта.

Необходимо не только заменить узлы и провода в сети, но и правильно сконфигурировать все компоненты для корректной работы решения в целом. Именно конфигурации и проверялись таким образом: начиная работы в удалении от ядра, мы как бы давали себе право на ошибку, не подвергая риску критически важные для работы предприятия участки.

Мы определили зоны, не влияющие на производственный процесс, а также критические участки цеха, погрузочно-разгрузочный блок, склады и т. д. На ключевых участках с клиентом был согласовано допустимое время простоя для каждого узла сети в отдельности: от 1 до 15 минут. Полностью избежать отключения отдельных узлов сети было невозможно, так как кабель должен быть физически переключен из старого оборудования в новое, а в процессе переключения необходимо также распутать бороду проводов, которая сформировалась в процессе нескольких лет эксплуатации без должного ухода (одно из последствий аутсорсинга работ по монтажу кабельных линий).

Работы были разделены на несколько этапов.

Этап 1 Аудит. Подготовка и согласование подхода к планированию работ и оценка готовности команд: клиента, подрядчика, выполняющего монтаж, и нашей команды.

Этап 2 Разработка форматадля проведения работ, с глубоким детальным анализом и планированием. Выбрали формат чек-листа с точным указанием порядка и последовательности действий, вплоть до последовательности переключения патч-кордов по портам.

Этап 3 Проведение работ в шкафах, не влияющих на производство. Оценка и корректировкавремени простоядля последующих этапов работ.

Этап 4 Проведение работ в шкафах, напрямую влияющих на производство. Оценка и корректировкавремени простоядля финального этапа работ.

Этап 5 Проведение работ в серверной по переключению оставшегося оборудования. Запуск на маршрутизации на новом ядре.

Этап 6 Последовательное переключение ядра системы со старых сетевых конфигураций на новые для плавного перехода всего комплекса системы (VLAN, маршрутизация и т. д.). На данном этапе мы подключили всех пользователей и перевели все сервисы на новое оборудование, проверили правильность подключения, удостоверились, что никакие из сервисов предприятия не остановились, гарантировали, что в случае возникновения каких-либо проблем они будут связаны непосредственно с ядром, что облегчало устранение возможных неполадок и финальную настройку.

Прическа бороды проводов

Проект оказался непростым еще и из-за сложных исходных условий.

Во-первых, это огромное количество узлов и участков сети, с запутанной топологией и классификацией проводов по их назначению. Такие бороды нужно было доставать из шкафов и кропотливо причесывать, разбираясь, какой провод откуда и куда ведет.

Выглядело это примерно так:


так:


или так:


Во-вторых, для каждой подобной задачи необходимо было подготовить файл с описанием процесса. Берем провод Х из порта 1 старого оборудования, втыкаем его в порт 18 нового оборудования. Звучит просто, но когда у тебя в исходных данных 48 полностью забитых портов, а также отсутствует опция простоя (мы помним про 24х7х365), единственный выход работать по блокам. Чем больше можно вытащить проводов из старого оборудования за один раз, тем быстрее можно их причесать и вставить в новое сетевое железо, избежав сбоев и простоев в работе сети.

Поэтому на подготовительном этапе мы провели разбивку сети по блокам каждый из них относился к определенному VLAN. Каждый порт (или их подмножество) на старом оборудовании это какой-то из VLAN в новой топологии сети. Мы сгруппировали их так: в первых портах коммутатора разместились пользовательские сети, в середине производственные сети, а в последних точки доступа и аплинки.

Такой подход позволил за один прием вытаскивать и причесывать из старого оборудования не 1 провод, а 10-15. Это в несколько раз ускорило рабочий процесс.

Кстати, вот как выглядят провода в шкафах после причесывания:


или, например, так:


После завершения 2-го этапа мы взяли паузу на анализ ошибок и динамики проекта. Например, сразу вылезли мелкие недочеты из-за неточностей в предоставленных нам схемах сети (неверный коннектор на схеме неверный купленный патч-корд и необходимость его замены).

Пауза была необходима, так как при работе с серверной права даже небольшой сбой в процессе был недопустим. Если поставлена цель обеспечить время простоя на участке сети не более 5 минут, то превышать его было нельзя. Любое возможное отклонение от графика должно было согласовываться с клиентом.

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

Вызов времени проект под COVID-ом

Без дополнительных сложностей, тем не менее, не обошлось. Конечно, в качестве одного из препятствий выступил коронавирус.

Работы осложнились тем, что началась пандемия, и невозможно было присутствовать во время проведения работ на площадке клиента всем специалистам, задействованным в процессе. На площадку были допущены только сотрудники монтажной организации, а контроль осуществлялся через комнату вZoom в ней находились сетевойинженер со стороны Linxdatacenter, я как руководитель проекта,сетевойинженер со стороны клиента, ответственный за производство работ, и команда, выполняющая монтажные работы.

В ходе работ возникали неучтенные проблемы, и приходилось вносить корректировки на лету. Так удалось быстро предотвращать влияние человеческого фактора (ошибки в схеме, ошибки в определении статуса активности интерфейса и т. д.).

Хотя дистанционный формат работы и казался непривычным в начале проекта, мы довольно быстро приспособились к новым условиям и вышли на финальный этап работ.

Мы запустили временную конфигурацию настроек сети для параллельной работы двух сетевых ядер старого и нового в целях осуществления плавного перехода. Однако оказалось, что не была удалена одна лишняя строчка из файла конфигурации нового ядра, и перехода не произошло. Это заставило нас потратить определенное время на поиск проблемы.

Выяснилось, что основной трафик передавался корректно, а управляющий трафик не достигал узла через новое ядро. Благодаря четкому разделению проекта на этапы, удалось довольно быстро установить участок сети, на котором возникло затруднение, выявить проблему и устранить ее.

А в результате

Технические итоги проекта

Прежде всего, было создано новое ядро новой сети предприятия, для чего мы построили физические/логические кольца. Сделано это таким образом, чтобы у каждого коммутатора в сети появилось второе плечо. В старой сети многие коммутаторы подсоединялись к ядру по одной трассе, одним плечом (аплинком). Если он рвался, коммутатор становился полностью недоступен. А если через один аплинк подключалось несколько коммутаторов, то авария выводила из строя целый отдел или производственную линию на предприятии.

В новой сети даже довольно серьезной сетевой инцидент ни при каком сценарии не сможет положить всю сеть или значимый ее участок.

90% всего сетевого оборудования обновлено, выведены из эксплуатации медиаконвертеры (преобразователи среды распространения сигнала), а также упразднена необходимость в выделенных силовых линиях для запитки оборудования за счет подключения к PoE-коммутаторам, где электропитание осуществляется по Ethernet-проводам.

Также, промаркированы все оптические соединения в серверной и в шкафах на местах на всех ключевых узлах связи. Это позволило подготовить топологическую схему оборудования и подключений в сети, отражающее ее фактическое состояние на сегодня.

Схема сети

Самый главный итог в техническом отношении: достаточно масштабные инфраструктурные работы были проведены быстро, не создавая никаких помех в работе предприятия и практически незаметно для его персонала.

Бизнес-итоги проекта

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

Успех проекта позволяет говорить о том, что наша инициатива по развитию сетевого направления в рамках портфеля сервисов Linxdatacenter верный выбор вектора развития компании. Ответственный подход к управлению проектами, грамотная стратегия, четкое планирование позволили нам выполнить работу на должном уровне.

Подтверждение качества работы запрос от клиента на продолжение оказания услуг по модернизации сети на его остальных площадках в России.

Модернизация дата-центра во время пандемии COVID-19 не самая простая задача, особенно когда речь идет об апгрейде системы электроснабжения площадки. Тем не менее, при наличии четкого плана действий, надежного подрядчика и грамотной проектной команды с ней можно справиться и в условиях форс-мажора.

Рассказываем, как все прошло и как наша площадка в Санкт-Петербурге стала еще надежнее для клиентов по параметру отказоустойчивости.


ИБП Delta в ЦОДе Linxdatacenter

Вводные условия

Система бесперебойного электропитания (СБЭП) нашего ЦОДа в Петербурге была изначально спроектирована по модели 2N.

Это означает, что в случае выхода из строя одного ИБП (или его отключения для техобслуживания), второй берет на себя полную нагрузку. Соответственно, фактически задействованная мощность одного источника бесперебойного питания (ИБП) в паре не должна превышать 50% от максимально доступной. Таким образом обеспечивается надежность работы системы.

В обычном режиме ИБП дают необходимые 100% мощности, поровну деля нагрузку между собой.

Однако рост нагрузок на дата-центр привел к необходимости модернизации: уровень потребления мощностей приближался к предельно допустимому порогу.

В связи с высоким спросом на ресурсы площадки мы приняли решение в пользу модульных ИБП как формата, оптимально отвечающего задачам развития дата-центра в текущий момент и позволяющего наращивать мощности в перспективе.

При этом внедрить модульные ИБП в СБЭП, построенную на моноблочных решениях, оказалось невозможно. Пришлось бы отключать часть оборудования, что привело бы к простоям ИТ-систем клиентов, поэтому этот сценарий мы отбросили сразу.

Необходимо было создать принципиально новую СБЭП, перераспределив нагрузку между имеющимися моноблочными ИБП и новыми модульными. При этом важно было соблюсти требования Uptime Institute в части мониторинга нагрузок до 50% от максимальной на единицу ИБП.

Выбор в пользу

Выбор пал на оборудование компании Delta Electronics: необходимая модель ИБП Delta DPH 500 kVA была доступна на складе в Петербурге, а компания-интегратор решения (ГК Темпесто) также обладала статусом монобрендового дистрибьютора вендора в России, что сыграло для нас большую роль по ходу проекта.

Модульный формат ИБП позволяет решать множество задач, связанных с энергетическим обеспечением ЦОДа, главная из которых повышение отказоустойчивости.

Дело в том, что моноблочные ИБП выходят из строя целиком, запуская эффект домино по всей цепочке выполнения SLA. В отличие от них, модульные ИБП в случае аварии вылетают помодульно, теряя по 50 кВт, что при грамотной настройке архитектуры СБЭП позволяет не ощутить последствия таких сбоев, причем в некоторых случаях влияние такой аварии будет стремиться к нулю.

Кроме того, модульные решения позволяют проводить замену неисправных модулей на горячую, легко масштабируются под колебания нагрузок на машинный зал, гораздо более компактны (модульный ИБП занимает одну стойку против 2,5 стоек для моноблочного устройства). Немаловажен и экономический фактор: модульные решения стоят почти в два раза дешевле по сравнению с лидирующими на рынке моноблочными моделями.

Словом, это был довольно легкий выбор.

За работу

Проектная команда состояла из 15 человек. В состав команды вошли десять монтажников, главный инженер, а также его заместители по разным направлениям (автоматика, электрика и т. д.).

Работы стартовали в апреле 2020 года с прицелом на завершение к июню. Однако следовать плану оказалось не так просто: задача осложнилась пандемией COVID-19, из-за которой один из поставщиков не смог вовремя доставить необходимые для щитового оборудования автоматические выключатели из Европы.

К этому моменту уже были выполнены все предпроектные изыскания и подготовлена проектная документация, закуплены необходимые ИБП и большая часть материалов. Ждать, когда ситуация нормализуется, было невозможно: обновленные серверные мощности должны были запуститься в работу в заранее установленные сроки по условиям контракта с новым клиентом ЦОДа.

Поэтому было принято решение приступить к монтажу на объекте, чтобы соблюсти запланированную этапность работ.


Массив аккумуляторных батарей ИБП в ЦОДе Linxdatacenter

Побить COVID-19: гибкость планирования, команды и фактор ГИПа

В первую очередь, мы сделали ставку на слаженную работу команды, особенно на связку бригадир-монтажники. Отмечу вклад подрядчика: специалисты Темпесто смогли обеспечить высочайшую гибкость взаимодействия с нами и между собой в не самых простых условиях.

Например, когда понадобилось переключать мощности с одного источника электроэнергии на другой, клиенты далеко не всегда были готовы к этой процедуре, несмотря на уведомления. Зачастую они не позволяли отключать свое оборудование, так как не успели подготовиться должным образом не сделали бэкап, не перебросили системы на резервную площадку и т. д.

Несмотря на это, простоев удалось избежать почти полностью. На такие случаи всегда был готов План Б, чем занять монтажников в рамках текущих задач.

Чтобы завершить проект в срок, работа велась ежедневно, без перерывов на выходные. Работать сотрудникам приходилось в достаточно непривычных условиях: с постоянным ношением СИЗ и соблюдением дистанции из-за пандемии.


Щит распределения питания в ЦОДе Linxdatacenter

Грамотное управление временем команды и четкое понимание архитектуры будущего решения помогли избежать существенных временных потерь, и монтаж кабельного, щитового оборудования и ИБП удалось выполнить вовремя.

Также помог статус официального дистрибьютора подрядчика по продуктам вендора. Когда выяснилось, что один из ИБП после распаковки оказался поврежденным, благодаря прямому контакту с поставщиком замена пришла за 1 неделю. Если бы поставщик оборудования был один, а монтажник другой, только на этой проблеме мы потеряли бы 2-4 недели.

Результаты

В результате модернизации, в процессе которой были установлены 4 дополнительных ИБП серии DeltaDHP 500 кВА, питание было частично перераспределено на новое оборудование, а максимальная нагрузка на единицу ИБП в итоге снизилась с 49% до 43%.

В целом, показатель отказоустойчивости ЦОДа и так был удовлетворительным, но апгрейд позволил его улучшить. Ранее, если загрузка одного ИБП превышала 50% от максимальной, то при аварии отключение было бы неизбежно. Например, когда у моноблочного ИБП вылетает сборка конденсаторов падают все завязанные на нем системы. У модульного ИБП выйдет из строя всего лишь один модуль, а остальные элементы продолжат работу.

Самое важное: выводы

Участники проектной команды приобрели важный опыт работы над сложными задачами в условиях непредвиденных кризисов.

К каким выводам мы пришли:

• Проблемы с поставками могут возникать даже в нормальных условиях. В условиях пандемии и других форс-мажорных обстоятельств нужно готовиться к самым негативным сценариям развития событий: сроки поставок могут срываться чаще и на более долгие сроки;
• Работы должны вестись согласно графику-плану, в котором заранее просчитываются любые риски. Особое внимание надо уделить тем узловым точкам, в которых этапы пересекаются;
• При нарушении сроков поставки необходимо делать те работы, которые возможно осуществлять независимо от срыва. Если приостановить все работы по проекту до получения всех комплектующих, работа рискует либо затянуться, либо превратиться в штурмовщину;
• Модернизация существующего комплекса более сложный в плане методов процесс, нежели строительство системыс нуля. Выполнение таких работ невозможно без тщательного планирования и разработки запасных планов действий.

Практика по поддержке и развитию облака в ЦОДе Linxdatacenter преподнесла нам интересный кейс. Достаточно рутинная операция по обновлению всего одного элемента облачной платформы привела к масштабному глубокому апгрейду.

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

Нельзя просто взять и обновить vCloud Director

Основные компоненты облака Linxdatacenter стэк технологий VMware, на котором реализована панель управления виртуальной инфраструктурой vCloud Director. Он развернут на базе компонентов Cisco и служебной инфраструктуре типа Windows ActiveDirectory.

В какой-то момент в конце 2020 года мы столкнулись с проблемой: версия vCloud Director 9.5 начала понемногу отставать от специфики текущих задач, а руки до ее апгрейда до версии10.1 или 10.2 не доходили.

Страшного в этом ничего не было, но в начале 2021 года прекратилась поддержка Flashв браузере.

Честно говоря, мы не ожидали, что Flash и разработчики браузеров поступят таким жестоким образом. То есть о прекращении поддержкислышали все и уже давно, но новость о том, что его физически будут удалять из операционных систем и полностью блокировать в браузерах с 12 января, стала очень неприятным сюрпризом.

Дело в том, что в vCloud Director реализован доступ через два портала. Первый на Flash, он жеявлялся основным и, скажем так, изначальным, с очень широкой функциональностью и большим количеством возможностей.

HTML-портал начали развивать с версии 8.20 как раз в перспективе отказа от Flash, потихоньку добавляя в него новую функциональность. Версия vCloud Director 9.5, которая сейчас представлена на трех наших площадках, удовлетворяет большинству запросов клиентов по функциям, но с точки зрения администрирования стали появляться довольно существенные проблемы.

В качестве промежуточного решения удалось найти конфигурацию браузера, в которой доступы к Flash пока остаются. И с точки зрения управления мы продолжаем контролировать ситуацию, никаких проблем нет.

Однако для пользователей функциональность версии 9.5 не идеальна. Пользователи уже привыкли работать во Flash, и его отсутствие вызывает неудобства, они задают вопросы, а вот раньше это было так, а как нам это сделать теперь?. В 10-х версиях функциональность ощутимо лучше и максимально приближена к Flash. Отсюда было принято решение о том, что обновление vCloud Director это задача 1.

Тяжелое наследие

Осложнялась ситуация тем, что облачная платформа в нашем ЦОДе в Санкт-Петербурге и на партнерской площадке в Варшаве это наше наследие от системного интегратора, который разворачивал ее еще в 2013 году. До 2017 года эта же компания полностью производила обслуживание и апгрейды, а далее мы нарастили достаточный объем собственной экспертизы, чтобы взять управление полностью в свои руки.

Уже предварительный анализ ситуации показал, что нельзя просто взять и обновиться с версии 9.5 до 10.2. Составление пошагового плана обновлений всех версий софта для разных элементов облака с матрицами совместимости заняло у ответственного за задачу архитектора более 2 недель.

Это вызвано сложной структурой зависимости версий ПО, логика которой требует постепенного и строго последовательного перехода к новым версиям с тем, чтобы сохранить бесперебойную работу облака в целом.

Необходимость невинного, казалось бы, апгрейда vCloud Director заставила нас запустить полное обновление платформы, начиная от Windows-серверов с Active Directory и заканчивая всеми дополнительными компонентами. Чтобы выполнить планируемое обновление до целевой версии в vCloud Director, потребуется обновить всю систему четыре раза: обновление платформы облака будет выполнено в три полноценных раунда или очереди.

Начнем мы со своего облака в Варшаве, затем последуют площадки в Петербурге и Москве. Плановый срок окончания этих работ май 2021 года.

Но для начала потренируемся на цифровом двойнике облака.

Digital twin для облака

План работ только по одной из площадок просто колоссальный с учетом ресурса проектной команды из трех специалистов.

Это ограничение, а также сроки, количество промежуточных шагов и сложность инфраструктуры потребовали от нас проведения тщательного тестирования практической реализации проекта на виртуальном макете цифровом двойнике (digital twin) облака в виртуальной лаборатории.

Цифровой двойник облака обеспечивает нам уверенность в качестве запускаемых изменений системы и достижении ожидаемых результатов. К тому же на таком двойнике очень удобно отрабатывать различные сценарии эксплуатации платформы, и в случаеошибки или сбоя у нас всегда будет возможность выполнить откат к снэпшоту виртуальной машины с исправлением допущенных ошибок. Это ускоряет процесс обновления и позволяет проводить его без потери в качестве работы системы в целом.

Все обновления предварительно будут выполнены на цифровом двойнике, и далее, при успешном протекании процессов постепенного перехода к новым версиям всех элементов платформы, будет скорректирован детальный план работы по реальной целевой инфраструктуре.

Цифровой двойник полностью повторяет инфраструктуру платформы вплоть до самых последних компонентоввсех систем. Все изменения реальной инфраструктуры настройки, конфигурации, обновления ПО сначала отрабатываются на нем.

Мы смотрим, как все элементы складываются в единую картину, определяем риски, рассчитываем время, которое занимает тот или иной этап обновления, на основе чего создается детальный план работ.

Двойник выполнен за счет технологии вложенной виртуализации Nested Virtualization. VMware позволяет поднимать гипервизорывнутри себя, и на этих гипервизорах также можно запускать виртуальные машины.

В рамках нашего варшавского облака выделены ресурсы под создание двойника и на них развернуты гипервизоры, виртуальные машины, сеть мы пересобрали облако с нуля с соблюдением всех версий ОС, пакетов, ПО и архитектуры, которая соединяет их в единое решение.

Это не Ctrl+C/Ctrl+V, то есть мы не просто скопировали существующую систему: воспроизведены только основные компоненты системы и логика их взаимодействия, вплоть до пропускной способности каналов связи,NGINX какreverse proxy иконфиги для регистрации трафика.

Двойник ест ресурсы площадки в объеме на $650 в месяц например, мы платим VMware как поставщику услуг за потребленную двойником оперативную память, а всего на нем развернуто более 20 виртуальных машин.

Это существенные затраты, но зато безопасная обкатка сценария обновления шаг за шагом гарантирует нам 100%-ную защиту от сбоев и непредвиденных моментов при обновлении на реальной инфраструктуре. Возможные потери из-за сбоя в работе системы на порядки превышают траты на содержание двойника.

Наши ожидания

По предварительным расчетам, ресурса системы после обновления хватит на то, чтобы платформа проработала на должном уровне без необходимости каких-либо изменений, не говоря уже о глобальной перестройке, как минимум, до конца 2021 года.

В рамках текущей подготовки к обновлению по большинству основных версий ПО ключевых систем показатель End-of-support датируется концом 2023 года. Также, по существенному количеству систем сроки прекращения поддержки версий ПО остаются пока что незаявленными.

То есть, общего запаса прочности должно хватить на 1-2 года, а если мы говорим про глобальное обновление, сравнимое с текущим, то мы закладываем сегодня фундамент на еще более длительный срок.

Жизненный цикл платформы облака предполагает необходимость всегда иметь актуальные версии ПО ключевых элементов системы.

Говоря в целом об этом направлении работы, можно отметить, что общая сложность и болезненность такой перестройки всегда будет зависеть от того, как сильно его запустить, перестав отслеживать совместимость версий, а также от того, насколько разнообразен зоопарк различных элементов, технологий, протоколов и ПО, на которых построено облако.

К чему здесь следует стремиться? К унификации: начатое глобальное обновление в итоге очень сильно упростит нам жизнь и улучшит надежность работы облака в целом.

Мы сможем полностью уйти от наследия интегратора, который всю эту инфраструктуру разворачивал. У нас не останется никаких белых пятен и потенциально слабых звеньев в цепочке создания ценности облака в виде его доступности, гибкости настроек, безотказности и других параметров, влияющих на SLA.

Как только на всех площадках все компоненты облака будут работать на единых версиях ПО, любые последующие апгрейды, расширения и интеграции станут вопросом грамотного управления технической составляющей, рутиной, а не глобальным административно-техническим проектом.

Цифровой двойник облака мы планируем использовать и дальше. Это удобный инструмент, который помогает сделать процесс обновления инфраструктуры более безопасным и быстрым.

В предыдущих частях мы рассказывали, как создавали и внедряли новую систему мониторинга ЦОД. В итоге у нас появился мощный механизм отслеживания и ведения статистики всех параметров ЦОДа, влияющих на доступность его ресурсов и показатели бесперебойной работы.

Следующей задачей на пути развития системы стал вопрос ее настройки: как сделать так, чтобы работать с новой системой было удобно, а сама она была бы максимально информативной?

Проблема здесь в том, что функционал системы позволяет включить множество аварийных оповещений и сигналов при таких настройках персонал будет вынужден постоянно реагировать на них, отрабатывая соответствующие сценарии.

Другой вариант: выставить недостаточное количество таких оповещений, создав риски для дежурных пропустить действительно важное событие.

В этой части мы поделимся практическим опытом настройки нашей системы мониторинга работы ЦОДа.

Немного теории

Собираемые системой SCADA переменные делятся на телесигнализацию и телеизмерения учили меня когда-то в институте. И на самом деле ничего не поменялось: телесигнализация это состояние устройства, например, нет аварии, есть авария, открыт, закрыт и т. д.

А телеизмерение, как нетрудно догадаться, это цифровое значение какого-либо параметра, например 220 Вольт или 10 Ампер.

Состояние или значение, настроенное пользователем, при котором на экране появляется сообщение (авария), называется уставкой. Можно настроить задержку до появления сообщения, то есть авария на экране появляется только через Х секунд (при условии, если аварийная ситуация не прекратилась раньше) или на замораживание сообщения на экране в этом случае авария уже пропала, но сообщение о ней на экране сохраняется еще Х секунд.

Аварии по показателю приоритетности обычно делятся на три основных типа: Красная, Желтая и Голубая. Красные аварии требуют немедленных действий сотрудников, Желтые о чем-то их предупреждают, Голубые чаще всего сообщают о каких-то некритичных событиях. Например, мы вывели Голубые аварии из сводки, которую видят дежурные, и используем их для мониторинга различных коммерческих параметров (превышение заказанной мощности). Отчеты по этим авариям направляются только менеджерам и не отвлекают дежурных.

Для удобства настройки однотипного оборудования переменные в разных устройствах, но с одним именем (например, OutputCurrent) имеют одинаковые настройки на всех устройствах системы. Если мы меняем уставку в одном месте она меняется везде.


Когда какое-то устройство требует индивидуальных настроек у требуемой переменной, мы применяем специальную отметку Только для этого устройства. Теперь переменная стала индивидуальной для одного конкретного устройства, имеет свою уставку и не влияет на другие одноименные переменные.

Дополнительно в самих устройствах есть собственные заводские уставки. Например, в PDU с завода настроено распознавание аварийной ситуации на превышение тока в 32А. В случае ее срабатывания от PDU поступит оповещение о типе аварии Overload Alarm. И это совсем другая переменная, не связанная с переменной OutputCurrent, настроенной в BMS.

Пример заводских настроек уставок внутри PDU:


Итак, мы перечислили основной функционал для настройки системы мониторинга.

Как же правильно настроить это пианино? Давайте рассмотрим задачи по порядку.

Чего мы хотим добиться

Самая главная задача: любое аварийное сообщение на морде панели управления оборудования должно отображаться в системе мониторинга. Если на устройстве горит красная лампочка, а в мониторинге ничего нет, значит не все переменные включены в мониторинг или их уставки настроены неверно.

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

Этап 1. Определение нужных и ненужных переменных у каждого устройства

Обычно к каждому устройству идет так называемая карта переменных, на основании которой инженером-наладчиком создается драйвер. Его задача указать системе мониторинга, в каком именно регистре получаемых данных находится нужная переменная. Например, в регистре 1 протокола опроса устройства находится информация о режиме работы двигателя System_on_fun, а в регистре 2 о режиме работы компрессора Compressor_1.

Количество переменных у одного устройства часто бывает больше 100. Сотрудник, изначально настраивающий систему (обычно это ИТ-инженер), не может сам решить, что здесь важно, а что нет. Как правило, все переменные добавляются в мониторинг по принципу а вдруг пригодится.

На первое время это допустимо сотрудники службы эксплуатации могут посмотреть на реальные значения всех доступных переменных и понять, что на самом деле им нужно. Но если надолго оставить систему в этом состоянии, то мы получим следующие негативные эффекты:

• Лишние переменные загружают оперативную задачу системы мониторинга и увеличивают размер архива, система вынуждена обрабатывать и сохранять ненужные данные.

• Чем больше опрашивается переменных, тем выше вероятность сбоя опроса. Особенно это актуально для устройств, подключенных по шлейфу (например, через шлюз по протоколу MODBUS). Это приводит к получению состояний нет данных (Н/Д) или обрыв связи, то есть фактически устройство периодически выпадает из мониторинга.

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

На скриншотах приведена часть кода драйвера. Символами // указаны скрытые из опроса переменные. Также виден список переменных, отображаемых для пользователя при настройке уставок в самой BMS.



Заводские уставки внутри устройств по нашему опыту на начальном этапе лучше не трогать (конечно, если они не сообщают вам уже об аварии). Однако на каждой тренировке по конкретному оборудованию следует напоминать сотрудникам о наличии уставок и в самом устройстве, и в BMS. Это в будущем поможет дежурным точно понимать, что именно является причиной аварийного сообщения.

Лишние переменные в драйвере надо постепенно выявлять и скрывать из опроса, а оставшиеся разделить на те, к которым следует назначить уставки, и на те, которые сохраняются без уставок только для последующего анализа и статистики.

Делать это должен не наладчик системы, а сотрудник, понимающий работу системы, которую контролирует система мониторинга, желательно главный инженер или главный энергетик.

Этап 2. Минимизация ложных и неинформативных сообщений

Ложные срабатывания часто происходят из-за сбоев в опросе устройства. Если сетевая карта устройства не снабжена автономным питанием, то и сбой в опросе и реальное отключение питания будут отображаться как один тип аварии обрыв связи.

В этом случае надо разделить оборудование на критическое (например, PDU) и обычное (например, щиты вентиляции ЩУВ). Для обычного оборудования можно установить задержку на сигнал обрыв связи (например, 300 секунд) тогда большинство ложных обрывов будут игнорироваться.

Понятно, что на критическое оборудование такую задержку ставить нельзя, поэтому если оно постоянно дает ложные сбои, то следует разбираться с физической сетью, количеством опрашиваемых переменных. Вполне возможно, что на один шлюз повешено очень много устройств и надо сегментировать сеть через добавление новых шлюзов.

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

В этом случае часть оборудования, запитанного без ИБП, штатно обесточивается и выдает ошибку обрыв связи, а сами ИБП выдают целый букет сообщений нет питания на вводе, нет питания на байпасе, питание от АКБ и т. п. Персонал сразу получает десятки сообщений.

Для оптимизации количества сообщений при переходе на ДГУ следует:

• настроить на штатно появляющиеся во время перехода аварийные сигналы более длительные временные задержки, чем время появления питания от ДГУ. Например, установить задержку на сигнал обрыв связи щита вентиляции 300 секунд при штатном времени перехода на ДГУ 200 секунд.

Тогда питание на ЩУВ появится раньше задержки уставки, и ситуация не будет распознана как аварийная. При это есть критически важные устройства, которые запитаны от ИБП и всегда должны быть на связи (например, PDU) сообщения об их дисконнекте должны появляться без задержки.

• проанализировать сообщения от ИБП при переходе на ДГУ и разделить их на нормальные с присвоением им желтого типа (например, констатация факта нет питания на вводе) и ненормальные (отключение батарейного автомата, которого быть не должно в любом режиме работы), с присвоением им красного типа.

При этом отдельно записываем в инструкцию дежурным, что в случае перехода на ДГУ желтые аварии можно наблюдать и не квитировать (они пропадут сами после завершения штатного перехода), а красные немедленно устранять (их быть не должно).

За один раз, полагаясь только на теорию, настроить уставки для этого переходного процесса очень сложно. Для успешной настройки надо несколько раз наблюдать за переходами на ДГУ в реальном времени.

Например, нам потребовалось наблюдение за 4-5 переходами для приемлемой настройки новой BMS. Чтобы проанализировать внеплановый процесс перехода, мы делали запись экрана системы мониторинга, так как важно наблюдать аварийные сообщения не в архиве событий, а анализировать появление аварий в динамике оперативной сводки.

Этап 3. Дополнительные советы из нашего опыта

1.На экранах дежурной смены не должно быть лишней индикации в цветах аварийных сообщений.

Пример из реальной практики. Один ЦОД заказал карту температурных потоков в серверной. Это 3D модель потоков воздуха с множеством температурных данных с датчиков. Получился вид северной с потоками воздуха где-то воздух был выделен зеленым, где-то желтым и красным (от самого холодного к самому горячему). При этом температуры воздуха везде в пределах нормы, а цвета применены только для наглядности отображения разницы температур в разных точках.

Далее этот пестрый вид вывели на один из мониторов в дежурке. В итоге получилось, что инструмент, созданный для аналитики процессов, оказался перед глазами дежурных, которые заточены бежать к оборудованию при виде красного цвета и напрягаться при виде желтого.

Наверное, дежурным объяснили, что на левом экране красное/желтое это нормально, а на правом экране эти же цвета сигнал к действию. Однако ясно, что такая практика очень серьезно увеличивает риск человеческого фактора.

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

2. С осторожностью используйте SMS-оповещения.

Несколько лет назад мы еще опасались плохого мобильного интернета и использовали SMS вместо мессенджеров. Один раз я случайно выставил неправильную уставку, она применилась ко всем одноименным в 100 устройствах, и подписанным на рассылку коллегам на телефоны пришло по 100 SMS-сообщений. С тех пор мы не используем SMS-рассылку.

3. Настраивайте дублирование сообщений об авариях через мессенджер.

Это можно реализовать, например, через Microsoft Teams или Telegram. Сообщения об авариях будут приходить и вам, и дежурным, при этом телефон будет издавать звуки и вибрировать (чего нет при работе с системой через браузер).

И не бойтесь, что сообщений будет много. По нашему опыту, за среднестатистический день работы ЦОДа приходит всего несколько десятков сообщений, и они не загружают телефоны сотрудников. То есть оборудование ЦОД и систему BMS можно настроить так, чтобы не получать сотни оповещений и при этом ничего важного не пропускать.

Чтобы сообщений было меньше, включайте в рассылку только оповещения о возникновении красных и желтых аварий, то есть необходимый минимум, позволяющий держать руку на пульсе событий.

4. Группируйте сообщения в мессенджерах.

Во время перехода на ДГУ или из-за комплексной аварии у вас будут запущены десятки активных аварийных ситуаций, телефон будет постоянно вибрировать от поступающих в мессенджер сообщений, не давая сделать важный звонок или открыть окно системы мониторинга.

Можно настроить рассылку так, чтобы в мессенджер приходило одно общее сообщение с общим списком аварий, произошедших за последнюю минуту. На появление аварий в сводке системы BMS эта настройка не влияет (аварии появляются в сводке без задержки), а за 1 минуту задержки поступления сообщения на телефон вы ничего не пропустите, а вот сообщений на ваш телефон будет приходить в разы меньше.

5. Ярко выделяйте в интерфейсе сообщение о пропадание связи с сервером.

Например, в помещении дежурных пропал интернет. Интерфейс пользователя не имеет связи с сервером и поэтому авария не появляется в сводке, тусклая надпись сервер не доступен может быть не замечена персоналом, сотрудники могут долго смотреть в зеленую панель BMS с числовыми параметрами, не подозревая о том, что она находится в офлайне.

На скриншоте пример индикации о пропадании связи с сервером BMS, при этом отображаются неактуальные параметры работы оборудования.


6.Подключайте к мониторингу как можно больше систем.

Например, традиционно система пожарной сигнализации работает автономно, а ее панель висит на посту охраны.

Да, по сигналу ПОЖАР срабатывают автоматические алгоритмы работы систем, запускается система оповещения, но о появлении сигналов Неисправность или Внимание сотрудник охраны сообщает дежурным голосом.

Полноценно подключить к мониторингу такую систему очень сложно, но в такой системе легко настроить три релейных сигнала неисправность, внимание и пожар, а затем подключить их сухими контактами в модуль системы BMS.

Тем самым снижается риск пресловутого человеческого фактора. Пример тестового сигнала ПОЖАР в системе BMS ЦОДа, подключенного через сухие контакты.


Подведем итоги нашей 4-серийной истории

Система мониторинга дата-центра это не просто глаза и уши для наблюдения за инженерными системами ЦОДа. Ее правильная работа позволяет достигать высочайшего уровня надежности через непрерывность работы площадки, а, значит, обеспечивает компании дополнительное конкурентное преимущество.

Пройдя довольно трудный и длинный путь, мы получили:

• быструю и стабильную систему мониторинга, которая на данный момент контролирует более 2500 устройств и обсчитывает около 10000 виртуальных датчиков;
• резервирование системы на платформе облачных решений Linхdatacenter в Санкт-Петербурге и Москве;
• доступ к системе из любой точки мира через веб-интерфейс, с дополнительной отправкой сообщений из системы на любые мессенджеры, что позволило сократить максимальное время информирования персонала об аварии до 1 минуты;
• ощутимую экономию, так как система обошлась в разы дешевле аналогов, легко масштабируется и не требует платы за лицензии для устройств или пользователей;
• надежное решение, которое позволило нам не только улучшить собственные процессы, но и предложить новый коммерческий продукт нашим заказчикам гибко настраиваемую и масштабируемую систему мониторинга.

Ранее мы уже рассказывали о том, как проходили аттестацию Uptime Institute Management & Operations Stamp of Approval в 2018 году и подтверждали уровень соответствия его требованиям в 2020.

Сегодня поговорим о тренировке и проверке знаний инженеров ЦОДа это опыт Linxdatacenter в Санкт-Петербурге, который сертифицирующая организация взяла на вооружение в своей работе.

Напомним, о чем идет речь: стандарт Management & Operations отраслевого экспертного института Uptime Institute оценивает качество управления инженерных служб дата-центров и направлен на снижение количества отказов из-за человеческого фактора.

Он появился в результате анализа 6000 эпизодов отказов ЦОДов за 20 лет наблюдений за отраслью и является частью (одной из трех) более емкого отраслевого стандарта Operational Sustainability.

Помимо M&O (управление и эксплуатация) туда входят также Building Characteristics (характеристики здания) и Site Location (расположение площадки). Вопросы управления и эксплуатации ЦОДа в этой иерархии играют главную роль в эксплуатационной устоичивости площадки.

Более 75% всех сбоев обусловлено человеческим фактором: он включает как прямые ошибки оператора, так и принятие неверных управленческих решений при комплектовании штата, выстраивании процессов обслуживания, обучения и общего подхода к работе.

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

Аттестация зрелости

Одно из базовых положений стандарта, на котором мы и развернули программу аттестации персонала, гласит: Наличие надлежащего количества квалифицированных сотрудников имеет решающее значение для достижения долгосрочных целеи. Без надлежащего количества квалифицированных сотрудников и правильнои организации их труда, у ЦОД не будет ресурсов для успешного функционирования.

Обеспечить себя такими сотрудниками стандарт рекомендует через качественный подбор персонала и выработку комплексного подхода к обслуживанию ЦОДа. Такая программа состоит из профилактического обслуживания (PM), политики уборки, системы управления техническим обслуживанием (MMS) для отслеживания работ, а также соглашения об уровне обслуживания (SLA).

Чем выше уровень Tier дата-центра, чем быстрее растут целевые показатели его производительности, строже становятся требования к организации, поскольку сложность и детализация каждого из этих элементов увеличивается.

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

Только такой подход обеспечивает согласованность эксплуатации и технического обслуживания инфраструктуры ЦОД. Цитируя стандарт еще раз: Весь персонал должен понимать политики, процедуры и уникальные требования к работе в ЦОД, чтобы избежать незапланированных простоев и реагировать на ожидаемые события.

Собственно, отсюда и берет начало наша система аттестации.

Вторая ее идеологическая опора стандарт ISO 22301 Security and resilience Business continuity management systems Безопасность и устойчивость Системы управления операционной непрерывностью бизнеса.

Этот стандарт непосредственно регулирует шаги компаний (во всех сферах, не только ИТ) по обеспечению непрерывного характера своей деятельности вне зависимости от наступления экстренных ситуаций и неблагоприятных внешних условий.

Один из его пунктов указывает, что организация должна определить необходимые компетенции лиц, выполняющих работу, которая влияет на обеспечение ее бесперебойного функционирования. И далее по тексту, на компании накладываются обязательства по обеспечению компетенций этих лиц на основе соответствующего образования, подготовки или практического опыта.

Этот процесс нужно поддерживать, совершенствовать и оценивать его результаты, сохраняя соответствующую документально подтвержденную информацию в качестве доказательства компетентности.

Наконец, третий столп нашей программы собственный опыт нескольких лет последовательной работы над повышением скоординированности и эффективности работы инженерных служб. Этот опыт нашел отражение в нашей документации по процедурам аварийной эксплуатации (EOP Emergency Operations Procedures), в том числе в части аттестации персонала.

Четко задокументированные и формализованные процедуры в структуре бизнес-процессов площадки в Санкт-Петербурге позволяют оценивать профессиональный уровень работника и выявлять соответствие его квалификации занимаемой должности или выполняемой им работы.

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

Основные виды и главные задачи

Зачем нам это нужно? С одной стороны да, работали как-то без аттестации раньше, без нее также обходятся масса (да почти все) коллег по отрасли.

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

Мы постоянно занимаемся апгрейдом инженерных подсистем и групп процессов управления дата-центром. Только за последнее время были внедрены процессы профилактическогоухода за дизель-генераторными установкамиианализа качества поставляемого топливадля них, контроль уровнядавления и подпора воздухав серверных в помещениях икомплекс мер по предотвращению загрязнения воздуха. Также была проведена серьезная модернизация системы управления зданием (BMS), внедрен в эксплуатацию широкий спектркомпонентов системы LOTO.

В ходе этих работ мы неоднократно убеждались, что любые методики контроля качества приносят хороший результат, только если они формализованы и применяются на регулярной основе это еще одна причина ввода обязательной аттестации.

Кроме того, такие проверки помогают стимулировать рост эффективности и качества труда, определить необходимость повышения квалификации и подтягивания уровня знаний конкретных специалистов, а также организовать правильную расстановку кадров с учетом уровня их профессиональных знаний и навыков.

Перед плановой аттестацией руководители проводят подготовительную консультационную работу, а именно за две недели аттестуемому персоналу сообщаются критерии аттестации, вопросы для экзамена, проводят разъяснительные консультации.

Все вопросы сопровождаются подробно разобранными ответами со ссылками на нормативные документы и инструкции.

Процедура по сути

Аттестацию проводит комиссия в составе не менее трех человек, процедура состоит из двух этапов.

На первом проводится тестирование аттестуемого работника в рамках опросников и тестов. Общее количество вопросов 60-70 в зависимости от специализации. Во время аттестации случайным образом выбираются 15. Около 80% вопросов касаются непосредственно профессии, остальные 20% смежных областей знаний и компетенций коллег по ЦОДу.

Для проведения аттестации был разработан специальный внутренний портал, который позволил автоматизировать и сделать прохождение аттестации регистрируемым процессом



Примеры вопросов для сотрудников различных департаментов

Механики

Раздел Maintenance (Обслуживание)

1. Когда запланировано следующее ТО систем, за которые вы отвечаете?
2. Сколько сотрудников указано в списке на доступ от подрядчика, который будет проводить следующее ТО?
3. Какая текущая версия и дата утверждения документа с контактами и SLA поставщиков?
4. Что такое Предупредительное обслуживание? (Predictive maintenance)? Дайте ссылку на инструкцию по Predictive maintenance и график его проведения.
5. Какие виды технического обслуживания проводятся в ЦОД? Чем они отличаются? Где можно увидеть списки такого обслуживания?

Раздел EOP

1. При какой температуре в помещениях ИБП нужно начинать выполнение EOP?
2. При каком давлении в системе ХС нужно начинать выполнение EOP?
3. Укажите действия при неисправности фанкойла Water loss alarm.

ИТ-инженеры

Раздел Оборудование

1. Укажите ближайшую дату поверки средства измерения (и его тип) по вашим системам.
2. Приложите ссылку на папку с документацией к любому оборудованию, относящемуся к вашим системам.
3. Приложите ссылку на исполнительную документацию по любой из обслуживаемых вами систем.
4. Приложите ссылку на папку с альбомом последних версий схем по обслуживаемым вами системам.

Раздел Работа в системе инцидент-менеджмента

1. Как определить, какой приоритет нужно поставить обращению?
2. Если для решения проблемы нужна дополнительная информация от клиента, какой статус нужно выставить в тикете?
3. Ваши действия при поступлении высокоприоритетных обращений в нерабочее время.
4. Как правильно запросить дополнительную информацию от клиента?
5. В чем разница в статусах On Hold и Waiting? Учитываются ли эти статусы при расчете времени решения обращения?

Инженеры-электрики

Раздел Общие инструкции, Приказы (Common Instructions, Orders)

1. Укажите ваши действия при пожаре в ЦОД и при пожаре в ДГУ.
2. Укажите ваши действия при появлении неисправностей на пожарной панели ЦОД или ДГУ.
3. Укажите ваши действия при ложном срабатывании систем пожаротушения ЦОД или ДГУ.
4. Каким документом регламентируются работы в действующих электроустановках?
5. Что должен сделать контролирующий системы мониторинга при появлении аварийных и предупредительных сообщений (за исключением периода перехода между источниками энергии)?
6. Где располагается мастер-ключ для экстренного доступа в стойки клиентов?
7. В каких инструкциях указаны меры по работе во время пандемии и какие они?

Как видно из приведенных примеров, мы учитываем текущие реалии, в которых работаем. В данном случае это вопросы по состоянию на декабрь 2020 года.

Второй этап процедуры аттестации состоит из личного собеседования комиссии со специалистом. В работе аттестационной комиссии обязательное участие принимает непосредственный руководитель аттестуемого работника.

Основными критериями, исходя из которых оцениваются профессиональные компетенции работника, являются уровень его подготовки, в том числе профессиональные навыки, итоги работы за определенный период времени, а также соответствие требованиям к занимаемой должности.

Решение принимается открытым голосованием большинством голосов.

Вердикты

По результатам аттестации выносится заключение:

• занимаемой должности соответствует;
• соответствует, но не полностью (рекомендуется повторная аттестация); или
• не соответствует занимаемой должности.

В первом случае сотрудника могут включить в резерв на вышестоящую должность, условия трудовых соглашений с ним не меняются. В последнем же рассматривается вопрос либо о переводе на другую работу, требующую более низкой квалификации, либо о расторжении трудового договора по п. 3 ч. 1 ст. 81 ТК РФ.

Неполное соответствие чревато переводом с согласия сотрудника на другую работу, а также направлением на курсы повышения квалификации (дополнительного обучения).

Тяжело в учении легко в бою

Большую роль в процессе обучения сотрудников служб эксплуатации дата-центра играет практический аспект тренировки и учения.

В качестве примера приведем выдержки из итогового протокола учений по отработке действий сотрудников дежурной смены и охраны ЦОДа в Санкт-Петербурге.

Хронология событий

10⁵⁰ Произошел пожар (имитация) помещении 107. Сработала пожарная сигнализация и система голосового оповещения.

10⁵⁰ Руководитель смены охраны объекта связался с дежурной сменой ЦОДа, сообщив им о месте пожара и поставил задачу сотруднику охраны по организации эвакуации клиентов ЦОДа.


12⁰⁷ Сотрудник охраны выдвинулся в ЦОД для проверки путей эвакуации, разблокировки калиток на путях эвакуации, проверки разблокировки полноростового турникета, организации эвакуации людей. Сотрудник охраны экипирован электрическим фонарем, изолирующим противогазом и рацией для связи.


12⁰⁷ Звонок сотрудника охраны ЦОДа старшему смены охраны ПСБ СКАЙ-ТРЕЙД с сообщением о происшествии в ЦОДе.

12⁰⁸ Начало эвакуации людей, не задействованных в обнаружении и локализации (ликвидации) пожара, из помещений ЦОДа.

12⁰⁹ Сотрудники дежурной смены ЦОДа выдвинулись для проверки причин срабатывания пожарной сигнализации и организации эвакуации людей из ЦОДа.


12¹¹ Сотрудники дежурной смены ЦОДа подошли к месту предполагаемого пожара. Сотрудники экипированы электрическими фонарями и изолирующими противогазами.


12¹² Доклад сотрудника охраны о том, что все помещения свободны и люди из ЦОДа эвакуированы.

12¹² Эвакуация завершена.


12¹⁵ Перевод системы пожарной сигнализации и голосового оповещения из режима Пожар в дежурный режим. Окончание пожарно-технической тренировки.

Это отчет о событийной канве мероприятия, которая, как мы видим, укладывается во временной промежуток продолжительностью чуть более одного часа. Далее лица, ответственные за проведение учений, указывают выявленные несоответствия и перечисляют решения, принятые в отношении команды.

В данном конкретном случае не был сымитирован звонок сотрудника дежурной смены на пульт пожарной охраны поэтому оценка только 4.

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

Выводы и планы развития

Формализация и документирование процессов помогают обеспечить историчность (отслеживание динамики), а также объективность оценок.

На данном этапе развития направления нам удалось реализовать комплексный подход к обучению и проверке уровня знаний персонала ЦОДа, от которых зависят такие показатели, как непрерывность работы площадки, и, в конечном итоге, SLA для клиентов.

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

И люди в этом перечне на первом месте.

Профессия системного администратора всегда сопровождается стереотипным восприятием. Сисадмин это некий универсальный айтишник в любой компании, который чинит компьютеры, поднимает Интернет, занимается оргтехникой, настраивает программы и т. д. Дошло до того, что появился День Сисадмина последняя пятница июля, то есть сегодня.

Более того, у праздника сегодня юбилей первый День Сисадмина был отпразднован в 2000 году в Чикаго американским универсальным айтишником по имени Тед Кекатос. Это был пикник на природе с участием сотрудников небольшой софтверной компании.

В Россию праздник пришел в 2006 году, когда под Калугой состоялся Всероссийский слёт системных администраторов, к котором далее добавился аналогичный ивент в Новосибирске.

Профессия живет и развивается, и сегодня отличный повод взглянуть на ее эволюцию, текущее состояние и перспективы, открываемые работой сисадмином в мире больших ИТ.

Сисадмин: вчера и сегодня

Сегодня существует множество вариаций практического наполнения работы системным администратором.

В небольшой компании до 100 сотрудников один и тот же человек может выполнять обязанности сисадмина, менеджера, он же будет управлять лицензиями на ПО иотвечать за обслуживание оргтехники, настраивать Wi-Fi, отвечать на запросы пользователей, отвечать за серверы.Если вдруг в компании есть 1С, то соответственно, этот человек еще каким-то образом будет разбираться и в этом направлении. Такова работа сисадмина в относительно малом бизнесе.

Что касательно компаний покрупнее сервис-провайдеров, cloud-провайдеров, разработчиков ПО и т. д., то здесь, безусловно, есть более углубленные сценарии эволюции профессии сисадмина.

К примеру, в таких компаниях навернякабудет позиция выделенного Unix-администратора, Windows admin, обязательно будет безопасник, а также сетевые инженеры. Наверняка у них у всех есть руководитель ИТ-отдела или ИТ-менеджер, который отвечает за управление инфраструктурой и ИТ-проекты в департаменте. В крупных компаниях понадобится уже ИТ-директор, разбирающийся в стратегическом планировании, и тут не лишним будет дополнительно получить степень MBA к уже имеющемуся техническому бэкграунду. Нет единственно правильного решения, все зависит от компании.

Большинство молодых коллег, кто еще только начинает карьеру сисадмина, начинают с первой и второй линий техподдержки отвечают на дурацкие вопросы пользователей, набираются опыта и приобретают навыки стрессоустойчивости. Их обучают более опытные системные администраторы, разрабатывают им алгоритмы действий по распространенным сценариям траблшутинга, настройки и т. д. Человек потихоньку обучается, и, если он успешен и ему все нравится, он постепенно дорастает до следующей ступени.

Здесь мы переходим к вопросу о том, можно ли рассматривать сисадминство, как некий портал в более серьезную ИТ-карьеру, или это какой-то замкнутый уровень, где можно развиваться лишь горизонтально?

The sky is the limit

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

Вначале ты специалист отдела ИТ-поддержки, потом системный администратор, а далее встает выбор специализации. Можно пойти в программисты, в Unix-администраторы, в сетевые инженеры, а также стать системным ИТ-архитектором или специалистом по безопасности или даже менеджером проектов.

Безусловно, все не так просто во-первых, надо набираться опыта, сдавать экзамены по различным учебным программам, получать сертификаты, регулярно доказывать, что ты способен показывать результат и применять полученные знания и опыт, постоянно обучаться. Если сисадмин выбирает путь развития в направлении системного архитектора, то здесь можно рассчитывать на зарплату не хуже, чем у ИТ-руководителей.

Кстати, из сисадмина можно пойти и в ИТ-менеджмент. Если тебе нравится управлять, сотрудничать, направлять то тебе путь заказан в область управления проектами.

Как вариант можно остаться системным администратором на очень хорошем профессиональном уровне, и развиваться в узкоспециализированной области, например в какой-нибудь облачном провайдере, сосредотачиваясь на задачах по облачной инфраструктуре и виртуализации.

К счастью для сисадминов, сегодня нет такой возможности, которая не была бы открыта для коллег каждый выбирает сам, куда ему дальше расти и развиваться.

Образование переоценено?

Хорошая новость: можно говорить, что порог вхождения в ИТ через позицию сисадмина не требует специального, скажем, математического, образования.

Среди знакомых встречалось немало гуманитариев, которым удалось построить успешную карьеру, начав с ИТ-саппорта и далее по описанному маршруту. Сисадминство здесь становится отличными ИТ-университетами.

Безусловно, техническое образование не будет лишним и, даже наоборот, будет очень полезно, но и в этом случае нужно будет проходить на какие-нибудь курсы по специальности и набираться опыта на реальных кейсах.

В целом, если человек захотел стать сисадмином, то сегодня это не такая закрытая профессия, как, скажем, пилот истребителя. Начать движение в сторону своей мечты можно буквально на диване дома с изучения литературы или курсов с экрана смартфона. Очень много информации по любому направлению доступно в виде бесплатных и платных курсов и статей.

Есть возможность подготовиться к своей первой ИТ-работе дома и совершенно спокойно потом устроиться в ИТ-поддержку.

Безусловно, те, кто обучался смежным специальностям в вузе, имеет стартовое преимущество, но, с другой стороны, человек с хорошим математическим образованием вряд ли планирует пойти в поддержку или в сисадмины, скорее всего он выберет другой путь например Big Data. А это серьезно снижает конкуренцию непосредственно на начальном уровне вхождения в отрасль.

Навыки: топ-5 сисадминских скиллов-2020

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

Прежде всего это желание работать и расти в этой профессии, энтузиазм, работоспособность и готовность постоянно учиться. Это главное.

Если человек где-то услышал, что сисадмин это круто, но, попробовав, понял, что ему профессия не нравится, то лучше не тратить время зря и сменить специальность. Профессия требует к себе отношения всерьез и надолго. В ИТ постоянно что-то меняется. Здесь нельзя разово что-то выучить и сидеть на этих знаниях лет 10 и ничего не делать, не изучать что-то новое. Учиться, учиться и еще раза учиться. /В. И. Ленин/

Второй важный аспект скиллсета это хорошая память и аналитические навыки. Постоянно нужно держать в голове массу знаний, добавлять к ней новые объемы и предметные области, уметь творчески их осмысливать и преобразовывать в сумму полезных профессиональных действий. И уметь выуживать и применять знания и опыт в нужный момент.

Третья часть минимальный набор профессиональных знаний. Для выпускников профильных технических вузов будет достаточно: знания основы баз данных, принципов устройства ОС (не глубоко, не на уровне архитектора), представления о том, как софт взаимодействует с железом, понимания принципов работы сетей, а также начальных навыков в программировании, базовых знаний TCP/IP, Unix, Windows систем. Умеешь переустанавливать Window и собрать свой компьютер самостоятельно значит уже почти готов стать сисадмином.

Одна из примет времени сегодня автоматизация, каждый сисадмин приходит к тому, что какие-то процессы проще прописать на уровне скриптов, сокращая таким образом свой нудный ручной труд.

Четвертый пункт знание английского языка, это совершенно обязательный навык. Пополнять свой личный багаж знаний лучше из первоисточников, язык ИТ сегодня это English.

Наконец, пятый аспект скиллсета сисадмина образца 2020 года мультифункциональность. Сейчас все переплетено, к примеру, иWindows и Unix, как правило, перемешаны в одной инфраструктуре по разным блокам задач.

Unix используется сейчас практически везде, и в корпоративных ИТ-инфраструктурах, и в облаках, на Unix уже работает 1C и MS SQL, а также облачные сервера Microsoftи Amazon cloud.

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

Словом, нужно соответствовать стереотипу #тыжайтишник и уметь работать на результат по любым задачам.

DevOps почти не виден

Один самых очевидных сценариев и трендов развития карьеры сисадмина сегодня DevOps; таков, по крайней мере, стереотип.

На самом деле, все не так просто: DevOps специалист в современном ИТ это больше помощник программиста, который постоянно доводит до ума и чинит инфраструктуру, разбирается, почему код заработал на одной версии библиотеки, а на другой не заработал. DevOps также автоматизирует разныеалгоритмы по развертыванию и тестированию продукта на своих или облачных серверах, помогает выбрать и сконфигурировать архитектуру ИТ-компонентов. И безусловно он может что-то напрограммировать и прочитать чужой код, но это не его основная функция.

DevOps это, по сути, немножко более специализированный системный администратор. Так его назвали, но профессию и задачи по сути это не изменило. Опять же сейчас эта профессия в тренде, но кто не успел туда зайти, имеют шанс сделать это на протяжении около 5 следующих лет.

Сегодня восходящий тренд в области построения ИТ-карьеры от уровня сисадмина робототехника и автоматизация (RPA), ИИ и Big Data, DevOps, Cloud admin.

Профессия сисадмина всегда находится на стыке разных предметных областей, это некий конструктор компетенций и навыков для самостоятельной сборки. Не лишним будет получить скилл стрессоустойчивости и минимальные знания психологии. Не стоит забывать, что вы работаете не только с ИТ, но и с людьми, которые бывают очень и очень разными. Вам также придется не раз объяснять, почему ваше ИТ-решение лучше, чем другие, и почему стоит использовать именно его.

Добавлю, что профессия будет оставаться востребованной неограниченно долго. Потому что все обещания крупных ИТ-вендоров, анонсирующих выпуск полностью самодостаточных платформ и систем, которые не будут ломаться, будут сами себя обслуживать и чинить, пока что не подтверждаются практикой. Об этом то и дело говорят Oracle, Microsoft и другие крупные компании. Но ничего такого не происходит, потому что информационные системы остаются предельно разнообразными и неоднородными с точки зрения платформ, языков, протоколов и т.д. Никакой искусственный интеллект пока не в состоянии настроить гладкую работу комплексных ИТ-архитектур безошибочно и без вмешательства человека.

А это значит, что сисадмины будут нужны еще очень долго и с очень высокими требованиями к их профессионализму.

IT-manager компании Linxdatacenter Илья Ильичев

Данная статья задумывалась как отправная точка, которая поможет новичкам быстро вникнуть в суть работы с БД RIPE, чтобы в голове сложилась целостная картина и понимание, для чего в ней используются те или иные объекты. Отмечу, что данная статья дает только общее представление о работе с данной системой, не описывая детальные шаги, но тем не менее я надеюсь, что после прочтения вам будет легче разобраться в вопросе.

Рано или поздно большинство сетевых инженеров сталкиваются с необходимостью взаимодействия с базой данных RIPE. Например, если вы устроились на работу в компанию, предоставляющую доступ в интернет, или организацию, которая владеет собственной автономной системой, то вам с 99%-ной вероятностью потребуется периодически добавлять/удалять и поддерживать актуальной какую-то информацию в БД RIPE. Даже просматривая вакансии при поиске работы, иногда можно наткнуться на требование Умение работать с RIPE.

Также в ходе своей работы, решении каких-то задач или устранении неполадок, вам может потребоваться, например, следующее: узнать контактные данные технических специалистов, администрирующих блоки определенных IP-адресов, уточнить политику маршрутизации, которая применяется в соседней с вами автономной системе, или направить жалобу о неправомерном использовании IP-адресов, принадлежащих какой-то организации и т. д. Когда сталкиваешься с этими задачами впервые, можно немного растеряться. Так что умение работать с БД RIPE и понимание того, как найти в ней необходимую информацию это полезный и нужный навык.

В ходе данной статьи я попробую ответить на вопросы: что из себя представляет БД RIPE? Какие функции она выполняет? Какие основные объекты используются на практике?

Найти более подробную информацию вы всегда можете в официальной документации: https://www.ripe.net/manage-ips-and-asns/db/support/documentation/ripe-database-documentation. В конце статьи также представлена ссылка на замечательный бесплатный курс от RIPE NCC, который включает в себя в том числе интересные интерактивные задачи, которые помогут получить практический опыт.

Начнем с определений:

1. IRR Internet Routing Registry. Это глобальная распределенная база данных маршрутных политик. Задумывалась такая база как инструмент, с помощью которого операторы связи смогут делиться своими маршрутными политиками и информацией о том, какие сети и кому они анонсируют. В совокупности это должно способствовать большей стабильности работы сети Интернет, помогать инженерам при устранении неполадок, связанных с глобальной маршрутизацией. Также эта база может являться источником данных для различных программ, которые помогают автоматически генерировать конфигурацию оборудования на основании доступной там информации. IRR использует так называемый язык спецификации маршрутных политик (RPSL) для описания хранимых в ней данных. БД RIPE в том числе исполняет и функции IRR.

2. RPSL Routing Policy Specification Language. Это язык, с помощью которого описываются маршрутные политики. Этот язык объектно-ориентированный, но к программированию он не имеет никакого отношения. По сути, он описывает классы объектов, а конкретные объекты в своих атрибутах содержат уже конкретную информацию. Например, есть класс aut-num, он описывает автономную систему: ее номер, какой организации принадлежит, к кому можно обратиться в случае проблем связности с этой автономной системой и т. д. Объекты, в свою очередь, являются кирпичиками, из которых состоит БД RIPE.

Подробнее про RPSL можно почитать тут:

https://www.rfcreader.com/#rfc2622

https://www.rfcreader.com/#rfc2650

Функции БД RIPE

Поддержание актуальной контактной информации

Интернет состоит из огромного количество связанных между собой сетей, автономных систем и людей, поддерживающих его работоспособность. Иногда вам может потребоваться узнать, кому принадлежит та или иная автономная система или блок IP-адресов, и как связаться с теми, кто за них отвечает. Вы не можете держать в своей записной книжке все эти контакты. БД RIPE именно то место, где данную информацию можно оперативно найти.

Учет интернет-ресурсов

Под интернет-ресурсами здесь понимаются блоки IP-адресов и номера автономных систем. RIPE NCC, являясь одним из RIR, занимается распределением интернет-ресурсов и их учетом для Европы, Ближнего Востока и Центральной Азии. Информация о выделенных номерах AS, распределенных блоках IP-адресов и т. д. все это учитывается и отображается в БД RIPE.

Публикация маршрутных политик

Как говорилось ранее, БД RIPE выполняет в том числе и функции IRR. Здесь, компании, владеющие своими автономными системами и блоками IP-адресов, могут публиковать свои маршрутные политики, тем самым делясь с остальными участниками информацией об их глобальной политике маршрутизации с внешним миром.

Обеспечение работы механизма DNS reverse lookup

БД RIPE играет ключевую роль в работоспособности DNS reverse lookup. Мы вернемся к этому вопросу позже.

Способы взаимодействия с БД RIPE

Необходимость взаимодействия с БД RIPE у вас может быть по следующим причинам: вы хотите найти какую-то информацию или вы хотите добавить/изменить/удалить какую-то информацию в ней.

Чтобы получить информацию из БД RIPE, можно воспользоваться сервисом whois прямо на сайте RIPE https://www.ripe.net/, либо одноименной утилитой, которая присутствует почти во всех дистрибутивах Linux.

Существует 4 способа добавить, изменить или удалить информацию:

1. Webupdates. Это самый простой и интуитивный способ работы с объектами. Вы просто заходите на сайт RIPE, авторизуетесь и с помощью веб-формы выполняете необходимые вам действия с объектами (при условии, что вы авторизованы это делать). Сам процесс выглядит так:

Шаг 1. Заходим в панель управления ресурсами, нажимаем Create an Object, выбираем тип создаваемого объекта и нажимаем Create.


Шаг 2. В следующем окне заполняем обязательные поля и нажимаем Submit:


Если вы корректно заполнили все обязательные поля для создаваемого объекта, то все пройдет гладко, в противном случае вы увидите сообщение о том, где вы допустили ошибку.

2. По электронной почте.

Вы отправляете письмо на специальный почтовый адрес auto-dbm@ripe.net, в теле письма полностью описываете атрибуты и значения объекта, который вы хотите добавить, изменить или удалить. Сейчас этот способ применяется редко, куда проще воспользоваться другими методами.

3. Syncupdates.

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

4. RESTful API.

Также работать с объектами в БД RIPE можно с помощью RESTful API. Данный способ удобно использовать для автоматизации каких-то действий с помощью скриптов. Подробное описание API можно посмотреть тут:

https://github.com/RIPE-NCC/whois/wiki/WHOIS-REST-API

Например, мы используем API БД RIPE следующим образом:

У нас есть IPAM система, в которой мы ведем учет всех наших IP-адресов. Когда нам необходимо выделить новую подсеть для клиента, то мы запускаем скрипт, который через API вытаскивает из IPAM первую свободную подсеть необходимого размера, далее через скрипт мы заполняем краткое описание назначения данной подсети. Затем скрипт с помощью API IPAM добавляет данную подсеть в базу IPAM, а с помощью API RIPE создает объект inetnum(6) в базе RIPE. Таким образом, нам не нужно самим заходить в IPAM, искать там свободную подсеть, затем заходить на сайт RIPE и создавать там новый объект вручную.

Общие свойства всех объектов

Как говорилось ранее, БД RIPE состоит из объектов. Каждый объект представлен двумя колонками: атрибуты (слева) и фактические значения (справа). Атрибуты всегда заканчиваются двоеточием :.

Пример объекта, описывающего вымышленную организацию Sandbox Inc.:


Объекты имеют обязательные и опциональные атрибуты. Обязательные атрибуты должны присутствовать в каждом объекте соответствующего класса, например, атрибут org-name: в объекте organisation из примера выше. Некоторые атрибуты могут повторяться.

Для того, чтобы узнать, какие атрибуты объекта обязательные, какие опциональные, какие можно использовать повторно, а какие нет, можно воспользоваться запросом whois -t object_type:


Здесь видно, что атрибут phone: является обязательным для объектов типа role, а атрибут e-mail: опциональным и может повторяться.

Когда вы создаете объект с помощью webupdates, то обязательные атрибуты сразу же отображаются в веб-форме, вам их нужно просто заполнить. Если же вы будете использовать какой-то скрипт для обновления через API, то уже сами должны позаботиться о том, чтобы не забыть указать обязательные атрибуты и их значения. Для этого удобно использовать шаблоны. Например, так может выглядеть шаблон Jinja2, описывающий объект inetnum в формате:



Если вы о чем-то забудете, то при попытке добавить объект в БД RIPE вам вернется код ошибки с описанием причины, по которой операция не может быть выполнена.

Также некоторые атрибуты объекта являются ключами. По ключам осуществляется поиск объектов в БД RIPE. Существует 3 типа ключей:

1. Primary уникальный ID объекта, однозначно определяет его в БД.
2. Lookup ключи, по которым объект можно найти в БД.
3. Inverse Lookup ключи, которые ссылаются на какой-то другой объект. Данный тип ключей используется, когда вы, например, хотите найти все объекты route, которые зарождаются в какой-то AS. Для этого в запросе whois используется ключ -i. Пример:

Данный запрос находит все объекты класса route, которые зарождаются в AS48399.

Найти объекты можно только по атрибутам, которые являются ключами, причем в параметрах поиска нужно указать точное значение атрибута. Например, атрибут aut-num: объекта aut-num является primary ключом. Если вы хотите найти объект aut-num, который создан для AS48399, то вам нужно указать в запросе именно as48399, варианты 48399 и as 48399 не дадут должного результата:


Назначение объектов

Объекты по их назначению можно условно разделить на 5 групп:

1. Контактная информация: person, role, organization.

2. Интернет-ресурсы: inetnum, inet6num, aut-num.

3. Маршрутизация, политика маршрутизации: route, route6, as-set, aut-num.

4. Reverse DNS: domain.

5. Безопасность объектов: maintainer.


Далее пройдемся по всем этим объектам, чтобы понять их назначение.

Группа Контакты

Объект person

Служит для описания контактной информации конкретного человека, который так или иначе связан с какими-то интернет ресурсами. Другие объекты, например inetnum, могут ссылаться на объект person в своих атрибутах admin-c или tech-c. Таким образом вы можете узнать контактную информацию человека или группы, которые отвечают за те или иные ресурсы.


В примере выше представлен объект inetnum, который содержит информацию о том, что блок IPv4 адресов 80.12.176.0/22 был выделен организации Sandbox и что в случае возникновения каких-то технических вопросов, связанных с данным блоком адресов, вы можете обращаться к персоне Jean Blue.

Был забавный случай, когда у моего бывшего коллеги раздался неожиданный звонок и человек на том конце трубки, не выбирая выражений, угрожал ему физической расправой. Выяснилось, что ему нагрубил какой-то школьник в онлайн-игре и скинул ему свой IP, который он узнал по запросу узнать мой IP адрес. Разумеется, школьник сидел за NAT. Наш хакер, недолго думая, вбил другой запрос узнать кому принадлежит IP и увидел контактную информацию моего коллеги, которая содержится в RIPE. Пришлось объяснять местному Кевину Митнику, что это немного не так работает :)

Объект role

Похож на объект person, но описывает уже контактную информацию какой-то группы, которая отвечает за определенную роль в организации. Такой группой может быть NOC. Объект role это своего рода контейнер для объектов person. Например, в организации работают 3 сетевых инженера, вы создаете группу NOC и в атрибутах tech-c: указываете ссылки на соответствующие объекты person.


Но также стоит отметить, что атрибуты admin-c: и tech-c: являются для role опциональными, поэтому данный объект может быть самодостаточным, т. е. не ссылаться на объекты person.

Еще одной важной особенностью объекта role является наличие атрибута abuse-mailbox:. В нем указываются контакты, по котором можно обращаться по вопросам злоупотребления вашими ресурсами. Например, если с принадлежащих вам IP-адресов рассылается спам, то вам скорее всего напишут именно по адресу электронной почты, указанному в данном атрибуте.

С практической точки зрения лучше использовать именно объект role вместо person, особенно, если у вас много сотрудников работают с данными в БД RIPE. Почему? Дело в том, что если вы пытаетесь удалить какой-то объект, но при этом есть объекты, которые на него все еще ссылаются, то вам придется убрать все ссылки на удаляемый объект. А теперь представьте, что у вас 1000 объектов inetnum, ссылающихся на объект person, принадлежащий вашему коллеге, который собрался увольняться и больше не отвечает за данные ресурсы. Вам придется во всех 1000 объектах удалить ссылки на него. Кроме того, например, объект organization может ссылаться только на объект role в своем атрибуте abuse-c:.

Объект organization

Во-первых, этот объект, как и объекты person и role, содержит контактную информацию, но уже об организации, которая владеет интернет-ресурсами, например: юридический адрес, телефон и т.д.

Во-вторых, это своего рода контейнер, который связывает все ресурсы организации. Такие объекты, как inet(6)num и aut-num, обязаны иметь атрибут org:, который указывает на то, какой организации выделены данные ресурсы.

Группа интернет-ресурсов

Объект aut-num

Данный объект создается в базе после того, как RIPE выделит какой-то организации определенный номер AS. Он показывает, кому принадлежит AS, и контактную информацию, по которой вы можете взаимодействовать с теми, кто за данную AS отвечает.

В этом объекте вы можете публиковать свою маршрутную политику.

Для этого используются атрибуты import: и export:, в которых вы указываете, от кого и какие маршруты вы принимаете и кому и какие маршруты анонсируете. Также операторы обычно описывают политику BGP community именно в этом объекте. Для наглядного примера попробуйте поискать в БД RIPE номера AS крупных операторов, например, as8359.

Чтобы лучше понять, как описывается маршрутная политика, рассмотрим следующий пример:


Допустим, что вы являетесь небольшим провайдером, у вас есть 2 аплинка и 3 клиента.

Аплинкам вы анонсируете свои сети и сети ваших клиентов, от аплинков принимаете full view.

Клиентам вы анонсируете full view, а принимаете только префиксы, которые им принадлежат.

Описание маршрутной политики при этом может выглядеть так:


Стоит отметить, что политика может описывать не только то, какие префиксы вы анонсируете или принимаете, но и более сложные сценарии. Например, вы указываете, что на какой-то префикс вы вешаете local preference 200. С помощью набора инструментов IRRToolSet вы можете автоматически создавать конфигурацию маршрутизаторов на основе информации, описанной в объекте aut-num. Подробнее тут:

https://github.com/irrtoolset/irrtoolset

Объекты inetnum и inet6num

Являются одними из самых важных объектов в БД RIPE. Данные объекты содержат информацию о том, кому и как были распределены блоки IP-адресов. Когда RIPE выделяет вам какой-то блок iP-адресов, то в RIPE NCC создается объект inetnum, указывающий, что этот блок выделен именно вам.

Когда вы далее выделяете из данного блока какой-то кусок под ваши нужды, например, из выделенной вам подсети /22 одну подсеть /24 вы используете под NAT, то вы также создаете объект inetnum и даете описание в атрибуте netname: что-то вроде NAT for users.

Важным атрибутом этих объектов является атрибут status:. Основные статусы:

ALLOCATED-PA RIPE NCC выделила блок IPv4 для какой-то организации.

ALLOCATED-BY-RIR RIPE NCC выделила блок IPv6 для какой-то организации.

ASSIGNED-PA организация выделила блок IPv4 для каких-то нужд.

ASSIDNED организация выделила блок IPv6 для каких-то нужд.

Группа политика маршрутизации

Объект route(6)

Это также одни из самых важных объектов в БД RIPE, они связывают AS и зарождающиеся в ней префиксы.

Если вы анонсируете какой-то префикс в Интернет, то вам необходимо создать объект route для этого префикса.

Почему важно это делать? Многие провайдеры автоматизируют процесс генерации фильтров BGP, которые вешают на анонсы от своих пиров. Реализуется это, например, с помощью утилиты bgpq3, которая обращается в RIPE и автоматически на основании объектов route генерирует соответствующий кусок конфига для создания фильтров. Все те префиксы, которые не описаны в объектах route, не попадут в конфигурацию, поэтому может возникнуть ситуация, когда из-за этого ваши сети не будут доступны извне. Вам придется обращаться в поддержку вашего аплинка, чтобы он разрешил на своем оборудовании принятие от вас данного префикса или же создать объект route для нового префикса и дождаться следующего запуска скрипта на стороне вашего провайдера.

Объект as-set

Это очень полезный объект, он помогает упростить процесс обновления маршрутных политик, которые описываются в объекте aut-num. Объект as-set позволяет вам группировать различные AS в один объект. Вернемся к примеру:



Для аплинков у нас описана политика, что мы анонсируем им префиксы от AS500, AS1, AS2, AS3.

При каждом обновлении данной политики вам придется менять информацию для всех аплинков.

Но вы можете поступить иначе: создать объект as-set и в его атрибутах members: описать номера AS, префиксы которых вы анонсируете, тогда такая политика будет выглядеть так:


Все, что вам нужно будет делать, когда ваша политика меняется, это удалять или добавлять AS из объекта as-set. Кроме того, атрибут members может ссылаться на другие as-set.

As-set часто используется для генерации фильтров. Скажем, клиент может вас попросить настроить фильтры в соответствии с их as-set, тогда вы опять можете воспользоваться утилитой bgpq3, но указывать уже не номер AS в качестве аргумента, а as-set. Например:


Объект domain

Как уже отмечалось ранее, БД RIPE играет ключевую роль в работе reverse DNS lookup.

В противоположность прямому DNS запросу, когда по доменному имени находится соответствующий ему IP-адрес (A запись), обратный запрос, наоборот, ищет доменное имя, которое соответствует IP-адресу (PTR запись). Зачем нужно отображать IP-адреса в доменные имена? В основном это используется как дополнительная защита от спама в электронной почте, также это помогает при устранении неполадок с помощью traceroute, т. к. если для IP-адреса существует PTR запись, то вместо IP в выводе traceroute вы будете видеть более информативные доменные имена.

Объект domain указывает DNS серверам RIPE на то, какой сервер отвечает за ту или иную обратную зону. Визуально это можно представить так:


Когда вы получаете какой-то блок IPv4 или IPv6 адресов от RIPE, то вы можете создавать объекты domain. Например, вы получили блок IPv4 адресов 192.168.1.0/22. Тогда для данного блока вы можете создать объекты domain, которые будут указывать на ваши DNS сервера, которые являются авторитативными для данных обратных зон. Важно отметить, что объект domain может быть создан только для /16 и /24 ipv4 подсетей, поэтому, если у вас есть блок /22, вам придется создать 4 объекта domain для 4х /24 подсетей и, соответственно, 4 обратные зоны на вашем DNS сервере.

Безопасность объектов

Объект maintainer

Теперь, когда мы разобрались с основными объектами, поговорим про безопасность. БД RIPE это публичная база данных, поэтому очень важно запретить делать что-либо с вашими объектами всем неавторизованным пользователям. Краеугольным камнем в безопасности БД RIPE является объект maintainer. Это своего рода замок, который вы вешаете на каждый объект, и открыть его может только тот, кто имеет от него ключи. Существует 3 типа таких ключей:

1. Single Sign On (SSO). Самый простой способ, вам просто нужно добавить в объекте maintainer атрибут auth: с указанием почты сотрудника, с помощью которой он авторизуется на сайте RIPE.
2. MD5 enrypted password.
3. PGP key.

Каждый объект в БД RIPE имеет атрибут mnt-by:, который ссылается на объект maintainer. Соответственно, если у вас есть доступ к данному maintainer, вы можете работать со всеми объектами, которые им защищены.

Заключение

Данную статью я готовил на основе материала из официального курса от RIPE, который доступен по адресу https://academy.ripe.net. Если вы хотите лучше разобраться в вопросе и попрактиковаться на реальных примерах, то советую его пройти. Курс интерактивный, интересный и бесплатный.

Полезные запросы whois:

whois -t object_type посмотреть шаблон объекта.

whois -T route -i origin ASxxxxx узнать все маршруты, которые происходят из автономной системы.

whois -i mnt-by maintainer_name узнать все объекты, которые защищены объектом maintainer_name.

whois -M subnet узнать, на какие более мелкие подсети поделена подсеть subnet.

whois -L subnet узнать, из какой более крупной подсети образована подсеть subnet.

Полезные ссылки:

1. https://www.ripe.net/manage-ips-and-asns/db/support/documentation/ripe-database-documentation
2. https://www.ripe.net/manage-ips-and-asns/db/support/the-ripe-database-business-rules
3. http://www.irr.net/docs/list.html

Вынужденный переход на удаленный режим функционирования стал для многих компаний стимулом попробовать новые форматы работы. Пик спроса в ИТ пришелся на виртуальное рабочее пространство. Понадобилось оно и нашим клиентам. По традиции мы решили сначала протестировать такое решение на себе, прежде чем предлагать его клиентам. Попробовав несколько опций инфраструктуры для удаленки, мы остановились на варианте с рабочим пространством в облаке AWS Amazon WorkSpaces, о котором и рассказываем.

Анатомия современной удаленки

Работа удаленно сегодня может ничем не отличаться по эффективности от работы в офисе, но при одном базовом условии. Рабочее пространство, среда, в которой оперирует сотрудник, должна обладать всеми привычными инструментами, используемыми сотрудниками для решения повседневных задач.

Сегодня это в подавляющем большинстве случаев ИТ-сервисы, приложения, корпоративные системы и базы данных, доступ к которым обеспечивается удаленно по сети Интернет, FTP и другим протоколам. По большому счету весь переход на удаленный режим упирается в способность компании предоставить сотруднику доступ к его привычному рабочему столу в любой точке мира.

При этом, помимо грамотно составленного набора ИТ-инструментов и онлайн-решений, чрезвычайно важны скорость и качество связи, а также защищенность всех операций.

Все существующие сегодня решения по организации удаленной работы делятся на три базовых типа по своей функциональности:

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

Очевидный, но заслуживающий упоминания момент: при создании собственной конфигурации ИТ-решения для удаленки следует тщательно подходить к выбору дата-центров для размещения инфраструктуры. Не останавливайтесь на сравнении ЦОДов по ценам, проверьте их позиции в рейтингах, почитайте отзывы клиентов, поищите публикации о них в СМИ.

Что такое Amazon WorkSpaces

С учетом всех факторов, а также опыта тестирования различных инструментов из всех трех категорий, мы остановили свой выбор при развертывании ИТ-среды для удаленной офисной работы на решении Amazon WorkSpaces.

Amazon WorkSpaces это удаленный рабочий стол в облакеAmazon, реализуемый по модели Desktop-as-a-Service DaaS.

Сервис предоставляет доступ по требованию к рабочим столам в облаке и избавляет от необходимости покупать резервные компьютеры. Объемы вычислительных ресурсов, оперативной памяти и дискового пространства таких рабочих столов настраиваются в зависимости от задач компании и потребностей конкретных пользователей.

Amazon WorkSpaces можно использовать для развертывания рабочих столов на базе Windows или Linux. Сервис позволяет быстро масштабировать ресурсы и создавать буквально тысячи рабочих столов для сотрудников по всему миру.

Биллинг осуществляется за фактически использованные ресурсы, что позволяет оптимизировать расходы по сравнению с традиционными рабочими столами и локальными решениями с использованием инфраструктуры виртуальных рабочих столов(VDI). Конечно, для эффективного управления расходами важно уже на старте работы понимать, какие параметры виртуальных машин необходимы для ваших задач, чтобы не переплачивать за избыточные ресурсы.

Владеть и управлять аппаратным обеспечением, обновлять версии ОС и применять исправления, а также администрировать инфраструктуру виртуальных рабочих столов(VDI) не нужно.

Как устроен сервис: нюансы и тонкости

Для управления информацией о пользователях, подключающихся к удаленным рабочим столам, WorkSpaces использует инструмент AWS Directory Service, который является службой AWS Managed Microsoft AD.

То есть, Amazon WorkSpaces не может работать без сервиса AWS Directory Service, и, следовательно, требуется оплата их обоих. Однако стоит отметить, что и Amazon WorkSpaces, и AWS Directory Service имеют бесплатные пакеты на срок до 1500 часов. Соответственно, есть возможность протестировать решение.

Кроме стандартных рабочих станций сервис Amazon WorkSpaces доступен сvGPU.

Этот пакет предлагает высокопроизводительный виртуальный рабочий стол. Он отлично подходит для разработчиков 3D-приложений и моделей, инженеров, использующих инструменты CAD, CAM или CAE.

Данный пакет доступен во всех регионах, где в настоящее время предлагается WorkSpaces, и может использоваться с любым устройством. Такое решение может стать альтернативой мощным офисным рабочим станциям в дизайн-студиях, которые в период изоляции оказалось невозможно доставить домой к сотрудникам, из-за чего компаниям пришлось либо организовывать закупку дорогостоящих ноутбуков, либо предлагать сотрудникам работу на личных устройствах.

Также, рабочие столы Amazon WorkSpaces с графическими процессорами можно использовать для анализа и визуализации данных. Так как мощности графического пакета находятся рядом с основными сервисами, такими как EC2, RDS, Amazon Redshift, S3 и Kinesis, можно проанализировать данные на сервере и затем визуально оформить результаты в смежном рабочем пространстве.

Эту комбинацию сервисов AWS можно использовать для создания приложений, разработка которых не была бы экономически эффективна при работе на обычных виртуальных машинах без использования графического процессора.

Как проходило тестирование

Мы протестировали сервис, проверив доступность удаленного рабочего стола из Интернета и с тестовой виртуальной машины в нашем облаке в Санкт-Петербурге.

1. Установили связность между нашей инфраструктурой в ЦОДе и нашимVPC(virtual private cloud) в AWS. Здесь все стандартно настройка BGP,DCC,Virtual Gateway.


2. Определились с AD (Active Directory).

Согласно документации Amazon, можно использовать AD как управляемый Amazon, так и управляемый локально.

3. Для теста мы выбрали схему с AD, управляемым Amazon.

При такой схеме нужно иметь в виду, что наVPCдолжно быть, как минимум, две подсети из разных зон доступности. Это требование AWS, оно исходит из необходимости физически изолировать серверыAD друг от друга. Необходимо не меньше двух серверов.

Например, в регионе eu-central-1 (Frankfurt) есть три зоны доступности (Availability Zone) eu-central-1a, eu-central-1b, eu-central-1c.

4. Для теста делаем один префикс в eu-central-1a, один префикс в eu-central-1b.

При создании подсети указываем AZ:


5. Две созданных нами подсети:


6. СоздаемActive DirectoryиWorkSpace.


7. После настройки на указанную почту приходит письмо, в котором есть ссылка для смены пароля на рабочем столе и для скачивания Amazon WorkSpaces для разных платформ Windows,Linux,MacOSи т. д.

8. Рабочий стол готов.

Прямое подключение к AWS

Для большинства компаний, имеющих собственные AD, будет интересна схема подключения с собственным AD. Для этого дополнительно необходимо настроить прямое выделенное соединение с AWS, через которое клиент может связать свойADи ресурсы компании, расположенные локально, с облаком Amazon.

Схематично это выглядит так:


Нужно учитывать, что для стабильной работы сервиса задержка между хостом, с которого происходит подключение к рабочему столу, и локацией AWS, где расположен WorkSpaces, не должна превышать 100мс согласно рекомендации Amazon.

В нашем случае мы предлагаем клиентам соединение через Франкфурт RTT (round-trip time) от Linxdatacenter в Москве и в Санкт-Петербурге до FR5 (точки присутствия на базе ЦОД Equinix во Франкфурте) составляет менее 40мс, что полностью удовлетворяет рекомендациям AWS.

Установка Amazon WorkSpaces на рабочую станцию

1. Устанавливаем приложение на рабочую станцию, с которой планируем подключаться.

2. Вводим Registration Code, который является идентификатором рабочего стола, и логин/пароль, указанные при созданииWorkSpace.

3. Рабочий стол доступен на ноутбуке сотрудника.


Скриншот с окном приложения Amazon WorkSpaces, подключенного к удаленному рабочему столу.

4. Теперь свяжем его с системами в компании. В нашем случае на примере подключения к ВМ в облаке Linxdatacenter в Санкт-Петербурге.


5. В обратную сторону (ВМ в облаке в Санкт-Петербурге > удаленный рабочий стол) связность также работает.


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


Параметры минимального пакета с vGPU:

• Display NVIDIA GPU with 1,536 CUDA cores and 4 GiB of graphics memory.
• Processing 8 vCPUs.
• Memory 15 GiB.
• System volume 100 GB.
• User volume 100 GB.

Развернули: что дальше?

Рабочие столы на Amazon WorkSpaces дают возможность мобильным и работающих удаленно сотрудникам использовать любые нужные для работы приложения через облачный рабочий стол, доступный из любой точки с подключением к сети Интернет.

Работает модель использование собственного устройства(BYOD): сервис поддерживает все стационарные ПК, ноутбуки Mac, iPad, Kindle Fire, планшеты на базе Android, Chromebook, а также браузеры Firefox и Chrome.

Если в компании возникают задачи тестирования софтверных новинок собственной разработки, рабочие столы Amazon WorkSpaces также решают эту задачу без повышения стоимости и необходимости хранить резервное оборудование. Самое главное: исходный код не будет храниться на устройствах разработчиков, а это дополнительная защита.

Еще один актуальный сценарий применения Amazon WorkSpaces оперативное слияние нескольких ИТ-отделов для совместной работы по проекту, когда требуется оперативно синхронизировать работу большого числа специалистов.

Это все на сегодня задавайте вопросы в комментариях.

P.S. Рекомендую посмотреть вот это видео поAmazon WorkSpaces.