Команда может выпустить релиз в срок, потратив на него вечера и выходные, а затем получить следующий план с такими же сроками. Со стороны всё выглядит как нормальная работа, хотя ошибки в оценке задач просто закрыли личным временем разработчиков. Разберём, как такие инциденты становятся привычным способом выпускать продукт и что проверять в процессах, если перед релизом снова приходится отменять вечер пятницы.Как переработки становятся частью планаРазовый аврал может случиться и в команде с построенными процессами. Проблема начинается, когда работа по ночам превращается в привычный способ закончить задачи к нужной дате. Допустим, требования к проекту изменились, работы стало больше, а срок остался прежним. Команда уже не раз справлялась в таких условиях, поэтому и сейчас от неё ждут того же. Разработчики задерживаются, доделывают необходимое, выпускают релиз, и на этом история выглядит законченной. Но в ней остаётся вопрос: удалось бы уложиться в срок в пределах рабочего времени?Если на него не ответить, успешный запуск подтвердит только дату выпуска. Переработки, за счёт которых команда справилась, легко потеряются за результатом. В следующий раз снова можно будет назначить срок без запаса на риски и доработки, рассчитывая, что при необходимости разработчики подключатся вечером. Личное время постепенно становится ресурсом, которым закрывают ошибки в расчётах. Поэтому при разборе прошедшего релиза стоит обсуждать и то, что потребовалось для его выпуска: как менялись требования, какие работы не попали в план и какую часть пришлось доделывать за пределами рабочего дня.Почему ночное спасение замечают, а профилактику нетУ аварии есть заметный сюжет: сервис не работает, команда ищет причину, кто-то находит решение и всё восстанавливает. Легко увидеть, кому сказать спасибо. У профилактики такого сюжета может не быть: разработчик настроил мониторинг, заметил риск и устранил его до того, как произошёл сбой. Остальные могли вообще не узнать, что система была близка к проблеме. Если компания регулярно отмечает только ночные спасения, именно они становятся заметным доказательством пользы сотрудника. Работа, благодаря которой аварии не случилось, получает меньше внимания, хотя она тоже повлияла на результат.Так закрепляется культура героизма. Команда видит, что готовность срочно подключиться и восстановить сервис ценят, а работу над предупреждением сбоев можно отложить. Самого спасения это не обесценивает: если сервис уже сломан, его действительно нужно восстановить. Но после инцидента стоит замечать и изменения, которые снижают вероятность повторения. Иначе у команды будет всё больше поводов благодарить друг друга за ночную работу, а тесты, мониторинг и другие способы предупредить следующий сбой продолжат ждать своего времени.Что происходит, когда без одного человека нельзя выпустить релизЕщё один признак проблемы: перед изменениями в конкретной системе нужно убедиться, что определённый сотрудник на связи. Один разработчик разбирается в старом модуле, один DevOps умеет восстановить инфраструктуру сервиса, и без них выпускать обновление страшно. Эти люди могут действительно хорошо знать систему, но вместе с их экспертизой у компании появляется зависимость. Возможность выпустить изменение или устранить сбой оказывается связана с доступностью конкретного человека. Для самого сотрудника это означает, что отпуск и выходные не всегда позволяют отключиться от работы.Такую зависимость легко принять как данность: сложную систему кто-то должен хорошо знать. Вопрос в том, почему при проблеме помочь может только этот человек. Если каждый серьёзный сбой заканчивается поиском одного и того же разработчика, это стоит включить в разбор наравне с тестами и откатом. Быстро восстановленный сервис ещё не означает, что команда сможет повторить восстановление без его участия. Поэтому при оценке результата полезно выяснить и то, какая часть работы потребовала знаний, сосредоточенных у одного сотрудника.Как аврал готовит следующий сбойКогда сервис нужно срочно восстановить или релиз уже пора выпускать, команда ограничена во времени. В этих условиях проще согласиться на решение, которое прямо сейчас возвращает работоспособность: отложить полноценное ревью, пропустить часть тестов, поставить временное исправление. Продукт снова работает, но причина проблемы может остаться. Такое исправление увеличивает технический долг и оставляет системе больше возможностей сломаться при следующих изменениях. Получается повторяющаяся цепочка: слабые процессы доводят команду до аврала, спешка заставляет срезать проверки, а принятые решения приближают новый инцидент.Для людей этот режим тоже не проходит бесследно. Постоянные переработки могут закончиться выгоранием, снижением продуктивности и уходом из компании. Готовность один раз помочь с аварией не означает, что сотрудник сможет жить так перед каждым запуском. Когда к ночной работе добавляется необходимость отвечать в отпуске и на выходных, у человека становится меньше возможностей отключиться от проекта. В результате компания рискует и качеством продукта, и составом команды, и репутацией работодателя. Поэтому обсуждать постоянные авралы стоит как проблему организации работы, которую одной вовлечённостью сотрудников не решить.Что проверить после очередного инцидентаЭксперты Centicore Group предлагают разбирать инцидент через вопросы к тестам, мониторингу, откату и распределению знаний в команде. Почему тесты пропустили ошибку, пользователи сообщили о сбое раньше системы мониторинга, а изменение нельзя было быстро откатить? Что мешало восстановлению и почему заняться им мог только один сотрудник? Ответы позволяют перейти от исправленной строки к конкретным изменениям в процессах и понять, что именно нужно подготовить к следующему выпуску.Причины могут находиться на разных уровнях. В управлении это нереалистичный срок, меняющиеся требования и отсутствие времени на риски. В инженерных процессах стоит проверить автоматические тесты, размер релизов, ручную сборку и возможность безопасного отката. Отдельно остаются технический долг, слабый мониторинг и критичные знания, сосредоточенные у отдельных сотрудников. Задача разбора в том, чтобы установить связь между этими условиями и произошедшим сбоем. Тогда будет понятно, почему очередное исправление кода само по себе не закрывает проблему и какая работа должна последовать за восстановлением сервиса.Что менять по результатам разбораЕсли проблемы связаны с крупными релизами, в которых одновременно меняется множество компонентов, стоит разбивать их на небольшие обновления. Их проще проверять и постепенно выводить в продакшен, а при сбое проще найти источник и ограничить масштаб последствий. Вместе с выпуском изменений нужно предусмотреть и возврат к стабильной версии. Это особенно заметно там, где восстановление сейчас занимает часы и требует ручного вмешательства. Возможность быстро откатить изменение должна быть частью подготовки к выпуску, иначе при аварии команда снова окажется перед необходимостью чинить систему на ходу.Если ошибки регулярно доходят до релиза, разбор должен возвращаться к автоматическому тестированию: какие проблемы проходят мимо проверок и что нужно изменить, чтобы обнаруживать их раньше. Когда же о сбое первыми сообщают пользователи, стоит разбираться с мониторингом. В обоих случаях полезно опираться на произошедший инцидент, чтобы понимать, какую проблему решает очередная доработка. Наличие тестов или мониторинга само по себе ещё не объясняет, почему конкретную ошибку пропустили. Разбор нужен как раз для того, чтобы связать наблюдавшийся сбой с проверками и сигналами, которых команде не хватило.Если аврал начинается с нереалистичного плана, техническими изменениями вопрос не закрыть. В сроках нужно учитывать риски и доработки, а при изменении требований пересматривать объём работ и возможность переноса дедлайна. Иначе команда снова получит задачу, которую раньше удавалось закончить только за счёт личного времени. По этой же причине запрет работать после 19:00 сам по себе не устраняет авралы. Требования, сроки и причины сбоев останутся прежними, а привычный способ закрывать разницу между планом и реальностью исчезнет. Изменять нужно условия, из-за которых работа регулярно не помещается в отведённое время.Итого: учитывайте работу, которая предотвращает сбоиБлагодарить человека, который ночью восстановил сервис, нормально. Вместе с этим стоит замечать работу над тестами, мониторингом, откатом и планированием, благодаря которой следующее изменение пройдёт спокойнее. После инцидента полезно обсуждать, какие его причины удалось устранить и какие доработки ещё нужны команде. Если изменился только сломанный код, а выпуск по-прежнему держится на переработках и доступности одного сотрудника, разбор ещё не дал результата для процессов. В следующий план должна попасть конкретная работа с обнаруженной причиной: проверками, восстановлением, размером релизов или сроками. Именно по этим изменениям можно понять, что команда сделала после ночного спасения.