Создание наблюдаемых API на Node.js: логирование, метрики и трейсинг

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

Эндпоинт возвращает ожидаемый ответ.

Запрос к базе данных выполняется корректно.

Система аутентификации работает так, как предусмотрено.

Фронтенд и бэкенд обмениваются данными без проблем.

На этом этапе вы можете предположить, что API готово.

Но со временем возникает другой вопрос:

Что произойдёт, если что-то сломается, а вы в тот момент не смотрите на код?

Запрос терпит неудачу после того, как сервис запущен.

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

Внешний сервис перестаёт отвечать.

Пользователь сообщает вам, что что-то не работает.

Эндпоинт внезапно начинает выдавать ошибки 500.

Сам сервис может всё ещё быть в рабочем состоянии.

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

Именно здесь логгирование и возможность наблюдения перестают быть второстепенными аспектами и становятся ключевой частью процесса создания API.

Написание API, которое работает корректно, — это одна из сложностей.

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

Логгирование — первое, что мне пришлось переосмыслить

Как и у большинства начинающих программистов, первоначальные привычки логгирования обычно связаны с использованием console.log().

Что-то вроде:

console.log("Login request received");
console.log(user);
console.log("Database query completed");

Такой подход хорошо работает при локальной разработке.

Он быстрый.

Он простой.

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

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

Возможно, придётся обрабатывать сотни или тысячи одновременных запросов.

Множество разных пользователей.

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

Фоновые задачи, выполняющиеся параллельно.

Постоянные запросы к базе данных.

Запросы к сторонним сервисам.

Попытки аутентификации, которые проваливаются.

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

Это привело к изменению подхода к восприятию логов.

Запись в журнале не должна просто сообщать:

"Что-то произошло."

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

Полезный лог содержит контекст

Посмотрите на разницу между этими двумя подходами.

Не очень полезно

Something went wrong

По сравнению с:

{
  "level": "error",
  "message": "Database query failed",
  "method": "GET",
  "route": "/api/projects",
  "requestId": "abc123",
  "durationMs": 842
}

Вторая версия сразу предоставляет гораздо более полезную информацию.

Вы можете сразу узнать:

• В чём заключалась фактическая ошибка
• Какая операция её вызвала
• Какой метод HTTP был использован
• Какой маршрут пострадал
• Какой конкретный запрос можно отследить
• Сколько времени заняла выполнение операции

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

Важен наличие контекста.

Структурированный логгинг изменил моё отношение к логам

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

Вместо того чтобы записывать событие в виде простого, свободного текста, например:

User login failed for some reason

Его можно представить в виде структурированных данных:

{
  "level": "warn",
  "event": "login_failed",
  "requestId": "abc123",
  "ip": "example",
  "timestamp": "..."
}

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

Можно выполнять запросы к таким элементам:

level = error

или:

event = login_failed

или:

route = /api/auth/login

Это особенно полезно, когда логи собираются на централизованной платформе для логирования.

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

Не логируйте всё

Это еще одна ловушка, в которую легко попасть.

Во время отладки кажется естественным хотеть больше данных, а не меньше.

В итоге вы начинаете логировать всё, что только можно вспомнить.

Тело запроса.

Тело ответа.

Полный объект пользователя.

Результаты работы базы данных.

Заголовки запроса.

Токены аутентификации.

Детали среды.

Внутренние ошибки объектов.

Вскоре у вас накапливается огромный объем зарегистрированных данных.

Это создает две отдельные проблемы.

Первая заключается в том, что становится сложнее находить действительно важную информацию.

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

Эта вторая проблема заслуживает отдельного раздела.

Никогда не считайте журналы логов безопасным местом для хранения секретов

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

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

Категории данных, требующие особой осторожности:

• Пароли пользователей
• Токены OAuth или bearer, используемые для доступа
• Токены, используемые для обновления сессии
• Ключи, используемые для аутентификации в API

Секреты, связанные с управлением сессиями

Учетные данные, используемые для подключения к базе данных

