Увидел в чате уважаемого человека пост про OpenZL, и не смог пройти мимо, т.к. понеслось - уже в ZFS начали его просить :)

Да, это ещё один компрессор, но с нюансом. Yann Collet там тоже отметился, так что давайте и сравним новинку с его произведениями искусства:
- LZ4 - максимально быстро, всё в угоду скорости, даже несжимаемое предпочитает по эвристике пропустить и не пытаться пожать (итого скорость ~memcpy на несжимаемом)*
- ZSTD - очень гибкий, быстрее gzip, эффективнее gzip, на малых режимах сжатия наследует многое от LZ4*. Одна из фишек - сжатие по словарю - т.е. если ваши данные ну очень типовые - составляете словарь наиболее частых вхождений и получаете легко коэффициент х20. Нюанс - словарь надо таскать с собой, что сильно уменьшает удобство.
- новинка OpenZL - читерит и требует знания про ваши структуры данных, но зато может дать огромный выигрыш. Проще всего объяснить на их же примере и вспомнить почему time-series DB умеют ну очень эффективно хранить последовательности: если вы храните упорядоченные числа, то эффективнее всего хранить их... дельту! Ключевое отличие от словарей - что для разжатия вам не нужны дополнительные артефакты.

Новое слово для сжатия известных структур/метаданных?

* на самом деле, грань между LZ4 и ZSTD сильно размылась, у каждого уже есть разные режимы, позволяющие сильно превратить одно в другое

Уважаемый человек побудил меня потратить всё время в сапсане на чтение paper'а об openZL, и я прямо насладился!

Идея - огонь:
- SDDL (язык для описания структуры данных) для парсинга на первом этапе, потом transform (промежуточный кодек), потом графы и итоговые кодеки в них.
- Кодеком может являться любая функция которая что-то сделает с данными (тот же zstd). Элемент графа - тоже кодек, но умеющий построить связь с другими кодеками передающий данные как есть.
- Работаем не с байтами, а со структурированными данными. При чём in-out стримов много! Полезный бонус - данные перед сжатием теперь можно не сериализовывать, а как есть отдать на соответствующий кодек для сжатия.
- Упор на практичность, универсальный декодер (главное чтоб имел нужные кодеки). И это гипер важно - основная проблема сделать новый алгоритм компрессии - в распространении его декомпрессора. OpenZL позволит делать максимально эффективные кодеки, используя один и тот же декодер!

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

Для простоты разберём пример:

csv "ФИО,рост,вес"
- парсим и выделяем каждый столбец отдельно
- теперь, например, столбец "рост" можно преобразовать из ascii/utf в int, может даже - отсортировать, если отсортировали - писать дельту а не значение, и всё это подать в специализированный кодек field_lz
- поле "ФИО" проще воспринимать как текст, тут можно использовать базовый zstd (для примера)
- итог - граф операций над данными, для декомпрессии его надо просто проиграть в обратную сторону (т.е. в итоговом артефакте есть информация о порядке декомпрессии известными декомпрессору кодеками)

А как вы упарываетесь в пути?

Кстати, тут python 3.14 релизнулся, все носятся с перформансом и тредами. Это конечно классно, но в среднем для вас разница будет на уровне погрешности.

Лично я очень ждал (и наконец - дождался):
- zstd из коробки. Король компрессоров in da house
- uuidv7 из коробки. Теперь индексы по uuid будут последовательны и эффективны, особенно это оценит mysql и подобные с gap lock на primary key

Коллеги проводят исследование с целью понять, что реально происходит внутри ИТ-команд и какие закономерности можно в этом увидеть.

Уже нащупаны интересные корреляции:
– между скоростью пайплайнов и качеством code review,
– между алертингом и стабильностью релизов,
– между ролями в команде и удовлетворённостью релизным процессом.

Но нужно больше данных, чтобы отделить закономерности от шума.

Пройти анкету можно за 10 минут. Её же можно использовать как мини-чек-лист для самооценки зрелости инженерной культуры.

