Вебмастер Букреев (Reader)

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

Вечером посыпались жалобы сразу на десятки совершенно не связанных между собой сервисов: банки, маркетплейсы, операторов связи, VK, Steam, Discord, онлайн-кинотеатры и прочее. Жалобы идут из разных регионов России.

Почти одновременно в Москве погас свет в нескольких районах. Сообщалось о проблемах в Гагаринском, Даниловском районе, Замоскворечье и районе Октябрьской. Были проблемы с мобильной связью, магазинами, транспортом. На Калужско-Рижской линии метро некоторое время увеличивали интервалы движения.

А теперь самое интересное.

Мне тут злые языки подсказали: смотрите в сторону Бутлерова, 7.

Для тех, кому адрес ничего не говорит: это ММТС-9, она же M9.

И вот это уже не просто "где-то дата-центр моргнул".

M9 - одна из ключевых телекоммуникационных площадок российского интернета. Там сконцентрировано огромное количество операторского оборудования и межоператорских соединений. Там же находится площадка MSK-IX. Сам MSK-IX в свое время называл Бутлерова, 7 самой востребованной в России локацией для межоператорского взаимодействия - на ней присутствовали сотни операторов.

И сообщения об аварии с электропитанием на M9 действительно есть. Некоторые хостеры уже сообщили клиентам о проблемах с питанием и деградации связности на площадке.

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

Но тут аккуратно: окончательно эту причинно-следственную цепочку пока никто официально не подтвердил. Так что пока это наиболее логичная рабочая версия, а не установленная причина.

И маленький технический нюанс.

Фраза "упала точка обмена трафиком и поэтому упал Рунет" - слишком примитивное объяснение. Интернет так не устроен, MSK-IX вообще географически распределён, маршруты резервируются, питание резервируется и все взрослые люди заранее готовятся к отказам.

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

Что мы сегодня, собственно, и наблюдаем.

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

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

Причем резервирование питания именно на этой точке - МНОГОКРАТНОЕ.
Интересно, какое количество полыхающих поп будет завтра на совещаниях и разборах…

Стек нарочно простой: Python-бот на Telegram Bot API (polling, без вебхуков), SQLite для всего состояния, Docker Compose для развёртывания на домашнем сервере.

Главный принцип архитектуры - разделение вероятностного и детерминированного. LLM (OpenAI Responses API, structured output) отвечает только за то, что действительно требует понимания языка: разобрать свободный русский текст в строгую схему (Pydantic), сформулировать похвалу, добавить недельному отчёту немного «человечности», иногда придумать новую тему раунда. Модель никогда не считает баллы, не хранит состояние и не имеет права отрицать то, что уже сохранено в базе - при обычном разговоре ей передаётся точный контекст из SQLite, и по нему она обязана сверяться.

Вся арифметика баллов живёт в одном модуле без единого обращения к LLM. Она детерминирована и покрыта тестами, а документация формул синхронизирована с кодом как источник истины.

Из инженерных деталей: обработка Telegram update идемпотентна по update_id, чтобы повторная доставка не начисляла баллы дважды; частичные отчёты - это upsert, неназванные поля не затираются; запись в уже закрытую неделю блокируется на уровне сервиса; плановые рассылки (утро/вечер/бэкап) идемпотентны через таблицу отправленных сообщений, что переживает рестарт контейнера.

Ежедневный бэкап SQLite с ретеншеном настроен отдельной джобой.

Ну, типа все 🙂

Как это выглядит на практике.

Утром в 11:00 приходит план на день: шаги, рабочие/домашние задачи, ведение дневника, что осталось из недельных целей вроде бассейна. Если не ответить - придёт мягкое напоминание ещё пару раз, максимум три сообщения.

Вечером - один опрос, без повторов. Отвечаю обычным текстом, свободной формулировкой, в любом порядке фактов. Бот разбирает сообщение сам и досчитывает необходимое но не выдумывает цифры, только уточняющий вопрос, если данных мало.

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

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

Продожение в следующей серии (Технические подробности)… 🙂

Псилохог подсказал одну интересную особенность мозга… Послушал несколько лекций по этой теме. Появилась идея.

Я давно заметил закономерность: у меня не проблема с силой воли вообще, а с тем, чтобы просто начать - выйти на прогулку, дойти до бассейна, сесть за домашние дела. Одно и то же напоминание в календаре я могу игнорировать неделями… 🙂

Решил сделать личного Telegram-бота, который превращает рутину в игру. Не трекер для галочек, а что-то, что напоминает по-разному, принимает отчёт обычным текстом («5 рабочих задач закрыл, 2 домашних, 4300 шагов, дневник заполнил») и сразу считает баллы.

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

В основе - принцип PINCH (Passion, Interest, Novelty, Challenge, Hurry): игра, личный контекст, еженедельная новизна оформления, вызов самому себе прошлому, и мягкая срочность вместо давления. Никакого стыда и чувства вины - только похвала, подколы и очередной раунд.

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

Продолжение в следующей серии… :-))

Почему xhigh effort - это не режим "максимальной эффективности"

Закончил тесты GPT на десяти реальных задачах. Сравнивал обычные значения effort с переключением на xhigh.

Результат довольно однозначный: xhigh не улучшил качество ни у одной из моделей, зато существенно увеличил время работы и расход токенов.

У GPT-5.6 результат снизился с 70,18% до 69,21%, а количество полностью решенных задач - с 6 из 10 до 5 из 10. Время выросло с 21:39 до 55:40, объем входных токенов - с 3,32 до 7,08 млн, выходных - с 44,96 до 122,28 тыс.

У GPT-5.5 результат снизился с 61,38% до 59,05%, решенных задач стало 4 из 10 вместо 5 из 10. Время выросло с 38:12 до часа, выходных токенов стало больше примерно вдвое.

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

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

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

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

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

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

Но "больше думать" - вообще не синоним эффективности.

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

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

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