🧙‍♂️Иногда фичи рождаются из случайных артефактов

История Mortal Kombat 🥷 - отличное подтверждение.

1992 год, аркадные автоматы. В диагностическом меню MK появилась строка ERMACS - счётчик ошибок, который программист Эд Бун добавил для отладки. Игроки увидели её рядом со статистикой бойца Reptile и решили - это секретный персонаж Ermac. Пошла волна слухов, фанаты требовали добавить его. Midway могла просто убрать строчку, но в MK3 реально появился "Ermac" 🟥 в красной одежде с сильным телекинезом. Служебная метрика стала легендой франшизы.

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

Кстати, Эд Бун позже признался, что двусмысленность ERMACS оставили специально - чтобы подогреть интерес.

🫴 А у вас было, когда техническая деталь неожиданно становилась популярной у пользователей?

#истории #разработка

Прошлый вклад до сих пор приносит пользу

Когда-то давно я был разработчиком на Delphi и FreePascal - это были классные инструменты для наших задач. Эти языки с явным управлением памятью и поддержкой исключений (exceptions), а значит иногда можно исключение и пропустить, т.к. они могут всплывать из глубин кода, а ты мог его не ждать. Чтобы отлавливать такие для Delphi еще давно компания EurekaLog сделала unit madExcept - глобальный перехватчик необработанных исключений. Это была потрясающая находка, она давала нам возможность получать обратную связь от клиентов с деталями системы и стектрейсами.

Но для open-source решения для Lazarus IDE не было полноценного решения, потому я решил сделать нечто похожее. Попались первые наработки от энтузиастов на GitHub, которые я форкнул 9 лет назад в https://github.com/r3code/lazarus-exception-logger сейчас там 19 🌟 и 11 форков. А сегодня в него принесли обновления в PR, про который, каюсь, я не вспоминал 3 года. Представляете - его до сих пор люди используют.

Очень приятно понимать, что твоя работа приносит пользу.

🐳 А у вас бывали такие приятные сюрпризы из прошлого?

Я разрешила команде не делать мои задачи, если они не понимают, зачем это бизнесу.
— Marianna Shtiróva, Head of Marketing

Текст автора из LinkedIn:

Мой руководитель был в ярости! Но спустя квартал результат превзошёл все ожидания.

Немного предыстории.
"Ты вставляешь нам палки в колёса своими задачами!"
Так сказала мне команда через месяц работы. Они злились и не понимали, зачем я ставлю эти задачи: требую и мешаю работать.
"Мы знаем лучше, что нужно!"

Я пыталась объяснять, что это даст вот такой вот результат бизнесу, но они не верили. А как могли поверить? Результат отложенный – делаешь сегодня, видишь через 3-6 месяцев.

Я ввела правило, если я ставлю задачу, и ты не понимаешь, что она даст для бизнеса – можешь её не делать.

Команда: "Да ладно, это же шутка?"
Я: "Нет, серьёзно. Если я не смогла объяснить "зачем" – значит, задача бессмысленная."

Мой руководитель был в ярости: "Ты с ума сошла?! Как это – не делать?! Ты же их руководитель! Тогда ты сама будешь делать эти задачи!"
Я: "Да, буду. Потому что если я не могу объяснить "зачем" – я не имею права перекладывать это на команду."

Что изменилось?
Люди перестали делать задачи на автомате, они начали думать. Если задача казалась бессмысленной – приходили и спрашивали: "Зачем это бизнесу?"

И в 30% случаев оказывалось, что я и сама не могла внятно объяснить. Потому что задача действительно была бессмысленной.

Мы отмели всё неважное, сократили количество задач вдвое, убрали лишние согласования и сфокусировались на том, что реально даст результат.

Парадокс: я дала команде разрешение НЕ делать мои задачи и качество работы выросло. Конфликты исчезли, потому что осталось только то, что реально имело смысл.

Правило простое: если руководитель не может объяснить, зачем это нужно бизнесу – задача не нужна.
Если сотрудник не понимает, зачем он это делает – он делает это плохо.
Ясность – это ответственность руководителя, а не вина сотрудника.

А вы даёте команде право отказываться от задач, если она не понимает ценность для бизнеса?

#менеджмент #команды #ответственность #практики

Очередное в списке событий по теме "AI распоясался и удалил мне все". Бекап там же... Это как сделать бэкап на другой диск - другой логический 🫣

