Привет, Хабр! Меня зовут Роман, и я хочу сегодня рассказать о том, как мы в Университете Иннополис разрабатывали тестовый стенд и сервис для системы Acronis Active Restore, которая вскоре должна стать частью продуктовой линейки компании.
Приглашаю всех, кому интересно, как строятся отношения университета с индустриальными партнёрами, следовать за котом.
Разработка Active Restore началась в рамках Acronis, но мы, будучи студентами Университета Иннополис, приняли участие в этом процессе в рамках образовательного промышленного проекта.
О самой идее, а также об архитектуре уже писал мой куратор (а теперь и коллега) Даулет Тумбаев.
в твоем посте .
Сегодня я расскажу о том, как мы готовили сервис от Иннополиса.
Все началось летом, когда нам сообщили, что в первом семестре к нам придут IT-компании и предложат свои идеи для практической работы.
И вот в декабре 2018 года нам представили 15 разных проектов, а в конце месяца мы расставили приоритеты и выяснили, кому что больше нравится.
Все магистранты заполнили форму, в которой нам нужно было выбрать четыре проекта, в которых мы хотели бы участвовать.
Нужно было мотивировать, почему я и почему эти проекты.
Например, я указал, что уже имею опыт системного программирования и разработки на языках C/C++.
Но главное, что проект позволил мне развивать свои навыки и продолжать расти.
Через две недели нас распределили, и с начала второго семестра началась работа над проектами.
Команда была сформирована, на первой встрече мы оценили сильные и слабые стороны друг друга и распределили роли.
- Роман Рыбкин — разработчик Python/C++.
- Евгений Ишутин — разработчик Python/C++, отвечающий за взаимодействие с компанией.
- Анастасия Родионова — разработчик Python/C++, отвечающий за написание документации.
- Брэндон Акоста — настройка среды, подготовка стенда для экспериментов и тестирования.
Наладили контакты с заказчиком, формализовали требования к проекту, запустили итерационный процесс, настроили рабочую среду.
Кстати, наша работа с заказчиком по-настоящему закипела, когда у нас начались факультативы.
Дело в том, что Акронис преподает факультативные предметы в Университете Иннополис (и не только).
А Алексей Костюшко, ведущий разработчик команды Kernel, на постоянной основе ведет два курса: «Реверс-инжиниринг» и «Архитектура ядра Windows и драйверы».
Насколько я знаю, в будущем также планируется курс по системному программированию и многопоточным вычислениям.
Но главное, что все эти курсы построены таким образом, чтобы помочь студентам справиться с промышленными проектами.
Они серьезно улучшают ваше понимание предметной области и тем самым упрощают работу над проектом.
Благодаря этому мы стартовали более энергично, чем другие команды, а взаимодействие с самим Acronis стало более тесным.
Владельцем продукта у нас выступил Алексей Костюшко, от него мы получили необходимые знания в предметной области.
Благодаря его факультативам наши навыки и компетенции значительно улучшились, и мы стали по-настоящему готовы выполнить поставленную перед нами задачу.
От мыслей к проекту
Первый месяц был крайне трудным для всех команд. Все терялись, не знали, с чего начать — может, с документов или, наоборот, с погружения в код. Поначалу противоречивые комментарии звучали от кураторов и наставников университета и представителей компаний.Когда все встало на свои места (по крайней мере, в моей голове), стало понятно, что выстроить внутренние взаимоотношения в команде и подготовить документы нам помогли наставники из университета.
Но настоящим прорывом стал приезд Даулета в марте.
Мы просто сели и работали над проектом все выходные.
Потом мы переосмыслили суть проекта, перезагрузились, перераспределили приоритеты задач и быстро полетели вперед. Мы поняли, что нужно сделать для запуска эксперимента (подробнее об этом ниже) и развития сервиса.
С этого момента общая идея превратилась в четкий план.
Началась настоящая разработка кода, и за 2 недели мы разработали первую версию тестового стенда, включая виртуальные машины, необходимые сервисы и код для автоматизации эксперимента и сбора данных.
Стоит отметить, что параллельно с индустриальным проектом проходили обучающие курсы, которые помогли нам построить грамотную архитектуру наших проектов и организовать Управление качеством.
Поначалу эти задачи занимали 70-90% времени в неделю, но, как оказалось, вложения времени были необходимы, чтобы избежать проблем в процессе разработки.
Целью университета было, чтобы мы научились грамотно структурировать процесс разработки, а компании как заказчики были больше заинтересованы в результате.
Это, конечно, принесло много суматохи, но помогло совместить теоретические и практические навыки.
Достаточная сложность и загруженность обеспечили мотивацию, в результате которой проект стал успешным.
Изначально в нашей команде два человека занимались чистой разработкой, один человек брал на себя документацию, а другой погружался в настройку среды.
Однако позже к нам присоединились еще трое холостяков, с которыми мы стали единой командой.
В университете решили запустить тестовый индустриальный проект для студентов третьего курса.
Расширение команды с 4 до 7 человек значительно ускорило процесс, потому что наши бакалавры могли легко выполнять задачи, связанные с разработкой.
Екатерина Левченко помогла с написанием Python-кода и пакетных скриптов для тестового стенда.
Разработчиками выступили Ансат Абиров и Руслан Ким, они занимались выбором и оптимизацией алгоритмов.
В таком формате мы работали до конца мая, когда эксперимент был запущен.
В этот момент индустриальный проект для бакалавров закончился.
Двое из них прошли стажировку в Acronis и продолжили работать с нами.
Поэтому после мая мы работали одной командой из 6 человек.
Перед нами был третий семестр, который в Иннополисе свободен от академической деятельности.
У нас было всего 2 факультатива, а остальное время ушло на промпроект. Именно в третьем семестре интенсивно началась работа над сервисом.
Процесс разработки идет полным ходом, демо-версии и отчеты стали регулярными.
В таком формате мы работали 1,5 месяца и в конце июля практически завершили разработку.
Технические детали
Сначала были сформулированы требования к сервису, который должен адекватно взаимодействовать с драйвером минифильтра файловой системы (что это такое можно прочитать здесь).здесь ) и его архитектура продумана.
Позаботившись о простоте дальнейшей поддержки кода, мы сразу предусмотрели модульный подход. Наш сервис включает в себя несколько менеджеров, агентов и обработчиков, причем еще до начала кодирования была встроена возможность работы в параллельном режиме.
Однако после обсуждения архитектуры на встрече с ребятами из Acronis было решено сначала провести эксперимент, а потом уже работать над самим сервисом.
В результате разработка заняла всего 2,5 месяца.
В остальное время мы проводили эксперимент по поиску минимально достаточного списка файлов, на которых можно было бы запустить Windows. В реальной системе этот набор файлов генерируется с помощью драйвера, однако мы решили найти этот набор эвристически, методом деления пополам, чтобы проверить работу драйвера.
Стенд для экспериментов.
Для этого мы собрали тестовый стенд Python из двух виртуальных машин.
Один из них работал под управлением Linux, а второй загружал Windows. Для них было настроено два диска: Virtual HD1 и Virtual HD2. Оба диска были подключены к ВМ1, на которой был установлен Linux. На этой виртуальной машине на HD1 было установлено приложение Killer, которое «повредило» HD2. Под повреждением мы подразумеваем удаление некоторых файлов с диска.
HD2 был загрузочным диском для VM2, на которой работала Windows. После того, как диск был «повреждён», мы попытались запустить ВМ2. Если это было возможно, то удаленные с диска файлы считались ненужными для запуска.
Чтобы автоматизировать этот процесс, мы постарались удалять файлы не случайным образом, а в рамках заранее запланированного подхода.
Алгоритм состоял из 3 шагов:
- Разделите список файлов пополам.
- Удалите одну из половин файлов.
- Попробуйте запустить систему.
Если система запустилась, то добавьте удаленные файлы в список ненужных.
В противном случае вернитесь к шагу 1.
Предположим, в файловой системе 1 000 000 файлов.
При этом наиболее эффективный поиск критических файлов происходил в тех случаях, когда критических файлов было около 15% от общего числа.
Метод половинного деления.
Поначалу с экспериментом было много проблем.
Испытательный стенд был готов через 2-3 недели.
И еще 1-1,5 месяца ушло на то, чтобы отловить баги, добавить код и применить разные хитрости, чтобы стенд заработал.
Сложнее всего было поймать баг, связанный с кэшированием дисковых операций.
Эксперимент длился два дня и дал очень оптимистичные результаты, которые оказались во много раз быстрее, чем при моделировании.
Однако проверка критических файлов не удалась, и система не запустилась.
Оказалось, что при принудительном выключении виртуальной машины не выполнялись операции удаления, которые были закешированы файловой системой, и, соответственно, диск не очищался полностью.
В результате алгоритм получал неверные результаты, и мы пару дней напрягали весь мозг, чтобы во всем этом разобраться.
В определенный момент мы заметили, что при длительной работе алгоритм зарылся в один из сегментов файловой системы и начал пытаться удалить одни и те же файлы (надеясь на новый результат).
Это происходило в моменты, когда алгоритм упирался в регионы, где их было больше всего, и при этом выбирал неправильный интервал для удаления.
На этом этапе мы решили добавить перестановку списка файлов.
То есть каждые несколько итераций список файлов перемешивался.
Это помогло вывести алгоритм из тупика.
Когда все было готово, мы запустили эти две ВМ на 3 дня.
Всего было проведено около 600 итераций, среди которых более 20 успешных запусков.
Стало ясно, что этот эксперимент можно проводить долго, а также на более мощных машинах, чтобы найти оптимальный размер файлов для запуска Windows. Также работу алгоритма можно распределить на несколько машин, чтобы еще больше ускорить этот процесс.
В нашем случае кроме Windows на диске находился только Python и наш сервис.
За три дня нам удалось сократить количество файлов с 70 тысяч до 50 тысяч.
Список файлов сократился всего на 28%, но стало понятно, что такой подход работает и позволяет определить минимальный набор файлов, необходимый для загрузки ОС.
Структура обслуживания
Коснемся немного структуры сервиса.Основным модулем сервиса является менеджер очередей.
Поскольку мы получаем список файлов от драйвера, нам необходимо восстановить файлы по этому списку.
Для этого мы создали собственную очередь с приоритетами.
У нас есть список файлов, которые восстанавливаются один за другим.
А если появляются новые запросы доступа, срочно необходимые файлы восстанавливаются в приоритетном порядке.
Благодаря этому в начале очереди будут те файлы, которые действительно нужны пользователю сейчас, а в конце очереди будут те файлы, которые могут понадобиться в будущем.
Но когда пользователь активно работает, может образоваться «очередь неупорядоченных объектов», а также список файлов, которые восстанавливаются прямо сейчас.
Кроме того, операцию поиска пришлось применить ко всем этим очередям сразу.
Увы, мы не нашли реализацию очереди, которая могла бы устанавливать несколько приоритетов файлов, поддерживая при этом поиск, а также меняя приоритеты на лету.
Мы не хотели адаптироваться к существующим структурам данных, поэтому пришлось написать свою и настроить возможность работы с ней.
Нашему сервису придется общаться сначала с драйвером, над которым работал Даулет, а уже после с компонентами, отвечающими за восстановление файлов.
Поэтому для начала мы решили сделать свой небольшой эмулятор системы восстановления, который мог бы выводить файлы из внешний диск, чтобы их можно было восстановить и протестировать службу.
Всего было предусмотрено два режима работы – обычный и режим восстановления.
В обычном режиме драйвер отправляет нам список затронутых файлов при запуске ОС.
Затем, пока система работает, драйвер отслеживает все операции с файлами и отправляет уведомления нашему сервису, а тот, в свою очередь, меняет список файлов.
В режиме восстановления драйвер уведомляет службу о необходимости восстановления системы.
Служба формирует очередь файлов, запускает программные агенты, запрашивающие файлы из резервной копии, и начинает процесс восстановления.
Диплом, предложение о работе и новые проекты
Когда сервис был готов и протестирован, нам осталась последняя активность по проекту.Необходимо было обновить и структурировать все артефакты, которые мы накопили, а также представить наши результаты заказчику и вузу.
Для компании это был очередной шаг к реализации проекта, для университета – наша дипломная работа.
По итогам презентации студентам было сделано предложение.
И через несколько недель я начну работать в Acronis. Результаты проекта привели разработчиков к мысли, что сервис можно сделать более эффективным, понизив его до уровня Native Windows Application. Но об этом в следующей статье.
Теги: #Разработка для Windows #вирусы #Резервное копирование #разработка #innopolis #аварийное восстановление #Acronis
-
Н.м.д. (Это Не Мое Дело)
19 Oct, 24 -
День Святого Патрика
19 Oct, 24 -
На Лифте В Космос - 2009. Итоги
19 Oct, 24 -
Apple Iad – Пользовательский Опыт
19 Oct, 24
