Компания Antithesis спонсировала этот пост.
Потеря институциональных знаний, когда люди покидают организацию, может быть тяжелой. Когда давние специалисты по сопровождению покидают проект с открытым исходным кодом, вернуть эти знания может быть практически невозможно.
Именно это случилось с etcd, распределенным хранилищем значений ключей с открытым исходным кодом, которое «старше, чем сам Kubernetes», — сказал ведущий специалист по сопровождению etcd Марек Сиаркович в этом выпуске The New Stack Makers.
Сиаркович, старший инженер-программист в Google, присоединился ко мне для участия в этом выпуске программы Makers «В дороге», записанном на KubeCon + CloudNativeCon North America в Атланте в прошлом месяце.
Проблема смены сопровождающих и потери знаний
Сиаркович перешел четыре года назад из команды Google Kubernetes в команду etcd. Примерно три года назад, рассказал он мне, проект etcd столкнулся с некоторыми проблемами с надежностью.
Пока команда сопровождающих работала над выпуском нового релиза, «многие сопровождающие ушли из проекта и были заменены новыми сопровождающими, и произошла утечка знаний. Таким образом, все свойства, которые нельзя было записать в код, были потеряны вместе с этими людьми. Все процедуры, как тестировать, как гарантировать корректность, которые были сделаны раньше, не были сделаны для нового релиза».
В результате команда выпустила версию, в которой «было несколько критических проблем, например, сбой приложения мог привести к несогласованности».
Достижение «Святого Грааля» для распределенной системы
Чтобы исправить ситуацию, новая команда специалистов по сопровождению провела так называемое «тестирование надежности». Чтобы проверить основную правильность проекта, а также правильность системы распространения, команда создала собственную структуру, «вдохновленную» Jepson с открытым исходным кодом.
Целью, по словам Сиарковича, было достижение линеаризуемости — способности «иметь распределенную систему, которая должна вести себя как один узел. Это похоже на Святой Грааль распределенных систем. И проверка этого является очень сложной проблемой».
Решение этой проблемы, как поняли специалисты по сопровождению, означало необходимость создания собственного механизма внесения сбоев. «Нам нужно было научить людей, сообщество тому, как его отлаживать, и все эти проблемы были огромными», — сказал Сиаркович.
В основе всего этого, по его предположению, лежало желание создать базу знаний, которая не исчезнет, если члены команды покинут проект.
Использование детерминированного моделирования для восстановления знаний
В поисках решения этой проблемы команда etcd обратилась к компании Antithesis, которая занималась детерминированным симуляционным тестированием. Без такого подхода к тестированию программного обеспечения обнаружение и воспроизведение ошибки в распределенной системе может оказаться рискованным.
«У вас есть некая гипотеза, вы пытаетесь воспроизвести ее, но вам нужно, чтобы вам повезло, чтобы иногда обнаружить некоторую гонку между несколькими компонентами или несколькими журналами и несколькими отдельными процессами, взаимодействующими по сети, чтобы найти ошибку». — сказал Сиаркович.
Напротив, по его словам, «детерминированное моделирование позволяет вам линеаризовать все, поэтому будет только один путь выполнения, и он всегда будет воспроизводимым».
По словам Сиарковича, сотрудничество с Antithesis облегчило сбор знаний. Команда могла «определить свойства, которые были только в документации или только в головах сопровождающих».
По его словам, преимуществом использования платформы Antithesis является возможность более надежно проверять утверждения инженеров. «Раньше у нас уже были утверждения, но они никогда не срабатывали. Поэтому казалось, что если оно никогда не срабатывает, то это должно быть хорошо».
Но такой подход «нет новостей — это хорошие новости», предположил он, лишил команду более глубоких знаний, которые могло бы выявить более тщательное тестирование. По словам Сиарковича, тестирование и внедрение ошибок Antithesis вышло за рамки того, что команда сопровождающих могла создать самостоятельно. «Комбинацию отказов, которую нужно выполнить, чтобы споткнуться, очень сложно реализовать самостоятельно, и она уникальна для каждого такого свойства».
Решение уникальных проблем тестирования в открытом исходном коде
Как сказал Сиаркович, ведущий специалист по сопровождению проекта с открытым исходным кодом, обучение членов сообщества тому, как проводить более надежное тестирование, является большой проблемой.
Проекты с открытым исходным кодом, отметил он, «похожи на дерево. …в начале основная часть является самой важной. Но по мере роста проекта появляется больше сообщества, они создают новые функции, новые вещи. Есть много людей, которые могут работать над листьями, но ядро обычно очень чувствительно, потому что оно связано со всем».
Когда дело доходит до долгосрочных проектов, таких как etcd или Kubernetes, ему нравится работать над ядром, стволом этих «деревьев». Но он признал, что эти основные части «не очень доступны для большинства участников, поэтому такой подход к тестированию может позволить сопровождающим писать правила, которые будут гарантировать, что, даже если сопровождающий допустит ошибку или не будет иметь достаточно времени, чтобы просмотреть что-то во всех подробностях, мы все равно сможем отловить это в тестировании».
Посмотрите полный выпуск, чтобы узнать больше о тестировании программного обеспечения с открытым исходным кодом, в том числе о роли, которую ИИ может сыграть в будущем, и о том, что находится в планах etcd.
Antithesis — это автономная платформа тестирования, которая находит ошибки в вашем программном обеспечении с идеальной воспроизводимостью и помогает вам их исправить. Он дополняет или заменяет существующие инструменты тестирования и работает вместе с обычным рабочим процессом CI. Узнайте больше ТЕНДЕНЦИОННЫЕ ИСТОРИИ YOUTUBE.COM/THENEWSTACK Технологии развиваются быстро, не пропустите ни одной серии. Подпишитесь на наш канал YouTube, чтобы смотреть все наши подкасты, интервью, демонстрации и многое другое. ПОДПИСАТЬСЯ Группа, созданная в Sketch. Хизер Джослин — главный редактор журнала The New Stack, специализирующаяся на вопросах управления и карьеры, которые актуальны для разработчиков программного обеспечения и инженеров. Ранее она работала главным редактором Container Solutions, консалтинговой компании Cloud Native… Подробнее от Хизер Джослин
