Пятничный деплой

Netronome — self-hosted-мониторинг качества сети и интернет-каналов Если Speedtest Tracker, который я упоминал одном из прошлых постов, в первую очередь собирает историю тестов скорости, то Netronome идёт дальше: объединяет проверку пропускной способности, диагностику маршрутов и мониторинг удалённых серверов. Что умеет Netronome: — запускать тесты через Speedtest.net, LibreSpeed и iperf3; — выполнять проверки автоматически по расписанию; — сохранять историю скорости, задержки и других показателей; — непрерывно контролировать потерю пакетов через ICMP; — анализировать маршрут с помощью traceroute и MTR; — показывать статистику потерь отдельно по каждому узлу маршрута; — контролировать DNS-запросы; — собирать с удалённых серверов загрузку CPU, память, диски, температуру и сетевой трафик; — отправлять уведомления в Telegram, Discord, email и другие сервисы через Shoutrrr. Для распределённого мониторинга используются легковесные агенты. Их можно установить на домашних серверах или удалённых площадках, а результаты свести в один веб-интерфейс. Есть интеграция с Tailscale и автоматическое обнаружение агентов внутри tailnet — удобно, если не хочется публиковать служебные порты в интернете. Netronome потенциально может подойти в сценариях: — контроля качества домашнего или офисного интернет-канала; — сравнения фактической скорости с тарифом провайдера; — мониторинга связи между филиалами через iperf3; — поиска участка маршрута, на котором начинаются потери; — наблюдения за серверами без развёртывания полноценного стека Prometheus; — контроля трафика VPN-контейнеров, например Gluetun. Само приложение написано на Go, а интерфейс — на React и TypeScript. Frontend и backend упакованы в один исполняемый файл. По данным разработчиков, типичное потребление памяти составляет около 35 МБ. Для хранения можно использовать SQLite или PostgreSQL. Развернуть Netronome можно готовым бинарником либо в Docker. В контейнерный образ уже включены iperf3, LibreSpeed CLI, traceroute, MTR и vnstat. Есть встроенная авторизация, OIDC и ограничение доступа по IP. Из нюансов: тесты скорости создают реальную нагрузку на канал, поэтому расписание нужно выбирать аккуратно. Для полноценной работы MTR потребуются дополнительные привилегии, а некоторые функции при установке без Docker зависят от внешних утилит. Основная функциональность распространяется на бесплатной основе, но разрабы отдельно предлагают платный набор дополнительных тем интерфейса. Репыч на GitHub @usr_bin_linux

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

🧠 Наглядный способ разобраться с памятью в Python Визуализатор показывает ссылки, изменяемые типы данных и разницу между поверхностным и глубоким копированием. Работает онлайн, исходники доступны на GitHub 🔗 🐸 Библиотека программиста

KYAML vs YAML: зачем усложнять простое? YAML давно стал привычным инструментом для DevOps. Но у него есть обратная сторона: неявные типы, зависимость структуры от отступов и множество возможностей, которые Kubernetes на самом деле не использует. Kubernetes предлагает более строгий подход к конфигурациям — KYAML и описывает его преймущества в своем блоге. Идея в том, чтобы оставить от YAML только то, что действительно нужно Kubernetes, и убрать неоднозначности. Что получает DevOps? 🟡 меньше зависимости от отступов; 🟡 более предсказуемую работу со строками и типами; 🟡 явное обозначение списков [] и структур {}; 🟡 более удобную работу с генерацией, шаблонами и автоматизацией; 🟡 KYAML остаётся валидным YAML и рассчитан на совместимость с существующими YAML-парсерами. Но есть и другая сторона. Среди обсуждений инженеров можно встретить мнение, что KYAML не избавляет Kubernetes-конфиги от сложности, объясняя это тем, что:  🟡 KYAML не уберёт Helm-шаблоны, огромные манифесты и десятки взаимосвязанных параметров. А значит, вместо решения основной проблемы можно получить ещё один формат, который команде придётся изучать и поддерживать; 🟡YAML уже встроен практически во всю DevOps-экосистему — от IDE и линтеров до CI/CD-инструментов. KYAML — новый подход, а значит, не все инструменты одинаково хорошо его поддерживают. И здесь возникает главный вопрос: KYAML действительно решает проблемы YAML — или просто вводит более строгие правила там, где и так всё работало? 👀 А вы бы использовали KYAML в своих проектах, либо же обычного YAML вам вполне хватает? Поделитесь мыслями.

