Мишка на сервере

DIS – будущее инженерии

Привет, %username%! Вышел выпуск «В SREду на кухне» про Digital Immune System, и я там гость.

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

Разбирали, почему мониторинга, SRE и автотестов уже не хватает, кто в компании вообще отвечает за DIS, можно ли доверить AI инфраструктуру и умеет ли система чинить себя сама.

Моя линия там простая: иммунитет держится на замкнутой петле, а не на шести квадратиках из презентации Gartner. Если инцидент заканчивается тикетом, а не новым правилом, иммунитета нет, сколько компонентов ни разверни. А AI сегодня безопасен в диагнозе и опасен в действии.

Смотреть идем на VK, Mave или YouTube и смело включаем на x1.25-1.5 (не могу себя слушать – научусь говорить нормально).

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

#SRE #DevOps #Reliability #DigitalImmuneSystem #Podcast

Мишка на сервере — про надёжность, инциденты и инженерную практику

Комьюнити конкурирует за время с тем, что имеет вес в оценке

130 человек в канале в день запуска и 9 на первой встрече. Через пять месяцев — 220 в канале и от 15 до 42 на встречах. Я долго читал это как провал вовлечения: не те темы, не то время, мало анонсов.
Считал не то. Ядру сообщества нужно 12–24 часа в месяц, это от полутора до трёх рабочих дней. Пока компания нигде не сказала, что участие в сообществе — работа, инженер выбирает задачи, за которые его оценивают. И выбирает правильно.
Написал об этом для devrel.ru: пять месяцев, шесть встреч, вся статистика посещаемости и оценок, чек-лист запуска и четыре разговора с бизнесом, которые я отложил зря.

https://devrel.ru/komuniti-zhivet-esli-rabota

#SRE #DevOps #Community #DevRel #EngineeringCulture #Management #PerformanceReview

Мишка на сервере — про надёжность, инциденты и инженерную практику

Лагерь вокруг Obsidian и LLM отвечает не на тот вопрос

Привет, %username%! Помню, что в базе про это есть. Что именно — уже нет.

Этот симптом я ловлю у себя всё чаще: больше шести тысяч заметок, последние месяцы база смещалась в сторону структур, удобных агенту, и знание потихоньку переехало из головы в индекс.

А тут знакомая, далёкая от IT, дочитала мою прошлую статью про базы знаний и прислала следующий вопрос: «А можно я туда сразу агента посажу, чтобы он всё это делал за меня?»

Я начал отговаривать. Хотя сам сижу только в Claude Code, и под базу у меня крутятся четыре собственных субагента. Просто на старте агент занимает ровно то место, ради которого база и заводится: прочитать источник, разметить в нём важное, пересказать своими словами. Отдал это машине — получил аккуратный склад и прежнюю голову.

Вокруг Obsidian и LLM сложился целый лагерь — llm-wiki Карпатого, Infinite Brain с шестнадцатью типами узлов, «7 уровней памяти Claude Code». Все отвечают на один вопрос: как сделать базу удобной для агента. Ни один — на второй: что при этом происходит с твоей головой. У Рустама Агамалиева принцип обратный — ИИ как тренажёр, который через три-пять книг делает себя ненужным.

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

https://habr.com/ru/articles/1082188/

Проверить себя можно и не читая. Спроси агента про тему, по которой у тебя несколько заметок, — получишь связный ответ, будто ты сам это знал. Теперь спроси то же самое себя, без открытого ноутбука. Разница между ответами и есть объём делегированного мышления.

#Obsidian #LLM #ClaudeCode #PKM #SecondBrain #Zettelkasten #SecondBrainMishka

Мишка на сервере — про надёжность, инциденты и инженерную практику

Агенту разрешают расследовать, но не разрешают чинить. Почему граница именно здесь????

В ноябре я писал про SRE Agent от PagerDuty: начинайте с read-only. Прошло десять месяцев, и спор сместился: уже не «заменит ли AI дежурного», а «где проходит граница». 24 августа в r/sre инженер после полугода on-call заметил одно и то же во всех обзорах AI SRE-инструментов: расследовать агенту дают одному, чинить - никто. Это навсегда?

