Перейти к содержанию

Рецепты

Конкретные workflow'ы, где srekit совмещается с реальным тулчейном. Каждый рецепт — copy-paste; меняй пути, имена команд, ID под свой контекст.

Сгенерить постмортем и запостить метаданные в трекер

TITLE="API outage"
SEV="SEV-1"
START="2026-05-06T08:00Z"
END="2026-05-06T09:30Z"

# Записать документ
srekit postmortem --title "$TITLE" --severity "$SEV" \
  --start "$START" --end "$END" \
  --out "postmortem-$(date -u +%Y-%m-%d).md"

# Извлечь метаданные и запостить
srekit postmortem --title "$TITLE" --severity "$SEV" \
  --start "$START" --end "$END" --json |
  jq '{title: .meta.title, severity: .meta.severity, started_at: .meta.start, ended_at: .meta.end}' |
  curl -X POST https://tracker.example.com/api/incidents \
    -H 'Content-Type: application/json' -d @-

Релизный день: отрезать changelog, потом затегать

srekit changelog release правит текст и на этом останавливается. Он не коммитит, не тегает и не пушит, поэтому необратимые шаги остаются под твоей рукой:

VERSION=1.2.0

# 1. Посмотреть до того, как это ляжет в файл
srekit changelog release --version "$VERSION" --dry-run

# 2. Отрезать: [Unreleased] уезжает под датированный заголовок, блок ссылок обновлён
srekit changelog release --version "$VERSION"

# 3. Отревьюить diff — изменились только [Unreleased], новая версия и блок ссылок
git diff CHANGELOG.md

# 4. Закоммитить и затегать
git commit -am "release: $VERSION"
git tag -a "v$VERSION" -m "$VERSION"
git push origin main "v$VERSION"

Бэкфилл версии, вышедшей до перехода на srekit, или версии, которую отозвали:

srekit changelog release --version 0.0.5 --date 2014-12-13 --yanked

CI-гейт: упасть, если changelog разъехался

Ловить региональную дату, выдуманный change type или пропущенное определение ссылки на pull request'е, а не после того, как на документе споткнётся downstream-тулинг:

name: changelog
on: [pull_request]
jobs:
  validate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v6
      - run: |
          curl -fsSL https://github.com/jtprogru/srekit/releases/latest/download/srekit_Linux_x86_64.tar.gz \
            | tar xz srekit
      - run: ./srekit changelog validate

Сообщается каждая проверка, job падает, если упала хотя бы одна. Локально — та же команда:

srekit changelog validate
# OK    heading-shape
# FAIL  change-types: unrecognized change type line 31: Improvements; allowed: Added, Changed, ...

Массово отрендерить runbook'и для всех сервисов из списка

while IFS= read -r service; do
  srekit runbook --title "p99 spike" --service "$service" \
    --out "runbooks/$service-p99.md" --force
done < services.txt

CI-гейт: упасть если кастомный шаблон не парсится

.github/workflows/templates.yaml:

name: templates
on: [push, pull_request]
jobs:
  validate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v6
      - run: |
          curl -fsSL https://github.com/jtprogru/srekit/releases/latest/download/srekit_Linux_x86_64.tar.gz \
            | tar xz srekit
      - run: ./srekit templates validate ./templates

Cron — недельная сводка дежурства

crontab -e:

0 18 * * 0  cd ~/work && srekit oncall-report --team platform \
              --out "reports/oncall-$(date -u +%Y-W%V).md"

Доставка в Slack вместо файла:

srekit oncall-report --team platform --stdout |
  curl -F file=@- -F channels=oncall-summaries \
    -F token=$SLACK_TOKEN https://slack.com/api/files.upload

Поймать дрейф шаблонов после апгрейда srekit

После brew upgrade srekit:

srekit templates list --json |
  jq '[.[] | select(.status == "embedded-only" or .status == "customized") | .name]'
# ["task.yaml", "runbook.yaml"]   # вот это посмотреть

Или просто diff:

srekit templates diff --name-only
# differs  runbook.yaml
# differs  slo.yaml

Дальше srekit templates upgrade смержит их через 3-way.

Разные identity под разные проекты

Конфиг-файл содержит личную identity; в .envrc рабочего репо (через direnv):

export SREKIT_AUTHOR="Mikhail Savin"
export SREKIT_EMAIL="m.savin@work.example.com"

cd в work-репо — srekit автоматом подхватит рабочую identity для RFC / on-call документов.

Закрепить версию srekit на проект

Некоторые команды хотят чтобы все инженеры использовали одинаковую версию srekit для воспроизводимости. Закрепить в project-скрипте:

#!/usr/bin/env bash
# bin/srekit
set -euo pipefail
WANT=0.32.1
HAVE=$(srekit --version 2>&1 | awk '/srekit version:/ {print $3}')
if [[ "$HAVE" != "$WANT" ]]; then
  echo "srekit $WANT required (have $HAVE)" >&2; exit 1
fi
exec srekit "$@"

Два репо, один источник шаблонов

Часто для multi-repo организаций: один общий sre-templates репо, много consumer'ов.

# В setup'е каждого репо:
git clone git@github.com:acme/sre-templates ~/.acme/templates
echo "templates_dir: ~/.acme/templates" >> ~/.config/srekit/config.yaml

# Подтянуть обновления:
srekit templates pull

Нужна отправная точка? jtprogru/sre-templates — готовый к клонированию пример ровно в той раскладке, что ждёт srekit: используй напрямую или форкни как основу общего репозитория организации.

См. также