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

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

Инфраструктура как код — мощная штука. Но даже один криво закоммиченный 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. Надеюсь, у тебя хорошая страховка.


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

Подпишись 👉 @channel_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, отсортируй. Увидишь — кто на самом деле обжора.

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

Работаете с СУБД? Присоединяйтесь к сообществу Pangolin для разработчиков и администраторов баз данных!

Pangolin DB — это PostgreSQL с 100+ доработками, и команда СберТеха открыто рассказывает о его разработке.
 
В канале «СУБД Pangolin» найдете:
🔹 Глубокие разборы архитектуры и кода
🔹 Кейсы оптимизации и доработки PostgreSQL
🔹 Советы и опыт инженеров
🔹 Вебинары и встречи с экспертами
🔹 Вакансии и жизнь команды от первого лица
 
Присоединяйтесь к сообществу, где говорят на языке баз данных!

🚀 Зачем 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, а системным ниндзя, которому по плечу всё — от тюнинга производительности до траблшутинга на голом железе.

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