DevOps *

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

Решение — Bitwarden Secrets Manager + CLI. Централизованно храним ключи, раздаём доступ выборочно и автоматически подтягиваем их при деплое. В статье покажу, как настроить всё с Docker, NestJS, Vite и Coolify, чтобы деплой стал безопасным и удобным.

Всем привет!

В этой статье мы разберём, как развернуть кластер ClickHouse с использованием ZooKeeper для обеспечения репликации и отказоустойчивости. Я покажу пошаговую настройку сервисов, объясню, зачем ZooKeeper нужен ClickHouse, какие порты и конфигурации используются, а также поделюсь практическими советами по работе в Kubernetes.

Привет, Хабр! Статья не входила в планы, пишу с чувством лёгкой сюрреалистичности. В воскресенье утром наш основной API-гейтвей пережил маленькую апокалиптическую битву с памятью и выиграл без моего участия. Делюсь с Вами, как небольшой скрипт, на который я не полагал абсолютно никаких надежд, отработал аварию.

Автомасштабирование узлов кластера Kubernetes и горизонтальное масштабирование подов позволяют быстро расширить ресурсы при пиковых нагрузках. Но сложные приложения могут не нагружать поды или узлы максимально, но требовать дополнительных ресурсов, например, для параллельной обработки нескольких объектов в очереди. Триггером масштабирования кластера может быть не утилизация, а события от внешних систем — например, очереди сообщений Kafka, системы мониторинга Prometheus или от платформы CI/CD.

Всем привет! Меня зовут Илья Смирнов, я архитектор решений в Cloud.ru. Расскажу, как лучше справляться с пиковыми нагрузками, если вы развернули свое приложение в кластере Kubernetes. Вместе запустим такое демо-приложение и посмотрим, как с ним работают классические подходы автомасштабирования — в этой части, а затем попробуем масштабировать кластер по событиям с помощью KEDA (Kubernetes-based Event Driven Autoscaler) — в следующей. Не пропустите!

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

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

Автоматизированное тестирование – важная часть разработки, но недостаточно просто запускать тесты. Важно предоставлять отчёты в удобном и наглядном формате, чтобы повышать прозрачность процессов и улучшать командную коммуникацию.

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

Привет! Я SDET-специалист SimbirSoft Руслан, и в этой статье мы разберем как настроить SMTP-сервер для отправки почты в Jenkins, как настроить GitLab Runner и как автоматизировать отправку отчетов после выполнения тестов.

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

В этой статье мы подробно рассмотрим типичные сценарии мониторинга устройств Интернета вещей. В частности, мы поговорим о различиях между мониторингом и наблюдением, о том, какие именно аспекты IoT заслуживают мониторинга и соответствующих стратегиях.

Когда я только начинал работать, 100% аптайма казались мне священным граалем. Казалось: если сервис никогда не падает — пользователи счастливы, бизнес доволен, инженеры спят спокойно. Но реальность быстро показала: каждая дополнительная «девятка» стоит всё дороже, а выгоды становятся всё менее заметными. В статье делюсь опытом: почему гонка за идеальной надёжностью — тупик, как помогает концепция Error Budget и почему лучше найти баланс между стабильностью и развитием.

Делимся опытом трансформации нашей инфраструктуры: от децентрализованных экземпляров Foreman с публичными IP до защищённой, изолированной архитектуры с централизованным управлением через GitLab, повышенной безопасностью и легкой масштабируемостью.

Технология eBPF не нова. Её используют повсеместно, ведь она упрощает написание кода для ядра ОС. классно и удобно, а главное безопасно! Но, как оказывается на практике, не все так гладко… Это не только удобное средство для написания кода, но и новые потенциальные векторы для атак. Поэтому давайте подробно разберём, как она работает, и как можно избежать потенциальных проблем. Для меня как безопасника интереснее всего использование eBPF сервисами и инструментами в продакшене. Именно там открываются возможные пути обхода для злоумышленников. 

Меня зовут Лев Хакимов, я DevOps и Kubernetes Security Lead в MWS Cloud Platform, а ещё преподаю в ИТМО. Занимаюсь обеспечением и построением процессов безопасности платформ Kubernetes в облаке MWS, организую CTF-соревнования по всей стране для школьников, студентов и действующих специалистов.

Даже самые надёжные и отказоустойчивые системы иногда могут преподносить неприятные сюрпризы. Что уж говорить про обычные VPS-сервера и запущенные на них проекты. Рано или поздно может случиться ситуация, когда сайт или какой-то сервис «упал». Причины бывают разные: от внешних (например, сбой у провайдера или проблемы на стороне хостинга) до внутренних — ошибка в коде, нехватка ресурсов или некорректные настройки.

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

