Сервис восстановился, а SLO-алерт всё ещё горит

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

В SRE Workbook Google разбирает проверку по двум окнам. Длинное показывает значимый расход error budget, короткое проверяет, продолжаются ли ошибки сейчас.

В примере для SLO 99,9% за 30 дней алерт требует одновременно:

— burn rate выше 14,4 за последний час
— burn rate выше 14,4 за последние 5 минут

Burn rate — скорость расходования бюджета ошибок относительно допустимой. Для этого SLO значение 14,4 соответствует доле ошибок 1,44%. Час с таким расходом — 2% бюджета за 30 дней в расчёте из книги.

Внутри пары нужен AND. Когда показатель за короткое окно опустится ниже порога, условие перестанет выполняться, хотя часовое окно ещё помнит сбой. Если добавляете пары для других скоростей расхода, их объединяют через OR.

Окна и пороги из примера нужно примерить к своему трафику. На малонагруженном сервисе даже несколько запросов заметно меняют долю ошибок. Точное время сброса алерта из одного размера окна не следует.

Разбор и примеры правил в SRE Workbook

#архитектура_на_салфетке

Что сделает systemd с пропущенным ночным запуском

Сервер был выключен ночью, и календарный таймер не запустил задачу. Чтобы при следующей активации таймера наверстать пропуск, у systemd есть Persistent=true.

Пример секции для backup.timer на Linux с systemd:

[Timer]
OnCalendar=daily
Persistent=true
RandomizedDelaySec=15m

Это только секция таймера. Для выполнения работы нужен отдельный backup.service. По умолчанию таймер активирует сервис с тем же базовым именем.

С Persistent=true systemd хранит время последнего срабатывания на диске. Если в период неактивности таймер должен был сработать хотя бы раз, при активации он вызовет сервис. Но не по разу за каждую пропущенную ночь.

У этой настройки две важные границы:

— она действует только с OnCalendar=. Для OnBootSec= и других монотонных таймеров эффекта нет
— догоняющий запуск тоже учитывает RandomizedDelaySec=. В примере он может дополнительно задержаться на случайный интервал до 15 минут

Точной секунды пример не обещает: у таймера есть ещё AccuracySec=, по умолчанию одна минута.

Параметры systemd.timer

#root_prompt

Новая NetworkPolicy не отменяет старое разрешение

Добавили default-deny, а к Pod всё ещё можно подключиться? Проверьте остальные политики, которые выбирают этот Pod.

У стандартных Kubernetes NetworkPolicy разрешения складываются. Для одного Pod и одного направления действует объединение разрешённых соединений из всех подходящих политик. Порядок создания политик результат не меняет.

Например, обе политики выбирают одни и те же Pod и действуют на ingress:

— первая не разрешает ни одного входящего соединения
— вторая разрешает вход от любых источников

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

Ingress и egress рассматриваются отдельно. Если соответствующие направления изолированы, для соединения Pod → Pod должны разрешить его и egress источника, и ingress назначения. Поэтому при проверке доступа смотрите podSelector и policyTypes на обеих сторонах.

И сначала убедитесь, что сетевой плагин поддерживает NetworkPolicy. Само создание объекта в API фильтрацию трафика не включает.

Модель NetworkPolicy в документации Kubernetes

#архитектура_на_салфетке

Заголовок PR не должен становиться shell-кодом

В GitHub Actions выражения ${{ ... }} внутри run: подставляются до запуска shell. Если напрямую вставить туда github.event.pull_request.title, чужой заголовок может изменить текст исполняемого скрипта.

Для inline-скриптов GitHub рекомендует передавать такое значение через промежуточную переменную окружения. Например, шаг внутри steps: job на Ubuntu runner:

- name: Print PR title
  shell: bash
  env:
    TITLE: ${{ github.event.pull_request.title }}
  run: |
    printf '%s\n' "$TITLE"

Теперь заголовок передаётся как данные. Bash не разбирает содержимое "$TITLE" повторно как команды. Двойные кавычки также не дают разбить значение по пробелам, а фиксированный формат '%s\n' не превращает сам заголовок в форматную строку.

Этот шаг только печатает значение, дополнительных прав ему не нужно. Не передавайте переменную дальше в eval или bash -c, иначе снова получите исполнение текста как кода.

Исправление защищает эту подстановку. Права токена, доступ к секретам и checkout непроверенного кода в привилегированных pull_request_target или workflow_run требуют отдельной проверки.

