🚀 Чеклист для продакшн-сервера на Linux

Проверяешь ли ты каждый новый сервер перед выкатыванием в прод? Вот тебе мини-чеклист, чтобы ничего не забыть:

1. 🔐 Безопасность
- Отключен root-доступ по SSH
- Включен firewall (например, ufw, firewalld)
- Обновлены все пакеты (apt upgrade / yum update)
- Установлены fail2ban / sshguard
- Развернута система логирования (rsyslog, journald + shipping в Loki/ELK)

2. 🛠️ Система
- Настроен NTP / systemd-timesyncd
- hostname прописан в /etc/hosts
- Правильно выставлены лимиты в /etc/security/limits.conf
- swap включен/отключен по требованиям
- Разделение дисков по best practice (/var, /tmp, /home и т.д.)

3. 📈 Мониторинг и алерты
- node_exporter или другой агент установлен
- alertrules настроены
- Логи собираются (Promtail, Filebeat, и т.д.)
- Проверка доступности (blackbox, ICMP, TCP)

4. ⚙️ DevOps ready
- CI/CD агент установлен (GitLab Runner, Jenkins agent, и т.д.)
- SSH ключи от CI добавлены
- Конфиги под контроль версий
- .env файлы спрятаны, secrets — в vault

5. 🧪 Smoke тесты
- Проверка CPU/RAM/Disk через stress-ng
- Проверка открытых портов ss -tuln
- curl и ping до нужных сервисов (внутренних/внешних)

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

🚀 Зачем DevOps-инженеру уметь читать ядро Linux?

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

📌 Когда это нужно:
- 🐛 Твой сервис падает на проде с segfault, и strace`/`gdb не дают внятной картины.
- 🔥 Системные лимиты или поведение cgroup'ов не совпадают с документацией.
- ⏱ Ты хочешь точно понять, что делает epoll_wait() или почему OOM killer прибивает твой процесс.

📖 Как начать:
1. Выбери версию ядра, с которой работаешь (uname -r тебе в помощь).
2. Клонируй исходники:

   git clone https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
   cd linux
   git checkout v5.x.x  # нужная версия
   

3. Ищи интересующие syscalls или подсистемы:
- fs/, kernel/, mm/, net/, ipc/ — ключевые директории.
- grep -rn "do_fork" или grep -rn "epoll_wait" — твои друзья.

🧠 Советы:
- Начинай с высокоуровневого понимания — читай документацию kernel.org, LWN.net, статьи от разработчиков.
- Используй cscope, ctags или LSP в редакторе — иначе заблудишься.
- Комментируй код для себя: через неделю забудешь, что понял.

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

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

🚀 Твоя система тормозит? А может, просто iowait шалит?

Очень часто мы жалуемся на "тормоза" в Linux, но глядим в top — а CPU загружен всего на 10%. Где подвох? А подвох в iowait.

iowait — это время, которое CPU тратит в ожидании ввода-вывода. То есть процессор мог бы работать, но ждет, пока закончится обращение к диску или сети.

Как диагностировать:

1. Открываем top или htop
Смотрим на строку Cpu(s): — там будет wa (wait):

   %Cpu(s):  5.3 us,  1.0 sy,  0.0 ni, 90.2 id,  3.5 wa, ...
   

2. Проверяем с iostat (из пакета sysstat):

   iostat -xz 1
   

Обрати внимание на await и util.
- await — среднее время ожидания операций I/O (чем выше, тем хуже).
- util — насколько загружен диск (100% = забит под завязку).

3. Используем dstat для наглядности:

   dstat -cdlmn --disk-util
   

Причины высокого iowait:
- Убитые HDD (с долгими seek time)
- Недостаточно RAM → активный swap
- NFS или медленные блочные устройства (ceph, iscsi)
- Базы данных без индексов или с большим кол-вом random I/O

Что делать:
- Проверить SMART у дисков: smartctl -a /dev/sdX
- Убедиться, что swap не используется без нужды: free -h, vmstat 1
- Настроить кэширование или перенести данные на SSD
- Мониторить в динамике: atop, netdata, grafana + node_exporter

