Привет, Хабр! Я Оля Шишенина, отвечаю за обучение и развитие сотрудников VK. Хочу рассказать про внутреннее мероприятие для инженеров, которое мы провели этой весной: Фиксатон VK — трёхдневный марафон по багфиксам, на котором разработчики чинили баги не только в своих командах, но и в смежных продуктах VK. Решения прошли многоэтапный фильтр от общего пула задач, через проверку кода, QA‑ревью при подготовке к релизу.

Победители фиксатона получили Nintendo, Playstation, а главному победителю по баллам в индивидуальном зачёте мы подарили Niva Legend — это отличная машина для того, кто любит фиксить и тюнинговать.

Числа:

• 12 продуктов;

• 1500 багов;

• 198 зарегистрированных участников‑инженеров VK;

• 3 дня работы;

• 815 багов исправлено за время Фиксатона;

• 420 решений влиты в прод в следующие две недели.

Треки:

• Backend;

• Frontend;

• Mobile;

• Desktop. 

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

Зачем было делать Фиксатон?

Наш Фиксатон — по сути багатон, или bug bash. Считается, что первыми такой формат работы с техдолгом придумали в Microsoft. Внутренние bug bash закрепились в командах Windows и Office ещё в конце 1990‑х: на несколько часов компания объявляла режим «охоты на баги», вводила простые правила и давала очки за найденные, воспроизведённые и исправленные дефекты. В итоге рутинная стабилизация продукта превращалась в короткий и мотивирующий марафон качества. 

Для каждого инженера это возможность исправить что‑то в любимом, но не обязательно своём продукте VK. Не увидеть на следующий день надоедливый баг, который ты пофиксил сам, — отдельный вид дзена.

Когда продуктов много, рано или поздно появляется потребность в сквозных инженерных практиках:

• единые ожидания по качеству;

• повторяемые процессы;

• обмен решениями и подходами между командами.

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

Кроме того, для нас был важен один из эффектов межпродуктового формата — свежий взгляд. Иногда багфикс в незнакомом продукте вытаскивает наружу системную проблему, и тогда «починить» означает «немного переделать сценарий». Так команда инженеров из VK Видео взялась за задачу в Облаке Mail: всё начиналось как простая замена иконок, но потом переросло в небольшой редизайн облачного хранилища. Обновили экраны папок, истории и предпросмотр файлов, а заодно глубоко погрузились в устройство и сценарии работы Облака.

Что было характерно для VK

• Разные стеки и стандарты. Исторически продукты жили в своих технологических нишах: разные языки, фреймворки, CI, правила ревью, релизные циклы, подходы к тестированию.

• Культура Zero bug. При условном соотношении один тестировщик на пять разработчиков команда берет на себя значительную часть тестирования. Но «уметь фиксить» и «уметь проверять» — это разные навыки.

Поэтому мы задумали Фиксатон как практику, которая одновременно:

• помогает разгребать накопившийся техдолг;

• заставляет процессно доводить исправления до состояния «можно влить»;

• прокачивает приёмку и регрессию у разработки;

• снижает барьер входа в чужие кодовые базы.

Как устроен Фиксатон?

В Фиксатон вошли задачи из 12 продуктов:

Тестировщики собрали пул багов, которые воспроизводятся, имеют понятный expected/actual, по разным причинам не исправлялись. Дальше мы сделали единый дашборд в Jira и загрузили туда 1500 задач.

Однако межпродуктовый формат ломается не на сложности багов, а на банальном:

• получить все необходимые доступы;

• разобраться в структуре проекта;

• правильно собрать проект;

• разобраться, где смотреть контракты и за что они отвечают;

• получить доступ к стендам;

• прогнать тесты;

• понять пользовательский сценарий.

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

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

• читать код;

• собирать и запускать проект локально;

• создавать ветки и MR;

• видеть CI и артефакты.

Технические подробности зависят от инфраструктуры, но суть одна — это отдельная координация между владельцами репозиториев, ИБ и командами продуктов.

Онбординг‑пакеты по каждому продукту (в Git). Для каждого продукта подготовили «быстрый вход», чтобы разработчик из другого домена не тратил половину Фиксатона на археологию:

• структура репозитория (где что лежит);

• как поднять локально (env vars, конфигурации);

• как прогнать тесты и линтеры;

• локальные особенности кода и соглашения;

• где смотреть журналы и метрики при проверке фикса.