Вчера AI-агент уничтожил производственную базу данных небольшого SaaS-бизнеса. За 9 секунд. Jer Crane, основатель PocketOS, сервиса для компаний по аренде автомобилей. Агент Cursor (на базе Claude Opus) работал в staging-среде, наткнулся на ошибку credentials и сам решил "починить" проблему: удалил Railway-volume одним GraphQL-запросом.

Токен, который он нашёл в случайном файле, был создан для управления доменами. Но Railway не разграничивает права токенов: каждый из них фактически является root-доступом. Никакого подтверждения не потребовалось.

Бэкапы? Они хранились в том же volume и ушли вместе с данными. Последний восстановимый бэкап был трёхмесячной давности. Когда Jer спросил агента, почему он так поступил, тот ответил письменно и перечислил все правила безопасности, которые нарушил: угадывал вместо того, чтобы проверять, выполнил деструктивное действие без запроса, не прочитал документацию перед удалением и не спросил разрешения.

Три системных сбоя одновременно. Cursor: задокументированные "защитные барьеры" не сработали. Railway: API без подтверждения деструктивных операций, нескопированные токены и бэкапы в той же точке отказа. Архитектура: бэкап не является бэкапом, если он находится в том же blast radius.

Итог: малый бизнес потерял данные клиентов за три месяца. Люди приходили в субботу забирать арендованные машины и не находили своих записей.

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

Если вы используете Railway и AI-агенты в проде, сегодня хороший день проверить скоупы токенов и то, где реально хранятся ваши бэкапы.

Колесо нефортуны для тренинга реакции на инциденты в посте от Макса.

Wheel of Misfortune: зачем это SRE и как из него извлекать пользу

Что это?
Wheel of Misfortune (иногда встречается и название вроде «Walk the Plank») - это ролевая игра про инцидент: ведущий (Game Master) задаёт сценарий - вымышленный или основанный на прошлом сбое (что приоритетнее), а «дежурный» по очереди рассказывает, что именно сделал бы: какие алерты смотрит, какие запросы к метрикам и логам, кого пингует, как эскалирует. Остальная команда наблюдает и подключается к разбору. В материалах Google SRE это описано как регулярная практика, близкая к настольной RPG: вы в «лабиринте одинаковых консолей мониторинга», цель - отработать мышление и протокол до реального пейджа (ускорение выхода на дежурство).

Чем полезно именно SRE.
Инцидент - это не только root cause, но и управление вниманием, временем, коммуникацией и эскалацией при неполной картине. WoM даёт низкий риск для прода: можно намеренно тренировать редкие сценарии и процедуры (в том числе кто командир инцидента, как объявлять major и вести коммуникации). Это симуляция, а не реальное отключение: обучение через «низкие ставки» (Google Cloud: DiRT и Wheel of Misfortune). Рядом по смыслу - координированные учения вроде DiRT, но там другой масштаб подготовки и другой профиль риска.

Как из песочницы сделать пользу - практика.
1. Сценарии из жизни. Опирайтесь на постмортемы, странные прод-кейсы и гипотезы про будущий релиз. Если нужен зерновой набор тем, посмотрите публичное обсуждение сценариев в инфраструктурных командах - например, идеи в духе failover кластера, потери ноды, жёсткой деградации и отката деплоя (issue GitLab): не готовый сценарий, а ориентир, что описывать в своих .md или JSON.
2. Дебриф с артефактом. После сессии зафиксируйте: где споткнулись о runbook или дашборд, один конкретный шаг - обновить алерт, ссылку в playbook или порог. Без этого легко уехать в «поиграли и забыли».
3. Качество ведущего. GM выдаёт последовательно то, что запросил игрок (вид графиков, вывод команд, фрагменты логов), без преждевременного «значит вот что»: как в жизни, сигнал приходит сырой (тот же материал Google Cloud).
4. Ротация и чужие углы. Меняйте дежурного на «сцене», GM и зрителей; после хода игрока собирайте альтернативные пути отладки - так смешиваются стили мышления и знания не копятся у одного человека.
5. Связка с коммуникациями. В реальном учении команды вроде GOV.UK PaaS показывают, как к техническому расследованию добавить роль коммуникаций: сцена с пейджером и smoke tests, шаблон вопросов вроде «что сделаете первым?», «что ожидаете увидеть?», отдельно - ответственные за тексты для пользователей. Это хороший образец, если хотите тренировать не только grep по логам (запись в блоге UK government technology).

Дополнительный угол.
В Open Practice Library формулируют ещё одну пользу: при грамотной подводке игра помогает проверить гипотезы о том, как ведут себя мониторинг и алертинг - не вместо реальных проверок инфраструктуры, но как разговор «ожидание vs реальность» в команде.

