DevOps *

Экономим с FinOps: доклады экспертов отрасли

Учиться на чужих ошибках дешевле, чем на своих. Практики FinOps рассказали, как разбирались с облачными расходами.

FinOps без иллюзий

Игорь Гальцев: FinOps – это не должность и не софт, а процесс. Инженеры, финансисты и менеджмент должны работать вместе, а из инструментов – только теги, распределенное бюджетирование и алерты. 

Когда счёт прилетает внезапно

Антон Черноусов из Yandex Cloud запустил проект без лимитов. Как итог – счёт на $2700 за день. Решить проблему помогла настройка бюджетов, алертов и автоматизации.

Практика и культура

Антон Егорушков из Купер (СберМаркет) рассказал, что динамические стенды и скоринг команд напрямую влияют на то, как расходуются бюджеты. Поэтому культуру FinOps строить сразу, иначе потом выйдет дороже.

Простые шаги

Станислав Погоржельский из VK Cloud считает, что экономия приходит как побочный эффект порядка. Добиться этого можно тестированием нагрузки, настройкой лимиты автоскейла и хранением файлов там, где надо. 

FinOps в Kubernetes

Алексей Минаев: 70% переплат сидят в Kubernetes, потому что ресурсов выделяют больше, чем используют. В итоге CPU загружен на 13%, память на 20%. Правильные реквесты и автоскейл поднимают утилизацию до нормальных 70%, и переплата исчезает.

SaaS и лицензии

Дитер Мейсон из Roku: FinOps не ограничивается только облаком. FinOps – это в том числе про управление подписками, аномалии в продлениях лицензий и, конечно, расчёт ROI.

Есть чем поделиться? Вступайте в наше сообщество Практики FinOps.

Как реально экономить на облаке с FinOps: рабочие кейсы

Мы много пишем о FinOps, о том, как он устроен и чем полезен. Но реальный опыт всегда интереснее любой теории. 

Мультиоблака и прозрачность

Поначалу Купер вообще не применял FinOps в своей работе, но потом привязал теги, CMDB и автоматизацию через Terraform. Результат: 75% расходов распределяются по владельцам, прозрачность и прогнозируемость бюджета. 

Производство и инженерный FinOps

ST Microelectronics работают с маленькой FinOps-командой, но экономят миллионы. Инженеры сами прогнозируют свои расходы и получают бонусы за точность прогнозов. В итоге их экономия – 30% без ущерба для SLA. 

Госсектор и Data Lake

Transport for NSW безуспешно боролись с зомби-ресурсами и ручными выгрузками. А потом запустили FinOps-дашборды и детектор аномалий. Как результат – расходы на Data Lake упали на 22%.

Автоматизация вместо таблиц

inQdo Cloud считали все расходы в Excel. Но когда внедрили FinOps-платформу, автоматизировали биллинг и нашли утечки бюджета, ситуация изменилась. Аналитику они сделали платной услугой для клиентов — и FinOps начал зарабатывать сам на себя.

Еще мы разобрали кейсы Qventus, Sportradar, Лемана Тех и NinjaCat. Проблемы у всех похожие, а решения разные: кто-то внедрил chargeback, кто-то показал разрабам цену запроса, а кто-то просто настроил автовыключение неиспользуемых ресурсов. Но все остались в плюсе.

Есть что рассказать? Залетайте в наше сообщество в Telegram и поделитесь своей историей с единомышленниками.

Привет, Хабр! Мы только что получили из типографии топовую DevOps-новинку этого года — книгу Камиль Фурнье и Иэна Ноуленда «Инжиниринг платформ: техническое и управленческое руководство». Промокод для читателей Хабра (скидка 32%) - fournier.

Переведённая нами статья Камиль Фурнье с описанием круга проблем и задач, которые решает книга - Инжиниринг платформ: не CFEngine единым / Хабр

Аннотация книги

Базовая книга по инжинирингу платформ – новому подходу к управлению программными системами, при работе с которыми требуется обслуживать множество разных аппаратных архитектур и операционных систем. Показано развитие концепции DevOps и объяснено, как  учитывать запросы и возможности пользователей независимо от способа работы с приложением, минимизировать задержки при обработке данных и упрощать масштабирование и поддержку многоплатформенных продуктов. Описан комплексный  подход к управлению продуктом с учетом потребностей клиентов, разработчиков, системных администраторов и предприятия в целом, актуальный на любых программных платформах.

