DevOps: кейс по миграции среды разработки в облако

Миграция среды разработки из in house во внешнее облако – процедура нестандартная, выполняется нечасто. Очень важно корректно перенести инфраструктуру и всю информацию из БД, особенно на действующем сайте. Предлагаем вашему вниманию кейс-отчет о том, как мы решали эту задачу для IT-стартапа, с какими трудностями пришлось иметь дело и сколько денег мы сэкономили заказчику.

Стартап на аутсорсе: с чем пришел заказчик

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

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

Для разработки заказчик уже взял инхаус-команду, подобрал аналитика и дизайнера. Продакт-менеджерами выступали сами организаторы, а вот DevOps и HelpDesk у них не было. Среда и инструменты находились на ресурсах аутсорсера. Существовали проблемы с лицензированием, железом, защитой персональных данных (ПД) и масса других.

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

Команда для стартапа и наша роль в проекте

Для создания серьезного IT-продукта на этапе стартапа требуется команда, состоящая в идеале из 15 специалистов, у каждого из которых – свои задачи и зона ответственности.

Примерная структура IT-команды:

Специалистов берут в штат либо привлекают на условиях аутсорсинга (реже – аутстаффинга). Полноценная команда на рынке стоит 2–5 млн руб. в месяц.

Разработка на аутсорсе интересна, если клиент располагает как минимум 1 млн в месяц. У большинства стартаперов таких денег нет, с целью экономии команды строятся из 3–5 человек и включают только основных IT-специалистов, без которых проект не запустить.

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

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

Задачи

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

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

1. Вынести из инхауса на внешнее хранилище все наработки команды разработчиков – программный код, системные библиотеки, базы данных и т. д., а также наладить бесперебойную работу.
2. Организовать возможность резервного копирования.
3. Обеспечить удобство пользования, выбрав и подготовив более подходящую по функционалу платформу для разработки, тестирования, отладки и выкладки релизов.
4. Защитить софт, использующий персональные данные, в соответствии с требованиями ФСТЭК.

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

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

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

Как мы выполняли перенос среды разработки в облако

Заказчик не был готов сразу потратить несколько сотен тысяч рублей на физические серверы и их настройку, поэтому выбор пал на аренду ресурсов у дата-центра Selectel. Это один из самых популярных провайдеров, предлагающих гибко конфигурируемые облачные хранилища. Стоимость аренды серверов заказчика устроила, и мы начали подготовку к миграции БД.

• Прежде всего подключили DevOps-инженера для лучшей коммуникации нашей команды с командой разработчиков.
• Провели совместный конф-колл с участием всех команд, с заказчиком и ответственными за команду разработки.
• Отдельно провели конф-колл с представителем “Б-152” для понимания требований законодательства к уровню защиты персональных данных по УЗ-2 и УЗ-3 для веб-сервиса.

Изначально запустились на виртуализации Open Stack. Но поскольку ориентировались на дешевизну, функциональность и масштабирование, пришли к мнению, что единственным подходящим решением является Kubernetes. Если функции OpenStack ориентированы на управление общедоступными и частными облачными установками, то Kubernetes управляет приложениями в контейнерах, чтобы большие приложения могли работать беспрепятственно.

Kubernetes — портативная платформа с открытым исходным кодом и широким функционалом, которая позволяет использовать Autoscaling (автоматически развертывать виртуальные машины), благодаря чему обеспечивается масштабируемость. Правда, использовать пришлось self-hosted-версию, а не услугу от Selectel, поскольку провайдер не закрывал данное решение по ФЗ-152.

Учитывая скромный бюджет проекта, необходимо было подобрать такую операционную систему, которая была бы максимально дешевой, при этом удовлетворяла всем требованиям по уровню безопасности. Остановились на операционной системе Red Hat Enterprise Linux, поскольку этот системный софт имеет сертификацию ФСТЭК и бесплатную подписку для разработчиков, что стало большим плюсом для заказчика.

Таким образом, используя кластер Kubernetes, мы смогли разбить серверы по направлениям и оптимизировать их ресурсы.

Затем нужно было осуществить перенос баз данных SQL. Мы развернули MS SQL Server, разместили необходимые БД. Так как СУБД не требует оплаты лицензии, именно бесплатность стала главным фактором, повлиявшим на выбор.

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

Чуть подробнее о том, что еще мы сделали в рамках переноса среды разработки в облако:

• организовали виртуальную инфраструктуру (VI);
• настроили виртуальные машины;
• развернули Kubernetes;
• установили MS SQL;
• настроили резервное копирование средствами SQL;
• настроили резервное копирование средствами Selectel;
• подключили DNS-имя;
• установили SSL-сертификат;
• произвели подключение GitLab (локальный и облачный репозиторий);
• настроили доступы для команды разработчиков;
• для защиты серверов и автоматизированных рабочих мест установили и выполнили настройку Secret Net и Kaspersky Endpoint Security, которые были выбраны в качестве СЗИ и СКЗИ соответственно.

Безопасность

Поскольку проект посвящен детскому образованию и планировалась интеграция с веб-сервисами, требующими обработки персональных данных, очень важно было позаботиться о безопасности ПД и подготовить меры, обеспечивающие защиту по нормам ФСТЭК. Изначально заказчик хотел сделать более слабый УЗ-3, однако этот уровень защищенности не предотвращает все возможные типы угроз и имеет меньшую защиту от уязвимостей, поэтому остановились на УЗ-2.

