Библиотека девопса | DevOps, SRE, Sysadmin

Почему операционные runbook - это спасение, а не бюрократия

Когда случается инцидент, мозг отключается первым.
Остаются только привычка и инструкции.

Хороший runbook - это документ, который:

1. Снимает стресс

Когда всё горит, видеть перед собой понятный чеклист - половина успеха.
Меньше паники - меньше ошибок.

2. Повышает MTTR

Чёткие шаги ➞ предсказуемые действия ➞ быстрый возврат сервиса.

3. Уменьшает bus-factor

Заболел единственный, кто "знает, что делать"?
Не проблема — знания уже лежат в runbook.

4. Убирает хаос

Инциденты редко уникальны.
Обычно это вариации одних и тех же проблем:
«диск переполнился», «база упала», «kube-scheduler решил отдохнуть».
Runbook превращает бардак в алгоритм.



Как выглядит рабочий runbook?

Минимальная структура:

- Контекст: что за система и как понять, что она неисправна
- Триггеры: alert'ы, метрики, логи
- Диагностика: команды, которые нужно выполнить
- Решения: пошагово, без "понятно же"
- Rollback / временные костыли
- Куда эскалировать
- Что записать в postmortem



Главная ошибка инженеров

Делать runbook после инцидента.
Правильный вариант: вести их как код - постепенно дополнять при любом изменении системы.

Runbook, который не обновляли 6 месяцев — не runbook.
Это исторический артефакт.

Подпишись 👉@devopslib

Почему большинство инцидентов происходят ночью?

Если посмотреть на статистику SRE-команд, почти 70% серьёзных инцидентов случаются после 23:00. Причина не в “мистике”, а в том, что ночью сходятся три фактора:

1. Накопленный technical debt
Патчи, которые “временно” залили месяц назад, начинают стрелять именно в момент минимального трафика - когда сервисы активнее пересобираются, переезжают, чистят очереди, крутят бэкапы.

2. Скедуленные задачи
Cron, ETL, бэкапы, реплики - всё это стартует после полуночи. Если что-то где-то неправильно рассчитано, concurrency внезапно уходит в космос.

3. Усталость дежурного
Даже идеальный инженер ночью реагирует медленнее. Отсюда более долгая диагностика, выше вероятность ошибки и неправильного rollback-а.

Как снизить риск?

- Отдельный staging для всех nightly-джобов.
- Автоматический анализ cron-нагрузки перед релизом.
- Progressive Delivery: тёмные релизы, canary, feature flags.
- Аналитика “частоты ночных ошибок” и профилактическая оптимизация.

Самый мощный прием - не выкатывать ночью. Ни один SLA не стоит бессонной ночи и кривого деплоя.

Подпишись 👉@devopslib

Почему сервисы «плывут» после релиза

Одна из самых болезненных проблем, когда вроде всё протестировано, всё зелёное, деплой успешен… а сервис внезапно начинает деградировать под реальной нагрузкой.

3 причины, которые чаще всего находил на проде:

1. Непредсказуемые паттерны трафика
Локальные и staging-тесты воспроизводят лишь типовые сценарии. Пользователи же способны создать такие комбинации запросов, о которых никто не думал.
Решение: включайте real-world нагрузку - реплеи боевых логов, canary с 1–5% трафика, shadow-traffic.

2. Неполная изоляция зависимостей
В тестовой среде сервисы живут в вакууме, а в проде начинают конкурировать за БД/кэш/очереди.
Решение: стрессовать зависимости отдельно: тестировать базу под 200% нагрузки, проверять деградацию кэша, моделировать задержки в сети.

3. «Невидимые» лимиты инфраструктуры
Тот самый случай, когда Kubernetes скейлится, но underlying-ресурсы — нет. Например, лимит RPS на ingress, ограничение соединений в Redis, или IOPS на дисках.
Решение: регулярно проводить game day: искать такие скрытые лимиты заранее, пока это не сделал прод.

Вывод: тестирование - это не про «пройти все QA-чеклисты». Это про понимание, как твой сервис ведёт себя в хаосе реального мира.