Docker для параноика: организация SSH‑доступа для rootless‑контейнера без передачи приватного ключа Примонтировать ~/.ssh в контейнер с флагом :ro — и вроде как позаботился о безопасности. Только приватный ключ при этом всё ещё можно прочитать и утащить. От этого read-only не спасает. В этом разборе на Хабре рассказывают о том, как дать rootless-контейнеру SSH-доступ через ssh-agent, оставив сам ключ на хосте. Пригодится для автоматизации, работы с приватными репозиториями и ИИ-агентов, которым нужен Git. Rootless Docker имеет свои нюансы: UID пользователя внутри контейнера преобразуется в другой UID на хосте, поэтому просто пробросить сокет агента недостаточно. Оказывается, доступ к сокету всё ещё позволяет пользоваться загруженным ключом. Если контейнер взломали, злоумышленник сможет выполнять доступные этой SSH-идентичности операции, пока имеет доступ к агенту. Сам приватный ключ через штатный протокол агента при этом не выдаётся. @usr_bin_linux

Несколько лет назад я написал целый цикл постов на тему виртуализации. Мотивация - расставить все точки над и, разобраться что есть что. Провести параллели и границы между контейнерами, виртуалками, а также объяснить понянтным языком что же такое Docker. Получилось 4 поста: - Введение в виртуализацию. Какая бывает, какие проблемы решает - Аппаратная виртуализация - Виртуализация на уровне ОС (Контейнеризация) - Истинно ли утверждение что Контейнеры это Docker? Почему я вспомнил об этих постах? Мой товарищ Никита у себя в канале взялся еще глубже препарировать тему и уже опубликовал пост о продвинутых технологиях на стыке виртуалок и контейнеров. Он посвящен OCI и тому что современные контейнеры стремятся быть абстракцией поверх VM, а не чем-то сбоку. И дальше идет разбор софта подтверждающего этот тезис. 🔖Контейнер ≠ Docker [1/3] by DevOps Brain Буду читать сам, поэтому могу смело советовать😊 Если вам такие посты заходят поддержите Никитоса лайком и подпиской❤️

Kubernetes NodeLocal DNSCache: ускоряем DNS-запросы 🚀 Без NodeLocal DNSCache DNS-запрос от Pod проходит через: Service IP → kube-proxy → DNAT → conntrack → CoreDNS В нагруженных кластерах это увеличивает задержки и создаёт дополнительную нагрузку на таблицу conntrack. NodeLocal DNSCache запускает локальный DNS-кеш на каждой ноде как DaemonSet: Pod → локальный DNS-кеш → CoreDNS Если запись уже есть в кеше, Pod получает ответ прямо с текущей ноды. При промахе запрос передаётся в CoreDNS. Преимущества - быстрее обрабатываются повторные DNS-запросы; - снижается нагрузка на CoreDNS; - уменьшается межнодовый DNS-трафик; - обходятся kube-proxy и DNAT; - сокращается количество UDP-записей в conntrack; - доступны DNS-метрики отдельно для каждой ноды. NodeLocal DNSCache стабилен с Kubernetes 1.18, но обычно его нужно включать отдельно и развернуть node-local-dns как DaemonSet. 🔗 Официальная документация Kubernetes: https://kubernetes.io/docs/tasks/administer-cluster/nodelocaldns/

k8s-overcommit Operator

The k8s-overcommit Operator is a Kubernetes operator designed to intelligently manage resource overcommit on pod resource requests. It automatically adjusts CPU and memory requests based on configurable overcommit classes, enabling better cluster resource utilization while maintaining workload performance.

https://github.com/InditexTech/k8s-overcommit-operator

HUATUO — eBPF-наблюдаемость и автоматическая диагностика ядра Linux HUATUO — open source-платформа для глубокой наблюдаемости Linux, созданная в DiDi (китайская служба такси). Она работает на уровне ядра и помогает разбирать проблемы, которые сложно диагностировать с помощью обычных метрик приложений: задержки планировщика, блокировки процессов, memory reclaim, OOM, сетевые потери, аномалии дискового I/O и всплески системного CPU. Под капотом HUATUO работают eBPF, kprobe, tracepoint и ftrace. Инструмент собирает данные без модификации приложений и может автоматически связывать их с Kubernetes-контейнерами, labels и annotations. В HUATUO есть несколько режимов работы: Metrics — постоянный сбор показателей CPU, памяти, сети, планировщика и дисковой подсистемы. Метрики публикуются в формате Prometheus. Events — фиксация событий ядра: OOM, soft lockup, hung task, packet drop, аномальный memory reclaim и сетевые задержки. AutoTracing — автоматический запуск углублённой диагностики при обнаружении аномалии. Например, при резком росте CPU sys, накоплении процессов в D-state, всплеске аллокаций памяти или проблемах с I/O. Continuous Profiling — построение flame graph и анализ on-CPU, off-CPU и memory-профилей для C, C++, Go, Java и Python. AutoTracing выглядит особенно полезным: детальная диагностика включается не после обращения пользователя, а непосредственно в момент срабатывания алерта. В результате сохраняются call stacks, список процессов, контекст контейнера и flame graph, необходимые для последующего RCA. HUATUO нативно интегрируется с Prometheus, Grafana, Elasticsearch и Pyroscope. Репыч на GitHub Документация @usr_bin_linux

