Все имена в тексте вымышлены.

Контекст

5–11 июля, неделя неполная. Три инцидента подряд: ложная тревога в мониторинге, реальная дыра в безопасности и синхронизация, которая молчала три недели, изображая работу. Плюс честный разговор с самим собой о том, что четвёртый день не в лучшей форме.

Ложный шторм

Нет данных ≠ всё стёрто

Бот мониторинга расписания школы периодически присылал уведомление о восьмидесяти двух изменениях разом — будто у полутора десятков инструкторов слоты на неделю вперёд одновременно опустели. Ложная тревога.

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

Инсайт

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

Пароли в открытую

Топ тир проблема безопасности

Работая над одним из школьных проектов, наткнулся на то, что пароль от сервера и токен телеграм-бота лежали в открытом виде прямо в скриптах. Сам себе сказал прямым текстом: "это же топ тир проблема безопасности".

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

Честно

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

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

Синхронизация молчала три недели

Триаж клиентов маркетплейса

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

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

Из тысяч записей в очереди реально "в работе" оказалось около полусотни. Из подтверждённых покупателей почти четыреста ещё ждали ответа.

Инсайт

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

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

Четвёртый день не очень

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

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

Честно

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

Персонализация дебрифов

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

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

Coach radar: почти топ-3

Посчитал результаты личного рейтинга за месяц, расширил выборку до всех инструкторов, отработавших больше восьмидесяти часов. Результат — почти топ-3 среди инструкторов школы. Заодно отметил слепое пятно: нет фотографии в профиле на сайте школы, а без неё ученики реже выбирают тебя из общего списка.

Цифры недели

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