DevOps *

Хочу понять, есть ли потребность в решении которое я проектирую.

Деплой через AI — есть ли в этом смысл?

Привет.

Я студент, изучаю Ansible на Raspberry Pi через Tailscale. Делюсь полным путем от первой ошибки до работающих веб-серверов. Код + выводы + уроки. Репозиторий на GitHub.

Self-hosted AI-платформа на Docker: N8N, Ollama, Open WebUI, Qdrant, Whisper. Автоустановка, 152-ФЗ. Разбор архитектуры, benchmark топовых моделей декабря 2025 (DeepSeek-R1, Llama 3.3, Qwen 2.5), метрики на CPU/GPU, расчёт TCO.

За последний год из компании Alfabit.org было уволено большое количество сотрудников. Договор в компании составлен так, что тебя могут уволить "одним днем" и ты еще останешься должен (и зарплата уйдет на погашение "не выполненных задач"). Обо всем по порядку:

Статья объясняет, как StarRocks 4.0 делает запросы к JSON почти столь же быстрыми, как к нативным столбцам. FlatJSON на этапе загрузки «колоннизирует» частые поля и задействует индексы (включая ZoneMap), словарное кодирование и Global Dictionary, а также Late Materialization. В результате логовая, e‑commerce и IoT‑аналитика работает в реальном времени без тяжёлого ETL.

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

В этой статье по мотивам доклада с DevOpsConf затрону тему не самых очевидных нюансов, с которыми столкнётся инженерная команда, мигрируя инфраструктуру на облака или в on-prem. У каждого решения есть причины, но прежде покажу на основе опыта и кейсов, какие неочевидные факторы следует учесть, чтобы миграция прошла хорошо. Не только в инженерном смысле, но и в соответствии с возможностями бизнеса.

StarRocks 4.0: Real‑Time Intelligence on Lakehouse. Сквозная оптимизация конвейера в реальном времени, 3–15× ускорение JSON, SQL Plan Manager, Decimal256 и поддержка Apache Iceberg для нативной Lakehouse‑аналитики.

Еще лет 10 назад iPhone в корпоративной среде воспринимали примерно как электрокары Тесла. Да, красиво, да, статусно, но как с этим жить – решительно непонятно. Особенно людям, которые дальше Windows и Outlook вообще никогда не выглядывали. Но мир поменялся, айтишники забыли, как патчить KDE2 под FreeBSD, а iPhone научились нормально работать с MDM. Однако остался вопрос: насколько все это применимо к реальной жизни, особенно в наших широтах, где к эппловским девайсам отношение стало, мягко говоря, настороженным?

Привет, Хабр! Сегодня хочу поделиться опытом того, как я отказался от стандартной утилиты мониторинга SSSD в пользу прямого общения с демоном через D-Bus и создал полнофункциональный Ansible-модуль.

Привет, Хабр! У платформы VK Cloud есть продукт, который позволяет компаниям частично или полностью перенести свою инфраструктуру не в публичное, а в частное облако. То есть хранить все в своем ЦОД и под личным контролем — но пользоваться при этом интерфейсом и инструментами, разработанными VK Tech.

В этой статье расскажем, как работает платформа VK Private Cloud и чем на самом деле она отличается от публичного облака. Будет много технических примеров, деталей и конфигураций и минимум общих описаний — только для уточнения нюансов. А также подробности о новой версии 4.3.

Zabbix — отличный универсальный инструмент. Но как только виртуалок становится не 20, а 200, всё превращается в бесконечный тюнинг: поднял лимит PHP, подкинул кэш, вырубил логирование — и надеешься, что доживёт до утра. Мы проверили, где эта грань на самом деле проходит и как себя ведёт альтернатива — zVirt Metrics. В статье — архитектура, производительность и честные цифры из тестов. Материал будет полезен инженерам, которые держат на себе мониторинг виртуализации и хотят, чтобы всё работало из коробки и без плясок с бубном при росте числа инсталляций zVirt.

