Администрирование

Привет! Я Саша Хренников, руководитель DevOps-юнита в KTS.

Неделю назад мы запустили DevOps-челлендж в честь 5-летия нашего блога на Хабре. Участникам нужно было разобраться, почему приложение не может синхронизироваться в ArgoCD, найти ошибку в конфигурации и довести деплой до зеленого статуса.

Челлендж завершен, а значит, пришло время подвести итоги и пошагово разобрать решение.

Но сначала важное объявление. Мы по-прежнему оставляем открытым доступ и к этому челленджу, и ко всем предыдущим испытаниям. Так что если вы пропустили запуск, не успели поучаствовать вовремя или просто хотите потренироваться, все еще можно пройти задачу самостоятельно в нашем боте. То же касается и архивных челленджей: они остаются доступными, чтобы можно было набить руку к следующему разу.

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

В конце статьи, как и обещал, будет таблица с десятью победителями, которые справились с задачей быстрее остальных и получат СДЭКом наши футболки.

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

На связи команда разработки контейнерной платформы «Штурвал». Недавно мы выпустили новую версию 2.13.

Теперь пользователям доступны установка через YAML и флаги командной строки, профили кластеров по шаблонам, containerd 2.x с шифрованием образов, сводные отчеты по безопасности. Под катом делимся самым интересным.

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

Я ставил Kubernetes на Orange Pi (orangepi4pro) и наивно ожидал, что Calico «просто заведётся». В реальности DaemonSet calico-node ушёл в перезапуски, readiness/liveness-пробы падали, а в событиях Kubernetes мелькали BIRD и Felix.

Сначала это выглядит как «какая-то проблема Calico/BGP», но причина оказалась куда прозаичнее: в установленном ядре банально нет нужных netfilter/ipset/ipip модулей.

Потыкал я на досуге один из ИИ-терминалов и делюсь этим опытом. Об установке писать не буду, там все банально и просто: тыкаете мышкой и готово. А вот дальше — все очень занимательно. Экспериментировать я буду на своих реальных задачах, поэтому часть функционала в статье не упомяну. У всех разные задачи и потребности, здесь нет серебряной пули. Поехали!

Мониторинг часто воспринимают как «ещё одну панель», на которую нужно иногда поглядывать. Открыть браузер, зайти в дашборд, проверить зелёные кружочки, закрыть. Но что, если сделать его частью вашего повседневного инструментария - как git, как curl, как любимая IDE? Именно для этого мы добавили в PingZen поддержку MCP.

Сегодня я расскажу, как мы превратили наш сервис в MCP-сервер с 126 инструментами, почему выбрали MCP SDK и как вы уже сейчас можете управлять мониторингом из Claude Code, Cursor и других AI-агентов. Без переключения контекста, без лишних движений - только нужные действия там, где вы работаете.

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

Почти в любой компании есть момент, когда кто-то говорит: «У нас какой-то зоопарк систем». Все кивают, кто-то даже предлагает навести порядок. Но на этом обычно все и заканчивается.

Потому что дальше возникает неприятный вопрос: а что именно у нас вообще есть? И вот тут внезапно выясняется, что часть систем никто не трогал годами, но отключить страшно, какие-то сервисы дублируют друг друга и используются параллельно, интеграции есть, но как они работают знает один человек (и он в отпуске), а часть инфраструктуры вообще существует сама по себе и живет своей жизнью.

Меня зовут Данила Трусов, я директор продукта «Инферит ИТМен». И за последние годы я ни разу не видел компанию, где бы «зоопарк» был исключением. Это скорее норма.

У вас в GitLab несколько проектов с одинаковым CI? Или просто надоела копипаста в пайплайнах? Каждое изменение нужно отразить в 10 местах? Рассказываем, как сократить код на 56 %, убрать дублирование и сделать один CI для всей группы проектов. Шаблоны, матрицы и практика.

Эта статья — не туториал и не обзор. Это история о том, как я искал инструмент для своих задач, не нашёл, расстроился, а потом успокоился и написал свой. Речь пойдёт о Ботинке — консольном AI-агенте для работы по SSH. Но сначала немного контекста.

Я работаю с Linux-серверами уже лет пятнадцать. За это время видел разные эпохи: когда всё настраивали руками, когда появился Ansible, когда все бросились в Kubernetes, когда устали от Kubernetes и вернулись к простым docker-compose. Скрипты-костыли множились, документация устаревала, а сервера как требовали внимания, так и требуют.

И вот теперь добавился ещё один слой — LLM. Можно спросить у модели, как настроить nginx, и получить рабочий конфиг. Можно попросить проанализировать логи. Но каждый раз копировать-вставлять между терминалом и чатом — это отдельный вид боли. Хочется, чтобы модель жила прямо в консоли, понимала контекст сервера и могла сама выполнить рутину.

Статья будет полезна тем, кто:

Работает с серверами по SSH и устал от рутины

Интересуется AI-агентами, но хочет что-то лёгкое и локальное

Имеет ограниченные ресурсы (не у всех есть 24GB VRAM)

Хочет понять, как строится архитектура агента с инструментами

Зачем ещё один AI-агент?

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

На волне хайпа попробовал OpenClaw — хайповый проект 2025-2026 года, self-hosted AI-агент для автоматизации жизненных задач. Идея в целом норм: агент работает 24/7, отвечает в Telegram/WhatsApp, умеет чистить почту, управлять календарём, чекиниться на рейсы. Четырёхслойная архитектура, куча интеграций, активное сообщество.

Но на практике для моих задач оказалось слишком тяжело:

Оверсложнённая архитектура — Gateway, Integration, Execution, Intelligence — это отлично для энтерпрайза, но перебор для «зайти на сервер и поправить конфиг»

