🔖 Динамические матрицы в 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"

Продолжение далее… 🔽

#github_actions

🔖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