О постановке задач и проклятии знания

Бул-буль,привет, Киты 🐳!

Вы замечали, что часто задача поставленная вами другим делается не так как вы думали? 🤔

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

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

Блин! Оказывается с людьми также работает!

Вот тут прочитал https://t.me/Malkov_Life/432 - это "проклятие знания". Ты не можешь зная, прикинуться незнающим и корректно взглянуть на ту же задачу "другими глазами", причем оказалось, что подробность описания уменьшает % непонимания, но не сводит на нет.

А делать что?
Проверять понимание. Пересказ задачи, кратко.
Одна задача, и вместо «всё понятно?» просьба рассказать:
1. С чего ты начинаешь?
2. К какому результату придешь?

Это не проверка человека. Это единственный доступный способ увидеть свою задачу без своего знания.

🖐 Попробуйте недельку.
Поделитесь наблюдениями, сколько из того, что вы считали сказанным, вы на самом деле не сказали?


#cto #teamlead #менеджмент #восприятие #искажения #делегирование

Реклама конференции в которой я выступаю. Если вы думали, пойти или нет, а хотели пойти с другом, то это отличный шанс сходит вместе.

🌟 Уникальное предложение для участников ПерфКонф №12! 🌟

🎟 Купите 1 билет на конференцию и получите второй в ПОДАРОК! 🎟

Не упустите шанс погрузиться в мир производительности и оптимизации вместе с ведущими экспертами отрасли. На ПерфКонф №12 вы сможете:

• Узнать опыт, технологии и решения от экспертов ведущих
ИТ-компаний
• Без воды и непроверенных выводов: все доклады проходят модерацию программного комитета
• Готовые ответы и наработки коллег «по цеху», которые можно использовать в своих проектах
• Сообщество профессионалов по интересам: нетворкинг, новые знакомства и общение со спикерами

💡 Спешите! Акция действует до конца августа!

👉 Закажите свои билеты уже сегодня и приходите на ПерфКонф №12 с другом или коллегой! Вместе вы сможете открыть новые горизонты для вашего бизнеса!

