Open source виртуализация для госорганизации: ТЗ и приемка

Что обычно забывают в ТЗ и из-за чего проваливается приемка

Главная причина срывов приемки в проектах виртуализации на open source для госорганизаций - расплывчатые формулировки. Когда в ТЗ написано «обеспечить отказоустойчивость» или «удобное управление», каждый читает это по-своему. В итоге подрядчик считает работу выполненной, а заказчик не может доказать, что ожидал другое.

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

Чтобы приемка была честной и воспроизводимой, заранее договоритесь, что именно подтверждаете документально. Обычно это три группы:

• Функциональность: полный жизненный цикл ВМ (создать, клонировать, мигрировать, снимки, удалить).
• Отказоустойчивость: какие отказы выдерживаем и за какое время восстанавливаем сервис.
• Управляемость: кто и как администрирует, какие есть отчеты, журналы, уведомления.

Связка простая: ТЗ задает измеримые требования, на их основе пишется ПМИ (что и как проверяем), затем по результатам оформляется протокол испытаний и акт приемки. Если в ТЗ нет чисел и сценариев, ПМИ превращается в «проверили визуально», а акт становится спорным документом.

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

Исходные требования госзаказчика, которые надо зафиксировать

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

Первое, что стоит закрепить, это критичность сервисов и измеримые показатели простоя и потерь данных. Указывайте RTO и RPO по группам систем, а не «в целом по кластеру». Например: для ведомственной почты RTO 1 час, для тестовых стендов RTO 24 часа; для баз данных RPO 15 минут, для файлового архива RPO 24 часа. Тогда в ПМИ можно проверить именно это.

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

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

Чтобы на приемке не спорить, в ТЗ обычно не хватает вот этих пунктов:

• Классы информации и режимы доступа (админские роли, сегментация, журналы).
• Границы проекта: что входит в виртуализацию, а что относится к СХД, сети и приложениям.
• Требования к отчетным материалам: схемы, реестры ВМ, инструкции, протоколы.
• Допущения и зависимости (например, что каналы и питание предоставляет заказчик).
• Критерии успешности: что считается «сдано» по каждому блоку.

Это экономит недели согласований и делает испытания честными.

Состав решения и границы поставки: что писать в ТЗ

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

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

• Слой виртуализации (гипервизор) и поддерживаемые варианты установки.
• Система управления (консоль, API, роли доступа).
• Службы на узлах и вспомогательная инфраструктура (мониторинг, журналы, репозитории обновлений).
• Компоненты сети и хранения, которые настраивает исполнитель (виртуальные сети, драйверы, multipath и т.д.).
• Границы ответственности: что делает исполнитель, а что остается ИТ-службе заказчика.

Дальше задайте минимальные характеристики узлов и совместимость: CPU, RAM, диски под систему и под ВМ, количество портов, требования к 10G/25G, поддерживаемые контроллеры и сетевые карты. Это особенно важно, когда кластер собирают на конкретной серверной базе (например, на стойковых серверах уровня GSE S200 Series): в ТЗ лучше привязать приемку к измеряемым параметрам, а не к формулировке «должно быть быстро».

Отдельным подпунктом опишите кластер: число узлов, домены отказа (стойка, электропитание, коммутатор), схему резервирования, и что считается «кворумом».

Не забудьте про права использования: даже в open source решениях часто есть смешанные компоненты (прошивки, драйверы, ОС управления, СУБД, бэкап). В ТЗ укажите, кто и как получает лицензии, ключи, доступ к репозиториям, и что остается у заказчика после сдачи.

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

Функциональные требования: базовые операции и жизненный цикл ВМ

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

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

Минимальный набор операций, который стоит прогнать на испытаниях:

• Создание ВМ из шаблона с заданными параметрами и проверкой запуска ОС.
• Клонирование ВМ (полное и из шаблона) с контролем уникальности имени/ID и сетевых настроек.
• Миграция ВМ между узлами без простоя или с допустимым простоем (в секундах).
• Удаление ВМ: удалить только ВМ или ВМ вместе с дисками, с подтверждением освобождения ресурсов.
• Снимки: создание, откат, удаление, плюс лимиты (максимум снимков и срок хранения), чтобы снимки не росли бесконечно.

