🔖SLA, SLO и SLI простыми словами - часть 1

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

Но спустя пару месяцев пользователи начинают жаловаться:

«Поиск выдает результаты через 5 секунд»
«Платежи проходят с задержкой»
«Интерфейс зависает при большом количестве данных»

Метрики — в норме, инфраструктура стабильна, но пользователю от этого не легче. И тут проблема в том, что мы не умеем измерять, насколько хорошо она работает с точки зрения опыта конечного пользователя.

1. От “горит или нет” к пониманию, как горит

Мониторинг обычно отвечает на вопрос: “жив ли сервис”. Но он не отвечает на вопрос: “живёт ли он хорошо”.

Пример: В одном интернет-магазине серверы не перегружены, ошибок 500 нет, но продажи упали на 7%. Оказалось, при переходе к оплате страница грузилась по 6-7 секунд и пользователи просто уходили. С точки зрения мониторинга - всё “зелёное”. С точки зрения бизнеса - потеря денег.

2. Что значит «работает хорошо»?

Чтобы говорить о качестве, нужно зафиксировать, что вообще считается “хорошим”. Для этого инженеры используют три понятия:

- SLA (Service Level Agreement) - "обещание" пользователю. Например: “Сервис доступен 99,9% времени”.
- SLO (Service Level Objective) - цель, к которой стремится команда. Например: “99,95% запросов выполняются за ≤ 200 мс”.
- SLI (Service Level Indicator) — конкретный измеряемый показатель. Например: “latency P99”, “ошибки 5xx”, “успешные транзакции”.

Пример: API биллинга установил SLO: 99,9% запросов быстрее 150 мс. Однажды latency вырос до 400 мс - не авария, но выход за цель. Виноваты оказались обновления сервиса, подгружавшие ненужные связи. После фикса всё вернулось в норму.

3. Бюджет ошибок как кредит доверия

Любая система допускает небольшой процент сбоев. Этот процент - бюджет ошибок. Если SLA 99,9%, то за год допустимо примерно 8 часов простоя.

Бюджет ошибок - это не KPI, а инструмент. Он даёт право на риск. Это возможность для команды использовать бюджет в своих интересах. Бюджет ошибок помогает решать - где стоит рисковать, а где пора стабилизировать.

Примеры: Команда внедряет новый алгоритм рекомендаций. Но есть риск, что новая система снизит продажи или перегрузит сервера запросами. Команда видит, что у них есть в бюджете ошибок время на эксперименты и они решаются катить изменения, чтобы проверить новую фичу. Таким образом вместо того чтобы доводить всё до идеала - они могут просто “освоить бюджет” и им ничего за это не будет. И если всё прошло гладко, то у них еще есть запас на следующие эксперименты.

4. Метрики как язык между инженерами и бизнесом

Инженеры говорят “всё работает”, бизнес говорит “клиенты жалуются”. SLO и SLI помогают перевести одно в другое.

Пример: Руководитель продукта в компании каждое утро открывает дашборд: “Логин”, “Платёж”, “Вывод средств”. Он не лезет в логи, он видит: вчера latency по платежам вышел за SLO. Теперь разговор идёт не о вине, а о влиянии на опыт клиента.

Во второй части мы поговорим о практической стороне вопроса

#observability #slo #sla

🔖SLA, SLO и SLI простыми словами - часть 2

5. Как начать измерять качество

1. Определяем критичные сценарии. Например: авторизация, поиск, оплата.
2. Назначаем целевые значения. Например: “95% запросов успешны, время ответа ≤ 300 мс”.
3. Собераем метрики. Prometheus + Grafana отлично подойдут.
4. Визуализирем расход бюджета. Сделайте график: горизонталь - дни, вертикаль - процент стабильности. Если линия ползёт вниз - вы “сжигаете” бюджет.
5. Ну и настроиваем алерты через генератор SLO. Например, sloth или любой другой.

https://sloth.dev - это инструмент, который позволяет описывать SLO декларативно и автоматически генерировать правила для Prometheus и Alertmanager. Вместо того чтобы писать PromQL-выражения руками, вы описываете цели в YAML (пример с официального сайта):

version: "prometheus/v1"
service: "myservice"
labels:
  owner: "myteam"
  repo: "myorg/myservice"
  tier: "2"