Куки, используемые для аутентификации сессии

Любые персональные или конфиденциальные данные пользователя

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

console.log(req.headers.authorization);

Это может сэкономить вам несколько минут при устранении ошибки.

Но эти данные могут оставаться в ваших логах долгое время после окончания сессии отладки.

Сама инфраструктура логирования также должна быть защищена.

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

Идентификаторы запросов стали чрезвычайно полезными

Представьте, что клиент отправляет запрос вот так:

POST /api/orders

Этот запрос проходит через несколько уровней:

Client
   ↓
Load Balancer
   ↓
Node.js API
   ↓
Database
   ↓
Payment service

Где-то по пути он терпит неудачу.

Теперь представьте, что каждая строка журнала, связанная с этим запросом, содержит один и тот же идентификатор:

requestId = 7f91...

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

Например:

request started
      ↓
authentication successful
      ↓
database query started
      ↓
database query completed
      ↓
payment request started
      ↓
payment service timeout
      ↓
request failed

Без общего идентификатора запроса эти отдельные записи журнала могут быть трудны для связывания друг с другом.

При наличии такого идентификатора они образуют единую целостную картину вместо разрозненных, несвязанных событий.

Логирование и отладка — это две разные задачи

Со временем разница между ними стала гораздо более очевидной.

При работе локально вы можете добавить что-то очень специфическое просто для проверки значения:

console.log(result);

Это полезно в данный момент, прямо здесь и сейчас.

Но логирование для производственной среды требует другого подхода к проектированию.

Логи для производства должны быть:

• Единообразными

Возможность поиска

Структурированность

Полезность

Безопасность

Умеренный объем

Краткое сообщение для отладки и реальная стратегия наблюдаемости — это не одно и то же.

Уровни логов каждый выполняет свою уникальную функцию

Распространенный подход — определение таких уровней, как:

debug
info
warn
error

Точные названия различаются в зависимости от инструментов и команд.

Но основная концепция остается неизменной.

Отладка

Точная информация, которая в основном актуальна во время активного исследования или устранения проблем в процессе разработки.

Информация

Обычные события, происходящие во время нормальной работы.

Например:

Server started
Request completed
Background job completed

Предупреждение

Произошло нечто необычное, но приложение продолжило работать нормально.

Например:

External service response was slow

Ошибка

Что-то сломалось и требует внимания.

Например:

Database connection failed

Запоминание этих категорий на самом деле не является главной целью.

Важно их последовательное применение.

Коды состояния HTTP также способствуют отслеживанию

Сначала казалось, что коды состояния предназначены исключительно для удобства клиента.

Однако они также служат полезным инструментом для понимания реального поведения вашего API.

Например:

200 → successful request
201 → resource created
400 → invalid request
401 → authentication required/failed
403 → forbidden
404 → resource not found
429 → rate limited
500 → internal server error

Представьте, что на ваших панелях управления внезапно появляется рост:

500 responses

Это признак, требующий дальнейшего расследования.

Или представьте скачок:

429 responses

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

Коды состояния становятся значимыми сигналами, когда их последовательно используют во всем API.

Сообщения об ошибках должны помогать вашей команде, а не злоумышленникам

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

Предположим, произошла ошибка при записи в базу данных.

Внутри системы сырая ошибка может выглядеть примерно так:

unique constraint violation on users_email_key

Это действительно полезно для отладки.

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

Вместо этого ответ API может выглядеть так:

{
  "success": false,
  "message": "The email address is already registered."
}

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

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

Стек-трейсы следует обрабатывать осторожно

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

Но это также может раскрыть внутренние детали того, как построена ваша система.

Вот почему существует значимая разница в подходе к этому вопросу:

Разработка

Здесь полные, подробные отчеты об ошибках действительно бывают полезны.

Продакшн

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

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

Затем появились метрики

Логи отвечают на вопросы вроде:

Что только что произошло?

Метрики отвечают на другой тип вопросов:

Как часто это происходит?