From Ingress to Gateway API: How We Modernized Networking on Our GKE Cluster

We recently migrated our production GKE cluster from the traditional Ingress controller to the Kubernetes Gateway API — and honestly, we should have done it sooner.

https://the-devops-engineer.medium.com/from-ingress-to-gateway-api-how-we-modernized-networking-on-our-gke-cluster-8409ffb53173

Ссылки к выпуску: 1. Runbook vs Playbook: почему это разные инструменты и зачем в 3 ночи нужны оба. 2. Мои статьи про DIS: - Цифровой иммунитет твоей инфраструктуры: шесть столпов Gartner и из чего система собирается - Инженерия устойчивости как продукт: петля обратной связи, SLO как gate в CI/CD, границы автоматики и пять маркеров зрелости 3. Платформа для 50 000 приложений: кейс Yandex Infrastructure, где надёжность держится на изоляции компонентов и быстром доступе дежурного, а не на самолечении. 4. AI-агенты в инфраструктуре: - SRE MCP: как пустить ИИ в прод и не устроить chaos engineering без кнопки «стоп»: Константин Михалкин, CTO h3llo cloud, на митапе «Алло, Ада» и VK - Как дать агенту управлять кластером вашей инфры?: Эдгар Сипки, на митапе DUC Флант

DIS – будущее инженерии Привет, %username%! Вышел выпуск «В SREду на кухне» про Digital Immune System, и я там гость. Этот подкаст мы когда-то запускали вместе с ребятами, так что вернуться на кухню уже внешним гостем было отдельно приятно. Без стола посидели со мной: Андрей Колесников, Андрей Волхонский и Василий Осипенко из Авито. Разбирали, почему мониторинга, SRE и автотестов уже не хватает, кто в компании вообще отвечает за DIS, можно ли доверить AI инфраструктуру и умеет ли система чинить себя сама. Моя линия там простая: иммунитет держится на замкнутой петле, а не на шести квадратиках из презентации Gartner. Если инцидент заканчивается тикетом, а не новым правилом, иммунитета нет, сколько компонентов ни разверни. А AI сегодня безопасен в диагнозе и опасен в действии. Смотреть идем на VK, Mave или YouTube и смело включаем на x1.25-1.5 (не могу себя слушать – научусь говорить нормально). А у тебя разбор инцидента хоть раз поменял политику, а не просто закрыл тикет? #SRE #DevOps #Reliability #DigitalImmuneSystem #Podcast Мишка на сервере — про надёжность, инциденты и инженерную практику

