DevOps *

Почему дешёвый VPS-сервер может обойтись дорого в продакшене? Тариф в 3–5 долларов в месяц за VPS кажется приятной экономией на старте. Но если тариф выбран только по цене, счёт за простой, срочную миграцию и потерянных клиентов может прийти позже и оказаться выше, чем сэкономленная разница в ценнике.

Что скрывается за низким ценником? За низкой ценой могут стоять оверселлинг, общий диск, ограниченная поддержка и слабые гарантии по SLA. У части провайдеров низкая цена достигается за счёт плотного размещения клиентов на одной ноде: продаётся больше vCPU и RAM, чем физически доступно, в расчёте на то, что нагрузки не совпадут. В результате могут появляться CPU steal time, просадки I/O от соседей по железу и нестабильная производительность общего хранилища. SLA на бюджетном VPS-сервере может отсутствовать или ограничиваться формальным обещанием без понятной компенсации.

Реальные риски в продакшене. Под нагрузкой проблемы проявляются внезапно: API начинает отвечать с задержками, база данных упирается в I/O, сервис падает в самый неподходящий момент. Потеря данных из-за отсутствия бэкапов или срочная миграция перед дедлайном – реальные риски для проектов, которые выбирают инфраструктуру только по цене.

Как считать полную стоимость VPS? Реальная цена – это не только тариф, а TCO: тариф + стоимость инцидентов. Один час простоя интернет-магазина в пиковый сезон легко перекрывает годовую разницу между дешёвым и надёжным VPS. Добавьте часы на диагностику и миграцию, потери из-за недовольных клиентов – и экономия быстро испаряется.

Чек-лист: признаки надёжного VPS:

•        SLA не ниже 99,9%

•        NVMe-хранилище со стабильной производительностью или понятными IOPS-лимитами

•        Современная аппаратная виртуализация, например KVM, и понятная политика изоляции ресурсов

•        Автоматические бэкапы с проверенным восстановлением

•        Поддержка 24/7 с заявленным временем ответа

•        Гарантированная пропускная способность сети

Прежде чем продлевать текущий тариф, проверьте свой VPS по этому чек-листу. Если несколько пунктов вызывают сомнения – стоит пересмотреть выбор сервера для продакшена до первого серьёзного инцидента.

Что прокачать системному администратору для профессионально роста

31 июля — День системного администратора, поздравляем с профессиональным праздником всех причастных! И это хороший повод ненадолго отложить чужие заявки и подумать о собственном развитии.

Профессия давно вышла за пределы настройки серверов и учетных записей. Современному админу приходится работать с контейнерами, автоматизацией, наблюдаемостью и безопасностью. Здесь собрали несколько бесплатных уроков для тех, кто хочет увереннее решать текущие задачи или двигаться в сторону DevOps, SRE и DevSecOps.

↓ Заглянуть под капот Linux
^{Когда проблема находится ниже уровня сервисов и конфигов, полезно понимать, что происходит внутри системы.}

«Что такое модуль ядра. Как его написать, собрать, запустить»
3 августа в 20:00
За один вечер можно пройти путь от исходного кода до загрузки собственного модуля и перестать воспринимать ядро Linux как полностью закрытый черный ящик. Записаться

↓ Быстрее находить причины сбоев
^{Обычный мониторинг сообщает, что сервису плохо. Наблюдаемость помогает понять, где именно все пошло не так.}

«OpenTelemetry — наблюдаемость на блюдечке»
4 августа в 20:00
Метрики, логи и трассировки пригодятся, когда один запрос проходит через несколько сервисов, а источник задержки или ошибки не лежит на поверхности. Записаться

↓ Сделать деплой предсказуемым
^{Если выпуск новой версии зависит от набора ручных команд и памяти конкретного сотрудника, процесс пора автоматизировать.}

«Kubernetes + CI/CD + GitOps — делаем стабильный деплой без выхода из кластера»
10 августа в 20:00
Полезно тем, кто хочет хранить состояние инфраструктуры в Git, контролировать изменения и откатываться без ночной археологии в терминале. Записаться

↓ Перестать искать логи по серверам вручную
^{Чем больше машин и контейнеров, тем меньше хочется подключаться к каждому из них ради одной строки.}

«Системы логирования: ELK, EFK или Graylog?»
17 августа в 20:00
Возможность сопоставить популярные стеки и понять, какой из них лучше подходит под конкретную инфраструктуру, объем данных и доступные ресурсы. Записаться

↓ Подготовиться к сбою до сбоя
^{Единственная точка отказа обычно не беспокоит ровно до того момента, пока не откажет.}

