Включая новую платформу виртуализации в портфель, интегратор берёт на себя её внедрение и сопровождение. Если после запуска проекта не удастся восстановить систему из резервной копии или перестанут подключаться пользователи, заказчик сначала позвонит ему. Поэтому при выборе вендора стоит выяснить, как продукт ведёт себя в инфраструктуре клиента и кто поможет, когда что-то пойдёт не так. Скидка на лицензии этого вопроса не решает.
По опыту технических встреч: полезнее всего обсуждать условия эксплуатации. Они показывают, для каких проектов платформа подходит и сколько работы потребует от партнёра.
Начать с проекта своего заказчика
Первую встречу легко потратить на обзор возможностей и так и не понять, подходит ли продукт интегратору. Полезнее заранее описать типовой проект: сколько серверов у заказчика, какие приложения и хранилища, чем делают резервные копии, кто будет администрировать систему. Тогда демонстрация и вопросы будут привязаны к будущей работе.
На встрече нужны инженеры, которым предстоит внедрять платформу, и архитектор. Заранее назначьте того, кто получит технические выводы и продолжит переговоры. Иначе оценка останется удачной встречей, запись которой никто не успел посмотреть.
Показать отличия и определить клиентов
Вендор обязан вместе с интегратором показать, чем продукт отличается от альтернатив и в каких задачах это полезно заказчику. Отличия нужно подтвердить на конкретных сценариях. Затем стороны должны определить круг потенциально заинтересованных клиентов: интегратор знает их инфраструктуру и планы, вендор — возможности продукта. Результатом станет список подходящих проектов и оснований для разговора с заказчиком.
Одновременно стороны должны обсудить экономику: стоимость решения для заказчика, доход партнёра и его затраты на продажу, пилот, внедрение и сопровождение. Расчёт нужен до затратных испытаний. Скидки и статусы обсуждают с пониманием объёма работ и потенциальных продаж. Техническая оценка проверит пригодность платформы для выбранных проектов.
Разобраться в устройстве продукта
Первый технический вопрос — из каких компонентов состоит платформа и как распределена ответственность за них. Какой гипервизор используется, что взято из открытых проектов, какие части развивает сам вендор? По ответу важно понять, кто сможет найти причину ошибки и выпустить исправление. Само по себе количество собственного кода ещё не говорит о качестве продукта.
Если решение включает виртуальные рабочие места, нужно уточнить их связь с серверной виртуализацией. У них общее управление? Можно ли развернуть VDI поверх другой платформы и с какими ограничениями? Ответы определяют состав проекта и то, кто будет разбирать инцидент на стыке компонентов.
Поддержка протокола хранения не равна проверке конкретного массива. Интегратору нужны список испытанных конфигураций, версии ПО и условия поддержки. Если оборудования заказчика в списке нет, нужно договориться о проверке и о том, кто подключится к диагностике при проблемах. Фраза «должно работать» для проекта слишком неопределённа.
Резервное копирование стоит обсуждать через восстановление. Чем защищаются машины, какие возможности есть у привычной заказчику системы бэкапа, что требуется для согласованной копии работающей базы данных? На пилоте нужно восстановить приложение и проверить его работу. Успешно созданная копия ещё не подтверждает, что после аварии заказчик получит пригодную систему.
Попросить показать сбой
Вопросы об отказоустойчивости полезно начинать с той конфигурации, которую интегратор действительно будет продавать. Если речь о двух или трёх серверах, пусть вендор объяснит поведение именно такого кластера. Нужен ли дополнительный узел для принятия решений, какие ресурсы резервируются, что останется доступным после отказа одного сервера? Схема большого стенда не отвечает на эти вопросы автоматически.
Отдельно стоит разобрать обрыв связи между частями кластера. Как система понимает, кто может продолжать работу? Что не даст двум изолированным частям одновременно управлять одной нагрузкой или писать в одни данные? Одного слова «кворум» здесь недостаточно. Важно увидеть всю последовательность действий и условия, при которых узел будет изолирован от ресурсов. Если для этого нужно оборудование или отдельная сеть управления, их придётся заложить в проект.
Следующая тема — обновления. Какие службы можно менять отдельно, что происходит с работающими ВМ, когда нужен перезапуск узла? Как система действует, если сервер перестал отвечать посреди операции? Интегратору нужны понятные условия отката и восстановления, а также порядок выпуска исправлений безопасности. Эти механизмы потом придётся объяснять заказчику и учитывать при планировании работ.
Часть сценариев стоит показать на тестовом стенде: остановить службу, разорвать связь между узлами, прервать операцию. Перед испытанием нужно согласовать ожидаемый результат и способ вернуть стенд в рабочее состояние. Затем смотреть, что произошло с приложениями, какие сообщения увидел администратор и сколько действий потребовалось от инженера. Так проверяется и автоматика, и удобство восстановления.
Оценить качество ответов
В техническом разговоре настораживает желание подтвердить любую возможность без уточнений. У продукта есть ограничения, и интегратору полезно узнать их до проекта. Чёткий ответ «в этой версии функции нет» позволяет принять решение. «Почти готово» оставляет неопределённость, которую потом придётся объяснять клиенту.
План разработки нужно обсуждать отдельно от доступного функционала. Если без определённой функции проект не состоится, обещание будущего релиза не закрывает требование. Нужно зафиксировать, что именно должно появиться, когда это можно проверить и что произойдёт при переносе срока. Выпущенное исправление и работающая доработка дают больше оснований для доверия, чем подробный план на год вперёд.
Ответ «уточню у архитектора» уместен, особенно если разговор дошёл до механизмов блокировок или тайм-аутов. Важно договориться о встрече и получить проверяемое объяснение. Интегратору нужен ответ, на который можно опереться при проектировании, поэтому уверенная импровизация только мешает.
Цифры тоже требуют уточнений. Если вендор называет число пользователей на сервер или пропускную способность шлюза, нужно спросить о версии, оборудовании и нагрузке. Офисная сессия и рабочее место с видеосвязью предъявляют разные требования. Результат полезен, когда понятно, при каких условиях его получили и можно ли повторить испытание.
По итогам встречи нужны письменные ответы на открытые вопросы, архитектурная схема, документация, перечни проверенных конфигураций и доступ к испытаниям. Для каждого незакрытого вопроса стоит назначить ответственного и срок, чтобы оценка продолжилась, когда участники вернутся к текущим проектам.
Проверить будущую поддержку
До партнёрского соглашения стоит разобрать обычный инцидент. Например, машина не запускается, а по первым признакам причина может быть и в платформе, и в хранилище. Кто принимает обращение, собирает диагностику и привлекает нужных специалистов? Кто остаётся ответственным за движение заявки, пока причина неизвестна? Заказчику трудно принять ситуацию, в которой его по очереди отправляют к нескольким поставщикам.
Интегратору нужно понимать границы собственной работы и помощи вендора. Что его инженеры должны уметь сделать сами, когда подключается разработчик, как передаются журналы, есть ли порядок срочной эскалации? Время реакции на обращение и время восстановления сервиса — разные вещи. Это различие стоит обсудить заранее вместе с режимом работы поддержки и доступными каналами связи.
Важны и эксплуатационные мелочи. Можно ли собрать диагностику через интерфейс, как найти файлы конкретной ВМ, какие действия допускаются вручную? Если инженер изменил настройку на узле, должна быть понятна граница поддерживаемой конфигурации. Документация и средства диагностики влияют на трудозатраты партнёра при каждом обращении, поэтому их стоит оценивать наравне с основными функциями.
Провести пилот с понятным результатом
Пилот без программы легко превращается в бесконечное знакомство с продуктом. Один инженер проверил установку, другой посмотрел интерфейс, третий предложил ещё несколько сценариев. Время потрачено, а общего вывода о готовности к проектам нет.
До начала испытаний нужно согласовать сценарии, ожидаемые результаты и условия завершения. Для каждого важного требования должно быть понятно, как его проверяют и что считают неуспехом. Например, при отказе узла приложение должно восстановиться за согласованное время. Конкретный предел выбирают под проект заказчика.
Удобно пройти два этапа. Сначала на подготовленном стенде вендора разобраться с устройством продукта и основными операциями. Затем развернуть его силами интегратора в своём контуре. На втором этапе становится видно, достаточно ли документации, где нужна помощь и сколько времени занимает установка без постоянных подсказок разработчика.
Программу вендора стоит дополнить своей нагрузкой и окружением. Для VDI это вход пользователей в начале рабочего дня, работа профилей, видеосвязь, USB-токены и смарт-карты. Для серверной виртуализации — приложения, сеть, хранение и резервное копирование типового клиента. Проверять нужно сочетания, которые предстоит поддерживать после продажи.
В конце пилота нужен короткий разбор: что подтверждено, какие ограничения обнаружены, что блокирует проект и можно ли это устранить. Если требуется новый релиз, повторную проверку назначают на его доступную версию. Так техническая оценка получает завершение, а решение о партнёрстве опирается на результаты испытаний.
Платформу стоит включать в портфель, когда вендор и интегратор понимают, кому и за счёт каких отличий её предлагать, сколько заработают на проектах и как обеспечат внедрение и поддержку. Владимир Сиротин, генеральный директор ООО «Лаборатория Виртуализации»
Источник: Владимир Сиротин, генеральный директор ООО «Лаборатория Виртуализации»
Иллюстрация предоставлена пресс-службой компании