Когда уровень защищенности ПД был установлен, оставалось предпринять технические и организационные мероприятия в соответствии с приказом ФСТЭК России. Все требования мы выполнили:

• разместили инфраструктуру на выделенном сервере;
• создали защищенное подключение;
• закупили рабочие места;
• установили специальное программное обеспечение и средства криптографической защиты информации для рабочих мест, с которых производится настройка;
• поставили и настроили антивирус Kaspersky Endpoint Security.

Работы проводились с защищенных рабочих мест.

Чтобы максимально обезопасить образовательную систему от несанкционированного доступа и исключить факторы риска при работе с ПД, воспользовались сведениями об угрозах информационной безопасности и уязвимостях, хранящимися в открытой базе данных ФСТЭК России.

Электронная БД ФСТЭК содержит регулярно обновляемую информацию с описанием условий, которые могут стать причиной несанкционированного доступа и неправомерных действий с конфиденциальной информацией. Знакомиться с БД ФСТЭК рекомендуется всем разработчикам ПО, операторам ПД, компаниям, занимающимся разработкой средств защиты.

Таблица “Типы угроз и уровни защищенности ПДн”:

При использовании сертифицированных ОС, СЗИ, средств защиты от несанкционированного доступа к прикладному ПО в большинстве случаев можно ориентироваться на УЗ-3.

Сложности

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

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

В ходе работ появилась еще одна серьезная проблема: при переносе инфраструктуры один из наших специалистов отмонтировал диск от виртуальной машины, но получилось так, что диск оказался полностью затерт. Хорошо, что мы своевременно настроили резервное копирование средствами СУБД MS SQL и воспользовались услугой Selectel для создания дополнительной копии всех дисков – это помогло восстановить информацию. Если бы бэкапов не было, БД сайта заказчика была бы целиком потеряна.

Как мы сделали хостинг проекта почти бесплатным

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

Например: если стандартная подписка на Red Hat Enterprise обошлась бы в 102 000 рублей на 4 VM (на момент реализации проекта), а обычный вариант SQL – в ~150 000 руб., то благодаря предложенному нами конфигу все это заказчик получил, не заплатив ни копейки. Кроме того, мы избавили его от целого ряда плановых и разовых затрат, абонентских платежей за резервное копирование и многих других расходов. Оплачивал он только арендованные ресурсы.

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

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

1. Первым шагом идем на УЗ-3, где нет никаких расходов, за исключением затрат на аренду ресурсов.
2. Пишем письмо в ФСТЭК, в котором указываем, что стремимся к УЗ-2 и обязуемся перейти на него через год. Получаем аккредитованные рабочие места с условием, что в течение года выполним свои обязательства.

Так мы обеспечили соблюдение закона, требований заказчика на этом этапе, создали задел для роста проекта и при этом сэкономили колоссальные средства.

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

Общая стоимость проекта, с учетом работы двух команд, стоимости аренды серверов, всех лицензий и других затрат, составила менее 1 млн руб. в месяц (обычно в IT-стартапы инвестируется в несколько раз больше денег).

Что дала заказчику миграция среды разработки в облачное хранилище

Благодаря выполненной нами работе заказчик получил сразу несколько профитов.

1. Удобное для бизнеса DevOps-решение. Все наработанные коды, базы данных и другие элементы структуры хранятся не у подрядчика, а в доступной для команды, ведущей проект, виртуальной среде. Вместе с тем учитывается критически важный аспект – при сохранении взаимодействия между разработчиком и операторами заказчику становится проще контролировать все этапы: от сборки до выпуска нового релиза и администрирования.
2. Легкая масштабируемость. Мы придумали способ реализации, который позволяет в будущем без проблем масштабировать систему.
3. Возможность интеграций. Уровень защищенности второго класса открывает заказчику путь к дальнейшим интеграциям. Аттестация по УЗ-2 необходима, чтобы сделать возможным подключение внешних сервисов. А чтобы ее получить, нужно специализированное облако, особые настройки, выполнение целого ряда других условий. Сейчас площадка полностью соответствует требованиям ФСТЭК России к технической защите и информационной безопасности подобных онлайн-проектов.

Система получилась условно бесплатной – заказчик платил только за арендованные ресурсы, покупать лицензии по факту не пришлось. Если бы потребовалось лицензирование, затраты были бы значительно выше.

Регламент взаимодействия команд

Это был еще один бонус, который получил заказчик в результате сотрудничества с “Интегрусом”.

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

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

• перечислили факторы, способные повлиять на сам продукт;
• распределили зоны ответственности;
• описали принцип коммуникации – где, как, по каким вопросам мы общаемся;
• определили сроки – за сколько времени необходимо предупреждать друг друга о запланированных мероприятиях и т. д.

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

Команда и временные затраты

С нашей стороны над кейсом работали:

• технический директор;
• DevOps-инженер;
• менеджер проектов.

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

В ближайших планах заказчика — доработка проекта, монетизация платформы, масштабирование и переход в “Яндекс.Облако”. Но это уже другая история…