Когда твой тестовый стенд разбросан по этажам, IP-адреса живут своей жизнью, а нужное устройство стабильно «гуляет» между кабинетами — это не инфраструктура, это квест. Три года назад я подключался к железкам по SSH и даже не знал, где они физически находятся. Сегодня всё иначе: у нас универсальная тестовая лаборатория, собранная как из конструктора LEGO — аккуратная, управляемая, с централизованной сетью, удалённым регулированием питания и мониторингом.

Этот текст — про то, как из хаоса родился порядок. Как вместо десятков разрозненных девайсов появилась стойка, где каждый винт, кабель и IP на своём месте. И как одна инженерная идея может превратиться в систему, которая экономит часы, нервы и делает работу с тестами наконец-то предсказуемой. Эта статья написана по мотивам моего доклада для конференции Highload++.

Привет, Хабр! Меня зовут Евгений Деркач, и я инженер по тестированию АО «ИнфоТеКС». Занимаюсь продуктом ViPNet Client Linux, предназначенным для создания и развёртывания защищённых VPN-сетей по технологии ViPNet, работающей не только на Linux, но и на Windows, Android и Aurora. Технологию отличают минимальные технические требования, позволяющие устанавливать ПО на широком перечне устройств - не только на привычных нам десктопах и смартфонах, но также и на IP-камерах, контроллерах, одноплатных компьютерах, роутерах и других устройствах.

Когда проблема — общая

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

Так происходит потому, что:

• мы привыкаем работать с тем, что имеем;

• не замечаем, что многое можно улучшить;

• и редко задумываемся, что однажды с этим придётся разбираться кому-то другому.

Перейдём от общего к частному.

Когда проблема — наша

Со словом «стенд» чаще всего возникают такие ассоциации: 

• что-то габаритное с большим количеством устройств — лампочки, антенны, микросхемы; 

• что-то виртуальное с огромным списком виртуалок, например, Proxmox VE или другие среды виртуализации.

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

Посмотрим подробнее, с чем приходилось работать изначально:

• множество неторопливых устройств, каждое со своим характером;

• значительные затраты времени на поиск нужного оборудования для обслуживания;

• разветвлённая сеть и распределённая команда — Москва, Санкт-Петербург, Уфа, Томск.

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

Чтобы добавить немного конкретики, приведу типичный рабочий пример.
Исходные данные: устройство «Байкал» с установленной системой «Альт СП».
Задача: установить «Ред ОС».
Время: один час.

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

Поднимаемся на четвёртый этаж — нет. Проверяем восьмой — тоже пусто. Поднимаемся на десятый — снова мимо. В итоге выясняется, что наш «Байкал» всё это время спокойно стоял на первом этаже. После небольшого «квеста по этажам» находим устройство, расчищаем место, подключаем и продолжаем работу.

Первая мысль тогда была простая, как в известном мультсериале: «Помогите Даше найти Байкал». Я, конечно, не Даша, но Байкал найти надо. Устройство всё-таки нашлось — отлично, можно работать дальше. Расчищаем место, аккуратно подключаем периферию, устанавливаем «Ред ОС», проверяем доступность сети и правильность адресации. Затем возвращаем устройство на место, приводим всё в порядок и идём довольные обратно в кабинет.

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

В связи с этим — немного исследований.

Интересные факты

По оценке РБК, крупные компании теряют сотни миллионов долларов ежегодно из-за неэффективных процессов и организационного хаоса.

• $184 млн в год — средние потери крупных организаций от несогласованности действий и неструктурированных рабочих процессов;

• 72% российских компаний признают, что теряют деньги из-за хаоса в операционной деятельности.

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

«Сложно жить в гармонии с хаосом». 

Дэвид Боуи

«То, что мы называем хаосом, — это всего лишь закономерности, которые мы не сумели распознать». 

Чак Паланик

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

Во всём этом я увидел некий аналог конструктора LEGO — множество отдельных, порой сложных, но всё же взаимосвязанных деталей. Работать с таким набором оказалось не только интересно, но и вдохновляюще: захотелось «собрать» из хаоса что-то цельное и логичное.

Стартовая локация

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

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

Со стартовой локацией определились — двигаемся дальше.

Главная деталь

В любой градостроительной игре или симуляторе есть центральный элемент — ядро, вокруг которого строится всё остальное: будь то Капитолий, Кремль или энергостанция. В нашем случае таким «сердцем» стенда стал маршрутизатор — узел, от которого началась системная сборка всей инфраструктуры.

Первым делом мы решили главную проблему — раздробленную сеть. Теперь всё объединено в единое пространство: одна сеть, единая структура, понятные связи. Работать стало значительно проще, удобнее и, что немаловажно, спокойнее. Но это был лишь первый шаг. После настройки сети начались настоящие приключения — этап подключения рядовых устройств.