Отдельно пропишите пулы ресурсов и квоты (например, по подразделениям). На приемке это проверяется просто: попыткой превысить квоту по CPU/RAM/диску и фиксацией корректного отказа.

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

Если эксплуатация будет опираться на автоматизацию, закрепите требования к API: какие операции доступны, как проходит аутентификация, ведется ли журналирование вызовов, и как проверяется один типовой сценарий (например, авторазвертывание тестовой ВМ на кластере).

Сеть и хранение: требования, без которых тесты будут бесполезны

Если сеть и хранилище описаны общими словами, приемка превращается в спор: «работает» у каждого будет означать разное. В ТЗ фиксируйте не только схему, но и измеримые критерии.

Сначала разделите потоки трафика. Для кластера обычно нужны отдельные контуры: управление (management), трафик ВМ (VM traffic), хранилище (storage) и резервный (репликация или backup). Укажите, где разделение обязано быть физическим (отдельные порты или адаптеры), а где достаточно логического (VLAN). Отдельно пропишите правила межсетевого взаимодействия на площадке: какие VLAN могут общаться, через какие средства контроля (ACL или межсетевой экран), и какие порты должны быть открыты для гипервизора, хранилища, резервного копирования и мониторинга.

Чтобы испытания были воспроизводимыми, добавьте в ТЗ минимум артефактов:

• Таблица VLAN и назначение сегментов (management/storage/VM/резерв).
• Карта подключений: порт сервера - порт коммутатора - скорость - режим (LACP, trunk/access).
• Требования к MTU, QoS (если нужно) и многоканальности (bonding, multipath).
• Тип хранилища (локальное, SAN, SDS) и что входит в поставку по границе ответственности.
• Целевые показатели: IOPS, задержка, пропускная способность под типовую нагрузку.

В ПМИ отдельно опишите методику теста производительности: профиль нагрузки (например, 70/30 чтение/запись, блок 4K и 64K), длительность прогрева, инструмент, число ВМ и сценарий «как в жизни» (несколько серверов приложений плюс одна ВМ с базой). Результаты фиксируйте в протоколе: измеренная задержка и просадки при отказе одного пути (линк, контроллер, узел).

Отказоустойчивость: как описать HA и как ее реально проверить

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

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

Как описать ожидаемое поведение

Критерии приемки формулируйте в метриках: время обнаружения сбоя, время восстановления сервиса (RTO на уровне ВМ или приложения), факт автоматического перезапуска ВМ, сохранность данных, уведомления (куда и в каком виде). Отдельно опишите плановые работы: миграция ВМ без простоя, допустимые окна обслуживания и что считается прерыванием сервиса (например, допустим краткий сетевой разрыв до N секунд).

Как реально проверять на испытаниях

В ПМИ перечислите тесты и то, что фиксируется в протоколе. Для ведомственного кластера на стойковых серверах (вроде GSE S200) обычно достаточно нескольких жестких проверок:

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

К протоколу приложите метрики (время, статусы), выгрузки событий или логов и скриншоты или вывод команд. Тогда спор не сведется к «кажется, работало».

Резервное копирование и аварийное восстановление: критерии приемки

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

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

В ПМИ обязательно добавьте проверку восстановления в отдельной зоне. Тестовый контур должен быть изолирован, чтобы восстановление не затронуло продуктив и сеть. Критерий успеха - не «ВМ запустилась», а «сервис работает»: загрузка ОС, доступ по сети, целостность данных, корректное время, доступность учетных записей.

Для DR между площадками зафиксируйте минимальный набор сервисов, который должен подняться первым (например: DNS/AD или иной каталог, NTP, система мониторинга, прокси или шлюз, 1-2 ключевых прикладных сервиса). Если второй площадки нет, задайте упрощенный сценарий: восстановление на альтернативном кластере в том же ЦОД.

