DevOps *

Полгода назад я работал над внедрением RAG-системы в крупной финансовой компании. Задача была типичная: построить корпоративного чат-бота, который мог бы отвечать на вопросы сотрудников по внутренним документам. Казалось бы, что может пойти не так? Берем готовую LLM, подключаем к базе знаний, добавляем немного магии с векторным поиском — и готово.

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

Если вы работаете с базами данных, то вам определенно стоит иметь понимание о производительности кластера СУБД. Для этого можно использовать базовые метрики. А можно — метрики от DBaaS в сочетании с Grafana. Они позволяют строить кастомные графики, которые могут быть полезны в той или иной ситуации.

Привет! Меня зовут Рамиль Адильбеков, я DevOps-инженер в Selectel. В этой статье покажу, как можно настроить базовый стек Prometheus/Grafana, подключить метрики от кластера облачных баз данных и загрузить дашборд.

Наша команда добавила к себе в список доступных для установки новую OS — Talos Linux. В этой статье мы постараемся рассказать, что такое Talos Linux, и в чем его удобство перед остальными OS для кластера Kubernetes. Дополнительно мы развернем тестовый кластер, на который задеплоим наше первое приложение.

Привет, Хабр! В мире автоматизации часто возникает вопрос: писать скрипт на Bash или на Python? Оба инструмента подходят отлично, но принципиально разные. Bash - больше про "скоропись", для системных задач, где важна скорость и краткость. Python же - универсальный язык, который намного лучше справляется со сложной логикой и структурами данных. Но когда лучше выбрать один, а когда - другой?

Некоторые задачи в Bash решаются одной строкой, когда же на Python потребуется десяток строк кода. При усложнении сценария - Bash превращается в головоломку из awk, sed и прочих, что значительно усложняет поддержку. В данной статье сравним подходы и определим, когда и какой язык лучше использовать.

Привет, Хабр! На связи Дарья Попова, тимлид группы мониторинга в Купере. Наша миссия — минимизировать потери от инцидентов для компании и обеспечить сервис на 10/10 для клиентов. Почему это именно группа — вы поймете дальше. Сегодня я расскажу, как мы выстраивали процессы и инструменты мониторинга и автоматизации — и как это все упростило нам жизнь.

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

Привет, Хабр!

Эта статья о том, как мы избавились от шаблонизации в пользу понятных слоёв в управлении инфраструктурой. Расскажу про предпосылки, поиск решения и инструмент, который мы выбрали — CUElang. Поехали!

В управлении Kubernetes-инфраструктурой рано или поздно наступает момент, когда шаблоны из удобного инструмента превращаются в источник боли.

Всем привет!

Недавно я провел опрос среди подписчиков моего Telegram-канала "Код на салфетке", спросив их о возникающих проблемах и ошибках при деплое. Ответов накопилось немало, и большинство из них касались применения Docker. Однако были и комментарии о том, как организовать проект и репозиторий.

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

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

Подготовил для вас roadmap, что важно в 2025 году знать успешному DevOps-инженеру. Пригодится как джуну, так и спецу с опытом, чтобы валидировать свои навыки.

Привет, Хабр! Меня зовут Алексей Быков, я занимаюсь развитием cloud-native-платформы для обработки данных Arenadata One (AD.ONE). В этой статье мы поговорим о neon-kubernetes-реализации PostgreSQL, её устройстве, особенностях и о том, почему классический подход к Postgres в Kubernetes не позволяет в полной мере использовать преимущества гибкой облачной инфраструктуры.

Тема не новая и активно развивается: уже давно существуют операторы (Zalando, Crunchy Data, CloudNativePG) для автоматизации развёртывания Postgres в Kubernetes. Однако они сохраняют монолитность базы, когда данные по-прежнему жёстко связаны с узлами, а горизонтальное или вертикальное масштабирование требует ручной настройки и остаётся непростым процессом. Подход Neon основан на полном разделении вычислений (compute) и хранилища (storage), что даёт нам возможность взглянуть на использование PostgreSQL в облаке по-новому, как на сервис с возможностью динамического масштабирования, мгновенного запуска инстансов, изолированных веток (branching) и других возможностей без необходимости в сложной инфраструктурной обвязке.

