👨‍🚒 Потянуло меня посмотреть, что в опыте пожарных настоящих есть полезного для IT-инцидентов.

Написал статью, чтобы закрепить свое виденье на этот вопрос.

И знаете, многое похоже, но кое-что прям явно хочется забрать.

Я, например, до сих пор горю, что некоторые считают тред инцидента в мессенджере равносильным протоколу / журналу инцидента.
Да возможно ваша культура общения настолько высока, что так и есть, но чаще в жизни это 40-300 сообщений, которые невозможно быстро причитать, когда зашел в инцидент.
Если у вас есть AI-бот которого можно натравить на инцидент, чтобы он сделал саммари - это круто. Но это все равно не протокол. Я считаю, что протокол должен вестись отдельно. Сейчас уже можно прикрутить к этому AI, идея - сделать бота, которому в треде указал через эмоджи сообщение и он закинул это в текущий протокол. А еще лучше сделать бота фасилитатора-инцидента, который бы подсказывал, что пора дать апдейт в таком то виде (может быть и сам бы предложил текст), рассказать какие гипотезы тестим, что делаем в ближайшие полчаса, уведомить пользователей и т.п.

Почитать https://habr.com/ru/articles/994690/

#статьи #sre #инцидент_менеджмент #habr

Это стоит перепостить!

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

Когда читаешь это, думаешь, да ладно - ну вот же 21 век крутые технологии, скорости гигабитные 5G и 6G, а тут речь за какой-то "господин килобайт". Даже возмущение какое-то возникает сначала )

Но хоть технологии и ушли далеко, но база по прежнему из 1983 года (тогда повсеместно началось применение TCP-протокола).

#tcp #репост #история #база

https://t.me/jtprogru_channel/4455

Вы как относитесь к написанию кода с AI?

Я вот с этой картинкой, не согласен. При работе с AI агентом я выступаю как Product Owner - описываю результат, который удовлетворит бизнес. Когда бизнес - это вы сами, то агенты - это ваша команда.

Косячит ли команда? Всегда ли понимает задачи правильно и однозначно? Конечно нет - на себе много раз проверял. Если принял задачу с мыслю "тут все очевидно", то это скорее звоночек, что лучше спросить "а что ты имел в виду?". Это во много раз сокращает переделки.

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

Можно еще научить агента спрашивать "правильно ли я понял, что".

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

Вы переиспользуете промты? Или каждый раз из головы?

Не мог удержаться не запостить этот скрин.

Я недавно посмотрел Темный рыцарь. И тут он!

P.S. Из фильма "Бетман против SRE".

#fun #мониторинг #grafana #batman

👁 Увидимся на DevOpsConf 2026 на моем докладе!

Вы уже знаете, что я с 2026 года в ПК DevOpsConf, но еще осенью я подал несколько заявок на доклад. В этот раз оказался интересна тема SLO.

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

📆 Встречаемся 3 апреля на
DevOpsConf 2026, Стрим: Наблюдаемость/Мониторинг инфраструктуры, Зал 6

🔖 В это году конференция на ВДНХ! Павильон № 38 Бизнес. Техноград

Про антипаттерны алертов.

Макс написал все за меня. Нет, не тот который ловит даже на парковке 😁.

Потому просто заберите себе это в практику — это реально полезно.

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

Брать тут https://t.me/youngmaxnotes/103

💫 Как у вас подгорело от "прекрасных" алертов? Расскажите в комментах

#алертинг #антипаттерны #база #репост

Тренировка по #инцидент_менеджемент

Помню как погружался в работу с инцидентами.
Я начал работать в небольшой компании, у нас был 1 дежурный. Я стал вторым. И оба мы были разработчиками.

Сначала он меня учил на пальцах о системе и взаимодействии компонентов, показывал как чинить часто возникающие проблемы, а я смотрел. Я записывал в доку, потом пытался повторить тоже самое сам под его присмотром. Дальше выдал мне доступ на прод. И вот первое дежурство с потными ручонками... Страшно. Но оно кончилось и ничего не развалилось 😁

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