🧠 Не забывай: низкая загрузка CPU не всегда значит, что всё хорошо. Иногда система просто ждёт диск.


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

🧠 Зачем set -e в bash-скриптах — и почему он может вас подставить

Многие пишут в баш-скриптах в начале:

#!/bin/bash
set -e

Типа: пусть скрипт падает при первой ошибке. Звучит здраво. Но есть нюанс.

Вот такой код:

set -e
mkdir /tmp/test || true
echo "Продолжаем..."

Что произойдёт, если /tmp/test уже существует?

👉 mkdir вернёт ошибку, но || true спасёт нас. Скрипт пойдёт дальше.

А теперь так:

set -e
if some_command; then
  echo "OK"
fi

Если some_command завершится с ненулевым кодом — всё, скрипт упадёт до входа в if.

🧨 И таких подводных камней с set -e хватает.

💡 Решение — аккуратнее: либо продуманные конструкции вроде if, ||, &&, либо использовать trap и обрабатывать ошибки осознанно.


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

🚨 Как быстро вычислить утечку памяти в Linux?

Когда система начинает “подтормаживать” без видимой причины — пора заподозрить утечку памяти. Вот как можно быстро найти виновника.

🔍 1. Проверяем использование памяти:

free -h

Если available стремится к нулю, есть повод копнуть глубже.

🔧 2. Сортируем процессы по потреблению RAM:

ps aux --sort=-%mem | head -n 10

Тут видно, кто больше всех ест память.

🧠 3. Следим за slab-объектами:

cat /proc/meminfo | grep Slab

Если значение растёт со временем — это сигнал утечки в ядре или драйверах.

🧪 4. Используем smem для точной оценки:

smem -r | sort -k 4 -nr | head

smem учитывает shared memory — оценка куда точнее, чем просто ps.

🎯 5. Если подозрение на конкретный процесс:
pmap — покажет, что именно грузит память:

pmap -x <PID>

🔥 Совет:
Запусти htop, нажми F6, выбери колонку RES, отсортируй. Увидишь — кто на самом деле обжора.

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

🧵 Чеклист перед выкладкой инфраструктурного кода в прод

Инфраструктура как код — мощная штука. Но даже один криво закоммиченный main.tf может повалить пол-продакшена. Вот мини-чеклист, который стоит прогонять перед мержем в main.


✅ 1. План применён?
terraform plan или pulumi preview должен быть свежим и понятным. Никаких сюрпризов в духе «удаляется продовая БД».

✅ 2. Есть backend?
Убедись, что состояние хранится не локально. Используй S3, GCS или аналог — иначе в один день ты потеряешь всё.

✅ 3. -target не попал в CI/CD
Временно использовать -target ок, но не коммить это в pipeline. Это костыль, а не стратегия.

✅ 4. Защищён ли state?
Шифрование включено? Доступ только у нужных людей? terraform state show — часто недооценённый источник чувствительных данных.

✅ 5. Модули не обновились «магически»?
Проверь, что версии всех модулей и провайдеров зафиксированы. Плавающие версии — путь к хаосу.

✅ 6. Документация и комментарии есть?
Ты можешь помнить, зачем это поле у S3, но через месяц ты же сам себе не поверишь. Пиши сразу.

✅ 7. Прогонен tflint / checkov / terraform validate?
Линтеры и валидация — это как spellcheck, но для продакшена. Лишними не будут.

✅ 8. Обратная совместимость учтена?
Изменения в ресурсах типа ALB, IAM policy или security group могут незаметно порушить весь трафик.

✅ 9. Всё в Git?
Terraform code без Git — это как сервер без мониторинга. Безответственно.

✅ 10. Apply сначала в staging!
Если у тебя нет stage-среды — ты и есть stage. Надеюсь, у тебя хорошая страховка.


🛠 Ты можешь автоматизировать почти всё из этого списка. Но думать всё равно придётся. Хотя бы пока.


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