Когда вы слышите «облачный провайдер», что первое приходит в голову? Компания, которая предоставляет виртуальные ресурсы и с которой приходится разговаривать строго по шаблону? Но чтобы решения действительно работали, нужен не поставщик, а партнёр — тот, кто погружён в вашу инфраструктуру, анализирует, советует, помогает.

Мы в K2 Cloud не всегда были такими. Наш путь начался более 15 лет назад, и сначала мы были просто провайдером. Но время, опыт и сотни проектов изменили всё: мы прошли путь от первого ЦОДа до облачной платформы собственной разработки с партнёрскими услугами под любой запрос бизнеса. И сегодня я расскажу, как это было — без маркетингового шума, просто как есть.

Меня зовут Кирилл Бойко, я технический директор K2 Cloud, и в облаках (в хорошем смысле) — давно.

Привет Хабр! Меня зовут Олег, я являюсь действующим QA Engineer в компании Intelsy. Это моя вторая статья после этой (тут могла бы быть ваша реклама), уж очень понравилось делиться информацией и получать обратную связь от читателей! Статья для тех, кто хочет улучшить процессы поставки кода в прод или понять, где можно сэкономить время! Постараюсь немного раскрыть эту тему, поделиться своим мнением (которое ни в коем случае не претендует на звание "истина в последней инстанции"), и да, по традиции помним "у каждого своя кухня". Надеюсь прочтение будет интересным и полезным!

В современных IT-командах границы между ролями стираются: разработчики пишут тесты, DevOps внедряют мониторинг, а тестировщики всё чаще участвуют в процессах, выходящих за рамки классического QA. Один из самых спорных вопросов — должен ли QA инженер заниматься релиз-менеджментом?

Некоторые компании нанимают отдельного релиз-менеджера, другие доверяют этот процесс DevOps, но всё больше организаций приходят к выводу, что именно QA инженер — лучший кандидат на эту роль (Так собственно все работает и у меня на проекте).

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

· Почему QA идеально подходит для управления релизами?
· Плюсы и минусы
· Как внедрить релиз-менеджмент в обязанности тестировщика
· Почему отдельная роль релиз-менеджера часто избыточна
· Какие инструменты и метрики использовать для успешного контроля выпусков

 1. Что такое релиз-менеджмент и почему QA должен в нём участвовать?

Релиз-менеджмент — это комплекс процессов, связанных с планированием, подготовкой и развертыванием новой версии продукта. Он включает:

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

Что нужно для этого предпринять?

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

I can help you create and manage Telegram bots. If you're new to the Bot API, please see the manual.


You can control me by sending these commands:

/newbot - create a new bot

/mybots - edit your bots

Edit Bots

/setname - change a bot's name

/setdescription - change bot description

/setabouttext - change bot about info

/setuserpic - change bot profile photo

/setcommands - change the list of commands

/deletebot - delete a bot

Bot Settings

/token - generate authorization token

/revoke - revoke bot access token

/setinline - toggle inline mode

/setinlinegeo - toggle inline location requests

/setinlinefeedback - change inline feedback settings

/setjoingroups - can your bot be added to groups?

/setprivacy - toggle privacy mode in groups


Web Apps

/myapps - edit your web apps

/newapp - create a new web app

/listapps - get a list of your web apps

/editapp - edit a web app

/deleteapp - delete an existing web app

Games

/mygames - edit your games

/newgame - create a new game

/listgames - get a list of your games

/editgame - edit a game

/deletegame - delete an existing game

Для создания бота выбираем опцию /newbot - create a new bot, указываем имя и username, который должен заканчиваться на bot. 

Представьте, что вас каждый день просят «быстренько развернуть стенд» — с OpenSearch, PPO и десятком доработанных инструментов, «ну чтобы все работало». Сначала вы автоматизируете то, что делали руками. Потом автоматизируете автоматизацию. А потом в какой-то момент понимаете: нужно не писать скрипты, а строить полноценный продукт. Так у нас в Orion soft появился HyperDrive — наш способ развернуть Kubernetes-контуры по-настоящему по кнопке. И в этой статье я расскажу, как мы это сделали: от боли и хаоса — к параллелизму, GitOps и здравой инженерной оркестрации.

Привет, Хабр! меня зовут Даниил Рахновский, я — ведущий архитектор в Orion soft. В индустрии DevOps — шесть лет, три из которых веду проекты по HighLoad-инфраструктуре. Основную часть этого времени работал на стороне заказчика, потом перешёл на «тёмную сторону» и теперь работаю на стороне вендора. Занимаюсь сложным проектированием в направлении Professional Services.