Подпишись 👉@devopslib

Тестирование отказоустойчивости: как DevOps проверяет «что будет, если всё сломается»


Что стоит тестировать регулярно:

1. Падение ноды/инстанса
Проверка, что оркестратор (Kubernetes, Nomad) перезапускает поды и перераспределяет нагрузку.

2. Недоступность внешних сервисов
Отказы DNS, очередей, баз. Важно увидеть, где нет таймаутов и ретраев.

3. Замедление дисков и сети
Часто не «падает», а деградирует. Медленные IO приводят к каскадным таймаутам.

4. Перегрев и рост нагрузки
Тестирование горизонтального и вертикального автоскейлинга.

5. Пробои в безопасности
Проверка, что отказ из-за блокировки, регенерации ключей или ротации сертификатов не валит прод.

Как это внедряют:

- Chaos Engineering (например, Chaos Mesh, Litmus).
Управляемый хаос показывает, как ведут себя реальные прод-нагрузки.

- GameDays
Команда собирается и моделирует реальные аварии: «Что будет, если умерет база?».

- SLO-ориентированный подход
Упавший компонент не считается проблемой, если не нарушены пользовательские SLO.

Что даёт грамотное тестирование отказоустойчивости:

- Минимизация RTO/RPO
- Предсказуемость поведения в пиковой нагрузке
- Повышение инженерной уверенности
- Чёткое понимание, где нужно инвестировать в инфраструктуру

Подпишись 👉@devopslib

Как я тестирую отказоустойчивость сервисов без боли и слёз

Один из самых частых вопросов в работе SRE а что будет, если упадёт X?
Чтобы не гадать, я регулярно использую небольшой собственный «чеклист хаоса». Он простой, но реально спасает от катастроф.

1. Отключаю один из инстансов сервиса
Если балансировщик начинает вести себя странно - фиксирую. Часто проблемы всплывают именно в момент деградации, а не отказа.

2. Имитирую деградацию базы
Замедление на 200–400 мс показывает, насколько хорошо сервисы работают с connection pool и retry-логикой.

3. Убиваю DNS на 30 секунд
Большинство проблем в проде - из-за DNS. Люблю тестировать, как приложение переживает недоступность резолвера.

4. Перегружаю сеть на 20–30%
Трафик растёт, очереди растут. Отличный способ понять, где узкое место: балансировщик, ingress или сам backend.

5. Проверяю автоскейлинг
Самая частая ошибка - красивые метрики, но неправильные триггеры. Тестирую всплесками нагрузки, а не «в теории».

Совет: запускай такие тесты маленькими порциями, но регулярно. Так инфраструктура становится предсказуемой, а инциденты - скучными.

Подпишись 👉@devopslib

🚨 Когда “сам себя перезапустил” — это не баг, а фича

Недавно один под обетом «никогда больше не трогать продакшн ночью» всё-таки зашёл “на минутку”.
Проверил pods, увидел CrashLoopBackOff, сделал kubectl delete pod, и - чудо - всё ожило!
Только через 10 минут понял, что просто три раза подряд перезапустил контейнер с тем же багом.

Moral of the story:
Не каждый автоперезапуск - спасение. Иногда Kubernetes просто смотрит на тебя и думает:

“Я делаю, что могу, но ты уверен, что хочешь, чтобы это продолжалось?”

🧠 Совет:
Если контейнер падает постоянно - не трогай pod. Смотри kubectl describe pod и kubectl logs -p.
Возможно, виноват init-контейнер, readiness-проба или ошибка в startup-скрипте.
И да - логи с -p спасают, когда под уже ушёл на перезапуск.

Подпишись 👉@devopslib

💥 Kubernetes хаос и решения. Часть 2 - «Боль автообновлений»

Если у тебя в кластере внезапно всё «упало» ночью, а утром тебя встретил alert с фразой “Pods not ready” - скорее всего, виноваты автообновления.

Сценарий классический:

- Включен auto-upgrade для node pool в GKE/EKS/AKS.
- Cloud-провайдер решил, что пора обновить kubelet и runtime.
- Worker-ноды перезагрузились, pods пошли в Terminating, Pending, а кластер стал частично неработоспособным.

Почему так происходит:

- Не настроены PodDisruptionBudgets (PDB).
- Нет стратегии drain с учётом приоритета workloads.
- Stateful приложения (Postgres, Kafka, Redis) теряют лидерство и консистентность.
- Контроллеры не успевают пересоздавать pod'ы из-за лимитов ресурсов или ошибок readinessProbe.

Как лечить:

1. Отключи автообновления для node pool - обновляй вручную.
2. Введи maintenance window, чтобы обновления шли только в заданные часы.
3. Определи PDB для всех важных pods - не более 1-2 одновременно недоступных.
4. Используй drain-сервис например, kured с контролем через annotations.
5. Тестируй обновления на staging-кластере - симулируй rolling drain.

Подпишись 👉@devopslib

💥 Kubernetes хаос и как его приручить

Все красиво, пока не падает прод. А потом ты открываешь kubectl get pods и видишь 37 подов в статусе CrashLoopBackOff.
Kubernetes вроде как должен “самоисцеляться”, но иногда он просто сидит и смотрит, как всё горит 🔥

Вот три типичных источника хаоса и как их быстро приручить:

1. Liveness / Readiness пробы
Когда они настроены неправильно - поды убиваются зря.
👉 Проверь, что readinessProbe не стреляется слишком часто, и добавь initialDelaySeconds.
Удивительно, как часто это спасает от самоуничтожения.

2. OOMKilled
Если ты видишь это в kubectl describe pod - у тебя проблема с лимитами.
👉 Поставь requests чуть ниже среднего потребления, limits - чуть выше пика.
И не забудь включить VerticalPodAutoscaler - пусть сам подскажет реальные цифры.

3. NetworkPolicies и DNS
Часто блокируются сервисы внутри кластера, особенно CoreDNS.
👉 Минимальный тест: kubectl exec -it pod -- nslookup kubernetes.default.
Если не работает - смотри NetworkPolicy и iptables в CNI.

Подпишись 👉@devopslib

Облако ITENTIS CLOUD: технологии топов, цена без наценки (и живая поддержка!)

Нашли брендовую вещь в надежном маркете на 30% дешевле? Вот и мы так же. 😉

ITENTIS CLOUD — не "бюджетный" вариант. Это ВСЕ те же технологии, что у Яндекса, Mail или VK (VPC, Kubernetes, S3, снимки, автомасштабирование), но...

🔥 ...ЗНАЧИТЕЛЬНО ДЕШЕВЛЕ! 🔥

Зачем платить за бренд? Получите то же самое (а кое-что лучше) и сэкономьте. Не верите? Сравните тарифы! Надежные дата-центры Tier III, как у всех.

И главное — наша поддержка. Вот где мы их РЕАЛЬНО обходим:

💩 У них: очереди, боты, ответ "в течение 24 часов".
😍 У нас: живой, компетентный специалист 24/7. Не бот! Настоящий человек, который РАЗБЕРЕТСЯ. Ответ за минуты. Сложный Kubernetes? Объясним и поможем. Это наш стандарт.

Что вы получаете за меньшие деньги:

1. Та же "начинка": все ключевые технологии (VPC, Kubernetes, S3 и т.д.) — как у топов.
2. Надежность: Tier III, 2FA, шифрование, брандмауэры.
3. Скорость: запуск кластера быстрее доставки пиццы.
4. Простой контроль: интуитивное управление.
5. ГЛАВНОЕ: цена, от которой улыбнетесь + поддержка, которая реально спасает.

"А подвох?" Да нигде!

▶️14 дней БЕСПЛАТНО: протестируйте всё.
▶️БЕСПЛАТНАЯ миграция: перенесем ваши проекты без простоев.
▶️Гарантия возврата: риск — ноль.

‼️ Понравится? Расскажите друзьям! Реферальная программа: за каждого клиента — бонус или скидка. Без мишуры.