Принять участие: https://forms.gle/NszR7VDuXL9sBbVAA

Результаты обязательно расскажу, коллеги поделятся.


Чем быстрее CI/CD - чем больше рисков "тестирования на проде"?

Minio "is a source only distribution now, if you want to build containers you need to build them yourselves".

Как выстрелить себе в ногу и не подать виду? Очередная история как опенсорсный проект превращается в проприетарный. А начинали они с вырезания функционала из опенсорса...

#unsource

В этот раз делать отдельный обзор на аварию даже как-то неудобно, DNS всё же :)

Вообще как корректно DNSу ответить именно в случае проблем - это больно, т.к. краткий ответ - ответить кровь из носу, но надо, иначе у всех кеш о записи протухнет и умрёт. Вот и получается, что для самых критичных вещей будь добр имей статичные записи с хорошим таким TTL.

А будущее всё также за cloud-agnostic (да-да, on-prem это тоже облако нынче) и #NoOps .

#машины_aws

Пожалуй, лучший инцидент, что я когда либо видел.

Если вкратце:
1. Управление DNS записями для DynamoDB отвалилось, в итоге:
2. Эндпоинты DynamoDB (в том числе для внутреннего пользования) отвалились, в итоге:
3. Storage backend, которым выступала DynamoDB, одного из компонентов control plane EC2 отвалился, в итоге:
4. Отвалился NLB, который не мог следить за событиями EC2.

Очень радует, что AWS решил минимальными усилиями решить конкретную проблему, а не сделать отдельный внутренний Kinesis как тогда с инцидентом CloudWatch и Cognito.


Да и не пользуйтесь us-east-1, сколько еще повторять. Новые фичи раньше всех того не стоят.

В сети можно найти интересные посты про "переволновавшиеся" LLMки, как они могут проигнорировать инструкции об безысходности и всё же дропнуть вам базу на проде.

По случаю вспомнил замечательный рассказ Станислава Лема - Ананке. 1971 год, короткий рассказ, Марс, научная фантастика, как нынче модно это называть - про машинное обучение.

Первый раз я прочитал это произведение лет 5 назад, и подумал, что этот sci-fi уже про "несвершившееся будущее" и сильно так устарел (хотя даже тогда он меня покорил той самой богиней Ананке). Но в этом году, да ещё с такими историями про LLM, оказывается что мы всё таки дожили до этого будущего, про которое когда-то подумал Лем :) Вот такие они - грёзы по несбывшемуся будущему.

#books

А ещё мне очень понравилась суть богини Ананке из древнегреческой мифологии - "неизбежность, судьба, нужда, необходимость". Всё как в жизни - если какой-то сценарий вероятен, то на масштабах он неизбежен. Например - ваш сервер когда-то гарантированно откажет самым неожиданным образом.

Забавно было буквально вчера в некоторых чатах на проблему DDoS'а ботами-краулерами читать "да просто юзай CF!"

Тем временем сегодня Cloudflare отдыхает... Ждём постпортема.

Cloudflare оперативно выкатил весьма детальный постмортем, за что им большое спасибо.
Про Rust уже все поржали, но я бы хотел обратить внимание на другое.

На первый взгляд, ситуация выглядит странно - просто выкатили обновление на всю сеть целиком. Ни тебе тестов, ни blue/green и cherry picking, ни даже внятной системы отката изменений. И эти люди борются звание дома высокой культуры быта! (с)

С другой стороны - глобальная инфраструктура из сотен (если не тысяч) узлов, где изменения нужно применять очень быстро, потому что это вопрос безопасноти клиентов, да и самого CF. Добавьте сюда чудовищную сложность - слои легаси, сотни разных сервисов, взаимосвязи между которыми до конца не знает вообще никто, а зависимость может прорастать через два-три слоя абстракций в обе стороны.