Критерии приемки удобно формализовать так:

• Успешно восстановлены N ВМ из бэкапа за время не более T (с фиксацией работоспособности сервиса).
• Достигнуты RPO и RTO, указанные в ТЗ, для каждой группы критичности.
• Копии хранятся раздельно от продуктивных данных и защищены шифрованием.
• Восстановление выполнено по инструкции, шаги воспроизводимы.
• Назначен регламент регулярных тестов восстановления (например, ежеквартально) с протоколом результатов.

Безопасность и аудит: что включить в ТЗ и в испытания

Безопасность в виртуализации часто «ломается» не из-за взлома, а из-за размытых прав и отсутствия понятных журналов. В ТЗ зафиксируйте: кто и какие действия может делать, как подтверждается личность пользователя и как потом доказать, что операция действительно была.

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

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

Для доступа задайте требования к аутентификации: интеграция с каталогом, политика паролей, блокировка при переборе, MFA для привилегированных действий. Для управления и API - шифрование (TLS), требования к сертификатам и их обновлению.

На приемке полезно заложить проверки:

• Оператор пытается удалить ВМ или изменить права и получает отказ.
• Роль «аудит» видит события, но не может ничего изменить.
• Вход без MFA (если требуется) не проходит, событие фиксируется.
• Соединение с панелью управления без доверенного сертификата блокируется.
• После изменения параметров ВМ в журнале видно кто, что и когда сделал, и запись нельзя удалить обычной ролью.

Управляемость и эксплуатация: требования, которые экономят время

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

Для мониторинга опишите, что именно собирается и как долго хранится. Минимальный набор:

• Загрузка CPU и RAM хостов и ВМ, включая oversubscription.
• Состояние хранилищ: задержки, IOPS, заполнение, прогноз емкости.
• Сеть: потери, задержки, ошибки портов, загрузка каналов.
• События кластера: миграции, падения сервисов, деградации.
• Тренды и отчеты за период (например, 30-90 дней).

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

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

Приемочные критерии удобно задавать через регламентные операции и время выполнения:

• Создать ВМ по шаблону и запустить - до N минут.
• Сделать снимок и откат - до N минут.
• Добавить диск и расширить ФС - до N минут.
• Мигрировать ВМ без простоя - до N минут.
• Выдать отчет по емкости и инцидентам за месяц - до N минут.

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

Пошагово: как составить программу и методику испытаний (ПМИ)

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

Начните с таблицы соответствия: требование ТЗ - тестовый сценарий - критерий прохождения - артефакты. Дальше оформляйте ПМИ так, чтобы ее можно было выполнить по шагам и повторить на таком же стенде.

Базовая структура ПМИ

Обычно хватает пяти блоков:

• Состав и границы стенда: узлы, сеть, СХД, версии ПО, роли доступа, что входит и что не входит в испытания.
• Исходные данные: шаблоны ВМ, тестовые учетные записи, нагрузочные профили, «эталонные» настройки.
• Шаги испытаний: действия оператора по пунктам, без двусмысленностей.
• Ожидаемый результат: конкретные значения (время переключения, статус кластера, успешность миграции, наличие записи в журнале).
• Фиксация результата: где и как сохраняются доказательства, кто подписывает.

Избегайте формулировок «проверить работоспособность». Лучше: «создать ВМ из шаблона X, запустить, получить IP, выполнить вход, зафиксировать время, сохранить событие Y в журнале».

Чем подтверждать результаты

Заранее согласуйте набор артефактов, приемлемый для комиссии:

• Скриншоты ключевых экранов (статусы, ошибки, версии).
• Выгрузка конфигурации кластера и сетей.
• Логи сервисов и журнал аудита действий.
• Метрики (CPU/RAM/IOPS/латентность) за период теста.
• Протокол команд и действий оператора с временем.