🚀 Проверка сетевых подключений с помощью ss

Команда ss — мощный инструмент для диагностики сетевых соединений в Linux. Она быстрее и информативнее старого доброго netstat. Вот несколько фишек, которые стоит знать:

🔸 Все соединения:

ss -tunap

Покажет TCP/UDP соединения, номера портов, PID процесса и имя.

🔸 Слушающие сокеты:

ss -tuln

Флаг -l фильтрует только те сокеты, которые находятся в состоянии LISTEN.

🔸 Фильтрация по порту:

ss -tuln sport = :22

Можно искать соединения по конкретному порту. Например, 22 — SSH.

🔸 Сокеты определённого процесса:

ss -p | grep nginx

Находит все подключения, где участвует nginx.

🔸 Состояния TCP:

ss -tan state established

Показывает только активные установленные TCP-соединения.

🧠 Если ты до сих пор используешь netstat, попробуй ss.

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

🧩 Почему важно использовать .env файлы в DevOps-проектах

Когда проект начинает обрастать конфигурацией, секретами, API-ключами и разными переменными окружения — легко всё потерять или случайно выложить в Git. Именно тут на сцену выходят .env файлы.

📦 Что такое .env?
Это простой текстовый файл с ключ-значениями, например:

DB_HOST=localhost
DB_USER=admin
DB_PASS=secret

Он не исполняется напрямую, но может быть подгружен в окружение с помощью утилит вроде dotenv, source, или встроенных механизмов в Docker, Compose, CI/CD и так далее.

🔐 Почему это круто:

- Безопасность: не хардкодим чувствительные данные в коде
- Гибкость: можно легко переключаться между dev/stage/prod окружениями
- Поддержка: большинство инструментов CI/CD и фреймворков умеют работать с .env
- Удобство: один файл — все переменные

🛡️ Совет:
Добавь .env в .gitignore, иначе можно случайно закоммитить секреты.

📌 Если работаешь с Docker Compose — укажи env_file в docker-compose.yml:

services:
  app:
    env_file:
      - .env

Так контейнеры будут сразу знать, какие переменные им нужны.

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

🚀 История одной фичи: systemd-run
(aka когда надо быстро запустить что-то от другого пользователя)

Ситуация: ты по SSH, нужно срочно что-то запустить от имени другого пользователя. sudo su? su -? screen? tmux? crontab?
Остановись. Посмотри на это:

sudo systemd-run --uid=appuser --pty bash

💡 Что происходит:
Ты создаёшь временный unit в systemd, от имени пользователя appuser, и получаешь интерактивную сессию в его окружении. Всё красиво, под контролем systemd, с логами, cgroup и т.п.

Можно запускать и отдельные команды:

sudo systemd-run --uid=appuser --pty top

Или фоново:

sudo systemd-run --uid=appuser --scope my-command

🔥 Преимущества:
- работает даже если shell пользователя отключён
- не требует входа в сессию
- всё логируется в journald
- systemd сам подчищает за собой

👀 Используй, когда:
- хочешь тестить что-то от другого юзера
- автоматизируешь запуск задач
- нет желания возиться с su/sudo/scripts

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

🧠 Фичи в Kubernetes, которые ты почти точно не используешь (а зря)

Сегодня делюсь парочкой полезных, но часто игнорируемых возможностей Kubernetes, которые могут упростить жизнь DevOps'а.


🚀 Init Containers
Всё ещё пихаешь скрипты и ожидания в основной контейнер? Init containers — твои друзья. Они запускаются до основного контейнера и идеально подходят для всяких подготовительных задач: прогрев кэша, валидация конфигов, ожидание зависимостей и т.д.


🔒 PodSecurityPolicy (PSP) (устарело, но ты знал?)
Да, PSP deprecated, но оно до сих пор используется в куче продакшенов. Если не хочешь мигрировать на OPA/Gatekeeper прямо сейчас — хотя бы убедись, что PSP у тебя не дырявая.


