Мы уже рассказывали на Хабре про цифровые продукты Почты — электронные заказные письма, отправку для бизнеса, электронные марки. Те, кто пользуется Почтой, могли заметить, что мы стали выпускать всё больше приложений и сервисов и научились делать это оперативно. Сейчас time to market для новых продуктов в Почте — всего 3 месяца, а релизы выходят каждую неделю.
Мы решили оглянуться назад и вспомнить, как большая компания внедрила DevOps практики, чтобы быстро реагировать на новые запросы.
Делать приложение год, и откатиться назад
Начнём с того, что исторически бизнес Почты — в офлайне. Цифровые продукты стали появляться у нас относительно недавно. Поэтому разработкой первых проектов для Почты полностью занимались внешние подрядчики. Это вызывало сложности: работа велась по методологии waterfall (водопад) и занимала много времени, срок разработки продукта мог занимать год и более. А когда случалось так, что подрядчик сменялся до запуска проекта, то мы оказывались если не в начале, то в середине пути и в компании совсем не оставалось наработок и экспертизы.
Чтобы ускориться, в Почте создали Департамент Развития Технологий — он должен был помочь систематизировать и улучшать работу над цифровыми продуктами и нарабатывать собственную экспертизу. Тогда и начался процесс зарождения DevOps в Почте — были закуплены первые централизованные инструменты, которые позволяли выстраивать и контролировать процессы, внедрять практики DevOps. Например, использование GitLab помогло нам управлять кодом и его изменениями и теперь мы каждый день видели что с ним происходит. TeamCity позволил автоматически собирать и тестировать продукты. Как только в GitLab появлялись изменения, TeamCity добавлял и прогонял их по системе. А Maven позволила во всех продуктах видеть один и тот же стандарт сборки, чтобы не разбираться с кучей разных систем. На схеме ниже можно увидеть более полный список инструментов, которые мы выбрали и внедрили для того, чтобы автоматизировать появившиеся тогда в компании стандарты.
Так выглядел выстроенный нами процесс по запуску новых продуктов в Почте
Благодаря нововведениям, мы смогли привести процесс разработки в порядок и сократить сроки выпуска релизов в 4 раза. Если раньше внешние разработчики показывали только финальный результат в назначенный срок, то теперь они регулярно демонстрировали и согласовывали промежуточные результаты. Партнеры стали работать на наших инструментах и по нашему процессу.
И на этой, довольно классической схеме, можно было проработать ещё долго, некоторые компании вообще живут с ней и по сей день, и отлично себя чувствуют. Но рынок логистики быстро растет, и чтобы успевать за спросом, Почта решила создать собственную команду, которая должна была ускорить цифровизацию. Так в 2018 году в Почте появился специальный филиал — Почтовые Технологии, ныне выделившийся в отдельное юрлицо. Перед Почтатехом стояли задачи ускорить разработку, сократив time to market, нарабатывать и сохранять экспертизу внутри компании.
Зарождение культуры изнутри
Если раньше от идеи до запуска продукта мог пройти год или больше, то теперь перед нами стояла цель тратить не больше 3 месяцев на создание MVP, с которым можно выходить на рынок. Чтобы перейти на собственную разработку и начать накапливать полноценную экспертизу, мы начали собирать собственную команду разработчиков. С приходом новых людей стали появляться и свежие идеи и подходы. Команды сами начали внедрять новые инструменты для того, чтобы сокращать время разработки и постепенно стали делиться своими результатами с остальными, рассказывая, как ускорились, как избавились от ожидания очередей на сборку и так далее.
Благодаря внедрению процессов DevOps мы хорошо ускорили процесс выпуска продуктов от идеи до первого пользователя (MVP):
2017 | 2018 | 2019 |
365 дней | 180 дней | >90 дней |
За счет чего мы ускорились? Просто дали разработчикам возможность не отвлекаться от основной работы. Когда код готов, происходит его автоматическая сборка, тестирование и принятие решения по доставке в продакшн. Хотя и последний этап в некоторых продуктах уже тоже работает автоматически.
Мы начали использовать продуктовый подход — сейчас в Почтатехе каждая команда отвечает за свой продукт от и до. У проекта есть собственная команда разработки, выделенные DevOps-инженеры, а в некоторых проектах и своя поддержка. Процесс выстроен так, что команда разработки — это же и команда сопровождения, которая знает не только как пишется код, а ещё и как он собирается, тестируется, доставляется на среды, работает в проде, эта же команда обеспечивает SLA продукта.
Продукты, созданные с применением DevOps, благополучно развиваются и после запуска, даже если приходится переводить специалистов между проектами или полностью менять команду. Грамотный контроль версий и управление стендами позволяет поддерживать и сохранять экспертизу внутри компании и обеспечивать надёжный и стабильный рост, сдерживая количество ручной работы.
Кейс: как DevOps ускорил выдачу серверов
Главная задача DevOps специалиста в Почте – поиск технических решений для существующих вызовов и проблем со стороны эксплуатации и разработки. К примеру, в прошлом году мы осознали, что из-за использования платформы виртуализации тратим много времени на заказ новых серверных мощностей. Чтобы получить сервер, надо подождать от одного дня до недели, а после получения заложить время на проверку работоспособности. В итоге от момента запроса до включения сервера в работу проходило 2-3 недели.
Тогда мы решили развиваться в двух направлениях: развернуть собственное облачную платформу и использовать Kubernetes. Теперь все работает так – у нас заказано десять достаточно мощных машин, и на них мы создаём окружения как нам нужно. Сервис перестаёт быть привязан к конкретному серверу – всем управляет Kubernetes.
После внедрения Kubernetes на некоторых продуктах процесс заработал значительно быстрее. Теперь, когда у бизнеса появляется новая задача, то после обсуждения её добавляют в багтрекер, в GitLab создаётся ветка (где будет вестись разработка по задаче) и сразу же в Kubernetes появляется окружение, где хранятся правки только по этой задаче. Здесь они будут тестироваться отдельно от остальных и никому не мешать, тут же формируются отчёты. Когда задачу закрывают, она мержится в основную интеграционную ветку, где проводятся тесты.
В начале рассказа мы показывали, как выглядела структура взаимодействия со сторонней разработкой. Сейчас же мы переходим к процессам и инструментам, изображенным на этой схеме:
По мере развития DevOps многие наши инструменты перешли в стандарты Почты. Так Confluence и GitLab стали привычными для всей компании. Вместе с GitLab появилась поддержка GitLab CI и теперь все наши новые продукты ею пользуются.
Ещё, благодаря внедрению новых продуктов и практик мы:
Построили систему управления конфигурациями.
Построили систему непрерывной интеграции – сборки и деплоя.
Сформировали свои подходы к тому, как продукты должны попадать во все среды – dev, test, stage, prod.
Развернули системы логирования и систему контроля качества кодов
Добавили системы работы с документацией, багами, тест-кейсами.
Начали продвигать подход «инфраструктура как код» (IaC).
DevOps проник в компанию из повседневной практики, без запроса на него «сверху». Такое хаотичное зарождение изнутри не прошло гладко. Каждый, кто внедрял свои инструменты и подходы, делал это по-своему. Человек мог наладить какой-то процесс, а после его ухода никто не знал, что и как должно работать. С последствиями несистемного внедрения теперь приходится разбираться. Для того, чтобы свести все процессы к единому подходу, в 2020 году в Почте сформировалось DevOps-комьюнити. Цель сообщества – сделать так, чтобы культура стала развиваться системно. Для этого мы начали выстраивать структуру и нанимать людей конкретно под DevOps-задачи. То есть прямо сейчас происходит самое интересное – выстраиваются основные подходы и стандарты.
К культуре через роли
Пока что DevOps в Почте это скорее роль, в которую заложены определённые задачи: сопровождение и автоматизация релизов, автоматизация постановки на мониторинг и анализ логов, участие в улучшении продукта под микросервисную архитектуру, предложения по приведению продукта к cloud-ready/native состоянию. Слово «роль» в отношении DevOps может звучать непривычно и странно, но особенности того, как развивается компания, накладывают нестандартное отношение к подходу.
Мы понимаем, что DevOps это ответственность не одного человека, а всей команды, поэтому сейчас наша главная цель – сделать так, чтобы DevOps в компании стал культурой. Чтобы каждый, кто участвует в создании продукта, осознавал, что тот должен полностью укладываться в DevOps процессы, а значит быть адаптированным под автоматизацию.
Сейчас у наших DevOps есть возможность напрямую отвечать за продукт, и для этого есть целый набор инструментов: системы сбора логов, сбора метрик, мониторинга, сборки, автоматического управления конфигурацией и контроля версий. DevOps может решить любую проблему как со стороны сервера, так и со стороны кода. Код не лежит где-то далеко за доступом по трём заявкам. Если нужны логи или метрики – они открыты для всех проектов. Когда не хватает каких-то данных – можно внедрить дополнительную систему, чтобы получить их. Главная цель – чтобы продукт работал, качество росло и разработка шла быстрее. Избавленные от рутины, DevOps специалисты занимаются одной из самых интересных задач – обеспечивают стабильную работу продукта при высокой нагрузке и частых релизах.