После вчерашней разминочки, продолжаем про CPU и мониторинг нагрузки. Казалось бы чего уж проще, смотри на общую нагрузку и радуйся жизни. Но нет, в сложных, нагруженных системах как мы выяснили в прошлом посте, делать это примерно полностью бесполезно. Сегодня разберем неочевидные и поэтому интересные ситуации с потреблением процессорных мощностей. Самый простой пример девиации, которую сложно увидеть на мониторинге это описанный в прошлый раз случай, когда процесс упирается в производительность CPU. Мониторинг многоядерной системы показывает почти полный idle, при полной загрузке одного ядра. Никаких алертов по CPU конечно не будет. Даже народная метрика Load Average, в простонародье LA, показывающая среднее количество потоков, стоящих в очередь на выполнение, такого не покажет. Именно для этого и в консольных командах вроде htop, и в экспортерах метрик есть данные по загрузке каждого ядра. Смотреть на график из 80ти ядер, выискивая причину тормозов тот еще квест, но лучше чем ничего. Еще одна метрика, которую вы никогда не увидите на общем графике нагрузки процессора это его настройки энегропотребления и частоты. Бывает редко, но иногда на железных серверах процессор может работать на трети от заявленной частоты, просто потому, что находится в режиме экономии электроэнергии. Много сэкономить не получится, а вот скорость работы приложений может пострадать, даже если частота под нагрузкой будет расти, гуглить "cpu performance governor". Предельный случай занижения частоты - защита от перегрева. Внутренняя логика процессора понижает частоту по достижении определенной температуры, что бы процессор не согрел и если у вас нет алертов на метрики снимаемые с материнской платы, вы получите снижение производительности. Производительность в этом случае не просто просядет, но может скакать, заставляя постоянно меняться время обработки. Для средней web-based системы это плюс-минус не важно, а вот для специализированных near real-time систем разброс времени обработки может стать очень большой проблемой. И тут мы приходим в облако. Облако это такой чудесный мир, где тебе примерно ничего не гарантировано. Ваш виртуальный процессор, данные которого вы видите в выводе lscpu, отделен от реального процессора системой виртуализации и аккаунтинга. Самой показательной была демонстрация теста производительности базы данных, которую мы делали в конце четырехдневного интенсива по MySQL, когда двухядерная (!) виртуалка в течении нескольких минут без малейших сомнений держала нагрузку в 12 (двенадцать!) параллельных потоков. Потом заложенное в облачный аккаунтинг время повышенной доступности ресурса закончилось и виртуалка резко умерла под нагрузкой, да так, что пришлось ее перезапускать. Было весело. Еще веселее было, когда у одного из клиентов в реальном проде сработал алерт по метрике пятисотых ошибок. Никаких работ или релизов последние сутки не наблюдалось. Собрали звонок, позвали ответственных инженеров и начали смотреть. Выяснилось, что одна из нод бекенда перестала справляться с нагрузкой. Взяла и перестала. Мониторинг показывал увеличенную нагрузку на процессор, LA на ноде улетел в небеса. Сначала решили, что балансировщику сильно поплохело и он на эту ноду полил повышенную нагрузку. Однако эта гипотеза не подтвердилась. Из балансировки ноду выкинули и начали разбираться. Перевернули все что можно. После приблизительно часа поиска один умный человек предложил проверить фактическую производительность процессора. Достали бенчмарк, прогнали и оказалось, что производительность CPU на виртуалке внезапно стала в где-то в четыре-пять раз ниже, чем была. Саппорт посмотрел что-то у себя и сказал: "перезагрузите". После перезагрузки все восстановилось. Были ли это "шумные соседи" по гипервизору и виртуалка переехала на новый гипервизор или глюканула система аккаунтинга в облаке для нас осталось загадкой. Так и живем! Рассказывайте свои истории, делитесь этим постом с другими, скоро увидимся! #SRE @downtime_bar

Планы на 3 октября — прийти на RWB Infra x Security Meetup Мы направим прожекторы на инфраструктуру и информационную безопасность — туда, где за привычными решениями скрываются сложные инженерные задачи, компромиссы и неочевидные риски. Будем разбирать реальные кейсы, искать узкие места, обсуждать и показывать решения, которые помогают инфраструктуре и безопасности выдерживать рост. Когда: суббота, 3 октября, старт в 13:00 Где: Москва + онлайн В программе 8 докладов, разделенных по двум тематическим трекам Трек Infra: • Тюнинг Gitlab CE как реакция на быстрый рост нагрузки • Путь баланса и компромиссов в DCIM • Единая инфраструктура доверия: PKI на базе Vault • Kubernetes vs Bare Metal: что может пойти не так Трек Security: • DevSecOps: от сканирования в пайплайне к платформе — и обратно • Почти эффективный VM: как мы боролись с хаосом в инфраструктуре и сократили время обработки уязвимостей • Как защищать данные, когда единого периметра больше нет • От заявки до доступа за 90 секунд: как шесть инженеров управляет доступом в тысяче систем Регистрация уже открыта — не откладывайте заявку и приглашайте коллег (количество мест на площадке ограничено)! Подробнее о программе — на сайте

Все проверки зелёные, а данных нет: как мониторить gRPC server‑side стримы

Стандартная (для многих) история. Отдаём какие‑то данные в реальном времени через server‑side web‑gRPC стримы. Цепочка: балансировщик, дальше Envoy с grpc‑web, дальше бэкенд. Все проверки зелёные: TCP поднят, хендшейк проходит, /healthz отвечает 200, в графане/slack'e тишина. А фронтенд у клиентов замёрз. И узнали мы об этом от клиентов, а не от мониторинга.

