💸 Мой коллега потратил $900 на AWS сертификаты и вот что получил

Спойлер: не работу мечты, а три PDF-ки в LinkedIn и завышенное ЧСВ.

Два года назад мой коллега поверил в миф "нужны сертификаты для карьерного роста". Сдал Solutions Architect Associate, потом Professional, потом DevOps Engineer. $300 + $300 + $300. Плюс время на подготовку — недели три на каждый.

Что изменилось после получения сертификатов? Ничего.

Почему сертификаты AWS/Azure — это не то, что вы думаете

1. Они проверяют знание экзамена, а не технологии

Вопросы на экзамене:

• "Какой сервис AWS использовать для X?"
• "Сколько максимум Y в Z?"
• "Что лучше: A или B в контексте C?"

Реальная работа:

• Terraform не применяется, потому что state locked
• Права IAM настроены так, что ничего не работает
• Бюджет не позволяет использовать "правильное" решение из экзамена

2. Готовятся через dump-сайты

90% тех, кто сдает AWS — просто зубрят вопросы с Whizlabs/TutorialsDojo. Мой коллега сам так делал. Это не обучение, это натаскивание на экзамен.

Можно сдать AWS Solutions Architect за неделю, ни разу не заходя в консоль AWS. Проверено.

3. Рекрутеры на них не смотрят

Я опросил 5 знакомых tech lead'ов и HR'ов. Вопрос: "Сертификат AWS в резюме — это плюс?"

Ответы:

• "Не минус" (4 человека)
• "Показывает мотивацию, но не skill" (3 человека)
• "Смотрю на опыт, а не на бумажки" (5 человек)
• "Если есть опыт без сертификата vs сертификат без опыта — беру опыт" (5 из 5)

Ноль предложений, где написано "required: AWS certification". Все пишут "желательно", но берут без него.

4. Они устаревают быстрее, чем действуют

Его Solutions Architect Associate (2024 года) уже содержит устаревшую информацию про EC2 pricing models. AWS меняет сервисы каждый месяц. Сертификат действует 3 года. Считайте сами.

5. Стоят неадекватных денег

$300 за экзамен. Еще $50-100 на курсы подготовки. Еще 40-60 часов времени.

За эти деньги и время можно:

• Поднять home lab на AWS free tier и получить реальный опыт
• Сделать pet project и выложить на GitHub

Когда сертификаты имеют смысл

Справедливости ради, есть случаи, когда они нужны:

1. Компания AWS Partner — им нужно X сертифицированных сотрудников для партнерского статуса. Вас попросят сдать, и компания оплатит.

2. Внутренние политики корпораций — некоторые банки/энтерпрайзы требуют сертификаты для работы с их облаком. Бюрократия.

3. Виза/релокация — в некоторых странах сертификаты = "подтверждение квалификации" для рабочей визы.

4. Вы джун без опыта — сертификат хотя бы показывает, что вы в теме. Но GitHub с проектами лучше.

Что реально важно

Вместо того, чтобы платить $300 за PDF, сделайте:

1. Pet project на AWS с Terraform

• Поднимите EKS кластер
• Настройте CI/CD через GitHub Actions
• Добавьте мониторинг (CloudWatch/Prometheus)
• Опубликуйте код на GitHub

2. Изучайте технологии на практике

• Разверните реальную инфраструктуру на AWS free tier
• Пройдите hands-on labs и tutorial'ы от AWS
• Экспериментируйте с разными сервисами и архитектурами

Это даст реальное понимание, а не заученные ответы на экзамен.

3. Научитесь проходить собеседования

• Прокачивайте soft skills: как рассказывать о своем опыте
• Готовьтесь к техническим интервью: разбор кейсов, system design
• Учитесь учиться: умение быстро осваивать новые технологии важнее любого сертификата

Работодатели ищут людей, которые умеют решать проблемы и быстро адаптироваться, а не тех, кто вызубрил ответы на экзамен.

Вывод