Рекомендации GitHub по обработке недоверенного ввода

#арсенал_инженера

Динозавр держится за ВМ и снапшоты по расписанию, Археолог давно не помнит, что и где у него крутится, а Повелителю облаков уютно до первого кругленького счёта. Это три из десяти типов инфраструктуры в тесте от команды Deckhouse.

Ответьте на 5 вопросов, узнайте свой тип и отправьте ссылку на результат команде. Посмотрим, совпадёт ли он у коллег.

→ Пройти тест и узнать свой тип

🐧 Память есть, а задачи ждут: смотрим PSI

Процент занятой RAM не показывает, сколько времени задачи теряют из-за нехватки ресурса. В Linux с поддержкой PSI это можно посмотреть без изменения настроек:

cat /proc/pressure/memory

Достаточно права чтения файла. В ответе будут строки some и full.

some — доля времени, когда хотя бы часть задач ждёт ресурс. full — когда одновременно ждут все non-idle задачи. avg10/60/300 — проценты за 10, 60 и 300 секунд, total — накопленное время ожидания в микросекундах.

Рядом есть /proc/pressure/cpu и io. Но CPU full на уровне всей системы не определён и выводится как 0 для совместимости. Это не признак здорового сервера. Отсутствие файла тоже не равно нулевому давлению.

PSI показывает ожидание, но не называет виновный процесс и не задаёт универсальный порог тревоги.

Документация ядра
#root_prompt

Сборка потерялась между job? Проверьте, не лежала ли она в cache

В GitLab CI кэш — ускоритель, наличие которого не гарантируется. Если тесты или deploy зависят от случайного cache hit, конвейер получился хрупким.

Загруженные зависимости можно кэшировать. Результат сборки, который нужен следующей стадии, передают через artifacts:paths. Например, кэш загрузок npm — в .npm/, собранный фронтенд — в dist/ как artifact.

Для зависимостей ключ удобно связать с lockfile через cache:key:files. При промахе job должна заново скачать зависимости и продолжить работу.

Есть ещё ловушка: cache восстанавливается раньше artifacts. Если дать им один путь, содержимое может перезаписаться. Разведите каталоги и проверьте pipeline без кэша. Процент ускорения зависит от runner, executor и хранилища.

Cache и artifacts в GitLab
#арсенал_инженера

Лишние байты образа можно ловить до деплоя

Dive умеет не только показывать слои. При CI=true он отключает интерфейс и возвращает pass/fail кодом завершения.

Linux/macOS, POSIX shell, установленный Dive и локальный образ myapp:build. Нужен доступ к Docker daemon, он привилегирован:

CI=true dive myapp:build --ci-config .dive-ci.yml

Пример содержимого файла:

rules:
  lowestEfficiency: 0.95
  highestWastedBytes: 20MB
  highestUserWastedPercent: 0.20

Провал: efficiency ниже 95%, лишние байты от 20 MB или доля лишнего от 20%. В последней метрике базовый слой исключён из общего размера. Пороги здесь учебные, подберите свои.

Оценка efficiency экспериментальная. Это проверка лишнего места, а не уязвимостей. В видео — интерактивный разбор слоёв, сам CI-режим работает без этого экрана.

Dive и правила CI
#арсенал_инженера

Миграция с VMware, домашний кластер, выросший из одного ноутбука, и ИИ для работы с инцидентами

Всё это на митапе Deckhouse User Community 12 ноября в Москве.

В программе три доклада:
— опыт НИУ «МИЭТ»: как университет переходит с VMware на виртуализацию Deckhouse — от пилота до миграции ВМ и резервного копирования;
— 13 лет домашней инфраструктуры: от одного ноутбука до геораспределённого кластера из нескольких квартир и дата-центров;
— IncidentGPT на практике: от участия в Open Source-проекте до внедрения в компании, а заодно переход с Prometheus на Deckhouse Prom++ ради экономии памяти.

Нетворкинг после основной программы тоже будет. :)

Где: People Loft, 1-я улица Энтузиастов, д. 12 (метро и D3 «Авиамоторная»).
Когда: 12 ноября, начало в 19:00. Сбор в 18:15, приходите! Возьмите с собой паспорт или водительское удостоверение.

Митап пройдёт только офлайн. Для участия зарегистрируйтесь на Timepad и дождитесь письма-подтверждения.