Результаты наблюдений над ошибками, исправлениями и доверие к зависимым системам
Каждые две недели я получаю вопросы такого рода: “я должен проверять контрольную сумму файлов приложений, при условии, что диск уже имеет коррекцию ошибок?” или “если протоколы TCP/IP имеет систему исправления ошибок в каждом пакете данных, зачем мне нужна система исправления ошибок на уровне приложения?” Вот еще один часто задаваемый вопрос: “материнские платы без системы ECC (Error Correction Code) намного дешевле – нам действительно нужна система ECC в памяти?”
Ответы на эти вопросы будет всегда положительным. Как правило, системам обнаружения и исправления ошибок на более низком уровне не удается исправлять, или даже обнаруживать некоторые проблемы. Программное обеспечение (ПО) вносит ошибки, аппаратное обеспечение вносит еще больше ошибок, встроенное ПО вносит ошибки. Ошибки закрадываются везде и абсолютно никому нельзя доверять.
На протяжении многих лет, всякий раз, когда у меня была возможность видеть результат добавления нового уровня системы обнаружения ошибок, он был одинаковым. Она срабатывает быстро и часто. В каждом из этих случаев, я предсказывал, что мы будем находить проблемы. Но даже со своей стороны, я всегда поражался частоте срабатывания системы исправления ошибок.
В один конечный серверный продукт высокого уровня, с которым мне приходилось работать, была на время добавлена функция проверки контрольной суммы страниц в течение ограниченного бета-выпуска. Система исправления ошибок срабатывала постоянно, и пользователи жаловались, что в этой новой бета-версии “так много ошибок, что они не могут с ней работать”. После глубокого исследования было обнаружено, что с ПО все в порядке, но у каждого пользователя было несколько, латентных искажений данных на диске. Может быть, они были созданы аппаратным обеспечением, может быть, встроенным ПО, или же ПО. Эти искажения даже могли быть созданы одной из наших четырех предыдущих версий, когда эти страницы в последний раз переписывались. Некоторые из этих страниц, наверное, не переписывались годами.
Я был поражен количеством обнаруженных искажений и начал думать над тем, как часто мне приходилось встречаться с “искажениями индекса” или другими известными проблемами, которые, вероятно, были внесены в программное или аппаратное обеспечение еще до нас. Диски имеют сложное аппаратное обеспечение и сотни тысяч строк кода, тогда как сети SAN имеет сложные каналы передачи данных и более миллиона строк кода. Драйверы устройств имеют десятки тысяч строк кода. Операционные системы имеют миллионы строк кода. И наше приложение имеет миллионы строк кода. И любой из нас мог напортачить, у каждого была возможность сделать ошибку, и есть большая вероятность, что все эти миллионы строк кода никогда не тестировались в той комбинации и на том аппаратном обеспечении, которые любой данный пользователь использует в настоящее время.
Другой пример. В этом случае, парк из десяти тысяч серверов был выделен для контроля частоты исправления ошибок DRAM ECC. На протяжении нескольких месяцев результаты были поразительными и в то же время пугающими. ECC срабатывала постоянно.
Все это подтверждает обязательность использования систем ECC в серверном приложении и нужно быть почти сумасшедшим, чтобы даже допускать мысль об использовании ценных приложений без систем с ECC. В дополнение к этому следует поинтересоваться, чем же в действительности отличаются клиенты? Серверы в основном имеют системы ECC, но в большей части клиентов они отсутствуют. DRAM клиента не лучше и, фактически, зачастую хуже в некоторых отношениях. В клиентских системах искажение данных случается ежедневно. Каждый день клиентские данные незаметно искажаются. Ежедневно приложения выходят из строя без явных причин. В общем, дополнительная стоимость cистемы ECC асимптотически приближается к стоимости дополнительной памяти для размещения ECC. Я годами доказывал, что Майкрософт должна требовать включения системы ECC в Windows Hardware Certification для всех систем, включая клиентские приложения.
Это будет хорошо для экосистемы и будет устранять главный источник недовольства пользователей. В сущности, именно это соображение привело к тому, что большинство встроенных систем поддерживают систему ECC. Никто не хочет, чтобы их автомобиль, камера или телевизор вышел из строя. При условии, что в крупных масштабах стоимость является низкой, память с поддержкой ECC должна быть во всех клиентских системах.
Вот интересный пример из области космических полетов. Он привлек мое внимание, и я начал искать дополнительную информацию по этой теме, и стал учиться на каждом шагу. Фобос-Грунт был российским космическим зондом, который предназначался, среди других задач, для сбора образцов грунта со спутника Марса Фобоса. Он был запущен вместе с ракетоносителем Зенит-2SB с космодрома Бойконур 2:16 am 9 ноября 2011 г. 24 ноября официально сообщили, что миссия провалилась и зонд застрял на нижней земной орбите. Впоследствии спутник упал на землю, и это стало концом очень дорогостоящей миссии.
Что же произошло на борту Фобоса? 3 февраля был выпущен официальный отчет об аварии: Основные положения заключения межведомственной комиссии по анализу причин нештатной ситуации, возникших в процессе летных испытаний космического аппарата «Фобос-Грунт». Конечно же, этот документ был на русском языке, но Google Translate обычно очень хорошо справляется с переводом. Также, IEEE Spectrum Magazine сообщил об аварии. Статья IEEE, Плохие микросхемы памяти привели к аварии русского марсианского зонда, дает неплохое описание аварийной ситуации, а переведенная русская статья содержит дополнительные данные, если вы хотите знать больше о ситуации.
Согласно содержащимся в отчете выводам, на борту корабля ‘Фобос-Грунт’ произошел двойной сбой памяти. По существу, оба компьютера в модуле с двойным резервированием вышли из строя в одно и то же время, или почти одновременно со сбоем SRAM. Компьютер был частью недавно разработанной системы управления полетами, который ориентировался на уменьшение массы систем управления полетами с 30 кг до 1.5 кг. Снижение веса системы управления полетами означает повышение полезной нагрузки, поэтому эти достижения являются важными. Тем не менее, эта новая система управления полетами виновата в задержке миссии на 2 года и последующем провале миссии.
Оба эти компьютера системы управления полетами являются идентичными комплектами вычислительных систем ЦВМ22, поставляемыми компанией Техком, отделившейся от конструкторского бюро Аргон (проект ‘Фобос-Грунт’). В официальном отчете о причинах происшедшего сообщается, что в обоих компьютерах произошел сбой в WS512K32V20G24M SRAM. Эти модули SRAMS изготавливаются White Electronic Design, а номер модели расшифровывается следующим образом: “W” обозначает White Electronic Design, “S” — SRAM, “512K32” – 32-битную память размером 512 килобайт, “V” — знак улучшения, “20” – время обращения к памяти 20 нс, “G24” – тип пакета ПО, а “M” указывает, что это устройство военного класса.
В работе «Высокий уровень восприимчивости к ‘защелкиванию‘ в современных коммерческо-стандартных (COTS) монолитных КМОП-устройствах статической ОЗУ 1M и 4M (SRAM)» Джо Бенедетто пишет, что эти модули SRAM очень восприимчивы к “защелкиванию”, состоянию, которое требует повторения подачи электроэнергии для возобновления работы, и может быть постоянным в некоторых случаях. Стивен МакКлур из NASA Jet Propulsion Laboratory является руководителем Radiation Effects Group. Он сообщает, что эти модули SRAM вряд ли были бы одобрены для использования в JPL (Плохие микросхемы памяти привели к аварии русского марсианского зонда).
Редко когда даже два сбоя могут приводить к аварии и этот случай не стал исключением. После двойного сбоя систем управления полетом космический корабль автономно переходит в “безопасный режим”, при котором он пытается оставаться в пределах нижней земной орбиты и поворачивает свои солнечные батареи таким образом, чтобы иметь достаточное количество электроэнергии. Это общепринятое инженерное решение, которое позволяет системе автоматически стабилизироваться в чрезвычайной ситуации, чтобы дать сотрудникам наземного центра управления полетами время на принятие мер по уменьшению проблемы. В этом случае, решение проблемы могло довольно простым, и состояло в перезагрузке обоих компьютеров (что, наверное, произошло автоматически), и перезапуск миссии, наверное, был бы достаточным.
К сожалению, был еще один сбой, и это был аппаратный сбой. Когда космический летательный аппарат переходит в безопасный режим, он не может общаться с наземными станциями, что, наверное, обусловлено его ориентацией. В сущности, если система вынуждена переходить в безопасный режим, в то время как она все еще находится в пределах земной орбиты, миссию можно считать проваленной, так как наземный центр управления полетами никогда не сможет вывести летательный аппарат из безопасного режима.
Я узнал, что этот последний сбой был очень интересным. Люди никогда не смогли бы допустить такой явной ошибки, и, тем не менее, именно этот вид технических дефектов постоянно встречается в больших системах. Эксперты в каждой вертикальной зоне или компоненте хорошо выполняют свою работу. Но взаимодействие вертикальных зон является сложным и, в отсутствие достаточно глубокой, перекрестной технической экспертизы, эти технические дефекты могут оставаться незамеченными. Хорошие специалисты проектируют неплохие компоненты и, все-таки зачастую в компонентах пропускаются явные ошибки.
Системы, которые являются достаточно сложными для того чтобы требовать глубокой вертикальной специализации, повержены риску слепоты, обусловленной этой сложностью. Каждая вертикальная команда хорошо знает свой компонент, но никто не понимает взаимодействия всех компонентов. Есть два решения проблемы, а именно, 1) присутствие хорошо продуманных и хорошо описанных интерфейсов между компонентами, будь то аппаратное или программное обеспечение 2) присутствие очень опытных, высококвалифицированных инженеров в команде, которые занимаются проблемами межкомпонентного взаимодействия и общего функционирования системы, особенно в аварийных ситуациях. Поручение этой ответственной задачи старшему менеджеру зачастую является недостаточно эффективным.
Ошибки, которые вытекают из слепоты, обусловленной сложностью системы, зачастую являются серьезными и кажутся удивительно простыми в ретроспективе, как в этом случае.
Вот некоторые выводы, которые можно сделать из этой аварии: микросхема SRAM, наверное, была плохо подобрана. Компьютерные системы должны перезагружаться, проверять память на наличие ошибок, и быть способными обнаруживать и загружать искаженный код из второстепенных размещений перед переходом в безопасный режим. По сути дела, безопасный режим должен позволять наземным станциям выполнять корректирующие действия, иначе он был бы бесполезным. Программные системы должны постоянно проверять память на наличие ошибок, а также проверять контрольную сумму работающей программы с целью выявления искажений. Очень небольшое количество ресурсов процессора, расходуемых на непрерывные, избыточные проверки, а также несколько дополнительных строк кода для реализации простых путей исправления ошибок в случае обнаружения ошибки, могли бы спасти миссию. Наконец, все мы должны помнить старую аксиому, согласно которой “ничего не будет работать, если оно не проверено”. Все крупные ошибки должны подвергаться тестированию. Пути исправления ошибок, как правило, не тестируются, поэтому особое внимание необходимо обращать именно на них. Общим правило состоит в том, что пути исправления ошибок должны быть простыми, быть максимально ограниченными по своему числу, и часто тестироваться.
Еще в 2007 году я написал ряд пособий по разработке, тестированию и функционированию программного обеспечения систем крупного масштаба: О разработке и развертывании интернет-сервисов. Эта работа касается крупномасштабных сервисов, но меня самого удивило, что некоторые, а может быть и многие, из предложений можно было бы успешно применять к сложным системам управления космическими полетами. Общей темой для этих двух только отчасти связанных областей является то, что их самым главным врагом является сложность, и все растущее число ошибок, вытекающей из этой сложности.
Этот случай напоминает нам о том, что никогда нельзя быть уверенным в надежной работе компонентов в многокомпонентной системе. Следует проверять контрольную сумму каждого блока данных и располагать хорошо продуманными и хорошо проверенными режимами исправления ошибок даже для маловероятных ситуаций. Вместо сложной логической схемы исправления ошибок для практически бесконечного числа возможных ошибок, лучше иметь грубые, простые методы исправления ошибок, которые можно широко применять и часто тестировать.
Не следует забывать, что все аппаратное обеспечение, все встроенное ПО, и все программное обеспечение может иметь и создавать ошибки. Не доверяйте никому и ничему. Используйте тестовые системы, которые могут обнаруживать сбои и искажения и гарантировать безошибочную работу рабочей системы – как правило, редкие ситуации случаются удивительно часто.
Дополнительные сведения по аварии спутника Фобос-Грунт см. здесь:
- Статья в журнале IEEE Spectrum: http://spectrum.ieee.org/aerospace/space-flight/did-bad-memory-chips-down-russias-mars-probe
- Официальный отчет о причинах аварии на русском языке: http://www.roscosmos.ru/main.php?id=2&nid=18647
- Статья на Russian Space Web:
Автор статьи James Hamilton член команды Amazon Web Services.
Статья опубликована с разрешения автора.
Оригинал статьи находится:
Блог James Hamilton:
Сообщения, вопросы и ответы
Вы можете задать вопрос, написать комментарий, обсудить данную новость или статью.