Как превратить SLO в алерты, которые не будят зря

У порога ошибок есть перекос. Для SLO 99,9% за 30 дней правило Prometheus «ошибки ≥ 0,1% за 10 минут» заметит полную недоступность за 0,6 секунды, но может срабатывать до 144 раз в сутки, хотя сервис всё ещё выполнит SLO.

Увеличить окно до 36 часов? Точность вырастет, зато после полной недоступности сигнал продолжит гореть 36 часов. Добавить for: 1h? Пятиминутные всплески каждые десять минут вообще не вызовут алерт, хотя съедят 35% месячного бюджета ошибок.

В главе Alerting on SLOs авторы сравнивают шесть схем по точности, полноте обнаружения, времени срабатывания и сброса. Практический ориентир: откажитесь от одного фиксированного порога и длительности for; стройте правила по скорости расходования бюджета ошибок относительно SLO. Так тяжёлый инцидент даст сигнал быстрее, а незначимое событие не превратится в вызов дежурного.

Как завершать Pod в Kubernetes без оборванных запросов

При rolling update, масштабировании или вытеснении Pod могут удалить, пока он отвечает на запрос. Для Service маршрут до экземпляра задаёт endpoint: IP-адрес Pod вместе с targetPort. В список попадают Pod, прошедшие readiness probe; при создании и удалении Pod список обновляется.

Перед изменением Deployment проверьте путь остановки:
1. новый Pod принимает трафик только после readiness probe;

2. для завершаемого Pod настроен preStop;

3. у долгих задач и постоянных соединений есть отдельный сценарий завершения;

4. длительность остановки согласована с масштабированием кластера.

В разборе Learnk8s показан путь Pod через kubelet, Service и endpoints, затем сценарии корректного завершения. Используйте его как чеклист для теста rolling update без оборванных соединений.

Как выбрать distroless-образ для статического и динамического бинарника

FROM scratch даёт пустую файловую систему. Каталоги, CA-сертификаты, данные пользователей, часовые пояса и общие библиотеки приходится добавлять вручную. Distroless уже содержит необходимый системный минимум.

Для статически собранного приложения подходит gcr.io/distroless/static: около 2 МБ, без libc и менеджера пакетов. Бинарнику с зависимостью от glibc нужен base-nossl размером около 15 МБ, а при зависимости от libssl — base размером 20,7 МБ. В замере статьи Trivy нашёл в static 0 уязвимостей, а в base восемь: семь низкой и одну средней опасности.

Перед сменой образа проверьте зависимости бинарника через ldd и выберите минимальный вариант с нужными библиотеками. Иерархию образов и Dockerfile для Go с CGO автор показывает в разборе iximiuz Labs.

Как удержать кардинальность метрик Prometheus под контролем

Кардинальность метки: число её уникальных значений. Число рядов равно произведению количеств значений меток. В примере два HTTP-метода, семь путей, пять машин и 12 рядов, создаваемых гистограммой, дают 840 временных рядов. Добавление одного значения к первым трём меткам увеличивает результат до 1728.

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

Детализацию по отдельным запросам оставьте журналам событий, а метрики используйте для общей картины и оповещений. Механика роста и ориентиры по пределам разобраны в статье Robust Perception.

В Суздаль за DevOps

Недавно мы съездили на «Без предела: Исходный код ритейла» от MAGNIT TECH в Суздаль. Разговор о технологиях начинался с купеческих рядов, продолжился на Demo Day на ГЭС на Нерли, а затем перешёл к самовару. Мы кайфанули от формата.

У Владимира Дроздецкого, например, зацепил заход через первый рабочий день инженера. По мере знакомства с инфраструктурой за привычными сборками и выкладками обнаруживается хозяйство на тысячи ядер. Через такую историю масштаб ощущается лучше, чем через цифры сами по себе: можно примерить на себя работу человека, которому всё это поддерживать. Ради этого взгляда изнутри советуем открыть презентацию. И наставление от Владимира не забудьте:

Не важно, сколько раз ты упал – важно, сколько раз ты поднялся. Главное — поднимайся с правильным IP-адресом

Модемный скрип перед соединением — если он сразу всплыл в голове, то тебе как раз в анкету от SpaceWeb и Типичного программиста! Она напомнит времена ЖЖ, гостевых книг, первых твитов и других интернет-икон того времени. Заодно расскажем, как менялись веб и SpaceWeb за 25 лет, немного заглянем в будущее, а в конце — промокод и результат, который может удивить.

Как requests и limits управляют подом Kubernetes

В манифесте четыре значения стоят рядом, но работают на разных этапах. Планировщик сравнивает requests с allocatable узла. После запуска kubelet и среда контейнеров переводят настройки в cgroups, где Linux распределяет CPU и ограничивает память.

Низкий requests.cpu уменьшает долю CPU при конкуренции. Достижение limits.cpu включает троттлинг: растёт задержка, падает пропускная способность. Заниженный requests.memory ужесточает вытеснение и OOM, а превышение limits.memory приводит к OOM kill. HPA считает загрузку относительно request.

Сопоставьте requests с kubectl top и allocatable узла: текущее потребление может быть ниже, но планировщик всё равно учитывает весь request. В руководстве Learnkube есть разбор от YAML до механизмов Linux.

Как проследить путь сетевого пакета в Kubernetes

В одном pod контейнеры делят сетевое пространство имён, IP-адрес и порты, поэтому видят друг друга через localhost. Пространство создаёт среда выполнения контейнеров, pause удерживает его, а CNI назначает IP и подключает pod к сети кластера.

В разборе пути пакета показаны маршруты к pod на том же и другом узле, а также к Service через Netfilter и iptables, которые перехватывают и переписывают трафик. Путь прослеживается от исходного запроса до контейнера приложения.

При сетевом инциденте начните с узла: lsns -t net покажет сетевые пространства, а sudo lsns -p <PID> свяжет их с процессом контейнера. Затем проверяйте границы по порядку: пространство pod, подключение CNI, связь между узлами и правила Service.

Как собирать компактные Docker-образы через multi-stage build

В одном Dockerfile можно отделить сборку от запуска: каждый FROM начинает новый этап, а COPY --from=build переносит в финальный образ только артефакт. В примере Docker Go SDK и промежуточные файлы остаются на этапе сборки, а образ на базе scratch содержит только бинарник.

Именуйте этапы через AS build: тогда COPY не сломается после перестановки инструкций. Для отладки собирайте этап командой docker build --target build . BuildKit обработает лишь этапы, от которых зависит выбранная цель.

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

Как изучить контейнеры от runc до Kubernetes

Контейнер полезно рассматривать как изолированную и ограниченную среду для процессов. В Linux пространства имён дают изоляцию, cgroups ограничивают ресурсы, а механизмы прав и фильтрации системных вызовов сужают доступ процесса. Программа runc подготавливает такую среду и запускает в ней процесс.

Затем стоит разобрать образы, containerd, Docker и оркестраторы. Для запуска runc достаточно каталога с config.json, исполняемым файлом и зависимостями. Образы нужны, чтобы экономить место и распространять файловые системы.

Практический порядок: запустить контейнер через runc, разобрать образ и containerd, затем связать эти слои с Docker и Kubernetes. Статья Learning Containers From The Bottom Up собирает маршрут и ссылки на углублённые разборы.

Как измерить и сократить toil в эксплуатации

Google SRE определяет toil как поток повторяющихся и предсказуемых задач поддержки: перезапусков, обновлений и разбора алертов. Такая работа может расти вместе с инфраструктурой, а закрытый тикет не предотвращает повтор проблемы.

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

Если инструкция сводится к входу на сервер, команде, проверке вывода и перезапуску сервиса, она уже похожа на псевдокод. Автоматизируйте выполнение без участия человека, а когда возможно, исправляйте первопричину. Критерии и примеры есть в главе «Eliminating Toil» из The Site Reliability Workbook.