«Готовим инфраструктуру к сбоям: отказоустойчивый кластер на базе VRRP и HAProxy»
18 августа в 19:00

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

А для тех, кто предпочитает закрывать пробелы в своем темпе, мы собрали целый дайджест, посвященный инфраструктуре.

Почему аптайм зависит не только от VPS-провайдера?

Провайдер может обещать 99,9% аптайма VPS, но аптайм продукта и аптайм инфраструктурного узла остаются разными показателями. Когда сервис падает, причина часто находится за пределами зоны ответственности провайдера: в приложении, деплое, базе данных, DNS или внешних API.

Что именно гарантирует VPS-провайдер? SLA VPS-провайдера покрывает доступность физического узла, сетевого канала и питания. Если оборудование работает и сеть доступна, инфраструктурная часть SLA может считаться выполненной. Код, конфигурации, база данных и внешние зависимости остаются в вашей зоне ответственности.

Где на самом деле ломается аптайм? На практике многие простои возникают не из-за сбоев инфраструктуры, а из-за ошибок в коде и операционных процессах. Неудачный деплой, утечка памяти, переполненный диск, истёкший SSL-сертификат, недоступный DNS или упавший сторонний API гасят сервис независимо от стабильности хостинга.

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

Как повысить реальный аптайм сервиса? Стабильность сервиса на VPS складывается из нескольких пунктов. Автоматические бэкапы и снапшоты упрощают восстановление после сбоя. Проверки состояния и алерты сокращают время обнаружения инцидента. CI/CD-пайплайн с проверками и понятным откатом снижает риск ошибок при деплое.

Чек-лист надёжности:

• Бэкапы и снапшоты настроены и проверены

• DNS TTL снижен перед плановыми миграциями

• SSL-сертификаты обновляются автоматически

• Есть процедура отката для каждого релиза

• Мониторинг и алерты подключены до деплоя

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

Как Купер перенес 100% инфраструктуры в облако, снизил количество инцидентов и сократил время на их устранение

🏭 Что за компания
Купер — онлайн-сервис доставки продуктов, товаров и готовой еды из магазинов и ресторанов. Сервис работает в 360 городах России, ежедневно обрабатывая десятки тысяч запросов в секунду. Ранее Купер уже перенес 40 ТБ аналитических данных в облако и остался доволен результатом, поэтому было принято решение продолжить процесс миграции. 

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

☁️ Что сделали
Команды провайдера и заказчика синхронизировали требования к инфраструктуре и сетевой архитектуре для плавного переезда. Провайдер помог сформировать команду миграции из 12 специалистов, чей онбординг занял две недели. За 10 месяцев Купер и Cloud.ru перенесли 100% ИТ-инфраструктуры в облако, завершив миграцию в конце апреля 2026 года.

Архитектуру разделили на три логически изолированных слоя — внешний периметр (DMZ) с балансировщиком и веб-серверами, демилитаризованную зону для проверки трафика и закрытый контур бэкенда с базами данных и системами обработки заказов. Дополнительно команда провайдера доработала PaaS-сервисы под задачи Купера, внеся более 30 изменений и взяв на себя их дальнейшее сопровождение — обновления, контроль совместимости и проверку работоспособности.

🦾 Что получили в итоге
Число инцидентов, связанных с облачной инфраструктурой, сократилось на 23%, доступность облачных ресурсов выросла, а средняя длительность инцидентов снизилась на 18%. Затраты на устранение технических сбоев уменьшились в 4 раза, а благодаря FinOps-инструментам Cloud.ru Купер получил прозрачный контроль бюджета и автоматические рекомендации по оптимизации расходов. В итоге онлайн-сервис получил масштабируемую платформу, способную стабильно обрабатывать данные любых объемов и выдерживать пиковые нагрузки без сбоев.

Подробнее читайте на сайте. 

🏕️ Ваши друзья не понимают, зачем идти в лес с IT-шниками.

Саша планирует поехать на DebugCamp в сентябре. Это наш регулярный выезд на природу на 20 человек — проводим 2 раза в год. Саша написал нам честно: «Зову всех, но в кругу нет кто согласился».

Знакомо?

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

На самом деле DebugCamp - это два дня с понятной программой. За 48 часов вы:

- Формулируете личный запрос (карьерный, технический, продуктовый)

- Получаете идеи от 10+ коллег — не small-talk, а разбор рабочих задач: приносите свою — группа помогает найти решение

- Проходите квест-ориентирование «Тропа Выживания» с инструктором

- Участвуете в вечернем разборе карьерных вопросов в кругу коллег у костра

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

Сомневаться - нормально. Вы не один такой.