Итог: ITENTIS CLOUD = Технологии топов + Честная цена + Человеческая поддержка 24/7.

Хватит переплачивать и ждать ответа! Получите максимум.

👉 Действуйте выгодно:

1. Сравните тарифы: https://itentis.cloud
2. Пишите:
🤖 Telegram-бот: @itentis_bot (Фраза: "Хочу облако дешевле Яндекса!")
✉️ Почта: sales@itentis.ru
3. Скажите: "Читал пост про ЭКОНОМИЮ в облаке!" 🚀(Получите бонус!)
4. Присоединяйтесь: https://t.me/+D0MuFDf8P1FlMTJi

https://itentis.cloud Мощное облако. Честная цена. Люди на связи.

Реклама. ООО "АВАНГАРД", ОГРН 1107746046550, erid: 2VtzqxcZdhf

💡 Сегодня немного про боль Kubernetes-кластеров

Когда у тебя всё крутится в k8s, кажется - удобно: автоскейлинг, изоляция, сервисы живут своей жизнью. Но как только в кластере начинают появляться десятки namespace и сотни подов, без нормальной политики ресурсов всё превращается в хаос.

👉 У каждого пода должны быть requests и limits. Если этого нет - кластер живёт как коммуналка без счётчиков: кто успел, тот и съел. Один жадный контейнер может легко задушить соседей.

👉 Мониторинг на уровне ResourceQuota и LimitRange реально спасает от «сюрпризов» в проде.

👉 А ещё - включите PodPriority и Preemption. Это даёт возможность критичным сервисам выжить, даже если какой-то non-prod под начал жрать всю память.

В итоге Kubernetes сам по себе не магия. Это инструмент. А инструмент требует гигиены и правил.

Подпишись 👉@devopslib

🚨 Скрытые расходы старого CI/CD

Очень часто вижу, что команды годами используют один и тот же CI/CD, который когда-то «поставили и забыли». На первый взгляд всё работает: пайплайны крутятся, артефакты собираются. Но внутри копятся скрытые издержки:

🐌 Медленные билды - ожидание деплоя в 10–15 минут превращается в десятки потерянных часов в месяц.
💸 Железо и лицензии - старые агенты гоняются на жирных VM, которые никто не оптимизировал.
🤯 Сложность поддержки — только один человек знает, как там всё устроено. Уйдёт - полкоманды будет гадать, что за магия в YAML.
🔒 Безопасность - забытые токены, старые версии раннеров, отсутствие актуальных патчей.

👉 В итоге мы «платим налог» не деньгами напрямую, а временем и рисками.

Что можно сделать:

1. Поставить метрики времени сборок и деплоя - пусть будет видно реальные цифры.
2. Разобрать пайплайны: есть ли шаги, которые можно параллелить или кэшировать.
3. Проверить обновления агента/раннера. Иногда апгрейд даёт +50% к скорости.
4. Автоматизировать инфраструктуру CI/CD через код (Terraform, Ansible, Helm) - чтобы не зависеть от «человека-ключа».

CI/CD - это не просто труба для кодека, а живой сервис. И его тоже надо мониторить и оптимизировать.

Подпишись 👉@devopslib

🚀 Как DevOps-инженеры мы часто увязаем в задачах автоматизации и забываем про «гигиену» инфраструктуры. А ведь простые проверки могут спасать от неприятных ночных алертов:

🔎 Периодически проверяй лимиты и квоты в облаке. Упёрся в лимит IP-адресов или дисков - и вот у тебя прод простаивает.

🧹 Смотри на orphan-ресурсы — старые volume, неиспользуемые load balancer’ы, забытые секреты в Vault. Всё это стоит денег и иногда может мешать.

🕓 Планируй регулярный audit logs review. Лишние сервисные аккаунты или подозрительная активность легко пропустить, если смотреть только на дашборды.

🛡 Не хардкодь секреты. Даже тестовые ключи лучше сразу класть в менеджер секретов, чтобы не ловить «утечку века» из git.

