Разбор упавших файловых систем, потерянных баз данных и умирающих дисков съедает время, особенно когда всё это приходится восстанавливать консольными утилитами или самописными скриптами. Однако настройку бэкапов можно упростить с помощью утилит — под катом я собрал топ-10 опенсорс-инструментов и рассказал, на основе чего выбирать.
Привет, Хабр! Я Дмитрий Киселев, руководитель группы сервисной поддержки решений по передаче данных в «Инфосистемы Джет» и создатель программы для стажёров в команде. И сегодня я расскажу вам о том, как мы придумали и уже несколько раз провели новые сетевые игры.
«Нужно построить зиккурат!» — знакомая фраза? А если нужно построить не зиккурат, а BGP-соседство? Именно этим и надо заниматься в первой стратегии, которую мы создали для сетевых инженеров — NetCraft.
После нашей первой игры для сетевиков — «Need for Speed: VXLAN EVPN. Гонки на коммутаторах» — мы поняли: инженерам мало просто настраивать скорость — интереснее придумывать сложный план действий. Так родилась идея стратегии в реальном времени, но с консолью вместо мышки.
Игра успешно зарекомендовала себя на Linkmeetup, Сетевом лете и IT Elements. Мы уже обновляем игры к Сетевому лету-2026, а пока я расскажу правила.
Привет, Хабр! Меня зовут Никита, и я из тех, кого принято называть импортозамещенцами. Я работаю в компании-интеграторе по ИБ «Экстрим безопасность», которая помогает заказчикам как с банальным PaperSec'ом, так и в вопросах результативного кибербеза. В нашем арсенале широкий спектр решений: начиная с SecretNet Studio, Dallas Lock, защищённых сетей, и до NGFW и продуктов из экосистемы Positive Technologies. И тем не менее, не смотря на ИБ-шный профиль компании, нам все-таки не удалось увернуться от тотального импортозамеса, который начался в 2022 году.
Статья о том, как читать kubectl describe pod не как длинный вывод, а как историю жизни Pod«а: кто его создал, куда его пытались поставить, скачался ли image, стартовали ли init containers, что случилось с probes, volumes, restarts и Events.»
Постарался сделать материал дружелюбным для джунов и мидлов, но без упрощения до «введите команду и посмотрите статус». Тут много реальной эксплуатации: Pending, CrashLoopBackOff, ImagePullBackOff, OOMKilled, FailedMount, CreateContainerConfigError, Evicted и любимое «Pod Running, но сервис не работает».
Если вам нужна не вся теория, а быстрая шпаргалка для инцидента — в конце статьи есть компактная схема: что смотреть в kubectl describe pod при Pending, CrashLoopBackOff, ImagePullBackOff, OOMKilled, FailedMount и других типовых состояниях. Можно сразу перейти к ней, сохранить и использовать как чек‑лист. А если хочется понять не только «куда смотреть», но и почему Kubernetes ведёт себя именно так — дальше разберём describe вместе по шагам.
У дисковой подсистемы слишком хорошая репутация в тарифных таблицах и не самая однозначная в инженерных обсуждениях. В первом случае нам продают гигабайты в секунду, во втором часто говорят, что для веба диск почти не важен.
Я работаю контент-маркетологом в Scalehost и по работе регулярно разбираю темы, связанные с производительностью веб-проектов. Вопрос “нужен ли сайту NVMe или это просто маркетинговая галочка” возникает так часто, что мне захотелось собрать его в один технически внятный разбор.
Модель pay-as-you-go, которую предлагают в облаке, всегда была палкой о двух концах. С одной стороны, история вроде честнее некуда: платишь ровно за то, что заказал. Как в ресторане. Но, с другой, именно она практике нередко приводит к такому перерасходу, что поневоле начинаешь задумываться, а нужно ли нам вообще это облако?
На самом деле чудес не бывает, и я намеренно перевел pay-as-you-go как “платишь за то, что заказал”. Внимание: заказал, а не потребил. Потому что в этом и заключается первая проблема – нет, не облаков, – а тех, кто их использует. Компании регулярно выходят за рамки бюджетов, потому что платят за ресурсы, которыми де-факто не пользуются. Тут и забытые тестовые стенды, и старые проекты, которые продолжают генерировать счета, и простаивающие виртуальные машины с запасом по мощности, и чего только не. В результате до 30% облачного бюджета просто улетает впустую. А у некоторых и того больше.
Плюс – усложнение архитектуры как таковой. Если раньше одно приложение работало на одном сервере, то теперь они состоят из десятков разных микросервисов, и каждому нужна своя база, свой кэш, своя очередь. А ведь еще есть тестовое окружение, staging, CI/CD и много других английских слов. И за все надо платить. Да, по отдельности вроде копейки. Но когда таких сервисов 100 или 200, сумма выходит приличная. Добавим сюда накладные расходы и получим еще минимум 15-25% к счету. А хотелось бы эти деньги оставить у себя в кармане. О том, как это сделать, сегодня и поговорим.
В процессе администрирования веб‑сервера наступает момент, когда нужно протестировать производительность решения, оптимизировать настройки, проверить гипотезу. Для решения этих задач нужно выбрать правильный инструмент для бенчмарка, о чём и будем говорить в этой статье. Все примеры будут разобраны на основе сервера Angie, но могут применяться и к другим продуктам. В этой статье будут освещены простые и доступные утилиты для оперативных тестов.
Объёмы данных продолжают расти, и вместе с ними растёт спрос на системы хранения, рассчитанные не только на годы, но и на десятилетия. При этом привычные носители — HDD, магнитные ленты и оптика — хорошо работают на среднем горизонте, но требуют регулярной миграции и обслуживания, если речь идёт о долгосрочных архивах.
Масштаб проблемы хорошо иллюстрируют оценки International Data Corporation: рост мировой датасферы с 33 зеттабайт в 2018 году до 175 зеттабайт к 2025-му.
Это первая статья из цикла о том, как я пытался сделать алерты Zabbix в домашней лаборатории чуть умнее, прикрутив к ним локальную LLM и не получить на выходе архитектурного монстра Франкенштейна.
В теории хотелось простого: система принимает события мониторинга, понимает их контекст, не дергает лишний раз по пустякам и подсказывает, куда смотреть в первую очередь. Но на практике необходимо начинать не с модели, не с кода и даже не с Docker Compose, а с нормального ТЗ.
В процессе написания материал разросся до неимоверных размеров, поэтому пришлось поделить его аж на четыре части. Ссылки буду добавлять по мере выпуска (примерно раз в одну-две недели).
Часть 1: Вводная и формирование ТЗ -> вы здесь
Часть 2: Выбор локальной LLM
Часть 3: Формирование HLD и немного LLD
Часть 4: Что из этого вышло
«Suricata IPS NFQueue with nDPI» — это значит, что программа suricata работает в режиме IPS с движком NFQueue и поддержкой nDPI.
Традиционные фаерволы могут блокировать нежелательный трафик по IP адресам и портам, но они не способны анализировать содержимое пакетов и обнаруживать сложные атаки, которые маскируются под легитимный трафик. Suricata сильно дополняет возможности классического фаервола — она позволяет блокировать данные на более высоком уровне — на уровне приложений.
Данная информация предназначена для тех, кто хотел бы получить опыт работы с suricata и попробовать ее возможности на практике. Приведенная конфигурация будет рассчитана на минимальное потребление ресурсов. Установка и настройка будут выполняться на ОС Debian 13 с nftables для текущей стабильной версии suricata 8.0.4.
Часть IV содержит:
8. Примеры просмотра данных eve.json в консоли.
9. Просмотр лога, алертов и дропов через web-интерфес.
10. Простой пример использования suricata - блокировка торрентов.
11. Контроль работоспособности и используемых ресурсов.
История инцидента в продакшене: после планового релиза новая версия сервиса не поднялась, а откат на предыдущую версию тоже не помог. Причина оказалась не в коде, а в расхождении между тем, что было описано в Git, и тем, что реально жило в Kubernetes. Ручная правка ConfigMap несколько месяцев существовала только в кластере, пока очередной релиз не пересоздал поды и не вытащил проблему наружу. Разбираю, как мы нашли причину, почему Git не был настоящим источником правды и зачем после этого перешли на GitOps с Argo CD.
150 лицензий на уволенных, сервер под столом без учёта, аудит через месяц. Знакомо? Разобрали 10 российских ITAM-систем: от Enterprise-платформ до сканеров для сисадминов. С таблицей сравнения, баллами и честным дисклеймером — статья в блоге вендора, и мы это не скрываем.
Привет! Меня зовут Антон Касимов, я руководитель Gals Software, а еще сертифицированный тренер и эксперт по Zabbix. В общем, могу сказать, что знаю эту систему чуть больше уровня «видел пару раз интерфейс». Zabbix — одна из самых популярных в мире систем мониторинга. Наверное, не существует компаний с собственной инфраструктурой, у которых не было бы Zabbix. Не так давно мы запустили услугу аудита Zabbix и обнаружили некоторые закономерности, на которые я хотел бы обратить внимание в этой статье. В нашем телеграм-канале Zabbix Recipes мы регулрно делимся нашими находками и публикуем анонсы вебинаров (скоро и по этой теме тоже будет), поэтому приглашаю присоединиться. Я построю повествование так, чтобы вы могли пройтись по статье как по чек-листу и проверить свою инсталляцию на предмет возможных улучшений. Погнали!
Flux CD — это набор инструментов для GitOps в Kubernetes. Он следит за Git-репозиторием и автоматически приводит состояние кластера в соответствие с описанными в нём манифестами и Helm-чартами. Flux работает как контроллер внутри кластера: подтягивает изменения из Git, применяет их через Kubernetes API и отслеживает статус каждого ресурса. Проект является graduated-проектом CNCF.
Когда вы впервые поднимаете GitOps в Kubernetes, Flux CD кажется достаточным: flux bootstrap, манифесты в Git, контроллеры тянут состояние кластера.
Но лучше перейти на Flux Operator:
Да, есть много платных приложений и сервисов, которые сделают всё красиво.
Но этот ручной способ выручит, когда покупать или пиратить недопустимо. Например в организациях.
Это неизбежно должно было случиться: искусственный интеллект докатился и до Linux. Один из самых популярных дистрибутивов, Ubuntu, готовится к внедрению нейросетей. К слову, обсуждение этой новости на официальном форуме вышло настолько жарким, что модераторам пришлось включать медленный режим, чтобы хоть как-то усмирить поток комментариев. Давайте и мы попробуем разобраться что там и как. Поехали!
Анализ DNS-снэпшота OpenINTEL за 2026-01-01
TL;DR. Используя ежедневные DNS-снэпшоты OpenINTEL поверх списка Tranco top-1M, мы собрали ландшафт email-инфраструктуры публичного веба на 1 января 2026 года. MX-записи опубликовали 660 114 доменов, SPF — 616 352, DMARC — 431 133. Дуополия Google Workspace (21.7%) + Microsoft 365 (16.3%) занимает суммарно ~38% receiving-стороны — заметно меньше, чем принято считать в популярных обзорах. На outbound-стороне Amazon SES вышел вперёд по числу авторизованных доменов (5.86%), обогнав SendGrid (4.66%). DMARC опубликован у двух третей SPF-доменов, но 19% всех DMARC-записей — это пустая v=DMARC1; p=none; без отчётов: формальная галочка, а не защита.
Несколько дней назад, 29 апреля 2026 года, вышел Proxmox Backup Server 4.2. Формально это промежуточный релиз: обновили базовую систему до Debian 13.4 Trixie, поставили Linux 7.0 как новый стабильный вариант ядра, добавили ZFS 2.4.1, поправили ошибки и доработали интерфейс. Но по смыслу релиз заметнее, чем кажется: S3-совместимые объектные хранилища стали официально поддерживаемыми, синхронизация между серверами научилась работать параллельно, появились шифрование и расшифровка на стороне сервера для задач синхронизации, а группы резервных копий и пространства имён теперь можно перемещать внутри хранилища.
То есть Proxmox Backup Server постепенно уходит от образа «удобной бэкапницы рядом с Proxmox VE». Он становится отдельным сервером резервного копирования: с дедупликацией, политиками хранения, проверкой целостности, удалённой синхронизацией, S3-хранилищами, лентами и внятной эксплуатационной моделью. Нет, не универсальной заменой всем системам резервного копирования на свете, но очень естественным инструментом для тех, у кого инфраструктура уже построена вокруг Proxmox.
Всем привет. В этой статье расскажу о новостях касаемо Loki. О том что было представлено на GrafanaCON 2026 в Барселоне. Чего нам ждать от новой архитектуры Loki, как она будет работать, и что прячет под капотом.
Всем привет! Храню 7 терабайт фото и видео у себя дома на Synology DS224+ с DSM 7.3+
Это сетевое хранилище поддерживает Docker. Я дополнительно установил плашку памяти и теперь у меня 18 ГБ ОЗУ.
Но суть в том, что ночами я слышу "булькание" и "шуршание" дисков, кстати диски красные, прямо созданные под сетевые хранилища: WD120EFBX-68B0EN0 две штуки по 12 ТБ с зеркалированием.
И у меня возник такой страх, а что если мои файлы что-то форматирует, а я просто лежу и не знаю об этом. И я начал поиски репозиториев на GitHub, посмотрел как делают другие, мне как обычно ничего не подошло и я решил создать свой проект, который полностью меня устраивает.