Для специалистов DevOps, системных администраторов, руководителей команд

Поделимся итогами исследования State of DevOps Russia 2025 на вебинаре

Команда «Экспресс 42» опросила тысячи инженеров и разработчиков для исследования состояния DevOps в России 2025. И вот анализ ответов завершён, а результаты готовы! Мы поделимся ими на вебинаре, который пройдёт 31 октября в 12:00 по московскому времени.

Зарегистрируйтесь, чтобы узнать, как изменился российский DevOps за год и какие тренды прослеживаются в индустрии — с фокусом на Developer Experience, ИИ и ИБ. Мы расскажем, какие инструменты и практики используют компании и покажем, как применить выводы исследования в ваших командах.

Что обсудим:

• характеристики Developer Experience, которые отличают высокоэффективные команды;

• задачи, для которых компании используют ИИ-инструменты;

• практики внедрения ИБ в процесс разработки;

• изменения в зарплатах и вакансиях DevOps-специалистов за год.

Будем вас ждать!

Привет, подкрутил немного свой kui. Добавил применение фильтра к подам в режиме подсматривания (watch it).

Теперь можно подсматривать только за интересными стрючками.

Творите, выдумывайте, пробуйте!)

Эгегей, kui еще немного окреп! Добавил команду 'rollout to revision'. Теперь можно откатывать деплои на определенную версию а не только на предыдущую.

Творите, выдумывайте, пробуйте!)

🔥 Как это было! Итоги Ansible Security CTF

14 октября мы собрались в уютном Failover Bar (г. Санкт-Петербург) 🏠, чтобы по-настоящему прокачать свои навыки в DevOps и кибербезопасности 🚀

Огромное спасибо всем участникам нашего интенсива "Ansible Security CTF – Защищай и Атакуй!" – вы сделали этот вечер незабываемым! 🙏

Что мы делали:
🛡 Писали Ansible playbooks, чтобы мгновенно закрывать уязвимости
🔎 Активно сканировали, подбирали пароли, искали флаги с помощью nmap, hydra и curl
💬 Общались, обменивались опытом и заводили новые знакомства!

🎉 Поздравляем победителей и напоминаем, что еще месяц в Failover Bar можно потренироваться на кейсах из интенсива! 💡В этом вам поможет бот 🤖 для CTF - https://t.me/DebugProCTF_bot

📆 Не хотите пропустить следующие мероприятия? Подписывайтесь на бота 🤖 DebugSkills - https://t.me/DebugProBot

👀 Ссылка на запись мастер-класса тут - https://vkvideo.ru/playlist/-232485571_2/video-232485571_456239019?linked=1

👀 Все фото в нашем канале - https://t.me/DebugSkills

Привет, небольшой апдейт. Добавил еще один тип k8s объектов который теперь можно тыкать kui'ем - volumeattachment

Творите, выдумывайте, пробуйте!)

Привет, как узнать % использования PVC? Kui поможет! Добавил команду PVC Usage

PVC это абстракция поэтому прямого пути (команды) узнать использование PVC нет. Как сделано? Ищем стручек (pod) который использует искомый PVC:

pvc_used_in=$(
    kubectl -n $namespace get po -o \
    jsonpath='{range .items[*]}{.metadata.name}{" "}{range .spec.volumes[*]}{.name}{" "}{.persistentVolumeClaim.claimName}{" \n"}{end}{end}' | \
    grep " $pvc_name "
)
raw=($pvc_used_in)
pod_name=${raw[0]}
mnt_name=${raw[1]}

Находим точку g монтирования:

pod_mount_name=$(
    kubectl -n $namespace get po/$pod_name -o \
    jsonpath='{range .spec.containers[*]}{range .volumeMounts[*]}{.name}{" "}{.mountPath}{"\n"}{end}{end}' | \
    awk "/$mnt_name /"'{print $2}'
)

Проверяем использование диска (PVC):

