Замечали, что скриншоты - это один из языком общения в поддержке и инцидентах?

Этот инструмент настолько привычный, что даже не задумываешься, что когда-то его просто не было!

Технически под капотом все прозаично. Экран - это просто массив точек в памяти. Операционная система берет состояние кадрового буфера и пишет его на диск. Ничего магического.

Интересно, что раньше это считалось инженерной функцией. Она была даже старых Nokia 15, но нельзя было просто так сохранить экран. Нужно было лезть через компьютер и специальные утилиты.

Сейчас это база в любой ОС, хоть в ПК, хоть в смартфоне.

Помню когда впервые увидел функцию распознавания текста с сриншота в MacBook - сильно обрадовался, т.к. мне тогда в 2020 приходилось часто искать проблемы в сессиях пользователей, а на скриншотах сессия была как UUID в 32 символа. Такое пока наберешь - уже задолбаешься, а еще и ошибешься, и снова задолбаешься, но уже - проверять.

А вы часто сохраняете крины ошибки для баг-репортов или предпочитаете логи?
Скриншоты логов? (для ценителей 😁)

#SRE #engineering #OS #tech_history #incident_management

AI-разработка или Vibe-кодинг. Удалось сделать продукт не трогая код руками. Что же понадобилось?

У меня как хобби осталась разработка, и иногда знакомые ко мне обращаются по этому вопросу за консультацией. Часто мы проводим 1-2 встречи, где я помогаю откопать реальную "боль" клиента, ведь только тогда можно предложить достаточно точное решение.

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

Ai-агентом выступал z.ai в VS Code с расширением Roo Code. Я описывал спецификации в файлах и отдавал агенту, а он писал HTML, CSS, JavaScript. Мне помогал мой опыт веб-разработки , то что я со всем этим работал и знаком, позволило мне давать правильные корректировки AI-агенту, когда он начинал делать лишнего или не так. Конечно это позволило набить руку и начать лучше применять агентов и в рабочих задачах.

Итогом стал proof of concept с одной 3D-моделью и простой логикой расчета цены за изделие.

🧙‍♂️ Что хочу сказать: мне очень нравится проводить клиента именно через этап от "хочу" до "ага-вот что я на самом деле хочу", это позволяет сделать более простое решение и гораздо быстрее, а значит Time-to-market будет ниже. Мне это чем то напоминает linux-философию с мелкими утилитами для решения одной проблемы. Здесь также, нам надо получить результат как можно быстрее и союкорректировать - считай истинный Agile с реальной ценностью.

#не_sre #разработка #разработка_на_заказ

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

История 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