Первые настройки

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

Некоторые устройства не имели штатных креплений — универсальная стойка в этом плане оказалась и преимуществом, и вызовом одновременно. Пришлось подключить инженерную изобретательность. На помощь пришли аддитивные технологии: с помощью 3D-принтера мы напечатали подложки и крепёжные элементы, подобрали оптимальные размеры, а затем аккуратно зафиксировали всё на стойке с помощью винтов, гаек и хомутов. Получилось опрятно, надёжно и, что важно, воспроизводимо для будущих сборок.

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

Первый «босс»

Первым «боссом» стал классический «ПрибитГвоздямиСтатик» — ситуация, знакомая многим. Это тот случай, когда IP-адрес прописан намертво и никакие настройки не помогают его изменить. Что бы ни делал — адрес остаётся тем же, словно вшит в прошивку.

Тактика здесь оказалась несложной:

1. Подключаем устройство к порту маршрутизатора с отладочной сетью из прежнего адресного пространства.

2. Заходим по старым параметрам, находим и правим конфигурационный файл. Самое трудное — вычислить, какой именно отвечает за сеть.

3. Перезагружаем устройство.

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

Казалось бы, схема простая и знакомая многим. Но, как это обычно бывает, «босс» редко приходит в одиночку — где-то рядом всегда прячется другой.

Ловкий беглец

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

Здесь пришлось проявить смекалку, но общая логика осталась прежней. Мы выделили отдельный рабочий порт на маршрутизаторе и назначили для него небольшой пул адресов из основной сети — точнее, один свободный. Благодаря этому нужное устройство всегда получало один и тот же IP-адрес, что позволило стабилизировать работу и избежать дальнейших изменений MAC-адреса.

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

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

Несгибаемый титан

Это «ПолныйРебутец» со своей харизмой — функционалом и настройками безопасности.

Особенность этого босса была в его уникальном перке: устройство уходило в перезагрузку каждые две минуты. Машина сказала «ребут!» — значит, ребут. Спорить бесполезно, никакие ухищрения не помогали. Настоящий полный ребутец! Причина — строгие настройки безопасности. Единственным выходом стало обращение к Паладину Техподдержки, который знал, как укротить эту упрямую машину.

Тактика:

• применяем «древние свитки» (скрипты) от «Паладина Техподдержки»;

• добавляем пару «бустов на ловкость»;

• несколько команд на исполнение.

И вуаля — несгибаемый титан повержен! Наш «ПолныйРебутец» наконец склонил свои электронные плечи, стал покладистым и согласился сотрудничать. После этой победы тесты пошли бодрее, а команда — увереннее. Тяжёлая череда боссов осталась позади, впереди — мини-квесты и повседневные задачи.

Поддержка с воздуха

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

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

Не у всех в запасе найдётся маленький старенький MikroTik, который когда-то верой и правдой раздавал интернет в офисе. Нам повезло — именно такой оказался под рукой. После быстрой перенастройки он снова в строю: теперь «летающие» устройства без проблем работают в общей сети, а тестирование проходит в едином контуре.

Виртуальные человейники

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

• растущая мода на масштабные, «всё-в-одном» решения;

• обширный список поддерживаемых Linux-дистрибутивов, требующих единой среды;

• необходимость экономии вычислительных и физических ресурсов.

Те, кто работал с Linux, наверняка поймут, о чём речь. Дистрибутивов — десятки, у каждого свои особенности, мелкие «шутки» и непредсказуемые нюансы, особенно у отечественных версий. Всё это нужно учитывать при тестировании.

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

Кроме того, ресурсы используются неэффективно: кто-то тестирует Ред ОС, кто-то Ubuntu, но при этом у каждого в пуле лежат виртуальные машины обеих систем — просто занимают место и ничем не полезны. В итоге ресурсы расходуются, время теряется, а производительность падает.

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

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

Скроллбар в интерфейсе наглядно показывает: виртуальных «этажей» действительно много — можно пролистывать их бесконечно. Всё зависит лишь от мощности сервера и выделенных ресурсов.

Хочется по две копии каждой системы? Пожалуйста. Нужны сотни снапшотов Astra Linux — без ограничений. С поддержкой ЗПС или без неё, с мандатным контролем целостности или в упрощённой конфигурации — платформа легко подстраивается под любые сценарии. Всё решается настройкой и здравым распределением ресурсов.

DLC: управляемое питание 

Сегодня без DLC не обходится ни одна игра — и наш инженерный «конструктор» не стал исключением. В нашем случае DLC — это модуль управляемого питания.

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