Если хоть раз думали «а почему бы и нет» - программа здесь

#DebugCamp #DebugSkills #ITмероприятия #поход #нетворкинг

Еще не поздно стать спикером на GoCloud Tech 2026 🎤

Хардкорная конференция для тех, кто создает технологии в эпоху ИИ, GoCloud Tech состоится 15 октября! Мы собираем доклады от коллег из индустрии и готовы предоставить трибуну каждому, кто хочет повлиять на развитие инженерных практик и готов делиться своим реальным опытом. Не важно, в какой компании вы работаете, если вам есть, что рассказать: 

• о технологиях, на которых держатся современные облачные платформы, и лучших практиках работы с ними;

• о том, как строить сложные системы и делать разработку в облаке эффективнее и безопаснее;

• о том, как подготовить данные и инфраструктуру к работе с ИИ.

Ждем ваши заявки на выступление до 11 августа!

Вместе обсудим, как ИИ меняет инфраструктуру, разработку и работу с данными.

Узнать подробнее о тематиках и таймлайне подготовки, а также подать заявку можно на лендинге. 

Kubernetes к 2035 году: стандарт, невидимая инфраструктура или история?

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

В новом выпуске «В SREду на кухне» вместе с Александром Невским, руководителем юнита k8s в Infrastructure Platform Авито, поговорили о том, куда Kubernetes движется дальше — и что это значит для инженеров, которые с ним работают сегодня.

Что на повестке

Становится ли Kubernetes проще или сложнее с каждым годом — и почему ответ неочевиден. Почему компании приходят к десяткам кластеров и как Fleet Management превращается в отдельную инженерную дисциплину. Заменит ли платформенная инженерия Kubernetes или просто спрячет его поглубже. Как LLM уже меняют работу DevOps и SRE — и кто вообще будет управлять инфраструктурой через десять лет.

Отдельно — прогноз на 2035 год. Без гарантий, но с аргументами.

Если вы работаете с Kubernetes и хотите понять, стоит ли копать глубже или достаточно уметь писать манифесты — этот выпуск про вас.

🔵 VK Видео 
📺 YouTube
📌 RuTube
Ⓜ️ Mave

Как управлять окружениями — venv / pip vs pipenv vs poetry?

Привет, Хабр! Продолжаем нашу рубрику с быстрыми ответами на некоторые часто встречающиеся вопросы. Сегодня разберем такую проблему: проекты постоянно ломаются из-за конфликтов зависимостей. Что выбрать для новых проектов и как сделать так, чтобы код работал одинаково, в том числе в CI?

Обычно начало всех проблем — смешение глобальных и локальных пакетов или отсутствие фиксированных версий библиотек. Главный совет: у каждого проекта должно быть собственное окружение с явно указанными зависимостями и сохраненным lock‑файлом в репозитории.

Если говорить о базе, то это связка venv и pip. Плюс она встроена в сам Python. Вы вручную создаете окружение, устанавливаете нужные пакеты и фиксируете их в requirements.txt. 

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

Сейчас это, пожалуй, наиболее сбалансированное решение: он создает и управляет окружениями, отслеживает версии, собирает wheel‑пакеты и умеет публиковать их в PyPI. Lock‑файл (poetry.lock) обеспечивает воспроизводимость сборок, а сам формат pyproject.toml — это стандарт. В итоге вы получаете чистое окружение, детерминированные зависимости и понятное поведение CI.

Вот пример рабочего цикла:

python -m venv .venv
source .venv/bin/activate
pip install -U pip
pip install poetry
poetry install
poetry run pytest

В CI чаще используют схему с экспортом зависимостей:

poetry export -f requirements.txt --without-hashes -o reqs.txt
pip install -r reqs.txt
pytest

Отдельно стоит упомянуть uv — относительно новый инструмент, созданный командой Astral (авторы Ruff). Он написан на Rust и совместим с Python. По сути, это те же функции pip, venv и частично poetry, но быстрее. От Poetry он отличается отсутствием публикации пакетов, но при этом умеет сам устанавливать и менять версии Python через .python-version. 

UV работает с pyproject.toml и имеет собственный uv.lock. Может использоваться вместе с Poetry, но лучше создавать единый uv.lock для строгой воспроизводимости. Для CI это удобно, вы пишите:

pip install uv

Далее есть два варианта:

• uv venv — создает виртуальное окружение. Это аналог python3.13 -m venv .venv, но работает быстрее и с автоустановкой версии Python.

• uv init — помимо .venv, добавляет шаблон проекта с pyproject.toml для зависимостей, Git-репозиторий и базовые файлы. Идеально для нового проекта.

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

