[Перевод] Тестирование программного обеспечения для космоса (интервью с разработчиком из SpaceX)
Stack Overflow побеседовал с Эрин Ишимотича, инженером в группе Software Delivery Engineering из Чокто Нейшн в Оклахоме. Ишимотича, работающая инженером на постоянной основе уже 15 лет, начала свою карьеру с написания скриптов shell и Perl, а в SpaceX работает уже около двух лет.
Проверять, проверять и еще раз проверять
Работа отдела Software Delivery Engineering, по словам Ишимотича, заключается в координации надлежащей практики разработки и тестирования программного обеспечения в компании SpaceX, обеспечивая, чтобы все, кто пишет код для космических аппаратов, использовали надлежащие методы контроля версий и проходили автоматизированное и человеческое тестирование, управляемое системой непрерывной интеграции (CI).
«Мы разрабатываем и поддерживаем нашу собственную систему CI», — сказала она. «У нас есть веб-служба, которая создает отчеты — она получает телеметрию от тестов программного и аппаратного обеспечения, строит графики и имеет свои собственные утверждения, которые она выполняет на основе данных, создавая отчет о том, как работает программное обеспечение».
Это означает, что специалисты из Software Delivery Engineering занимаются разработкой, тестированием и DevOps, в команде около 15 инженеров, включая специальную команду Software Reliability Engineering (SRE).
Контроль качества программного обеспечения для космических аппаратов отличается от обычных корпоративных или потребительских приложений. Требования к нему довольно высоки. «Вы можете посмотреть на классификацию программного обеспечения NASA — об этом есть много общедоступной информации. Мы делаем нечто подобное. Существует несколько различных стандартов качества, которые применяются к программному обеспечению, начиная от инструментов CI и заканчивая летным программным обеспечением, которое обеспечивает критически важные функции безопасности для экипажа».
В связи с этим есть много дополнительных вещей, которые нужно сделать в процессе разработки, прежде чем вам разрешат слияние», — говорит Ишимотича. «У нас много проверок и перепроверок. У нас есть правила ревью пул реквестов, которые должны быть выполнены, и даже тестирование после слияния, чтобы убедиться, что изменения, которые были сделаны, пока пул реквест находился в работе, не повлияют на изменения, которые мы только что слили».
Прикрываем друг друга
Процесс разработки, по-видимому, это agile, с проектированием на основе тестирования и несколькими инженерами, постепенно вносящими изменения в код.
«Большую часть времени мы работаем с концепцией ответственного инженера, который берет тикет — проблему — из бэклога». Затем ответственный инженер работает над проблемой, начиная с понимания сути проблемы и доводя ее до конца, возможно, даже развертывая новое программное обеспечение.«Если я беру тикет, я сначала изучаю проблему и пытаюсь ее воспроизвести. Затем я разрабатываю исправление или функцию, реализующую исправление, обеспечиваю покрытие тестами и функциональное тестирование в изолированной среде. Затем я делаю пул реквест на это исправление. Это моя обязанность — найти того, кто рассмотрит ПР».
Процесс не является законченным, когда ревью завершено. «Когда PR сливается, я отвечаю за то, чтобы следующий тест на мастере прошел в CI. А затем мы приступаем к верификации».
Среда CI основана на [HT Condor], системе управления рабочей нагрузкой для интенсивных вычислений, которая возникла в High Throughput Computing Group Висконсинского университета в Мэдисоне. Эта система ценится в SpaceX за ее мощные возможности управления очередями, приоритетами заданий и ресурсами — особенно для испытательных стендов HITL (Hardware-in-the-loop, подробнее о них позже).
Condor управляет рабочими нагрузками аналогично традиционной пакетной системе, но может лучше использовать незадействованные ресурсы компьютера. По словам Ишимотича, «мы выполняем около миллиона сборок CI в месяц».
Управление сборками и ракеты на столе
Платформа построена на PostgreSQL для управления метаданными о сборках, результатах тестирования и других артефактах, наряду с большим количеством Python и C/C++.
Python используется для запуска бэкенд-тестов, организации сборок, а также все наши веб-серверы основаны на Python. Это множество маленьких скриптов и множество больших веб-сервисов. Angular и JavaScript на веб-сервисах для фронтэнда, и немного Typescript, который очень хорош, я его большой поклонник.
Широко используется Docker, а также немного Kubernetes. «Docker часто используется для эфемерных сборок». Используя Docker, можно гарантировать, что каждая сборка выполняется в чистой среде. «Возможность поместить эти задания в Docker означает, что мы можем каждый раз отбрасывать побочные эффекты, что просто замечательно».
Мы поинтересовались, как в Software Delivery Engineering работают с оборудованием. «Мы не так часто работаем с оборудованием транспорта, как с оборудованием центров обработки данных», — сказал Ишимотича. «Мы постоянно перестраиваем рабочие системы и добавляем оборудование в систему CI. У нас около 550 малых, средних и больших воркеров, выполняющих различные виды работ. Маленький воркер имеет два ядра, а наши большие воркеры имеют 28 ядер и 32 гигабайта памяти».
Есть одна классная часть работы, которая связана с игрой на реальном оборудовании. «У нас также есть тонна испытательных стендов, подключенных к системе CI. Мы называем эти тесты HITLs, произносится «хиттлз», что означает «аппаратное обеспечение в цикле». Это единичные, сделанные на заказ, буквально все внутренности ракеты разложены на столе. У нее нет ни топливных баков, ни двигателей, но есть все бортовые компьютеры и датчики». Она рассмеялась. «У нас есть один для сидений на Dragon 2, и в нем есть приводы, мы можем перемещать сиденья». Вам не нужно быть ученым-ракетостроителем, чтобы стать инженером-испытателем, но довольно забавно быть инженером-испытателем, который работает с настоящими физическими ракетами.
У вас будет возможность разрабатывать софт разного уровня, тестировать, запускать в производство и видеть в действии готовые автомобильные изделия, к созданию которых вы приложили руку.
В компании организован специальный испытательный центр, дающий возможность проводить исследования в области управления ДВС, в том числе и в составе автомобиля. Испытательная лаборатория включает моторные боксы, барабанные стенды, температурную и климатическую установки, вибрационный стенд, камеру соляного тумана, рентгеновскую установку и другое специализированное оборудование.
Если вам интересно попробовать свои силы в решении тех задач, которые у нас есть, пишите в личку.
Мы, пожалуй, самый сильный в России центр компетенций по разработке автомобильной электроники. Сейчас активно растем и открыли много вакансий (порядка 30, в том числе в регионах), таких как инженер-программист, инженер-конструктор, ведущий инженер-разработчик (DSP-программист) и др.
У нас много интересных задач от автопроизводителей и концернов, двигающих индустрию. Если хотите расти, как специалист, и учиться у лучших, будем рады видеть вас в нашей команде. Также мы готовы делиться экспертизой, самым важным что происходит в automotive. Задавайте нам любые вопросы, ответим, пообсуждаем.
