Все мы любим кодить.

Когда мы думаем о кодировании, мы обычно представляем, что строим.

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

Но романтические образы в нашей голове часто не воплощаются в жизнь.

Разработчики программного обеспечения тратят большую часть своего времени не только на создание, но и на другие задачи. Они посещают собрания, обсуждают спецификации, планируют и приводят в порядок существующий код. И, конечно же, их любимое занятие - исправление ошибок.

Я еще не встречал разработчика, который любит находить проблемы в своей кодовой базе. Но это разочарование, вероятно, связано с тем, что поиск и воспроизведение ошибок занимает много времени.

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

Какой браузер и версию вы используете? Какая ОС? Вы можете сказать мне, где именно вы нажали? Вот что случилось потом? На какой странице вы были раньше? Как вы вообще попали на этот экран?

Так много вопросов, так мало (полезных) ответов.

Отладка проблемы может занять вечность!

Полагаться на то, что пользователи сообщают о проблемах

Многие группы разработчиков программного обеспечения по-прежнему полагаются на то, что пользователи сообщают о проблемах с их приложениями.

Что в наши дни просто безумие.

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

Но они никогда не вернутся.

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

Разработчики будут тратить больше времени на устранение проблемы, используя небольшие фрагменты информации, чем на ее устранение. В том случае, если они вообще смогут найти проблему.

Ваше программное обеспечение не так хорошо, как вы думаете

Я разговаривал со своим другом, который работает в большом интернет-магазине. Он объяснил мне, как они обнаружили в своей системе онлайн-заказов большую проблему, о которой никто не знал.

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

То, что они обнаружили, вызывало тревогу.

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

Каждый восьмой сеанс оформления заказа был прерван.

Обнаружение и устранение этой проблемы привело к немедленному росту продаж на 20 000 долларов в месяц! Люди больше не сталкивались с проблемами в процессе покупки.

По их оценкам, это затронуло более 5000 пользователей, но они получили только два запроса в службу поддержки по этому поводу.

Хотя команда была счастлива найти проблему, было также сокрушительное разочарование. Неопознанная ошибка, вероятно, привела к упущенному доходу на сумму более 100 000 долларов США.

Отправлять себе электронное письмо при возникновении ошибок - глупая идея

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

Пока вы этого не сделаете.

Если вы настроите это, это может выглядеть так:

public void TryProcessLineNumber(int lineNumber)
{
    try
    {
        ProcessLineNumber(lineNumber);
    }
    catch (Exception ex)
    {
        LetMyselfKnowViaEmail("Something went wrong: " + ex.Message);
    }
}

Но остерегайтесь проблем, которые он может создать.

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

  • Детали диагностики ограничены
  • Сложно настроить правила уведомлений, и все становится шумно
  • Исключение, попавшее в бесконечный цикл, может отправить 50 000 писем на ваш почтовый ящик за ночь.
  • Ошибки не имеют уровня приоритета и не влияют на видимость, и все они выглядят одинаково.
  • Получив более сотни писем, вы перестаете их читать.

Вскоре после того, как вы начнете присылать себе ошибки по электронной почте, вы начнете их игнорировать. Или вы фильтруете их в папку, потому что там очень много шума и нет сигнала.

Вам осталось просмотреть тысячи электронных писем в поисках правильного экземпляра ошибки.

Нам нужно что-то умнее.

ELMAH - регистрация ваших исключений

ELMAH (Модули регистрации ошибок и обработчики) - это полностью подключаемая функция регистрации ошибок в масштабе всего приложения. Его можно динамически добавлять к работающему веб-приложению ASP.NET или даже ко всем веб-приложениям ASP.NET на машине без какой-либо перекомпиляции или повторного развертывания.

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

ELMAH - это, по сути, пакет NuGet для веб-приложений .NET. Он регистрирует каждое исключение, возникающее на одном или нескольких веб-сайтах, в выбранном вами хранилище. В отличие от других фреймворков ведения журнала, ELMAH автоматически регистрируется в каждом исключении при настройке в его простейшей форме. Конечно, есть API, который можно использовать для регистрации пользовательских ошибок. Но большинство людей используют только автоматическую часть. В этом уроке мы сосредоточимся только на основных частях.

Вот отличный урок о том, как начать.

Специальные инструменты для отчетов об ошибках и сбоях

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

Это всего лишь несколько строк кода.

Использование подобного инструмента позволяет:

  • Избавьтесь от шумных исключений и сосредоточьтесь на важных вещах, например на влиянии на пользователей.
  • Настройте настраиваемые уведомления по электронной почте, Slack или HipChat
  • Используйте один инструмент для отслеживания нескольких языков и платформ
  • Воспользуйтесь группировкой ошибок для похожих ошибок
  • Держите всю команду в курсе ошибок и их решения

Подобные инструменты недешевы или бесплатны, как другие программы, которые мы обсуждали, но какова цена вашего времени? Скажем, вы используете бесплатное решение. Затем вы должны прекратить кодирование на три часа, пока вы пытаетесь воспроизвести ошибку. На самом деле это очень низкая окупаемость инвестиций.

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

Даже если вы считаете, что ваш код идеален и у пользователей нет проблем, подключите такой инструмент, как Raygun. Вы будете удивлены тем, что найдете.

Проактивный подход и пожинайте плоды

Мы все хотели бы, чтобы технологии автоматически устраняли проблемы с программным обеспечением. К сожалению, я думаю, что нам еще далеко до самовосстановления и самосознания.

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

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

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

Сосредоточьте внимание на своей команде при обработке ошибок и сбоев в ваших собственных приложениях. Выявляйте проблемы раньше пользователей и не полагайтесь на них в сообщениях об ошибках.

Потому что они этого не сделают.