Журнал продукта: недели вживую

11 октября, около восьми вечера. В боте «Кодиума» человек оставляет заявку, а бот отвечает: «CRM недоступна». Сервер с CRM в Москве завис: диск почти не отвечал, подключение по SSH рвалось, перезагрузка висела на «Syncing filesystems – timed out». Код ни при чём, у хостинга сломалось хранилище. Данные остались целы, все 84 заявки на месте, ночная копия лежала на Яндекс Диске. А потом выяснилось неприятное: та заявка, на которую бот получил таймаут, в CRM всё-таки записалась. Если бы человек нажал «отправить» ещё раз, в базе было бы две одинаковые.

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

Чему научишься в этом уроке:
• вести журнал продукта по пяти полям: дата, что случилось, как заметил, что сделал, сколько стоило;
• за 15–20 минут проверять, жив ли продукт, не глядя в код;
• выбирать из журнала правки, которые стоят времени, и доводить их до конца;
• считать, во что обходится поддержка, деньгами и часами.

Три недели вживую

Последние недели трека ты почти ничего нового не строишь. Бот из П1, интеграция П2, мониторинг П3, CRM П4 и ассистент П7 просто работают, а ты записываешь всё, что с ними происходит. Это похоже на медкарту в поликлинике: врач не помнит, что было с тобой полгода назад, но по записям видит, что кашель возвращается каждую осень. Без записей каждый сбой выглядит случайным. С записями видно, что повторяется и что стоит чинить первым.

Журнал идёт фоном все четыре недели финала. Остальные уроки ты проходишь параллельно с ним, а не после него. Так выглядит календарь:

• Неделя 13. С первого дня начинаешь журнал продукта (этот урок). Собираешь черновики трёх кейсов (9.2) и сразу ищешь собеседника для разговора (9.4): договориться о времени дольше, чем поговорить.
• Неделя 14. Фраза и витрина (9.3). Разговор, резюме и коммерческое предложение (9.4).
• Неделя 15. План на 3 месяца (9.5) и выбор учёбы (9.6). Три правки по журналу.
• Неделя 16. Дописываешь в кейсы цифры и сбои из журнала, записываешь видео и сдаёшь трек (9.7).

По времени финал занимает около 10–11 часов за четыре недели: журнал примерно 10 минут в день, остальное несколько вечеров на миссии. Три недели журнала считаются с первой записи.

Работает ли продукт три недели без тебя, хочет знать любой заказчик. Журнал отвечает на этот вопрос фактами. Из него же потом возьмёшь цифры для портфолио (урок 9.2) и строку «сколько стоит поддержка» для коммерческого предложения (урок 9.4).

Пять полей записи

1. Дата и, если важно, время по Москве.
2. Что случилось: одной фразой, как увидел бы заказчик. «Бот не ответил на /start», а не «упал polling».
3. Как заметил: мониторинг, журнал службы, сообщение человека, своя проверка. Это поле показывает, где у тебя слепые места.
4. Что сделал: диагноз и правка. Если правки пока нет, так и пиши: «не сделано».
5. Сколько стоило: деньги, время агента, твоё время, потерянные заявки, простой.

Журнал веди таблицей с колонками «Дата | Что случилось | Как заметил | Что сделал | Сколько стоило»: ровно так он войдёт в документ сдачи (урок 9.7). Держать таблицу можно где удобно: файл в репозитории, облачная таблица, заметка. Главное, чтобы в нём не было ключей, телефонов, имён и адресов серверов. Журнал покажешь другим людям, поэтому пиши сразу так, будто его прочтёт заказчик.

Слово «журнал» в курсе встречается в трёх смыслах, не путай их. Журнал продукта ведёшь ты руками, это таблица из этого урока. Журнал службы сервер пишет сам, его читаешь командой journalctl. Журнал запросов к модели ведёт ассистент из П7: там видны модель и расход каждого ответа.

Образец: десять настоящих сбоев прогона

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