📦 Ephemeral Containers
Идеальны для отладки. Хочешь зайти в прод-под без шелла или нужных утилит? Добавляешь ephemeral контейнер с bash’ем, curl’ом и всем нужным, не перезапуская под.

kubectl debug -it pod-name --image=busybox

🌐 NetworkPolicy
Ты уверен, что твои поды не могут лезть куда угодно? Пока не включены NetworkPolicy, твой кластер — как квартира без дверей. Даже самый кривой Dev может случайно (или не очень) сломать пол интернета изнутри.


⏱ Liveness vs Readiness
Это не одно и то же. Readiness говорит, когда трафик можно пускать. Liveness — когда под умер. Если перепутал — получишь либо DDoS от своих же сервисов, либо перезапуск в вечном цикле.


Пользуешься всеми? Респект. Нет? Самое время попробовать.

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

🚀Проблема, которой нет — и почему это важно замечать

Сегодня на проде упал alert: "Disk usage > 90%". Все бросились проверять, начали чистить старые логи, сносить временные файлы…
Через час выяснилось — в этом pod-е выключен log rotation. Логи не собираются, monitoring — через copy-paste из другого сервиса.
А теперь внимание — это staging. Его давно никто не трогал, и его… можно было просто пересоздать.

💡Мораль:
Иногда мы влетаем в тушение "проблем", не задавая себе один простой вопрос: а это вообще проблема?
DevOps — не только про решение задач, но и про грамотный приоритез. Не каждое красное — это пожар.

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

🧰 Тёмные уголки CI/CD: почему твой pipeline тормозит и как его починить

Когда pipeline в CI/CD работает медленно, это не просто раздражает — это напрямую бьёт по скорости релизов и нервам команды. Вот тебе список часто забываемых причин, почему всё может тормозить, и как это исправить:


🔥 1. Лишние шаги в pipeline
Ты удивишься, сколько "временных" тестов или сборок остаются навсегда. Проверяй каждый шаг — реально ли он нужен?

💡 Что делать:
Периодически проводи ревизию pipeline. Удаляй устаревшие шаги или разделяй pipeline на fast/slow треки.


🐌 2. Медленные Docker-образы
Если ты каждый раз тащишь 1GB образ, то ничего удивительного. Особенно если не используешь кеш.

💡 Что делать:
- Используй multi-stage build
- Обрезай base-образы
- Включи кеширование слоёв в CI


🔁 3. Нет параллельного выполнения
Когда всё идёт строго по очереди, даже быстрая задача может затянуться.

💡 Что делать:
- Разбивай pipeline на независимые джобы
- Включай matrix билд, если тестируешь на разных платформах/версиях


🧪 4. Тесты без приоритета
Падают все тесты? А если бы сначала шли самые "ломкие", ты бы быстрее увидел фейл.

💡 Что делать:
- Отдели "fast-fail" тесты
- Используй тегирование и запускай важные тесты в первую очередь


📦 5. Устаревшие dependencies
Половина времени уходит на попытки подтянуть несуществующие версии библиотек или ждать response от старых package registry.

💡 Что делать:
- Используй lock-файлы
- Ставь кеш для зависимостей
- Обновляй registry mirror


Медленный pipeline — это технический долг. Он не только тратит твое время, но и мешает экспериментам. Оптимизируй — и сам себя поблагодаришь.

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

🚀 Terraform vs Pulumi: Что выбрать?

Инфраструктура как код (IaC) давно уже не новость, но выбор инструмента всё ещё вызывает споры. Terraform и Pulumi — два мощных игрока, и вот коротко о том, где каждый из них shines ✨:

🟩 Terraform — стабильный, проверенный временем:
- HCL читается легко, даже если ты не девелопер.
- Большое сообщество, куча модулей.
- Отлично подходит для "декларативных" команд — описал состояние и забыл.
- Работает везде: AWS, Azure, GCP, даже VMware и всякие niche-провайдеры.

