Бизнес-кейс: когда облачные технологии играют против вас

Ввводные

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

Каждый облачный провайдер подразумевает, что команде нужно разбираться в конкретном сервисе, настройках и тонкостях. Но как правило команды состоят из разработчиков, а DevOps-инженеров у них нет. Им нужно писать код, а не переживать за то, что что-то может просто отвалиться. И такая картина почти у каждого нашего клиента — кто-то приходит во время пожара, кто-то успевает чуть раньше.

Благодаря аудиту инфраструктуры ваша компания поймет текущее положение дел с точки зрения DevOps, а процессы смогут перейти из режима хаоса в контролирумую систему.

Решение

Мы проанализировали рынок и выбрали надёжный провайдер — Hetzner. Это помогло оптимизировать процесс, сократить ценник и понять, как двигаться дальше. Бизнес в этом плане ничего не теряет, ведь отказоустойчивое решение можно развернуть и на арендованном железе. Взяли сервера и повезли. После чего настроили Kubernetes, выстроили процессы и научили разработчиков действовать по нашему шаблону.

У клиента были тестовые контуры и контур продакшена. Для экономии средств, мы поняли, что тестовый контур вполне может располагаться на казахстанском железе — один сервер как раз уже был развернут. И там же мы развернули Gitlab, Jira и Confluence. Там же мы подняли раннеры, чтобы оптимизировать ресурсы. А в Hetzner развернули продакшн. На нескольких серверах создали виртуальные машины, настроили их и и приготовились к переносу.

Перенесли исходный код всех приложений из Azure на казахстанское железо, разобрались в его устройстве — то есть, прошли все стадии от сборки и тестирования до всего остального. После чего поменяли deploy каждого приложения в новый кластер, который был уже расположен в Hetzner. Так и перенесли все плавненько — запланировали ночные работы для всей этой истории и совместно со специалистом компании-клиента задеплоили.

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

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

С тимлидом разработки уточнили время переноса — и уложились с 2 часов ночи до 5 утра. На этом этапе мы всегда учитываем специфику бизнеса и вместе с клиентом выбираем подходящее окно для миграции. Как только нам подтвердили перенос, мы поменяли DNS и по-приветствовали новую хостинг-площадку

Что мы получили в итоге?

Сократили затраты на хостинг втрое. На общий чек особенно повлияло размещение продакшена в Hetzner. Таким образом освободили ресурсы бизнеса на другие задачи.

В результате верной настройки процесса CI/CD разработчикам стало жить куда комфортнее. Мы поняли, как собирается каждый проект клиента, и автоматизировали весь процесс. Теперь команда просто отправляла commit в систему, после чего автоматом запускался пайплайн, который собирал приложение, тестировал и деплоил его сначала в dev, потом в продакшн. В итоге вся цепочка CI/CD была настроена максимально эффективно.

После основной задачи мы продолжили совместную работу. Теперь команда разработки может создавать задачи на техподдержку. Если вдруг что-то сломается или начнет работать не так, как нужно, то у нас есть дежурные, которые тут же возьмутся за тикет. Но мы не только тушим пожары: когда у разработчиков появляется новый сервис, мы его деплоим, а какой-нибудь лишний старый — удаляем. То же самое с нагрузкой — если её надо перераспределить, клиент обращается к нам.

.