pvc_usage=$(
    kubectl -n $namespace exec po/$pod_name -- df -h $pod_mount_name
)

Выводим результат:

echo "PVC capacity: $pvc_capacity"
echo "PVC used in:"; echo "$pvc_used_in"
echo "PVC usage:"  ; echo "$pvc_usage"
PVC capacity: 750Gi
PVC used in:
kafka-dev-broker-1 data data-kafka-dev-broker-1 
PVC usage:
Filesystem      Size  Used Avail Use% Mounted on
/dev/rbd4       738G   44G  695G   6% /bitnami/kafka

Бонусом добавил возможность прибивать PVCишки kui'ем, добавил команды Delete и Terminate.

Творите, выдумывайте, пробуйте!)

Роли в FinOps

Как бы странно это ни звучало, но главное, на чем держится FinOps, — это общий язык, на котором говорят и финансисты, и технари. При этом у каждого из них есть своя роль:

➖  инженеры и DevOps, которые запускают ресурсы и должны видеть их стоимость

➖  продакты и бизнес-менеджеры, которые отвечают за ценность и окупаемость

➖  финансисты и закупки, которые смотрят на бюджеты и договоры

➖  руководители и C-level, которые принимают стратегические решения

В каждой компании распределение может отличаться. Но идея одна: никто не работает в вакууме. Инженеры понимают, во сколько обходятся их сервисы, финансисты знают, за что платят, а топы видят, какую отдачу приносит облако.

Такой подход убирает вечный спор, кто сколько тратит, и превращает расходы в совместную ответственность.

Близка тема, где финансы и инженеры наконец говорят на одном языке? Заглядываем в «Практики FinOps», там выходят кейсы, доклады, лайфхаки и немного самоиронии про жизнь в облаке.

Просто напоминаю про багбаунти от Selectel с призами до 30 000 рублей

В центре внимания — сам образ, его конфигурация, скрипты для автоматизации, настройки операционной системы и Keycloak. Всё остальное, включая DDoS-атаки, фишинг и внешние угрозы, находится вне рамок мероприятия.

Количество участников ограничено: 30 человек, из которых будут выбраны 3 победителя. Регистрация уже открыта, стартуем в октябре — присоединяйтесь и покажите, на что вы способны! 

Призы:

1 место: 30 000 бонусных рублей

2 место: 20 000 бонусных рублей

3 место: 10 000 бонусных рублей

Как устроено под капотом

Мы сделали образ Keycloak в облаке Selectel. Он содержит docker-compose c Keycloak, Postgres, Nginx и скриптами бэкапов. Настраивается через cloud-init: все подставляется из user-data. Поддержка cron-задач, логика запуска, безопасность по умолчанию. Образ рассчитан на стабильную работу из коробки.

Внутри образа Nginx работает как обратный прокси, Certbot выпускает сертификаты. Есть cron-задачи для обновлений и создания дампов. Закрытые URL’ы, доступ по white-list — ради безопасности админского контура. Настройка происходит автоматически при запуске образа.

Эгегей! Радость, kui снова подрос! Добавлена команда 'SSL update' для обновления сертификатов и ключей в секретах типа 'kubernetes.io/tls'. Как это работает?

• Кладете в какую-нибудь папку новый сертификай, файл должен называться tls.crt и ключ с именем tls.key

• Запускаете kui в этой папке, находите секрет с сертификатом который необходимо обновить

• Обновляете через 'SSL update'

Под капотом, обновление выполняется вот такой командой:

printf -v ssl_patch_data '{"data": {"tls.crt": "%s", "tls.key": "%s"}}' "$(base64 -w0 tls.crt)" "$(base64 -w0 tls.key)"
kubectl patch secret/<secret_name> -n <namespace> --patch="$ssl_patch_data"

Творите, выдумывайте, пробуйте!)

Друзья, у меня крутая новость! 🔥

📍 Проведу живую встреча по теме:
Ansible Security CTF — Защищай и Атакуй!

📅 Когда: 14 октября
🕖 Время: 19:00 
📍 Где: «Failover Bar» (Санкт‑Петербург, 2-я Советская, 18)