🟦 Pulumi — больше, чем просто IaC:
- Пишешь инфраструктуру на реальных языках: TypeScript, Python, Go, C#.
- Можно строить абстракции, писать модули как нормальный код, использовать CI/CD-практики без боли.
- Очень удобно для Dev-first команд.

🤔 Что выбрать?
- Если у тебя инфраструктурная команда и важна стабильность — бери Terraform.
- Если у вас fullstack/DevOps-инженеры, которые уже пишут на Go или TS — Pulumi даст больше гибкости.

💡 А может и то, и другое? Некоторые проекты используют оба инструмента: core-инфра — на Terraform, динамические окружения — на Pulumi.

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

🔧 Почему systemd – это не только про запуск сервисов

Многие до сих пор думают, что systemd нужен только для того, чтобы стартовать сервисы. Но на деле он — как швейцарский нож для линуксоидов.

Вот несколько его «скрытых» возможностей, которые ты, возможно, упускаешь:

🔹 systemd timers — альтернатива cron. Более гибкая, с логами, юнитами, и возможностью зависимости от других сервисов.

🔹 systemd-run — запускай любые команды как временный сервис. Отлично подходит для тестов, отложенного выполнения или запуска с нужными лимитами ресурсов.

🔹 Resource control (cgroups) — через systemd можно ограничить CPU, память, IO для любого юнита. Прям как в Kubernetes, только локально.

🔹 journalctl — лог-менеджер, которого ты заслуживаешь. Фильтры по юниту, по времени, по PID, по приоритету — goodbye, grep.

🔹 User units — можно писать юниты не только для root, но и для обычных пользователей. Отлично для изоляции окружений.

Если ты до сих пор относишься к systemd как к init-процессу — попробуй копнуть глубже. Он вполне может заменить кучу сторонних тулзов и сделать твою систему чище.

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

Kubernetes: не клади всё в один namespace 🧠

Кажется мелочью, но namespace — один из ключевых инструментов для поддержания порядка в проде. Правильное разделение — это безопасность, изоляция и удобство поддержки. Разберём, как использовать namespace’ы по-взрослому.


Зачем это вообще нужно?

Namespace в Kubernetes — способ логической изоляции ресурсов. Если не следить за этим, вы рискуете:
- словить конфликт имён между сервисами
- дать доступ тем, кому не надо
- усложнить отладку и мониторинг


Что стоит выносить в отдельные namespace'ы:

1. По окружениям
Создайте dev, staging, prod — и не пересекайте. Это основа безопасного и предсказуемого CI/CD.

2. По командам или микросервисам
Например, team-a, team-b, billing, auth. Удобно для разграничения прав и алертов.

3. По системным компонентам
Например, monitoring, logging, infra. Не мешайте Prometheus и Nginx Ingress с боевыми сервисами.


Бонусы от правильной изоляции:

- RBAC на namespace — это 🔐 DevSecOps must-have
- Снижается blast radius при ошибках (kubectl delete all --all -n wrong-namespace — и прод цел)
- Упрощается мониторинг: фильтрация по namespace в Grafana — как отдельный дешборд
- Логи в Loki, метрики в Prometheus — нагляднее и чище


Антипаттерны, которых стоит избегать:

🚫 Один namespace на всё (особенно default)
🚫 Генерация namespace в CI (ns-392839) без чистки
🚫 Namespace без resource quotas и limit ranges


Вывод:
Разделяй и властвуй. Namespace — не просто "для красоты", а фундамент для масштабируемого, безопасного и поддерживаемого кластера. Если вы до сих пор всё кидаете в default — пора рефакторить 🛠


📚 Дополнительно:
- https://kubernetes.io/ru/docs/concepts/overview/working-with-objects/namespaces/
- https://github.com/kubernetes-sigs/kustomize

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

🛠 Как DevOps превращается в саппорта: незаметный дрейф

Инфра стабильна. Мониторинг молчит. Алёрты — тишина.
Ты думаешь: «Ну наконец-то! Можно позакрывать долги, потрогать Terraform, почитать про eBPF…»