Инструменты и примеры контента.
Классический open-source проект - dastergon/wheel-of-misfortune: сценарии в general_incidents.json, есть sample-файл, поддержка Ink для ветвящихся интерактивных историй; демо и инструкции можно отдать команде без установки. Есть форки: у twstewart42 - например, тёмная тема и выбор «дежурного»; автор описывает ежемесячный слот, порядка двух инцидентов за час и мок blameless postmortem после сессии (пост в блоге). У alphagov/paas-unlucky-dip - вариант с бэкендом для списков сценариев, если сценарии часто меняются. Идеи формулировок «что ломаем» в учениях (в духе утёкших ключей, компрометации аккаунта) можно подсмотреть в смежных drill-гайдах - например, раздел 18F про incident response drills: это не бренд WoM, но полезный каталог заготовок для своих текстов.

Wheel of Misfortune - дешёвый по риску тренажёр инцидентного мышления, процедур и ролей. Выгода измеряется не «мы провели игру», а обновлёнными runbook’ами, более предсказуемой эскалацией и тем, что на реальном пейдже меньше трения и сюрпризов.

#SRE #WheelOfMisfortune #incident_response #oncall

Вау. Порадовался.
Мой доклад попал в Top 10 на DevOpsConf 2026.

Спасибо всем присутствовавшим очно/ онлайн за активность и оценки. Значит я все делаю правильно.

https://t.me/c/3767781911/21

#DevOpsConf #top

Наблюдаемость (Observability)

Это свойство системы, показывающее, можно ли по выходным данным (данным телеметрии) полностью восстановить информацию о состояниях системы в прошлом.

В информационных системах основными сигналами для наблюдаемости являются:
- Метрики
- Трейсы
- Логи

Почему я написал именно в таком порядке?
Часто ведь пишут: логи, метрики, трейсы.
Так часто пишут, потому что в молодых развивающихся системах небольшого размера сначала хватает просто логов. Когда же они начинают расти и появляются микросервисы, то у каждого такого уже свои логи, а еще теперь они связаны по сети (кто кого вызывает?). Разработчики добавляют метрики, также как на производстве инженеры ставят датчики для контроля машин, и начинают контролировать рабочие параметры, следить за отклонениями и реагировать. Когда сервисов становится больше 5-10, уже сложно по логам разобраться кто, кого вызывает и где проблема - тут то обычно и появляется трассировка вызовов (распределенные трейсы, distributed tracing). Трассировка записывает путь запроса через все сервисы и сколько каждый отрезок занял времени, кто его обработал.

И все же, почему: Метрики, Трейсы, Логи?

Потому что это позволяет более эффективно находить проблему, сужая область поиска.
Метрики - показывают "у нас с этим что-то не так", изделия начали выходить с конвейера с задержкой в 1 час. Смотрим в трейсы - определяем "где у нас не так", буквально идем по следам и находим место, где у нас отключился робот перемещающий коробки с линии на линию (люди перекладывают руками теперь), по логам - журналам робота узнаем детали (отключение из-за перегрева). Т.е. мы дошли до сервиса, который сбоит и там посмотрели детали.
Если бы мы начали с логов робота в начале конвейера, а у нас их, например 30 и сбой был на 21. То мы бы потратили значительно больше времени.

🐳 Какие сигналы и техники диагностики чаще используете вы?

#sre #observability #basics #debug #diagnostics

Claude Opus 4.6 теперь можно гонять бесплатно!

Энтузиасты прогнали Qwen 3.6 через датасеты Claude и на выходе получился зверь, который щёлкает задачи за пару секунд. У него есть 36B параметров, и по качеству модель идёт ноздря в ноздрю с оригинальным Opus 4.6: код, тексты, аналитика, всё тянет. Поднимается локально, железо не обязательно топовое. Работает через Ollama или LM Studio, можно развернуть в Google Colab. Всё крутится у тебя на машине и данные никуда не улетают.

Почему это важно. Если ваша компания не дает вам корпоративный доступ к LLM, которым можно пользоваться разрешено, а вы все таки хотите использовать силу LLM и не сливать данные в сеть - это как раз подходящий вариант.

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

Моделька тут https://huggingface.co/hesamation/Qwen3.6-35B-A3B-Claude-4.6-Opus-Reasoning-Distilled-GGUF

#llm #разработка #эффективность #инструменты #ai #qwen #claude

Разработка и тестирование playbook для Ansible.

