Высокий балл за «релизоспособность» (releasability) означает стабильно высокое качество работы, быстрое обнаружение и разрешение инцидентов, быстрые обратную связь и восстановление, пишет на портале The New Stack Мэнди Уоллс, DevOps-специалист компании PagerDuty.

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

Очень эффективную схему измерения того, как эти изменения влияют на производительность, предлагает DevOps Research and Assessment (DORA) — долгосрочная исследовательская программа, которая «стремится понять возможности, определяющие производительность доставки ПО и операций».

Одним из показателей производительности, который выделяется в этой системе, является «релизоспособность». Этот показатель делает основной акцент на том, чтобы команды разработчиков ПО всегда могли выйти на рынок со своими продуктами, и выступает в качестве конкретного измерения эффективности конвейера непрерывной доставки (CD) компании.

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

Основные метрики DORA для непрерывной доставки

В рамках системы DORA существует широкий спектр показателей, которые можно измерить, а также оценить влияние, которое они оказывают на эффективность разработки ПО в организации. Этими показателями могут быть технические возможности и процессы — такие как искусственный интеллект, непрерывная интеграция (CI) или скорость проверки кода — или показатели, которые могут быть более тесно связаны с производительностью.

Эта вторая группа жизненно важна для измерения производительности CD. Две ключевые метрики в этой группе — стабильность и пропускная способность. Первый показатель характеризует частоту отказов организации в проведении изменений и время восстановления после этих отказов, а второй измеряет время подготовки к любым изменениям и частоту этих изменений. Вместе они дают представление об успехах организации в разработке ПО, а также о времени, которое требуется для восстановления после неудачных изменений. Поскольку организации стремятся к золотому стандарту CD, понимание их работы, особенно в случае неудачных изменений, имеет жизненно важное значение.

Понять, почему ваш продукт сломался

В контексте CD разработчики должны уметь легко и быстро понять, почему продукт или обновление вышли из строя. Учитывая, что от 50 до 80% обновлений ПО выходят из строя, разработчики должны иметь возможность быстро определить точную причину сбоя и устранить ее. Сокращение времени разрешения инцидентов — или исправления ошибок — является одним из существенных преимуществ постоянной работы разработчиков над метрикой релизоспособности. Это означает, что при возникновении проблем их легко устранить, а циклы восстановления проходят быстро.

Чтобы соответствовать все более быстро меняющимся целям разработки, разработчикам необходимо найти способы сократить время, которое они тратят на реагирование на инциденты и устранение неполадок. Для этого им необходим доступ к инсайтам реального времени, которые позволят им выявлять, диагностировать и устранять любые инциденты по мере их возникновения. Эти инсайты могут дать разработчикам мгновенное и ясное понимание того, как изменения влияют на их конвейеры разработки ПО, даже если изменения могут быть недостаточно значительными, чтобы вызвать инцидент.

Эти «события изменений» (change events) представляют собой «хлебные крошки», по которым можно проследить каждое изменение, внесенное в продукт на протяжении всего цикла его разработки, что позволяет разработчикам увидеть непосредственные последствия каждого обновления. Это касается как развертывания кода приложения, так и того, как увеличение или уменьшение масштаба сервиса может повлиять на его производительность. Возможно, наиболее полезно то, что они доступны не только в течение всего цикла разработки продукта, но и после его выхода на рынок. Это позволяет реагировать на любые инциденты и падения производительности сразу же после их возникновения.

Корреляция изменений: ключ к непрерывной и качественной доставке

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

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

Преимущества понимания изменений

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