Я разрешила команде не делать мои задачи, если они не понимают, зачем это бизнесу.
— 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к статей пока. Я не замечаю каких-то проблем с производительностью.

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

AI SRE Summit 2026: выжимка из заметок

Привет, киты 🐳.

Наткнулся на пост на реддите и решил поделиться.

AI в SRE - это уже не демо, а продакшен. Вопросы сместились с "как это работает" на "кто отвечает, когда оно ломается".

Ключевые тезисы

1. Стоимость и надёжность - это одно целое
ИИ-агент, который лечит инцидент автоскейлингом, может накрутить счёт за облако на $50K. Если в ваших SLO нет бюджета - вы не контролируете надёжность.

2. Нельзя наложить ИИ на сломанную платформу
Broken platform + AI = более сложный баг, который сложнее отладить. Сначала наведите порядок в конфигурациях, логировании и деплое. Потом добавляйте агентов.

3. Observability теперь для машин
ИИ-агенту нужна структурированная, семантически богатая телеметрия. Если логи - это "text/plain с примесью надежды", агент будет гадать. Гадание в продакшене = инцидент.

4. У ИИ-агента нет владельца
Кто отвечает, когда автономный агент неправильно интерпретировал метрику или запустил неверный скрипт? Пока это серая зона. Нужны чёткие рамки: что агент делает сам, а где нужен человеческий апрув.

5. Роль SRE трансформируется
Было: тушим пожары, пишем ранбуки, дежурим.
Становится: проектируем границы автономии, пишем политики, интерпретируем решения ИИ.

Что уже сделать бы надо

- Добавьте бюджетные лимиты (деньги) в error budgets. Нет денег - нет надёжности
- Структурируйте логи под ИИ: векторизуйте, тегируйте, давайте контекст. Logfmt лучше свободного текста
- Введите режимы для агентов: автономно / с апрувом / только рекомендации. Переключайте по уровню риска
- Документируйте решения ИИ для постмортема и обучения
- Тренируйте команду на гибридных сценариях: человек + ИИ, а не "или-или"

Что я думаю

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

ИИ - усилитель процессов. Хаос ускорит хаос. База + ИИ = масштабирование надёжности.

Вопрос: если агент чинит инциденты, кто чинит агента когда он сломался?

P.s. вспоминается статья 1982 г "Иронии автоматизации", проблемы те же

The Ёп - да, ёп, че я такое в вел?!

Привет, киты 🐳!

Я чето задолбался исправлять команды в консоли, лень толкнула искать исправлялку - и я нашел thefuck. Работает оно неплохо, но fuck! FUCK это длинно и писать тоже ЛЕНЬ )

Потому, ёп - вот что звучит в голове )
И ёп - то что подходит мне и тебе 😆 Ёп - он тот же fuck, только короче 😈

Потому, ставим себе Ёп! и пишем меньше 😜

https://github.com/r3code/theep

#theep #tools #эффективность #инструмент #хулиганим

Ребят, не по теме SRE, а по теме контактов. Знакомый ищет спеца кто делает SEO продвижение в Google по России. Если у вас есть проверенные люди — прошу накидать контактов в личку @r3code.

#запрос #контакты #неформат

1:1 - это не терапия, а место, где можно по-человечески поговорить не только о работе.

Уйдем чуть-чуть от технички в более простые, но не менее важные вещи.
Раньше я воспринимал 1:1 довольно утилитарно.

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

Потом в Додо мне показали другой формат.

Оказалось, что 1:1 - это не только про задачи, перформанс и “что у тебя по проекту”. Иногда это маленький safe space, где можно сказать:
- “я устал”
- “я не вывожу”
- “меня бесит вот эта штука”
- “я не понимаю, куда дальше расти”
- “у меня сейчас сложный период вне работы”

И нормальный руководитель в этот момент не становится психологом, спасателем или мамой. Но он начинает видеть контекст.

А контекст решает.

Если руководитель видит только карточки в трекере, он управляет карточками.
Если он видит человека и контекст вокруг него, он может управлять нагрузкой, ожиданиями, ростом и рисками.

Для меня это прям поменяло отношение к 1:1. Это перестало быть встречей ради встречи и стало нормальным инструментом управления.

Что, на мой взгляд, делает 1:1 полезным:

1. Регулярность
Лучше стабильные 30 минут раз в 1-2 недели, чем “созвонимся, когда будет тема”.
Потому что “темы нет” - это тоже состояние. Иногда самое важное всплывает не в начале, а на 17-й минуте после стандартного “да вроде всё нормально”.

2. Это не статус-митинг
1:1 - это не место, куда надо переносить весь таск-трекер.
Статусы должны жить в таск-трекере, стендапах, PR, документах - где угодно, но не съедать весь 1:1.
Задачи можно обсуждать, но обычно за ними должна быть настоящая тема: блокер, конфликт, перегруз, непонятные ожидания, потеря мотивации.

Если весь 1:1 - это “ну что там по тикету?”, то поздравляю, вы изобрели плохой дейлик на двоих.

3. Повестка должна быть с двух сторон

Хорошо, когда и руководитель, и человек заранее накидывают темы.

Если повестку всегда приносит только руководитель, встреча быстро превращается в “начальник что-то хотел”. А 1:1 всё-таки должен быть местом, где человек тоже может принести то, что ему важно.

4. Safe space создаётся поведением, а не словами

Недостаточно сказать “у нас тут безопасное пространство”.
Безопасность появляется, когда тебя не перебивают, не обесценивают, не используют личное против тебя через месяц и не превращают каждую честную фразу в performance issue.

Доверие строится медленно, а ломается очень быстро. Классика, ничего нового.

5. Личное можно обсуждать, но аккуратно

1:1 - не исповедь и не терапия. Руководитель не должен лезть человеку в душу.

Но если человек сам говорит “у меня сейчас дома тяжело” или “я не вывожу”, нормальная реакция - не копаться в деталях, а понять, как это влияет на работу и чем можно помочь.

Где-то это пересборка нагрузки. Где-то отпуск. Где-то более чёткие ожидания. Где-то просто “окей, я понял, давай в ближайшие пару недель не будем накидывать сверху”.

6. Нужны follow-up’ы

Если на 1:1 договорились что-то сделать - это надо потом вспомнить.
“Я поговорю с командой”, “посмотрю промо-план”, “помогу разгрузить”, “вернусь с ответом” - это не декоративные фразы, а action items.

Нет follow-up’а - нет доверия. Всё очень просто и очень больно.

Хороший 1:1 после себя оставляет чуть больше ясности, спокойствия или движения вперёд.

Для человека - это место, где его слышат не только как исполнителя задач.
Для руководителя - это ранний мониторинг состояния команды.
Только вместо CPU, latency и error rate у тебя мотивация, усталость, ясность, доверие и рост.

И если после 1:1 ничего не меняется ни в голове, ни в действиях, ни в отношениях - возможно, это был просто ещё один календарный алерт без runbook’а.

А у вас 1:1 больше про задачи, про людей или “ну надо же иногда созваниваться”?

#sre #teamhealth #onetoone #leadership