Примеры включают:

Requests per second
Error rate
Response latency
Database connection count
CPU usage
Memory usage

Представьте API, которое обычно отвечает следующим образом:

150 ms

а затем среднее время задержки резко возрастает до:

1200 ms

Даже если каждый запрос по-прежнему возвращает код 200, явно произошли какие-то изменения.

Эти изменения имеют значение.

API не обязательно сломано.

Но оно тоже не ведет себя так, как обычно.

Именно показатели позволяют заметить подобные изменения.

Сами средние значения могут вводить в заблуждение

Это оказалось еще одним важным уроком.

Предположим, ваше API обрабатывает 10 000 запросов.

Большинство из них завершаются за:

100–200 ms

Но небольшое количество из них занимает:

5–10 seconds

Среднее значение по всем запросам может легко скрыть эту группу исключений.

Именно поэтому время задержки часто измеряют с использованием процентилов.

Например:

p50
p95
p99

Грубо говоря:

p50 — что означает типичный запрос.

p95 — что испытывает медленная часть запросов.

p99 — как выглядит самый худший сценарий нагрузки.

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

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

Логи описывают события; метрики показывают тенденции

Это различие оказалось действительно полезным на практике.

Представьте себе:

Metric:
API latency increased

Это говорит вам, что что-то изменилось.

Затем вы проверяете логи и находите:

Database query took 4.8 seconds

Теперь у вас есть правдоподобная причина.

Эти два источника данных дополняют друг друга.

Вы можете представить эту связь так:

Metrics
   ↓
Something looks wrong
   ↓
Logs
   ↓
What happened?
   ↓
Tracing
   ↓
Where did it happen?

Это естественным образом приводит к следующему аспекту наблюдаемости.

Отслеживание запроса от начала до конца

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

Например:

HTTP Request
     │
     ├── Authentication
     │
     ├── Controller
     │
     ├── Service
     │
     ├── Database query
     │
     └── External API

Каждый этап процесса может содержать собственные данные о времени выполнения.

Возможно, окажется, что саму слой API достаточно:

200 ms

в то время как вызов внешнего сервиса потребляет:

4 seconds

Без отслеживания обычно можно увидеть лишь расплывчатую жалобу вроде:

API is slow

После внедрения отслеживания можно задать гораздо более точный вопрос:

Какой именно этап этого запроса вызывает замедление?

Это гораздо более эффективный вопрос для отладки.

Логи, метрики и отслеживание отвечают на разные вопросы

Полезно рассматривать эти три типа данных именно так:

SignalCore questionLogsЧто произошло?MetricsКак часто или в каком объеме?TracesКуда на самом деле ушло время во время запроса?

Между ними есть определенное перекрытие, но ни один из трех не может полностью заменить другой.

Хорошо спроектированная система обычно опирается на все три компонента одновременно.

Покупка инструментов — это не то же самое, что обеспечение возможности наблюдения

Возможно, это самое важное вывод из всего этого процесса.

Легко предположить:

«Как только я установлю инструмент для наблюдения, мое приложение станет поддающимся наблюдению».

На самом деле все не так.

Инструменты хороши в сборе данных.

Но кто-то все равно должен отвечать на вопросы вроде:

• Что именно необходимо измерять?
• Что стоит записывать?
• Какие события имеют значение?
• Что считается ошибкой?

Какие условия оправдывают отправку уведомления?

Какие поля считаются чувствительными?

Как долго следует хранить эти данные?

Как связывать вместе связанные запросы?

Настройка инструментов редко бывает сложной частью.

Сложность заключается в определении того, какая информация действительно важна.

Роль OpenTelemetry

При более глубоком изучении возможностей мониторинга OpenTelemetry постоянно выходил как концепция, достойная понимания.

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

• Трейсы
• Метрики
• Логи

Вместо того чтобы ограничивать подход к мониторингу одним поставщиком услуг, OpenTelemetry предлагает способ сбора и обработки телеметрии, независимый от конкретного поставщика.