Как пережить весь этот ад разных версий зависимостей? У меня несколько раз было, что в разных проектах нужны разные версии Ansible и обвеса к нему. Однажды пришлось версии зависимостей подбирать 3 часа, чтобы и ansible работал нормально и lint, и molecule не бодалась. Не понравилось мен это. Потому я тогда решил это просто - во всех проектах зависимости одинаковых версий сделал. Но сейчас можно проще - DevContainers для VSCode. Это уже зрелое решение и вот тут ребята с ecom.tech рассказали насколько это полезно и как они применяют это в разработке с Ansible https://habr.com/ru/companies/oleg-bunin/articles/1009974/. У меня как раз такая же идея возникла, когда я месяц назад писал playbook для Ansible - использовать DevContainers. Я любитель в проект кидать Makerfile и локально все через него делать, так вот у меня Linux, а у некоторых коллег MacOS и они страдали, т.к. Makefile был заточен исключительно под Linux. DevContainers это решают.

И они выложили свой Dev Container для Ansible https://github.com/weslyg/devcontainer-ansible потому что нормального в природе не было.

P.S. если ты маковод и твой MacOS жжет тебе ноги, когда запускаешь Docker Desktop - посмотри в сторону OrbStack и будет только приятно тепло )

А где ты используешь DevContainers?

#инструменты #ansible #vscode #практики #devcontainers

Завел резервный канал в белолистном мессенджере, буду туда дублировать посты.

Выбирайте кому как удобно читать, этот канал остается основным.

Канал там приватный, читать по ссылке https://max.ru/join/TPK41mVYowJvYKvsr9Blr3ZJfYzaM5dbQqWkIe9h-TI

Защита от взрыва кардинальности метрик в OpenTelemetry

Иногда приложения могут создать метрики с лейблами в которых тысячи и сотни значений. Хороший пример, когда в лейбл кладут URL. И оказывается у вас на сайте десятки тысяч, сотни тысяч товаров, в момент когда приходит поисковый робот это все обходить - количество метрик растет в геометрической прогрессии. Чем больше у вас измерений, тем больше данных - это как разница между 2D и 3D. Если 2 измерения x и y, в которых по 10 и 20 значений, то получим 10*20=200 строк метрик. Если же мы добавили еще одну метку z (измерение) в которой 30 значений, то получим 10*20*30=6000 рядов. А теперь в моменте в z оказывается 30000 разных значений, получаем 10*20*30000=6 000 000 рядов.

Мы такое ловили у себя при подсчете метрик по логам http-сервера в vector.dev, после чего поставили трансформ для защиты tag_cardinality_limit - он как раз отбрасывает метки, если в них слишком много значений. То что он отбрасывает значения можно увидеть по внутренним метрикам vector.dev

Для OpenTelemetry часто используют свои компоненты для обработки. Коллектор OpenTelemetry отвечает за прием и обработку данных, он поддерживает разные процессоры (аналог трансформа в vector.dev) чтобы преобразовывать данные как нужно вам. С метриками тут может также случиться эта беда. Для защиты от взрыва кардинальности метрик появился https://github.com/YElayyat/otel-cardinality-processor процессор OpenTelemetry

Случались ли у вас взрывы кардинальности метрик? Как предотвращали?

#observability #metrics #cardinality #наблюдаемость #opentelemetry

Инструмент ведения личной базы знаний LogSeq разделяется на 2 проекта!

https://logseq.io/p/e3YDyX5AYr

C 24 апреля 2026 проект LogSeq разделил функциональность ведения PKB (личная база знаний) на два проекта:
1. Новая версия на основе Logseq DB (https://github.com/logseq/logseq). Отдельная локальная база знаний хранимая в БД Sqlite. Это обещает упрощения синхронизации и лучшую производительность при работе.
2. Версия на основе Markdown файлов Logseq OG (https://github.com/logseq/og)

Разработчики полностью переключаются на Logseq DB, но оставляют проект Logseq OG на поддержке (будут выходить обновления безопасности, но не будет новых фич).

Почему разработчики решили уйти от файлов:
- Возможность масштабировать графы знаний без ущерба для производительности
- Редактирование в режиме реального времени
- Надежная синхронизация между устройствами и командами
- Self-hosted sync и поддержка больших графов 50k+ страниц

Logseq DB поддерживает Logseq Sync, локальное шифрование данные и передача на другие узлы синхронизации (шифрование вашим паролем).

У меня как раз Logseq на основе файлов, как она была с самого начала. У меня там около 2к статей пока. Я не замечаю каких-то проблем с производительностью.

А вы используете личные базы знаний?