Сертификаты AWS/Azure — это не scam, но их ценность сильно переоценена.

Если у вас есть $300 и 60 часов:

• ❌ Не идите сдавать сертификат ради галочки в LinkedIn
• ✅ Постройте что-то реальное и покажите это

Опыт бьет бумажки. Всегда.

У кого есть сертификаты облаков? Помогли ли они в карьере? Или это просто красивый значок?

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

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

https://youtube.com/shorts/gLeHYmySjDY?feature=share

🐘 Рабочий кейс: PostgreSQL жрала 16 GB RAM. Проблему нашёл за 1 SQL-запрос

На проекте e-commerce БД начала жрать память. PostgreSQL 14, сервер 32 GB RAM, из которых 16 GB уходило на базу. Staging с 10 RPS тормозил — запросы 2-3 секунды вместо 100 мс.

Диагностика за 5 минут

Шаг 1: Проверил размер базы

SELECT pg_size_pretty(pg_database_size('production_db'));
-- 8.2 GB (нормально)

Шаг 2: Размер таблиц

SELECT tablename, pg_size_pretty(pg_total_relation_size('public.'||tablename)) 
FROM pg_tables WHERE schemaname = 'public' 
ORDER BY pg_total_relation_size('public.'||tablename) DESC LIMIT 5;

user_sessions — 2.1 GB при 5000 юзеров онлайн. Подозрительно.

Шаг 3: Размер индексов

SELECT indexname, pg_size_pretty(pg_relation_size(indexrelid))
FROM pg_indexes JOIN pg_class ON indexrelid = pg_class.oid
WHERE schemaname = 'public' ORDER BY pg_relation_size(indexrelid) DESC;

Бинго:

user_sessions_data_gin_idx | 12.4 GB ❌

Индекс 12.4 GB при таблице 2.1 GB — красный флаг.

Шаг 4: Проверил использование индекса

SELECT indexrelname, idx_scan FROM pg_stat_user_indexes 
WHERE indexrelname = 'user_sessions_data_gin_idx';
-- idx_scan: 12 (за неделю!)

Проблема: GIN-индекс на JSONB

GIN индексировал весь JSONB:

{
  "cart": {"items": [...]},  // до 50 товаров
  "history": {"viewed_products": [...]},  // до 100 ID
  "tracking": {"pages_visited": [...]}  // десятки страниц
}

5000 сессий × 100 ключей в JSON = 500k записей в индексе. Плюс старые сессии.

Использовался 12 раз за неделю. Жрал 12 GB RAM.

Решение

DROP INDEX user_sessions_data_gin_idx;

Результат:

• PostgreSQL memory: 16 GB → 4.5 GB
• Query latency: 2-3 сек → 80-150 мс
• Освободилось 12 GB на диске

Бонус: Нашёл 180k протухших сессий, добавил cleanup cron → таблица 2.1 GB → 400 MB.

Вывод

GIN-индексы на JSONB жрут в 5-10x больше памяти, чем сама таблица.

Проверяйте использование через pg_stat_user_indexes. Если idx_scan низкий — индекс не нужен.

Индексируйте конкретные поля, а не весь JSON:

-- Плохо:
CREATE INDEX ON user_sessions USING gin (session_data);

-- Хорошо:
CREATE INDEX ON user_sessions ((session_data->>'user_id'));

Один SQL-запрос показал индекс на 12 GB, который используется 12 раз в неделю. Удалил — сэкономил 12 GB и ускорил запросы в 20 раз.


У кого были проблемы с прожорливыми индексами в PostgreSQL?

Вопрос без ответа висит дольше, чем хотелось бы?

У нас есть комьюнити — группа GigaDevOps, где:

🎙 Проходят смолтоки: живые неформальные созвоны о карьере, инструментах, реальном DevOps
🎯 Мок-собеседования: потренироваться вживую перед настоящим интервью
👨‍💻 Общение с практикующими DevOps-инженерами, которые отвечают на вопросы из реальной работы

Можно смотреть контент. А можно ещё и спрашивать.