🎯 Что будет:
⚔️ Практический мастер‑класс по автоматизации безопасности
🐳 Развертываем уязвимую инфраструктуру в Docker
🛡 Пишем Ansible playbook для защиты
🏆 CTF‑соревнование — ищем флаги и закрываем уязвимости!

⏰ Формат: 2 часа интенсивной практики

💻 Что взять с собой: ноутбук и желание ломать/защищать системы

🚀 Программа:
✅ 5 реальных сервисов с уязвимостями
✅ Практика с nmap, hydra, curl
✅ Написание продвинутых Ansible playbooks
✅ Система очков и подсказок
✅ Живое общение и нетворкинг

👨‍💻 Ведущий я: Андрей Чуян
DevOps-инженер, автор канала «IT‑волна»

Места ограничены! Запись на мероприятие

Добавляйте нашего бота чтобы ничего не пропустить! 🤖

SSP SOFT продолжает найм — ищем крутых ребят в команду 🔥

Кто мы такие и что делаем? SSP SOFT — это компания среднего бизнеса, наши направления: разработка заказного софта, IT-аутсорсинг выделенных команд и еще мы немного аутстафферы. Кандидатов ждут реальные, интересные проекты, прокачка скиллов и приятные бенефиты. Стараемся делом показывать, что для нас сотрудник — главная ценность. Минимум бюрократии, только рабочие процессы.

✅ Что мы предлагаем нашим будущим коллегам:
— Интересные задачи,
— Персонального наставника — мы позаботимся о твоем онбординге,
— Центр компетенций — прокачивай свои скиллы без ограничений,
— Свободу передвижения — работай откуда душа желает в РФ,(ино-локации обсуждаются),
— Офисы для общительных — добро пожаловать в наши уютные пространства в Москве (офис в ЦАО) и в Томске.
— Разумный Work-Life Balance — чтобы хватало сил и на работу, и на жизнь.

🎁 А еще:
— Бонусная программа с «плюшками в рынке»,
— Обучение за наш счет — вкладываем в будущее,
— ДМС с заботой о твоей улыбке (стоматология включена).

