Если мониторинг показывает, что ЦП большую часть времени в простое, а оперативка не выбивается из нормальных значений, значит, узкие места нужно искать в других подсистемах. В статье расскажу про основные причины заторможенности Linux-сервера и как проверить, есть ли они у вас.
Привет, Хабр! Меня зовут Рома Корчагин, я занимаюсь внедрением процессов безопасной разработки в продукте «Штурвал» от «Лаборатории Числитель». Наша платформа позволяет создавать сотни кластеров и управлять ими силами небольшой команды.
Считается, что практики DevOps действительно ускоряют разработку, но классические методы безопасности за этим прогрессом не успевают. В этой статье я расскажу, можно ли автоматизировать внедрение Sec в DevOps и при этом снизить нагрузку на разработчиков. Разберём четыре основных подхода — и отдельно поговорим про Shift-Down Security, который, на мой взгляд, отлично закрывает недочёты остальных.
Мы немного в когнитивном диссонансе, потому что история дикая и сделать правильно в ней явно будет неправильно. Сейчас объясню, но сначала хронология обращений в поддержку VDS-хостинга.
В один прекрасный день в техподдержку прилетает тикет. Пишет человек, что его почта была взломана и он утерял доступ к своему аккаунту. Пишет с личной почты с публичного сервиса типа @mail.ru.
Аккаунт зарегистрирован на почту внутри домена, домен и сервер, соответственно, скомпрометированы, по всей видимости. Просит восстановить доступ к серверу и перевязать всё на его личный ящик.
Мы, естественно, на слово не верим. Запросили дополнительные документы: паспорт и всё возможное, связанное с аккаунтом. Он присылает скан паспорта. ФИО в паспорте совпадает с данными в профиле аккаунта. Во-вторых, самое главное — банковские чеки и квитанции об оплате этого самого сервера за последние месяцы. Мы смотрим: документы в порядке, деньги платил именно он. Ситуация штатная: человек — назовём его первым человеком-пауком — потерял почту, подтвердил личность, подтвердил оплаты. Мы переносим аккаунт на его личную почту и отдаём доступ.
И тут с почты внутри домена приходит такой же тикет, только на другое имя. Мол, утерял доступ, верните.
…Был обычный ноябрьский вечер, 2024 год шёл к своему завершению: на носу была «чёрная пятница». Я вернулся домой в Новосибирск из почти двухнедельной командировки, пробыв в пути 12 часов и поспав часа четыре. В 19:07 алерт сообщил мне о падении одного из контроллеров. В целом, проблема не критичная, так как сервисы зарезервированы. Но всё же одним глазом я заглянул в чат с разбором.
Через час ситуация стремительно ухудшилась: каскадом начали отказывать узлы, отвечающие за внешнюю связность. А затем развитие событий приняло фатальный оборот — в какой‑то момент одновременно отказали сервисы внешней связности сразу в двух зонах доступности…
Это был один из самых крупных региональных инцидентов в облаке, после которого мы многое изменили в сети, чтобы сделать её устойчивее. С того момента прошло больше года, так что пришла пора рассказать эту историю от начала и до конца.
В прошлой статье я уже показал наши основные подходы к повышению отказоустойчивости в этой ситуации. Однако за кадром остался сам процесс разработки новых решений и то, как мы мыслили, чтобы найти наилучший выход. Сегодня расскажу об этом подробнее. Статья основана на моём недавнем выступлении на Highload++ и дополнена по следам дальнейших расследований инцидентов.
Приобрели недавно ПО Лоцман:КБ и в процессе установки появилась необходимость развернуть под нее PostgreSQL как сервер БД
На первый взгляд - "делов на 5 минут", но как выяснилось спустя пару дней - "есть нюанс" :)
1. Развернули через стандартный docker-compose
В этом цикле статей мы подробно рассмотрим технологию LUKS с позиции системного администрирования и способы защиты мастер-ключа, в том числе и с использованием алгоритмов ГОСТ Р 34.10-2012 на Рутокен ЭЦП 3.0. Материал прошел обсуждение в фокус-группе нашего сообщества ALD Proфессионалов и будет включен в содержание открытого курса по службе каталога ALD Pro. Возможности повысить квалификацию в объеме 16 академ. часов не обещаем, но вкусных буковок будет много.
Привет, Хабр! Сегодня начинаем долгий и подробный разбор уровней зрелости IT-организации. Это не просто теория — это практический гайд для CTO, IT-директоров и руководителей, которые хотят понять, где сейчас находится их компания и как двигаться вперёд.
Начнём с Level 0 — состояния полного хаоса. Если вы узнаёте свою компанию в этом описании, не паникуйте. Level 0 — это не конец света, это просто стартовая точка, и есть чёткий путь отсюда.
По оценкам iKS-Consulting, в 2018 году платформу VMware использовали 78,8% компаний, которые применяют виртуализацию. Весной 2025 года в аналогичном исследовании указано, что доля отечественных решений в ПО виртуализации достигла 60,2%, а доля VMware оценивается в ~39% (оценка по данным анализа 19 крупнейших российских облачных провайдеров). То есть VMware-решения все еще заметны, но уже не доминируют так, как несколькими годами ранее
За несколько лет VMware в России прошла путь от «платформы по умолчанию» среди тех, кто виртуализирует, до одной из заметных, но уже не ведущих опций. Рынок быстро перераспределяется в пользу отечественных платформ — ради доступности поддержки и обновлений, управляемости процессов и соответствия требованиям в российских контурах.
В этой статье разберемся, как выбрать платформу виртуализации. Для этого вспомним краткую историю VMware и сравним подходы и классы платформ (On-Prem и у провайдера) с точки зрения эксплуатации, безопасности и миграции. В конце вас ждет чек-лист требований (включая ИБ/комплаенс) и таблица выбора по сценариям, чтобы быстро отсеять неподходящие варианты и собрать план перехода без сюрпризов на согласованиях с ИБ.
Статья описывает практический переход от физической к логической сегментации сети на примере сети небольшого предприятия с тремя зданиями.
Решаем задачу организации гостевого доступа в новом месте без изменения физической инфраструктуры. Для решения используется технология VLAN, что позволяет гибко перераспределять сетевые сегменты независимо от физического расположения оборудования.
Coolify — это популярная open-source платформа для хостинга приложений на своем сервере.
В первой части нашего руководства по Coolify мы провели подготовительную работу — приобрели VPS, настроили файрвол для него, взяли домен и прописали DNS.
А в этой части мы наконец переходим к самому Coolify — разберемся, как установить его на сервере и настроить для дальнейшей работы. Чтобы в следующей третьей части уже перейти к деплою приложений.
Когда проект вырастает из простых задач, каждый повторный запрос к базе данных превращается в бесполезную нагрузку на диски и процессор. И вместо того чтобы заставлять систему раз за разом искать, фильтровать и считывать одни и те же данные, логичнее отдавать их напрямую из оперативной памяти.
В этой статье разберем, как эффективно внедрить слой кэширования на связке Redis + Spring Boot 3 / Java 21.
Пробежимся по базовым командам Redis, реализуем cache‑aside вручную и через аннотации Spring Cache, а затем разберем два полезных паттерна для микросервисов: Fixed‑Window Rate Limiter и распределенный лок. Не пугайтесь сложных терминов, все понятным языком рассказал под катом.
Уведомления в информационных системах представляют собой способ информирования пользователей о событиях, изменениях или запросах в системе. Они могут быть представлены в виде писем на электронную почту, текстовых сообщений, звуковых сигналов, всплывающих окон и других форм. Однако, существует несколько проблем, которые могут негативно сказаться на опыте пользования системой, особенно в тех системах, где функционал уведомлений играет важную роль в организации рабочего процесса.
Цель статьи – выявить и проанализировать эти проблемы, результатом станет ответ на вопрос: как улучшить взаимодействие с уведомлениями и использовать их наиболее эффективно в информационных системах? Как пример информационной системы рассмотрим «среду общих данных» строительных проектов. Также эта статья будет полезна специалистам, которые находятся в процессе выбора системы.
Цель этой статьи — восполнить пробел в документации связки Strimzi Kafka и мониторинга. У Strimzi есть раздел про метрики и Prometheus и примеры в репозитории (examples/metrics/prometheus-install), но они рассчитаны на общий Prometheus Operator; пошагового руководства именно под Helm-чарт kube-prometheus-stack (с порядком установки и нужными label’ами) в открытом доступе не нашлось. Ниже — собранный и проверенный вариант такой установки.
При проектировании инфраструктуры часто возникает задача поднять кластер «с чистого листа». Безусловно, Terraform и Ansible — это стандарт индустрии. Однако мне нужен был процесс быстрого получения готового кластера K8s, полностью независимый от локального окружения, чтобы запуск не требовал предварительной подготовки версий библиотек, интерпретаторов или наличия локальных файлов конфигурации.
В этой реализации я намеренно упростил работу с конфигурацией: параметры виртуальных машин (CPU, RAM, диски) описаны прямо в коде (см. config.go). Я решил, что проектирование гибкой системы внешних конфигов можно оставить на потом, чтобы на данном этапе не отвлекаться и сфокусироваться на главной задаче — отладке самого механизма восстановления и связности компонентов.
Я реализовал подход полной автоматизации с использованием технологий, которыми увлекаюсь. Суть проста: на машине CI-раннера нет ничего, кроме одного бинарного файла. Всё состояние кластера (IP-адреса, ID дисков), дампы баз данных и зашифрованные секреты хранятся в S3. Это позволяет восстановить кластер в исходное состояние даже после полного удаления, просто вытянув актуальное состояние из облачного хранилища.
В этой статье я поделюсь опытом создания кастомного CLI для подготовки инфраструктуры и использования FluxCD для развертывания приложений. А для проверки результата я использую Yandex Cloud Managed Kubernetes, чтобы запустить K6 Operator и дать внешнюю нагрузку в 1000 пользователей на восстановленные сервисы.
Всегда ли вы понимали как работать с устройствами в Linux?
Задавали себе вопрос "А что в пути забыли ссылки?"
Или хотели знать, как в Linux представлены USB-устроства на уровне системы?
В этой статье я разбиаю как работать с внешними устройствами, для чего нужна директории /sys и /dev, как представлены в системе USB-устройства и cd-диски.
Клиенты часто спрашивают, как построить геораспределенный и катастрофоустойчивый Kubernetes. Так, чтобы при отказе целого дата-центра нагрузка переключалась на резервную площадку без смены IP-адресов сервисов.
Можно возразить, что проще изменить DNS-запись и направить трафик на инстанс в другом дата-центр. Но есть риск: кэширование на рекурсорах некоторых провайдеров может негативно повлиять на доступность. Они иногда игнорируют TTL и хранят старые данные неопределенный срок. Поэтому в таких сценариях крайне желательно сохранить IP-адрес.
Один из элементов «мозаики» такой геораспределенной системы — балансировщик нагрузки с возможностью использования адресов из anycast-подсети, которую выделяет поставщик услуг. В этой статье мы не будем затрагивать вопрос передачи данных и их консистентность на двух разных площадках — разберем только сетевую составляющую. Подробности под катом!
Мы уже писали о нагрузочном тестировании машины баз данных Tantor XData 2Y на базе процессоров Intel, точнее, об успешно пройденном тесте на 30 тыс. пользователей 1С. Впечатляющие показатели — это прекрасно, однако реальность рынка enterprise-решений такова, что технические характеристики — не единственный критерий для выбора оборудования. Требования 398-ФЗ, стратегии импортозамещения, санкционные риски и бюджетные ограничения заставляют компании искать баланс между производительностью и другими факторами.
В линейке Tantor XData есть модель 2B на базе процессоров Baikal-S, позиционируемая как ответ на подобные вызовы. В новой статье мы делимся результатами нагрузочного тестирования этой модели и рассказываем об особенностях работы ARM-архитектуры с PostgreSQL и практическом опыте оптимизации такой системы — со всеми техническими деталями, метриками производительности и найденными узкими местами.
Кому эта статья может быть полезна?
Многие сегодня припарковали свои проекты на виртуальных серверах типа vps/vds или физическом сервере. И вот, по каким-то причинам, вы не хотели бы показывать свой код напрямую.
Если вы уже знаете про GitLab runner, Docker и registry – то можно пройти мимо и сберечь свое время. А кто не знает - добро пожаловать. Постараюсь, чтобы было не сложно.
Какие могут быть причины?
Привет, Хабр! Меня зовут Данила Трусов, я директор продукта «Инферит ИТМен». В этом посте хочу рассказать, что именно мы сделали в версии 6.5 и почему эти изменения важны для команд, которые работают с распределенной и неоднородной инфраструктурой.
«Инферит ИТМен» — это система учета и контроля ИТ-активов. При развитии продукта мы в первую очередь ориентируемся на практические сценарии эксплуатации: большое количество узлов, разные типы устройств, нестандартные источники данных и ограниченные ресурсы ИТ-служб. В версии 6.5 мы сделали очередной шаг в эту сторону.
Когда на сервере появляется «прожорливый» процесс, который забирает все ядра и постепенно выдавливает память, хочется ограничить его быстро — но так, чтобы это было воспроизводимо и не держалось на магии.
В статье — практический разбор cgroups v2: как руками через cgroupfs создать группу, задать лимиты CPU/RAM и правильно запускать процессы без «окна без ограничений», а затем сделать то же самое через cg*-утилиты и systemd-run/slice. По дороге станет ясно, почему эти приёмы напрямую перекладываются на мир Docker и Kubernetes.