Отладка *

Наивность, fail-fast, fallback, failback, оптимизация и стратегия — на слизне, на кухне и на JavaScript

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

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

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

В прошлой статье я сделал обзор популярных способов отладки embedded: GDB-клиент -> GDB-сервер (OpenOCD) -> программатор -> целевой МК. Тогда я сформулировал свои субъективные требования к “идеальному” программатору. И на тот момент у меня уже был минимально рабочий вариант такого программатора. И вот спешу представить к чему привели меня изыскания в этом направлении.

Мы переводили карту парковок с растровой подложки на векторные тайлы и получили чёрный экран. Без единой ошибки в консоли: ни исключения, ни предупреждения, идеально чистый лог. Единственной уликой оказалось отсутствие запросов за тайлами — воркер MapLibre не попал в сборку, потому что Rollup не умеет разбирать шаблонную строку в new URL(…, import.meta.url). Разбираем этот баг и ещё два из той же серии: как смена города убивала Leaflet и почему событие load у карты не наступает никогда.

Спросил у Claude Code «Ответь одним словом: работает». Двадцать девять символов. На сервер ушло 305 042 байта — 113 460 токенов, ответ из четырёх.

Поставил между агентом и сервером прокси на сорок строк Python и разобрал тело запроса по частям. Системный промпт — четыре процента. Восемьдесят пять процентов — описания 137 инструментов, из которых 107 принёс один MCP-сервер, которым я в этой сессии не пользовался. Ещё 29 тысяч символов добавил хук плагина. И на каждый ход уходит второй запрос, о котором я не просил.

То же самое проделал с Codex CLI: 29 килобайт, 9 817 токенов, а системный промпт при этом такой же длины. Дальше — таблица, что убирается флагами (один MCP-сервер стоил 52 тысячи токенов на запрос), что это значит для окна и кэша, и скрипт, чтобы посмотреть свой первый запрос.

За полгода Tailscale 19 раз столкнулась с повреждением баз SQLite, но воспроизвести сбой не удавалось: между инцидентами проходили то часы, то недели. Инженеры собирали диагностику прямо в продакшене, проверяли одну гипотезу за другой и в итоге нашли редкую гонку между записью и созданием контрольной точки — баг, который скрывался в SQLite минимум 16 лет.

Полгода назад я начал писать сжатую файловую систему для macOS. Идея была довольно простой. В macOS уже существует decmpfs — встроенный механизм прозрачного сжатия файлов. Приложение продолжает видеть обычный файл, хотя физически его содержимое может храниться в сжатом виде. Но у этого подхода есть неприятное для моей задачи свойство: после изменения файла сжатие может исчезнуть.

Например, можно сжать node_modules, получить приличную экономию места, потом запустить сборку — часть файлов перезапишется, распакуется, и каталог постепенно снова начнёт занимать почти исходный объём. Мне хотелось другого поведения: если файл лежит на сжатом диске, он должен оставаться сжатым независимо от того, сколько раз его переписывали.

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

Но почему она умерла?

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

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

Недавно нам встретился прекрасный пример этого. Переданная клиентом SD-карта SanDisk Ultra 32GB ничем не распознавалась. Изначально казалось, что потребуется сложное восстановление флэш-памяти, но в результате всё свелось к двум микроскопическим компонентам, спрятанным внутри карты. Я решил, что это будет подходящей возможностью продемонстрировать процесс восстановления.

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

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

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

Привет, Хабр! Пилю потихоньку пет‑проект и решил поделиться тем, что вылезло при первом же деплое.

Откуда взялась эта штука 

Основная занятость у меня связана с ИИ, но есть ещё подработки по 1С — в основном администрирование: обновления, настройка оборудования, выгрузки и прочее. Всё взаимодействие идёт в Telegram: множество чатов, в каждом свои задачи, у каждой свой дедлайн и своё техническое окно, когда её вообще можно делать. Базу не обновишь в разгар рабочего дня — значит, задача не просто «к пятнице», а «в пятницу после семи».

Пока задач несколько, они держатся в голове. Дальше начинается путаница: помнишь, что на этой неделе у кого‑то обновление, а у кого именно — уже нет. Я начал забывать про клиентов. Писал на бумажке. Бумажка не работает по простой причине: про неё тоже надо вспомнить. Она лежит рядом и молчит. А напоминание должно приходить само и туда, где я и так сижу целый день. Так и родилась мысль сделать свой блэкджек.

