У многих компаний, которые создают облачные SaaS-решения, рано или поздно может возникнуть запрос от пользователей: «Можно ли поставить ваш продукт у нас на собственной инфраструктуре?», то есть появляется запрос на on-prem версию. Но не каждый SaaS-продукт сразу готов к такому сценарию: чтобы он работал у клиента, его нужно корректно внедрить в инфраструктуру заказчика.
С таким вопросом столкнулась и компания Skillaz, которая предоставляет HR-платформу для автоматизации управления персоналом. Мы подключились к Skillaz, чтобы помочь выстроить этот процесс — от инфраструктурной части до организационной. Ниже мы расскажем, как формируется внедрение на железе клиента, а не в привычных и удобных для подобных развертываний облаках. А также о том, как мы вместе превращали эти внедрения в воспроизводимый и управляемый сценарий.
Про набитые шишки и что из этого вышло
Первые же внедрения стали для всех хорошими полевыми испытаниями. Мы быстро поняли, что те подходы, которые хорошо работают для SaaS, в on-prem мире не срабатывают. По ходу работы стало понятно: мы недооценили сроки и трудозатраты. Иногда информации на старте было меньше, чем хотелось бы. Например, где будет располагаться инфраструктура и какие у нее есть особенности. Из-за этого приходилось уточнять детали в процессе и в некоторых случаях переделывать уже сделанное. Еще одна проблема — отсутствие стандартизации. В первое время каждый проект делался «с нуля», без шаблонов и четкой схемы и потому внедрение превращалось в уникальный квест.
Дополнительные трудности возникали и в коммуникациях: требовалось синхронизировать три стороны, а задачи иногда упирались в особенности инфраструктуры или внутренние регламенты клиентов. На старте также зачастую не хватало документации: теперь же у заказчиков есть подробные инструкции для самостоятельного сопровождения продукта после внедрения.
Из-за всего этого первые проекты давались тяжело. Однако именно эти ошибки стали толчком к выстраиванию воспроизводимого процесса. Потребность в предсказуемости и повторяемости была и у нас, и у Skillaz.
Одним из первых решений по стандартизации стала анкета для on-prem проектов. Она представляет собой некий «портрет» конкретного проекта и решает ключевую задачу — собрать всю критически важную информацию еще до начала работ, чтобы проект не буксовал в процессе.
Анкета состоит из нескольких блоков. В первую очередь собирается общая информация: кто конечный заказчик, какие контуры (dev, prod и т.п.) нужны, будут ли предоставлены доступы, какие есть к ним требования и какая процедура их согласования. Также уточняется есть ли какие-то специфические технические требования, изолированность контуров, интеграции с корпоративными сервисами, требования к ПО и версиям. Важным пунктом являются и требования по информационной безопасности и ограничения, которые они накладывают. Тут же задаются такие организационные вопросы, как: требуется ли подготовка документации и руководства администратора и есть ли необходимый штат для дальнейшего сопровождения on-prem решения или нужны будет дополнительные консультации?
Следующий блок анкеты это «сайзинг» проекта — расчет необходимых ресурсов для работы системы. Сюда входит такая информация как: назначение и роль ВМ, количество и тип vCPU, дисковое пространство. Далее в анкете указывается базовый план работ, на основе которого собирается план работ под конкретный проект. В нем прописываются все названия работ, их оценка в часах и продолжительность в днях, а также результаты этих работ по пунктам. И последним блоком в анкете указываются организационные и юридические ограничения ITSumma. Это позволяет сразу разграничить ответственность и обязательства, которые мы на себя берем в рамках данных работ.
Примеры реальных вопросов из анкеты:
Поставка предполагает описание CI/CD в gitlab, IaC в Ansible+Docker и/или Helm/Helmfile? Есть ли дополнительные требования к IaC?
Есть ли доступ из контура в интернет? Как организовано проксирование docker registry, при наличии изолированного контура?
Будут ли предоставлены доступы к контуру заказчика для развертывания инфраструктуры? Будет ли доступ по SSH/VPN?
Следом за пресейл-анкетой появился шаблон технического задания, который формировался на основе данных из анкеты. В нем фиксировалось из каких компонентов будет состоять текущее внедрение, зоны ответственности (где заканчивается продукт Skillaz и начинается инфраструктура клиента), а также критерии готовности и приемки. Параллельно развивалась библиотека типовых инструкций. Благодаря этому команды могли быстрее выполнять рутинные операции, в том числе, выросло и качество релизов у Skillaz.
С каждой итерацией шаблонов становилось всё больше, и это постепенно превратилось в набор best practices для on-prem проектов Skillaz. Так импровизации постепенно сложились в систему — живую, гибкую и уже вполне предсказуемую. Каждый новый проект добавляет что-то свое: новый шаблон, инструкцию, готовое решение.
Что происходит под капотом
С технической стороны развертывание on-prem решений представляет собой целую цепочку задач — от сетевой настройки до интеграции с корпоративными сервисами заказчика. Обычно работа начинается с подготовки окружений: создание виртуалок или кластеров, настройка сетей, VPN и доступов. Далее устанавливаются инфраструктурные сервисы, без которых продукт не запустится: MongoDB, Redis, PostgreSQL, RabbitMQ, а также системы логирования и мониторинга. Следующий этап — это настройка CI/CD, зеркал репозиториев и систем хранения образов.
И только после всех этих шагов можно приступать непосредственно к развертыванию самого продукта — с его микросервисами, интеграциями и специфическими настройками.
Но это в идеале. На практике каждое внедрение приносит свои нюансы. Мы собрали несколько примеров реализованных проектов, чтобы показать, насколько по-разному может выглядеть техническая часть даже при одном и том же продукте.
Проект 1
В этом проекте продукт Skillaz нужно было развернуть во внутренней инфраструктуре предприятия, использующей OpenShift (OKD). Уже на старте выяснилось, что OKD требует нерутованных контейнеров, а это значит, что при��ычные Docker-образы не подойдут. Поэтому команда ITSumma переработала Helm-чарты и образы, адаптировала сборку под rootless-среду, а заодно интегрировала с корпоративными сервисами — Vault (с LDAP-авторизацией), VictoriaMetrics, Grafana и OpenSearch. По итогу проект стал не просто завершенным внедрением, но также на его основе появились шаблоны чартов и подходы, которые теперь можно тиражировать и под другие проекты.
Проект 2
Здесь развертывание нужно было выполнить в облаке Cloud.ru на базе Huawei, где уже существовал корпоративный Kubernetes-кластер. Казалось бы, готовая площадка должна упростить задачу. Но адресация и маршрутизация были настроены нестандартно: трафик шел не с нод, а из подов. В результате пришлось переписывать сетевые правила, пересоздавать VPC и приводить архитектуру к корректной схеме.
Вот он важный нюанс — проверять базовые сетевые настройки на первом же этапе.
Проект 3
Инфраструктура заказчика — гибридное корпоративное облако с self-service-порталом (в нем можно заказывать ресурсы, создавать ВМ и сети, и т.д.). На старте начали внедрение не в том облаке, позже виртуалки пришлось перекатывать между платформами. В процессе приходилось учитывать внутренние политики безопасности и согласовывать каждое подключение. Коммуникации растягивались: мы закрывали свой объем работ, а через несколько месяцев заказчик возвращался с уточнениями и дополнительными задачами.
Бывали и более нетипичные случаи внедрений. Приведем один из них в качестве лирического отступления под названием: "Как поднять инфраструктуру по зуму?"
Это история о том, что всегда нужно быть готовым к ситуации, когда прямого доступа к инфраструктуре не дают. В одном из проектов нам пришлось вести развертывание по Zoom: на стороне заказчика был свой администратор, и мы шли шаг за шагом, помогая пройти установку, параллельно объясняя базовые действия в Ansible. В итоге инфраструктуру подняли за несколько сессий по видеосвязи: чуть дольше обычного, но с хорошим результатом.
Мораль же здесь такова — если нужно быстро и качественно, то лучший способ это убрать лишние прослойки и дать инженерам прямой доступ. Если доступа всё же нет, то нужно заложить время на такое вот «пилотирование по зум» и подготовить пошаговые инструкции под уровень исполнителя.
Наши выводы
Этот опыт показал нам простую вещь: превратить SaaS в on-prem решение — это целый проект, а не побочная задача. И подходить к нему нужно сразу именно с такой позиции. Ведь даже когда процесс внедрения стал более предсказуемым, сюрпризы не закончились: каждое внедрение это отдельная инфраструктура, своя команда со стороны заказчика.
Для компаний, которые только задумываются об on-prem решении для своего продукта, мы бы выделили несколько советов:
Считайте on-prem отдельным продуктом и процессом, а не дополнением к основному SaaS приложению. Тут будут другие задачи и метрики.
Разделяйте зоны ответственности. Четко определяйте, что входит в ваш продукт, а что относится к инфраструктуре клиента — кто за что отвечает и платит.
Закладывайте ресурсы на внедрение. Без этого сроки и бюджеты почти гарантированно «поплывут».
Формируйте анкеты, шаблоны и документацию — иначе каждый проект превратится в уникальный кейс. Пресейл-анкета поможет сразу прикрыть слепые зоны и избежать множества сюрпризов уже на старте.
Обсуждайте сразу уровень исполнителя и доступы со стороны заказчика. По возможности лучше убирайте лишние прослойки. Если прямого доступа нет, то сразу закладывайте overhead на внедрение.
Фиксируйте рутину. Все повторяемые операции и решения должны жить в инструкциях и шаблонах, а не только в головах инженеров.
Сохраняйте управляемость. Можно менять процессы, подключать внешних исполнителей, адаптироваться под заказчика — главное, чтобы для всех участников было видно, что всё под контролем и внедрение продвигается.
Оглядываясь назад, можно сказать, что пройденный путь стоил всех усилий и ошибок — мы действительно научились делать on-prem внедрения более предсказуемыми. А для Skillaz это был важный этап: on-prem версия продукта прошла обкатку и теперь живёт по стабильному процессу.
Самое важное в нашем ТГ-канале. Без лишнего спама.