slos:
  # We allow failing (5xx and 429) 1 request every 1000 requests (99.9%).
  - name: "requests-availability"
    objective: 99.9
    description: "Common SLO based on availability for HTTP request responses."
    sli:
      events:
        error_query: sum(rate(http_request_duration_seconds_count{job="myservice",code=~"(5..|429)"}[{{.window}}]))
        total_query: sum(rate(http_request_duration_seconds_count{job="myservice"}[{{.window}}]))
    alerting:
      name: MyServiceHighErrorRate
      labels:
        category: "availability"
      annotations:
        # Overwrite default Sloth SLO alert summmary on ticket and page alerts.
        summary: "High error rate on 'myservice' requests responses"
      page_alert:
        labels:
          severity: pageteam
          routing_key: myteam
      ticket_alert:
        labels:
          severity: "slack"
          slack_channel: "#alerts-myteam"

Из этого Sloth сам создаёт нужные PrometheusRule и алерты с множителями согласно https://sre.google/workbook/alerting-on-slos/#6-multiwindow-multi-burn-rate-alerts. SLO становятся кодом, который можно версионировать, ревьюить и катить, интегрировав генератор с CICD процессы.

9. Что в итоге

Тимлид в такой экосистеме уже не “смотрит на алерты”, а управляет балансом между скоростью и надёжностью. Он помогает команде использовать бюджет ошибок осознанно и видеть, как изменения влияют на SLO.

- Мониторинг говорит, жив ли сервис. SLO - как живёт ваш продукт.
- SLO, SLI и SLA делают качество измеримым.
- Бюджет ошибок даёт свободу для экспериментов.
- Sloth и подобные генераторы делают SLO воспроизводимыми, как код.
- Тимлид управляет не метриками, а зрелостью команды.

Заключение

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

#observability #slo #sli

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

#humor #fun
---
💬DevOps Brain 🌐Github

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

Давайте я просто покажу примеры использования с кратким описанием и все сами поймете.

pdsh - инструмент, который позволяет выполнять команды на множестве хостов параллельно.

# Проверим uptime на хостах начиная с 1 по 5, исключив 3
pdsh -w node[1-5] -x node3 uptime

# Перезагрузим все хосты, кроме node3 и node7
pdsh -w node[1-10] -x node3,node7 'sudo reboot'

Если вы достаточно организованы, чтобы вести список хостов - можно даже использовать файл с заранее определенными хостами

# File: my_hosts.txt
# node1
# node2
# db[01-05]

pdsh -w "^my_hosts.txt" 'uptime'

Вы скажете:

Так тебе же ничего не мешает использовать для этих целей Ansible!

ansible -i 'node1,node2,node3' all -m shell -a 'uptime'

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

Когда одного pdsh мало - берите PSSH

pssh - отличная альтернатива pdsh

# Одновременное обновление пакетов на всех хостах
pssh -h production_servers.txt -l admin -t 300 "sudo apt update && sudo apt upgrade -y"

pscp - массовое копирование на сервера

# Залить скрипт мониторинга на все хосты
pscp -h all_hosts.txt monitor_script.sh /usr/local/bin/

prsync - параллельное копирование через rsync

# Обновить статические файлы только если они изменились
prsync -h cdn_nodes.txt -a "-avz" static/ /var/www/static/

pslurp - собрать файлы с серверов на локальную тачку

# Собрать логи со всех серверов в отдельные папки
pslurp -h servers.txt -l user -L ./collected_logs /var/log/app/error.log app_error.log

Эти инструменты не заменят полноценные системы управления конфигурациями вроде Ansible или chef, но для быстрых задач, срочных исправлений или массового сбора информации - они незаменимы.

#tools #cli #administration
---
💬DevOps Brain 🌐Github

🔖Лучшие практики конфигурирования Kubernetes в 2025 — Часть 1: Это база!

Kubernetes обычно выглядит дружелюбным 🧌 ровно до того момента, пока вы не начнёте обновлять кластер или выкатывать изменения. И вот тогда внезапно выясняется, что "мелочи" в манифестах - не мелочи. В этой серии из 6 частей за 6 дней я соберу лучшие практики конфигурирования Kubernetes.

В первой части будем говорить про фундамент: версии API, Git как источник истины, YAML и базовый набор привычек для развертывания workloads без “ну оно же вчера работало”. Это те вещи, которые дают самый быстрый эффект и чаще всего окупаются первым же стабильным релизом.

А дальше - прикладная "эксплуатация по-взрослому": сеть/метки/конфиги и ресурсы (часть 2), безопасность+наблюдаемость+graceful shutdown+образы (часть 3), масштабирование/хранилище/планирование и контейнерные паттерны (часть 4), GitOps/mesh/ingress/RBAC и отладка (часть 5), и финально про стоимость, политики, backup/DR, probes и troubleshooting (часть 6).

