🔖 Эмуляция сетевых проблем в 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

#linux #networking

🔖 Наводим красоту в 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 и наслаждаемся.

#tools

🔖Говорим с 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 (буду очень благодарен за ⭐). На этом у меня всё - всем пока и приятного пользования.

#cicd #ai

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