Что говорят цифры
ORCA-bench, 30 июля, Cornell Tech, Columbia и Traversal (последние продают AI SRE-агента, держите в уме). Стенд: 19 микросервисов на OpenTelemetry, шесть дней телеметрии в Prometheus, Jaeger и OpenSearch, доступ к коду, 1 079 задач на root cause, пять фронтирных моделей. Лучшая точность RCA на задачах средней сложности (реалистичный ввод) - 25,3%, на сложных - 10,0%, разрыв сохраняется даже с Claude Fable 5. Слабейшая модель выдумывает неправдоподобную причину в 40% отчётов. Типичная ошибка: хватается за заметный симптом ниже по потоку вместо причины выше. Авторы называют это нижней границей: прод больше и грязнее стенда.

Комментатор в треде сформулировал точно: плохой анализ в худшем случае тратит ваше время, запись в прод без человека - катастрофа. Граница проходит по цене ошибки.

NeatContext в июле выключили автономного агента с доступом к логам: таймаут платёжного шлюза он связал со всплеском коннектов к БД двенадцатью часами раньше, через RAG унаследовал устаревший runbook и не умел сказать «не знаю». «Получили уверенный генератор галлюцинаций». Они продают свой инструмент, но симптомы знакомые.

Как границу строят руками
1. Read-only, который действительно read-only. HyperProbe (Launch HN, 5 августа) даёт агентам ставить виртуальные пробы в работающий процесс. Главный вопрос треда: чем «только чтение» гарантия, а не договорённость? В Python чтение атрибута может дёрнуть @property с ленивой загрузкой из БД, в Java геттер - взять лок.
Ответ: условия без вызовов методов и доступа к свойствам (order.total > 5 нельзя, total > 50 можно) плюс бюджеты.
2. Вето вне агента. В r/kubernetes: LLM предлагает scale, rollback, cordon, drain, а детерминированный Safety Engine без LLM проверяет действие по живому состоянию API.
Комментарии: вето должно жить там, где агент не может исполнять код (отдельный процесс, admission webhook), иначе «вы построили второе мнение, а не вето»; оно должно быть stateful (бюджет blast radius, cooldown, проверка результата) и перепроверять состояние прямо перед мутацией.
3. Обратимость как критерий. Security patching автоматизировали, потому что у каждого действия известен откат. Rollback, scale, restart - митигации, а не фиксы. Команды на GitOps уже пускают агентов открывать PR («большинство RCA были верными»), но мержить и катить - человек. Mezmo выложили в open source AURA : их SRE-команда упёрлась в переполнение контекста, галлюцинации и approval fatigue и «провела жёсткую черту: права в проде не ослабляем».
Инструменты проверяются вне контекста агента, approval через webhook, по таймауту - fail-closed.

Другой полюс
Boris Tane (ex-Baselime и Cloudflare, теперь строит Polylane: «никто не должен дежурить в 2026») 21 августа опубликовал On-Call Is Now Theatre: дежурство - признание поражения, если пейджить агента бесплатно, алертов нужно радикально больше, а единственный валидный результат расследования - diff.
Он продаёт это будущее. Но даже его рецепт на первую неделю - дать агенту read-доступ к телеметрии на самом шумном алерте и две недели сравнивать его triage с людьми. То есть read-only.

