DevOps Brain 🧠
652 subscribers
100 photos
2 videos
82 links
Привет, я Никита — инженер, который умеет слушать бизнес и говорит с ним на одном языке. Работаю на стыке DevOps/SRE, продуктовой инженерии и здравого смысла. Если тебе близки такие темы, то тебе в мой канал😸
Download Telegram
Всё это позволило Microsoft продать 10 млн копий за 2 года. Да, OS/2 была функциональнее, но она была дороже, сложнее и менее доступной массовому пользователю. И Microsoft поняла: зачем делиться OS/2 с IBM, если можно развивать Windows и контролировать рынок. А еще поняла, что пользователям важнее удобство и доступность, а не техническое совершенство. Именно в этот момент Microsoft приняла решение покинуть проект OS/2 и начать разработку Windows NT, опираясь на опыт, полученный во время работы над OS/2. А IBM продолжила развивать OS/2 самостоятельно.

Разблокировано воспоминание: Когда мне было лет 6, я дружил с девчонкой. Она жила несколькими этажами ниже. Я довольно часто бегал к ней в гости. А у нее был старший брат, который увлекался компами - и я вот помню как он мне хвастался что поставил на комп OS/2. Он был явно очень собой доволен и счастлив, что у него это получилось. Я не знаю как я это помню до сих пор, но почему то это отпечаталось в моей памяти.

В 1992 выходит OS/2 2.0 уже без участия Microsoft. Полноценная 32-битная система для 386, поддержка кооперативной и вытесняющей многозадачности, виртуализация DOS, запуск Windows-программ внутри - всё это было в новой операционной системе.

OS/2 могла одновременно запускать несколько Windows 3.0 приложений в отдельных защищённых сессиях. И это было даже безопаснее и стабильнее, чем сам Windows.

IBM продвигала OS/2 как “лучше Windows”, но этой ОС нужно было больше ОЗУ, места на диске, и драйвера ставились труднее. К тому же не каждый пользователь справлялся с установкой.

Выход Windows 3.1 в 1992 добил ситуацию. Простая установка, игры, драйвера - всё шло “из коробки”. OS/2 же оставалась системой для гиков и корпоративных клиентов.

В мае 1993 года IBM выпускает OS/2 2.1 и к концу 1993 года IBM занимает всего лишь менее четырех процентов рынка настольных компьютеров. Но начинает прокладывть себе путь как на рынок серверов и встраиваемых систем.

В 1994 IBM выпускает OS/2 Warp 3.0 и она стала самой популярной версией OS/2. Она предлагала поддержку мультимедиа, интернет-приложений и имела улучшенный интерфейс. Warp продавалась в коробках, рекламировалась в журналах и по ТВ.

IBM даже подписала контракт с DC Comics - выпускали комиксы о WarpMan, борющемся с “злыми синими окнами”. Но несмотря на юмор и креатив, успеха не вышло.

В 1995 выходит Windows 95. Поддержка Win32, современный GUI, огромная база разработчиков и массовая реклама от Microsoft сделали своё дело - окончательно добили OS/2 на рынке настольных ПК.

К концу 1996 года OS/2 завоевала почти тринадцать процентов рынка серверов и чуть более трех процентов рынка настольных ПК. Серверные версии OS/2 были технически превосходны и имели хорошую ценность, но NT быстро обгоняла OS/2, а Linux также начал отвоевывать часть рынка серверов.

В 2001 IBM выпустила последнюю версию - OS/2 Warp 4.52. После этого проект закрыли, но лицензии передали сторонним компаниям. Так появились eComStation и ArcaOS на базе OS/2.

ArcaOS - современное ответвление OS/2. Работает на новых процессорах, поддерживает USB 3.0, Wi-Fi, современные дисплеи и т.д. Система всё ещё используется в некоторых банках.

OS/2 была технически передовой системой, превосходящей Windows по многим параметрам, но проиграла из-за более высокой стоимости оборудования, сложности использования, неудачной маркетинговой стратегии. Но ключевым фактором стал разрыв отношений с Microsoft, которые вовремя поняли что пользователи не хотят настраивать систему, они хотят включить и чтобы сразу работало. Можем ли мы упрекнуть Microsoft в неэтичности по отношению к IBM вопрос открытый - решайте сами…