В статье описание механизма работы демона, который по расписанию подгружает.proto на лету через proto‑loader, открывает server‑side RPC как обычный клиент, ждёт кадров (например 3) в бюджет времени и валидирует каждый кадр. Статья на Хабре Репыч на Гитхаб 📱 Telegram | 📲 MAX

archify

Agent skill for beautiful, verifiable architecture, workflow, sequence, data-flow, and lifecycle diagrams—self-contained HTML with motion and crisp export.

https://github.com/tt-a1i/archify

От firing до postmortem: рабочее место дежурного поверх Grafana и Mattermost

Алертинг у нас построен на правилах Grafana. Сами правила описаны в Terraform, хранятся в Git и применяются через CI/CD-пайплайн. Такой подход даёт review, историю изменений и воспроизводимую конфигурацию вместо ручного редактирования правил в интерфейсе. Дальше Grafana Alertmanager маршрутизирует уведомления по labels в несколько каналов внутреннего Mattermost. За этими каналами следит дежурная смена. В Grafana также есть отдельная доска, которая выводит активные алерты списком. Она помогла видеть общую картину, но не решила вопрос, что происходит с каждым алертом после доставки. Во время всплеска нужное сообщение иногда теряется среди десятков похожих. Некоторые алерты горят неделю, а обновления по ним появляются раз в несколько дней и каждый раз начинаются почти с нуля, как будто сигнал пришёл только что. Дежурные меняются и не всегда помнят, разбирали ли этот алерт раньше, занимается ли им другой инженер и кто сейчас ведёт исправление — инфраструктура или команда разработки. Получается своеобразная карусель: алерт продолжает гореть, люди меняются, а контекст приходится восстанавливать заново.

В статье описан подход, при котором вокруг Grafana построен операционный слой: единая карточка алерта, назначение владельца, история повторных срабатываний, автогруппировка связанных алертов, метрики MTTA/MTTR и автоматическая подготовка postmortem с использованием LLM. При этом AI не принимает решений, а только помогает анализировать уже собранные данные — вся логика жизненного цикла алерта остается детерминированной. Очередное напоминание о том, что наблюдаемость — это не только сбор метрик, но и грамотно организованный процесс реагирования на инциденты. Читать на Хабре. 📱 Telegram | 📲 MAX

Я долгое время считал, что подход/термин “Shift Down Security” появился в материале SIG Security Kubernetes в 2025 году. Но на самом деле корректнее считать 2023 год и статью ребят из Google Cloud под названием "The Modernization Imperative: Shifting left is for suckers. Shift down instead"! Автор статьи критикует чрезмерное «shift left» — перенос на разработчиков всё большего числа задач: тестирования, безопасности, эксплуатации, релизов и т. п. Хотя раннее подключение QA и security полезно, но на практике это нередко превращает инженеров в перегруженных «универсалов». Вместо этого он предлагает «shift down» подход : передавать сложность вниз, на управляемые платформы и абстракции.

⚡️ Поды здоровы, а запросы в Kubernetes случайно отваливаются? Проверьте conntrack. Linux хранит состояния отслеживаемых соединений в таблице conntrack. Она используется в том числе при NAT для Kubernetes Services. Если таблица переполняется, новые соединения могут терять пакеты. Симптомы: периодические тайм-ауты, сбои DNS и ошибки API при нормальных показателях приложений. Как проверить на проблемном узле:

# Текущее число записей и лимит
sysctl net.netfilter.nf_conntrack_count
sysctl net.netfilter.nf_conntrack_max

# Сообщения ядра
sudo journalctl -k | grep -i conntrack

Характерная запись:

nf_conntrack: table full, dropping packet

Что делать: • Увеличить лимит с учётом доступной памяти. Универсального значения для всех узлов нет. • Проверить настройки conntrack.maxPerCore и conntrack.min в kube-proxy: он может управлять лимитом. Одного изменения через sysctl недостаточно для устойчивой настройки. • Сократить создание новых соединений: использовать пулы, HTTP keep-alive, проверить лавину повторных запросов. • Пересматривать тайм-ауты по состояниям соединений после диагностики. Слишком короткие значения могут нарушить работу долгоживущих подключений. Следите за заполнением таблицы на каждом узле. Свободные ресурсы соседних нод не спасают таблицу перегруженной. https://kubernetes.io/docs/reference/config-api/kube-proxy-config.v1alpha1/

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