Если хотите освоить инструменты Python, то в Академии Selectel у нас есть отдельная подборка статей. Там мы рассказываем, как настраивать инструменты, работать с базами данных, создавать программы с интерфейсом и использовать Python для парсинга.

Дайджест: новости за июнь 2026

Рассказываем, что произошло в июне и объясняем, зачем это может пригодиться.

🧠 AI Factory  —  цифровая среда для работы с генеративным ИИ
AI Agents — EvoClaw в Evolution AI Agents вышел в общий доступ и теперь покрыт SLA: сервис можно закладывать в прод без опасений.
Managed RAG — в сервисе появились OCR для doc/docx с картинками, загрузка данных через API источником Custom и полноценный API для работы с чанками. Документы из объектного хранилища синхронизируются по расписанию, а новый экстрактор разбирает аудио и видео.
ML Inference — появилась возможность при пиковых нагрузках маршрутизировать запросы с Foundation Models, чтобы производительность не падала.
Notebooks — в сервисе добавили совместное редактирование ноутбуков, управление логами и алертами без выхода из интерфейса, а также готовые дашборды мониторинга. Команда может работать над экспериментами параллельно и мгновенно обнаруживать проблемы, если они возникают.

📈 Evolution Data Platform — комплекс управляемых сервисов для работы с данными
Managed Airflow — сервис вышел в общий доступ: оркестрация данных теперь под SLA.
Managed Trino — топики Kafka теперь читаются прямо SQL-запросом без ETL, а кластер можно развернуть с одной нодой и автомасштабированием. Аналитика стриминга стала проще и дешевле.
Managed Spark —  добавили несколько улучшений в сервис; задачи теперь создаются за секунды, добавлена поддержка Gang Scheduling, чтобы они блокировали друг друга по ресурсам.
Evolution Managed Flink — сервис для работы с потоковыми данными вышел на стадию открытого тестирования, а значит настал момент, когда его функции можно оценить бесплатно и без обязательств.

Важное обновление: платформа перешла на асинхронную модель управления сервисами, кластеры можно самостоятельно приостанавливать и возобновлять, появилось тегирование. Меньше расходов на простаивающие ресурсы и удобнее навигация.

☁️ Новости других сервисов Cloud.ru Evolution
Evolution Artifact Registry — поддержка PyPI-реестров перешла в публичный доступ: Docker-, RPM- и Python-артефакты теперь хранятся в одном месте без отдельной инфраструктуры.
Evolution Managed Kubernetes — обновили ключевые плагины (Istio, KEDA, Trivy Operator и другие), добавлен Spegel для ускорения загрузки образов, а Ingress Nginx получил поддержку PROXY-протокола.
Evolution Managed PostgreSQL — кластеры можно вручную останавливать на срок до 30 дней, платя только за диск, — заметная экономия на неактивных базах.
Evolution Managed Redis — добавлено мультизональное размещение кластеров Master/Replica: одна зона упала — кластер жив.
Evolution Distributed Train — появился Jupyter Server с мультидоступом: несколько пользователей работают в изолированных окружениях под одним сервером. Совместная работа над ML-задачами стала стабильнее и удобнее.

🏢 Cloud.ru Advanced и Облако VMware
В сервисе Advanced Data Warehouse Service поменялся интерфейс создания кластера и появились новые возможности, а в Terraform добавились новые ресурсы. 

Подробнее читайте в полной версии дайджеста.

📽️Вебинары
В июне провели четыре вебинара, записи которых уже доступны на страничке с мероприятиями. Там же можно зарегистрироваться на июльские вебинары от экспертов. 

💼 Свежие кейсы
Рассказали, как Agentic Lab запустили в продакшен ИИ-помощника для юристов, который способен выстраивать хронологию событий любого дела и быстро находить нужные сведения в огромных массивах данных.

Остаемся на связи! ✌️

FinOps по фасттреку: как искать экономию в облаке и не сломать сервис

FinOps часто описывают как полноценную методологию: Inform, Optimize, Operate, процессы, роли, регулярная аналитика, отчётность и культура потребления.

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

В новом выпуске «Практики FinOps» поговорили с Вячеславом Бессоновым, генеральным директором Hilbert Team.

Обсудили, как выглядит FinOps по фасттреку: когда не строят сразу всю методологию, а начинают с quick wins, анализа биллинга, гипотез оптимизации, расчёта ROI и проверки, не сломает ли экономия рабочий сервис.

В выпуске разбираем:

• почему облачного биллинга часто хватает только для первого среза

• какие задачи закрывают FinOps-инструменты, Excel и Python notebooks