Внедрив маленькие привычки, можно сократить 80% неожиданных проблем и освободить время на то, что реально интересно.

Подпишись 👉@devopslib

💡 Многие девопсы недооценивают силу readiness и liveness проб в Kubernetes.

Проблема: без них kubelet считает под «живым», даже если приложение давно висит и не отвечает. В итоге у тебя в кластере «зелёные» поды, а пользователи шлют мат в поддержку.

👉 Разница:

LivenessProbe — проверяет, живо ли приложение. Если не отвечает - pod рестартует.
ReadinessProbe — проверяет, готов ли сервис обрабатывать трафик. Если нет - трафик не идёт, но pod не перезапускается.

⚙️ Частые ошибки:

- Делают одинаковый endpoint для обоих проб. В итоге под либо вечно рестартует, либо никогда не попадает в сервис.
- Ставят слишком жёсткие таймауты - приложение ещё грузит кэш, а kubelet уже думает «оно мёртвое».
- Забывают про startupProbe - и получают вечный рестарт на тяжёлых приложениях (например, Java с долгим стартом).

✅ Хорошая практика:

- liveness → простой healthcheck (например, GET /ping).
- readiness → что-то посложнее (например, проверка подключения к БД).
- startupProbe → обязательно для всего, что стартует дольше пары секунд.

Kubernetes умеет заботиться о твоих подах, но только если ты правильно объяснишь ему, что значит «жив» и «готов».

Подпишись 👉@devopslib

🔥 kubectl rollout restart - лучший друг девопса

Когда нужно быстро перезапустить деплоймент в Kubernetes, многие лезут редактировать манифест или руками удаляют поды. Но есть куда более элегантный способ:

kubectl rollout restart deployment my-app

Что делает эта команда:

- Не трогает сам манифест.
- Генерирует новый replicaSet с теми же образами.
- Аккуратно перезапускает поды по rolling update.

⚡️ Плюсы:

- Удобно для обновления конфигов (например, ConfigMap или Secret), если они примонтированы в поды.
- Можно применить массово:

kubectl rollout restart deployment -n my-namespace

- Работает и для daemonset / statefulset.

💡 Если хочешь проверить статус перезапуска:

kubectl rollout status deployment my-app

Подпишись 👉@devopslib

🚀 Как я однажды сломал прод одним kubectl apply

Сидишь себе спокойно, делаешь хотфикс, вроде всё готово. Думаю: "ну ща быстренько закатим" → kubectl apply -f deployment.yaml.
И тут - бах! Вылетает вся продовая нагрузка.

Почему?
А потому что в deployment.yaml был replicas: 1, а в кластере реально крутилось 12 подов. 😅
Kubernetes честно решил: "Ну раз надо 1, значит уберём остальные".
И убрал.

⚡️Вывод:

- Никогда не храните в гите "локальные" конфиги без проверки.
- Сравнивайте diff перед применением (kubectl diff -f ...).
- Лучше юзать GitOps (ArgoCD / Flux), чтобы руками не катать.

Теперь у нас правило: в прод руками через kubectl apply - нельзя. Только через пайплайны.


Подпишись 👉@devopslib

GitHub Actions: секреты без боли и утечек

Вот концентрат практик, чтобы ваши токены и ключи не вываливались в логи и чужие форки.

🔐 Где хранить

- Secrets: шифруются, доступны через secrets.*. Уровни: Repository, Environment, Organization, Dependabot.
- Variables (vars): не для чувствительного — просто конфиг.
- Environment + reviewers: ставьте для production - без апрува шаги с секретами не стартуют.

🪪 GITHUB_TOKEN и права
Явно задавайте права минимально необходимые:

permissions:
  contents: read
  id-token: write   # нужно для OIDC

Не полагайтесь на дефолты. Чем меньше - тем лучше.

🔄 OIDC вместо статических ключей
К облакам — без долгоживущих секретов:

jobs:
  deploy:
    permissions:
      id-token: write
      contents: read
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: AWS OIDC
        uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: arn:aws:iam::123456789012:role/gha-deploy
          aws-region: eu-central-1
      - run: aws sts get-caller-identity