Orion soft — это вендор. Мы разрабатываем инфраструктурное программное обеспечение, в портфель которого входит целая экосистема продуктов, а именно zVirt, Nova и другие. В Professional Services мы занимаемся аудитом ИТ-процессов, построением программно-определяемых ЦОДов на собственных технологиях. А еще предоставляем экспертизу вендора и поддержку для пользователей, чтобы наши продукты и технологии правильно и эффективно использовались.

В этой статье по мотивам моего доклада для DevOpsConf 2025 расскажу, как мы решали задачи массового деплоя сложных K8s-окружений. Для этого собрали лучшие практики и применили Open-Source-инструменты, а что-то — дописали с командой самостоятельно. Благодаря этой истории вы убедитесь, что DevOps-инструменты при правильном подходе и оркестрации помогают решать задачи по клику на единственную кнопку.

Мой коллега, Андрей Квапил, недавно в своей статье «Эволюция платформ виртуализации: как мы пришли к миру managed‑сервисов и как сервис‑провайдерам конкурировать с AWS» выдвинул тезис, что AWS, GCP и Azure предоставляют своим пользователям удобные API.

Это продолжение цикла, рассказывающего о практике развёртывания производственного кластера Cassandra. В первой части мы начали продвигаться вот по такому плану:

1. Анализ рабочей нагрузки и требований
2. Разработка схемы данных
3. Настройка хостовых машин
= ВЫ НАХОДИТЕСЬ ЗДЕСЬ =
4. Настройка конфигурации Cassandra
5. Настройка топологии кластера
6. Подключение Prometheus Cassandra Exporter
7. Подключение Prometheus Node Exporter
8. Вывод всех метрик в Grafana
9. Проведение нагрузочного тестирования
10. Дополнительный тюнинг по результатам теста

Продолжим?

Привет, Хабр!

Помните то блаженное время, когда для доступа к любому ресурсу хватало простого WireGuard до сервера в Германии? Я тоже помню. Но эта эпоха закончилась. Недавно я заметил, что мой верный VPN стал лагать, рвать соединение и вести себя так, будто его кто‑то целенаправленно «душит». Это был тот самый момент, когда я понял: игра изменилась. Системы глубокого анализа трафика (DPI) стали умнее, и мой трафик для них был как на ладони.

Это стало моим личным вызовом. Я отправился в путешествие по миру современных средств обхода блокировок, наступил на множество граблей (чего только стоит осознание, что «двойное шифрование» — это миф!), но в итоге нашел свое сокровище — рабочую и относительно устойчивую схему на базе VLESS+Reality и Multi‑hop.

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

Меня зовут Владимир Казеннов. С недавнего времени я руковожу группой развёртывания программного обеспечения (ПО) MES-систем в одном из подразделений нашей дружной ИТ-команды «Северстали». Сегодня я немного приоткрою завесу тайны, покрывающую корпоративный деплой.

По инструментам всё достаточно просто. На столе у нас GitLab, ему когда‑то очень‑очень давно помогал Jenkins, немного Vault, чуть‑чуть Helm. Далее погружаемся в кубер, в его лучшую версию на все времена — RKE (Rancher Kubernetes Engine), там уже и Graylog наблюдает за нами, рядом же крутится Kafka c Redis.

Привет, Хабр!

В первой части нашего путешествия мы превратили голый VPS в маленькую крепость. Мы создали пользователя с sudo, настроили вход по SSH‑ключам, выставили на стражу файрвол UFW и наняли вышибалу Fail2ban. Теперь лобовые brute‑force атаки и автоматические сканеры разбиваются о наши стены, не доставляя хлопот. Мы победили, верно?

Не совсем. Наша крепость неприступна, но она слепа. Мы отбиваем тех, кто ломится в ворота, но совершенно не видим, что происходит на периметре. Что если уязвимость найдется в нашем веб‑сервере? Что если одна из запущенных нами программ начнет слать странный трафик, став частью ботнета?

Здесь нам нужна «сигнализация». Система, которая станет нашими глазами и ушами, и поднимет тревогу при малейшем подозрительном движении. Сегодня мы установим именно такую — Maltrail.

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