📢 Мы ищем прямо сейчас:
1️⃣Специалиста технической поддержки 1С (https://vk.cc/cPXAGI)
2️⃣Разработчика 1С (https://vk.cc/cPXAIE)
3️⃣DevOps-инженера (https://vk.cc/cPXAJW)

👉Если ты открыт для классной работы, топовых бонусов и профессионального роста — присылай резюме в ЛС нашему HR Lead Алине (https://t.me/AONikitina).
Не забудь в сопроводительном или в начале переписки указать секретную фразу «Нашел(ла) вас на Хабре».

Подробности о других наших вакансиях читай на ХХ.ру (https://hh.ru/employer/5648224?hhtmFrom=vacancy)
Приглашаем стать частью SSP SOFT!

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

Счета растут, бюджеты сложно прогнозировать, а прозрачности мало. Особенно это ощущают компании, где несколько команд используют разные облачные сервисы и никто не видит полной картины.

Чтобы помочь компаниям системнее подойти к FinOps, мы собрали FinOps Community Bot. Это Telegram-бот, который объединяет несколько инструментов:

• Тест по FinOps. 9 вопросов за 5–7 минут. Бот рассчитает уровень зрелости вашей компании в управлении облачными затратами и подскажет следующие шаги.

• База знаний. Подборка статей, инструкций и практических материалов по FinOps.

• Календарь событий. Митапы, вебинары и конференции для специалистов и руководителей.

• Закрытый чат. Возможность обсудить опыт с коллегами и задать вопросы сообществу.

Бот полезен для любых ролей: CEO увидит картину в целом, CFO получит идеи по оптимизации расходов, DevOps-инженеры и CTO — практические шаги для улучшения процессов.

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

👉 Попробовать

Бессерверные вычисления: почему ваш код может стать заложником провайдера

Бессерверная архитектура обещает не думать об инфраструктуре, но скрывает риски vendor lock-in, которые проявятся слишком поздно. Пока вы наслаждаетесь отсутствием серверов, ваша бизнес-логика медленно превращается в заложника облачного провайдера.

Проблема:

• Cold start в критичных приложениях достигает 10-15 секунд

• Стоимость непредсказуема при скачках нагрузки

• Локальная разработка и отладка превращаются в квест

Реальные кейсы:

python

# Проблема: разрыв между продакшеном и локальной средой
def lambda_handler(event, context):
    # На локальной машине работает
    # В AWS Lambda падает с таймаутом
    return expensive_operation()  # 25+ секунд

Что мониторим в бессерверной среде:

1. Performance

   • Холодные/горячие старты

   • Потребление памяти

   • Execution duration

2. Безопасность

   • Права IAM-ролей

   • Доступ к секретам

   • Цепочки вызовов функций

3. Экономика

   • Стоимость вызова

   • Количество параллельных исполнений

   • Использование сторонних сервисов

Когда бессервер оправдан:

• Обработка событий с неравномерной нагрузкой

• Фоновые задачи (генерация отчетов, ночные джобы)

• API с низким RPS

Альтернативы:

• Kubernetes + Knative — гибридный подход

• Cloudflare Workers — edge-вычисления

• Self-hosted FaaS — полный контроль

Вывод:
Бессерверные технологии — мощный инструмент, но требуют тщательного проектирования и постоянного мониторинга затрат. Прежде чем погружаться в serverless, оцените, готовы ли вы к зависимости от вендора и непредсказуемым расходам.

Строите микросервисную архитектуру? Уверены, что с аутентификацией и авторизацией всё идеально?

2 октября разберем на бесплатном вебинаре «Аутентификация в микросервисах за 1 час: Keycloak и JWT без головной боли» отраслевой стандарт для безопасности — Keycloak.

План вебинара (только полезное):

✔️ Keycloak как IAM-сервер: быстрый старт и настройка.

✔️ Интеграция с ASP.NET приложением: пишем код, который работает.

✔️ Четкое разграничение прав (Authorization): чтобы пользователи видели только своё.

✔️ OAuth 2.0 / OIDC & JWT: не просто аббревиатуры, а инструменты, которые вы поймёте и примените.

Итог: вы уйдете с чёткими инструкциями и рабочим примером для ваших проектов.

📅 Когда: 2 октября, 17:00-18:00 (МСК)

👨‍🎓 Спикер: Андреев Андрей — эксперт в области разработки и архитектуры ПО.

👉Забронировать место 👈

Этот час сэкономит вам недели на проектировании и отладке безопасности.

Контейнеры не панацея: скрытые затраты на содержание Kubernetes, о которых молчат вендоры

Kubernetes стал де-факто стандартом оркестрации, но за кадром остаются реальные эксплуатационные расходы. Когда стоимость обслуживания кластера превышает стоимость самих сервисов — пора пересматривать архитектурные решения.

Что не учитывают при внедрении:

• Эффективность нод: В среднем 35-40% ресурсов простаивают "на всякий случай"

• Стоимость сетей: Service mesh + CNI добавляют 15-20% к потреблению CPU

• Трудозатраты: 1 инженер на 3-5 кластеров — утопия для средних компаний

Реальные метрики из практики:

bash

# Анализ утилизации за 3 месяца
kubectl top nodes | awk '{sum += $3} END {print "Средняя загрузка:", sum/NR "%"}'
# Результат: 41% по CPU, 28% по памяти

Где теряем деньги:

1. Overprovisioning
   "На всякий случай" развертываем на 200% больше ресурсов

2. Сложность мониторинга
   Требуется отдельный стек: Prometheus + Grafana + Alertmanager

3. Безопасность
   Pod Security Policies, network policies — +20% к времени развертывания

Когда Kubernetes оправдан:

• 50+ микросервисов

• Непредсказуемая нагрузка

• Команда из 3+ DevOps инженеров

Альтернативы для средних проектов:

• Nomad — проще оркестратор без привязки к контейнерам

• Docker Swarm — для простых сценариев

• Managed k8s — если нет своей экспертизы

Вывод:
Kubernetes — мощный инструмент, но не серебряная пуля. Прежде чем прыгать в эту экосистему, посчитайте TCO и убедитесь, что сложность управления не съест всю экономию от контейнеризации.

#Kubernetes #DevOps #контейнеризация #TCO #микросервисы

А как у вас с реальной утилизацией ресурсов в k8s? Делитесь наблюдениями в комментариях.

Записки параноика: почему Zero Trust — это не мода, а новая реальность для ИТ-инфраструктуры

Современные угрозы больше не останавливаются на периметре. Атаки стали целевыми, изощренными и часто исходят изнутри. Традиционный подход «замок и ров» безнадежно устарел.

Почему Zero Trust — это не просто buzzword:

• 68% компаний сталкивались с инцидентами внутренних угроз

• Среднее время обнаружения нарушителя в сети — 207 дней

• Традиционные VPN стали главным вектором атак в 2024

Как мы внедряли Zero Trust без переписывания всей инфраструктуры:

Сегментация на микроуровне:

yaml

# Instead of: Allow 10.0.0.0/8
# We use: 
- name: db-access
  source: app-server-01
  destination: postgres-01
  port: 5432
  auth: mTLS + service-account

Service Mesh вместо VPN:

• Istio для взаимной аутентификации сервисов

• Автоматическое шифрование всего трафика

• Детальный контроль доступа на уровне L7
  
  Непрерывная верификация:

bash

# Проверка целостности хостов каждые 30 сек
sudo attestation-agent verify --policy strict

Технические вызовы, с которыми столкнулись:

• Производительность: Overhead Istio ~3ms на hop

• Сложность отладки: Трассировка запросов через 5+ сервисов

• Миграция: Постепенный перенос legacy-систем

Метрики после 6 месяцев работы:

• Время сдерживания атаки сократилось с часов до минут

• Количество инцидентов снизилось на 73%

• Audit trail для compliance стал детализированным

Ключевые инсайты:

1. Начинайте с идентификации — без точной инвентаризации сервисов ничего не выйдет

2. Поэтапное внедрение — от критичных workload к периферии

3. Автоматизация политик — ручное управление не масштабируется

Zero Trust — это не продукт, а архитектурный принцип. И да, он требует изменений в менталитете команды больше, чем в технологиях.

Post-Quantum Cryptography: тихая революция в инфраструктуре, которую нельзя игнорировать

Пока большинство обсуждает ИИ, в мире криптографии происходит настоящая революция. NIST утвердил первые стандарты постквантовой криптографии, и это потребует фундаментальных изменений в ИТ-инфраструктуре уже в ближайшие 2–3 года.

Проблема:

Современные алгоритмы (RSA, ECC) могут быть взломаны квантовыми компьютерами в обозримом будущем. Миграция на PQC — не вопрос «если», а вопрос «когда».

Что меняется:

• Размер ключей увеличивается в 5-10 раз

• Процессоры испытывают нагрузку на 30-50% выше

• TLS-хендшейки становятся значительно объемнее

Наши тесты с OpenSSH 9.8:

bash

# Стандартный ключ Ed25519: 68 байт
# PQC-ключ Dilithium3: 1842 байта
# Рост трафика при подключении: ~2700%

Практические рекомендации:

1. Аудит инфраструктуры:

python

# Скрипт для поиска уязвимых сервисов
import ssl
for protocol in ['TLSv1.2', 'TLSv1.3']:
    ctx = ssl.create_default_context()
    ctx.set_ciphers(protocol)

2. План миграции:

• 2025: Тестирование гибридных схем (PQC + традиционные алгоритмы)

• 2026: Перевод внутренних сервисов

• 2027: Полный переход для внешних endpoint

3. Аппаратные требования:

• CPU с поддержкой AVX2/AVX-512

• Увеличение буферов сетевых карт

• +30% к оперативной памяти для сертификатов

Метрики производительности после перехода:

• 📉 Throughput VPN: снижение на 15%

• 📈 Потребление CPU: рост на 40%

• ⏱️ Время TLS-хендшейка: +80 мс

Вывод:

Откладывание перехода на PQC аналогично игнорированию проблемы Y2K в 90-х. Уже сегодня нужно начинать тестирование и планирование, чтобы избежать хаотичной миграции под давлением регуляторов.

Уже проводили тесты с постквантовыми алгоритмами? Делитесь результатами в комментариях — соберем статистику по разным конфигурациям.