Станет ли у Cloudflare меньше клиентов? Сомневаюсь. Более того, на ПФ в понедельник я слышал мнение, что мелкий бизнес а России даже уходит с отечественных CDN на CF (потому что до конца оранжевого гиганта блокировать пока не собираются, а "бесплатный" CDN и DDoS-защита никуда не исчезли). Про зарубеж я вообще молчу.

Так и живём

#thereisnoclouds @snakeslair

К вопросу о скорости починки cf, коммент от их CEO (link):

Because we initially thought it was an attack. And then when we figured it out we didn’t have a way to insert a good file into the queue. And then we needed to reboot processes on (a lot) of machines worldwide to get them to flush their bad files.

Все мы люди.

Про CPU steal-time

К своему чудовищному стыду я ещё недавно совершенно не знал, что гипервизоры с хостов прокидывают в виртуалку специальную метрику steal-time, и она забирается в промстэк вместе с system/user/idle и прочими стандартным node_exporter-ом.

CPU Steal-time буквально “украденное время”. Проц выдали не тебе, а соседу. Про эту метрику мне сказал коллега по ПК Хайлоада, Георгий Меликов, за что ему большое спасибо. Я проверил, что протягивается, и забыл.

Не прошло и 2х недель, вчера участник тренинга по перфомансу показывает жутко зашумленные графики стрельб, очень отдаленно напоминающие правильные, и говорит: я уже всё перепробовал, WTF. Замечаю большой steal time (почти равен сумме user+system) и пишу в саппорт, так и так, похоже, шумный сосед / перегруженный хост.

И да, саппорт подтверждает, виртуалку переносят, 100К RPS наливаются. Клауды такие клауды 🙂

👍 зато девопс пайплайн тераформ, а не вот это ваше всё
🔥 ну, за онпрем!

Когда-то про это коллеги хорошую статью написали https://habr.com/ru/companies/vk/articles/449316/

3 декабря в Мск будет OS DevConf 25 - "Конференция про разработку системного ПО, ядра Linux и open source".

Почему приглашаю:
- мы с коллегой впервые анонсим наш новый SDS - RawStor. Расскажем почему решили писать ещё один сторадж, и ответим, почему в нём "client всегда прав". (всё в опенсорсе)
- будет ещё несколько докладов про стораджи: SPDK, Lustre (очень жду этого доклада, к примеру, контрибьюторы приедут!)
- ну и много других докладов рядом с Linux

Увидимся!

И продолжаем приглашения на новогодние тусовки :) Приходите - увидимся!

InfraDev Community приглашает на Cloud Fail ((Over)): специальный новогодний выпуск InfraDev Meetup.

Без фейлов не обходится ни один крутой продукт, ну а истории успеха — «за ширмой» оказываются историями поисков и ошибок с удачным концом.
Поговорим про то, какие проблемы возникают под капотом инфраструктурных продуктов, как они решаются и какие уроки из этого получаются.

Спикеры:
☁️Василий Степанов, руководитель направления инфраструктурных сервисов, VK Cloud, VK Tech.
☁️Константин Крамлих, руководитель поднаправления сетевых продуктов, Yandex.Cloud.
☁️Секретный доклад: подробности добавим позднее.

Подробнее о докладах читайте на странице мероприятия.

Когда: 18 декабря, с 18:00 до 23:59 
Где: Москва, Ленинградский пр., 70, офис VK Tech, БЦ «Алкон» (количество мест ограничено).
Приходите на встречу или участвуйте онлайн.

Зарегистрироваться.

А тем временем - минио закрылись. Кто форкнет первым?

Devin AI got fired

Кстати, уже доступны записи докладов, ютуб/рутуб/вк.

Но это же канальчик и про стораджи, так что приведу доклады про сторадж:
- мой с коллегой, про наш сторадж RawStor ютуб/рутуб/слайды (@gmelikov @vasi2y)
- про SPDK в MWS ютуб/рутуб (@swaoter)
- обзорный про Lustre FS от контрибьюторов с 20-летним стажем ютуб/рутуб