⛓ https://devopsbrain.ru/posts/2025-12-10-kubernetes-best-practices-2025-chast-1/

🔖 #kubernetes
---
💬DevOps Brain 🌐Github

🔖Лучшие практики конфигурирования Kubernetes в 2025 — Часть 2: Сервисы, метки, конфиги и лимиты

Пришло время поговорить про сервисы, метки, конфиги, лимиты и секреты. Ведь это те самые места, где небольшая ошибка превращается в инцидент.

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

Так что ставьте 🔥 и добавляйте в избранное. Поехали...

⛓ https://devopsbrain.ru/posts/2025-12-10-kubernetes-best-practices-2025-chast-2/

🔖 #kubernetes
---
💬DevOps Brain 🌐Github

🔖Лучшие практики конфигурирования Kubernetes в 2025 - Часть 3: безопасность, логи, наблюдаемость и graceful shutdown

Ну что, котлеги, надеюсь вы нашли для себя что-то полезное в предыдущих 2 частях. Если это так - то не скупитесь ставить 🔥.

Это дает мне понять, что материал полезен и вам интересно то о чем я пишу.

Пришло время ехать дальше и вот что я вам скажу: есть два подхода к продакшену - “потом прикрутим безопасность/метрики/грейсфул” и “почему оно снова умерло. Открываем логи и метрики и смотрим!”. Обычно команды быстро мигрируют от первого ко второму - через боль, но мигрируют. 🤪

Эта часть c кучей примеров про безопасность подов, сетевые политики, наблюдаемость (метрики/логи/трейсы), корректное завершение (SIGTERM, draining) и управление образами. Применение этих практик сделает инциденты для вас диагностируемыми и переживаемыми - даже когда всё идёт не по плану.

⛓ https://devopsbrain.ru/posts/2025-12-10-kubernetes-best-practices-2025-chast-3/

Предыдущие части:
⛓ https://devopsbrain.ru/posts/2025-12-10-kubernetes-best-practices-2025-chast-1/
⛓ https://devopsbrain.ru/posts/2025-12-10-kubernetes-best-practices-2025-chast-2/

🔖 #kubernetes
---
💬DevOps Brain 🌐Github

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

Ниже я составил для вас чеклист из 7️⃣ пунктов на своем опыте, которые позволят вам спокойно провести праздники:

1️⃣. Бабки на счетах. Проверь не выпадает ли оплата счета на праздники в ваших облачных платформах, датацентрах, хостингах. У меня была пара случаев в жизни когда мы проморгали это и было очень неприятно. Пополнение балансов в праздники для юрлиц довольно болезненная процедура и можно неплохо так “встрять”.

2️⃣. DNS и сертификаты. Лучше заранее проверить, что продление вашего корпоративного домена не выпадет на праздники. Конечно никто его сразу не разделегирует. Но вдруг твой регистратор уже тебе присылал "письмо счастья" и ты его проморгал.

3️⃣. Алерты, мониторинг, on-call. Прежде чем ты впадешь в алкогольную кому - протестируй как работает твой мониторинг и алертинг. Лучше тест сделать прямо перед праздниками. Также стоит проверить, что ребятки на on-call могут своими ручками дотянуться до всей нужной инфры и секретов, если что-то пойдет не так.

4️⃣. Бекапы. Проверь, что бекапы на месте и из самых критичных, ты можешь развернуться. А еще лучше сразу настрой автоматическое развертывание бекапа, если его еще нет. Ты даже не вспомнишь где они лежат когда будешь запивать аспирин рассолом после бурной гулянки у родственников.

5️⃣. Ресурсы. Пробегись по своей инфре и хотя бы методом “penis to nose”, что тебе хватит ресурсов если вдруг трафика набежит в период бурных распродаж.

6️⃣. Базы данных. Очень желательно посмотреть на рост места на базах данных и тем же методом “penis to nose” прикинуть, что места хватит или лучше докинуть. Также стоит проверить ( если вдруг там нет мониторинга ), что реплики реплицируются и там нет ошибок.

7️⃣. Процессы и люди. Убедись, что в компании и команде четко разделены зоны ответственности, а также что ты не единственный кто знает “как это работает на самом деле”. Фишечкой на торте станет наличие Runbook и Disaster Recovery Plan.

🎄Пусть в праздники падают только снежинки, а не сервисы. С наступающими и спокойного on-call’а

🔖 #checklist
---
💬DevOps Brain 🌐Github

🔖Скрипт для быстрой диагностики Linux

