В предыдущей статье я рассказывал, что наша команда Платформы получила цель «Техстек всегда актуален». Но многие ли компании могут похвастаться тем, что все компоненты их стека не покрылись пылью, а регулярно обновляются?
Скажу честно: мы тоже долго не занимались этим системно, пока не поняли, что эта работа приоритетна. Мы больше не хотим попадать в ситуацию, когда устаревшая база данных не позволяет выполнить запрос вне единственного индекса, созданного 15 лет назад. В этой статье я подробно расскажу, как мы построили процесс, который гарантирует актуальность технологического стека.
Как OKR помог свернуть горы
Меня зовут Станислав Решетнев, я руководитель отдела разработки в Sape (направление Link Building). В нашей компании есть команда Платформы, которая упрощает жизнь продуктовым командам. На ее плечи легла задача «Техстек всегда актуален». Смысл не в том, чтобы один раз все поправить, а чтобы обновления стали системой, без пропусков и напоминаний.
В OKR принято ставить амбициозные и вдохновляющие цели. Команда такую цель приняла, и работа закипела. В итоге сегодня у нас нет ни одного блокера, а весь стек обновляется по SLA.
Часть 1. Описываем техстек и задаем SLO на сроки обновления
Начали с описания технологического стека и определения границ обновлений. Границы оказались нетривиальными, поэтому расскажу о них подробнее.
Вот основные компоненты нашего стека:
PHP
Symfony
RoadRunner
ClickHouse
N8n
MySQL / Postgres Cluster
Sphinx / Manticore
Podman
RabbitMQ
ConfluentPlatform
Vite
VueJS
Часть компонентов, например реляционные БД для бизнес-данных, используются и в других направлениях разработки. Мы решили обслуживать только те, что входят в наше направление, что не всегда было просто. Например, была проблема с устаревшей версией MySQL. Приложения привязались к ней специфическими запросами с конвертацией кодировок, а огромные таблицы не имели нормальных индексов. Мы решили подобрать новую БД, которая устроит все команды, но сам перенос делать только для направления Link Building.
Но обновить базу данных недостаточно, чтобы техстек считался актуальным. Нужно, чтобы все приложения на нее перешли. Поэтому мы добавили в процесс делегирование: как только выходит новая версия БД, в команды, где она используется, уходит задача на переход.
У разных компонентов своя специфика:
Для PHP и Symfony нужно обновлять конкретные приложения, и важно, чтобы все перешли на новый docker-образ. Мы ведем реестр приложений, которые планируем обновлять (они заданы в SLA). Обычно мы сначала обновляем PHP, добиваясь совместимости со старой версией Symfony, а затем планируем обновление Symfony.
Оркестратор рабочих процессов n8n, напротив, общий, поэтому в соглашении заложено только обновление кластера.
Фреймворк и сборщик фронтенда Vite/VueJS обновляем вместе.
А когда планировать обновление? Есть два подхода: обновляться сразу после выхода новой версии или дожидаться приближения End of Life.
Для каждого компонента мы выработали свой SLO (Service Level Objective – метрика, за которую будет отвечать SLA). За точку отсчета взяли выход LTS-версии и зафиксировали срок, в который нужно уложиться с обновлением.
Проект по плановому обновлению в таск-трекере выглядит так:
В нем собраны вехи по компонентам с ответственным за обновление. В каждой вехе прописаны правила обновления. Под каждое плановое обновление создается отдельная веха с тегом компонента и ожидаемой датой:
Теги нужны, чтобы собирать инфополе и контролировать SLA. Об этом расскажу далее.
Часть 2. Создаем метрику и инфополе обновлений
Для прикладных рабочих процессов мы традиционно используем n8n. Создавать их в этой среде быстро, и это приемлемо, когда нет жестких требований к отказоустойчивости. Мы мониторим падение процессов и штатно чиним их.
Мы подготовили рабочий процесс, который выглядит так:
Алгоритм таков:
Получаем из Data Tables n8n список компонентов и ID их тегов в таск-трекере.
Получаем задачи из таск-трекера по тегу, оставляем только вехи.
По каждому тегу и компоненту вычисляем: выполнено обновление или нет (веха закрыта) и какая планируемая дата.
Считаем число выполненных обновлений, дату следующего и дату последнего обновления.
Записываем все в таблицу.
Результат выглядит так:
Подсвечиваем цветами обновляемость по SLA, даты обновлений — цветовой картой, считаем итоговую статистику. Как видите, удалось добиться обновляемости всех компонентов!
Часть 3. Описываем и запускаем процесс
Итак, у нас есть проект в таск-трекере с циклами обновления и инфополе с уведомлениями об актуальности. Теперь опишем процесс, который собирает все воедино и запускает систему:
Когда подходит срок планового обновления, разработчики Платформы видят задачу в таск-трекере. На встрече по планированию спринта закладывают задачи по обновлению.
После выполнения задача закрывается, и сразу же, согласно SLA, создается новая (например, дата выхода LTS + 6 месяцев).
Если задача не создалась, мы увидим это в инфополе: в таблице у компонента подсветится ячейка. За этим следит вся команда, но ответственность на лидере Платформы.
Эта система несложная и реализована подручными средствами. Но с ней нам не нужно беспокоиться, что мы забыли что-то обновить или не нашли времени. Теперь это определяют SLA и процесс. Согласитесь, гораздо комфортнее, когда в споре за ресурсы арбитром выступает SLA.
Спасибо за внимание! Буду рад в комментариях почитать, как в вашей компании решается проблема актуализации техстека.