1. 09.10. Telegram отвечал российскому серверу на 10 запросов из 20, бот падал по таймауту. Заметил: бот молчал на /start. Сделал: перенёс бота в Амстердам, стало 20 из 20. Стоило: второй сервер.
2. 09.10. Ссылка на скачивание с Диска вернула переадресацию, код решил «файла нет» и затёр старые заявки новым файлом. Заметил: вторая тестовая заявка «съела» первую. Сделал: переход по переадресации, новый файл только если файла правда нет, запасной файл очереди. Стоило: тестовые данные и 5,2 минуты агента.
3. 10.10. В журнале службы отчёта токен бота открытым текстом. Заметил: читал журнал глазами после выкладки. Сделал: убрал подробный вывод библиотеки запросов, перевыпустил токен у @BotFather. Стоило: 5,1 минуты агента.
4. 10.10. Мониторинг упал с «InvalidToken: Not Found», агент переименовал переменные в .env. Заметил: журнал таймера. Сделал: вернул имена, запустил вручную. Стоило: один пропущенный отчёт.
5. 10–11.10. Миграция делала копию базы на каждом старте, на сервере набралось 100 копий. Заметил: посчитал файлы в папке копий. Сделал: миграция только когда нужна. Стоило: место на диске.
6. 11.10. После выкладки П6 у «Кодиума» оказались пустые сроки подписки, кабинет действующего клиента закрылся. Заметил: запрос к базе на сервере в режиме только чтения. Сделал: вернул сроки, дал школе 14 дней. Стоило: недоступный кабинет у клиента.
7. 11.10. Одно нажатие «Оплатить» в тестовом магазине создало 7 платежей за 18 секунд. Заметил: таблица платежей. Сделал: ключ повтора, статус по ответу кассы. Стоило: ничего, магазин тестовый.
8. 11.10. Зависла CRM в Москве, история из начала урока. Заметил: бот ответил «CRM недоступна». Сделал: диагноз, письмо в поддержку хостинга. Стоило: простой CRM и риск дубля.
9. 12.10. Основная модель с сервера бота не отвечала 60 секунд, хотя с ноутбука автора отвечала за 9,4. Запасная выручала, но человек ждал 35–42 секунды. Заметил: живая проверка. Сделал: поменял основную и запасную местами, теперь ответ за 3–7 секунд. Стоило: время клиента.
10. 12.10. Два сообщения подряд обрабатывались одновременно, история разговора перемешалась. Заметил: живая проверка. Сделал: вопросы одного человека встают в очередь.

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

Что смотреть и как часто

Каждый день хватает пяти минут, раз в неделю нужно минут двадцать.

• Каждый день. Пришла ли утренняя сводка мониторинга. Отвечает ли бот на /start. Нет ли в журнале службы бота ошибок за сутки. Журнал службы читаешь, но личных данных в нём быть не должно: увидел телефон или имя, это уже запись в журнал продукта.
• Раз в неделю. Расход в кабинете CloseRouter (не оценку из Claude Code, она в десятки раз выше реальной). Свежая ли ночная копия базы CRM. Включены ли службы на автозапуск (systemctl is-enabled) и сколько они работают без перерыва (systemctl status). Боевой сервер ради проверки не перезагружай. Полный pytest -q: тестов не меньше, чем было.
• Раз за три недели. Восстановить копию базы на пробу, как в уроке 5.5. Копия, которую ни разу не восстанавливали, может оказаться пустой.

Сколько стоит, чтобы продукт жил

Поле «сколько стоило» по отдельности кажется мелочью. Сложи за месяц, и получишь себестоимость поддержки. Из прогона: сервер CRM в Москве стоит 1 720 ₽ в месяц. Сервер в Амстердаме у автора (1 ядро, 2 ГБ памяти, 30 ГБ диска) стоит 2 660 ₽ в месяц или 3,63 ₽ в час — по панели Timeweb на 12.10.2026; свою цифру смотри по счёту. Разбор мониторинга моделью обходится примерно в 0,5 ₽ в месяц, один ответ ассистента в доли цента. Модель почти ничего не стоит. Дорого стоят серверы и твоё время на поддержку.

Работа агента за весь трек у автора стоила около 12,2 $, и 82% этой суммы пришлись на один паттерн П6. Там были длинные сессии с переделками. В П7 после плана и новой сессии ушло около 0,4 $. Если починка из журнала затягивается, начни новую сессию с коротким планом, это дешевле.

Три правки по журналу

Журнал нужен не для отчёта. За три недели выбери из него три правки и сделай их. Хорошая правка закрывает повторяющийся сбой или сбой, который стоил клиенту денег или заявки. Если сбоев мало, правкой считается и улучшение по записи «что заметил». Правило для любой правки одно: коммит, pytest -q до и после и строка, какую запись журнала она закрывает.

Пример, который остался несделанным в прогоне: ключ заявки против дубля. Если ключ ты уже сделал в уроке 8.6, возьми для правки другую запись. Представь квитанцию с номером. Бот выписывает номер один раз, при первой попытке отправить заявку, и при повторе отправляет тот же номер. CRM, увидев номер, который уже есть, вторую запись не создаёт и отвечает «уже принято». Такой номер называют ключом идемпотентности (от слова «одинаковый»: сколько ни повторяй, результат один).

