Когда я делал тесты на основе библиотеки Jepsen для Tarantool, то планировал добавить в тестирование сбои на файловой системе. Почему-то так сложилось, что в самой библиотеке Jepsen нет сбоев для файловых систем и даже Кайл в одном из своих комментариев написал, что было бы здорово, если бы кто-то добавил их в Jepesen. Я знаю, что есть две файловые системы на основе FUSE: CharybdeFS от разработчиков ScyllaDB и PetardFS, но у меня есть вопросы к интерфейсам для описания сбоев в этих файловых системах. CharybdeFS при запуске поднимает сервер и по протоколу Thrift можно включать и выключать различные виды сбоев, а PetardFS использует XML для конфигурации при запуске. Ни первый ни второй вариант мне не понравился и я сделал свою файловую систему с тем же подходом, но конфигурацию можно описывать с помощью файла в формате INI (как конфиги в Windows). Это такой компромисс формата удобного и для чтения машиной и человеком. Файл с конфигурацией лежит на самой ФС и перечитывается каждый раз, когда его обновляют (мы же ФС и знаем какие операции и с какими файлами происходят). Как оказалось, такая тестовая ФС полезна не только при тестировании распределенных систем или баз данных. В тикеты пришёл парень, который тестирует парсер и ему нужно, чтобы за одно чтение возвращался ровно 1 байт из файла. Поэтому ассортимент возможных сбоев я ещё буду расширять.

https://github.com/ligurio/unreliablefs

🔐 Иллюстрация и объяснение каждого байта TLS-соединения: https://proglib.io/w/e0f20879

Для Амазона/Гугла есть много рекомендаций по настройке безопасности. Вот чеклист по безопасности и для Yandex.Cloud. Он достаточно простой, если у кого-то есть более подробные инструкции или чеклисты для Яндекса — присылайте его нам, опубликуем в канале тоже.
http://a.e42.link/jYoY7

Кафка с медом (простите):
О том как говорят Кафку в Honeycomb.io

- решили делать свое, так как не хотят ждать ответа от суппорта, если что-то сломается у их клиентов
- переехали из AK 0.11 в Confluent Community (5.3/AK 2.3)
- переехали на Confluent Platform 6.0 (enterprise): Tiered Storage (в их паттерне надо держать 24-48 часов в быстром доступе NVMe, чтобы можно было быстро replay. И Self-balancing Kafka (Cruise Control сразу зашит))
- так же Кафка нормально живет на arm-е (они используют graviton от AWS).
- много правильных рассуждений на тему sizing - выбор на каком instance type бежать еще пол беды, надо понять сколько это будет стоить.

Не знаю, кому будет полезно. Копировать as is не надо, но я рекомендую как минимум разобраться с их ходом мыслей Liz Fong-Jones и ее команды (из зафолловить ее).
Там много правильных идей на тему цена-производительность-заплатить вендору

Вдогонку к предыдущему сообщению, тредик из Твитера Liz
- видео и код с прибаутками как запустить это дело на Graviton2
- в блоге еще сказано не юзать стоковую OpenJDK, а юзать Correto
- ZStandard compression можно юзать в проде

irate() vs rate() — What’re they telling you?

Prometheus makes available great functions for data aggregation by timeline. Among these functions, I focused my analysis on irate() and rate() which give us similar outcomes but they work in different way. Читать дальше.

Оказывается у AWS есть альтернативная (честная) версия их AWS Service Health Dashboard. Потому что, как мне сказали оригинальный продукт - bullshit. Поэтому, если у вас AWS то вам бует полезно добавить в закладки https://stop.lying.cloud/

Introducing Prometheus Agent Mode

The Agent mode optimizes Prometheus for the remote write use case. It disables querying, alerting, and local storage, and replaces it with a customized TSDB WAL. Everything else stays the same: scraping logic, service discovery and related configuration.

Нормально! 💪

https://prometheus.io/blog/2021/11/16/agent/

Production Readiness Review (PRR)

Несколько лет назад Google рассказал миру о том кто такие SRE (Site Reliability Engineers) и как они помогут обеспечить надежность приложения в продакшене. Кто-то из вас наверняка слышал, что SRE реализуют практики DevOps, а сам по себе DevOps это больше философия чем роль в команде. PRR это процесс, который позволяет подготовить приложение к продакшену. На первом этапе рождается чеклист, лучше всего если чеклист отражает опыт команды и учитывает нюансы эксплуатации продукта. Когда чеклист готов, начинается процесс ревью, человек от команды и ревьюер встречаются и на коротких митингах проходят чеклист, сфокусированно, не распыляясь, качественно. Сам факт прохождения PRR обещает значительно уменьшить количество проблем в продакшене, как минимум благодаря тому что к некоторым из них мы уже готовы и зафиксировали как риски

Вот небольшая статья от GrafanaLabs: https://grafana.com/blog/2021/10/13/how-were-building-a-production-readiness-review-process-at-grafana-labs/

#practice #sre

Не повторяйте: мои инфраструктурные ошибки / Хабр
https://habr.com/ru/company/ispsystem/blog/594819/

Внезапно - релиз plumber 1.0, моей любимой утилиты для работы с Кафкой и другими очередями✌️✌️

https://github.com/batchcorp/plumber

Oracle Cloud раздаёт бесплатно навсегда инстансы с 24 ГБ памяти / Хабр
https://habr.com/ru/company/itsumma/news/t/595151/