Лучшие практики устранения проблем с ПО

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

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

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

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

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

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

• не упускайте из виду асинхронность. Планирование дебрифинга в более сжатые сроки означает, что найти для него место в календаре каждого члена команды будет сложнее. Вместо того чтобы отодвигать встречу все дальше и дальше, выполняйте бóльшую часть работы асинхронно. Убедитесь, что итоговый документ об инциденте отражает все мнения, и используйте самые быстрые каналы связи, чтобы попросить людей внести в него свой вклад. Также рассмотрите возможность записи обсуждения (это легко сделать с помощью Zoom), чтобы все, кто не смог присутствовать, смогли посмотреть его позже, и никто не беспокоился о том, что пропустил встречу;
• не затягивайтерасследование. Важно сократить сроки проведения расследования. Сбор данных на ранней стадии позволяет избежать сразу нескольких текущих расследований и дает возможность всем участникам быстрее вернуться к работе в спринте;
• упростите шаблон документа об инциденте. Рассмотрите возможность упрощения шаблона, чтобы в нем было меньше разделов, и сделайте каждый из них максимально простым для заполнения. Для того чтобы документ был полным, он должен включать следующие разделы:
  • воздействие и масштаб;
  • триггер (что послужило началом инцидента);
  • решение (что в итоге помогло исправить ситуацию);
  • хронология событий;
  • корневая причина;
  • что прошло хорошо;
  • что не прошло успешно;
  • пункты действий;
  • данные и анализ (все графики);

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

  📎📎📎📎📎📎📎📎📎📎