CPU Isolation: исследование в шести частях о применение техник CPU Isolation для задержкочувствительных нагрузок.

Недостаточно просто выгнать все процессы, кроме целевого, с ядра с помощью cpuset и привязать его к CPU через taskset. Надо не забыть и о фоновых задачах ядра, т.н. housekeeping work.

Housekeeping work – это совокупность фоновых операций, которые ядро Linux выполняет для поддержания своей внутренней инфраструктуры. Эти задачи включают обработку таймеров, обновление системного времени, управление очередями отложенной работы (workqueues), обработку прерываний, очистку ресурсов и прочее. Несмотря на то, что они обычно незаметны для пользователя, именно эти операции обеспечивают стабильность и корректное функционирование всей системы.

Оборотной стороной housekeeping work является то, что она привносит непредсказуемые задержки (jitter), прерывая выполнение пользовательских задач.

Борьба с этими задержками и есть центральная тема цикла.

Приветик всем! В этот тяжелый понедельник после солнечного затмения и вспышек на солнце мы опубликовали выпуск #74.

В новом выпуске Виктор побеседовал с ключевыми лицами конференции "DevOpsConf", которая через неделю отмечает 10 лет.
В выпуске мы поговорили с cовладелецем\генеральным директором компании «Флант» Александром Титовым и Head of SRE Дмитрием Зайцевым о истории конференции, современных трендах в докладах и мире IT в целом. И конечно затронули такие трендовые темы как eBPF 🙂

Просмотр, лайк, репост 🙂

https://youtu.be/lP6oKlAacN0

GitLab CI для Docker-образов #habr
https://habr.com/ru/companies/otus/articles/896010/
Tags: gitlab, Docker, docker образы, GitLab API, ci cd, CI CD пайплайны
Author: badcasedaily1 (OTUS)

Quadlet: Running Podman containers under systemd
https://mo8it.com/blog/quadlet/

Отказоустойчивость в MinIO #habr
https://habr.com/ru/companies/habr_rutube/articles/895286/
Tags: minio, отказоустойчивость, s3, репликация, хранение данных
Author: stratnevpy (RUTUBE)

Сегодня в 18:00 MSK ждём всех на открытую встречу Devhands: выбор брокера и системы очередей в 2025м.

Kafka, Rabbit, NATS или что-то ещё?

Своро выясним! Уже через час начнется очередная открытая встреча Devhands.

У меня в гостях будет Владимир Перепелица, эксперт по большим проектам, очередям и Tarantool, Solution Architect в Exness, создатель S3 в VK Cloud, регулярный спикер и член ПК конференций Highload.

Будем обсуждать:
- выбор брокера и системы очередей 2025м году, что поменялось?
- NATS, его особенности, перспективы, кого он “подвинет” в первую очередь, Kafka или RabbitMQ?
- что нового в свежей Apache Kafka 4?
- насколько популярны архитектуры, где, например, Kafka основной storage (IoT, сбор метрик и тд)

Бесплатно, без регистрации и sms:
https://www.youtube.com/@AlexeyRybak/streams. Запись будет - там же в стримах.

Приходите, будет интересно.

​Эй, где моя ошибка? Как OpenTelemetry фиксирует ошибки

В зависимости от языка программирования, на котором вы привыкли работать, у вас могут быть определённые представления о том, что такое ошибка, что такое исключение и как его следует обрабатывать. Например, в Go нет исключений — отчасти для того, чтобы отбить у программистов желание причислять слишком много обычных ошибок к «исключительным». С другой стороны, в Java, Python и т. п. поддержка для работы с исключениями встроена.

Когда разные языки расходятся во мнении, что такое ошибки или исключения и как их обрабатывать, возникает вопрос: что использовать, если нужны стандартизированная телеметрия и отчёты об ошибках для микросервисов, написанных на этих языках? OpenTelemetry отвечает на него. Читать дальше на Хабре.

​Шардированный кластер ClickHouse

Про ClickHouse как MPP-систему (Massively Parallel Processing) не так много информации можно найти в открытом доступе, но многое можно рассказать. Автор этой статье делится своим опытом и считает, что его рассказ поможет кому-нибудь сформировать целостную картину о том, как в ClickHouse спроектированы распределённые вычисления. Читать на Хабре.

Подробный разбор инцидента от 30 марта в Яндекс Облаке

Что случилось?

В период с 30.03.2025 12:25 по 31.03.2025 00:00 (МСК) сервисы Yandex Cloud, расположенные в зоне ru-central1-b, были недоступны. Инцидент был вызван двойным отказом по питанию из-за сбоя на городской высоковольтной подстанции, питающей ряд областных и промышленных объектов, включая дата-центр Яндекса.
. . .
Предотвращение

Корневая причина инцидента – потеря напряжения на двух независимых источниках питания одновременно. Команда Yandex Cloud анализирует возможные варианты предотвращения этого риска (включая вариант добавления третьего независимого источника питания). Об итоговом решении мы сообщим дополнительно.