Мой сервис обрабатывает большой поток PDF от самых разных генераторов. В начале июня один‑единственный файл уложил его на 30 минут: HPA раздул поды до потолка, и все они наглухо повисли, 100% CPU, обработка стоит, очередь копится, алерты сыпятся пачками. Расследование в трёх актах: ложный подозреваемый, закомментированный panic и санитайзер, не знавший алфавит до конца.

Всем привет! Меня зовут Илья Данилкин, я тимлид в Авито Авто.

AI-агенты обычно живут рядом с Python, но всё же немало команд выбирают язык Go. Дело в том, что агенты большую часть времени не заняты сложными математическими расчётами, а ждут ответа модели или результата инструмента. А ещё работают в режиме бесконечных параллельных запусков. И если пользователь останавливает задачу, его запрос и следующие вызовы инструментов тоже нужно остановить.

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

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

Сервис жив, CPU в норме, паники нет — а часть запросов зависает на минуты. В async‑Rust привычный стек часто мало помогает: задача могла застрять на блокирующем вызове, мьютексе или просто перестать получать пробуждения.

Разбираем, как отличать эти сценарии в Tokio и куда смотреть, когда отладчик молчит.

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

Может ли лишняя запись в yarn.lock повесить браузер? Наша прожила в репозитории три месяца, не привлекая внимания, а потом ночью после релиза положила прод вечным лоадером - причём только в Chromium. Рассказываю, как мы шли к разгадке через ложные следы и что в итоге оказалось в рантайме.

Я делаю NotiBox — Pusher‑совместимый сервис realtime уведомлений. Под капотом я использую Sockudo — WebSocket сервер на Rust. Прежде чем показывать реальным пользователям, я решил проверить, на сколько Sockudo на самом деле «blazingly fast».

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

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

Другой сценарий — ничего не перегружено, но новые соединения/запросы не проходят, растёт задержка ответов. Это тоже ожидаемо и понятно как чинить: смотришь на TIME WAIT сокеты, max open files, и другие «предохранители».

А что делать, если там тоже всё по нулям? Вот тут начинается настоящее приключение.

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

Основные изменения Infostart Toolkit Air 2026.2 связаны с повседневными задачами 1С-разработчиков: анализом результатов запросов, поиском данных в больших выборках и отладкой отчетов на СКД. Результаты запросов теперь можно просматривать не только в таблице, но и в виде дерева. В обоих режимах доступны фильтрация и быстрый поиск, а при работе с несколькими коллекциями — поиск нужной таблицы по части имени. Вывод данных также оптимизирован: результаты загружаются только после выбора соответствующего элемента, что сокращает потребление памяти.

Через четыре часа после первой статьи пришёл комментарий: в моём коде не хватает трёх инструкций, и на настоящей плате он рассыплется.

Читатель arteast был прав.

Сел воспроизводить поломку. Собрал два варианта, свой и правильный, прогнал на строке в 231 байт. Вывод побайтово одинаковый. Замедлил линию до предела. Ничего не изменилось. Написал программу, которая смотрит, бывает ли передатчик занят хоть когда-нибудь. При выводе в консоль не бывает.

Моя ошибка внутри эмулятора не проявляется вообще. Проверить себя было нечем.

Пришлось чинить эмулятор.

На первый взгляд, Social Login — одна из самых простых функций современного веб-приложения.

Добавить кнопку «Войти через VK». Добавить кнопку «Войти через Яндекс». OAuth 2.0 давно стандартизирован, OpenID Connect тоже. Документации и библиотек полно. Да и AI сегодня умеет писать интеграции быстрее человека. Поэтому, когда я решил добавить VK ID и Яндекс ID в Авторизу, честно рассчитывал уложиться в один рабочий день:

Свою систему знаю. OIDC знаю. Подобные интеграции раньше проектировал. Под рукой ChatGPT, Claude и AI-агенты.

Что вообще может пойти не так?

Спойлер: получилось почти три дня. И самой сложной частью оказался не OAuth.

День первый. Самоуверенность

Профайлер показывает write() и worker файлового логгера среди верхних стеков. Однако системный профайлер не знает, какая из тысяч строк вывода в лог породила нагрузку. Отключать логирование совсем — ужасное решение. Как же связать файловый ввод-вывод с конкретными строками вывода в лог, каналами и backend?