OpenTelemetry бесплатен ровно до дня, когда вы начали его эксплуатировать

Стандарт снял привязку к вендорскому агенту: инструментируете один раз, шлёте куда хотите. Что начинается дальше, перечисляет спонсорский разбор на DevOps.com.

Коллекторов становится по одному на кластер или регион, у каждого свои batch и memory_limiter, и под нагрузкой узким местом оказывается сам коллектор. Хранение OTel не закрывает: трейс-стор, TSDB под метрики и индекс логов вы выбираете и обновляете согласованно. Переход от медленного спана к нужной строке лога тоже не появляется сам: слой корреляции пишете вы и правите при каждом изменении схемы. И пейджер при отвале ingestion звонит вашим инженерам, а не SRE вендора.

Что делать до миграции: заложить в план человека на пайплайн и посчитать квартальные часы на апгрейды SDK и семантических конвенций по всем сервисам. Не сходится — считать ценник managed.

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

При инциденте на Linux-хосте легко сразу уйти в глубокую трассировку. На странице Linux Performance собраны карты инструментов наблюдаемости, статического анализа, тестирования производительности и настройки системы, а также материалы по sar.

Для первого прохода возьмите Linux Performance Analysis in 60,000 Milliseconds: там перечислены первые десять команд для расследования. Затем выбирайте нужную глубину: perf для профилирования, eBPF и ftrace для трассировки, Flame Graphs для визуализации результатов. Есть и доклады по контейнерам, настройке EC2 и чеклистам SRE.

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

Что проверить перед запуском приложения в Kubernetes

Pod может запуститься, а обновление или масштабирование всё равно окажется хрупким. До релиза проверьте приложение: структурированные логи идут в stdout и stderr, настройки отделены от образа, несекретные лежат в ConfigMap, чувствительные в Secret.

При завершении процесс должен обработать SIGTERM: перестать принимать новые запросы, закончить текущие, закрыть соединения и выйти до terminationGracePeriodSeconds. Иначе Kubernetes остановит его принудительно, хотя трафик ещё может попадать в Pod.

Чек-лист LearnKube охватывает пять этапов: приложение, манифесты Kubernetes, безопасность, масштабирование и выход в продакшен. Пройдите его перед запуском, миграцией или внутренним ревью платформы и исправьте проваленные пункты до релиза.

Зелёный CI не ловит деградацию под трафиком, зато её ловит канарейка с автооткатом

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

DevOps.com предлагает перестать считать тесты воротами «прошло/упало» и перенести проверку в выкат: Argo CD раскатывает манифесты, Flagger подаёт на новую версию 10% трафика, потом 30%, потом 100%. На каждом шаге он сверяет RED-метрики канарейки (запросы, ошибки, длительность) со старой версией и при скачке задержки по 95-му перцентилю сам откатывается.

Что делать: включить в тестах и сервисах трейсы OpenTelemetry, иначе сравнивать нечего; задать Flagger пороги по ошибкам и p95, разрешить автооткат; синтетику по ключевым сценариям гонять раз в минуту из регионов, где ваши пользователи.

ACME отработал с кодом 0, а пользователи всё ещё получают старый сертификат

Cron обновил сертификат, джоба зелёная, а nginx, HAProxy или IIS держат в памяти прежний: файлы на диске новые, но процесс перечитывает их только после reload. Второй случай: скрипт кладёт файл в один каталог, а конфиг после давней миграции читает из другого. Скрипт выйдет с нулём, ничего не изменив.

Поэтому пайплайн заканчивается не успешной командой, а проверкой живого эндпоинта после reload:
• снять сертификат с боевого адреса: echo | openssl s_client -connect example.com:443 -servername example.com | openssl x509 -noout -serial -enddate;
• сравнить serial и notAfter с тем, что только что задеплоили;
• расходятся: сделать reload и проверить, из какого пути читает сервис.

Пока этого шага нет, об истёкшем сертификате вы узнаёте от пользователей. Разбор цепочки от renew до recover — в статье на DevOps.com.