Один из удобных инструментов для этого — Uptime Kuma. Это относительно молодой (по сравнению с «тяжеловесами» вроде Zabbix) проект, который активно развивается, прост в установке и отлично подходит для новичков.

В этой статье мы разберёмся:

Введение: Почему RAG?

Представьте: приходит письмо из вышестоящих или надзорных органов с требованием предоставить информацию или отчёт. Тут начинается суета и судорожный поиск нужных документов. А что, если всю внутреннюю документацию — приказы, инструкции, отчёты — можно было бы "спросить"? Задать вопрос и получить точный ответ, подкреплённый информацией из этих документов.

Именно для этого и существуют системы RAG (Retrieval-Augmented Generation). Это не просто LLM, которая отвечает, что знает, а система, которая ищет информацию в вашей базе данных, а затем использует её для формирования точного и релевантного ответа.

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

Сегодня официально выпустили новую версию Kubernetes — 1.34. Собрали обзор со всеми изменениями. Среди главных нововведений — отслеживание здоровья устройств при DRA, тонкая настройка рестарта контейнеров в подах, асинхронная обработка API-вызовов, нативная доставка сертификатов X.509 в поды и новая разновидность YAML для описания конфигураций.

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

Как всё это было организовано - расскажу в этой статье.

Всем привет! Меня зовут Александр Стерлигов, я руковожу проектным офисом в MWS Cloud Platform. Мы начали строить новое облако в 2023 году, и всего за год наша команда выросла со 150 до 520 человек.

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

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

Когда я только начинал дежурить, телефон ночью был моим главным врагом: PagerDuty вырывал из сна десятки раз, а инциденты превращались в хаос. Со временем я понял, что on-call можно превратить в предсказуемый процесс — с правильными алертами, runbook-ами и командной культурой. В этой статье расскажу, как я перестал бояться алертов и научился относиться к дежурствам спокойно. Будет личный опыт, фейлы и практические советы

Привет, Хабр! Думаю, многие сталкивались с необходимостью генерации тысячи пользователей. Вручную - не вариант, слишком долго. В данной статье разберу библиотеку Faker. Это генератор реалистичных тестовых данных, который превращает заполнение базы и создание демо-контента из рутины в дело пары строк кода. В статье продемонстрирую, как генерировать тысячи правдоподобных записей на русском, заполнять БД и создавать собственные типы данных для ваших проектов.

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

Ситуация изменилась, когда я познакомился с практиками SRE: SLO, SLI и error budget. Они помогли превратить хаос в систему и объяснить бизнесу надёжность на понятном языке. Теперь вместо бессмысленного «сервис упал!» мы обсуждаем конкретные цифры: сколько бюджета ошибок потрачено и когда можно катить релиз.

В этой статье расскажу, как мы внедрили наблюдаемость на основе golden signals, научились писать постмортемы без поиска виноватых и встроили задачи по надёжности прямо в бэклог. Всё — из реальной практики инженера, который за год прошёл путь от «тушения пожаров» к спокойной работе с прогнозируемой стабильностью.

Современные платформы для машинного обучения (ML)  — это комплексные системы. В их состав входит множество разнообразных инструментов — от средств обработки данных до систем развертывания моделей. А по мере увеличения масштаба и сложности таких платформ на первый план выходит вопрос эффективного управления доступом и безопасностью. Решить его можно, внедрив технологию Single Sign-On (SSO), которая позволяет пользователям получать доступ сразу ко всем компонентам платформы. 

Меня зовут Дмитрий Матушкин, я инженер платформы Nova Container Platfrom в Orion soft. В этой статье мы подробно рассмотрим процесс внедрения и настройки StarVault (аналог HashiCorp Vault, но все действия похожи на те, что нужно произвести в Vault) с использованием технологии OpenID Connect (OIDC) в качестве единой точки входа для популярных компонентов ML-платформы: MLflow, Airflow и JupyterHub.   

Все данные сервисы будут развернуты в кластере Kubernetes. Для удобства развертывания и настройки ванильного кластера я буду использовать решение Nova Container Platform, которое позволяет получить готовый кластер за 10 минут. Также будем считать, что в StarVault уже создан OIDC provider, например, с названием "some_provider".

В статье рассказываем, как всего за 5 дней собрать современный омниканальный контакт‑центр для фитнес‑клуба на базе open‑source‑платформы Chatwoot и подключить к нему WhatsApp, Telegram и VK с помощью самописных шлюзов на Python (Wasender, Telethon, VK API). Вы узнаете, почему мы отказались от «коробочных» SaaS‑решений, автоматизировали до 84% рутинных сценариев (поздравления, записи, напоминания) и подготовили инфраструктуру под внедрение AI‑ассистентов и аналитики SLA. Приводим архитектурные схемы, технические детали и бизнес‑выгоды — от сокращения ручной работы до сохранения всех коммуникаций с клиентами в едином окне.