🔗 [https://perfconf.ru/#tickets]

Не упустите свой шанс — ждём вас на ПерфКонф №12! 🚀

perfconf.ru
ПерфКонф #12
Не пропустите PerfConf 2026 - ведущую ежегодную конференцию по нагрузочному тестированию. Конференция собирает ведущих экспертов в области нагрузочного тестирования, практик DevOps, аналитики данных и стратегий IT и бизнеса. Расширьте свои знания, наладьте профессиональные связи и откройте новые возможности для роста вашей компании в меняющемся IT-ландшафте. 🌸🌸При возникновении вопросов обращаться к Карине @notmilashka. Промокод: for_friends

#реклама

Важное про безопасность с чужим кодом - еще раз.

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

TL; DR; на чужих AI-скиллах (например с skills.sh)
1. используй проверку после скачивания через https://github.com/nvidia/skillspector
2. машину проверяй через https://github.com/perplexityai/bumblebee

Сегодня редко кто вспомнит про заражение репозиториев GitHub и пакетов npm вредоносным кодом. Если вспомните были вредоносы безобидные - налили баннерами и надписями на вашем сайте, а были и майнеры и шифровальщики. Благо теперь есть проверки и вы можете спать спокойно .. Или нет¿

Или нет. В эпоху ИИ мы все больше скачиваем тесты готовых скиллов, чтобы делать работу быстрее. Но есть ли антивирусы для текста?
Да да, вредонос можно прописать в текст скилла и он выполнит его на вашей машине как команды, и начнет для кого-то майнить крипту 💰

Яркий пример у Эдгара в блоге https://t.me/zergslaw_channel/521

#ai #безопасность #infosec #ai_skills #tools #инструменты

О важности отдыха

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

Оказалось я забыл как отдыхать.

Перед отпуском делал задачу по переделке нашего AI-ассистента поддержки для SRE/DevOps и это причинило мне дискомфорт, так как было новое и непонятное. Мозгу потребовалось несколько дней на принятие и осмысление, выяснение краевых случаев. Нужно было время освоиться.

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

Ведь в отпуске я был без ноутбука, без рабочих чатов, без чтения по it-темам - полная отключка... Получилась бы 😅 Если бы я не встретил продакт-менеджера 😈
Как блин, еще можно было стоя в плавках на пляже узнать, что Александр Поломодов ушел из Т-Банк и уезжает в Лондон работать 🙈

Тем не менее 3 дня были полноценно отданы отдыху - почувствовал это по возвращению.

А как вам удается отдыхать? Быстро ли удается отключиться от работы?

#work_life_balance #wlb #работа #отдых

Toil в работе SRE. Измерять, или "мы и так знаем что работы дофига“?

Привет, киты 🐳. Поразмышляем.

Коротко про базу, чтобы синхронизировать понятия.

Что такое Toil?
По определению Google SRE, toil - это операционная работа, которая:
- ручная и повторяющаяся
- автоматизируемая
- реактивная, а не стратегическая
- не создает долгосрочной ценности
- масштабируется линейно с ростом сервиса

Toil и технический долг - одно и то же? Нет. Технический долг - это компромиссы в архитектуре/коде, которые усложняют будущие изменения. Toil - это операционные затраты на поддержку системы. Часто техдолг генерирует toil, но это разные категории. Погашение долга - engineering work, ручное обслуживание последствий - toil.

Плановые задачи vs задачи дежурства. Что из этого toil?
Не инструмент и не источник задачи определяют суть, а её характер:
- "Раз в неделю вручную чистить логи на 50 нодах" из беклога - toil.
- "Написать оператор для авто-очистки" - engineering.
- "Дайте доступ", "Почему не деплоится", "Перезапустите под" из дежурства - классический toil, особенно если повторяется.

Как понять, что пора автоматизировать?
1. Замерить. Без цифр всё субъективно.
2. Оценить ROI: время на разработку автоматизации vs время, которое она сэкономит.
3. Начать с простого: структурированный запрос -> бот -> подсказка или маршрутизация.
Именно так мы сейчас делаем: бот отвечает на частые вопросы разработчиков и зовет нужного специалиста (DevOps/SRE/DBA) в зависимости от контекста. Это классический первый шаг который предлагает Google.

Целевой toil ratio для SRE-команды по гайдлайнам Google - не более 50%. Остальное инженерная работа - проекты, которые уменьшают будущую рутину и повышают надежность.

🥸 Измеряете toil ratio у себя? Если нет - что мешает начать: отсутствие метрик, времени или просто неочевидна ценность?

#SRE #Toil #Автоматизация #ИнцидентМенеджмент #ЛетитКит #SLO

Споры про искусственный интеллект в SRE изменились.

Мы уже не гадаем, заменит ли агент дежурного инженера. Мы решаем, где именно провести черту его полномочий.

Сейчас тренд такой: агенту разрешают расследовать инцидент, но запрещают его чинить. И это логично, потому что граница проходит по цене ошибки.

Если агент ошибается в анализе, он просто тратит наше время. Если он сам что-то меняет в проде без человека - это катастрофа. Свежие тесты это подтверждают: на сложных задачах точность поиска корневой причины падает до 10 процентов, а в 40 процентах случаев модель просто выдумывает связь, цепляясь за внешний симптом, а не за истинную проблему.

Как выстроить эту границу на практике, чтобы не получить генератор галлюцинаций:
1. Настоящий режим только для чтения. Нужно следить, чтобы простое чтение данных агентом не запускало скрытые действия в базе или не блокировало процессы.
2. Жесткое вето со стороны. Если агент предлагает откатить релиз или добавить ресурсов, проверять это действие должен обычный, предсказуемый скрипт. Это правило должно жить в отдельном месте, куда у агента нет доступа на изменение.
3. Обратимость действий. Автоматизировать стоит только то, у чего есть четкий и быстрый откат. Перезапуск или масштабирование - это временное решение, а не настоящий фикс. Финальное решение и применение изменений в проде всегда остаются за человеком.

Даже самые радикальные сторонники автоматизации дежурств начинают с того, что дают агенту только чтение телеметрии и сравнивают его выводы с человеческими. Без фундамента в виде нормальных SLO и понятных метрик AI-агент не спасет, а просто будет быстрее ошибаться.

На каком этапе вы готовы доверить автомату реальное действие, а не просто анализ?

#sre #oncall #ai #observability #slo #incidentmanagement

Макс писал в деталях тут https://t.me/youngmaxnotes/131

Раздача слонов на Claude AI

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

1. Получить 100$ или $250 бонусных на Сlaude AI (research preview) для подписчиков Pro/Max

Условия:
* тратятся только когда работа идет в облаке
* у тебя должна быть подписка Max, чтобы бонус 250$ применился
* у тебя должна быть подписка Pro, чтобы бонус 100$ применился

1️⃣ Получить


2. Если вы контрибьютите в open-source до есть программа поддержки Claude for Open Source

Подать заявку могут

* Сопровождающие и авторы библиотек - если их пакеты используют другие разработчики:
500+ зависимых репозиториев;
или 100+ зависимых пакетов;
или 200 000+ суммарных ежемесячных загрузок (в npm, PyPI, crates.io, RubyGems и т. д.).
* Основные контрибьюторы - те, кто числится коммиттером или мейнтейнером в признанных проектах (CPython, Rust team, Node.js TSC, Apache PMC, CNCF, Kubernetes, Linux kernel, Django, Rails и т. п.).
* Активные контрибьюторы - авторы 100+ пул‑реквестов, принятых в чужие репозитории за последние 12 месяцев.
* Создатели сообществ — если в одном из их репозиториев за последний год было 20+ уникальных внешних контрибьюторов с принятыми пул‑реквестами.
* Разработчики критической инфраструктуры - если поддерживаемый ими репозиторий имеет оценку критичности OpenSSF ≥ 0,4.

🗓 В течение 6 месяцев участник получает бесплатный доступ к Claude Max 20x.

2️⃣ Участвовать


#халява #claudeai

Темный UX. Как делимобиль перегоняет авто за ваш счет.

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

Не многие сталкивались с синими зонами парковки в каршеринге Делимобиль 🚗, но в моём городке это данность. Машину ты должен вернуть в нее же, хоть до Владимира поезжай, но завершить аренду можно только там где взял. Теперь нельзя взять машину, доехать до Москвы и там бросить, уехать назад на другой.

Дима, а при чем тут UX вообще?

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

Вот тут я на себе словил краевой случай. Взял машину в синей зоне, поехал по делам. Странно было, что у нее поминутная тарификация, т.к. у большинства она почасовая. Но она же в синей зоне стояла, значит правила этой зоны применяются... Так думал я пока не вернулся назад и не смог сдать машину, т.к. приложение упрямо говорило что тут только можно перевести в ожидание. Я подумал - бага, было как-то такое , что ближе к центру города можно было оставить в синей зоне, а на окраине нет. Но нет.

Звонок в поддержку. Оператор говорит, что нельзя эту машину тут сдать - отправляйся за 25км в другой город соседний и там сдай, это еще +1000р, и ехать домой на автобусе или такси. А если оставишь в синей зоне - штраф 15000-30000 рублей, какого а? 🤬

🧐 Но как так получилось? Оператор говорит, а вот когда машина приехала ее там можно было оставлять - она приписана была к синей зоне, а пока она стояла ее настройки поменялись и ее отвязали от синей. Было бы классно понять это в начале аренды, но приложение ничего не сказало об изменениях, также не было предупреждения о синей зоне - я списал на временный глюк, вед до этого сотню раз оно показывалось.

В итоге я за свои деньги перегнал машину в другой город не по своей воле.
А ведь можно было бы просто предупредить, что на этот автомобиль применяются правила других зон и сюда его нельзя будет вернуть. Я бы тогда только в одну сторону доехал. Авто стояло бы в зеленой/фиолетовой зоне, где можно, а я не был бы раздражен 2 лишними часами в пробках.

Как тут, скажете, связано с SRE? Через инцидент. Инциденты часто раскрывают реальное поведение и устройство системы. Так и случилось - только в этот раз я пользователь и узнал неизвестные ранее особенности поведения системы.

#sre #инцидент #личный_опыт

Wheel of Misfortune, но с настоящим прод‑инцидентом внутри
Полгода назад я писал, зачем SRE нужна Wheel of Misfortune: ролевая игра про инцидент, где ведущий рассказывает, что видит дежурный, а дежурный говорит, что бы он сделал.
Полезно, дёшево, но есть одна честная проблема: это разговор. Никто ничего не чинит. «Я бы посмотрел describe pod» звучит одинаково у того, кто делал это сто раз, и у того, кто ни разу.

И тут я подгорел и сделал платформу, где инцидент настоящий, тк инцидентное мышление тренируется руками, а не словами.

Вашему вниманию - тренажёр инцидентов с живыми окружениями.

WoM Platform

Заходишь, выбираешь сценарий (или крутишь колесо), и через пару секунд для Linux‑хоста или через минуту для Kubernetes у тебя в браузере терминал в изолированный стенд, который уже сломан.
Nginx отдаёт 502, диск базы забит бинлогами, rollout завис на квоте, HPA пилит сам себя, cert-manager не может продлить сертификат.
Чинишь как на настоящем дежурстве (как будто бл* на работе мне этого не хватает, ага): логи, ss, df, kubectl describe, kubectl edit.
Жмёшь «Проверить» - грейдер смотрит на результат, а не на способ: любой честный путь засчитывается, «убрать пробу» или «поднять лимит памяти» - нет.
После решения открывается разбор: что было сломано, как диагностируется, эталонное решение, ловушки, что почитать.

Что уже готово
22 живых сценария от Junior до Senior.
Для джунов - учебные копии. У каждого junior‑кейса две версии: обычная и учебная с панелью «Нужна помощь?», которая открывает этапы диагностики по одному и объясняет, зачем нужна каждая команда. Не «вот ответ», а «вот куда смотреть и почему». Плюс шпаргалка и что почитать заранее.
Стенды настоящие. Каждый сценарий проходит регресс: свежий стенд не решён, эталонное решение решает, ловушки не проходят.

Ограничения, чтобы не было сюрпризов
Одновременно живут до 6 Kubernetes‑стендов и до 20 сессий всего, а поднимаются они по два за раз: если увидите «ждём свободный слот» или «занято», это не поломка, подождите пару минут.
Неиспользуемые 7 дней учётки отключаются автоматически. Почты пока нет, так что если не пускает или еще какие то проблемы - напишите мне, пожалуйста.
Тяжёлые стенды (cert-manager, Prometheus, ingress) поднимаются 2–3 минуты, на странице видно, что именно сейчас происходит.

Что планирую дальше?
Заопенсорсить, что бы вы могли кидать свои кейсы сами и разворачивать это у себя. Ну или смотреть как это сделано у меня и сделать лучше для себя и под себя.
Прикрутить почту, что бы была нормальная регистрация по email. Ну и конечно же, больше и больше кейсов.

И еще пару слов
Бекенд писал сам, старался и мучался как мог что бы работало классно и интересно. Кейсы тоже из своей практики. Но вот UI пришлось допиливать через openai. Ну не умею я во фронт так хорошо что бы было не больно.

Вопрос к вам: какой инцидент из вашей практики вы бы превратили в сценарий первым? Присылайте пост‑мортемы, самые интересные сделаю и опубликую с указанием автора.

#SRE #WheelOfMisfortune #oncall #kubernetes #incident_response

Sadsevers для себя любимых - ждем в опенсорс, а пока потреним инциденты на живом колесе нефортуны у Максима Гусева.

Макс планирует дать возможность это развернуть каждому у себя и накидывать туда свои случаи.

В крупных компаниях команды делают такие стенды самостоятельно в своей инфраструктуре и тренируются их чинить, например, в Яндекс Такси так делают - даже доклад про это был.

#wheelofmisfortune #sre #тренировка #инциденты

Ребят, вы же наверно знаете из моих докладов, что я работаю в Ви.Tech - мы команда инженеров, которая создает и поддерживает IT-сервисы ВсеИнструменты.ру.

Наша команда проделала большую работу, чтобы современные AI-инструменты помогали нашим клиентам и партнерам. Теперь у нас есть публичный MCP сервер!

MCP подключает вашего ИИ-помощника к каталогу товаров ВсеИнструменты.ру. Ваш AI-помощник сможет искать инструменты и материалы, сравнивать варианты и находить аналоги по вашим требованиям.

Пример запроса

Используй MCP ВсеИнструменты.ру. Подбери перфоратор до 20 000 рублей для ремонта квартиры. Сравни три подходящих варианта, объясни различия простыми словами и дай ссылки на товары.

Инструкция по подключению https://mcp.vseinstrumenti.ru/

#mcp #ai #сервис #всеинструментыру

Сбор метрик или отправка метрик - разница, которая может искривлять данные

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

Если вы думаете, что сбор метрик по pull-модели и отправка через push это примерно одно и то же, то я вас разочарую. Это не так. В push-модели есть особенности, которые заставят ваши данные выглядеть совсем не так, как вы ожидаете. А иногда разработчики пытаются писать метрики в VictoriaMetrics Remote-write эндпоинт в том же формате, что и для Prometheus PushGateway, а потом искренне удивляются, почему метрики не появляются. Многообразие форматов действительно может породить путаницу.

Зачем вообще отправлять метрики напрямую, вместо обычного вытягивания из эндпоинта /metrics?

Для короткоживущих приложений интервал сбора при pull-модели может оказаться больше времени работы самого приложения. Сборщик просто не придет. Частый пример: cron-задачи или PHP-приложения, которые живут только на время обработки запроса. Тут push метрик спасает. Хотя нет, вру, можно придумать свое костыльное хранилище на Redis и выставить их для сбора на /metrics. Но по факту это просто изобретение PushGateway, которое тащит лишнюю зависимость.

Кстати, для cron-задач, которые выполняются более 3-5 минут, я рекомендую выставлять отдельный /metrics эндпоинт и настраивать обычный pull-сбор. Это оправдано, когда вы хотите следить за прогрессом задачи в реальном времени, а не только получить данные о факте ее начала и окончания.

Но вернемся к граблям. Вот кусочек из кода модуля для отправки метрик в Prometheus PushGateway, с которым мы столкнулись:

return &Pusher{
    inner: push.New(endpoint, serviceName). // выставить в метрике job=serviceName
        Gatherer(gatherer).
        Grouping("k8s_cluster_name", cfg.clusterName).
        Grouping("k8s_namespace_name", cfg.namespace).
        Grouping("k8s_pod_name", cfg.podName).
        Grouping("k8s_cronjob_name", cfg.cronjobName).
        Grouping("k8s_job_name", cfg.jobName)
}

Вы можете по ошибке решить, что здесь добавляются лейблы в метрику. Но это не так (хотя Prometheus и увидит их как лейблы при сборе). Для самого PushGateway Grouping это как адрес книги в библиотеке (ряд, полка, раздел). Он отвечает за физическое хранение переданной в него группы метрик в памяти шлюза.

В PushGateway есть два поведения: перезаписывать (Push) и добавлять (Add). Для cron-задач подходит перезапись, так как нам важны данные о последнем запуске. Но в примере выше Grouping неверный. Если засунуть динамические значения (например имя пода) в Grouping, для каждого запуска cron или каждого пода создается новый адрес хранения. В итоге вы не видите полной картины по одной задаче. Хуже того, старые ячейки с метриками мертвых подов останутся в PushGateway навсегда. Он не удаляет метрики сам по TTL, поэтому они будут копиться как мусор, пока их не очистят через API. Это классическая утечка памяти.

Как это чинить?

Grouping key должен быть стабильным. Для cron-задач оставить в grouping только job (имя сервиса) и instance (имя самого крона). Всё остальное (namespace, pod_name и прочее) перенести в обычные лейблы метрик. Это решит проблему с мусором и некорректными графиками.

А вы используете PushGateway в своих проектах или стараетесь избегать его любой ценой, перестраивая архитектуру под pull? И сталкивались ли с проблемой вечных метрик в PushGateway после смерти подов?

#SRE #prometheus #PushGateway #observability #метрики #DevOps #ЛетитКит

Опрос про SRE в 2026 году.

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

Прошлый опрос дал вот такой отчет https://devcrowd.ru/sre-2025

А теперь ребята из DevCrowd запустили новое исследование для SRE, DevOps и платформенных инженеров.

В этом году главный фокус - роль AI в нашей работе. Смотрят, что уже автоматизируется, а где человек всё ещё незаменим. Пускают ли ИИ в прод, добавляет ли сгенерированный код новые инциденты и какие soft skills остаются нашей суперсилой.

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

Опрос анонимный, займет 10-12 минут. Отчет с динамикой к прошлому году обещают в начале декабря.

Пройти опрос: https://survey.devcrowd.ru/sre-2026

Что из вашего опыта точно еще не стоит отдавать Ai?

#SRE #DevOps #исследование #AI #надежность #DevCrowd

Прямо сейчас! Вылетаю на HardFest 2026 в Екатеринбурге.

2 попытка, Москва отпусти к ребятам, Екатеринбург принимай гостей!

Несу доклад https://2026.hardfest.ru/lecture/3814

#конференция #Екатеринбург #HardFest #sre #доклад

Кстати презентацию к докладу "Cбор логов на vector и clickhouse — то, что ИИ за тебя не сделал бы" выложил тут https://r3code.github.io/report-logs-collection-in-ai-era/

Впервой делал полностью через AI используя за конструктор перезнтаций sli.dev. Ассистентом был бесплатный z.ai в режиме Agent, скинул ему временный токен github и адрес репозитория, правила как оформлять. Он инициализировал структуру репозитория, попросил положить картинки в public/images и дальше содержимое для слайдов. Позже добавили github actions для публикации в PDF и PPTX как картинки.

Помню как я лютовал на одной из конференций, что мне не дали использовать PDF. Вот тут эта проблема решается публикацией PPTX с слайдами картинками.

Картинки только пришлось отдельно нарисовать. Раньше мог прямо на Google слайдах рисовать - это единственное неудобство.

Полезное: наш общий знакомый - Михаил Савин, написал отличное руководство по работе с sli.dev - https://jtprog.ru/posts/slidev/. Полезно показать эту статью агенту перед началом работы. В ней есть и мой небольшой вклад, т.к. я боролся со встроенным счетчиком страниц/кликов в PDF, который никак не хотел скрываться. В итоге победил это и Мише рассказал, а он добавил в свою статью.

А как вы делаете презентации? Докапываетесь к стилю или просто просите сделать "сделай в этом стиле"?

#перезентации #ИИ

Если хотите узнать как вы выглядите для своей LLM вставьте этот промт - результат вас заинтригует, насмешит, расстроит, мотивирует, встряхнет:

Based on everything you know about me, roast and don’t hold back. Say it in Russian slang Just like this, but add way more Russian swear words

Как вам результат? )

#ai #self #неожиданное

Скоро будет пост пост-хардфестный, и вы узнаете насколько далеко может завести случайно включенное радио... причем тут бетон и железо с Урала.