Небольшой проект на Node.js, вероятно, с самого начала не нуждается в полноценной платформе для мониторинга.

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

Для телеметрии требуется такая же осторожность в вопросах конфиденциальности, как и для логов

Здесь есть аспект безопасности, который стоит ещё раз подчеркнуть.

Правило, применимое к логам, одинаково важно и для телеметрии:

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

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

• Логи
• Трейсы
• Метрики
• Инструменты отслеживания ошибок
• Панели мониторинга

Хранение всего содержимого HTTP-запроса в трейсе может показаться удобным во время отладки.

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

password
token
personal information
payment information

Внезапно ваша система наблюдаемости превращается в ещё одно место хранения конфиденциальных данных.

Проблемы безопасности касаются не только логов — они затрагивают всю систему наблюдаемости в целом.

Степень подробности должна различаться в зависимости от среды

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

Это часто означает включение более детального логирования.

В производственной среде приоритеты смещаются в сторону:

• Поддержания высокого соотношения полезной информации к шуму
• Нагрузки на производительность
• Рисков для безопасности
• Удобства поиска данных
• Политик хранения
• Функций оповещений

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

Именно поэтому важно настраивать логирование отдельно для каждой среды.

Поведение базы данных требует отдельного внимания

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

Представьте, что этот эндпоинт вдруг начинает отвечать в течение нескольких секунд:

GET /api/projects

Слой приложения может казаться совершенно здоровым.

Однако подлинный запрос может иметь следующие проблемы:

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

Это напрямую связано с ранее упомянутыми аспектами качественного проектирования схем PostgreSQL.

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

Ни один из этих факторов сам по себе недостаточен.

Видимость помогает выявить проблемы типа N+1

Возьмём такой сценарий:

Get 100 projects
       ↓
Get owner for project 1
Get owner for project 2
Get owner for project 3
...
Get owner for project 100

С функциональной точки зрения API может работать нормально.

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

Без способа мониторинга активности базы данных подобные проблемы могут оставаться незамеченными до тех пор, пока объём трафика не станет настолько велик, что они проявятся.

Сама по себе возможность наблюдения не решит проблему паттерна N+1.

Однако она позволяет заметить наличие этого паттерна с самого начала.

Сигналы тревоги должны побуждать к реальным действиям

Системы уведомлений — ещё одна область, которую стоит переосмыслить.

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

Хороший сигнал тревоги должен позволить ответить на вопрос:

Требуется ли моё внимание прямо сейчас?

Что-то вроде:

Error rate has increased significantly

Вероятно, стоит отметить это как проблему.

Но:

One request took 1.2 seconds

Почти наверняка не стоит из-за этого беспокоить кого-либо.

Точные пороги будут различаться в зависимости от системы.

Основная идея остаётся неизменной:

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

Повторяемый процесс значительно снижает напряжение при отладке в продакшене

Когда что-то ломается, случайная проверка редко помогает быстро найти причину. Более эффективно следовать определённой последовательности действий.

1. Проверьте, действительно ли возникла проблема

Сначала убедитесь, что действительно произошла ошибка.

Errors increased?
Latency increased?
Specific endpoint affected?

2. Определите, насколько широко распространена проблема

Выясните, ограничивается ли проблема:

one user?
one endpoint?
all users?
one API instance?
database?
external service?

3. Посмотрите, что изменилось недавно

Проверьте, было ли:

deployment?
configuration change?
database migration?
dependency update?

4. Изучение журналов

Ищите:

errors
timeouts
failed dependencies
database failures
unexpected status codes

5. Анализ метрик

Обратите внимание на:

latency
error rate
traffic
CPU
memory
database metrics

6. Отслеживание запросов при возможности

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

7. Устранение реальной причины

Сопротивляйтесь желанию просто скрыть симптомы.

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

Перезагрузка может скрыть настоящую проблему

Стоит об этом сказать, потому что искушение действительно велико.

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

Но настоящая причина могла быть следующей:

