Мы рассмотрели наиболее трудоемкие задачи для разработчиков. Оказывается, в среднем более 25% их времени уходит на устранение неполадок.
На устранение производственных ошибок может быть потрачено более одного рабочего дня рабочей недели разработчика. Во многих случаях это даже больше, чем это. Мы постоянно слышим от инженерных команд, что их разработчики тратят в среднем не менее 25% своего времени на решение (или попытки решить) производственных проблем. Это означает, что они посвящают устранению неполадок больше, чем целый день своей рабочей недели.
Откуда берется все это время? И как это получается так быстро?
1. Идентификация произошла ошибка
Первый шаг в решении любой проблемы – это признание того, что она у вас есть в первую очередь. Затем вам, вероятно, следует выяснить, в чем проблема, если вы еще не знаете. Удивительно (или нет ), на самом деле это одна из частей процесса отладки, которая доставляет разработчикам больше всего хлопот.
Как вы сначала выясняете, что что-то работает неправильно?
От людей, с которыми мы разговаривали, мы узнали, что в среднем более половины производственных ошибок регистрируются конечными пользователями. Многие из этих компаний полагаются на то, что пользователи оставляют отзывы о 80-90% ошибок.
Сразу же мы знаем, что не рекомендуется полагаться на то, что ваши пользователи сообщат вам, когда у вас возникнет проблема или что что-то работает неправильно. Что еще хуже, вы не хотите иметь проблем, о которых НЕ сообщают пользователи, потому что это будет напрямую связано с низкой удовлетворенностью клиентов и оттоком клиентов.
Проблема с тем, что конечные пользователи сообщают об ошибках, заключается в том, что чаще всего в их отчетах отсутствует важная информация об ошибке. Диалог, если вам посчастливится его провести, отнимает много времени, и между инженерией, поддержкой и контролем качества происходит много переходов туда и обратно, что отнимает огромное количество времени для получения информации для устранения неполадок.
2. Определение серьезности ошибки
Независимо от того, поступает ли ваша информация из отзывов пользователей или отображается в журналах, определение частоты ошибок имеет важное значение для определения того, имеете ли вы дело с критической проблемой или нет. Если ошибка возникает нечасто и не оказывает большого влияния на пользователей, выделение времени на воспроизведение и устранение проблемы может не стоить затрат, когда происходит гораздо больше критических ошибок.
Когда вы полагаетесь на журналы и конечных пользователей, ваши возможности для понимания частоты и серьезности ошибок ограничены. При рассмотрении исключений, зарегистрированных предупреждений или ошибок частота ошибок является ключевым показателем для оценки работоспособности системы в целом. Чтобы определить наиболее важные проблемы, требующие внимания наших разработчиков, мы используем Over Ops для сортировки новых ошибок и их частоты, прежде чем перейти к анализу их первопричин. Некоторые из наших наиболее успешных пользователей применяют подход “Ноль входящих сообщений” к исключениям, как если бы они были электронными письмами, требующими обработки. Вот как они это делают .
3. Поиск уязвимого кода (или просматривая файлы журналов)
Как только ошибка будет выявлена, пришло время найти ее фактическое местоположение в коде и убедиться, что она назначена правильному разработчику. Есть несколько способов сделать это, но наиболее распространенная практика – потратить часы или даже дни на просмотр файлов журналов и поиск подсказок. Помимо того, что это сравнимо с поиском иголки в стоге сена, разработчик, которому поручено решить проблему, может не иметь четкого представления о том, что он или она ищет. Кроме того, необходимая им информация, возможно, вообще не была записана в журналы.
Использование инструментов управления журналами, таких как Splunk или Elk , может помочь устранить шум, но они не могут помочь, если информация, которую вы ищете, никогда не записывалась в журналы с самого начала. В этом случае единственный способ получить необходимую вам информацию – добавить подробность ведения журнала и надеяться, что когда (если!) ошибка повторяется, вы можете видеть, что происходит.
4. Воспроизведение ошибки
Если ваши журналы не дают вам четкого ответа на вопрос, почему произошла ошибка, а это весьма вероятно, следующим шагом будет попытка воспроизвести ее. Кроме того, воспроизведение ошибки до того, как вы попытаетесь ее исправить, является хорошей практикой в любом случае. В конце концов, если вы сначала не воспроизведете проблему, то как вы можете быть уверены, что исправили ее, когда закончите отладку?
К сожалению, из-за расплывчатых отчетов, поступающих от пользователей, и неясных заявлений о регистрации, связанных с ошибкой, поиск точного потока событий, вызвавших ее, занимает много времени и может быть даже невозможным.
Если вам повезет, проблема могла возникнуть в части кода, над которой вы недавно работали, и вы можете легко определить шаги, которые привели к ней. В противном случае наиболее распространенный способ найти поток событий – попробовать разные вещи и понаблюдать за результатами, отправить заявку в отдел контроля качества для дополнительного тестирования, просмотреть журналы или, возможно, добавить дополнительные инструкции для ведения журнала. Чаще всего неудача на этом этапе приводит к закрытию билетов с печально известным… “не удалось воспроизвести”.
5. Вход в “режим боевой комнаты”
Трудно оспорить преимущества работы в обстановке, подобной “боевой комнате”. Это может принести с собой ясность проекта, более тесную коммуникацию и повышение производительности. Итак, возможно, вы подумываете о том, чтобы переставить мебель в своем офисе, чтобы стимулировать инновации и прогресс, или, может быть, ваше приложение вышло из строя по какой-то неизвестной причине, и вам нужно выяснить, почему ПРЯМО СЕЙЧАС.
Если вам повезет, вам, возможно, придется посещать военную комнату только один или два раза в год, когда произойдет что-то катастрофическое. Для других ситуации в военной комнате происходят еженедельно или даже ежедневно. Поскольку так много времени уходит на решение проблем, почти не остается времени для продвижения дорожной карты продукта.
Некоторые разработчики, с которыми мы недавно разговаривали, описали сбор информации для ситуации в военной комнате и все еще не имеют информации для продвижения вперед с решением. Некоторые описывали ситуации в военной комнате, которые длились 5 или 6 дней. Это плохо. Эти ситуации не только отнимают время у остальных ваших рабочих задач, но и могут нанести ущерб репутации и доходам компании.
Лекарство
Наиболее эффективный способ, который мы нашли, сократить время, затрачиваемое вашей командой на отладку, – это автоматизировать процесс устранения ошибок. Это означает автоматизацию не только идентификации ошибок, но, что более важно, автоматизацию анализа первопричин с доступом к полному исходному коду и состоянию переменных во всем стеке вызовов каждой ошибки.
Overtops создал инструмент, который делает именно это. Он не только предоставляет вам источник и полный стек вызовов любого исключения или ошибки, но и показывает точное состояние переменной во время ошибки, поэтому командам больше не нужно тратить бесконечные часы на ее воспроизведение. Посмотрите, как это работает здесь .
Заключительные Мысли
Производственная отладка абсолютно необходима, но позволять ей занимать так много времени – НЕТ! Эти 25% быстро складываются. Это добавляет штатного наемного разработчика на каждые 3, работающих над новыми функциями и проектами. Это безумие!
Пришло время начать автоматизировать процесс отладки производства, чтобы вы могли выйти из боевой комнаты и вернуться к своему отставанию.
Написанный Тали Сорокер , первоначально опубликованный в блоге OverOps.
Оригинал: “https://dev.to/overopshq/5-ways-developers-waste-more-than-20-of-their-work-week-2nm6”