• почему гипотеза оптимизации не равна готовому решению

• как считать оптимизацию как отдельный IT-проект

• когда quick win может дать 5–10%, а когда 20–30% требуют серьёзной переработки архитектуры

• почему теги у заказчиков всё ещё скорее исключение, чем правило

• как делить общую инфраструктуру между продуктами и cost centers

• чем отличается экономика on-prem от облака

• почему будущее FinOps движется к подходу workload first

• как AI-токены становятся новой частью unit-экономики

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

Смотреть выпуск

YouTube
Rutube
VK Видео

Слушать выпуск

Telegram Player
Яндекс Музыка
VK Музыка

«Практики FinOps» — cообщество для тех, кто управляет затратами на IT-инфраструктуру и хочет обсуждать FinOps на практических кейсах. Мы в телеграм.

Подборка вебинаров на июль

Вы просили — мы сделали. Повторяем вебинары про работу с данными в облаке: от развертывания платформы до ETL-процессов и полноценной BI-аналитики. Регистрируйтесь, чтобы спросить экспертов о важных деталях и получить ответ.

Как развернуть платформу данных в облаке и подготовить данные для аналитики
Покажем, как быстро развернуть managed-сервисы Evolution Data Platform, подключить источники данных и построить пайплайны для подготовки данных к аналитике. Разберем интеграцию с PostgreSQL, ADB, S3 и настройку автоматического обновления — без долгого погружения в инфраструктуру.
🧑‍💻 Для кого: дата-инженеры, аналитики, архитекторы данных.
📅 Когда: 16 июля 11:00 мск.
📍 Где: Онлайн. Зарегистрируйтесь, чтобы задать вопросы спикерам.

ETL в облаке: от хаоса к управляемым процессам
Покажем, как выстроить надежную ETL-платформу в облаке на базе Evolution Data Platform. Разберем интеграцию разрозненных источников, управление метаданными и оркестрацию — и покажем всё это в live-демо: от извлечения данных до готовой витрины.
🧑‍💻 Для кого: дата-инженеры, DevOps, руководители дата-команд.
📅 Когда: 23 июля 11:00 мск.
📍 Где: Онлайн. Зарегистрируйтесь, чтобы задать вопросы спикерам.

Evolution Managed BI: все возможности BI-сервиса в облаке
Разберем, как получить максимум от Evolution Managed BI: подключить источники данных, настроить интерактивные дашборды, кеширование запросов и автоматические алерты. Покажем продвинутые возможности сервиса — от виртуальных датасетов до управления доступом.
🧑‍💻 Для кого: аналитики, BI-разработчики, руководители дата-отделов.
📅 Когда: 30 июля 11:00 мск.
📍 Где: Онлайн. Зарегистрируйтесь, чтобы задать вопросы спикерам.

Observability ИИ‑агентов: запустили Monium Traces в Yandex AI Studio

Теперь можно анализировать поведение ИИ‑агентов в Yandex AI Studio с помощью трейсов прямо в UI платформы. Трейсы показывают всю цепочку решений агента и контекст каждого шага — системные промпты, вызовы модели и инструментов, промежуточные результаты. Всё, что реально влияет на поведение агента.

Почему это важно
Observability для агентов устроена принципиально иначе, чем для обычных сервисов, где нам доступен дебаг по коду. В случае ИИ главный материал — большие тексты: системные промпты, сообщения пользователя, ответы модели, вызовы тулов. Даже когда инфраструктура может быть полностью «зелёной» — latency в норме, ошибок нет — агент может уверенно отдавать неверный ответ или уходить в бесконечный цикл вызовов. Классический мониторинг здесь не поможет: он не покажет, почему модель выбрала не тот тул или потеряла контекст.

Анализ трейсов:

• помогает быстро понять причину конкретных ответов и поведения агентов

• ускоряет отладку сложных сценариев

• повышает прозрачность работы агента

• позволяет точно локализовать узкие места в цепочке обработки запроса

В видео — как выглядит трейсинг в интерфейсе Yandex AI Studio:

Чтобы начать — откройте AI Studio, перейдите во вкладку «Логирование» и подключите отслеживание трейсов моделей и агентов.

От алерта к его причине за 10 минут — вебинар про ускорение диагностики инцидентов

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

На вебинаре 17 июля покажем, как Deckhouse Observability Platform (DOP) связывает данные по инфраструктуре и приложениям в единую картину и помогает быстрее пройти путь «алерт → локализация → первопричина». В программе:

• Обзор новых возможностей DOP: APM, распределённый веб-мониторинг, система инцидент-менеджмента, SLA/SLO-дашборды и другое.