Ссылка на группу 👇
https://t.me/gigadevopscommunity

Влиться в команду, понять процессы, не облажаться на первых задачах — это реально сложно без поддержки рядом.
Большинство джунов остаются с этим один на один. Наши — нет.
Куратор помогает разобраться, не паниковать и двигаться вперёд даже когда кажется что всё идёт не так.

https://youtube.com/shorts/p-DwkmQdM0A?feature=share

🎭 "Культурный fit" - вежливый способ дискриминации

Спойлер: когда говорят "вы не подходите по культуре", на самом деле говорят "вы не похожи на нас".

Я провел 50+ собеседований как интервьюер. Видел, как "культурный фит" используется, чтобы не брать нормальных кандидатов по причинам, которые никто не озвучит.

Реальные отказы по "культурному фиту"

Кандидат 1: Middle DevOps, техническое 9/10.
Отказ: "Не подходит по культуре"
Реально: "Слишком тихий, мы активная команда"
Перевод: интроверт не нужен.

Кандидат 2: Senior, 7 лет опыта, решил все задачи.
Отказ: "Культурный фит под вопросом"
Реально: "Он старше всех в команде (38 лет), будет некомфортно"
Перевод: эйджизм.

Кандидат 3: Женщина, Strong Middle.
Отказ: "Не уверены в культурном соответствии"
Реально (курилка): "В команде одни парни, не впишется"
Перевод: сексизм.

Кандидат 4: Парень из Узбекистана, Senior.
Отказ: "Культурные различия"
Реально: "Акцент сильный"
Перевод: национальная дискриминация.

Почему это проблема

1. Нет критериев
Технические навыки измеряются. "Культурный фит" = субъективное мнение = bias.

2. Закрепляет однородность
Нанимаем "похожих на нас" → команда-клон одного типа людей: того же возраста, взглядов, бэкграунда.

3. Легальное прикрытие
Нельзя сказать "ты старый/женщина/иностранец". Но можно "культурный фит" — legal.

Как это работает

Вопрос: "Представь, мы идем в бар после работы. Как себя поведешь?"
Это не про навыки. Это проверка свой/чужой.

Вопрос: "Расскажи про хобби"
Игры/аниме → "инфантильный". Семья → "не вовлечен". Спорт → "свой".

Правильного ответа нет. Есть ответ "похожий на интервьюера".

Что делать

Кандидатам:

Спрашивайте конкретику:

• Какие конкретно ценности я не разделяю?
• Какие примеры поведения смутили?

90% времени ответа не будет. Потому что причина не в культуре.

Red flags:

• "Мы как семья" 🚩
• "Молодая команда" (эйджизм)
• "Team player" (сверхурочные без доплат)

Работодателям:

Замените "фит" на "value alignment":
Не "похож ли", а "разделяет ли ценности": прозрачность, ownership, готовность учиться.

Структурированные интервью:
Одинаковые вопросы всем. Оценка по критериям, не по "ощущениям".

Вывод

"Культурный фит" — про комфорт, а не ценности.

Людям комфортно с похожими. Но однородные команды хуже решают проблемы и пропускают ошибки.

Если кандидат прошёл техническое, но "не подходит по культуре" — спросите честно: это про ценности или про то, что он не похож на вас?


P.S. Кста 19 марта в 19:00 МСК проводим практикум — разбираем реальные DevOps-задачи с AI в эфире. Приносите свои задачи, решим вместе.

👉 Зарегистрироваться

🔴 LIVE через 5 минут!

Практикум: Решение DevOps задач с AI в 10 раз быстрее

РЕГИСТРАЦИЯ

Мы уже начали. Заходите!

Все боятся что ИИ вытеснит разработчиков. И этот страх понятен.
Но DevOps — это про инфраструктуру, процессы, безопасность. Это руки, голова и ответственность за то, чтобы всё работало. Это не автоматизируется кнопкой.
DevOps-инженеры нужны были, нужны и будут — независимо от того, что умеет ChatGPT.