Главная особенность этих фильтров — управляемость. Теперь питание можно контролировать удалённо, не вставая из-за рабочего места.

Это открыло новые возможности:

1. Отключать питание нужных устройств дистанционно. Например, при необходимости полностью отключить интернет в определённом сегменте (пусть и вместе с железом — такие издержки допустимы).

2. Проверять критические сценарии тестирования — отказоустойчивость, восстановление работоспособности, реакцию систем на внезапное отключение или сброс питания.

Анонс новых DLC

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

• Реворк DLC с удалённым питанием

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

• DLC с ревизией деталей

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

• Мониторинговое дополнение

Многие наверняка сталкивались с подобной ситуацией: важно понимать, когда и почему у вас что-то перестало работать. Представьте, вы спокойно пишете тест-кейсы или настраиваете сеть, и тут вбегает коллега — «Слушай, всё пропало! Я не могу подключиться к 15-й железке. Ты в курсе, что с ней?» А вы — нет. Подходите, проверяете, а устройство уже вторые сутки не отвечает. Возможно, был скачок напряжения — оно выключилось и не запустилось снова. Такие случаи показывают, насколько важно иметь систему мониторинга. Она позволяет вовремя узнать о сбоях, быстро восстановить работоспособность и дальше уже разбираться с причиной проблемы, вместо того чтобы реагировать постфактум.

• Automation DLS

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

Особенности Automation DLC

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

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

• Ограниченность места на устройствах

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

• Отсутствие функции снапшотов

Если мы что-то сломали — это нормально, мы все люди, ошибки неизбежны. Казалось бы, должны выручать снапшоты: вернул систему в нужное состояние — и всё снова работает. Но, как уже упоминалось, в случае с железом этот вариант не подходит — просто потому, что подобного функционала там нет. Поэтому приходится действовать максимально аккуратно: внимательно разбираться со структурой каталогов, не заходить в «запрещённые» области и не трогать критические файлы, чтобы случайно ничего не повредить. А если всё-таки что-то серьёзно поломали, можно ли просто откатиться до заводских настроек? Хотелось бы — но, увы, нет. Такой возможности здесь тоже не предусмотрено.

• Отсутствие сброса до заводских настроек

Некоторые устройства просто не предусматривают возможность отката к заводским настройкам — и на то есть вполне логичные причины. С точки зрения безопасности это была бы потенциальная уязвимость: представьте, кто-то получил физический доступ к девайсу, сбросил его, перенастроил под себя и получил доступ к защищённой сети. Очевидно, такие сценарии нужно исключать, поэтому производители часто сознательно не добавляют подобный функционал. В итоге сценарий получается довольно прозаичный: «окирпичил» устройство — отправляешь производителю. Руководство, конечно, в восторге от этого не будет, премией не наградит, но и сильных разборок, возможно, не последует. Зато времени потеряете немало. Особенно это критично в период релизного тестирования, когда сроки горят и каждый час на счету. Поэтому лучше не доводить до подобных ситуаций — аккуратность здесь действительно спасает.

В итоге стенд мы собрали, но какой у этого профит? Стоит отметить пару нюансов.

Практическая значимость

• Удобство для команды

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

• Масштабируемость и универсальность

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

• Забота о потомках

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

Пример того, как это выглядит:

Во внутренней wiki ведётся таблица с устройствами: модель, адрес, расположение. Отдельная графа — «Примечания». Например, во второй строке явно указано: «Не распаковывать в корневом каталоге — возможны критические последствия».

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

Также для всех девайсов теперь есть ориентировки:

Теперь нет нужды бегать по этажам и кабинетам в поисках нужного устройства — например, того же «Байкала» с «Альтом». Мы чётко понимаем, где он находится и как выглядит. На самих устройствах наклеены стикеры с адресами, поэтому ориентироваться становится ещё проще. Всё организовано буквально перед глазами: заходишь в кабинет — и видишь две стойки рядом. На поиск нужного оборудования теперь уходит не час, а пара минут — достаточно окинуть взглядом, найти нужное устройство и сразу перейти к работе.

Пасхалка

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

Представьте такую ситуацию. Вы тёмным декабрьским утром приходите к себе в кабинет, открываете дверь и видите вот такую картину.

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

Вместо итогов

Мы привыкаем работать с чем-то вокруг нас и не задумываемся о том, что это потом кому-то достанется, а стоило бы. Поэтому предлагаю вам на следующий рабочий день прийти к себе в кабинет и сделать ревью того, что там находится. Уверен, у каждого найдётся, что можно улучшить и оптимизировать. А если вам нужны идеи, что именно улучшать — приходите на конференцию Highload++ — именно там мы обсуждаем все вызовы и сложности высоконагруженных приложений и как работать с ними эффективно.