Сотрудник уволился, ноутбук — тоже

Уволенный уносит ноутбук. Новичок выходит без ноутбука. Между ними — «серая зона» из техники, которая числится за людьми только на бумаге. Считаем, сколько это стоит компании в год.

Уволенный уносит ноутбук. Новичок выходит без ноутбука. Между ними — «серая зона» из техники, которая числится за людьми только на бумаге. Считаем, сколько это стоит компании в год.

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

Привет, Хабр!
На связи команда инженеров сервисного центра с очередной нетривиальной задачей, которую мы решали у одного нашего крупного заказчика.
Многие Linux-серверы со временем сталкиваются с одной и той же проблемой: корневая файловая система постепенно «обрастает» данными приложений, снэпшоты виртуальных машин становятся слишком большими, резервное копирование занимает всё больше времени, а свободного места для классической миграции уже не остаётся. Особенно часто это встречается на старых системах, где изначальная разметка дисков создавалась без понимания того, какое прикладное программное обеспечение будет использоваться в будущем.
Так возникает необходимость вынести данные приложения на отдельную файловую систему, но традиционный подход требует полного копирования больших объёмов данных и длительного простоя сервисов. В этой статье мы покажем способ изменить разметку уже работающей Linux-системы без переустановки ОС и без копирования сотен гигабайт данных.

Безопасный AI-мониторинг Oracle в закрытом контуре с использованием Python, Ollama и V$WAITCLASSMETRIC
Введение
В существующей системе мониторинга Oracle уже использовалось разработанное мной решение, которое с интервалом в 1 минуту собирало метрики производительности из представления V$WAITCLASSMETRIC и отображало их в Grafana. Графики наглядно показывали изменения времени ожиданий в классах User I/O, Commit, Concurrency и других, однако они показывали лишь сам факт изменения нагрузки, не объясняя его причины.
Возникла идея: если метрики уже собираются для построения дашбордов, почему бы одновременно не отправлять их локальной языковой модели? Тогда вместе с графиком можем сразу отображать текстовое объяснение происходящего, список наиболее вероятных причин изменения показателей и рекомендации, с чего начать дальнейшую диагностику.
Так появился небольшой эксперимент — дополнить существующую систему мониторинга Oracle локальным AI-ассистентом.

Представьте ситуацию: вы приходите к руководству с четким техническим обоснованием миграции в облако: оборудование устаревает, вычислительных мощностей не хватает, риски простоев растут. Рассказываете, как облако поможет быстрее запускать новые сервисы, масштабировать инфраструктуру и снизить нагрузку на команду. А в ответ слышите: «Бюджет не согласован. Живите с тем, что есть».
Знакомая ситуация? Проблема не в качестве ваших аргументов. Проблема в том, что ИТ и бизнес говорят на разных языках. Вы говорите на языке технологий, а CFO – на языке финансов. У вас даже KPI разные: для вас важны аптайм, время восстановления, скорость развертывания сред, в то время как для финансового директора – только деньги.
Пока вы не найдете точки соприкосновения, договориться о бюджете на миграцию в облако будет тяжело. Но не стоит отказываться от технологической логики, просто нужно научиться переводить её на язык инвестиций. Показать CFO, что облако выгодно не потому, что оно «гибкое, масштабируемое и современное», а потому что оно приносит деньги или помогает перестать их терять.

Всем привет! Это первая публикация из цикла статей про распределение сервисов в кластере виртуализации. В статье будет описан один из подходов к решению задачи от определения проблемы до результатов тестов с демонстрацией работы готового решения.

Привет, Хабр! На связи Игорь Шишкин, я руковожу отделом разработки облачной платформы Рег.облака. Когда инженеру нужно где-то сложить данные, первая мысль — взять диск побольше. Но внутри нашей инфраструктуры почти всё, что растет и читается параллельно, давно переехало в S3: логи, метрики, бэкапы баз, образы контейнеров, артефакты сборок. Диск остался только там, где он по-настоящему незаменим. В этой статье я расскажу, где именно мы используем объектное хранилище и почему в каждом из этих мест выбрали именно его, а не диск.

Привет, Habr! Меня зовут Валентин, я DevOps-инженер команды Platform V Kintsugi. Мы занимаемся развитием облачного сервиса и на практике регулярно сталкиваемся как с архитектурными задачами построения распределённых систем, так и с вопросами обеспечения их безопасности.
В предыдущей части мы подробно разобрали механизм делегирования TLS-соединения на уровень Service Mesh и показали, как Egress Gateway может выступать полноценным участником PostgreSQL handshake. Однако этот сценарий рассматривался в упрощённой конфигурации — один сервис, один сертификат, одно подключение.

Доменные имена не резолвятся, страницы висят, а по IP всё доступно. В логах DNS‑сервера при этом чисто, BIND запущен, конфигурация на первый взгляд выглядит рабочей.
Разбираемся, как одна ошибка в forwarders может отправить DNS‑запросы по кругу и превратить обычный резолвинг в цепочку таймаутов.

Как в Debian настроить Btrfs, Snapper и grub-btrfs так, чтобы после неудачного обновления вернуть рабочую систему за несколько минут.