“Наши руки не для скуки” (с). Я давно хотел накидать скрипт для супер быстрой диагностики Linux. Конечно, это не замена полноценному мониторингу. Это дополнительный инструмент, который вы можете использовать в своем арсенале чтобы упростить себе жизнь. Самое главное что он сэкономит кучу времени.

В отчете вы получите:

🔵Системную информацию - версия ОС, ядро, архитектура, uptime, внешний IP
🔵Аппаратные ресурсы - CPU, RAM, Swap, температура процессоров
🔵Дисковое пространство - занятое место, inodes, SMART статус
🔵Тест скорости дисков - скорость записи/чтения (100MB тест)
🔵Сетевые интерфейсы - статус, ошибки, активные соединения
🔵Тест сети - ping до шлюза, ya.ru и 8.8.8.8 (по 10 пакетов каждый), скорость интернета
🔵Процессы - топ по CPU и памяти, zombie процессы
🔵Системные логи - критические ошибки, OOM события, kernel warnings
🔵Системные службы - проверка упавших служб
🔵Безопасность - неудачные входы, активные SSH сессии
🔵Docker - статус контейнеров и их ресурсы

curl -o ~/linux-diag-script.sh https://gist.githubusercontent.com/itcaat/45edeaf15f2d508bee766daa9a97400c/raw/linux-diag-script.sh
chmod +x ./linux-diag-script.sh
./linux-diag-script.sh

# Одной командой
curl https://gist.githubusercontent.com/itcaat/45edeaf15f2d508bee766daa9a97400c/raw/linux-diag-script.sh | sudo bash

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

1. Найди [@BotFather](https://t.me/BotFather) в Telegram
2. Отправь команду /newbot
3. Следуй инструкциям и получи токен бота (например: `123456789:ABCdefGHIjklMNOpqrsTUVwxyz`)
4. Получи Chat ID:
- Отправь сообщение боту
- Откройте: https://api.telegram.org/bot<YOUR_BOT_TOKEN>/getUpdates
- Найди "chat":{"id": - это твой Chat ID

Теперь можешь добавить в cron (подставь свой botToken и chatId) и будешь получать уведомление в telegram если будет обнаружена какая то проблема.

# Проверка каждые 6 часов
0 */6 * * * root TELEGRAM_BOT_TOKEN="your_token" TELEGRAM_CHAT_ID="your_chat_id" /usr/local/bin/linux-diag-script.sh >/dev/null 2>&1

Актуальная версия скрипты доступна на GitHub Gist. Вы можете модифицировать его под свои нужды, добавлять новые проверки или как то интегрировать в runbook-и.

🔖 #linux #tools
---
DevOps Brain | Github

🔖Как вкатиться в работу после длинных праздников

Ну что, надеюсь все пережили эти длинные празники? 😀Пора возвращаться ( как бы это не было грустно) в суровую реальность.

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

Самое главное - не принимай серьёзных решений. Увольнение, смена профессии и переезд в Бали - отложи на неделю. После праздников мы склонны к резким движениям и странным идеям.

А помочь пережить первую рабочую неделю без лишней драмы тебе помогут небольшие советы ✍️:

1. Признай очевидное.
Да, работать не хочется. И нет, с тобой ничего не случилось. Это не выгорание, это организм всё ещё считает, что январь - выходной.

2. Не пытайся “ворваться” - это ловушка.
После праздников надо входить медленно: сначала понять кем ты работал и чем занимался. И после этого переходить к быстро-решаемым маленьким задачам.

3. Сначала контекст.
Начни с того, чтобы разобраться, какие темы сейчас живые, а что может подождать. Это сэкономит силы и время.

4. Составь список дел. Короткий.
Например: “разобрать почту”, “не уволиться”, “поесть”. Этого будет вполне достаточно на первый день.

5. Запланируй первую “победу”.
Закрой что-то простое и порадуйся. Мозгу нужно вспомнить, что работа - это не только страдание, но и галочка “done”.

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

7. Разговаривай с людьми.
Все в одинаковом состоянии. Обсудить это - уже терапия. А ещё иногда так выясняется, что дедлайны тоже ещё плавают.

И на последок - не требуй от себя героизма. Ты не обязан быть продуктивным, позитивным, вдохновлённым и замотивированным в первый же день. Достаточно быть адекватным и на связи.

Кстати, если у вас есть истории как что то разломалось в праздники - приходите в комменты =)

#карьера

---
DevOps Brain | Github

🔖 Полезные TUI тулзы - git-igitt

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

Некоторые супер известные - из серии lazydocker, lazygit и тд. Но банальщину оставим на потом. Хочется показать менее известные TUI-тулзы.

И первая тулза это git-igitt. Она нужна для просмотра Git-истории с читаемыми графами веток прямо в терминале.

⚡ Плюшки:

• визуальные Git-графы в терминале
• навигация по коммитам
• просмотр diff-ов
• кроссплатформенный

Установить можно через cargo или скачав соотвествующий бинарь со страницы релизов.

# Установить cargo можно командой curl https://sh.rustup.rs -sSf | sh
cargo install git-igitt

Навигация очень простая - просто стрелками на клавиатуре вверх вниз влево и вправо.

#tools #git

---
DevOps Brain | Github

🔖 Полезные TUI тулзы - dive

Рано или поздно у тебя или твоих коллег появляется Docker-образ, который по какой-то причине весит в разы больше, чем ожидали. Часто виной тому - лишние логи, кэш пакетных менеджеров (apt, npm, pip), или даже исходный код, который не нужен в runtime.

Как следствие pull образа занимает вечность, ну а дальше сильно замедляется развертывание в кластерах или на нодах.

Возникает вопрос: как посмотреть, что находится внутри этого образа и как сделать его меньше? Именно для этого и нужен dive.

По сути dive - это рентген для Docker-образов, который покажет:

- Все реальные слои файловой системы образа.
- Какие именно файлы были добавлены, изменены или удалены в каждом слое.

Попробуйте запустить dive на своем самом большом образе - гарантирую, вы удивитесь =)