memory leak

Или исчерпанным:

database connections

Или приложением, потребляющим много ресурсов:

background job

Перезагрузка устранила лишь видимые симптомы — она не обязательно исправила то, что на самом деле было не так.

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

Частые ошибки в логгинге и отслеживании

Вот ошибки, которых стоит активно избегать.

1. Запись произвольных строк в логи

Это приводит лишь к появлению шума, а не к чему-то полезному.

2. Запись конфиденциальных данных в логи

Пароли, токены, секреты и личные данные требуют осторожного обращения, а не небрежного отношения.

3. Игнорирование корреляции запросов

Без идентификаторов запросов отслеживание одного запроса на разных этапах становится гораздо сложнее.

4. Отслеживание только времени работы

API технически может считаться «в работе», но при этом быть крайне медленным или частично неисправным.

5. Опора исключительно на среднее время задержки

Анализ по процентилям может выявить проблемы, скрытые простым средним значением.

6. Игнорирование производительности базы данных

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

7. Настройка слишком большого количества оповещений

Постоянный шум от оповещений приводит к усталости и игнорированию сигналов.

8. Внедрение механизмов наблюдаемости позже

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

9>Раскрытие клиентам деталей внутренних ошибок

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

10. Добавление инструментов без четкой цели

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

Чек-лист для оценки уровня наблюдаемости

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

Логирование

• Зафиксируются ли важные события приложения?
• Является ли логирование структурированным?
• Применяются ли уровни логов последовательно?
• Есть ли достаточно контекстной информации для анализа сбоев?
• Присутствуют ли идентификаторы запросов?
• Удаляются ли конфиденциальные данные или они полностью исключаются?

Ошибки

• Фиксируются ли неожиданные ошибки?
• Видят ли клиенты только безопасные, универсальные сообщения об ошибках?
• Доступны ли внутри системы подробные диагностические данные?
• Можно ли связать ошибки с конкретными запросами?

Метрики

• Знаете ли вы объем своих запросов?
• Знаете ли вы уровень ошибок?
• Знаете ли вы время отклика системы?
• Можете ли вы выявить аномалии в паттернах трафика?

• Можете ли вы отслеживать важные зависимости?

База данных

• Можете ли вы выявлять медленные запросы?
• Можете ли вы видеть проблемы, связанные с подключениями?
• Можете ли вы исследовать конечные точки, которые интенсивно обращаются к базе данных?
• Видны ли вам сбои в работе базы данных?

Отслеживание

• Можете ли вы проследить важные запросы через всю систему?
• Можете ли вы обнаруживать медленные операции?
• Можете ли вы видеть вызовы внешних сервисов?
• Можете ли вы связывать действия между разными сервисами?

Уведомления

• Приводят ли важные сбои действительно к отправке уведомлений?
• Являются ли пороговые значения значимыми?
• Являются ли уведомления практически полезными?
• Контролируется ли избыточное количество уведомлений?

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

При разработке локально достаточно просто открыть терминал и наблюдать за происходящим в реальном времени. В продакшене всё не так.

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

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

Именно поэтому логгинг и возможность наблюдения имеют такое огромное значение. Это не просто дополнения к мониторингу — это часть способности системы объяснять свою работу.

К чему это приводит дальше

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

Следующим логичным шагом является более глубокое изучение аспектов развертывания в рамках той же цепочки — контейнеры, настройка среды, пайплайны CI/CD, проверки работоспособности, плавное остановление процессов, стратегии развертывания и всё то, что действительно меняется, когда приложение на Node.js переходит с локальной машины в производственную среду. Эту область лучше всего осваивать через практическую реализацию, а не только на основе теории.

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

Написание качественного кода по-прежнему важно. Но когда что-то всё же идёт не так — а это рано или поздно происходит, — способность понять, что именно произошло, имеет не меньшее значение.

Создайте систему. Защитите её. Сделайте возможным её отслеживание. Затем сосредоточьтесь на упрощении её эксплуатации.