• Разбор задач эксплуатации и инфраструктурных команд: как быстрее находить причины сбоев и снижать риск пропустить критический инцидент.

• Демо: развёртывание мониторинга с получением первых данных «из коробки» без ручной настройки.

Спикер — Владимир Гурьянов, технический директор DOP, которого вы можете знать по множеству выступлений о наблюдаемости на конференциях. Регистрируйтесь и подключайтесь 17 июля в 12:00.

FinOps для гибридной инфраструктуры: как считать ЦОДы, облака, лимиты и AI-затраты

FinOps часто начинается с облачных счетов. Но в компаниях с гибридной инфраструктурой этого быстро становится мало.

В реальной модели затрат рядом оказываются on-prem, colocation, Kubernetes, сервисные команды, закупки железа, лимиты, ФОТ, лицензии, публичные облака и новые AI-проекты. Если всё это смотреть отдельными кусками, общий IT-бюджет вроде бы есть, а ответа на вопрос «куда именно уходят деньги» всё равно нет.

В новом выпуске «Практики FinOps» поговорили с Дмитрием Деевым (@Dimperus), руководителем отдела ИТ-инфраструктуры и сервисов компании «ВсеИнструменты.ру».

Обсудили, как перейти от общего бюджета к модели аллокации, зачем приводить on-prem к ежемесячной стоимости, почему команды не сразу привыкают к лимитам и как IT-департамент может перестать выглядеть только затратным подразделением.

В выпуске разбираем:

• чем ITFM отличается от классического FinOps;

• как считать гибридную инфраструктуру: ЦОДы, облака, colocation;

• почему on-prem нужно приводить к ежемесячной стоимости;

• как работают лимиты, ресурсные пулы и служба единого окна;

• зачем нужны теги, метаинформация и дашборды для владельцев бюджета;

• почему FinOps не всегда про экономию;

• как учитывать AI-затраты, GPU и новые инфраструктурные сценарии;

• куда может прийти FinOps через автоматизацию, алерты и LLM.

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

Смотреть выпуск
YouTube
Rutube
VK Видео

Слушать выпуск
Telegram Player (Mave)
Яндекс Музыка
VK Музыка

«Практики FinOps» — cообщество для тех, кто управляет затратами на IT-инфраструктуру и хочет обсуждать FinOps на практических кейсах. Мы в телеграм.

🔥 Docker для начинающих: от «что это» до своего контейнера за 4 часа

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

25 июля, 10:00-14:00 МСК | Максим Тачков, Middle Developer (BIM), преподаватель Docker. По отзывам с прошлой лабы: экспертиза 9/10.

5 блоков за 4 часа: (1) Основы Docker → (2) Сборка (Dockerfile) → (3) Управление (Compose, логи, мониторинг) → (4) Данные (volumes, bind mounts) → (5) Сети (Docker Network, DNS)

За 4 часа вы:

- 🐳 Освоите словарь Docker: image, container, volume, network, Dockerfile

- 🔧 Соберёте и запустите свой первый контейнер из Dockerfile

- 🛠 Научитесь управлять контейнерами через Docker Compose

- 📦 Настроите хранение данных через volumes и bind mounts

- 🌐 Настроите сетевое взаимодействие между контейнерами

Для кого: Backend, frontend, fullstack разработчики, QA-инженеры, системные и бизнес-аналитики, архитекторы, технические менеджеры. Нужно: базовый CLI, понимание веб-приложений, VS Code.

🎬 Запись — 20%. Живая практика с ведущим, ответы на вопросы, разбор ошибок — только на лабораторной.

📖 Pre-read: за 3 дня до лабы высылаем шпаргалку по Docker-командам — подготовьтесь заранее и не теряйте темп.

🛠️ Makefile как «пульт управления» — одна команда = одно действие. Фокус на понимании, а не на синтаксисе CLI.

🚀 Дальнейший маршрут: Kubernetes → REST+OpenAPI → Keycloak → Kafka → Prometheus+Grafana.

🔗 Подробнее: https://debugskills.ru/content?article=labs-docker-basics

Как на собственных серверах настроить систему сбора и хранения данных с датчиков и снизить нагрузку на команду эксплуатации

Собрать данные с датчиков — это полбеды. Главная боль — заставить Kafka, PostgreSQL и ClickHouse стабильно работать в приватном облаке без выгорания команды на Day-2-операциях и ручном масштабировании stateful-сервисов.

