Вчера выкатили 3 релиза, а сегодня поддержка ловит очередной инцидент, но уже непонятно, какой именно релиз его вызвал. Знакомая картина?
Проблема в том, что вы не видите связи между тем, что выкатываете на продакшен, и тем, что ломается после этого. А когда связь теряется, релизы превращаются из инструмента развития в источник непредсказуемых сбоев.
Привет, меня зовут Артем Герасимов, я владелец продукта SimpleOne SDLC. В этой статье я расскажу вам, как слишком частые релизы могут негативно сказываться на качестве продукта и что с этим можно сделать.
Почему частые релизы могут провоцировать появление проблем
Многие команды приняли DevOps-культуру и внедрили практики непрерывной интеграции и развертывания (CI/CD). Частота релизов выросла в разы. Казалось бы, это должно означать, что продукт развивается быстрее, а пользователи получают новую функциональность чаще но в реальности все сложнее.
Для SaaS-продуктов, особенно B2C, частые маленькие релизы действительно могут быть нормой и работать отлично. Пользователи даже не замечают обновлений: зашли в Google Документы утром — одна версия, вечером — уже другая, и никаких действий от них не требуется. Здесь частые релизы являются конкурентным преимуществом.
Совсем другая история с on-premise решениями и enterprise-продуктами. Здесь каждое обновление:
требует выделения ресурсов ИТ-отдела клиента;
проходит через процедуры согласования и тестирования на стороне заказчика;
может потребовать простоя системы;
несет риски для критичных бизнес-процессов.
Для таких клиентов частые релизы становятся не благом, а головной болью. Они физически не могут и не хотят обновляться каждую неделю или даже каждый месяц. Реальность такова, что enterprise-клиенты обновляются раз в полгода или год, а иногда и реже.
Проблема возникает, когда команда разработки строит процессы под частые релизы, не учитывая реальное поведение своих клиентов. Получается парадокс:
разработка выпускает маленький релиз каждый месяц;
тратит ресурсы на регрессионное тестирование, подготовку документации, релизные процедуры;
но клиенты не обновляются, потому что для них это дорого;
в итоге время и деньги потрачены впустую.
Поэтому дальше мы будем говорить в первую очередь о ситуациях, когда частые релизы не соответствуют реальным потребностям и возможностям клиентов. Если у вас SaaS и вы успешно релизитесь по несколько раз в день с полным покрытием автотестами и стабильной работой — эта статья не про вас. Но если вы чувствуете, что после ускорения релизов количество проблем только выросло, читайте дальше.
Релизов много, ценности мало
В компаниях растет не только частота релизов, но и количество инцидентов после каждого обновления. Когда релизы слишком частые, возникает несколько проблем:
релизы становятся менее насыщенными и ценными для пользователей;
уменьшается время на тестирование и проверки;
клиентам не хочется тратить время на обновление, если оно приносит минимум новой функциональности;
возрастает количество инцидентов из-за недостаточного тестирования.
Связь между изменениями теряется
Когда релизы выходят каждый день или даже несколько раз в день, команда теряет способность отследить причинно-следственные связи: на следующий день после трех релизов приходит сообщение о сломанной кнопке, которую правили в двух из трех релизов, и непонятно, в каком именно релизе произошла поломка. Приходится комплексно погружаться в код вместо того, чтобы локализовать проблему в конкретном изменении.
Это замедляет не только исправление ошибок, но и общую скорость работы команды.
Частота релизов повышает риски
Частота релизов сама по себе не равна стабильности. Важна корреляция с метриками восстановления (MTTR) и общим количеством критичных инцидентов.
Каждый релиз несет определенные операционные риски: данные могут подгрузиться неправильно, интеграции могут сломаться и все такое.
Релиз является публичным событием, которое ведет за собой определенное количество действий и рисков. Если процесс CI/CD где-то ломается, мы рискуем, что у клиента что-то упадет и он потеряет данные или возможность работать. Чем чаще мы релизимся, тем выше вероятность такого сценария.
Но релизы все равно нужны!
Это не значит, что нужно отказаться от релизов вообще или выпускать их крайне редко. Существует подход feature flags (механизм отделения деплоя от открытия функциональности для пользователя), когда код постоянно выкатывается на продакшен, но функциональность открывается только по запросу владельца продукта.
Такой подход дает несколько преимуществ:
нет лишней рассинхронизации между командами;
команда разработки быстро выпускает и делает, не дожидаясь разрешения;
гипотезы тестируются быстрее;
дефекты чинятся оперативнее.
Приведу пример из личной практики: команда разработки SimpleOne SDLC в какой-то момент пришла с инициативой релизиться каждый месяц. По итогу это привело к нескольким проблемам:
Функциональности стало выходить значительно меньше из-за длинного цикла разработки.
За месяц не так много получилось успевать.
Продукты были очень сырыми.
Проходило много дополнительных регрессов, релизов и других действий, которые теоретически были не нужны для маленьких релизов.
Самое интересное: клиенты не обновлялись каждый месяц. Получалось так, что команда выпускала каждый месяц что-то маленькое, но клиент этим не пользовался, и время тратилось на релизные процессы впустую.
Компания пересмотрела подход: с лета SimpleOne не релизится каждый месяц специально, а только «по готовности», накапливая действительно ценную функциональность.
Частота релизов должна соответствовать типу продукта и ожиданиям клиентов:
Для B2C SaaS-приложений (вроде Google Документов) ежедневные обновления незаметны и уместны, пользователи даже не узнают, что что-то изменилось.
Для мобильных приложений частые обновления могут раздражать, потому что пользователю приходится постоянно что-то скачивать.
Для B2B продуктов, которые устанавливаются на стороне клиента (on-premise), обновление один-два раза в год является нормой, релизиться каждый день в такой ситуации бессмысленно.
Важно не увеличивать частоту релизов без понимания того, для чего это нужно. Иначе возрастает количество инцидентов, потому что времени на релиз меньше, и команда меньше времени уделяет тестированию и проверкам. Релизы становятся пустыми, менее наполненными, менее ценными. И тогда возникает вопрос: нужно ли клиенту тратить свое время на обновление, если оно не особо-то ценное?
Почему инциденты повторяются
Корень проблемы не в инструментах автоматизации и не в методологиях разработки. Проблема в том, как компании работают с последствиями релизов, и почему разработка не видит связи с тем, что происходит в эксплуатации.
Инциденты после релизов часто классифицируются как операционные: команда поддержки находит обходное решение, пользователь получает ответ, инцидент закрывается. Формально — все починили. Но на самом деле наложена заплатка, а корневая причина так и осталась на месте. Количество таких заплаток растет, накапливается технический долг.
Зачастую в компании нет процесса управления проблемами (Problem Management), хотя он позволяет превратить повторяющиеся инциденты в известные ошибки:
Если инцидент возник один раз, его чинят как инцидент;
Если он повторяется несколько раз, из него создается проблема;
Проблема фиксируется в базе данных известных ошибок (Knowledge Error Database, KEDB);
Для проблемы описывается обходное ��ешение, которое позволяет временно устранить последствия;
Техническая поддержка использует это обходное решение для быстрого ответа пользователям;
Разработка получает задачу исправить корневую причину раз и навсегда.
Разрыв между разработкой и поддержкой
Все описанные выше проблемы — заплатки, повторяющиеся инциденты, растущий технический долг — это не причины, а симптомы.
Корневая проблема глубже: разработка и поддержка живут в параллельных мирах и не общаются между собой.
Процесс управления проблемами работает только при наличии связки между службой поддержки и разработкой. Связка управления ИТ-услугами (ITSM) и жизненного цикла разработки (SDLC) является фундаментом стабильной системы. Без нее возникает опасный разрыв, который разрушает весь цикл создания ценности. Что происходит при разрыве:
С одной стороны баррикад — разработка. Она не получает обратную связь от эксплуатации и не знает, какие проблемы реально волнуют пользователей в продакшене. Разработчики работают в своей системе управления задачами (Jira, YouTrack, Azure DevOps), фокусируются на новой функциональности, которую требует бизнес, и не видят, что половина их "исправлений" на самом деле временные заплатки.
С другой стороны — техническая поддержка. Она справляется с инцидентами обходными путями, работает в своей ITSM-системе (ServiceNow, Zendesk, или что-то еще), накапливает знания об известных ошибках в своей базе (KEDB). Но главное: поддержка не знает, что проблему можно и нужно отдать разработке для полноценного решения. У них есть процесс: создать проблему, найти временное решение, закрыть инцидент. Но нет процесса передачи этой проблемы дальше в разработку.
Между этими двумя мирами нет связующего звена. Разработчики не видят, что поддержка двадцатый раз за месяц объясняет пользователям один и тот же workaround. Поддержка не знает, что разработка могла бы исправить эту проблему навсегда за день работы. Последствия разрыва:
Цикл не замыкается
Инцидент возникает, поддержка находит обходное решение, инцидент закрывается, про него все забывают. Через неделю инцидент повторяется, снова обходное решение. И так по кругу.
Накапливаются костыли на костылях
В базе знаний поддержки появляются сотни инструкций с workaround. В коде продукта накапливаются сотни временных проверок и условий. Никто не помнит, зачем они там и можно ли их убрать. Каждый новый разработчик боится что-то менять, потому что неизвестно, что сломается.
Как результат — никто не хочет работать в компании, где все держится на временных решениях. Опытные разработчики уходят, потому что устали от легаси-кода в заплатках. Новые уходят после первого погружения в кодовую базу. Специалисты поддержки выгорают, отвечая на одни и те же вопросы. Пользователи разочаровываются в продукте, который "вроде работает, но постоянно глючит".
Что делать? Управляемый релиз требует сквозного контура обратной связи
Релиз — не финишная черта, а начало наблюдения. Что сломалось после выката? Почему это произошло? Как быстро удалось восстановить работу? Ответы на эти вопросы важнее скорости доставки.
Релиз может казаться концом истории для разработчиков, но точно не для бизнеса. После релиза важно понимать как работает выпущенная функциональность, что происходит с системой и какие метрики изменились.
Это дополнительные метрики DORA (DevOps Research and Assessment — исследование и оценка DevOps), которые показывают:
сколько инцидентов произошло после релиза;
насколько хорошо протестировали релиз;
нужно ли увеличить регресс;
нужно ли лучше покрыть тестами определенные части системы.
Для управляемого релиза необходим замкнутый цикл обратной связи. В идеальном мире он выглядит так:
Релиз выходит на продакшен.
Возникает инцидент.
Инцидент анализируется. Если он повторяется, создается проблема.
Формируется запрос на изменение (Change).
Изменение включается в следующий релиз.
Важный момент: не все инциденты обязательно должны превращаться в проблему. Если инцидент неповторяющийся, можно пропустить этап создания проблемы и сразу создать запрос на изменение.
Конечно, это картина идеального мира, и на практике редко получается следовать такому четкому алгоритму, но когда мы к этому стремимся — мы поддерживаем продукт в качественном состоянии.
Основные связки метрик
Для отслеживания эффективности цикла обратной связи используются метрики DORA. Они показывают реальную картину стабильности.
Lead Time for Changes и MTTR
Lead Time for Changes показывает, сколько времени проходит от коммита до продакшена. В связке с MTTR (Mean Time To Recovery, среднее время восстановления) эти метрики дают скорость реакции на ошибки.
Здесь надо понимать, что это скорее полезно для критичных инцидентов. На мелкие инциденты реагировать и пытаться исправлять их сразу не имеет смысла. Поэтому, если смотреть на скорость реакции без учета важности инцидентов, то получается размытая метрика, которая не дает полной картины.
Возможно, критические инциденты команда исправляет за пять минут, и все отлично, а мелкие инциденты исправляет три года. По итогу средняя метрика будет где-то около года. Поэтому важно делить метрики по степени приоритета и понимать: критичные инциденты должны чиниться за день, а некритичные могут подождать и месяц.
Тренд известных ошибок в KEDB
Временной тренд известных ошибок в базе данных (KEDB) показывает, растет ли количество временных решений.
Если ошибок в KEDB становится все больше, значит у вас растет количество временных решений, а это не очень хорошо. Это говорит о том, что:
техническая поддержка исправляет все больше проблем обходными путями;
разработка не справляется с исправлением корневых причин;
технический долг накапливается быстрее, чем погашается;
рано или поздно система станет неуправляемой из-за множества костылей.
Это не про качество планирования релиза, а про общее состояние продукта. Растущий тренд в KEDB является тревожным сигналом, что процесс вышел из-под контроля. Команда тратит все больше времени на поддержание временных решений вместо того, чтобы устранять проблемы навсегда.
Здоровая динамика выглядит иначе: проблемы попадают в KEDB, но затем планомерно исправляются и закрываются. База остается стабильной или даже уменьшается со временем.
Change Failure Rate (коэффициент неудачных изменений)
Коэффициент неудачных изменений показывает, какая доля релизов приводит к проблемам в продакшене. Это не метрика конкретного релиза, а общий показатель качества процессов разработки и тестирования продукта.
Метрика рассчитывается просто: количество неудачных развертываний делится на общее количество развертываний за период.
В связке с количеством инцидентов категории P1 и P2 (критичные и высокие) этот показатель дает полное представление о реальной стабильности системы. Он отвечает на вопросы:
как часто релизы приводят к серьезным проблемам;
насколько надежен процесс тестирования перед выкаткой;
сколько критичных инцидентов происходит после релизов.
Высокий коэффициент неудачных изменений сигнализирует о системных проблемах в процессе разработки: недостаточное тестирование, слабое покрытие автотестами, отсутствие этапов проверки перед продакшеном.
Единое информационное пространство
Когда системы управления разработкой (SDLC) и управления ИТ-услугами (ITSM) работают в едином информационном пространстве, команда получает полную прозрачность всего цикла: от задачи в спринте до инцидента в продакшене и обратно.
Что дает единое пространство:
Прямая связь инцидентов с задачами и релизами
Когда приходит инцидент, система автоматически показывает в каком релизе произошло изменение, какая конкретно задача из спринта могла привести к проблеме, кто работал над этой задачей и так далее.
Не нужно вручную искать в коммитах и переписке, что могло сломаться: связь видна сразу.
Приоритизация дефектов по количеству инцидентов
В едином пространстве видно, сколько инцидентов связано с каждым дефектом:
один-два инцидента — возможно, единичная проблема, можно запланировать в обычном порядке;
больше пяти — частая проблема, нужно поднять приоритет;
больше десяти — массовая ошибка, требуется срочное исправление.
Вместо субъективных оценок команда видит объективные данные и принимает решения на их основе.
Управление техническим долгом
Система фиксирует какие проблемы из KEDB еще не превратились в задачи разработки, сколько времени команда тратит на обходные решения вместо исправления корневых причин и какие области продукта накопили больше всего технического долга.
Это позволяет осознанно планировать работу над улучшением стабильности, а не только гнаться за новой функциональностью.
Метрики времени восстановления
Единое пространство отслеживает сколько времени прошло от обнаружения инцидента до его исправления и как быстро команда реагирует на проблемы разной критичности.
Пример: как это реализовано в SimpleOne
В SimpleOne продукты SDLC и ITSM построены на единой платформе, что обеспечивает бесшовную интеграцию данных:
когда техническая поддержка создает инцидент в ITSM, она может сразу связать его с релизом из SDLC;
если инцидент повторяется, из него создается проблема в ITSM с описанием обходного решения;
из проблемы автоматически можно создать дефект в бэклоге прод��кта в SDLC;
дефект попадает в общую приоритизацию вместе с продуктовыми задачами, и владелец продукта видит, сколько инцидентов связано с этим дефектом;
когда дефект исправлен и попадает в релиз, система автоматически связывает релиз с исправленной проблемой;
техническая поддержка видит, что проблема решена, и может убрать обходное решение из инструкций.
Такая сквозная интеграция превращает разрозненные данные в единую картину: команда разработки понимает реальное влияние своей работы на пользователей, техническая поддержка знает, когда проблемы будут исправлены навсегда, а владелец продукта принимает решения на основе данных, а не догадок.
Резюме
Частые релизы — не проблема сами по себе. Проблема возникает, когда компания теряет связь между тем, что выкатывает на продакшен, и тем, что происходит после этого.
Без замкнутого контура обратной связи между разработкой и эксплуатацией релизы превращаются из инструмента развития в источник нестабильности.
Управляемые релизы требуют трех вещей:
Процесс управления проблемами, который превращает повторяющиеся инциденты в известные ошибки с описанными обходными решениями.
Метрики DORA, которые показывают реальную картину стабильности и помогают принимать решения на основе данных, а не предположений.
Интеграция между SDLC и ITSM, которая связывает задачи разработки с инцидентами в эксплуатации.
Когда эти элементы работают вместе, частые релизы действительно ускоряют развитие продукта, а не стопорят.
А сталкивались ли вы с ростом инцидентов после ускорения релизов?
