Такого понятия, как идеальный программный продукт, не существует. Независимо от того, насколько стабильно работает ваше приложение, в процессе эксплуатации обязательно возникнут ситуации, когда что-то пойдет не так. Джесси Ван Херк, руководитель по инжинирингу продуктов Jobber, рассказывает на портале eWeek о том, какие шаги (основные и вспомогательные) нужно предпринять, чтобы провести разбор инцидента и извлечь из него уроки.

Чтобы извлечь максимальный урок из каждого инцидента, очень важно, чтобы инженерные команды регулярно проводили ретроспективный анализ ПО (post-mortem software investigation) и делали соответствующие выводы. Это особенно важно в условиях роста компаний и перехода команд на удаленную работу.

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

Основные шаги

Хотя универсального решения для каждой команды не существует, есть несколько основных шагов, которые следует предпринять, чтобы снизить число инцидентов и оптимизировать устранение проблем с ПО:

  • собирайте данные во время инцидента. Важно собрать воедино как можно больше данных о ходе инцидента. Сюда входят серверные графики, фрагменты журналов и скриншоты, показывающие, что происходило в тот или иной момент времени. Не все эти данные могут оказаться полезными, но они пригодятся, когда вы начнете детально разбирать инцидент;
  • сразу же начните расследование. Обяжите одного из разработчиков/менеджеров взять на себя роль ведущего следователя, который будет отвечать за проведение расследования, ретроспективное документирование и проведение дебрифинга («разбор полетов»). Если начать расследование сразу, ничего не будет упущено;
  • проанализируйте результаты в течение недели. Пока все еще свежо, проведите дебрифинг, чтобы проанализировать накопившуюся за время расследования информацию, обсудить порядок действий и внести необходимые изменения. Это может быть 30-60-минутная видеосессия с участием команды, участвовавшей в инциденте, а также представителей других отделов, которых это касается (в первую очередь, службы поддержки клиентов);
  • поделитесь результатами. Как только дебрифинг будет завершен, разместите его результаты в доступном для всей компании месте для обеспечения прозрачности — инциденты не должны быть скрыты.

Дополнительные меры

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

  • не упускайте из виду асинхронность. Планирование дебрифинга в более сжатые сроки означает, что найти для него место в календаре каждого члена команды будет сложнее. Вместо того чтобы отодвигать встречу все дальше и дальше, выполняйте бóльшую часть работы асинхронно. Убедитесь, что итоговый документ об инциденте отражает все мнения, и используйте самые быстрые каналы связи, чтобы попросить людей внести в него свой вклад. Также рассмотрите возможность записи обсуждения (это легко сделать с помощью Zoom), чтобы все, кто не смог присутствовать, смогли посмотреть его позже, и никто не беспокоился о том, что пропустил встречу;
  • не затягивайте расследование. Важно сократить сроки проведения расследования. Сбор данных на ранней стадии позволяет избежать сразу нескольких текущих расследований и дает возможность всем участникам быстрее вернуться к работе в спринте;
  • упростите шаблон документа об инциденте. Рассмотрите возможность упрощения шаблона, чтобы в нем было меньше разделов, и сделайте каждый из них максимально простым для заполнения. Для того чтобы документ был полным, он должен включать следующие разделы:
    • воздействие и масштаб;
    • триггер (что послужило началом инцидента);
    • решение (что в итоге помогло исправить ситуацию);
    • хронология событий;
    • корневая причина;
    • что прошло хорошо;
    • что не прошло успешно;
    • пункты действий;
    • данные и анализ (все графики);
  • сразу же обратитесь за помощью к командам, работающим с клиентами. Эти команды всегда вносят большой вклад и могут помочь ускорить расследование. Обращайтесь к ним заблаговременно, чтобы успеть внести их вклад в итоговый документ до дебрифинга. Не следует ждать подведения итогов;
  • отслеживайте выполнение пунктов действий в бэклогах. Зачем отслеживать ход выполнения пунктов действий в документе об инциденте, если уже есть стандартный инструмент для отслеживания работы? Получите все пункты действий, как только сможете, чтобы их можно было сверить с бэклогами и не потерять. Также полезно иметь автоматические отчеты, которые отражают список невыполненных действий;
  • создайте секцию для «вещей, которые мы должны сделать, если у нас будет время». Понятно, что не все пункты действий реально выполнимы — некоторые из них являются скорее желанием или тем, что каждый должен иметь в виду. Чтобы пункты действий были более четкими, включите в эту секцию то, что вы считаете важным, но не можете превратить в порученную/отслеживаемую работу. Лучше иметь небольшой набор пунктов действий, которые вы действительно выполняете, чем огромный список того, что вы хотели бы сделать, будь у вас время;
  • сохраняйте спокойствие. Это скорее призыв, но о нем нужно напомнить! Интересуйтесь тем, что произошло, и сосредоточьтесь на том, что вы собираетесь делать, чтобы исправить ситуацию, а не ищите виновных.

Удаленная работа и быстрый темп разработки не обязательно должны усложнять инциденты. Следуя перечисленным выше лучшим практикам, инженеры-программисты и менеджеры команд смогут извлечь максимум пользы из расследования инцидента и сосредоточиться на главном: извлечь из него уроки и улучшить ситуацию в будущем.