Аналогично есть для GCP/Azure. Итог: нулевые постоянные ключи, только краткоживущие токены.

🧪 Секреты и PR из форков
По умолчанию секреты недоступны для pull_request из форков - и это хорошо.
Если нужно выполнить деплой/проверку после мерджа - делайте через workflow_run или отделяйте джобы:

if: github.event.pull_request.head.repo.fork == false

Избегайте pull_request_target для запуска непроверенного кода с секретами.

🧯 Не печатайте секреты

- Никогда не echo $SECRET.
- Прокидывайте через stdin:

echo "${{ secrets.NPM_TOKEN }}" | npm login --registry=https://registry.npmjs.org --scope=@org --auth-type=legacy --password-stdin

- Для временных значений добавляйте маску:

echo "::add-mask::${TOKEN_FROM_API}"

- Не включайте set -x/trace в шагах, где работают секреты.

🗝️ Секрет как файл

- name: Write SSH key
  run: |
    install -m 700 -d ~/.ssh
    printf '%s' "${{ secrets.DEPLOY_KEY }}" > ~/.ssh/id_ed25519
    chmod 600 ~/.ssh/id_ed25519

Если это PEM/JSON — храните в секрете как base64 и декодируйте в рантайме.

🧰 Склады секретов

- Централизуйте в Vault/SM (HashiCorp Vault, AWS/GCP/Azure Secrets Manager) + OIDC.
- В GitHub — используйте Org secrets и environment secrets для переиспользования.

🧹 Ротация и доставка

- Автоматизируйте через CLI:

gh secret set NPM_TOKEN --repo owner/repo --body "$TOKEN"
gh secret set PROD_DB_URL --env production --repo owner/repo --body "$URL"

- Добавьте регулярную ротацию токенов и ключей (календарь + скрипт/бот).

🛡️ Secret scanning
Включите Secret scanning и Push Protection для приватных реп - ловит утечки ещё до пуша/мерджа.

🧩 Шаблон безопасного деплоя

name: deploy
on:
  push:
    branches: [ main ]
jobs:
  deploy:
    environment: production   # защита + секреты проды
    permissions:
      contents: read
      id-token: write
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Login registry
        run: echo "${{ secrets.REGISTRY_TOKEN }}" | docker login ghcr.io -u ${{ github.actor }} --password-stdin
      - name: Cloud auth (OIDC)
        uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: arn:aws:iam::123456789012:role/gha-deploy
          aws-region: eu-central-1
      - name: Deploy
        run: ./scripts/deploy.sh

Чек-лист на дорожку: минимум прав, OIDC > статические ключи, секреты в environment, никакого echo, форки изолируем, сканирование включаем, ротацию автоматизируем.

Подпишись 👉@devopslib

🔥 GitHub Actions и секреты: как не словить утечку

Многие думают, что положить секреты в Secrets в настройках репозитория - это всё, можно расслабиться. Но есть нюансы:

1️⃣ Secrets = env vars
В рантайме GitHub Actions подставляет секреты как переменные окружения. Их легко случайно вывести в лог, если бездумно делать echo $SECRET_KEY. Логи сохраняются, а доступ к ним могут получить коллеги с правами на Actions.

2️⃣ Маскирование работает не всегда
GitHub пытается автоматически маскировать значения секретов в логах. Но если у тебя секрет - это, например, base64 строка или JSON, маскировка может сработать криво. Тут уже сам контролируешь вывод.

3️⃣ Не храни много секретов в репозитории
Лучше использовать GitHub OIDC (OpenID Connect) и получать временные креды от AWS, GCP или Azure прямо в рантайме. Так ты избежишь постоянных ключей в Secrets.

4️⃣ Используй environments
В GitHub есть Environments с отдельными секретами и правилами доступа. Можно разграничить staging/prod, включить approvals перед деплоем. Это must-have.

5️⃣ Проверяй permissions у Actions
По умолчанию GitHub даёт job полный доступ к GITHUB_TOKEN. Иногда достаточно permissions: read-only, а не write-all. Меньше прав → меньше дыр.