https://youtube.com/shorts/5yidAjxC1vw?feature=share

Многие сисадмины понимают, что DevOps — это х2 к зарплате и другой уровень задач. Но почему-то откладывают.

Почему именно ты ещё не перешел в DevOps?

🤔 Не знаю с чего начать
😭 Нет времени учиться
😱 Боюсь что не возьмут
🔥 Уже в процессе

🚀 Если ты сисадмин и чувствуешь потолок — это для тебя

Работаешь с серверами, знаешь Linux, но зарплата стоит на месте, а в DevOps не берут без Docker и CI/CD?

26 марта в 19:00 МСК проводим вебинар: разберём как администратору перейти в DevOps и выйти на 200–300к+.

Что будет:
- Пошаговый план перехода за 3–6 месяцев
- Карта стека: что уже есть, что добрать
- Как подготовиться к собеседованию и забрать оффер на 200к+

Ведёт Виталий — ментор с 6 годами опыта в DevOps/SRE. За прошлый год помог 200+ людям перейти из админа в DevOps.

👉 ЗАНЯТЬ МЕСТО

Сисадмин зарабатывает в 2 раза меньше DevOps-инженера

И это не теория - данные Хабр Карьеры и hh.ru:

Junior: 75 000 ₽ против 110 000 ₽ (+47%)
Middle: 120 000 ₽ против 210 000 ₽ (+75%)
Senior: 165 000 ₽ против 340 000 ₽ (+106%)

При этом сисадмин уже знает половину нужного стека: Linux, сети, troubleshooting.

Сколько времени занимает переход?

4 месяца с учётом поиска работы - при условии что занимаешься системно, а не "посмотрю курс когда будет время".

По словам реальных DevOps-инженеров: "почти 90% моих коллег - бывшие сисадмины".

Главная ловушка, в которую все попадают:

Прыгают сразу в Kubernetes, не освоив Docker и Linux. На собеседованиях это вскрывается мгновенно.

Правильный порядок: Linux - Git - Docker - CI/CD - Terraform/Ansible - Kubernetes - облака.

Другая ловушка: год теории без практики. Каждый инструмент должен закрепляться pet-проектом - иначе через месяц всё забудется.

Переход с 75 000 ₽ (junior сисадмин) до 210 000 ₽ (middle DevOps) - это ×2,8 за 2-3 года. Один из самых выгодных карьерных манёвров в российском IT.

> > > > >

Если хочешь пройти этот путь системно - приходи на вебинар 👇
РЕГИСТРАЦИЯ

DevOps Middle 250к — потолок? Разбираю зарплатные данные 2026 по Хабр Карьере и hh.ru
https://telegra.ph/DevOps-Middle-250k--potolok-03-22

BTW на вебинаре разберем по косточкам эту тему, регистрируйтесь:

👉 РЕСГТРАЦИЯ НА ВЕБИНАР

💪 Лучшие DevOps-ы приходят по рекомендации - так было с половиной наших учеников.

Если ты уже учишься или учился с нами и знаешь кого-то, кому это нужно - приводи. За каждого ученика получишь 10% от стоимости его обучения реальными деньгами на карту.

Как это работает:

• Получаешь свою партнерскую ссылку
• Делишься ссылкой с другом
• Друг заходит на обучение - ты получаешь 10%

🤜🤛Поделитесь со знакомыми, жду в моем рабочем акке @sandoromarini

⚡️ Стартуем через 5 минут!

Вебинар: Как администратору перейти в DevOps и выйти на 200–300к+

👉 РЕГИСТРАЦИЯ

Эфир открыт. Заходи!

Провели вебинар «Из админа в DevOps» — спасибо всем кто был.
Разобрали путь из администратора в DevOps — от текущих навыков до оффера на 200к+.
Запись вебинара осталась — пиши, отправлю.
Хочешь понять, что конкретно тебе нужно для перехода в DevOps — Федор разберёт твой кейс лично.
👉 @sandoromarini