https://habr.com/ru/articles/906698/
👏6🔥3👍1
🔖Как прокачать сетку между разными ЦОД за пару команд

Сегодня поговорим как разогнать скорость передачи по сети на максимум всего за пару команд. В качестве примера представим, что у нас распределенная инфраструктура, которая живет в разных регионах. Также у нас есть какой то VPN между ЦОД-ами, который решает проблему связности ресурсов и безопасности. И есть требование: каждый час надо скачивать бекап на 50GB и разворачивать в другом регионе.

И вот вы настроили свой cronjob, запустили его и пошли пить чай и брать следующую таску в работу. Через какое то время обнаруживаете что скорость во время скачивания бекапа серьезно проседает, ну и плюс периодически могут теряться пакеты, а RTT вообще 30ms. И вот бекап уже даже за пару часов не может скачаться.

Это классическая история для алгоритма управления перегрузкой (Congestion Control Algorithms) CUBIC. Эти алгоритмы встроены в ядро операционных систем и работают автоматически, без вашего участия.

Но не все так плохо - Google начал придумывать более оптимальный алгоритм еще в 2016 и назвал его BBR (Bottleneck Bandwidth and Round-trip time). Алгоритм BBR проходит через несколько фаз, но для простоты можно выделить его основную логику:

1. Разведка: BBR периодически ненадолго увеличивает скорость отправки данных, чтобы проверить, не выросла ли пропускная способность канала (вдруг «трубу» расширили?).
2. Дренаж: После разведки он наоборот, немного снижает скорость, чтобы «осушить» возможные очереди из пакетов, которые могли скопиться в буферах маршрутизаторов, уменьшая задержку.
3. Стабильная работа: Основное время BBR работает на рассчитанной оптимальной скорости, которая обеспечивает максимальную пропускную способность при минимальной задержке.

