Я несколько раз тратил дни на отладку основных причин

Первоначально опубликовано @

Способность отлаживать и устранять неполадки не только экономит время, но и обеспечивает качество и стабильность конечного продукта, поэтому навыки кодирования — не единственные определяющие критерии эффективного разработчика/инженера.

Я работаю разработчиком Dot Net уже более 8 лет, и я не буду лгать, что мне снились проблемы с приложениями, которые беспокоили меня во время моей работы. Я несколько раз проводил дни в поисках первопричин и исправлений проблем, которые появлялись в моей корзине. Сегодня я буду описывать одну такую ​​страшную проблему в рамках продолжающегося #DebuggingFeb на Hashnode.

Это было корпоративное приложение в области страхования, созданное с использованием DotNet MVC и SQL-сервера. Приложение уже было в производстве с кучей пользователей, и я присоединился к команде не более 6 месяцев назад и в тот момент работал над новым модулем.

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

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

Затем я получил несколько CSV-файлов, которые фактические пользователи загрузили в prod, и попробовал с ними, и это снова сработало во всех трех средах.

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

Когда я не мог придумать ничего другого, я подумал, что, может быть, пользователи делают что-то не так. Поскольку они базировались в США, я попросил службу поддержки позвонить нескольким из них и записать на экран, как они пытаются выполнить задание.

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

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

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

Они быстро ответили, что на прошлой неделе в двух из них было установлено исправление безопасности, и оба сервера также были перезапущены.

Теперь я был совершенно уверен, что нахожусь на правильном пути, но все же у меня не было исправления или основной причины. Далее нужно было выяснить, какой сервер вызывает проблему.

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

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

Просто запуск службы сделал свое дело, и он снова заработал. Мне просто нужно было щелкнуть правой кнопкой мыши на сервисе и нажать «Пуск». Это было исправлением проблемы, которую я пытался выяснить уже более 2 дней.

Мне пришлось отправить электронное письмо в RCA по поводу этой проблемы, и именно тогда я узнал, что команда QA была проинформирована о таких действиях командой Infra на сервере, и они использовали тестирование дыма после перезапуска.

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

Их попросили обновить свои тестовые примеры, чтобы протестировать отдельные серверы, публикующие такие обновления.

Я понял, что прежде чем копаться в коде и часами искать исправление, я должен подумать об очевидных причинах чего-то такого прерывистого и случайного.

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

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