Войдите в Cloud Native Dojo: отладка на уровне черного пояса

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

В своей книге «[Почему программы терпят неудачу — руководство по системной отладке] (https://www.amazon.com/Why-Programs-Fail-Systematic-Debugging/dp/0123745152)» Андреас Целлер рассказал историю из своей молодежь работает в компьютерном магазине. Покупатель зашел в магазин с новым компьютером Commodore 64. Для контекста: тогда компьютеры загружались непосредственно в базовый интерпретатор; basic будет принимать номера строк в качестве первого аргумента. Он попытался ввести эту действительную базовую строку:

```базовый

10 принт «Привет, мир»

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

При отладке и программировании в целом нам нужно разбивать проблему на более мелкие компоненты. Итак, он напечатал:

Пустое заявление.

Оказалось, что пользователь привык к пишущим машинкам, где он печатал строчную букву L и букву O, чтобы набирать цифры один и ноль. Он следовал той же практике на компьютере и просто набирал «lo».

Когда я прочитал эту историю, я громко рассмеялся, но я также подумал: это история не об отладке. Но это так, отладка — это неожиданное. Речь идет о сужении (или нарезке) проблемы до тех пор, пока у нас не будет чистой проблемы, которую мы сможем наблюдать. В этот момент решение представляется нам.

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

1. Отладка полиглота

1. Отладка невоспроизводимого

1. Загрязнение данных

Отладка полиглота

Это не новая проблема. Как человек, который зарабатывал себе на жизнь созданием JVM, я время от времени проводил «мета-отладку»: отлаживал поддержку отладки для JVM. Это заставило меня переключиться между Java и нативным кодом, при этом оба отладчика работали и выполнялись пошагово.

Этого следует ожидать при создании низкоуровневого кода виртуальной машины. Но это то, что становится все более распространенным по всем направлениям. Сервер может быть написан на Python или Java с интерфейсом JavaScript. Мы можем отслеживать проблему через внешний отладчик вплоть до серверной части.

Точно так же при развертывании микрослужбы каждая служба может быть реализована на другом языке. Теоретически мы можем протестировать все по отдельности. На практике это просто нереально. Баги случаются. По своему определению они неожиданны.

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

[Удаленная отладка проблематична, рискованна] (https://talktotheduck.dev/psa-the-risks-of-remote-jdwp-debugging) и не может масштабироваться для сложных развертываний. Поэтому многие разработчики ограничиваются ведением журналов и, возможно, некоторыми инструментами наблюдения. Хотя это может помочь с некоторыми проблемами, это плохая замена локальной отладке. Инструменты непрерывного наблюдения дают нам возможность выйти за рамки простого мониторинга. Мы можем получить отладку на уровне исходного кода, аналогичную традиционным отладчикам на рабочих серверах.

Отладка невоспроизводимого

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

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

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

Загрязнение данных

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

Загрязнение данных коварно. Его невероятно сложно отлаживать и невероятно сложно исправить постфактум, поскольку исправления кода недостаточно.

Так что же такое ошибка загрязнения данных?

Это ошибка, которая приводит к неверным данным. Само по себе это не большая проблема… Проблема в том, что эти данные распространяются, возможно, между микросервисами и в базу данных. В этот момент это становится огромной проблемой. Плохие данные — это проблема, но ошибка, вызвавшая ее, может быть где угодно, даже на другом сервере. Это как искать иголку в стоге сена. Эти ошибки особенно коварны, так как они часто возникают только в продакшене, и устранение их может быть хуже, чем сама проблема.

Хорошим примером этого является «undefined», который загрязняет базы данных повсюду, поскольку он распространяется из плохого кода JavaScript и каким-то образом проникает в базы данных. Как правило, их отлаживают постфактум, помещая журнал стека в то место, где записываются или отправляются данные. Используйте там условие, чтобы убедиться, что это действительно недопустимые данные, и обнаружить это нарушение.

Это можно сделать с помощью кода, а также с помощью инструментов непрерывного наблюдения, таких как [Lightrun] (https://lightrun.com/).

TL;DR

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

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

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

Первоначально опубликовано в [The New Stack] (https://thenewstack.io/enter-the-cloud-native-dojo-blackbelt-level-debugging/).