Дело о пропаже денег: как я использовал навыки детектива, чтобы отследить баг в приложении 🔍
11 января 2023 г.Как разработчик Android, работающий над популярным приложением для денежных переводов, поддерживающим более 100 тысяч пользователей, я должен обеспечить бесперебойную работу приложения и оперативное решение всех выявленных проблем. Я привык к случайным обращениям в службу поддержки от пользователей, сообщающих о проблемах с приложением. Но однажды я получил кучу билетов от людей, которые не смогли отправить деньги в определенный регион через приложение. Это было особенно тревожно, потому что это было близко к сезону праздников, когда многие люди полагаются на наше приложение, чтобы отправлять деньги своим близким.
Я знал, что должен добраться до сути этого вопроса как можно быстрее. Поэтому я обратился к мудрости Шерлока Холмса и начал свою детективную деятельность. Но, как я вскоре узнал, решить эту проблему будет непросто. Потребовались все мои детективные навыки, а также немного удачи, чтобы отследить основную причину ошибки и восстановить нормальную работу приложения.
Настройка
Я начал с того, что воспроизвел проблему на своем устройстве, пытаясь отправить деньги в пострадавший регион. Конечно же, приложение зависло и отобразило сообщение об ошибке: «Транзакция не удалась. Повторите попытку позже». Я попытался использовать профилировщик в Android Studio, чтобы проверить, не возникли ли проблемы с производительностью, которые могли быть причиной проблемы. Никаких кубиков; приложение работало должным образом.
Я быстро проверил журналы, чтобы увидеть, есть ли там какая-либо информация, которая могла бы помочь мне понять, что происходит. К сожалению, журналы не очень помогли. Они показали, что приложение делало обычные сетевые запросы, но не было никаких указаний на то, что вызвало проблему. Однако казалось, что ошибка будет возникать каждый раз, когда мы пытаемся сделать запрос POST к конечной точке transactions, но только для этого конкретного региона. Казалось, что бы я ни пытался; Я не мог приблизиться к разгадке тайны.
Затем я вытащил последний код и проверил производственную ветку, чтобы узнать, могут ли какие-либо недавние коммиты иметь отношение к рассматриваемой проблеме. Я также пробовал делать отдельные запросы с помощью Postman и заметил кое-что странное. Запрос вернул код ответа 400, что означает неверный запрос; обычно это означает, что клиент не отправляет всю информацию, требуемую серверной частью. Однако ему не удалось вернуть осмысленную ошибку с подробным описанием того, какие данные отсутствовали в запросе. Учитывая, что этот запрос работал раньше, казалось, что проблема была на стороне сервера.
Чтобы проверить эту теорию, я использовал отладчик, чтобы углубиться в код. Я установил точки останова в ключевых точках кода и снова попытался отправить транзакцию, на этот раз внимательно следя за тем, что происходит под капотом. Я проверил, содержит ли запрос все необходимые данные, которые требуются серверной части, и даже вывел из системы запрос и ответ. Увы, все было так, как и ожидалось, но я все еще получал ошибку Bad request.
Сюжет сгущается
Продолжив расследование, я не мог отделаться от ощущения, что что-то упускаю. Казалось, должно быть очевидное объяснение проблемы, но сколько я ни искал, я не мог его найти. Мне хотелось насмехаться над собой, над моим собственным Мориарти, над неразгаданной ошибкой.
Когда я уже начал терять надежду, у меня появилась идея. Я вспомнил, что за две недели до того, как возникла проблема, команда бэкенда выпустила обновление серверного кода приложения. Возможно, проблема была вызвана обновлением?
Я связался с бэкэнд-разработчиками в Slack, чтобы узнать, есть ли у них понимание проблемы. Они сказали мне, что недавно выпустили обновление кода на стороне сервера, но не были уверены, может ли оно быть связано с проблемой, с которой я столкнулся. В настоящее время они были заняты исправлением другой проблемы и смогли изучить мою только позже. Они упомянули, что обновление развертывалось постепенно, и сначала его получил лишь небольшой процент пользователей. В соответствии с новой политикой наши развертывания теперь были поэтапными, и пользователи получали их в течение двух недель. Возможно ли, что обновление вызвало проблему только у пользователей, которые его получили?
Момент лампочки
Я быстро проверил свои журналы аварийного срабатывания firebase, чтобы увидеть, есть ли связь между временем обновления и временем пользователи начали сталкиваться с проблемой. И действительно, я нашел подсказку!
Пообщавшись с командой, моя теория подтвердилась. Обновление включало изменение способа обработки сервером определенных типов транзакций. И оказалось, что это изменение вызывало проблемы именно с транзакциями в затронутом регионе. После дальнейшего изучения я обнаружил, что серверная часть теперь требует включения в запросы транзакций дополнительного поля, которое ранее было необязательным. Это изменение было внесено из-за новых правил в регионе, но, к сожалению, оно было сделано в спешке, плохо задокументировано и не было тщательно протестировано. В результате это поле не было включено в запросы транзакций для затронутого региона, что привело к сбою транзакций.
Я не мог в это поверить. После всей моей детективной работы я, наконец, нашел основную причину ошибки. Потребовалось много шерлоковской дедукции и некоторого творческого мышления, но я, наконец, раскрыл дело о пропаже денег.
Я немедленно связался с бэкэнд-командой, чтобы сообщить им, что я обнаружил. Они были потрясены, узнав, что их обновление вызвало проблему, и извинились за оплошность. Мы договорились о двустороннем решении. Бэкенд-команда выпустит исправление со значением по умолчанию для теперь обязательного поля, что позволит пользователям выполнять транзакции, в то время как команда мобильного приложения выпустит обновленную версию нашего приложения для Android, которое будет запрашивать эту дополнительную информацию.
Заключение
Устранение этой ошибки было сложным и полезным опытом. Это напомнило мне о важности творческого мышления и не бояться пробовать разные подходы при отладке проблемы. И точно так же, как прочная связь между Шерлоком и Ватсоном, это также напомнило мне о силе сотрудничества и командной работы — без помощи бэкэнд-команды я, возможно, никогда не смог бы решить эту проблему.
Я надеюсь, что эта история моей детективной работы послужит напоминанием другим разработчикам о том, что нужно всегда искать подсказки и никогда не отказываться от решения сложной проблемы. Как однажды сказал Шерлок Холмс: «Как только вы исключите невозможное, все, что останется, каким бы невероятным оно ни было, должно быть правдой». Имея это в виду, я знаю, что любую ошибку можно победить, какой бы хитрой она ни казалась на первый взгляд.
Оригинал