Полгода назад я заложил идею сервиса логирования. В декабре я его реализовал — и работа ускорилась на 30%. Плюс знаковое событие: в команде появился бизнес-аналитик. История о том, как один прорыв меняет всё, и почему учиться читать логи нужно на практике.
Когда 15 минут на анализ ошибки — это слишком долго
Очередная ошибка. Я открываю терминал — сотни строк. Открываю консоль браузера — десятки предупреждений. Смотрю серверные логи — пытаюсь понять, где именно всё сломалось.
15 минут. Иногда больше.
И так — каждый раз.
Я понимал: это "слепая зона". Я не вижу полной картины. Не понимаю, что привело к ошибке. Только результат.
Идея сервиса логирования родилась полгода назад, когда я работал с приложением Focus в кодовом пространстве GitHub. Но тогда были другие приоритеты: календарь, задачи, база знаний.
Логирование ждало.
Пока в декабре не произошло два знаковых события.
Знаковое событие #1: В команде появился второй человек
Начало декабря. Я работаю над Focus полгода. Один.
И вдруг — в команде появляется бизнес-аналитик. Света. Мы знакомы лично. Она знала о моей идее, но присоединилась только сейчас.
Большое упущение с моей стороны: я не анонсировал это в декабре. Не рассказал читателям. Но сейчас исправляю.
Почему это важно? Потому что команда меняет темп. Даже если нас двое.
Света уже многое сделала. Но больше всего повлияло User Story — описание того, как пользователь будет взаимодействовать с приложением.
Я не всегда понимаю всё, что делает бизнес-аналитик. Но её обратная связь и User Story повлияли на стратегию и ход развития проекта в целом.
Я думал: "Буду делать не спеша. Хоть 5 лет."
После появления Светы: "Нужно ускоряться. Через 2 месяца должен быть прототип."
Время покажет, насколько долго продлится наше сотрудничество. Но факт остаётся фактом: появление человека с другой ролью (не второго разработчика) изменило мышление.
Лучше, когда в команде есть люди с разными ролями. Если на стройке одни маляры — дом не построится.
Знаковое событие #2: Реализация сервиса логирования
Ускорение темпа, новое видение проекта — и я понял: мне нужен сервис логирования. Срочно.
Идея ждала полгода. Реализация заняла 2 часа.
Почему так быстро? Основа была заложена. Архитектура. Структура. Оставалось собрать.
Что умеет сервис:
- Записывает действия пользователя и системы
- Переключатель: день / неделя / месяц / год
- Для разработки критичен режим "один день"
- Кнопка "Экспорт логов" — скачать файл
Изначально я думал: можно будет записывать логи хоть на год. Если файл небольшой (несколько строк) — почему бы и нет?
На практике оказалось: данных намного больше, чем я мог представить. И я пришёл к пониманию: неделя, месяц, год — нужно будет убирать. Потому что это перегрузит страницу и работу базы данных.
Я не представлял, как будет работать логирование. Только практика показала реальные масштабы.
Эволюция логов: от нескольких строк до массива данных
Когда только внедрили: логи весили несколько строк.
Сейчас (неделя спустя): самый большой файл — 0,98 МБ (1 036 591 байт). Всего 67 строк, но в каждой строке — огромные массивы данных.
Почему так много?
Потому что я тестирую сложные задачи. Например: "Агент, сделай анализ книги 'Думай как математик'."
В логах записывается всё:
- Чтение книги
- Мысли агента
- План работы
- Анализ
Но это не одна модель. Это агентская система. Книгу может прочитать несколько моделей.
В одной строке можно увидеть ход размышлений нескольких моделей.
А у меня 67 строк. Поэтому можно перечитать книгу не несколько раз, а много раз.
Плюс в логах записывается не только анализ книги. Там много чего логируется для того, чтобы отслеживать причинно-следственную связь ошибки.
30% экономии времени: конкретные примеры
До логирования:
- 15 минут на поиск одной ошибки (иногда больше)
- Копаюсь в терминале, консоли браузера, серверных логах
- Не всегда понимаю причину
- Мог топтаться неделю, думая, что причина в другом
После логирования:
- Нажал кнопку → скачал лог → открыл файл → нашёл ошибку
- Вижу контекст: что привело к проблеме
- Быстрее нахожу причину (хотя иногда это всё равно занимает время)
Экономия времени: примерно 30% на отладку.
JSON, "абракадабра" и обучение чтению логов
Первый раз, когда я открыл файл логов, увидел что-то вроде этого:
Copy{
"task": "\"\\u0418\\u0441\\u0441\\u043b\\u0435\\u0434\\u043e\\u0432\\u0430\\u043d\\u0438\\u0435 \\u043a\\u043d\\u0438\\u0433\\u0438 '\\u0414\\u0443\\u043c\\u0430\\u0439 \\u043a\\u0430\\u043a \\u043c\\u0430\\u0442\\u0435\\u043c\\u0430\\u0442\\u0438\\u043a'\"",
"steps": [...]
}
Моя первая мысль: "Это спам?"
Потом понял: это JSON. Формат, в котором машины пишут метаданные.
Для тех, кто не знаком с JSON: это структура данных, которую используют программы для обмена информацией. Выглядит как набор ключей и значений: "название": "данные".
Как я учусь читать логи (и почему это сложно)
Честно признаюсь:
Я не профессионал в чтении логов. Я прошёл простые уроки от AI, но учусь на ходу.
Что я понял за декабрь — начало января:
1. Смотрите на ID записей, а не на номер строки
- ID может записываться не последовательно
- Привязка к ID важнее, чем физическое расположение в файле
2. Читайте смыслы и последовательность
- Не просто ищите слово "error"
- Смотрите контекст: что было до, что после
- Логическая цепочка действий важнее отдельных строк
3. "Error" в логах — не всегда ошибка
Когда я проходил курс от AI, мне подсказали: "Error" — это иногда просто информационное сообщение. Оно должно быть, как запись для отслеживания. Это не всегда означает проблему.
Это важный лайфхак, о котором я сам не знал.
4. Практика важнее курсов
Не на всех курсах даётся достойная практика. Навык оттачивается лучше на практических кейсах конкретного проекта.
Можно прочитать много книг. Но куда важнее — навык.
Реальный пример: как логи помогли найти ошибку
Задача: Агент должен составить план и следовать ему.
Проблема: Агент крашится на этапе составления плана.
Раньше: я бы проверял код, сервер, консоль. Думал бы: "Может, проблема в модели? Или в промте?"
С логами: открыл файл → нашёл ошибку через 1 час:
DATABASE_ERROR: missing required table: [table_name]: SQL_ERROR
(Название базы данных изменено для статьи)
Причина: при обращении к базе данных отсутствовала нужная таблица.
До логов: мог бы топтаться на этой ошибке неделю, пытаясь понять, почему агент не работает.
С логами: нашёл причину за час → исправил.
Находить причину — куда важнее, чем просто видеть ошибку.
Почему AI не может читать мои логи (и как это обойти)
После того, как логи стали огромными, я попытался передать их AI для анализа.
Результат: "Файл слишком большой."
Пробовал разные модели. Google Gemini. Claude. ChatGPT.
Ни одна не справилась просто через загрузку в чат.
Лайфхак для читателей:
Я обнаружил, как можно обойти этот момент.
К сожалению, на момент написания статьи я всё ещё не идеально умею читать логи. Я всё ещё в процессе обучения.
Но есть способ получить помощь от AI:
- Загрузите файл на Google Drive
- В чате Gemini нажмите кнопку "+" → подключите Google Drive
- Укажите путь к файлу и название
- Укажите диапазон строк (например: "Прочитай строки 30-50")
- Попросите:"Дай вводные уроки — на что обращать внимание при чтении таких данных"
"Дай обратную связь: что не так с моими логами?"
Почему это работает?
Когда файл на Google Drive, AI может прочитать большие массивы данных, которые не помещаются в чат.
Это обходной путь для тех, кто, как и я, учится читать логи.
Сервис логирования — это не "сделал и забыл"
Неделя спустя после внедрения я понял: сервис логирования нужно постоянно дорабатывать.
Почему?
Потому что мой продукт неустойчивый. Я постоянно добавляю новые функции. Внедряю изменения. И логирование должно адаптироваться.
Если бы у меня был законченный, стабильный продукт — логи писались бы одинаково.
Но я в процессе разработки. Поэтому каждый день дорабатываю то, что записывается в логи.
Вопрос читателям: Если вы знаете, как сделать идеальный инструмент логирования в постоянно изменяющихся условиях — пишите в комментариях. Буду благодарен за советы.
Практический совет: настройте логирование сразу
Если ваш проект:
- Долгосрочный (будет развиваться годами)
- Сложный (база данных, API, агенты, множество функций)
Настройте логирование в самом начале.
Потому что:
- Ошибки неизбежны — логи помогут находить причину быстрее
- База данных может падать — логи покажут, где именно
- Пользователи будут жаловаться — логи покажут объективную картину (нажимал ли пользователь кнопку? Когда? Что произошло?)
Не откладывайте. Я отложил на полгода — и потратил лишние недели на поиск ошибок.
Что я понял за декабрь — начало января
О логировании:
- Экономит примерно 30% времени на отладку
- Находить причину важнее, чем просто видеть ошибку
- Учиться нужно на конкретном проекте, а не на курсах — не на всех курсах даётся достойная практика
- AI не заменит человека в чтении сложных логов — разработчику или тестировщику нужно самому учиться читать
О команде:
- Даже двое — это команда
- Человек с другой ролью меняет мышление
- User Story и обратная связь бизнес-аналитика помогли увидеть стратегию
- Время покажет, насколько долго продлится сотрудничество — но факт остаётся: темп ускорился
О разработке:
- Опыт накапливается: календарь 2 недели → логирование 2 часа
- Идеи могут ждать, но лучше не откладывать критичные функции
- Несовершенство нормально: я не профессионал, учусь на ходу — и это нормально
Финал: главный посыл
Одиночки двигаются медленно. Даже если талантливы.
Команда ускоряет. Даже если нас двое.
Логирование экономит время. Даже если учишься читать логи на ходу.
Практика важнее курсов. Всегда.
P.S. Если вы знаете, как настроить идеальное логирование для сложных проектов — делитесь в комментариях.
Если вы бизнес-аналитик, дизайнер, маркетолог — и хотите получить практику на реальном проекте — пишите. Может быть, вы станете третьим в команде Focus.
Учитесь на практике. Настраивайте логирование сразу. Ищите команду.
Дмитрий, создатель Focus Блогер, No-Code разработчик, человек, который учится на ходу