Новое видение ремонта компьютеров

1. Введение

Сегодня, когда люди нуждаются в ремонте своих компьютеров, их процесс не сильно отличается от найма кого-то, чтобы установить телевизор: они либо приносят компьютер в ремонтную службу [1, 3], либо звонят технику (или члену семьи) и спрашивают для домашнего звонка. Этот процесс неудобен. Это также подвергает риску конфиденциальность данных клиентов и целостность их систем: службы ремонта получили известность за кражу персональных данных от клиентов [22] или иным образом вторгаются в их конфиденциальность [7].
Удаленные рабочие столы [2, 4, 5] избегают физического перемещения, но все же требуют, чтобы клиент сделал выбор. Клиент может проводить время и следить за ремонтом (хотя многие клиенты ремонтных служб, вероятно, не имеют технической поддержки для обнаружения ложных действий в первую очередь). Или клиент может сэкономить время и проигнорировать ремонтника, предоставив ему карт-бланш, точно так же, как если бы компьютер находился в магазине. Ни один выбор не кажется большим.
Цель этой статьи - сформулировать новое видение ремонта. Это видение мотивировано тремя тенденциями:
• Ремонт программного обеспечения. Мы рассмотрели услуги по розничному ремонту и выяснили, что в настоящее время значительная часть ремонтных работ включает только изменения программного обеспечения (§2). Такой ремонт по своей сути не требует путешествия.
• Виртуальные машины. Многие компьютеры сегодня, даже настольные компьютеры, включают технологию виртуализации, которая позволяет клиентам отправлять свои компьютеры в электронном виде [9, 19] (путем отправки изображения виртуальной машины) и обеспечивать гарантии от ремонта (путем реализации защиты на мониторе виртуальной машины).
• Аутсорсинг. Поставщики услуг уже давно предлагают услуги с добавленной стоимостью, такие как управление настольными системами и ИТ-консалтинг. В последнее время товарные вычисления следуют аналогичным путем, переходя к хорошо зарекомендовавшим себя, за пределами сайта, частично анонимным поставщикам услуг (часто называемым облаком).

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

