На кону финансовые данные клиентов, а странный и неуловимый баг в Cilium не даёт как следует настроить сетевую безопасность.
Статья о том, почему любая «нерешаемая» проблема — это «пока недостаточно изученная» проблема. От случайных догадок — к системному исследованию и пул-реквесту с фиксом прямо в Linux.
Эта статья о проблемах, с которыми сталкивается инженер при попытке объединить зоопарк старого оборудования с современным подходом к его мониторингу. Современный мониторинг строится вокруг динамических сущностей: микросервисы, контейнеры, оркестрация в Kubernetes, сбор метрик через Prometheus и визуализация в Grafana. В этой парадигме всё динамично меняется и обычно разговаривает на языке /metrics и OpenTelemetry. Для инженера это привычная и удобная экосистема, где работают автообнаружение и pull-модель которые позволяют забыть о ручном конфигурировании целей сбора.
Почему Debian 9, PHP 7.0 и никаких фреймворков. И как поднять HTTPS за 5 минут
Предисловие для тех, кто не читал первую статью
В прошлый раз я рассказал, как хотел сделать две странички для SAMBA и NFS, а получилась панель управления NAS на 20+ страниц. Проект назвал Mini Bucket.
Важно: та версия была бета. Сырая, с недоработками, но живая. Её задача — показать концепцию. А народ заинтересовался. Значит, надо доводить до ума.
Теперь — версия 3.6.2. Исправлена куча проблем, добавлена безопасность, появился отдельный домен, форум и вики. И сегодня я по шагам покажу установку со скринами.
Но сначала — кратко о том, что изменилось. А потом — чистая практика....
Вокруг любой технической системы накапливаются артефакты трёх видов: числа, по которым о системе судят, утверждения о её свойствах и действия в ответ на отклонения. Разница между инженерией и деятельностью, внешне на неё похожей, видна по устройству этих артефактов и в каждом случае сводится к одному вопросу.
1. Введение
Всем привет! Меня зовут Яблоков Олег, я — ведущий инженер ИТ-отдела Navio и отвечаю за систему мониторинга основной инфраструктуры компании. Это работа на стыке разработки и эксплуатации (development & operations, DevOps), наблюдаемости (Observability) и обеспечения надёжности сервисов (Site Reliability Engineering, SRE). Моя основная задача не просто собирать метрики, а сделать так, чтобы по ним можно было быстро понять статусы сервисов и не утонуть в шуме оповещений.
Когда я пришел в компанию около года назад, система мониторинга уже существовала и закрывала базовые задачи. В наборе технологий использовались Prometheus, Thanos, Alertmanager, Grafana, Elasticsearch и различные наборы оповещений. Со временем количество компонентов и инструментов увеличилось, что усложнило их сопровождение и масштабирование.
В этой статье я расскажу, как происходила миграция мониторинга в Kubernetes, почему в качестве основной базой данных временных рядов (Time Series Database, TSDB) была выбрана Victoria Metrics, как мониторинг связали с Gitlab и Argo CD, пересобрали систему оповещений (alerting) и начали постепенно двигаться от инфраструктурного мониторинга к сервисному подходу и практикам обеспечения надёжности сервисов (Site Reliability Engineering, SRE).
2. С чего все начиналось.
Изначально мониторинг представлял собой связку Prometheus, Thanos, Alertmanager, Grafana и Elasticsearch. Разворачивалось все через Docker Compose на отдельных серверах, а сама система постепенно росла вместе с инфраструктурой.
Docker уже давно перестал быть «модной новинкой» и превратился в минимум для любого бэкендера, DevOps-инженера или QA. Строчка с Docker есть почти в каждом резюме, поэтому на собеседованиях технические специалисты любят копать глубже.
Вызубрить десяток флагов для docker run — недостаточно. Интервьюеры хотят видеть, что вы понимаете саму архитектуру контейнеризации: как работает изоляция процессов, почему данные внезапно исчезают после рестарта, чем слои отличаются от томов и что будет, если PID 1 внутри контейнера завершит работу.
За полтора месяца после релиза я добавил в свой iOS-апп 9 сетевых инструментов — и почти каждый оказался отдельной задачей: параллельный MTR, Path MTU на ICMP Echo, детект блокировок по SNI. Делюсь самыми интересными граблями и кодом.
ИИ пишет код, разбирает тикеты, лезет в автоматизацию — и всё ближе к продакшену. Но рядом с инфраструктурой еще не значит внутри нее. В рамках юбилейной серии SpaceWeb — 25 лет на рынке — мы поговорили с экспертами компании о том, где у ИИ-агента заканчивается роль помощника и начинается роль администратора.
3 июня 2026 года Эндрю Триджелл, один из авторов rsync (и создатель Samba), написал пост, перевод которого предлагается ниже. Поводом стала волна негодования после релиза rsync 3.4.3, в котором закрыли шесть уязвимостей: пользователи начали сообщать о регрессиях, из‑за которых ломались уже работающие конфигурации и сценарии, годами считавшиеся привычными, надежными, рутинными.
Можно было бы сказать «бывает», но масла в огонь подливал тот факт, что незадолго до этого в истории коммитов rsync появилось около пятидесяти изменений, подготовленных с помощью Claude. На этом фоне любые сбои почти автоматически стали читаться как «в важный инфраструктурный проект пустили ИИ, и он нагенерировал плохие исправления» — сами понимаете, как к такому сейчас относится ИТ‑сообщество.
В списке того, что поломалось, были и инкрементальные бэкапы с несколькими --compare-dest, и сборка на старых ядрах Linux и старых версиях macOS, и поведение --link-dest, и другие привычные сценарии. Триджелл ответил не тредом в комментариях, а отдельной заметкой в своём блоге на Medium — местами раздраженной, местами ехидной, но ценной именно тем, что это взгляд опытного инженера, который сейчас реально держит на себе проект.
В этот прекрасный июньский день хочется немного выдохнуть: фичи доделаны, образы залиты, регресс пройден, в наушниках играет приятная музыка, а впереди целое лето и каникулы.
С вами снова я — Павел Мирошин, тимлид команды разработки «Графини» (первый аналог Grafana, написанный с нуля). И сегодня хочу немного рассказать о том, что мы сделали в новом большом релизе 2026H1 «Ассамблея».
Внутри про кеширование витрин, прогнозирование, импорт дашбордов из Grafana и другие обновления.
Мы пройдем по самым интересным техническим граблям создателей сети: от концепции «Галактической сети» Ликлайдера до первого в истории упавшего сервера и того дня, когда интернет чуть не стерла уборщица с пылесосом в CERN. Разбираемся, как зоопарк несовместимых машин превратился в нервную систему планеты.
Привет Хабр! Это снова Дмитрий Закорючкин из компании Avanpost, и сегодня я продолжаю рассказывать про нашу службу каталогов — Avanpost Directory Service. Я уже писал про наш подход к групповым политикам, а мой коллега освещал такую важную тему как устройство бекенда каталога. Темой сегодняшней статьи станет контроль доступа в Avanpost DS (не ролевая модель — это тема для отдельной статьи, а именно механизмы контроля доступа).
Передача АV-сигналов на основе технологии AVoIP (Audio Video over IP) постепенно вытесняет классическую коммутацию: маршрутизация по Ethernet более удобна и масштабируема по сравнению с матричной, ограниченной количеством портов коммутатора. Однако помимо озвученных преимуществ она наследует уязвимости IP-сетей.
Согласно данным AVIXA(Ассоциация Аудиовизуального и Интеграционного Опыта), инциденты в AVoIP инфраструктуре, связанные с сетевой безопасностью, происходят по весьма банальной причине: зачастую AV‑инженеры не считают себя сетевыми специалистами, а IT‑отдел не контролирует AV‑сегмент.
В этой статье разберем, чем обоснован переход от классической матричной коммутации на AVoIP, узнаем причины возникновения и ключевые уязвимости, а также основные методы защиты.
Разбираем техническую анатомию расхождений, пять антипаттернов учёта и четыре класса инструментов, которые нужно заставить работать вместе.
Я срьрал 100+ вопросов с собеседований по Rust с краткими разборами: владение, типажи, конкурентность, async, unsafe, производительность и др. Отдельный продвинутый блок A1–A21 для staff-уровня. Цель - показать, где обычно спотыкаются даже опытные, и помочь подготовиться к следующему собеседованию. Надеюсь будет реально полезно!
Около месяца назад я решил испытать один интересный технический сценарий организации кабельного скоростного канала передачи данных между двумя компьютерами/ноутбуками. Речь о штатной возможности Thunderbolt 3/4/5 портов работать в так называемом режиме Thunderbolt Networking. Суть этого способа кабельной передачи в следующем:
Попытался структурировать всю эту прекрасную линуксовую фрагментацию и собрал «айсберг» дистрибутивов
Если у вас пет-проект или небольшой стартап на GitLab.com, рано или поздно вы упрётесь в потолок бесплатного тарифа: 400 минут пайплайнов в месяц и общая очередь раннеров. Покупка дополнительных минут стоит денег и не решает вторую проблему: общие раннеры GitLab обслуживают миллионы проектов, и в часы пик ваша джоба может провисеть в очереди 10-20 минут.
Решение — свой GitLab Runner на VPS: без чужих джоб, под полным контролем. Такой раннер не имеет лимитов по времени, кроме ресурсов самого сервера. В статье за вечер собираем такой раннер с нуля на Ubuntu 24.04 LTS, поднимаем пайплайн на три стадии (тесты, сборка Docker-образов, пуш в GitLab Container Registry), добавляем кэширование, безопасность и автообновление.
Всем привет, меня зовут Илья и я хочу вам рассказать как я после небольшой правки в тераформ я потерял все мастера в кластере Elasticsearch. ЧатГПТ и гугл уже принесли мне лопату чтобы похоронить эти сервера, но начальство сказало: "Может что нибудь придумаешь?". В итоге 6 часов работ и кластер снова живой и зеленый. Хотите знать больше?
Продолжаем серию «Адаптивное администрирование Sigla Vision». Разберем кейсы, где триггеры в базе FineDB помогают решать задачи администрирования Sigla Vision.
Привет, Хабр! Меня зовут Всеволод Коваленко. В Газпромбанке я занимаюсь развитием функционала BI-системы на базе Sigla Vision.
В предыдущей статье «Версионирование таблиц репозитория метаданных Sigla Vision» мы разобрали исторические таблицы, которые хранят данные о состояниях записей в БД. Версионирование таблиц мы тоже строили на триггерах FineDB. Теперь покажем, как те же триггеры решают еще ряд задач администрирования Sigla Vision.