Сколько замечал, для Debian stable никто не делал отдельных репозиториев со свежими графическими драйверами, в отличие от Ubuntu, а поиграть в новые игры или получить свежие фишки Mesa хочется, не переходя на свежие дистрибутивы вроде Arch Linux или Fedora. Пакетный менеджер в Debian очень строгий, и смесь Ubuntu-ppa он терпеть не будет, так что придётся всё собирать вручную из исходников.
В статье описана сборка свежих драйверов Mesa3D для Debian Trixie с использованием Podman и манифеста Kubernetes.

TL;DR. Я выбирал Timeweb не из-за цены, а из-за «имени» и обещанной надёжности. За май–июнь 2026 года зона ams-1 (Амстердам, дата-центр Qupra) пережила шесть крупных аварий с суммарным окном недоступности около 46 часов — причём последняя авария на момент написания этих строк всё ещё не закрыта и идёт уже более 15 часов. Хостер на своём сайте обещает Tier III и аптайм 99,98 % — это 1 час 45 минут простоя в год. За два месяца факт превысил годовой лимит этого обещания примерно в 26 раз. Все цифры ниже — не мои домыслы и не «жалобы в чате», а сообщения из официального канала статусов самого Timeweb.

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

Демон cron знаком каждому, кто админит Linux. Он крутит бэкапы, чистит временные файлы и запускает скрипты, о которых все уже давно забыли. Однако многие не знают, что одна строка в crontab способна снести данные, забить диск, устроить форк-бомбу или открыть лазейку для хакера. Под катом я разберу, когда и как именно cron становится опасным, и какие команды помогут держать его в узде.

Конфигурируем, собираем и устанавливаем ядро Linux на свое железо. Отчищаем ядро от лишних модулей через make localmodconfig и modeprobed-db store, компилируем, обновляем GRUB.

При работе с Apache Kafka рано или поздно возникает необходимость быстро проверить топик, прочитать сообщения или посмотреть состояние группы потребителей (consumer group). Можно применять стандартные инструменты Kafka. Однако на практике они часто оказываются не самыми удобными для повседневной работы. Многие команды получаются длинными, каждый раз требуют передачи параметров подключения и нуждаются в различных CLI-утилитах.
Есть и более легкие решения — например, kcat, который хорошо знаком многим инженерам и часто используется для диагностики Kafka. Но существует и вариант поудобнее — kafkactl.
Привет, Хабр! Меня зовут Сергей Кардапольцев, я технический писатель в Selectel. В этой статье мы познакомимся с kafkactl — CLI-инструментом для работы с Kafka. Посмотрим, чем он отличается от стандартных Kafka-утилит и kcat, а также разберем базовые сценарии работы на примере кластера.

Привет, Хабр!
С вами снова Илья Вязников, инженер сопровождения СОФРОС. Продолжаю делится практическими приёмами и полезными настройками платформы.
В этой статье покажем, как интегрировать Datareon Platform с Zabbix через API Центра мониторинга.

Миграция — риск даже для небольших инфраструктур. А когда у вас больше миллиарда пользователей и петабайт данных, права на ошибку нет вообще. Но выход всё равно один — грамотно спланировать переезд и... взять и сделать.
В статье — о том, как Reddit перешёл на Kubernetes: почему они отказались от Amazon EC2, какие ограничения им пришлось учитывать и чем их опыт может быть полезен в других проектах.

Александр Либкинд, руководитель направления развития сервисов управления затратами и эксперт Практики FinOps, поделился материалом о том, почему ручная инвентаризация инфраструктуры редко приводит к устойчивой экономии и как перейти от разовых проверок к управляемой модели.
Поводом могут быть GPU-инстансы, тестовые окружения, неиспользуемые диски, свободные IP-адреса или любые другие ресурсы, которые продолжают потреблять бюджет после завершения задачи. Но проблема почти всегда шире, чем один тип инфраструктуры.
Если у ресурса нет владельца, команды, среды и приложения, компания не управляет затратами. Она просто периодически пытается разобраться, что можно отключить без последствий.
Поднимая очередной VDS для небольшого личного проекта, я решил провести эксперимент. Последнее время я всё чаще делегирую рутинные задачи AI-агентам: сравнить пару таблиц, написать обоснование, разобрать логи. Задачи шаблонные — и агенты справляются с ними достаточно хорошо. Первоначальная настройка нового сервера как раз из этого ряда: действия известные, последовательность одна и та же, с небольшими вариациями по месту.
Мне досталась абсолютно чистая виртуальная машина. Типовой список задач выглядит шаблонно: обновить пакеты, сменить хостнейм, создать непривилегированного пользователя, настроить sudo, закрыть SSH для root, выключить авторизацию по паролю и оставить только ключи, поднять файрвол — разрешить нужные порты, запретить остальное, установить защиту от брутфорса. Всё это вместе называется «первые десять минут на сервере» и кочует из статьи в статью примерно с начала времен.
Я наблюдал за работой агента вполглаза, подтверждая команды — всё-таки новым чудесным технологиям я пока ещё доверяю не до конца. В какой-то момент взгляд зацепился за нетипичное: настраивая SSH-доступ, я привычно ввожу в терминал ssh-keygen -t rsa -b 4096 — уже много лет, не задумываясь, на уровне доведённой до автоматизма мышечной памяти.
Агент предложил мне нечто иное.
Я решил разобраться — и это увело меня на полчаса в мир криптографии и шифрования. Результатами этого погружения мне хочется поделиться в этой статье.