SiliFuzz: Fuzzing CPUs by proxy

Недавно писал про статью инженеров гугла об аппаратных дефектах микропроцессоров (Cores that don't count) Там констатировалось, что такие дефекты есть, и их не так уж мало – но что с этим делать обсуждалось только гипотетически.

SiliFuzz: Fuzzing CPUs by proxy¹ – продолжение этой темы. Авторы задались целью создать механизм непрерывного тестирования парка серверов на аппаратные ошибки. Поскольку заранее неизвестно, какие именно аппаратные ошибки искать, то авторы решили положиться на фаззинг.

Они генерировали сотни тысяч тестов – полу-случайных наборов инструкций. Эти наборы прогонялись на разных процессорах, чтобы получить "правильный" результат их выполнения – таким образом "набор инструкций" превращался в "тест"², с известным ожидаемым результатом. Дальше с какой-то периодичностью подмножество этих тестов прогоняется на каждом ядре процессора каждой машины из парка серверов. Машины, давшие подозрительные результаты – выводятся на карантин, для дальнейшего разбирательства.

Статья довольно короткая, не буду ее пересказывать. Мне показались интересными 2 вещи: как они генерируют тестовые последовательности инструкций, и что широкое применение таких тестов начинает выглядеть неожиданно вполне реальным и близким.

Тестирование конфигурации: aftermath через 5 лет

Пару лет назад я увлекался темой тестирования конфигурации – проверку конфигурации приложений оффлайн, перед выкладкой на рабочие сервера, с помощью юнит-тестов. Эту идею к нам в проект принес Андрей Сатарин, позже я применил ее более масштабно в другом проекте, и рассказывал об этом опыте на Гейзенбаге 2018.

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

Проблема тестирования конфигурации в том, что нет готовой инфраструктуры

Одна из проблем с тестированием конфигурации состоит в том, что нет готовой инфраструктуры

Я имею в виду, что когда вы собираетесь написать тест для кода — у вас уже многое есть. У вас есть какая-то доменная модель, у вас есть какие-то API, у вас есть какие-то builders/wizards/DSL. Да, поверх всего этого, обычно, все равно приходится дописать прослойку вспомогательного кода, предназначенного именно для тестирования (aka "test-harness"), но если основной код спроектирован и написан достаточно хорошо, то эта прослойка довольно тонкая. Условно, процентов 50-80 уже написано, и эти проценты очень облегчают начало.

Configuration as code

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

Сейчас мне кажется, что выносить конфигурацию приложения в текстовые файлы (в том числе xml/json/yaml…) — это сильно переоцененный прием. Настолько переоцененный, что он уже почти антипаттерн. Ну как синглетон — сам по себе вроде неплох, но был период, когда его пользовали где ни попадя, в хвост и гриву. Так же и с конфигурацией в текстовых файлах: якобы это дает гибкость, но эта гибкость на практике оказывается чаще вредной, чем полезной.

"Тестирование конфигурации для java-разработчиков" (Гейзенбаг 2018, Петербург)

Меж тем я тут немного погрузился в тестирование — вплоть до того, что выступал на питерском Гейзенбаге с докладом про тестирование конфигурации. Только вчера вернулся, а сегодня на сайте конференции уже выложили слайды.

Тезисно: я рассказывал о том, что конфигурация это важная часть приложения — такая же важная, как код. Ошибки в конфигурации приводят к некорректной работе сервисов, и/или отказам в обслуживании — ровно так же, как и ошибки в коде.

Но код приложения проходит множество проверок — начиная от компилятора (если вы, конечно, пишете на нормальных языках, а не на JavaScript), и кончая многими уровнями тестов. Конфигурация же, чаще всего, это просто какие-то текстовые файлы (properties, xml, yaml, json...), с очень вольным форматом, практически без валидации. Никаких автоматизированных тестов для нее, как правило, нет.