На вебинаре покажем, как на Deckhouse Kubernetes Platform (DKP) и managed-сервисах упаковать IoT-сценарии и аналитический контур в единую платформу, чтобы снизить стоимость эксплуатации и уйти от DIY-подхода к data-инфраструктуре.

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

В программе:

• Разберём схему event-driven-платформы и разделение операционного и аналитического контуров.

• Покажем live-demo: ingest событий с датчиков, потоковая обработка и вывод в дашборды.

• Проверим, как паттерны из умного дома масштабируются до промышленного IoT на DKP.

• Разберём жизненный цикл data-сервисов (backup, scaling, observability) и то, сколько времени занимает их обслуживание.

Бонусы: промокод на все курсы Deckhouse Академии.

Будет полезно DevOps и SRE-инженерам, инфраструктурным и платформенным командам, enterprise-архитекторам и всем, кто строит IoT- и data-платформы в private cloud или on-prem.

Спикер — Дмитрий Гайворонский, менеджер по развитию направления Deckhouse Data Orchestration.

Регистрируйтесь и подключайтесь 10 июля в 12:00 (МСК). 

Вы пробовали ChatGPT и Cursor. Но система из нескольких AI-агентов — это другой уровень: агенты конфликтуют, теряют контекст, зацикливаются, а отладка напоминает расследование без улик.

🎻 Один AI = музыкант. Несколько AI = оркестр. А кто дирижёр?

19 июля, 10:00-14:00 МСК — лабораторная работа с Андреем Чуяном, создателем ROLES-экосистемы (3 экосистемы, 15+ ролей). За 4 часа: проектирование AI-ролей с YAML-контрактами, 5 хаос-сценариев, MCP-сервер на личной VM, самодиагностика экосистемы.

📐 Проверенная методология FPF + TDD в основе каждого блока.

🔗 Подробное описание: https://debugskills.ru/content?article=labs-ai-orchestration
Готовы спроектировать свою первую AI-экосистему? Приходите 19 июля! 🚀

Релиз ≠ деплой: почему прод падает именно после обновлений

Большинство крупных инцидентов происходят сразу после релиза. Не во время нагрузочного теста, не в случайный вторник — а именно тогда, когда команда только что что-то выкатила и выдохнула. Почему так, если всё прошло тестирование?

В новом выпуске «В SREду на кухне» вместе с Артёмом Гетманским, техруком юнитов в Авито, и Андреем Мухиным, TechLead из MWS, разобрались: что вообще считается релизом, чем он отличается от деплоя — и как не превратить каждое обновление в рулетку.

Что на повестке

Оказывается, релиз может сломать прод даже без единой строчки нового кода — и это не баг, а особенность современных систем. Разбираем, как Feature Flags, Canary, Blue-Green и Rolling-стратегии помогают снизить риск, когда hotfix тоже считается релизом и что с этим делать, и как error budget влияет на то, насколько смело команда вообще решается катить изменения.

Отдельно досталось вопросу, должны ли SRE участвовать в продуктовых релизах — и у участников выпуска на этот счёт нашлись весьма конкретные мнения.

🔵 VK Видео 
📺 YouTube
📌 RuTube
Ⓜ️ Mave

Что почитать по инфраструктуре: Docker, K8s, сети и защита серверов

Собрали свежие статьи из нашего блога — те, что легко затерялись в ленте, но которые стоит дочитать до конца. Если на неделе было не до Хабра, вот короткий дайджест с самым полезным.

Ваш docker-compose.yml сломается: 5 настроек, которые все забывают
Локально всё крутится, на сервере неделю тоже — а потом Postgres съедает всю память, OOM-киллер убивает соседний сервис, а логи забивают диск. Всё лечится парой строк в compose-файле, но про них забывают: на машине разработчика они просто не проявляются. Разбираем пять настроек, без которых compose не доживёт до второй недели на проде.

Прощай, Fail2Ban: усиливаем защиту Netbird и Caddy с CrowdSec
Fail2Ban десять лет был золотым стандартом, но он реактивен: чтобы он сработал, атакующему сначала нужно постучаться в ваш SSH пять раз. А что, если блокировать вредоносные IP ещё до того, как их трафик дойдёт до сервера? История о переходе на CrowdSec с пошаговыми примерами кода — и о том, как «шум» от атак упал на 99%.

Разбираемся с форвардингом IP-пакетов в сетевых уровнях L2 и L3
Чем коммутатор отличается от маршрутизатора, зачем нужен TTL, как устроена CAM-таблица и почему без ARP ваш пакет никогда не доедет до получателя. Спокойный разбор основ, который наводит порядок в голове — для тех, кто хочет наконец перестать путать L2 и L3.