Ключевое отличие в том, что CUBIC реагирует на потери, а BBR реагирует на изменения в сети (сравнение CUBIC и BBR на реальных устройствах от компании ESNet https://internet2.edu/wp-content/uploads/2022/12/techex22-AdvancedNetworking-ExploringtheBBRv2CongestionControlAlgorithm-Tierney.pdf)

BBR вы можете включить на свежих ядрах как Linux так и Windows:


# linux
echo "net.core.default_qdisc=fq" >> /etc/sysctl.conf
echo "net.ipv4.tcp_congestion_control=bbr" >> /etc/sysctl.conf
sysctl -p

# windows
NetTCPSetting | Select SettingName, CongestionProvider
netsh int tcp set supplemental template=Internet congestionprovider=BBR2
netsh int tcp set supplemental template=InternetCustom congestionprovider=BBR2
netsh int tcp set supplemental template=Datacenter congestionprovider=BBR2
netsh int tcp set supplemental template=DatacenterCustom congestionprovider=BBR2
netsh int tcp set supplemental template=Compat congestionprovider=BBR2


Где можно попробовать включать: между облаками/ЦОДами (NAT и VPN-шлюзы), а также конечные сервера где требуется просасывать большие объемы трафика.

На моей практике включение BBR на конечных серверах и VPN-инстансах дало буст по сетке x6. Но вы должны иметь ввиду, что BBR может быть довольно агрессивен по отношению к соседям использующим CUBIC - поэтому после включения стоит понаблюдать за ситуацией. А сравнить эффективность вы можете через iperf3 -c YOUR_IP -t 60 -P 16.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥15
🔖 Эмуляция сетевых проблем в Linux через tc netem

В практике иногда встречаются кейсы когда нужно проверить как себя ведет приложение при сетевых проблемах. На помощь спешит tc netem (аббревиатура от Network Emulator) — инструмент Linux для эмуляции сетевых проблем.

netem — это qdisc (queueing discipline) в Linux — часть подсистемы управления трафиком (tc из iproute2). Его задача симулировать реальные сетевые проблемы: задержки, потери пакетов, дубликации, неправильный порядок, ограничение пропускной способности и т.д.

Когда и зачем использовать
Тестирование протоколов — например, TCP или VoIP, если хочешь увидеть, как они ведут себя при потере и/или задержке.
Разработка приложений, чтобы убедиться, что сценарии “плохой сети” обрабатываются корректно.
Реалистичная нагрузка — эмуляция загруженных сетей или мобильных сетей, где часто бывают потери, задержки, “хвосты” задержек.

Добавить фиксированную задержку


sudo tc qdisc add dev eth0 root netem delay 100ms


Добавить задержку + джиттер с корреляцией
Эта команда, которая эмулирует не просто "плохую" сеть, а нестабильную сеть с "памятью". Гораздо ближе к реальным условиям (например, к мобильным сетям 3G/4G/5G или перегруженным каналам).


sudo tc qdisc change dev eth0 root netem delay 100ms 10ms 25%


delay 100ms средняя задержка, вокруг которой будут "колебаться" ваши пакеты. 10ms — джиттер (величина, на которую задержка может случайным образом отклоняться). В данном случае задержка каждого пакета будет выбираться случайным образом из диапазона от 90ms до 110ms (100ms ± 10ms). Без корреляции это были бы просто случайные, независимые друг от друга значения.

Корреляция 25% это параметр, который определяет, насколько задержка текущего пакета зависит от задержки предыдущего пакета. Без корреляции (0%) джиттер дает абсолютно случайные и независимые скачки задержки. Это не очень реалистично для многих реальных сетей. С корреляцией 25%: если предыдущий пакет имел задержку (например, 110 мс), то высока вероятность, что и следующий пакет тоже будет иметь задержку выше среднего. Таким образом мы получаем некий эффект "памяти" сети. Это дает более реальное поведение сетей для тестирования.

Добавить "нормальное" распределение задержек
Большинство пакетов получают задержку, близкую к среднему значению. Крайние значения (сильные отклонения) маловероятны, но возможны. Данный тип использует Гауссово распределение. Существуют и другие:`uniform`, pareto, paretonormal.


sudo tc qdisc change dev eth0 root netem delay 100ms 20ms distribution normal


Потеря пакетов


sudo tc qdisc change dev eth0 root netem loss 20%


Дубликация пакетов
Эта команда инструктирует ядро Linux изменить текущие сетевые правила на сетевом интерфейсе eth0 так, чтобы он случайным образом дублировал 1% всех исходящих сетевых пакетов. Допустим, что ваше приложение отправляет 1000 пакетов. При включенном правиле duplicate 1%: ~990 пакетов дойдут до получателя в нормальном, единственном экземпляре. ~10 пакетов будут дублированы. Получатель получит их в двух одинаковых копиях, одна сразу за другой. Полезно при тестирование устойчивости протоколов и приложений. Например, как поведет себя кодек или игровой движок.


sudo tc qdisc change dev eth0 root netem duplicate 1%


Ограничение пропускной способности + учёт overhead
Использование overhead позволяет ограничить скорость именно на уровне полезных данных, которую увидит приложение, что критически важно для корректного тестирования пропускной способности. Для грубого ограничения "лишь бы было медленнее" можно использовать просто rate 5mbit, но для точных реалистичной эмуляции канала связи учет overhead обязателен.


sudo tc qdisc change dev eth0 root netem rate 5mbit 20 1500 5


rate 5mbit скорость полезной нагрузки
20 размер заголовков канального уровня (L2)
1500 размер MTU
5 размер в байтах сетевого и транспортного уровня (L3+L4)

Почистить за собой


sudo tc qdisc delete dev eth0 root netem
Please open Telegram to view this post
VIEW IN TELEGRAM
👏8👍5🔥3
🔖 Наводим красоту в htop

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

Я не хочу долго расписывать как и что настраивать, а просто дам вам однострочник который сделает всю магию. Он по сути он просто бекапит текущий конфиг (если он вообще был) и забирает из https://gist.github.com/itcaat/45ea5994d66378fc4bd647cab860a05f новый.


mkdir -p ~/.config/htop && [ -f ~/.config/htop/htoprc ] && mv ~/.config/htop/htoprc ~/.config/htop/htoprc.bak.$(date +%Y%m%d%H%M%S); curl -fsSL "https://gist.github.com/itcaat/45ea5994d66378fc4bd647cab860a05f/raw" -o ~/.config/htop/htoprc


После этого запускаем htop и наслаждаемся.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥122❤‍🔥11
🔖Говорим с TeamCity на одном языке с помощью MCP

Этот пет-проект я начинал делать с единственной целью “понять а как это работает на самом деле”, но он уже оброс кое-какими mcp-тулзами и, кажется, пришло время им поделиться. Если у вас есть TeamCity и количество билд конфигураций в нем такое, что чёрт ногу сломит - то скорее всего данный MCP Server вам будет полезен. В данный момент в нем реализованы следующие тулзы:

### Поиск и анализ

1. `search_builds` — Поиск билдов по статусу, ветке, дате, тегам, пользователю
2. `search_build_configurations` — Поиск конфигураций по параметрам, шагам, VCS
3. `fetch_build_log` — Получение логов билда для диагностики

### Управление билдами

1. `trigger_build` — Запуск нового билда с параметрами и указанием ветки
2. `cancel_build` — Отмена запущенного или ожидающего билда
3. `pin_build` — Закрепление/открепление билда для предотвращения автоудаления

### Управление метаданными и артефактами

1. `set_build_tag` — Добавление/удаление тегов к билдам
2. `download_artifact` — Скачивание артефактов из билда

Примеры использования


"Покажи все FAILURE билды за сегодня"
"Найди самые медленные билды в проекте shitcode"
"Почему свалилась сборка #2321 и как это исправить"
"Запусти билд MyProject_Deploy на ветке main"
"Закрепи билд #1234 с тегом v.1.0.7"


Настроить очень просто - создаем токен в Teamcity (я рекомендую придерживаться принципа PoLP) и задаем конфигурацию MCP.


# Пример подключения в Cursor
{
"mcpServers": {
"teamcity": {
"command": "docker",
"args": [
"run",
"--rm",
"-i",
"-e",
"TC_URL",
"-e",
"TC_TOKEN",
"itcaat/teamcity-mcp:v1.0.7",
"--transport",
"stdio"
],
"env": {
"TC_URL": "https://teamcity.example.com",
"TC_TOKEN": "YOUR_TOKEN_HERE"
}
}
}
}


В дальнейшем в нем появятся тулы для создания билд конфигураций. А сами исходники доступны тут https://github.com/itcaat/teamcity-mcp (буду очень благодарен за ). На этом у меня всё - всем пока и приятного пользования.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥511
Подъезжают первые комплектухи. Старший сын попросил такой же "комп для учебы" как и у младшего. Приходится раскошеливаться, чтобы было справедливо.

Потом покажу что получилось 🤌
6❤‍🔥3🔥2
🔖 Динамические матрицы в github actions - часть 1

Сегодня мы с вами на практике разберем что такое динамические матрицы в github actions.

Я подготовил монорепозиторий с несколькими микросервисами url-shortener-demo с очень коротким флоу: фичабранч(через PR) → main. Как понятно из названия это проект позволяющий генерировать короткие ссылки. А для упрощения локального запуска подготовлен docker-compose.yml, состоящий из сервисов:

1. api-gateway (Go) - API Gateway, единая точка входа
2. shortener-service (Go + Redis) - Создание коротких URL
3. redirect-service (Go + Redis + Kafka) - Перенаправление + события перехода для аналитики
4. analytics-service (Go + MongoDB + Kafka) - Аналитика
5. frontend (HTML + Nginx) - Веб-интерфейс

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

Теперь про магию - на самом деле вы, наверняка, видели множество примеров со статичными матрицами сборки (например, когда сборка приложения делается на нескольких OS). Но что если пойти дальше и самому сгенерировать матрицу в зависимости от того что поменялось? К счастью github actions позволяет нам это сделать.

При создании PR мы автоматически можем определить какой сервис поменялся, собрать его и выложить. А в случае, если поменялось что-то в pkg - собрать все сервисы.


# .github/workflows/build-pr.yml - часть 1
name: Build Pull Request

jobs:
changed-services:
name: Detect changed services
runs-on: ubuntu-latest
outputs:
matrix: ${{ steps.set-matrix.outputs.matrix }}
any_changed: ${{ steps.changed-files.outputs.any_changed }}
steps:
- name: Checkout
uses: actions/checkout@v4
with:
fetch-depth: 0

- name: Get changed services
id: changed-files
uses: tj-actions/changed-files@v45
with:
dir_names: true
dir_names_max_depth: 1
json: true
files: |
**/*
files_ignore: |
**/*.md
.github/**
scripts/**
*.md

- name: List all changed files
run: |
echo "Changed files: ${{ steps.changed-files.outputs.all_changed_files }}"

- name: Set matrix
id: set-matrix
run: |
# Находим все директории с Dockerfile
ALL_SERVICES=$(find . -maxdepth 2 -name "Dockerfile" -type f | sed 's|^\./||' | sed 's|/Dockerfile$||' | jq -R -s 'split("\n") | map(select(length > 0))' | jq -c .)
echo "All services with Dockerfile: $ALL_SERVICES"

# Получаем измененные файлы и убираем экранирование
CHANGED_DIRS_RAW='${{ steps.changed-files.outputs.all_changed_files }}'
CHANGED_DIRS=$(echo "$CHANGED_DIRS_RAW" | sed 's/\\"/"/g')
echo "Changed directories: $CHANGED_DIRS"

# Если изменился pkg/, пересобираем все Go сервисы (с go.mod)
if echo "$CHANGED_DIRS" | jq -e 'index("pkg")' > /dev/null 2>&1; then
SERVICES=$(find . -maxdepth 2 -name "go.mod" -type f | sed 's|^\./||' | sed 's|/go.mod$||' | jq -R -s 'split("\n") | map(select(length > 0))' | jq -c .)
echo "pkg/ changed, rebuilding all Go services: $SERVICES"
else
# Фильтруем: оставляем только измененные директории с Dockerfile
SERVICES=$(jq -nc --argjson all "$ALL_SERVICES" --argjson changed "$CHANGED_DIRS" \
'$changed | map(select(. as $dir | $all | index($dir)))' | jq -c .)
echo "Changed services: $SERVICES"
fi

# Если нет сервисов для сборки, создаем пустой массив
if [ "$SERVICES" = "[]" ] || [ -z "$SERVICES" ]; then
echo "No services to build"
SERVICES="[]"
fi

echo "matrix={\"service\":$SERVICES}" >> "$GITHUB_OUTPUT"


Продолжение далее… 🔽
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥3
🔖 Динамические матрицы в github actions - часть 2

Теперь просто в этом же build-pr.yml добавим джобу build и выглядеть она будет так.


# .github/workflows/build-pr.yml - часть 2
#jobs:
#changed-services:
#....
build:
name: Build ${{ matrix.service }}
runs-on: ubuntu-latest
needs: [changed-services]
if: ${{ needs.changed-services.outputs.any_changed == 'true' }}
strategy:
fail-fast: false
matrix: ${{ fromJSON(needs.changed-services.outputs.matrix) }}

steps:
- name: Checkout
uses: actions/checkout@v4

- name: Set up Docker Buildx
uses: docker/setup-buildx-action@v3

- name: Log in to GitHub Container Registry
uses: docker/login-action@v3
with:
registry: ${{ env.REGISTRY }}
username: ${{ github.actor }}
password: ${{ secrets.GITHUB_TOKEN }}

- name: Extract metadata
id: meta
uses: docker/metadata-action@v5
with:
images: ${{ env.REGISTRY }}/${{ env.IMAGE_PREFIX }}/${{ matrix.service }}
tags: |
type=ref,event=pr
type=sha,prefix=pr-${{ github.event.pull_request.number }}-
type=raw,value=pr-${{ github.event.pull_request.number }}

- name: Build and push
uses: docker/build-push-action@v6
with:
context: .
file: ${{ matrix.service }}/Dockerfile
platforms: linux/amd64,linux/arm64
push: true
tags: ${{ steps.meta.outputs.tags }}
labels: ${{ steps.meta.outputs.labels }}
cache-from: type=gha,scope=${{ matrix.service }}
cache-to: type=gha,mode=max,scope=${{ matrix.service }}

- name: Add PR comment
uses: mshick/add-pr-comment@v2
with:
message: |
**${{ matrix.service }}** successfully built!

**Images:**
`
${{ steps.meta.outputs.tags }}
`

**Pull command:**
`bash
docker pull ${{ env.REGISTRY }}/${{ env.IMAGE_PREFIX }}/${{ matrix.service }}:pr-${{ github.event.pull_request.number }}
`
message-id: build-${{ matrix.service }}


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

Как это будет выглядеть в github смотрите на скринах. В качестве домашнего задания можете форкнуть реп https://github.com/itcaat/url-shortener-demo (все примеры workflow вы найдете там же) и сделать так, чтобы собирались не все сервисы при изменении в pkg, а только те что реально зависят от измененного пакета.

Теперь вы просто мастер Йода в мире github actions, а остальные пусть дальше собирают всё подряд.

habr [2025.10.17]: https://habr.com/ru/articles/957636/
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥6
DevOps Brain 🧠
Подъезжают первые комплектухи. Старший сын попросил такой же "комп для учебы" как и у младшего. Приходится раскошеливаться, чтобы было справедливо. Потом покажу что получилось 🤌
Сегодня вечер субботы и совершенно не хочется говорить о чем то серьезном - но мне очень хочется поделиться с вами что по итогу получилось при сборке так называемого "компа для учебы".

Если кратко - получилось в итоге за вменяемые деньги(150к) собрать 2 одинаковых компа “для учебы” для своих детей.

Что там внутри:
🔥 Процессор: AMD Ryzen 7 7700
🧠 Оперативка: Kingston FURY Beast 32GB RGB
❄️ Кулер: Deepcool AG620 ARGB V2 - на самом деле их провода это какой то трешак. Никому не советую, в схеме без пол литра не разобраться.
🖤 Корпус: ARDOR GAMING Crystal CC1 Black (чёрный, как мои глаза после бессонной ночи с разломанным продом)
Блок питания: Cougar GES 850W
🛠 Материнка: ASUS TUF GAMING B650-PLUS WIFI
🚀 SSD: Samsung 990 PRO 2TB
🎮 Видяха: RTX 5070

На самом деле компы я лет 15 назад собирал последний раз, но руки то помнят. Это довольно большой срок, но по факту практически ничего не изменилось. Особенно меня забомбило с фронтальных коннекторов ( Power LED, Reset SW и прочими) - это какое то издевательство. Кажется, что было достаточно времени что бы придумать стандарт, что бы “под лупой” не рассмативать это непотребство.

В целом собирала моя кошка Эльза, а я так - чисто помогал.
1🔥16❤‍🔥3
🔖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. Теперь разговор идёт не о вине, а о влиянии на опыт клиента.

Во второй части мы поговорим о практической стороне вопроса
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥7❤‍🔥2
🔖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 воспроизводимыми, как код.
- Тимлид управляет не метриками, а зрелостью команды.

Заключение

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

habr[2025.10.14]: https://habr.com/ru/articles/956318/
Please open Telegram to view this post
VIEW IN TELEGRAM
❤‍🔥5
Всем привет. У нас появилась вкусная вакансия для начинающих DevOps-инженеров. Залетайте, не стесняйтесь. 🐱

https://www.aviasales.ru/about/vacancies/4082754
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥10
Напоминаю, что пятница - лучшее время проверить как хорошо работают ваши процессы, мониторинг, cicd и ролбеки. Поэтому обязательно сегодня катитесь в прод. 😀
😁10❤‍🔥4