Ориентация на lifestyle-автоматизацию — почта, календарь, бронирования. А мне нужно: логи, systemd, docker, nginx

Постоянно висящий сервис — 24/7 демон, который кушает ресурсы. А я хочу: запустил — поработал — закрыл

Мессенджер как интерфейс — удобно для личного ассистента, но для админской работы нужен терминал и SSH

OpenClaw крут для своей ниши — персональный ассистент в Telegram. Но моя задача другая: консольный агент для системного администрирования. Зайти по SSH, диагностировать проблему, поправить, уйти. Без демонов, без мессенджеров, без оверхеда.

Так родился Ботинок.

Ключевая идея: не сервис, а инструмент

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

Идея пришла из наблюдения за тем, как работают разработчики с Cursor, Windsurf и подобными IDE. Там ты открыв

С конца нулевых в ИТ-кругах ведутся разговоры о социально ориентированных облачных хранилищах, призванных усилить контроль пользователей над своими данными. Мы в Beeline Cloud решили взглянуть на «альтернативные модели управления данными» — например, как выглядит профсоюз владельцев данных и для чего он нужен — и обсудить, почему такие форматы (пока еще) не получили широкого распространения.

В этой короткой статье я расскажу, как определить IP-адреса, которые использует Telegram. А что делать с этой информацией дальше - решайте сами.

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

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

У одного из наших заказчиков вся инфраструктура расположена в Yandex Cloud и для доступа во внутреннюю сеть ко внутренним ресурсам компании а-ля Grafana, Prometheus, Elasticsearch и т.д. использовался VPN-сервис на базе Self-Hosted OpenVPN. При этом аутентификация пользователей VPN осуществлялась просто по локальным учетным записям на сервере через конфигурацию сервера вида

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

~120 строк на Python.

qtile — тайловый оконный менеджер для Linux, целиком написанный на Python. Конфиг — тоже Python, с asyncio, доступом к procfs и вообще ко всему, что есть в системе. Я сижу на qtile уже почти 15 лет с одним и тем же конфигом, который потихоньку допиливаю, и что мне в нём нравится: панель оконного менеджера — удобное место для визуализации метрик, собранных из произвольных Python-скриптов.

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

Но есть и другая сторона — когда доменные имена живут только внутри вашей приватной сети. Это и есть приватный DNS. Он не показывает адрес сервера для внешних запросов на резолв имени db.internal, да и вообще не отвечает на запросы извне.

Он нужен, чтобы не запоминать, на каком IP локальный GitLab или тестовый стенд, и не гадать: «так, .105 — это балансировщик или база данных?». Ну и чтобы не бегать по всем серверам, заменяя один IP-адрес на другой для той самой базы, переехавшей на более мощное железо руками, — это долго, и легко ошибиться.

В этой статье разберем, зачем вообще нужна своя система имен в закрытом контуре и как она устроена технически.

Меня зовут Дмитрий Синявский, я SRE в Ви.Tech, IT дочке «ВсеИнструменты.ру». В какой то момент я поймал себя на мысли, что вокруг DevOps снова спорят как в начале десятых: одни уверяют, что он умер, другие переименовывают все в platform engineering, третьи ждут, что ИИ наконец сделает всю грязную работу за инженеров. Мы с Владимиром Утратенко, который прошел путь от техподдержки до техдиректора и сейчас развивает платформу «Штурвал», спокойно разложили это по полочкам.

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

Привет, я Максим Королев из Петрович-Теха. В прошлой статье про «Дежурного» я рассказывал, как мы ушли от «толстых» обработчиков aiogram к архитектуре CORE + два адаптера — Telegram и MAX.

С замедлением Telegram стало понятно, что нам нужен стабильный резервный канал. Часть команды уже перешла на MAX, часть осталась в Telegram. И вот мы столкнулись с классической проблемой: один коллега пишет в TG, другой отвечает из MAX — диалог разрывается, контекст теряется, инцидент ведется «вслепую». Нужен был мост. И мы ввели параллельную работу в Telegram и в MAX, соединили эти два мира между собой и глубже встроили бота в процессы ITIL 4/ITSM. 

Главное сделали так, что:

Загрузка процессора под 100% на сервере 1С – одна из самых частых и критичных проблем. Это приводит к торможению работы пользователей и, как следствие, к простою и убыткам для бизнеса. Причины могут быть как в прикладном коде, так и в особенностях работы платформы и серверного оборудования. В этой статье структурируем все основные причины высокой нагрузки на CPU, дадим краткий алгоритм диагностики и предоставим ссылки на детальные руководства по решению.

Это статья моего коллеги Андрея Бурмистрова, эксперта в сфере оптимизации производительности 1С.

Привет! Меня зовут Иван Откидач, я DevOps-инженер в команде DBA. Моя основная специализация — NoSQL-базы данных, в частности Redis и MongoDB. С каждым месяцем количество Redis, находящихся на нашей поддержке, растёт, поэтому обеспечение их стабильной и надёжной работы — один из приоритетов нашего подразделения. В этой статье мы разберем, как устроен механизм отказоустойчивости в Redis Cluster и почему он может давать сбои в multi-AZ-инфраструктуре. Также покажем один из практических подходов к решению этой проблемы.

Привет, Хабр! На связи команда Рунити под руководством Антона Ивахненко: Дмитрий Виноградов, руководитель направления разработки, менеджер продукта Карина Калеева, ML-инженер Александр Михеев и тех.лид Владимир Устьянцев. 

В этой статье мы рассказываем про RAG-ассистента, который скоро у нас появится. Этот ассистент ищет по Confluence и GitLab одновременно, уважает права доступа и не отправляет корпоративные данные наружу. Но обо всём по порядку.