«Облачный» пилот без самообмана: как понять, что сервис готов к работе

Облако может отлично выглядеть на тестовой площадке и совершенно иначе – в момент, когда бизнес зависит от него каждый день. Пока виртуальная машина запускается, сервис отвечает, а менеджер быстро выходит на связь, кажется, что пилот пройден. Но главный вопрос остается за рамками такой проверки: что произойдет, когда системе понадобится выдержать нагрузку, восстановить данные или пережить сбой? Аслан Шингаров, заместитель коммерческого директора ActiveCloud, рассказывает, какие сценарии стоит проверить до заключения большого контракта и почему универсального набора тестов для всех компаний не существует.

Почему работающая панель еще ничего не гарантирует

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

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

Такой подход проверяет статику. А проблемы при взаимодействии с поставщиком проявляются в динамике.

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

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

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

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

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

Лучший способ проверить облако – заранее устроить ему проблемы

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

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

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

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

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

Какие проверки действительно нужны бизнесу

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

Обычно оценка сводится к CPU, RAM и количество баллов в синтетическом тесте. Хотя взаимодействие с провайдером – про другое. Можно, например, проверить переключение площадок в случае аварии. Но сначала стоит понять, относится ли такой сценарий к конкретному бизнесу. 

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

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

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

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

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

Четыре часа простоя могут стоить по-разному

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

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

Для аварийного восстановления уже есть конкретные показатели, которые показывают, за какое время система должна восстановиться и какой объем данных допустимо потерять. Это RPO и RTO, Recovery Point Objective и Recovery Time Objective.

На уровне провайдера все зависит от того, какую именно услугу выбирает заказчик. Если речь идет об отдельной услуге Disaster Recovery, то в рамках ее внедрения команда может проверить эти параметры на практике. Но это уже другой объем документов и работы. Пишут Disaster Recovery Plan, назначают ответственных, определяют временные рамки и тип переключения, распределяют ответственность за перенос на другую площадку, прописывают порядок действий и способ подключения пользователей к новой площадке. Это такая мини-версия дальнейшей основы бизнес-комьюнити-плана.

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

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

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

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

Как понять, что пилот действительно удался

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

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

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

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

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

Этого набора достаточно, чтобы получить базовую картину. Все остальное зависит от конкретного бизнеса.

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

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