Прокачиваем DevOps в компании

Привет! Меня зовут Сергей, я занимаюсь направлением DevOps в KTS.

Наша компания помогает бизнесу реализовывать IT-сервисы. С 2015 года мы специализируемся на разработке сложных высоконагруженных сервисов для крупных корпораций, таких как Mail.Ru или X5.

Проектов очень много. На разработку и поддержку требуется много времени и ресурсов. Поэтому мы уделяем большое внимание инфраструктуре и различным способам повышения эффективности разработки. DevOps так и расшифровывается: Development & Operations.

К лету 2021 года мы настолько преисполнились пониманием мира DevOps, что решили выделить это как отдельную услугу. Ведь есть куча компаний, которым это очень надо — как мы в прошлом. По крайней мере, мы так считали.

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

Для начала расскажем, с чего мы начинали и как пришли к текущему состоянию.

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

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

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

Начали с системы релиза.

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

Когда разработчик делает что-то локально (на своем компьютере), он должен проверять свою часть кода. Проект может быть огромным и включать большое количество компонентов. Чтобы не запускать все локально, разработчик отправляет в Gitlab весь проект, раскладывает его и проверяет работоспособность.

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

Когда разработчиков и тестировщиков становится много, одного тестового стенда не хватает.

С одним стендом у вас 2 варианта: либо сотрудники проверяют свои части проекта по очереди, либо все должны объединить свои задачи в один «пакет» кода, который запускают на стенде.

И то и другое неудобно. Если проверять код по очереди, нужно много времени и согласований. Если объединять в одно целое, неудобно исправлять ошибки — код нужно снова разделять между разработчиками, чтобы оставить только верно работающие части.

Эту проблему мы решили через автоматический деплой по веткам, который выглядит так: разработчик работает над своей задачей, для которой в системе контроля версий есть отдельная ветка. Например, «Task 25». Для теста он отправляет ветку в Gitlab, и автоматические скрипты специально для него создают отдельную копию приложения. Таким образом мы получаем любое необходимое количество тестовых стендов. Сам разработчик не делает ничего, просто отгружает ветку кода в Gitlab. Тестировщик тоже проверяет только эту ветку, переходя по отдельному домену, например task25.project.ru. После проверки ветку добавляют в релиз.

Так можно смотреть отдельно каждую задачу и потихоньку «припаивать» их к основному коду. Если раньше 10 человек делили один тестовый стенд, сейчас у каждого есть свой.

Таким образом менеджеры и тестировщики могут сразу смотреть на результат задачи, достаточно перейти на нужный поддомен по названию задачи, где будет текущая версия проекта + задача разработчика. Это существенно сокращает время доведения фичей до релиза. А время = деньги.

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

Есть такая парадигма, что на одной машине должен быть запущен только один проект. Тогда, если с машиной что-то случится, остальные проекты продолжат работать. Так все работает независимо, но есть минус: компания нерационально тратит ресурсы. Для запуска виртуальных машин есть минимальные объемы и мощности: например, нельзя купить меньше одного ядра. К тому же не стоит покупать виртуальную машину с мощностью «впритык» — вдруг приложение масштабируется и ему не хватит ресурсов? И поэтому получается, что множество машин простаивает — они поддерживают работу проектов, которые практически не тратят ресурсов, используют мощности машин лишь на малую часть.

Сейчас мы запускаем проекты с использованием Docker и Kubernetes. Они дают два преимущества: делят ресурсы для рационального использования и обеспечивают отказоустойчивость.

Docker позволяет развернуть на одной машине несколько проектов: сервис режет мощности виртуальной машины на небольшие контейнеры. Теперь на каждый проект вы можете выделить столько мощности, сколько необходимо, собрать собственную виртуальную машину из маленьких контейнеров.

Kubernetes работает поверх корневого ядра Docker и обеспечивает отказоустойчивость. Теперь мы можем купить 5 машин, и все мелкие проекты запустить на них. Если какое-то приложение начнет потреблять больше мощности, Kubernetes создаст дополнительные виртуальные контейнеры на другой машине. То же самое будет, если какие-то виртуальные контейнеры выйдут из строя.

Благодаря этому мы подстрахованы.

Сейчас деплой переведен на Kubernetes, который позволяет легко масштабировать приложения для адаптации к высоким нагрузкам. Если какой-то проект начал потреблять больше мощности, ему требуется больше Docker-контейнеров для работы, иначе он будет тормозить. Kubernetes сам посмотрит на запросы всех проектов и поймет, что выделенной мощности недостаточно. Тогда система подключит дополнительную машину. Можно настроить процесс так, что Kubernetes даже покупать машины будет сам.

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

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

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

В продакшне у каждого приложения автоматически настраиваются все мониторинги. Объясню на примере, как это происходит у нас для типовых проектов.

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

Если что-то идет не так, разработчики должны получать уведомления. Для их генерации у нас есть alert-менеджер и Телеграм-бот. У каждого уведомления есть уровень опасности — warning или critical.

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

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

Для логирования мы используем Loki. Он собирает логи со всех проектов и отправляет в хранилище. Loki тоже можно использовать через Grafana: запросить логи за период времени с ключевым словом (для более детального исследования) и посмотреть на метрики. Так можно быстро найти причины проблемы.

Сейчас мы работаем над созданием «DevOps-коробки»: продукта, который позволит убрать ручной труд из релизного цикла и настройки инфраструктуры. Сетевые доступы, dns-записи, необходимые БД и очереди, хранилища файлов, стек мониторинга и логирования… Разработчик укажет это в файле рядом с кодом приложения, и все будет автоматически настроено при первом же релизе. Для этого мы используем специальный инструмент — Terraform.

Есть такой подход, как Infrastructure As a Code (IaC).

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

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

Например, мы начали выписывать DNS-записи, устанавливать БД в облаке Selectel, переводим туда очередь сообщений в ребите и многое другое.

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

Это и есть цель нашей DevOps-коробки.

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

А про то, как мы тестировали гипотезы и находили первых клиентов, расскажу в следующей статье.