Побочный эффект: эти материалы пригодились и после — часть онбордингов мы переиспользовали при обычной адаптации разработчиков.

Подготовка участников: приёмка и чек‑листы

Мы не хотели, чтобы качество фиксов упиралось в «не умею проверять» или «не знаю, что считается готовым». Поэтому заранее провели обучение и сделали интерактивные чек‑листы.

Сессия про ИИ‑ассистенты

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

Обучение по ручной приёмке багов

Рассказали, как проверять причину, а не симптом, как мыслить расследованиями, границами и консистентностью, а не принимать «у меня на машине работает».

Все участники в итоге понимали:
— как фиксировать шаги воспроизведения бага и проверять негативные сценарии;
— как делать минимальный регресс вокруг фикса;
— как проверять фикс в условиях, близких к боевым;
— как доводить проверку до границ (пустые значения, максимумы, кэш, состояние после ошибки);
— как подтверждать, что исправление не сломало смежное поведение и зависимые компоненты.
— как ловить плавающие баги и гонки (воспроизведение под нагрузкой, логирование, стрессовые прогоны);
— как проверять фиксы в распределённых системах (идемпотентность, частичные сбои, консистентность данных между сервисами);
— как строить гипотезу о причине до правки и подтверждать её тестом, а не «поправить и посмотреть»;
— как отличать фикс симптома от фикса корневой причины и почему это важно для регресса.

Формула хорошего фикса

Мы отдельно проговаривали: цель — не «закрыть тикет» и не «отправить коммит», а довести изменение до состояния, когда оно:

• понятно;

• проверено;

• не ломает соседние сценарии;

• может быть принято продуктом и доехать до релиза.

Чек‑листы по направлениям

Мы собрали сайт, где участники выбирали стек и тип изменений и получали чек‑лист, что нужно проверить. Для каждого стека собрали пакеты проверок, которые покрывают большую часть типовых ситуаций: backend, frontend и mobile.

Это не «учебник по QA», а практические списки, где можно отметить, какие изменения внесены в ходе исправления, а система сама приготовит тебе чек‑лист с важными для таких ситуаций проверками. Например, если при исправлении мобильного приложения затронута работа с эндпоинтами API, то нужно не забыть проверить, что Response корректно преобразуется в модель приложения, а состояние интерфейса обновляется правильно.

Жизненный цикл бага на Фиксатоне

Пример: баг в VK Музыке, исправленный участником из VK Видео:

При создании плейлиста треки из поиска просто некуда было добавить — не было кнопки и способа завершить выбор, фича, по факту, не работала. Сделали разделённое выделение в поиске и в библиотеке на две независимые корзины, добавили нижнюю кнопку «Добавить» со счётчиком, которая красиво уезжает от клавиатуры. Теперь можно собрать плейлист из поиска. Это было сложно, так как потребовалось собрать интерфейс в новом проекте.

Почему мы сделали две проверки: QA + Dev продукта

Тестер и разработчик смотрят на разные риски:

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

Итоги

Мы считали результаты в двух срезах:

1. Баллы (с коэффициентами сложности и ценности), чтобы не стимулировать «закрывать только лёгкое».

2. Отдельная номинация — сколько исправлений реально доехало до прода.

Причина такого подхода в том, что «решено» ≠ «влито» ≠ «в проде», а инженерная ценность появляется на последнем шаге.

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

Фактические результаты: за три дня исправили 815 багов, и за две недели после Фиксатона — 420 решений вывели на прод.

При планировании Фиксатона мы ставили несколько целей: приоритизация и уменьшение технического долга (минимум 15–20% принятых фиксов, а получилось 28% оперативно влитых в прод изменений), повышение кросс‑опыления продуктов, погружение разработки в вопросы багфикса.

Что бы мы повторили в следующий раз (и что точно не стоит недооценивать)

Если перевести опыт в инженерные выводы, то самые «окупаемые» элементы межпродуктового формата такие:

1. Онбординг и доступы — это 50% успеха. Если их не сделать заранее, то мероприятие превращается в чат «у меня не собирается».

2. Обучение приёмке + чек‑листы заметно повышают долю исправлений, которые проходят QA‑проверку с первого раза.

3. Два ревью (QA + Dev продукта) обязательны. Иначе либо падает качество, либо продуктовые команды не готовы принимать изменения.

4. Метрика «доехало до прода» важнее, чем «сколько тикетов закрыли». Она лучше отражает реальную пользу для пользователей и продукта.

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

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