В журнале продукта запись: бот получил таймаут от CRM, но заявка в CRM записалась. При повторе будет дубль.
1. Сначала воспроизведи: тестом покажи, что две отправки одной заявки дают две записи. Покажи мне падающий тест.
2. Бот создаёт ключ заявки один раз и шлёт его при каждой попытке. CRM хранит ключ с уникальностью и на повтор отвечает "уже принято" с тем же номером заявки.
3. Старые заявки без ключа не трогай. Миграцию покажи до запуска.
4. В конце: pytest -q целиком, число тестов до и после. Тесты не удалять и не пропускать.

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

Если не получилось

• За неделю нет ни одной записи → проверь, смотришь ли ты вообще: пришла ли сводка, отвечает ли бот. Тихая неделя тоже запись: «проверил, всё работает, 15 минут».
• В журнале службы нашёлся токен или телефон → это сбой. Убери вывод, перевыпусти токен и запиши.
• Агент говорит «исправлено», а сбой повторяется → верни ему запись журнала целиком и попроси сначала воспроизвести сбой тестом.
• Сервер завис, и ты не понимаешь почему → не чини вслепую. Сохрани, что видел, и напиши в поддержку хостинга. В прогоне виноват был хостинг, а не код.

Контрольный вопрос. Ты проверяешь бота раз в неделю и находишь, что пять дней назад он не отвечал на /start два часа. Что из этого становится записью журнала продукта?

АНичего, сейчас бот отвечает, значит, всё в порядке

БЗапись с датой, что случилось, как заметил (недельная проверка), что сделал и сколько стоило, плюс вывод: смотреть надо чаще

ВСтрока «бот глючил» без даты

ГТолько исправление кода, журнал не нужен

Подсказка: Вспомни пять полей. Какое поле показывает, что сбой нашёлся поздно?

На курсе задания проверяются автоматически. Решить первое задание бесплатно →  ·  Подобрать курс

Контрольный вопрос. Из журнала за три недели нужно выбрать правки. Какие записи стоят правки в первую очередь? Отметь все верные.

Выберите все верные варианты.

АТихий день, когда всё работало

БСбой, который повторился три раза

ВЗаявка, которая могла записаться дважды

ГТокен бота в журнале службы

Подсказка: Какие записи стоили клиенту заявки, денег или безопасности?

На курсе задания проверяются автоматически. Решить первое задание бесплатно →  ·  Подобрать курс

Задание. МИССИЯ «Три недели вживую». Твои продукты работают сами, ты наблюдаешь и записываешь. 1. Журнал продукта за три недели (около 10 минут в день): таблица с колонками «Дата | Что случилось | Как заметил | Что сделал | Сколько стоило», каждая запись с пятью полями (дата, что случилось, как заметил, что сделал, сколько стоило). Тихие недели тоже записаны. 2. Отметки еженедельной проверки: сводка мониторинга, ответ бота на /start, systemctl is-enabled и время работы служб, расход в кабинете CloseRouter, дата последней копии базы CRM, итог pytest -q. 3. Три правки по журналу: для каждой ссылка на коммит, последняя строка pytest -q до и после, одна фраза, какую запись журнала она закрывает. 4. Строка «сколько стоит месяц поддержки»: серверы по счёту в панели, модели по кабинету, твои часы. Принято, если: в журнале не меньше трёх недель и у каждой записи пять полей; три правки со ссылками на коммиты, число тестов не уменьшилось; расход взят из кабинета, а не из оценки Claude Code; в журнале нет ключей, токенов, телефонов, имён и адресов серверов.

Подсказка: Начни с первой записи сегодня: даже «проверил, всё работает» с датой уже часть журнала.

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

На курсе задания проверяются автоматически. Решить первое задание бесплатно →  ·  Подобрать курс

Что дальше

Журнал продолжаешь вести всю неделю 13 и дальше, а следующий урок проходишь параллельно. Черновики трёх кейсов портфолио собираешь уже сейчас, цифры журнала и то, что не получилось, допишешь в них к сдаче.

Итог:
• журнал продукта ведётся по пяти полям, без секретов и личных данных;
• сбои чаще находятся глазами, чем тестами, поэтому продукт проверяется каждый день и каждую неделю;
• из журнала выбраны три правки, и они доведены до коммита;
• видно, сколько стоит месяц поддержки.

← Назад  ·  ↑ В начало урока  ·  ⌂ В начало курса  ·  Вперёд →