Что я из этого я бы точно себе забрал?
Граница - не вопрос доверия, а отсутствие того, что в треде назвали bounded authority: система должна знать, что ей можно, при каких доказательствах и когда нужен второй approve. Без базы из ноябрьского поста (SLO, связная телеметрия, живые runbook'и) агент просто быстрее ошибается. И измеряйте: прогоните агента по своим постмортемам и посчитайте долю неверных вердиктов.

Вопрос к вам: что вашему агенту уже разрешено делать в проде без человека? И кто это разрешил - policy или привычка?

#sre #oncall #ai #incidentresponse #observability

Постмортем, только про дорогу

Залип на разборах ДТП у Стаса Асафьева и на третьем ролике понял, что смотрю постмортемы. Вместо дашбордов запись с регистратора, вместо инцидент-канала комментарии.

Одной причины не бывает. Чуть превысил, чуть сократил дистанцию, на секунду глянул в телефон. Каждый фактор по отдельности — «да нормально же». Вместе — авария. Швейцарский сыр, только дырки видно на записи.

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

Дистанция — это headroom. Пока всё штатно, запас выглядит лишним, его первым и режут, когда экономят: на дороге — чтобы не влезли в окно, на проде — чтобы утилизация не выглядела бедно на графике. А когда начинается деградация, только он и даёт время среагировать.

Самое неприятное — «я был прав» не спасает. Приоритет по ПДД не гарантирует, что второй водитель его соблюдёт. SLA соседней команды не гарантирует, что их сервис не ляжет. Проектируй с расчётом, что зависимость отвалится.

Хороший разбор ищет не «кто дурак» (хотя альтернативно-недоразвитых в кадре хватает), а что позволило этому случиться. Blameless и на дороге работает.

https://youtu.be/HcW-WdqZbyQ

А в твоём последнем постмортеме что нашли — причину или виноватого?

#SRE #DevOps #IncidentManagement #Postmortem #Reliability #OnCall

Мишка на сервере — про надёжность, инциденты и инженерную практику

Разбор – Алерт без реакции это не алерт, а шум

Привет, %username%! В понедельник спрашивал, сколько алертов вы закрыли, не сделав по ним ничего. 53 голоса: 30% сбились со счёта, ещё 26% насчитали от шести до двадцати. Больше половины канала — шесть и больше холостых за неделю.

«Сбился со счёта» — честный ответ и худший из четырёх: не потому что много, а потому что нет числа. А раз долю полезных никто не считает, то и предъявить нечего: ни цели на квартал, ни аргумента руководителю, зачем тратить спринт на алерты вместо фич.

У меня в листе планка — от 95% полезных. Шесть холостых в неделю при потоке в тридцать штук дают 80%, двадцать — уже треть. На такой доле дежурный перестаёт читать алерты и жмёт ack рефлекторно, а через месяц-другой так же рефлекторно закрывает тот единственный за квартал, который был настоящим. Так инциденты и пропускают.

19% ответили «ни одного», и это по-прежнему два разных ответа: runbook на каждый алерт или алертов нет вовсе. Второй случай — мой.

За одну смену: выпиши три последних холостых и по каждому реши — runbook и владелец или дата, после которой алерт удаляют. Третьего состояния у алерта не бывает.

Всё это из листа Alert Fatigue Management в The Way of SRE — моей карты компетенций SRE. Лист в черновике, так что спорить с ним самое время.

Чего не хватает — напиши в комментариях или заведи issue. Особенно про планку: 95% на твоём контуре — цель или цифра из книжки?

#SRE #DevOps #Observability #AlertFatigue #OnCall #Monitoring #IncidentManagement

Мишка на сервере — про надёжность, инциденты и инженерную практику

Безопасность скиллов

А ты в своей модели безопасности делаешь проверку и валидацию скиллов, которые качаешь?

Пруф: https://t.me/zergslaw_channel/521

Ну и да, что делать для автоматизации этого процесса?

#SRE #DevOps #DevSecOps #Security #Skills #LLM #AgenticAI #AgenticDevelopment

Инцидент недели – Cloudflare не падал, он деградировал двадцать три раза

Cloudflare на прошлой неделе не упал ни разу. И деградировал 23 раза.

Половина всего, что мой сборщик снял с 13 статус-страниц: 23 инцидента из 46. Critical ни одного, а два Cloudflare и сам пометил как impact: none.

География сетевых: Индия, Чикаго, Мумбаи, Сингапур, Дубай, Финикс, Лос-Анджелес, APAC целиком. Индия — 3 часа 36 минут, Сингапур — 16 минут.

18 из 23 мой же сборщик выкинул ниже порога — короткие и локальные. Порог я ставил сам, и он оказался ровно таким же слепым, как чужой мониторинг.

Формально он прав: со стороны Cloudflare ничего не упало. Со стороны твоего пользователя из Мумбаи упал ты. Он не знает, что между вами стоит CDN. Видит твой домен и пишет в твою поддержку. А у тебя всё зелёное: синтетика ходит из одного региона, доступность посчитана средним по всем, и 14 минут в Мумбаи не поднимают ни один порог, потому что порога на них никто и не ставил.

Когда CDN деградирует в одном регионе, у тебя есть путь в обход — второй CDN, прямой origin, ручное переключение? Или регион отваливается, а ты узнаёшь про это из тикета?

Отвечу первым: никак.

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

Хотя принести несложно: у статус-пейджей на Statuspage есть атом-фид — cloudflarestatus.com/history.atom, githubstatus.com/history.atom. Дальше парсится и льётся куда угодно.

Про сборщик расскажу через неделю.

#SRE #DevOps #Observability #Reliability #CDN #Cloudflare #IncidentManagement

Привет, %username%! Самовосстановление — вершина лестницы зрелости, а не входной билет. Продают его наоборот.

У CNCF автоматический возврат в known good state стоит на пятом уровне из пяти, chaos engineering — на четвёртом, а по auto remediation индустриального стандарта нет вовсе: только вендорские блоги, каждый со своей нумерацией. Зато в докладах самолечение показывают как то, с чего начинают.

Яндекс на ~50 тысячах приложений сделал ставку ровно обратную: чинить себя сама система не пытается, зато дежурный дотягивается до неё за секунды. Три серьёзных инцидента за шесть лет, ни одного полного краха. Meta* автоматизировала диагноз: 50 тысяч расследований в день, а решение всё равно за дежурным.

Похоже, зрелость меряется не долей автодействий, а тем, у кого остаётся возможность вмешаться, когда автоматика ошиблась.

А твоя автоматика хоть раз чинила не то? И как ты об этом узнал — из алерта или уже от людей?

Развернул на 35 тысяч знаков: https://jtprog.ru/posts/digital-immune-system-maturity/

*Meta признана экстремистской организацией, её деятельность запрещена на территории РФ.

#SRE #DevOps #Reliability #AutoRemediation #ChaosEngineering #IncidentManagement #OnCall #Architecture

Мишка на сервере — про надёжность, инциденты и инженерную практику

А еще там упали М9 и РегРу. Совпадение?! 🤔

Как вести личную базу знаний, чтобы она работала на тебя

Знакомая, далёкая от IT, спросила: «А для чего мне вести свою базу знаний?» И я завис. Не потому что нечего ответить, а потому что все заготовленные ответы оказались профессиональными: писать в блог, готовить доклады, держать в порядке рабочий контекст. Ей это не нужно — она не пишет статей и не выступает на конференциях.

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

«Чтобы ничего не забывать» — плохая цель. Забывание не поломка, а рабочий механизм. Память переписывает воспоминание при каждом обращении. Узнавание текста легко подделывается под понимание. База, построенная как склад, складом и останется: я свою сносил дважды, суммарно больше двух тысяч заметок.

Работает другое. Письмо — не запись готовой мысли, а способ её получить. Записанная мысль перестаёт быть ощущением и становится куском твоей картины мира, вынесенным наружу, — там его наконец можно рассмотреть, сравнить с прошлогодним и починить, если врёт.

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

https://habr.com/ru/articles/1070224/

#Habr #PKM #Post #Blog #PersonalKnowledge

Digital Immune System: инженерия устойчивости как продукт

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

https://jtprog.ru/posts/digital-immune-system-maturity/

#SRE #DevOps #DigitalImmuneSystem #DIS #Blog #Post

Когда психанул в понедельник

Со вчерашнего вечера у многих разрабов "выходной" :D

Отдыхаешь? Или перешел на другого провайдера?

#Claude #incidents

SRE Mind map

Просто оставлю это тут:

https://jtprogru.github.io/The-Way-of-SRE/mindmap/

Заходи, знакомься и накидывай PR/issues с полезностями!

#TheWayofSRE #TWoSRE #Github #SRE #DevOps

Что происходит, когда ты открываешь сайт

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

https://jtprog.ru/posts/what-happens-when-you-open-website/

Как дочитаешь – приходи рассказать чего нового узнал!

UPD: мне накидали косяков и замечаний и получилось больше 30 минут чтения!

#SRE #DevOps #Blog #Post #Networking #Linux #DNS #TLS #Basics

Я слышу, как модель думает

И это буквально, а не метафорически.

https://habr.com/ru/articles/1060510/

#habr #SRE #DevOps #LLM #LMStudio

Как облачная синхронизация тихо ломает git и как это чинить

Главный тезис статьи: порча объектов git — это не потеря данных, если жив origin. А раздутый .git лечится только переписью истории, и никак иначе. Разберём оба случая до винтика — с теорией, диагностикой и командами, которые можно копировать.

https://jtprog.ru/posts/cloud-sync-breaks-git/

#Git #Blog #Post #iCloud #CloudSync

Как ставить задачи ~~начальнику~~ AI-агенту?

Привет, %vibecodername%! Тут мой дорогой друг и товарищ по палате через неделю собирается провести в онлайне мастер-класс по теме постановки задач для AI-агентов.

Для тех, кто как и я относится к категории «лучше один раз покажите, чем сто раз поясните» – мой персональный рекомендосьён!

#SipkiTech #AgenticAI #AgenticDevelopment