Я работаю DevOps-инженером в команде разработки продукта Колибри-АРМ, аналога Microsoft SCCM, покрывающего потребности в импортозамещении ПО для управления парком АРМ. В данной статье будет описан кейс решения задачи по обеспечению высокой доступности продукта – она будет по большей части описывать перенос непосредственно функциональности, и тут не будут рассматриваться такие аспекты как безопасность кластера и приложения внутри.

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

Привет, Хабр! Меня зовут Макарий, и как Senior SRE в Yandex Cloud я не только участвовал в разработке Managed Service for Kubernetes, но и всегда любил в свободное время посмотреть, что интересного понавыпускали для «кубика». Kubernetes, как де‑факто стандарт оркестрации контейнеров, предлагает базовые механизмы для управления вычислительными ресурсами. Однако стандартный планировщик Kubernetes (kube‑scheduler) разрабатывался с учётом общих принципов балансировки нагрузки и не специализирован для уникальных особенностей рабочих GPU‑нагрузок.

Предлагаю рассмотреть весь спектр возможностей — от встроенных механизмов шедулинга K8s до специализированных планировщиков, таких как Volcano, Apache YuniKorn и KAI‑Scheduler. Проанализирую конкретные сценарии, в которых каждый из этих инструментов демонстрирует свои преимущества, и предложу рекомендации по выбору оптимального решения для ваших рабочих GPU‑нагрузок.

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

Для практики я использую локальный кластер на Minikube — он позволяет экспериментировать с компонентами Kubernetes без аренды серверов или облачных инфраструктуры.

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

Всем привет! Меня зовут Сергей, и я Backend Kotlin разработчик в компании занимающейся разработкой систем повышающую безопасность дорожного движения. И я расскажу, как мы с помощью Jetpack Compose и GitLab API упростили процесс деплоя на 100+ распределённых серверов, повысив при этом удобство и предсказуемость процесса.

В последнее время тема лидерства в IT компаниях потерялась в потоке энтузиазма, вызванного безграничными перспективами отрасли. Лидерство, конечно, фигурирует в современных методологиях типа Agile и DevOps, но при этом не наделяется достаточной силой, чтобы выполнить свою трансформационную роль. Лидерство выглядит как Золушка с неочевидным для всех королевским потенциалом. Эта статья возвращает лидерство на пьедестал, обосновывая его уместность именно для IT. Речь здесь идет о таком лидерстве, которое одержимо незаурядным результатом в равной степени, как и опорой на смыслы и человеческое достоинство и не имеет ничего общего с расхожим «лидерством», которое практически равнозначно понятию «руководитель». За таким подлинным пониманием лидерства, стоят хорошо известные с 70-х годов принципы трансформационного лидерства Джеймса Бернса и Бернарда Басса. В период индустриальной эпохи эти принципы использовались факультативно, хотя и с большим успехом. Лидерство в компаниях стало притчей во яцызах , но не возобладало в традиционном менеджерском управлении. Эра информационных технологий делает трансформационное лидерство в IT компаниях безальтернативным. Эта статья не про теоретические изыскания на будущее, а про достижение незаурядных результатов в настоящем.

Многие команды уже построили вокруг Kubernetes свои внутренние платформы, но со временем они превращаются в свалку YAML’ов и разрозненных Helm-чартов. В статье показывается, как собрать из этого аккуратный «конструктор» из трёх уровней компоновки (инфраструктура, сервисы платформы, приложения), завязать всё на GitOps через Argo CD и vCluster, а затем скрыть сложность за шаблонами и CRD, чтобы разработчику было достаточно описать один WebApp-ресурс вместо возни с десятком сущностей Kubernetes.

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

Я хочу показать один из способов решения такой задачи на примере облака VK Cloud с учетом специфики его SDN-сети. Отдельно хочется добавить, что рассматриваемый в статье подход к построению сетевой связности может быть успешно применен не только в VK Cloud.

В основу статьи легли вопросы и задачи, с которыми клиенты часто обращаются к командам Presale архитекторов и Professional services VK Cloud, когда они хотят построить надежное гибридное решение для своего бизнеса.

Мне хотелось написать статью, которая будет не научно-популярным повествованием, а практическим руководством, систематизирующим имеющиеся знания по разным продуктам и сетевым технологиям.