Вот это объяснение.

​Кажется в одном из выпусков про DWDM упоминалосья что не надо смотреть на оптические панели, не зная мощности сигналов в оптике, а то панель может посмотреть обратно на тебя.

Не удержусь зарепостить эту прелесть, информация не так уж и эфемерна😅 Выжигание байтиков по дереву

Из реальной жизни

Вьетнамские флешбеки

В SDSном чате подняли тему митигаций аппаратных уязвимостей (мякотка тут https://habr.com/ru/articles/852536/ ),

конкретно на AMD была очень неприятная дырка Speculative Return Stack Overflow (SRSO) , и на кейсах, где присутствует частый context switch оно весьма больно бъёт по перформансу, при этом severity около 5 из 10 (т.е. medium well), и эксплоит тоже весьма требователен к условиям запуска (минимум локальный доступ).

Интересен момент, что митигация на самом деле не одна, есть несколько различных вариантов с разным спектром защиты, и отличается она в основном User->Kernel и Guest->Host протечками.

К чему это всё: если ясно понятен профиль нагрузки хоста (локальных юзеров одна штука) и в ядре у вас нет ничего важного, то можно задуматься о выставлении spec_rstack_overflow=microcode, который обеспечит изоляцию Guest->Host, чего для тех же локальных лаптопов весьма достаточно (да съедят меня безопасники).

Шарить надо только нужное

перевели монументальную статью о дедупе в ZFS, и как он изменится в релизе 2.3 https://habr.com/ru/companies/vk/articles/863904/

#books

Обожаю sci-fi, чем твёрже тем лучше.
Залпом прочитал "Семиевие" Нила Стивенсона за 2 недели. Автор, как всегда, многословен, но тем и прекрасны некоторые его книги.

Отзывы на SeveneveS пестрят жирными намёками на скучность и подобное "войне и миру" описание регулярных флешбеков в биографию героев. Но для меня в этом и прелесть Стивенсона как автора - столько увлекательных идей, и все* технически реализуемы!

Также стоит отметить рабочий подход с "чтобы построить новый мир, надо разрушить до основания старый", как бы грустно это не звучало,
НО даже в наших рядовых рабочих задачах есть проблема абстрагироваться от уже имеющихся наработок и посмотреть - а как же было бы оптимальнее сделать в принципе? Обожаю этот подход!

Книгу категорически рекомендую любителям hard sci-fi, и буду рад вашим рекомендациям что ещё почитать из похожего. Эту книгу могу сравнить с произведениями Andy Weir (особенно Project Hail Mary) и Dragon's egg от Robert L. Howard.

А задумывались ли вы над тем, ĸаĸ появились ĸаталоги . и .. ?

Интересный и краткий экскурс в историю https://habr.com/ru/companies/vk/articles/879456/

Недавно разразился скандал про продажу б/у HDD под видом новых от официального реселлера Seagate https://www.tomshardware.com/pc-components/hdds/seagates-fraudulent-hard-drives-scandal-deepens-as-clues-point-at-chinese-chia-mining-farms

С одной стороны, покупая новое мы, естественно, хотим получать что-то с завода без следов эксплуатации.

А, с другой, HDD в первый год работы имеют повышенный риск смерти, и при покупке HDD с пробегом 5-15 тысяч часов, вы не только можете сэкономить, но и уменьшить процент отказов! Backblaze уже делился статистикой на этот счёт https://www.backblaze.com/blog/how-long-do-disk-drives-last/

Да, гарантия должна покрывать как раз первый год-два жизни диска, но повод на подумать всё равно есть. Да будет битва "гарантия" VS "за цену нового купим 2 б/у"!

В мире локальных стораджей наметилась очень интересная тенденция складывать всё в S3,
AWS у себя в FSx (где они используют zfs) ловко сделали псевдо-tiering и сгружают данные сразу в S3:

This change is in use by FSx in production today for FSx Intelligent Tiering file systems, which use S3 storage-backed vdevs.

А пару лет назад Delphix передумал выкладывать object-based vdev в апстрим.

Интересный кейс, выгода решает.

Давно думали выступить? Самое время! Если переживаете или боитесь - можете приходить в комментарии-личку, как член программного комитета помогу подготовить заявку:

🔥 Saint HighLoad++ 2025 ждёт твой доклад!

Если у тебя есть опыт работы с высоконагруженными системами, большими данными, машинным обучением, инфраструктурой, DevOps или безопасностью, самое время подать заявку на выступление!

🎤 Выступать не страшно – мы помогаем с подготовкой, оплачиваем дорогу и даём бесплатный билет.

🚀 Присоединяйся к сильному сообществу разработчиков и делись своим опытом!

📌 Подача докладов открыта до 23 февраля: cfp.highload.ru

Уважаемые хардкорщики, приглашаем вас на чисто технический оффлайн митап (+ есть онлайн), приходите! Увидимся!

VK Tech приглашает на InfraDevMeetup, посвященный разработке и эксплуатации инфраструктурных платформ, от разработчиков инфраструктурных сервисов.

Поговорим про устройство среднестатистических SDS и их выбор/разработку, в чём проблема «отношений» RabbitMQ и SDN Neutron, как можно спасти данные из аварийного Ceph и как построить датацентр для авто-тестов.

Спикеры:
☁️Василий Степанов, руководитель команды разработки Storage, VK Cloud.
☁️Артемий Капитула, техлид группы разработки систем хранения, Wildberries.
☁️Александр Шишебаров, ведущий разработчик, Selectel.
☁️Александр Крымов, старший разработчик, Kaspersky.
Подробнее о докладах читайте на странице мероприятия.

Когда: 26 марта, с 18:00 до 23:00
Где: Москва, Ленинградский 70, БЦ Алкон, офис VK Tech

Приходите на встречу или участвуйте онлайн.
Зарегистрироваться.

Ah, good ol' finnish guy, who's always ready to feed you up
https://lore.kernel.org/lkml/CAHk-=wiZ=ZBZyKfg-pyA3wmEq+RkscKB1s68c7k=3GaT48e9Jg@mail.gmail.com/

Капитанства пост - забудьте про md5, используйте xxh3 если вам не нужна криптостойкость, приемлемый дефолт - sha256.

Наивный тест на скорость "дефолтных" хешей из питона, по 10МБ рандома, псевдо-методика тут . Да, если не можете притащить сторонние либы - sha256 наше всё.

Попробуем формат мини-постмортемов.

Вчера на полдня ложился Интернет Google Cloud (GCP):

the issue occurred due to an invalid automated quota update to our API management system which was distributed globally, causing external API requests to be rejected. To recover we bypassed the offending quota check, which allowed recovery in most regions within 2 hours. However, the quota policy database in us-central1 became overloaded, resulting in much longer recovery in that region. Several products had moderate residual impact (e.g. backlogs) for up to an hour after the primary issue was mitigated and a small number recovering after that.

Давайте попробуем порассуждать что же произошло на основе публичных данных:
- Первопричина - в quota api гугла прилетели некорректные данные (извне/изнутри/при обновлении), которые по цепочке вниз разломали всё остальное.
- В любой инфраструктуре есть "фасад" с IAMом, квотами и другими "бизнесовыми" сервисами. Обычно аварии, связанные с ними должны иметь аффект только на этот самый "фасад", и аффектить максимум controlplane, т.е. возможность управлять сущностями.
- Но, судя по аффекту, некорректные метаданные всё же добрались до dataplane и успешно сломали и сами инфраструктурные сервисы (минимум их часть)

Сами Google сделали такие выводы:

- Prevent our API management platform from failing due to invalid or corrupt data.
- Prevent metadata from propagating globally without appropriate protection, testing and monitoring in place.
- Improve system error handling and comprehensive testing for handling of invalid data.

Переводя для себя: валидация входящих данных должна быть строжайшей, а всё, что разъезжается глобально - должно разъезжаться строго поэтапно, чтобы не накрыть всю систему разом. Ну и частные ошибки надо уметь игнорировать.

Лично для меня вывод - защититься от такого гарантированно сложно, но если строить обработку ошибок не от частного (отдельные обработчики на каждую), а от общего (не важно какая ошибка произошла), и при этом уметь обработать ошибку по конкретной сущности отдельно - такого можно избегать. Пример - любая невалидная запись не важно по какой причине должна быть отброшена с громким ором об этом, не останавливая работу в целом. Вспоминаем любимый нами reconciliation loop. Ну и чёткое разделение control/data-plane.

Что интересно, GCP за собой положил и часть Cloudflare. Но разбор их проблемы оставим на десерт, если такой формат вам интересен.

#postmortem

Продолжим тему постмортемов, ч.2 аварии в GCP.

Оказалось, что один из ключевых компонентов Cloudflare хостится на GCP, который значительно пострадал.

Анализ на базе публично доступного:
- У CF есть публичный key-value распределённый сторадж - Workers KV
- CF придерживается политики "по максимуму используем свои же кубики", и Workers KV является основой также и для других сервисов CF (тут им респект - dogfooding это прекрасно)
- Workers KV is a data storage that allows you to store and retrieve data globally , звучит отлично
- На деле выяснилось, что хотя сервис и распределённый, и кеш у него распределённый, НО итоговый сторадж (он же - единая точка правды) - централизован
- Итог - "топология звезда, центр лёг - всему пизда"

Делаем выводы:
- Единая точка правды - нормальная практика, но стоит быть готовым к её полному уходу (что сложно)
- Как можно уменьшить аффект - стараться разделить read и write операции, read в таком случае можно хорошенько разгружать и делать распределённым
- Разумный компромисс - в случае аварии "в центре" переходить в read-only режим
- А это значит, что нужно стремиться делать подавляющее количество операций - только на чтение
- Ну и капитанское: моновендорность - это к проблемам. Хотите такое переживать - учитесь работать в парадигме мультиклауда, уход даже нескольких регионов разом - статистическая норма на долгосроке.

Сами CF говорят что уже планировали подобные работы:

Bringing forward our work to improve the redundancy within Workers KV’s storage infrastructure, removing the dependency on any single provider.

Можно конечно выбрать самого крупного вендора, и надеяться, что с его падением упадёт и весь остальной Интернет :)

#postmortem