И тут приходит тикет:
> «Что-то не работает»
> «Перезапустите под»
> «Очистите кеш в Redis»
> «Можно дать доступ другу моего кота в Kubernetes?»

И ты уже не инженер. Ты саппорт. Уровень 0.
С каждым таким тикетом ты немного забываешь, как настраивать Helm-чарты и лочить версии в Ansible.

📌 Как не утонуть:
- Фильтруй. Не всё требует DevOps-инженера. Делегируй.
- Автоматизируй. Скрипты, self-service, боты.
- Защищай фокус. Оповести команду: есть баг — пиши в багтрекер, а не в личку.
- Заводи «тихие часы» без чатов — только код.

DevOps — не helpdesk.
Напоминай об этом не только другим, но и себе.

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

🚀 Как правильно выбрать образ для контейнера в продакшн

Погнали! Выбираешь образ для своего контейнера — казалось бы, что тут сложного? ubuntu:latest, node:alpine, python:3.11 — звучит знакомо, да? Но на проде каждая мелочь имеет значение.

🧩 Вот чеклист, как выбрать правильный образ:

1. Минимализм решает
- Меньше образ — меньше поверхность атаки.
- alpine, distroless, scratch — отличные кандидаты.
- Но не забывай: в alpine может не быть нужной тебе библиотеки. Проверь заранее.

2. Понимание зависимостей
- Не ставь лишнего. Не нужен тебе curl, vim, gcc — не ставь.
- Чем меньше зависимостей, тем проще отлаживать, меньше шансов на уязвимости.

3. Только стабильные теги
- Никогда не используй latest в продакшене.
- Всегда указывай конкретную версию: python:3.11.3, node:18.16.0.

4. Сканируй образы
- Используй trivy, grype, dockle.
- Встроенные инструменты в CI — мастхэв.

5. Собирай свои образы
- Не бойся билдить свои минимальные образы на базе scratch или distroless.
- Так ты точно знаешь, что внутри.

💡 Микро-лайфхак: если тебе нужно просто что-то запустить в минималистичном окружении — посмотри на busybox. Это магия.

Контейнеры — это не просто “запустить что-то”. Это часть твоей безопасности, скорости и стабильности.

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

🔥 Helm как оружие массового деплоя: лучшие практики и грабли

Helm — неотъемлемый инструмент в арсенале любого DevOps-инженера, работающего с Kubernetes. Но с ростом количества чартов и окружений легко наступить на старые грабли. Разберём, как использовать Helm эффективно и безопасно.


🧩 1. Разделяй и властвуй: структура чартов

Многие начинают с одного монолитного чарта, но это быстро выходит из-под контроля. Рекомендации:
- Используй umbrella chart для сложных сервисов
- Выноси повторяемые компоненты в зависимые чарты (shared ingress, redis, etc.)
- DRY: общие шаблоны в _helpers.tpl

Пример:

{{- define "myapp.fullname" -}}
{{- printf "%s-%s" .Release.Name .Chart.Name | trunc 63 | trimSuffix "-" -}}
{{- end -}}

🔐 2. Конфиденциальность прежде всего

Не храни secrets в values.yaml. Используй:
- Sealed Secrets
- External Secrets Operator
- Шаблонизацию из Vault через helm template + envsubst


🚀 3. CI/CD и Helm: как подружить

Интеграция Helm в GitHub Actions или GitLab CI:
- Используй helm lint и helm template для проверки
- Делай dry-run перед деплоем
- Храни versioned values-файлы в Git для окружений

GitLab пример:

deploy:
  script:
    - helm upgrade --install myapp ./chart --values values-prod.yaml --atomic

🧠 4. Версионирование и откаты

Каждый деплой — новая версия:
- helm rollback — must-have в инцидентах
- Храни changelog в Chart.yaml (appVersion, version)
- Применяй GitOps-подход: Helmfile, ArgoCD, Flux


✅ Вывод:

Helm — мощный инструмент, если его не превращать в набор костылей. Избегай хранения конфиденциалки в явном виде, поддерживай структуру чартов чистой и используй Helm как часть CI/CD, а не вручную. И не забывай про helm diff перед обновлениями 😉

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

🚀 Этапы построения надёжного CI/CD пайплайна

1. Определение требований и целей
Перед началом нужно понять:
- Какие языки и фреймворки используются?
- Какие окружения нужны (Dev, Stage, Prod)?
- Какие ограничения по безопасности?
- Где будут хоститься приложения: AWS, GCP, Azure, on-prem?


2. Выбор инструментов
Для надёжного CI/CD стоит выбрать проверенные инструменты:

| Этап | Инструменты (примеры)
|---------------------| ---------------------------------------|
| VCS | Git (GitHub, GitLab, Bitbucket)
| CI | GitHub Actions, GitLab CI, Jenkins, CircleCI
| CD | ArgoCD, Spinnaker, FluxCD, Helm, Terraform
| Контейнеризация | Docker, Podman
| Оркестрация | Kubernetes (EKS, GKE, AKS, self-hosted)


3. Организация структуры репозитория
Стандартизируйте репозиторий:
- src/ — исходники
- tests/ — тесты
- infra/ — инфраструктура (Terraform, Ansible)
- .github/workflows/ или .gitlab-ci.yml — pipeline-файлы


4. CI: Проверка кода
Основные этапы CI:
- 🧪 Юнит-тесты
- 🧼 Линтинг
- 🛡️ Security сканеры (например, Trivy, Snyk)
- 📦 Сборка артефакта (Docker-образ, binary и т.п.)
- 📂 Кэширование зависимостей (ускоряет сборку)

Пример шага в GitHub Actions:

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Install deps
        run: npm ci
      - name: Run tests
        run: npm test

5. CD: Автоматическое развёртывание
Продумайте каналы релиза:
- Dev: автоматически по каждому пушу в develop
- Staging: ручной запуск из CI
- Production: только через Pull Request и одобрение

CD-инструменты (например, ArgoCD или GitOps подход) автоматически разворачивают приложение из Git-репозитория манифестов.


6. Инфраструктура как код (IaC)
Terraform, Ansible, Pulumi — обязательны для управляемости.

Пример команды:

terraform init
terraform plan
terraform apply

7. Secrets Management
Никаких секретов в коде!

✅ Используйте:
- AWS Secrets Manager
- HashiCorp Vault
- GitHub/GitLab Secrets
- Sealed Secrets (в K8s)


8. Мониторинг и оповещения
После деплоя:
- Мониторинг: Prometheus + Grafana, NewRelic, Datadog
- Логи: ELK, Loki, CloudWatch
- Алёрты в Slack/Telegram


9. Валидация и откат
- Блю/Грин или Канареечный деплой
- Автоматический откат при неуспешной health-check проверке


10. Security Best Practices
- Автоматическая проверка CVE
- Сканирование Docker образов
- Ограничение доступа (IAM, RBAC)


🔒 Пример простого пайплайна (GitHub Actions + Docker + Kubernetes)

1. Пуш в main → запускается CI
2. Сборка Docker-образа и пуш в registry
3. Автообновление image в манифесте (kustomize/Helm)
4. ArgoCD замечает изменения и разворачивает новую версию

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

Как не убить свой продакшн в пятницу вечером

Есть старое правило: "Не выкатывай релизы в пятницу". Но почему, если всё автоматизировано и тесты зелёные?

Потому что:
- Даже идеальный код может сломаться на реальных данных.
- Даже самая крутая инфраструктура может повести себя неожиданно.
- Даже если баг фиксится быстро — собрать всех нужных людей в пятницу вечером сложно.

Что делать:
- Планируй релизы на начало недели.
- Делай канареечные выкаты — сначала на часть пользователей.
- Пиши чёткие план отката (rollback plan) к каждому релизу.
- Настраивай алертинг и мониторинг заранее.

И помни: лучше провести вечер за пиццей, чем за дебагом продакшна через VPN в кафе.

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