# https://github.com/wagoodman/dive
dive <your-image:tag>

#tools #tui

---
DevOps Brain | Github | YouTube

🔖Полезные TUI тулзы - ncdu

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

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

Я покажу 2 примера использования - в базовом варианте ( будет достаточно для 99 процентов случаев ):

ncdu <some_path>

Расширенный пример с самыми интересными параметрами, которые потенциально могут пригодиться.

# --exclude-caches - не учитывать кеши
# --exclude '*.log' - не учитывать log-файлы
# --color dark - темная тема
# --show-percent - показывать процент от общего размера
# -- graph-style - стиль графической полоски (чисто вкусовщина для красоты)
ncdu --exclude-caches \
  --exclude '*.log' \
  --exclude '/proc/*' \
  --color dark \
  --show-percent \
  --graph-style half-block <some_path>

Пакет доступен для всех популярных linux-дистрибутивов и macos. Пример как она работает есть на видео - как видно больше всего места в моем домашнем каталоге жрет Counter Strike oO.

#tools #cli #linux

---
Telegram | Github | YouTube | Twitter

🔖Симулируем сети в GNS3. Часть 1 - настройка под MacOS

Я тут в праздники упоролся и подготовил материал на тему проектирования сетей в графическом симуляторе GNS3. Это будет небольшой цикл из нескольких статей в которых мы:

- Научимся работать в GNS3
- Настроим MikroTik RouterOS через консоль
- Изучим конфигурацию статических и динамических IP-адресов с разными пулами адресов
- Реализацем NAT для доступа в интернет
- Настроим Firewall правила на MikroTik:
- Воспользуемся адресными списками для упрощения управления
- Реализуем сегментацию сети и реализауем политики безопасности

Ну и на вкусное: пересоберем сеть с использованием Cisco L2-коммутатора, настроим VLAN и подрубим OSPF. Ну и вообще разберемся раз и навсегда на реальном примере как это работает на самом деле и зачем это нужно =)

Но для начала, если у тебя macOS на m-проце, я подгтовил пост как там настроить GNS3. К сожалению, там надо немного поплясать что симулятор заработал. Для остальных ОС проблем нет поставить и настроить. В общем - надеюсь тебе будет интересно.

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

---
📱 Telegram 📱 Github 📱 YouTube 📱 Twitter

🔖Симулируем сети в GNS3. Часть 2 - делаем свою первую сеть

Как и обещал я выкатываю 2-ую часть по симулятору сетей GNS3.

В статье мы разберем:
- Работу с GNS3 для моделирования сетей.
- Настройку MikroTik RouterOS через консоль (CLI).
- Конфигурацию статических и динамических IP-адресов.
- Настройку DHCP-серверов с разными пулами адресов.
- Реализацию NAT для доступа в интернет.
- Создание и применение Firewall правил.
- Использование адресных списков для упрощения управления.
- Сегментацию сети и реализацию политик безопасности.

Я буду очень рад если вы накидаете плюсов на хабре под постом. 😌

➡️ https://habr.com/ru/articles/988152/

---
📱 Telegram 📱 Github 📱 YouTube 📱 Twitter