Self-service деплой: как перестать ждать DevOps и ускорить команду
Знакомая картина: разработчик полчаса висит в Slack, ожидая, пока кто-то накатит сборку на стенд. С ростом команды DevOps-инженер становится единственным шлюзом между кодом и продакшеном — и это горлышко съедает до 30% времени. Tech Lead рассказывает, как self-service платформа убирает узкое место, с кейсами Monzo и Spotify.

Kubernetes: архитектура и абстракции — полный гайд
K8s называют стандартом, но понимание его механик встречается редко. Control Plane и Worker Nodes, Pod, Service, Deployment, Namespace — «прожиточный минимум» абстракций, без которых нельзя выходить в прод. Плюс отрезвляющая история о том, как Tinder год переезжал на кластер из 1000 узлов и что у них при этом ломалось.

От capabilities к AppArmor: что реально остановит атакующего в контейнере
Уязвимость в веб-приложении, злоумышленник уже выполняет команды внутри контейнера — что именно его остановит? На одной и той же рабочей нагрузке показано, как последовательно срабатывают три слоя защиты: capabilities, seccomp и AppArmor. Где каждый помогает, где бессилен и почему работать они должны только вместе.

Хотите системно закрыть пробелы по инфраструктуре? Собрали большой дайджест по Linux, Docker, Kubernetes, CI/CD и сетевой безопасности: бесплатные уроки, практические гайды и курсы — всё в одном месте.

Как я в Zabbix мониторю аккаунт в REG.RU: баланс, неоплаченные счета и сроки всех услуг - через API reg.ru

Домен можно сторожить по WHOIS: взял имя, посмотрел дату, повесил триггер «истекает через 30 дней». Но WHOIS видит ровно один домен и ничего вокруг. Он не знает, что на счёте кончились деньги, что висит неоплаченный счёт, из-за которого услугу снимут раньше срока, что в том же аккаунте ещё десяток доменов, SSL и хостинг. Поэтому я опрашиваю не WHOIS, а биллинговый API самого регистратора - он отдаёт весь аккаунт целиком. Собрал из этого шаблон под Zabbix 7.0, MIT. Расскажу, как он устроен и что в нём, на мой взгляд, сделано правильно.

Архитектура Три HTTP-айтема ходят в api.reg.ru - список услуг, неоплаченные счета и баланс - и складывают сырой JSON. Дальше всё считается из него: dependent items тянут баланс, сумму и число счетов через JSONPath, а LLD разворачивает прототипы под каждую услугу (ненужные типы отсекаются макросом-регуляркой). Каждая цепочка начинается с error_handler - битый или пустой ответ API не роняет айтем, а подставляет безопасное значение. На весь аккаунт получается несколько запросов в час, а не отдельная проверка на каждую услугу.

Что считаю правильным дизайном - две цепочки зависимостей Первое - nodata. Когда API регистратора отваливается целиком, каждый триггер «нет данных» (услуги, счета, баланс) хочет сработать сам, и ты получаешь пачку алертов про одну причину. Я завязал nodata услуг и счетов на корневой «No data from balance API». Полный отвал API теперь - один алерт, а не три. Корень я специально оставил без зависимостей, чтобы случайно не завязали и его, - об этом есть комментарий прямо в шаблоне.

Второе - сроки. На каждую услугу не один триггер, а каскад: ИСТЕКЛА (Disaster) → ≤7 дней (High) → ≤14 (Warning) → ≤30 (Info). Каждый уровень зависит от более тяжёлого. Поэтому услуга, которой осталось три дня, даёт один алерт High - а не три штуки (Info, Warning, High) одновременно. По мере приближения срока ты видишь ровно один триггер нужной серьёзности.

Для работы API, необходимо прописать разершенные IP в кабинете https://www.reg.ru/user/account/settings/api/, в настройках API задать адьтернативный пароль, и сохранить в макрос хоста {$RR_PASSWORD} как Secret. Логин - {$RR_USERNAME}. Для рег.облако взять API в https://cloud.reg.ru/panel/settings и сохранить в {$RRC_API_KEY}

Итог Баланс, неоплаченные счета и сроки всех услуг - под алертами в одном дашборде, без отдельного демона-прослойки. В репозитории два шаблона: разобранный выше под api.reg.ru (домены, хостинг, SSL) и отдельный под облачный api.cloudvps.reg.ru - там к балансу и срокам добавлен мониторинг самих VPS: реглеты, снапшоты, сети. Шаблоны, README и changelog - GitHub, PR и issues welcome.

А чем вы следите за биллингом у провайдеров и регистраторов - дёргаете API, или живёте на письмах «ваша услуга истекает»?