🔥 Helm chart, который я писал 2 дня и который сломал прод

Два дня.
Lint — чистый. Staging — зелёный. Code review — approved.

Пятница. 17:00.

helm upgrade --install 

Enter. Закрыл ноутбук.

Через 3 минуты — Grafana красная.
Поды падают один за другим.

Первые мысли — окей, сейчас откатимся.

helm rollback — зависает.
Релиз в состоянии pending-upgrade.

Приложение сломано.
Задеплоить фикс невозможно.
Пайплайн просто встал.
Полная блокировка.

kubectl logs --previous — пусто.
kubectl describe — ничего полезного.
helm get manifest — и вот оно.

Одна строка в values.yaml:

replicas:

nil → nil pointer → контейнер даже не стартует.

И это не какая-то «редкая ошибка».

В 2021 инженер в Skyscanner пропустил пару {{ }} в шаблоне.
ArgoCD воспринял это как удаление namespace’ов — и снёс прод во всех регионах.
4.5 часа даунтайма.

В Leroy Merlin сделали helm upgrade --force для рестарта.
Helm убил все поды сразу. Потом начал поднимать новые.
В этот момент — полный outage.

И по статистике, ~79% инцидентов в Kubernetes — это не баги в коде.
Это изменения конфигурации.

✔️ После этого у меня осталось три правила:
helm diff upgrade — смотреть изменения ДО деплоя
helm lint --strict + helm template --debug — гонять локально
--atomic --timeout 10m — всегда, без исключений

И отдельное:
никогда не использовать --force в проде.

81% команд на Kubernetes используют Helm.
И при этом большинство проблем — не в Kubernetes, а в том, как мы пишем чарты.

У тебя был момент, когда Helm ломал прод? 👇

💀 Jenkins умер? Не совсем. Но для новых проектов — почти да
“Jenkins уже не актуален?” Если смотреть на цифры — нет.

Он всё ещё держит около 44% рынка, используется в большинстве enterprise-компаний и встречается даже в 80% Fortune 500.
Но важный момент — это не рост, а инерция.

С 2018 года доля упала примерно с 70% до текущих значений.
И почти весь новый рост рынка забрали другие инструменты.

🧠 Что реально происходит
В новых проектах Jenkins почти не выбирают. Не потому что он “плохой”, а потому что есть более простые варианты.

GitHub Actions, GitLab CI или Argo дают:
— старт за часы, а не дни
— отсутствие инфраструктуры
— нормальный DX без Groovy и плагинов

В итоге Jenkins остаётся там, где он уже есть.
А не там, где выбирают с нуля.

⚠️ Почему от него уходят
Главная проблема — не в возможностях, а в стоимости поддержки.
Jenkins почти всегда означает: отдельный сервер, плагины, обновления, отладку и человека, который этим занимается.

Плюс со временем накапливается классический “plugin hell”: десятки зависимостей, где любое обновление может что-то сломать.

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

🧩 Где он всё ещё на своём месте
При этом Jenkins не “умирает” — у него есть понятная ниша.

Он по-прежнему удобен там, где:
нужен on-prem, жёсткий контроль данных или air-gap
много легаси и нестандартных интеграций
несколько VCS и сложные пайплайны
кастомное железо или тяжёлые билды

В таких условиях он часто остаётся самым гибким вариантом.

🧠 Итог
Jenkins — это уже не инструмент “по умолчанию”, это инструмент “по необходимости”.

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

И это нормально.

Потому что в DevOps инструменты меняются быстрее, чем системы, которые на них построены.

🤖 AI-агент для Kubernetes → Jira: полезный инструмент или генератор шума
Идея простая:
алерт → AI разобрался → создал тикет.

И это уже не эксперимент.
k8sgpt (7 500 ⭐️) в CNCF Sandbox, HolmesGPT уже используется в продакшне.