💡Для управления секретами в масштабах компании лучше интегрировать GitHub с HashiCorp Vault, Doppler или AWS Secrets Manager. Тогда GitHub Secrets будет только точкой входа, а не хранилищем всего подряд.

Подпишись 👉@devopslib

🛠️ GitHub Actions: секреты и подводные камни

GitHub Actions сегодня используют все - от пет-проектов до продакшн пайплайнов. Но даже у опытных инженеров часто встречаются ошибки при работе с секретами.

❌ Типичные ошибки:

- Хранение токенов в коде или .env файлах, которые случайно попадают в репозиторий.
- Вывод секретов в логи (например, через echo). GitHub заменяет их на ***, но иногда этого недостаточно.
- Использование одного общего токена для разных окружений (dev, staging, prod).

✅ Лучшие практики:

1. Secrets vs. Environments
Используй Environments с разными наборами секретов для разных стадий. Например: STAGING_DB_PASS и PROD_DB_PASS.

2. OIDC вместо токенов
GitHub поддерживает OIDC Federation. Это значит, что пайплайн может получать временные креды от AWS, GCP или Azure без хранения ключей.

3. Проверяй разрешения по умолчанию
В permissions: указывай минимально необходимые. Например:

   permissions:
     contents: read
     id-token: write
   

4. Secrets scanning
Включи secret scanning и push protection, чтобы случайно не залить ключи.

💡 Маленький трюк:
Если нужно временно отладить пайплайн с секретом - лучше использовать ::add-mask:: в логах, чем echo.

Подпишись 👉@devopslib

🔥 GitOps - next level для DevOps

Раньше деплой выглядел так: написали Helm-чарт → закинули kubectl apply → надеемся, что всё взлетит. Но у такого подхода куча минусов: ручные действия, нет прозрачного аудита, легко ошибиться.

🛠 Решение - GitOps.

👉 Суть: всё, что крутится в кластере, описано в Git.

- Изменения вносим через Pull Request.
- CI прогоняет проверки.
- Спец-оператор (ArgoCD или Flux) синхронизирует кластер с Git-репозиторием.

📌 Преимущества:

- Истина всегда в Git → легко откатиться.
- Аудит и история изменений из коробки.
- Меньше доступа к самому кластеру → безопаснее.
- Автоматическая самовосстановляемость: если кто-то руками изменит деплой, GitOps всё вернёт.

💡 По сути, Git становится "центральным управлением инфраструктуры".
Если раньше у вас был ssh и kubectl, то теперь всё решает git push.

❓А у вас уже есть GitOps в проде или пока классические пайплайны?

Подпишись 👉@devopslib

🔥 CI/CD пайплайны: боль или спасение?

Любой DevOps рано или поздно сталкивается с тем, что пайплайн превращается в монстра: шаги на 2000 строк, десятки if-ов, и полдня на разбор «почему не задеплоилось».

Но по сути CI/CD - это не только «запустить тесты и выкатить в прод», а целая философия:

🔹 CI (Continuous Integration)

- каждое изменение мержится быстро и проверяется автоматически;
- цель - держать main-ветку в «рабочем» состоянии всегда;
- меньше конфликтов и сюрпризов при релизах.

🔹 CD (Continuous Delivery/Deployment)

- всё, что прошло CI, можно выкатывать хоть в прод;
- ручная кнопка или автодеплой — зависит от зрелости команды;
- уменьшает время «от коммита до продакшна».

⚡️ Где ломается магия?

- Если пайплайны начинают жить своей жизнью, а разработчики боятся их трогать.
- Если тесты гоняются по часу, и команда снова жмёт «на выходных зарелизим».
- Если нет нормальной стратегии отката.

💡 Совет: держи пайплайн простым, модульным и прозрачным. Лучше несколько коротких пайплайнов, чем один гигант.

А у тебя пайплайн больше похож на швейцарские часы или на «дженкинс на костылях»? 😅

Подпишись 👉@devopslib