Обратите внимание, что в контексте данного видения является Розничный ремонт, в отличие от Учебной работы по устранению неполадок [8, 11, 14, 15, 17, 18, 20, 21, 23, 25-28]. Там опытный системный администратор сталкивается со сложной проблемой конфигурации (скажем, тонко неправильный маркер в httpd.Этот человек доверяет средство устранения неполадок (или это одно и то же лицо). В нашей установке, однако, пользователи неопытны (настолько, что они не смогут использовать приведенные выше инструменты), проблемы относительно легки для средства устранения неполадок (как указано в нашем опросе), и клиент не полностью доверяет ремонтнику. Таким образом, технические проблемы в нашем сценарии различны (хотя описанные выше инструменты были бы полезны ремонтнику, так что они дополняют нашу работу).

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

Ключевым компонентом решения этих задач является богатая литература по отслеживанию зависимостей[8, 15, 17, 18, 20, 21, 23, 28] и, в частности, избирательное повтор [11, 14], которое мы (иронично) используем для защиты от ремонтника. Мы займем и другие работы, включая миграцию виртуальных машин [6, 10, 19].

Есть также новые проблемы, чтобы решить: защита конфиденциальности клиентов, позволяя ремонтник работать, статически проверки ремонта, слияния изменений ремонтника с пользователем, отслеживания зависимостей между обновлениями ОС, согласованно составляя вышеупомянутые и многое другое. Однако у нас пока нет полноценных решений. Скорее, основной вклад этого документа заключается в формулировании как видения, так и повестки дня исследований, которые должны быть рассмотрены для его реализации. Вторичные взносы направлены на розничный ремонт (что подразумевает новую модель: легкий ремонт, но ненадежные ремонтники) и проведение расследования текущих услуг розничного ремонта, о чем мы сообщаем далее.

2 Запрос на розничный ремонт

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

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

(1) телефонные исследования лучших отрядов Buy Geek в Остине и вокруг него;

(2) incognito посещает шесть баров Apple Genius; и 

(3) анализ 18 месяцев проблемы билетов обрабатываются UT Austin в информационных технологических службах.

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

Почти все респонденты первого этапа заявили, что аппаратные проблемы были относительно необычными, хотя они варьировались в своих оценках точной доли ремонта оборудования и программного обеспечения. Мы также слышали от каждого агента, что они переустановили ОС менее чем в 20% случаев. Без исключения, агенты назвали вирусы наиболее распространенной проблемой клиентов. Как правило, агент Geek Squad сталкивается с вредоносной инфекцией. После диагностики проблемы агент использует собственные средства, которые пытаются очистить компьютер клиента, как правило, без переустановки операционной системы.

Вторая фаза была более строгой. Она состояла из десяти вопросов по пятибалльной шкале, и половина опросов проводилась кем-то, кто не является одним из авторов и кто не знал наших гипотез о том, какие ремонты наиболее распространены. Из восемнадцати магазинов, которые мы называли, агенты в одиннадцать согласились участвовать.

На рисунке 1 приведена вторая фаза. Ремонт программного обеспечения, по-видимому, распространены. Действительно, глядя на отдельные ответы, девять из одиннадцати оценили “внесение изменений в реестр или другие параметры” по крайней мере так высоко (по частоте), как “замена жесткого диска или другого аппаратного компонента”. И ремонты на уровне приложений появляются чаще, чем переустановки ОС: девять из десяти номинальных “внесение изменений в реестр или другие параметры”, по крайней мере, так высоко, как “переустановка операционной системы” (это было девять из десяти, а не одиннадцать, потому что аппаратные проблемы с изменением параметров, хотя они также переустановить ОС довольно часто-большинство из которых согласуется с опросами. В отличие от выродков, гении были непреклонны в том, что никогда не видели вредоносных программ.

Вышеуказанные результаты, очевидно, не являются научными, но они подкреплены гораздо большим набором данных. Мы получили анонимную 111,824 заявками на 1 января 2009 года по 8 июня 2010 г., от центрального информационно-технического обслуживания УТ Остин, которая предоставляет широкий спектр ИТ-поддержки 75000 студентов, преподавателей и сотрудников. Мы хотели знать, какой процент ремонтов связан с программным обеспечением и аппаратным обеспечением. Мы отфильтровали билеты проблемы, чтобы удалить проблемы, не связанные с ремонтом (такие как сетевое администрирование учетной записи и “как-к” вопросы). Из оставшихся 15 572 билетов, разбивка 76% программного обеспечения, 24% аппаратного обеспечения.

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

3 Модель и архитектура

Теперь мы описываем нашу модель и архитектуру, перенося сопутствующие вызовы на следующий раздел. Напомним, что в нашей розничной установке ремонта ремонт часто бывает простым, клиенты технически неопытны, а ремонтнику не доверяют. Таким образом, наша модель не предполагает, что ремонтник действует правильно: случайно или умышленно, он может попытаться сделать ложный ремонт или нарушить конфиденциальность клиента. Предположение нашей модели, в этом разделе и в большинстве следующих, заключается в том, что для ремонта не требуется изменять ядро, установленное в системе клиента. Это ограничение упрощает некоторые проблемы, и он опирается на эмпирические исследования. С другой стороны, ограничение является значительным, и мы рассмотрим его позже (в §4.4). 

Рисунок 2. Архитектура ремонта со стула.

На рисунке 2 изображена наша предполагаемая архитектура. Компьютер клиента-это виртуальная машина (VM), однако в обычной работе он не должен работать на мониторе виртуальной машины (VMM). Файлы клиента разделяются на публичные и частные. (Мы рассматриваем возможность такого разделения в §4.1.) Общедоступная часть включает приложения, конфигурацию системы, двоичные файлы и модули ядра. Закрытая часть содержит данные клиента.

4 проблемы и исследования

4.1 Конфиденциальность

Для диагностики и устранения проблем ремонтники иногда должны видеть личные файлы. Например, конфиденциальные данные могут находиться в файлах конфигурации, участвующих в восстановлении [13]. По этой причине и другие, конфиденциальность вызывает проблемы. Для их решения, мы пройдемся по ряду инструментов. Эти инструменты технически не изощренны, но то, что они кажутся достаточными, само по себе интересно (по крайней мере, на рисунке 2—архитектура ремонта со стула.

Пока клиент работает, гостевая Операционная система отслеживает действия и зависимости [8, 11, 14, 15, 17, 18, 20, 21, 23, 28]; это отслеживание имеет несколько применений в нашей архитектуре. Наш выбор кодирования-это график истории действий, график зависимостей, предложенный Ретро [14], который хранит все содержимое действий, а не только причинно-следственные связи между ними, делая селективное повтор точным и эффективным. Система заказчика также содержит помощник по ремонту, который делится на часть VMM и часть гостевой ОС.

Когда клиенту требуется ремонт, часть VMM помощника по ремонту использует технологию миграции виртуальных машин [6, 10, 19] для отправки ремонтнику копии файловой системы с закрытой частью, ослепленной. Простой способ реализации ослепления-не отправлять данные; другой способ-шифровать их. Когда ремонтник хочет получить доступ к личным данным, он обращается с запросом к клиенту, который таким образом может дать осознанное согласие (или отказаться). Клиент может выборочно дебитировать отдельные файлы и группы из них эффективно.

Ремонтник осуществляет ремонт внутри изображения, как оно работает на ВММ. Обратите внимание, что действия ремонтировщика должны генерировать график истории действий (так как клиентская ОС отслеживает зависимости и так как ремонтировщик не должен вносить изменения в ядро). Фактически ремонтник должен кодировать любое восстановление как график истории действий, так как часть операционной системы помощника по ремонту клиента ожидает подграф истории действий (а не, скажем, новое изображение). Учитывая этот подграф, часть операционной системы помощника по восстановлению клиента 

(1) проверяет, что действия представляют собой допустимые исправления (например, что они не изменяют ядро или что они соответствуют определенному списку применимых исправлений);

(2) оставляет дверь открытой, чтобы откатить действия ремонтника (если ремонт позже будет признан ложным) без отбрасывания после ремонта изменений клиента; и сливает действия ремонтника с любыми изменениями, которые клиент сделал во время работы во время ремонта.

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