Отказоустойчивость в 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

Kubernetes в изоляции: когда ваш кластер не должен знать о существовании интернета

Вы думаете, что развернуть Kubernetes без интернета — это просто kubeadm init плюс пара манифестов? Посмотрим, как скрипты решают проблемы, о которых вы даже не задумывались.

Спойлер: здесь есть чему удивиться.
И философский вопрос: зачем это всё?

Потому что настоящий DevOps — не тот, кто умеет копировать команды из интернета, а тот, кто может развернуть production‑кластер:
- на заброшенной арктической станции,
- на сервере с доступом только через 3G‑модем,
- в подвале банка с железобетонными стенами.

👉 https://habr.com/ru/companies/slsoft/articles/897102/

#kubernetes

Коммерсантъ: Yandex B2B Tech выводит на рынок сервис для мониторинга и выявления киберинцидентов YCDR

– YCDR помогает оперативно обнаружить хакерские атаки и др.
– Он разработан на базе центра мониторинга безопасности (SOC)
– В рамках него доступна SIEM-система собственной разработки
– Также доступны инструменты Security Data Lake и ИИ-решения
– SIEM выявляет аномалии, помогает предотвращать атаки и др.
– Инвестиции Yandex Cloud для ИБ за 2024 составили 1,3 млрд руб.
– Рост инвестиций за 2023 был 30%, за 2025 рост составит 40%
– Yandex Cloud запустила 17 сервисов безопасности для бизнеса
– Среди них, например, межсетевой экран Web Application Firewall
– Yandex Cloud обеспечивает безопасность всей облачной платформы
– Также технологии помогают защищать облачную среду клиентов
– Услуга SOCaaS удобна благодаря технологиям и быстрому запуску

@ftsec

Хвалюсь тулзой на основе VictoriaLogs: https://github.com/vrutkovs/audit-log-stats
Нам часто приходится анализировать audit log кубернетесовских аписерверов и вытягивать оттуда инфу о том какой юзер чаще всего достает ресурсы, сколько времени занимает ответ и разбивка этого времени на части - etcd / webhook / сериализация и т.д. В графане сразу сделан дашборд, который позволяет быстро найти виновника тормозов.

Сами аудит логи это простой jsonl, но зато их очень много и кардинальность улетает в небеса. После долгого мучения с перфомансом локи переделал на VLogs и теперь всё 🚀быстро🚀

cc @valyala

​Мониторинг с Grafana. Best practices

Не очень свежая статья, но тем не менее актуальности не потеряла. Есть базовые рекомендации, о которых, быть может, вы не знали.

OS Talos Linux. Хайп или реальный продукт

OS Talos Linux спроектирован специально под Kubernetes.
На трансляции разберем почему поднялся хайп вокруг этой OS и на сколько она функциональна, а так же:
• архитектуру и философию проекта
• эксплуатацию
• кейсы
• примеры решений

👉 https://www.youtube.com/watch?v=liso5CNn4G4&t=1458s

#kubernetes #talos