Освоился и с кубером и Google Cloud. Один падучий сервис будил меня 4 дня подряд в час ночи. Я на 3 день сделал себе консоль прямо на телефоне, чтобы ходить перезагружать тот сбойный под не вставая с кровати 😉 На 5 ночь я проснулся сам в 1 час ночи - но никто не позвонил. Оказалось разработчики починили 👨‍🔧 вчера.

Пока компания маленькая и растет - можно и получается учиться прямо на проде, т.к. потери не велики.

В большой компании и в зрелом бизнесе такое уже не позволят. Да и до всего прода вы доступ уже не получите.

Тогда как тренироваться?
Вы можете попробовать сделать стенд повторяющий часть прода и там ломать и пробовать чинить - так делают ребята в Яндекс такси (рассказывали в докладе).

Другой способ – попробовать отдельные тренажёры. Вот несколько площадок для тренировок онлайн по Linux и Kubernetes:
- https://labs.iximiuz.com/challenges?author=ivan-velichko&filter=all&category=kubernetes
- https://sadservers.com/
- https://keep-alive.ru - командные траблшутинга
- https://srega.me/ - индивидуальные тренировки в формате Capture the flag

Или
- Оффлайн на своей машине https://github.com/Manoj-engineer/k8squest


А как в работу с инцидентами погружались вы? Как получали опыт troubleshooting?

#troubleshooting #личный_опыт #sre

Не тот open API. Когда вы не управляете клиентами.

Очередной раз вижу в чате клич "Ребята, отзовитесь, кто пользуется API нашего сервиса X?".

Кажется, что за ерунда? Это же все наши внутренние сервисы -- посмотри по логам, по трейсам откуда запросы идут...
Но там может этого не быть. Например, ваши же сервисы не отправляют User-Agent со своим именем и версией в вызове, или нет трейсов. Всё - у вас просто куча логов об обращении на какой то endpoint вашего API.

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

О чем я говорю - о способе который видел впервые у Amazon.
Как это работает:
1) Вы даете доступ в API только по индивидуальным ApiKey, каждому потребителю свой
2) Каждый потребитель запрашивает у вас ApiKey и обязан принести сразу число - сколько нагрузки он будет вам давать (rps, ops)
3) Вы смотрите в показатели своего сервиса и принимаете решение. Если хватает мощности, то сразу выдаете ApiKey, иначе вы можете сказать "Ребята, у нас не хватит производительности вас обслужить - берем задачу на подумать как повысить производительность", и когда повысили - выдаем ApiKey.
4) Конечно хоршо бы вести базу какой ApiKey на какой сервис выдали, чтобы найти ответственных если что.
5) И также по ApiKey вы можете легко выставлять Rate-Limit, что позволит не завалить весь сервис, если один из клиентов сошел с ума.

А у вас пользуется подобными способами?
Встроено это в процесс подключения новых потребителей API?

Проверка инфраструктуры кодом - иногда и двух пар глаз 👀👀 недостаточно

Бывало у вас так: два инженера посмотрели в пулл-реквест, кивнули, мерджнули, а потом - бац!
Инцидент из-за кривой настройки безопасности или ресурса, улетевшего в продакшн без лимитов?
У нас бывало. И это не вопрос компетенции. Это вопрос того, что человек просто не может держать в голове все 750+ правил безопасной конфигурации.

Тут на помощь приходят инструменты статического анализа для Infrastructure as Code (IaC). Например, попался мне на глаза Checkov - https://www.checkov.io/

Что умеет:
- сканирует Terraform, CloudFormation, ARM, Helm, Kubernetes, Dockerfile и Serverless Framework
- проверяет на 750+ предустановленных политик - от открытых портов до отсутствия шифрования
- позволяет писать свои политики, если у вас специфичные требования
- интегрируется в CI/CD, чтобы ловить проблемы до мерджа

Почему это важно для SRE и DevOps:
- снижает когнитивную нагрузку на ревьюверов
- формализует знания о лучших практиках
- превращает "мы так не делаем" в автоматический чек
- дает артефакт для аудита и постмортема

Альтернативы, которые тоже стоит посмотреть:
- tfsec - легковесный, фокус на Terraform
- Terrascan - поддерживает несколько провайдеров, хорош для политик как код
- KICS от Checkmarx - открытый, с акцентом на безопасность

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