Критерии прохождения фиксируйте жестко: «пройдено/не пройдено», а также что считается дефектом (потеря управления, откат настроек, расхождение версий, отсутствие логов). Допустимые отклонения оформляйте отдельным перечнем замечаний: описание, риск, срок исправления, временная мера, решение комиссии.

Частые ошибки в ТЗ и протоколе приемки

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

Ошибки, которые потом дорого исправляются:

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

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

Короткий чеклист перед согласованием ТЗ и перед приемкой

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

Перед согласованием ТЗ

Проверьте, что в ТЗ есть измеримые требования и понятные границы поставки:

• Состав и границы решения: что входит (хосты, сеть, хранилище, ПО, поддержка), а что точно не входит.
• Функции жизненного цикла ВМ: создание, запуск, останов, миграция, клонирование/шаблоны, снимки, удаление.
• Метрики и пороги: емкость (ВМ, vCPU, RAM, хранилище), целевые показатели производительности, RTO/RPO и допустимое время простоя.
• Безопасность и аудит: роли, минимальные права, журналирование действий администраторов, требования к хранению и выгрузке логов.
• Приемочные документы: ПМИ, формат протокола, перечень артефактов к акту (конфиги, логи, отчеты).

Каждый пункт должен быть «проверяемым»: тест, ожидаемый результат и критерий «зачет/незачет».

Перед подписанием акта приемки

На приемке проверьте не только «запускается», но и «управляется»:

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

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

Пример реалистичной приемки для ведомственного кластера

Исходные условия для проверки можно описать так: кластер из 4 узлов (3 рабочих + 1 для кворума или как резерв), 30 виртуальных машин. Из них 10 критичных (учетные системы, каталог, почта), 15 средних (веб-сервисы, внутренняя отчетность), 5 тестовых. В ТЗ заранее зафиксируйте, что часть ВМ должна переживать сбои без простоя, а часть допускает короткий перерыв.

Сценарии приемки удобнее оформлять как короткие практические испытания, каждое с измеримым критерием успеха:

• Живая миграция ВМ между узлами при рабочей нагрузке: сеть и сессии не рвутся, среднее время миграции укладывается в согласованный лимит.
• Падение одного узла (выключение питания): критичные ВМ автоматически поднимаются на других узлах, простой каждой ВМ не превышает X минут, события фиксируются в журнале и приходят уведомления.
• Восстановление ВМ из резервной копии: восстановление выполняется по инструкции, сервис проходит контрольные проверки, фактическое RTO и RPO не хуже заявленных.
• Ролевой доступ и аудит: администратор, оператор и аудитор имеют разные права, запретные действия блокируются, изменения конфигурации попадают в журнал.

Чтобы спорных моментов было меньше, заранее договоритесь, какие данные записываются в протокол. Минимальный набор:

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

Следующие шаги: пилот, документы и подготовка к эксплуатации

Главный риск в таких проектах - когда пилот и приемка живут отдельно от реальной эксплуатации. После черновика ТЗ и ПМИ сделайте короткий, но честный цикл проверки на пилотном стенде.

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

Дальше помогает простой план:

• Развернуть пилот (даже 2-3 узла) и прогнать ПМИ до закупки основной партии.
• Согласовать минимальные метрики: время развертывания ВМ, RTO/RPO для критичных сервисов, время переключения при отказе узла.
• Утвердить набор отказных тестов: отключение хоста, разрыв сети, деградация хранилища, потеря управления.
• Подготовить комплект документов: эксплуатационный регламент, матрица ролей, план обновлений, шаблоны отчетов для аудита.
• Запланировать обучение: администраторы, дежурная смена, ИБ, и короткий сценарий «что делаем в 02:00».

Если на этапе пилота нужна помощь с подбором серверов и внедрением, это удобно закрывать одной командой: производитель и системный интегратор, который отвечает и за «железо», и за поддержку. В Казахстане такой формат часто реализуют через GSE.kz (gse.kz): у компании есть собственные серверы S200 Series и услуги системной интеграции, включая круглосуточную техническую поддержку.