🧠 Что происходит на практике
Prometheus срабатывает → AlertManager группирует алерты → webhook летит в AI-агент.
Агент подтягивает контекст из Kubernetes (логи, describe, события), после чего LLM решает: создать тикет, агрегировать или проигнорировать.

На выходе — тикет в Jira с уже собранным контекстом.

💸 Сколько это стоит
Около $0.32 за 1 000 алертов (GPT-4o mini).

Для большинства команд это практически ноль.
И проблема точно не в деньгах.

⚠️ Где всё ломается
Наивная реализация превращается в спам.
Падает нода → падают поды → каждый шлёт алерт → агент создаёт десятки тикетов на одну проблему.

Решение всегда одно и то же:
1. Группировка алертов в AlertManager
2. Дедупликация (например, по fingerprint через JQL).

🧩 Когда AI не нужен
До 80% алертов в Kubernetes предсказуемы.

CrashLoopBackOff, OOMKilled, disk full — всё это проще и надёжнее обрабатывается правилами.

Если можно решить через if/else — лучше решить через if/else.
Это быстрее и без сюрпризов.

🧠 Когда он действительно полезен
AI имеет смысл там, где обычный routing уже не справляется:
— нужно связать несколько алертов
— разобрать логи или stack trace
— понять нетипичную ситуацию без runbook

📚 Ресурсы:
• k8sgpt: github.com/k8sgpt-ai/k8sgpt
• HolmesGPT: github.com/HolmesGPT/holmesgpt
• K8s MCP Server: github.com/Flux159/mcp-server-kubernetes
• Jira MCP: github.com/sooperset/mcp-atlassian

🇷🇺 DevOps в России ≠ западный roadmap

💵 В любом DevOps-roadmap всё выглядит красиво:

Linux → Docker → Kubernetes → CI/CD → Terraform → Monitoring → Cloud.

🧨 Но на реальной работе вас проверяют не по тому, сколько инструментов вы “изучили”.

Проверяют другое:

— можете ли разобраться в чужой инфраструктуре;
— понимаете ли, почему сервис не стартует;
— умеете ли читать логи;
— можете ли аккуратно поменять конфиг;
— не ломаете ли то, что уже работает;
— умеете ли задавать нормальные вопросы;
— способны ли довести задачу до результата.

🪆В российских компаниях часто нет идеальной инфраструктуры из туториала.

Там может быть старый Jenkins рядом с GitLab CI, on-prem вместо облака, Kubernetes “как настроили до вас”, ручные деплои, Zabbix, Prometheus, Grafana, ELK/Loki и legacy-сервисы, к которым страшно прикасаться без базы.

Поэтому DevOps нельзя учить только как список технологий.

Сначала нужна база:

➖ Linux: процессы, systemd, права, логи, диагностика
➖ сети: DNS, TCP/IP, HTTP, порты, маршруты
➖ Git: ветки, merge request, ревью, история изменений
➖ Docker: Dockerfile, образы, volume, network, compose
➖ CI/CD: pipeline, артефакты, причины падений
➖ Kubernetes: Pod, Deployment, Service, Ingress, ConfigMap, Secret
➖ мониторинг и логи: понять, что сломалось и где искать причину

Но после базы начинается главное — работа на испыте.

Потому что там вас оценивают уже не как новичка, а как человека, которому можно дать задачу:

“Разберись, почему деплой падает после merge.”
“Посмотри, почему сервис недоступен из namespace.”
“Добавь переменную в pipeline и не сломай прод.”
“Проверь логи, там что-то с подключением к базе.”
“Опиши, что сделал, чтобы другой инженер понял ход решения.”

В GigaDevOps мы не продаём иллюзию, что после просмотра уроков человек автоматически становится инженером.

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

Цель — не просто “изучить DevOps”.

Цель — выйти на работу, выдержать реальные задачи, дедлайны и ответственность.

DevOps в России — это не западный roadmap.

Это база + практика + умение работать в живой инфраструктуре.

Дочитали — пишите в коментах промокод МАЙ26 и забирайте подарок у @ratushnov касается всех, даже действующих студентов.