А вы используете статический анализ для IaC? Какой инструмент выбрали и почему? Сталкивались с инцидентами, которые можно было предотвратить автоматической проверкой?

#SRE #IaC #SAST #Security #DevSecOps #DevOps

Друзья и коллеги. Я внезапно обнаружил, что нас уже 150!

Для меня это неожиданно приятно.
Рад, что мои материалы и мысли тебе интересны, а возможно помогли в жизни и работе.

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

И что интересно, чаще всего у меня находится о чем написать. А иногда и коллеги закидывают в личку предложения по темам.

Спасибо, тебе - дорогой читатель 🫠

#нерабочее #канал #подписчики

Говорит DevOpsConf 2026 Москва: Мы набираем 🙋🙋🏻‍♀️волонтеров🔥 в команду организаторов

🤓 Обращаюсь к тебе как член Программного комитета DevOpsConf.

2 и 3 апреля в павильоне на ВДНХ соберется очень много инженеров: DevOps, SRE, архитекторы, лиды.

🤝 Ты подходишь, ведь ты из тех, кто хочет:
— увидеть конференцию изнутри 🔬
— стать частью нашего профессионального сообщества 😎

🗓 График волонтеров:
— 1-3 апреля (но готовы согласовать с вами конкретные дни)
— 1 апреля: офлайн инструктаж на площадке ориентировочно с 12:00-16:00
— 2-3 апреля: 08:00-20:00 с перерывами на обед, отдых и участие в афтепати в первый день (по желанию)

↩️ Что даем взамен:

🔸Полный доступ за кулисы. Увидите, как работает "внутренняя кухня" ивента. Спойлер: там веселее, чем в зале.

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

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

🍽 Питание для всех волонтеров на площадке.

🏨 Проживание при необходимости для иногородних. Мы поможем вам с логистикой.

Если вы готовы не просто сидеть в первом ряду, а реально помочь нам сделать этот движ - ждем💥

👉 Варианты:
1_ Я в деле — перехожу на анкету за подробностями: https://helpteam.ontico.ru/
2_ Я знаю тех кто давно такого хотел, сейчас им расскажу!

#ontico #волонтеры #devopsconf

🔖 Прошла первая Observability Conf в Москве

Я выступил с докладом "Стандартизация логов без боли: Vector + OpenTelemetry + ClickHouse".

Это была компиляция опыта за 3 года, как мы дошли до унификации логов, что сделали и что получили. Вопросов опять было много.

Этот доклад отличается тем, что мы vitech.team выложили (Всеинструменты.ру) в open-source, то что получилось при реализации - зовем мы это Unified Log Pipeline.

🥎 Презентация и материалы к докладу тут https://github.com/vseinstrumentiru/observability-conf-2026

Пробуйте демо "Unified Log Pipeline" тут https://github.com/vseinstrumentiru/unified-log-pipeline/. Код еще будем обновлять, если найдем баги или что-то улучшим.

🤓 Буду рад, если кому-то это поможет быстро решить проблему сбора логов.

🙋 Как думаете стоит ли про это написать отдельную статью с подробностями?
Или лучше просто добавить эти же подробности, как доку в репозиторий с кодом?

🛠 Опубликовали свою реализацию для сбора логов с vector.dev - Unified Log Pipeline

Год назад я рассказывал доклад на DevOpsConf 2025 "Укрощение хаоса логов с помощью модели OpenTelemetry, Vector и ClickHouse. Итоги за два года" (видео). Был план выложить в Open-source реализацию: трансформы vector.dev, Ansible-плейбук, схему БД. Но это заняло значительно больше времени, т.к. проходило проверки внутренние по ИБ и очистку кода от "лишнего". И вот теперь мы опубликовали его.

Реализация стандарта логирования на базе OpenTelemetry Logs Data Model: vector.dev трансформы, Ansible playbook, ClickHouse таблицы
https://github.com/vseinstrumentiru/unified-log-pipeline

🧐 Что скажете? Вы делали у себя что-то подобное? Получилось унифицировать сбор логов?