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

Меня зовут Дмитрий, я руковожу отделом ИТ-инфраструктуры и сервисов в Ви.Tech, IT-дочке ВсеИнструменты.ру. В предыдущих частях я рассказывал про P&L-центры, ценообразование, учет ресурсов и планирование бюджета, а теперь хочу перейти к самой чувствительной части всей этой истории - оптимизации потребления.

Здесь уже недостаточно просто собрать цифры в отчет. Нужно понять, где ресурсы реально тратятся неэффективно, что с этим можно сделать без вреда для сервисов и с какими организационными проблемами мы почти наверняка столкнемся по дороге.

Меня зовут Дмитрий, я руковожу отделом ИТ-инфраструктуры и сервисов в Ви.Tech, IT-дочке ВсеИнструменты.ру. В прошлой части я рассказывал, как мы собираем и считаем потребление вычислительных ресурсов, а теперь хочу перейти к следующему шагу - планированию ИТ-бюджета на базе этих данных.

Для этого я обычно использую два дополняющих друг друга подхода:

Меня зовут Дмитрий, я руковожу отделом ИТ-инфраструктуры и сервисов в Ви.Tech, IT-дочке ВсеИнструменты.ру. В прошлой части я подробно разбирал ценообразование вычислительных ресурсов, а теперь давайте соберем все это в единую модель учета и посмотрим, как она помогает не просто считать цифры, а принимать вполне прикладные решения.

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

1. Отдельно стоящее оборудование

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

HW_month_price = HW_price / 60

При этом:

Сталкивались уже с EvaTeam (российский аналог Jira)? Чувствуете боль при работе с бизнес-процессами (workflow)? Думаю я могу вам немного помочь

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

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

Привет! Я Саша Хренников, руководитель 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-адрес на другой для той самой базы, переехавшей на более мощное железо руками, — это долго, и легко ошибиться.

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