Когда я только начинал работать, 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-ами и командной культурой. В этой статье расскажу, как я перестал бояться алертов и научился относиться к дежурствам спокойно. Будет личный опыт, фейлы и практические советы
Привет, Хабр! Думаю, многие сталкивались с необходимостью генерации тысячи пользователей. Вручную - не вариант, слишком долго. В данной статье разберу библиотеку Faker. Это генератор реалистичных тестовых данных, который превращает заполнение базы и создание демо-контента из рутины в дело пары строк кода. В статье продемонстрирую, как генерировать тысячи правдоподобных записей на русском, заполнять БД и создавать собственные типы данных для ваших проектов.
Привет, Хабр!
Сегодня расскажем не столько о решении — оно оказалось простым – сколько о самом процессе его поиска. Он был настолько увлекательным, что в какой-то момент мы почти уверовали в существование магии. Но мы — инженеры, а поэтому как никто знаем, что чудес не бывает. Поэтому, откинув домыслы и иррациональность, мы шаг за шагом распутывали этот технический узел, докапываясь до первопричины проблемы. Приступим же к нашему расследованию. Приятного чтения!
Когда я только начинал работать с инфраструктурой, всё выглядело как бесконечный пожар: сотни алертов, ночные звонки, хаотичные релизы и нервы на пределе. Мы гасили инциденты вручную, но проблема возвращалась снова и снова.
Ситуация изменилась, когда я познакомился с практиками SRE: SLO, SLI и error budget. Они помогли превратить хаос в систему и объяснить бизнесу надёжность на понятном языке. Теперь вместо бессмысленного «сервис упал!» мы обсуждаем конкретные цифры: сколько бюджета ошибок потрачено и когда можно катить релиз.
В этой статье расскажу, как мы внедрили наблюдаемость на основе golden signals, научились писать постмортемы без поиска виноватых и встроили задачи по надёжности прямо в бэклог. Всё — из реальной практики инженера, который за год прошёл путь от «тушения пожаров» к спокойной работе с прогнозируемой стабильностью.
Теперь ресурсы контейнеров в Kubernetes можно менять «на лету» — без перезапуска и простоев. В статье рассказываем, как работает in-place resize, где эта функция реально спасает приложения от перегрузки и какие ограничения стоит учитывать на практике.
Привет! Меня зовут Андрей Колесников, я тимлид одной из DevOps-команд Авито. Уже 10 лет я работаю с высоконагруженными и бизнес-критичными системами. В этой статье рассказываю, как мы управляем нашей инфраструктурой с помощью Puppet, и объясняю, почему мы продолжаем его использовать.
Привет Хабр! Меня зовут Юлия Воробьева, и уже больше 10 лет я занимаюсь тестированием. За это время успела поработать в проектах, связанных с восстановлением, миграцией и резервным копированием данных. Я много занимаюсь облачными технологиями и получаю от этого настоящее удовольствие. Последние 6 лет я работаю в компании Хайстекс, где продукт и задачи позволяют мне не просто тестировать, а прокачивать экспертизу и при этом сохранять интерес к облачным решениям.
В этой статье расскажу, как мы настроили, внедрили и протестировали резервное копирование с решением Хайстекс Акура и S3-хранилищем от Selectel, на основе реальных требований и возможностей компании-клиента. Покажу, как это выглядит на практике глазами QA.
Не претендую на универсальный рецепт, но подробно опишу, как мы упростили восстановление тестовой среды, сэкономили время и перестали бояться, что важные данные потеряются после очередного сбоя. Разберу всё по шагам: как настраивали, что сработало, где пришлось доработать и какие выводы сделали в итоге. Если вам интересно, как внедрить надежный бэкап всех данных у себя в компании, встретимся под катом. Там же ссылка на вебинар для тех, кому ближе видеоформат.
Вам когда-нибудь хотелось создать собственный системный вызов? Может быть, вы получали такое домашнее задание, пытались сделать это из интереса или просто для того, чтобы узнать что-то новое о ядре. В любом случае, системные вызовы – крутая штука, чтобы подробнее разобраться в Linux.