Резюме по инциденту
https://status.yandex.cloud/ru/incidents/1129

​pev2

PEV2 — компонент VueJS для графической визуализации плана выполнения PostgreSQL.

Репыч на Гитхабе

#машины_разное

С небольшой ноткой усталого садизма наблюдаю за негодованием одно-зональников, когда у Яндекса отстреливает яйцо зона. Принимаю аргументы, что межзональный трафик денег стоит всегда, а Яндекс ломается только раз в год.

Хотя другой инцидент меня зацепил посильнее, а именно «Не было такого!» инцидент у Оракла с кражей учетных данных для входа в их облако. Ухх!

Тут надо сделать несколько заметок, от которых у меня идет холодок по коже.

Во-первых, взлом произошел по двухлетней уязвимости, которую совсем не ждешь на SSO или другом публичном эндпоинте. С точки зрения безопасности облачных систем это треш и неприемлемо, а Оракл можно еще по PCI-DSS за такое отругать.

Во-вторых, черношапочник получил доступ к зашифрованным паролям, что вообще странно, учитывая что пароли принято хешировать (тут пусть знатоки SSO и всяких oAuth меня поправят)

Ну и напоследок, переход в режим отказа, который прозвучал от представителей Оракла, понятен, но некрасив. Вендоры не любят признавать инциденты публично, вспомнить хотя бы городскую легенду о «одобрении VP, чтобы объявить инцидент в AWS», потому что за публичным признанием потом собирается пачка коллективных исков. Но Оракл хоть и признался своим клиентам о взломе, публично должен был объявить о внутреннем расследовании и отказаться от дальнейших комментариев. По опыту вынужден сказать, что это единственное правильное кризисное управление в таких ситуациях.

Секционирование в PostgreSQL. Архитектура корзинного хранения данных. (Basket partitioning)

Когда размеры таблиц становятся большими — обслуживание и доступ к данным становятся непростой задачей. Автор этой статьи делится методикой организации секционирования в PostgreSQL, которая существенно упростила ему жизнь с таблицами большого размера, хранящими, например, исторические данные по датам. Технология «Корзинное секционирование» (Basket partitioning) реализована архитектурно, без необходимости расширения функционала сторонними инструментами или расширениями, только штатными средствами ванильных версий PostgreSQL. Такая система хранения реализована, например, в проекте мониторинга pg_awr для упрощения удаления старых данных. Читать дальше на Хабре.

Побывал тут на DevOpsConf и послушал круглый стол про SRE - было сказано много интересного, но услышал новый для себя стандарт APDEX - метод для оценки работы приложения. Поискал что это за зверь и нашел неплохую статью в интернете https://docs.newrelic.com/docs/apm/new-relic-apm/apdex/apdex-measure-user-satisfaction/

Отличная подборка литературы

Code of Leadership #35 - Interview with Eugene Kozlov about SDLC (Рубрика #Engineering)

В очередном выпуске подкаста ко мне пришел интересный гость, Евгений Козлов, с которым мы вместе работаем в Т-Технология. Женя является Staff Software Engineer и руководит разработкой аналитической платформы Statist https://www.tbank.ru/career/technologies/statist/ , на которую мы съехали с другим решений наровде Amplitude, Adobe Site Catalyst и других. Женя интересуется высоконагруженными серверными системами, вопросами производительности, системами управления базами данных а также хранилищами данных. Женя ведет интересный канал @careerunderhood

За час мы успели обсудить следующие темы
1) Работу над платформенным продуктом "Статист"
2) Важность профессиональных связей и сотрудничества
3) Личную историю Жени и его выбор карьерного пути
4) Зачем нам фундаментальное образование и как оно помогает в разработке софта
5) Карьерный путь: от Ruby к C#, а дальше к Go
6) Чем Ruby был хорош и почему упала его популярность
7) Особенность работы с асинхронными бекендами, с которой Женя познакомился еще программируя на Ruby
😍 Переход в T-Bank и развитие навыков
9) Будущее программирования - важно не знать язык, а уметь решать проблемы с его использованием
10) Важность широты интересов и базы знаний

Рекомендации от Жени для изучения
1) The Pragmatic Programmer, 20th Anniversary Edition - книга о лучших подходах к разработке программного обеспечения, обновленная версия классического труда для современных программистов.
2) Программирование Cloud Native. Микросервисы, Docker и Kubernetes (2-ое издание, 2022) - компактная книга о создании облачных приложений с использованием микросервисов, Docker и Kubernetes.
3) Scalability Rules: Principles for Scaling Web Applications - руководство для инженеров стартапов о масштабировании веб-приложений.
4) Fundamentals of Data Engineering: Building Reliable Data Systems - книга о базовых принципах проектирования надежных систем обработки данных.
5) Путеводитель по базам данных - подробное руководство по архитектуре и алгоритмам современных систем управления базами данных

Выпуск подкаста доступен в Youtube, VK Video, Podster.fm, Ya Music.

#Architecture #Software #Engineering #ProductManagement #Management #Economics