Исправили баг — получили два новых

Как «простые» ИТ-проекты превращаются в бесконечный квест и что с этим делать

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

Кейс первый: СХД, гипервизор и эффект домино

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

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

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

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

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

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

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

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

Кейс второй: «Элементарный» проект с ИБП, сервером и байпасом

Второй кейс — классика жанра для любого интегратора. Задача выглядит просто: поставить в стойку один ИБП, сервер и байпас. Всё оборудование приехало в срок, инженеры тоже — что может пойти не так?

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

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

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

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

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

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

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

Несколько экспертных выводов — из практики и личного опыта

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

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

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

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

Итог

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

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

Виталий Попов

Директор департамента реализации инфраструктурных проектов «Софтлайн Решения» (ГК Softline)