Привет, Хабр! Статья не входила в планы, пишу с чувством лёгкой сюрреалистичности. В воскресенье утром наш основной API-гейтвей пережил маленькую апокалиптическую битву с памятью и выиграл без моего участия. Делюсь с Вами, как небольшой скрипт, на который я не полагал абсолютно никаких надежд, отработал аварию.
Влагозащищенный и пыленепроницаемый DECT-телефон Gigaset R700H PRO со степенью защиты IP65 — это надежное и многофункциональное устройство, которое стабильно работает под прямым потоком воды (под дождем), в условиях повышенной влажности или в пыльных производственных помещениях.
Знаете, этой статьи могло и не быть. Если бы не один случай, который меня так взбесил, что пришлось искать решение.
Автомасштабирование узлов кластера Kubernetes и горизонтальное масштабирование подов позволяют быстро расширить ресурсы при пиковых нагрузках. Но сложные приложения могут не нагружать поды или узлы максимально, но требовать дополнительных ресурсов, например, для параллельной обработки нескольких объектов в очереди. Триггером масштабирования кластера может быть не утилизация, а события от внешних систем — например, очереди сообщений Kafka, системы мониторинга Prometheus или от платформы CI/CD.
Всем привет! Меня зовут Илья Смирнов, я архитектор решений в Cloud.ru. Расскажу, как лучше справляться с пиковыми нагрузками, если вы развернули свое приложение в кластере Kubernetes. Вместе запустим такое демо-приложение и посмотрим, как с ним работают классические подходы автомасштабирования — в этой части, а затем попробуем масштабировать кластер по событиям с помощью KEDA (Kubernetes-based Event Driven Autoscaler) — в следующей. Не пропустите!
VDS/VPS берут в том случае, когда нужен контроль над сервером и гарантированные ресурсы. Но сценарии использования всегда различаются — кому-то нужен интернет-магазин, кому-то почтовый или игровой сервер, а кто-то вовсе хранит там архив с фото своего кота. Под катом я собрал типичные кейсы и советы о том, на что смотреть при выборе VDS под конкретные задачи. Приглашаю.
Поделюсь опытом практического применения приложения UltraVNC для доступа к рабочим столам пользователей. Не серверов. Пользователей. Статей на эту тему даже очень много, но все они представляют собой вольные переводы мануалов с излишне подробными демонстрациями инсталлятора.
Как часто в своей работе вы задумываетесь о необходимости обеспечения удаленного доступа для пользователей? Как на счет 100% бесплатных решений?
Да, такое мы все любим, но уж очень невелик выбор подобных решений под Linux...
Когда я только начинал работать, 100% аптайма казались мне священным граалем. Казалось: если сервис никогда не падает — пользователи счастливы, бизнес доволен, инженеры спят спокойно. Но реальность быстро показала: каждая дополнительная «девятка» стоит всё дороже, а выгоды становятся всё менее заметными. В статье делюсь опытом: почему гонка за идеальной надёжностью — тупик, как помогает концепция Error Budget и почему лучше найти баланс между стабильностью и развитием.
Делимся опытом трансформации нашей инфраструктуры: от децентрализованных экземпляров Foreman с публичными IP до защищённой, изолированной архитектуры с централизованным управлением через GitLab, повышенной безопасностью и легкой масштабируемостью.
Представьте типичное утро понедельника в ИТ-отделе: вы открываете систему тикетов и видите десять одинаковых заявок: «После вчерашнего обновления macOS перестал работать [важный корпоративный софт]».
Если это звучит знакомо, не паникуйте, вы не одиноки. Apple постоянно выпускает обновления безопасности и новые версии ОС, о чём она напоминает даже в документации: «поддержка актуального ПО – одна из самых важных задач для поддержки безопасности Mac». Однако в корпоративной среде эта же надёжность может обернуться головной болью для админа. С одной стороны, пропуск обновления может оставить дыры в безопасности; с другой – каждое обновление сопряжено с рисками несовместимости с бизнес-приложениями, скриптами и оборудованием.
В этом руководстве мы разберёмся со всеми основными инструментами и техниками по управлению обновлениями macOS. Материал построен по принципу от простого к сложному: начнём с базовых компонентов системы обновлений, затем — разбор softwareupdate и defaults, рассмотрим MDM-профили, а также методы блокировки и оптимизацию доставки обновлений.
Привет, Хабр! Я Станислав Габдулгазиев, архитектор департамента поддержки продаж Arenadata. Кажется, ещё вчера мы радовались возможностям Apache Spark 3.0, разбирались с Adaptive Query Execution и наслаждались улучшениями Pandas API. Но мир больших данных не стоит на месте, и вот уже на подходе Apache Spark 4.0. Новый мажорный релиз — это всегда событие: он обещает новые фичи, прирост производительности и, конечно же, новые вызовы при миграции.
Apache Spark де-факто стал стандартом для распределённой обработки данных. От классических ETL-пайплайнов и SQL-аналитики до сложного машинного обучения и стриминга — Spark так или иначе задействован во многих современных data-платформах. Поэтому каждый новый релиз вызывает живой интерес у комьюнити: что там под капотом? Какие проблемы решены? Не сломается ли то, что работало годами?
Теоретическую основу кэширования DNS в Linux мы разбирали в первой части, где говорили про работу процесса разрешения имен — от вызова getaddrinfo() до получения IP-адреса. Вторая часть была посвящена различным уровням кэшей самой системы, приложений и языков программирования, контейнеров, прокси - а также их мониторингу и сбросу. Теперь самое время перейти к практике.
Если вы когда-либо запускали подряд команды ping, curl, dig и получали разные IP-адреса, вы не одиноки. Поведение DNS в Linux — не просто вызов getaddrinfo(). Это взаимодействие множества слоёв: от glibc и NSS до NetworkManager, systemd-resolved, dnsmasq и облачных конфигураций. В этой части разберем практические аспекты DNS:
почему одинаковые запросы дают разные IP
как реально контролируется разрешение имен: что вызывает кого и зачем
как проводить диагностику: strace, resolvectl, tcpdump
Даже самые надёжные и отказоустойчивые системы иногда могут преподносить неприятные сюрпризы. Что уж говорить про обычные VPS-сервера и запущенные на них проекты. Рано или поздно может случиться ситуация, когда сайт или какой-то сервис «упал». Причины бывают разные: от внешних (например, сбой у провайдера или проблемы на стороне хостинга) до внутренних — ошибка в коде, нехватка ресурсов или некорректные настройки.
К таким ситуациям важно быть готовым заранее. И лучший способ — настроить мониторинг, который будет следить за работой сервисов и вовремя оповещать вас, если что-то пошло не так.
Один из удобных инструментов для этого — Uptime Kuma. Это относительно молодой (по сравнению с «тяжеловесами» вроде Zabbix) проект, который активно развивается, прост в установке и отлично подходит для новичков.
В этой статье мы разберёмся:
Впасть в зависимость от облачных сервисов в корпоративном сегменте довольно просто. Сначала ты просто переносишь пару приложений для тестов, потом соглашаешься на расширенный план, и вот уже через год IT-директор хватается за голову от счетов, которые выросли в несколько раз. Хуже всего, что с течением времени сервисов становится только больше, команды разворачивают новые проекты, а контроля за тратами как не было, так и нет. Кто запустил эти 50 инстансов? За что платим 200 тысяч в месяц? Почему расходы на машинное обучение выросли втрое?
В таких условиях FinOps перестает быть просто модным термином, становясь, по сути, единственным рабочим способом вернуть контроль над IT-бюджетом. Остается самая малость – доказать руководству, что эти инвестиции окупятся. А тут без конкретных метрик и четкого расчета ROI не обойтись.
Сегодня официально выпустили новую версию Kubernetes — 1.34. Собрали обзор со всеми изменениями. Среди главных нововведений — отслеживание здоровья устройств при DRA, тонкая настройка рестарта контейнеров в подах, асинхронная обработка API-вызовов, нативная доставка сертификатов X.509 в поды и новая разновидность YAML для описания конфигураций.
Мы все были в ситуации, когда нужно показать экран с множеством окон, и требуется несколько минут перед нажатием кнопки «Поделиться экраном», чтобы принять решение. Это нормально, особенно если ваша система — ваш второй (или даже первый) дом: с личными заметками, документами, паролями, чатами и так далее.
Далее мы настроим удобный рабочий процесс для такого случая. Однако эта настройка будет использовать новую функцию, встроенную в Hyprland и, скорее всего, отсутствующую в других DE/композиторах. Я продемонстрирую нашу конечную цель. Например, мой режим демонстрации экрана может выглядеть так:
Привет, Хабр! Меня зовут Александр Бардаш. Я CTO в MWS Octapi — это интеграционная платформа МТС Web Services, которая объединяет все возможные способы взаимодействия между системами в экосистеме компании. В ней используется подход Event Mesh — технология, которая позволяет обрабатывать данные в реальном времени и обеспечивает безопасность, производительность и управляемость. Сегодня предлагаю посмотреть, как все это работает.
Этот текст — переработка моего доклада с HighLoad++. Устраивайтесь поудобнее, читайте и задавайте вопросы в комментариях, на все постараюсь ответить.
В корпоративной среде часто возникает задача раздать сертификаты ЭЦП всем сотрудникам. Стандартные методы certutil и Import-PfxCertificate не всегда работают: приложения вроде СБИС не видят такие сертификаты. В статье рассказываю, как автоматизировать распространение с помощью PowerShell и GPO — с заменой SID, импортом в реестр и копированием файлов.
Детективная история о том, как к одному из наших партнеров ГК IT Expert пришла торговая сеть с пропажей 200 компьютеров в CMDB. И как получилось их найти с помощью интеграции с ИТМен-Вентурой.
Когда я только начинал дежурить, телефон ночью был моим главным врагом: PagerDuty вырывал из сна десятки раз, а инциденты превращались в хаос. Со временем я понял, что on-call можно превратить в предсказуемый процесс — с правильными алертами, runbook-ами и командной культурой. В этой статье расскажу, как я перестал бояться алертов и научился относиться к дежурствам спокойно. Будет личный опыт, фейлы и практические советы