существует ли язык защиты от стихийных бедствий? - PullRequest
41 голосов
/ 10 сентября 2009

При создании системных служб, которые должны иметь высокую надежность, я часто заканчиваю тем, что пишу множество «отказоустойчивых» механизмов в случае таких вещей, как: потеря связи (например, связь с БД), что произойдет, если питание теряется, а служба перезапускается .... как собирать куски и продолжать правильно (и помнить, что при подборе кусков сила может снова уйти ...) и т. д. и т. д.

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

Это уже существует? Если так, где я могу найти это? Если нет, то почему это не может быть реализовано? Мне кажется, это очень удобно для критических систем.

p.s. В случае потери соединения с БД это будет означать, что возникла проблема, и необходимо ручное вмешательство. В тот момент, когда соединение восстановится, оно продолжит с того места, где остановилось.

EDIT: Поскольку обсуждение, похоже, прошло, позвольте мне добавить несколько моментов (пока я жду, прежде чем смогу добавить награду к вопросу)

Отклик Эрланга сейчас, похоже, самый высокий. Я знаю об Эрланге и читал прагматичную книгу Армстронга (основного создателя). Это все очень хорошо (хотя функциональные языки заставляют мою голову вращаться при всей рекурсии), но бит «отказоустойчивый» не приходит автоматически. Отнюдь не. Erlang предлагает множество супервизоров и других методологий для контроля процесса и его перезапуска в случае необходимости. Тем не менее, чтобы правильно сделать что-то, что работает с этими структурами, вам нужно быть настоящим гуру erlang, и вам нужно, чтобы ваше программное обеспечение соответствовало всем этим фреймворкам. Кроме того, если питание падает, программист тоже должен собрать кусочки и попытаться восстановить при следующем запуске программы

То, что я ищу, является чем-то гораздо более простым:

Представьте себе язык (такой простой, как, например, PHP), где вы можете делать такие вещи, как запросы к БД, выполнять над ними действия, выполнять операции с файлами, выполнять операции с папками и т. Д.

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

И последнее, но не менее важное: если соединение с БД прерывается и не может быть восстановлено, язык просто останавливается и сигнализирует (возможно, syslog) о вмешательстве человека, а затем продолжает с того места, где он остановился.

Такой язык значительно упростил бы программирование многих сервисов.

EDIT: Кажется (судя по всем комментариям и ответам), что такой системы не существует. И, вероятно, не будет в ближайшем обозримом будущем из-за невозможности получить (почти?) Право.

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

(или подход к контрольной точке, как указал один из комментаторов (как в видеоигре). Установите контрольную точку .... и, если программа умрет, перезапустите здесь в следующий раз.)

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

Я буду смотреть на создание своей собственной инфраструктуры (возможно, с постоянным состоянием и снимками), чтобы добавить функции, которые я ищу в .Net или другой виртуальной машине.

Всем спасибо за вклад и отличные идеи.

Ответы [ 28 ]

59 голосов
/ 10 сентября 2009

Erlang был разработан для использования в телекоммуникационных системах, где высокое значение имеет фундаментальное значение. Я думаю, что у них есть стандартная методология для построения наборов коммуникационных процессов, в которых сбои могут быть изящно обработаны.

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

33 голосов
/ 13 сентября 2009

Программная транзакционная память (STM) в сочетании с энергонезависимой ОЗУ, вероятно, удовлетворит пересмотренный вопрос ОП.

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

Основная идея проста: все операции чтения и записи в блоке «транзакции» записываются (как-то!); если какие-либо два потока конфликтуют с этими наборами (конфликты чтения-записи или записи-записи) в конце любой из их транзакций, один выбирается в качестве победителя и продолжается, а другой вынужден откатывать свое состояние до начала транзакции и повторно выполнить.

Если кто-то настаивал на том, что все вычисления были транзакциями, а состояние в начале (/ конце) каждой транзакции сохранялось в энергонезависимой памяти (NVRAM), сбой питания можно рассматривать как сбой транзакции, приводящий к «откату» , Вычисления будут осуществляться только из транзакционных состояний надежным способом. NVRAM в наши дни может быть реализован с флэш-памятью или с резервной батареей. Может потребоваться МНОГО NVRAM, так как программы имеют много состояний (см. Статью о миникомпьютере в конце). В качестве альтернативы зафиксированные изменения состояния могут быть записаны в файлы журнала, которые были записаны на диск; это стандартный метод, используемый большинством баз данных и надежными файловыми системами.

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

Люди обычно не проектировали языки для STM; для исследовательских целей, они в основном улучшена Java с помощью STM (см. статью «Сообщения ACM в июне этого года»). Я слышал, у MS есть экспериментальная версия C #. У Intel есть экспериментальная версия для C и C ++. Страница Википедии имеет длинный список. И функциональное программирование, ребята как обычно утверждают, что свойство свободных от побочных эффектов функциональных программ делает STM относительно тривиальным для реализации на функциональных языках.

Если я правильно помню, еще в 70-х годах была значительная ранняя работа в распределенных операционных системах, в которых процессы (код + состояние) могли проходить тривиально от машины к машине. Я полагаю, что несколько таких систем явно допускали сбой узла и могли перезапустить процесс в отказавшем узле из состояния сохранения в другом узле. Ранняя ключевая работа была на Распределенная вычислительная система Дэйва Фарбера. Поскольку разработка языков в 70-х годах была популярной, я помню, что у DCS был собственный язык программирования, но я не помню названия. Если DCS не разрешил сбой узла и перезапустил его, я вполне уверен, что последующие действия в исследовательских системах сделали.

РЕДАКТИРОВАТЬ: система 1996 года, которая, на первый взгляд, обладает желаемыми свойствами, задокументировано здесь . Его концепция атомарных транзакций соответствует идеям STM. (Идет доказать, что под солнцем не так много нового).

Примечание: еще в 70-х годах Core Memory все еще была королем. Ядро, будучи магнитным, было энергонезависимым при сбоях питания, и многие мини-компьютеры (и я уверен, что мэйнфреймы) имели прерывания при сбое питания, которые уведомляли программное обеспечение за несколько миллисекунд до потери питания. Используя это, можно легко сохранить состояние регистра машины и полностью отключить его. Когда питание будет восстановлено, управление вернется к точке восстановления состояния, и программное обеспечение сможет продолжить работу. Таким образом, многие программы могут выдерживать мигания и надежно перезагружаться. Я лично построил систему с разделением времени на миникомпьютере Data General Nova; на самом деле вы можете запустить 16 телетайпов, получить мощный удар, вернуться и перезапустить все телетайпы, как будто ничего не произошло. Переход от какофонии к тишине и обратно был ошеломляющим, я знаю, мне приходилось повторять это много раз, чтобы отладить код управления сбоем питания, и он, конечно, сделал отличную демонстрацию (дергайте, гробовая тишина, вставляйте обратно .. .). Название языка, который сделал это, было, конечно, Assembler: -}

13 голосов
/ 13 сентября 2009

Я сомневаюсь, что описываемые вами языковые возможности возможны.

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

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

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

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

13 голосов
/ 10 сентября 2009

Из того, что я знаю¹, Ada часто используется в критических (отказоустойчивых) системах безопасности.

Ада изначально была нацелена на встроенные системы и системы реального времени.

Примечательные особенности Ada включают в себя: строгая типизация, механизмы модульности (пакеты), проверка во время выполнения, параллельная обработка (задачи), исключение обработка и дженерики. Ада 95 добавлена поддержка объектно-ориентированного программирование, в том числе динамическое отправка.

Ада поддерживает проверки во время выполнения в порядке защитить от доступа к нераспределенная память, переполнение буфера ошибки, отдельные ошибки, массив ошибки доступа и другие обнаружимые ошибок. Эти проверки могут быть отключены в интерес эффективности времени выполнения, но часто могут быть скомпилированы эффективно. Это также включает средства, чтобы помочь проверка программы.

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

Программирование в N-версии также может дать вам полезную справочную информацию.

¹ Это в основном один знакомый, который пишет встроенное программное обеспечение, критическое для безопасности

11 голосов
/ 19 сентября 2009

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

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

И есть проблема создания Ортогональной Устойчивости на основном языке. Были попытки сделать OP в Java, в том числе те, которые были сделаны людьми, связанными с Sun (проект Pjama), но в данный момент ничего активного нет. Подходы JDO / Hibernate более популярны в наши дни.


Я должен отметить, что ортогональное постоянство не является в значительной степени устойчивым к бедствиям. Например, он не может иметь дело с:

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

Для тех, я не верю, что есть общие решения, которые были бы практичны.

10 голосов
/ 14 сентября 2009

Нет , язык для защиты от стихийных бедствий не существует.

Edit:

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

Бедствие с точки зрения ИТ может возникнуть в столь многих формах, что ни один процесс не может решить все эти разные проблемы. Идея о том, что вы можете разработать язык для решения всех проблем, с которыми что-то может пойти не так, просто неверна. Из-за абстрагирования от аппаратного обеспечения многие проблемы даже не имеют большого смысла решать с помощью языка программирования; все же они все еще «бедствия».

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

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

10 голосов
/ 10 сентября 2009

Большинство таких усилий, называемых « отказоустойчивость », касаются аппаратного обеспечения, а не программного обеспечения.

Экстремальным примером этого является Tandem , чьи «безостановочные» машины имеют полное резервирование.

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

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

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

4 голосов
/ 15 сентября 2009

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

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

Теперь представьте систему, построенную из двух таких дискретных систем - для наглядности, одна из них является сервером базы данных, а другая - сервером приложений для веб-сайта онлайн-банкинга.

Если одна делает паузу, что делает другая? Как он справляется с внезапной недоступностью своего коллеги?

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

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

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

Таким образом, кажется, что защита от стихийных бедствий лучше в текущей форме - бесперебойные источники питания, готовые к работе серверы горячего резервного копирования, несколько сетевых маршрутов между хостами и т. Д. И тогда нам остается только надеяться, что наше программное обеспечение содержит бесплатно!

3 голосов
/ 15 сентября 2009

Точный ответ:

Ada и SPARK были разработаны для максимальной отказоустойчивости и перемещения всех возможных ошибок во время компиляции, а не во время выполнения. Ада была разработана Министерством обороны США для военных и авиационных систем, работающих на встроенных устройствах, таких как самолеты. Искра является его потомком. В ранней американской космической программе использовался другой язык, HAL / S, предназначенный для обработки сбоев аппаратного обеспечения и повреждения памяти из-за космических лучей.


Практический ответ:

Я никогда не встречал никого, кто мог бы закодировать Ада / Спарк. Для большинства пользователей лучшим ответом являются варианты SQL на СУБД с автоматическим переключением при сбое и кластеризацией серверов. Проверка целостности гарантирует безопасность. Нечто подобное T-SQL или PL / SQL обладает полной транзакционной безопасностью, является полным по Тьюрингу и довольно терпимым к проблемам.


Причина, по которой нет лучшего ответа:

По соображениям производительности вы не можете обеспечить долговечность при каждой работе программы. Если вы это сделаете, обработка замедлится до скорости вашего самого быстрого безвредного хранилища. В лучшем случае ваша производительность упадет в тысячу или миллион раз, из-за того, что НИЧЕГО медленнее, чем кэши ЦП или ОЗУ.

Это было бы эквивалентно переходу с процессора Core 2 Duo на древний процессор 8086 - самое большее, вы могли бы выполнять пару сотен операций в секунду. За исключением того, что это будет даже МЕДЛЕННО.

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

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

3 голосов
/ 18 сентября 2009

Этот вопрос заставил меня опубликовать этот текст

(цитата из HGTTG ​​от Дугласа Адамса:)


Кликни, гул.

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

На борту корабля все было так, как было на протяжении тысячелетий, глубоко темным и безмолвным.

Кликни, гул.

По крайней мере, почти все.

Кликни, кликни, гул.

Нажмите, гудите, нажмите, гудите, нажмите, гудите.

Нажмите, нажмите, нажмите, нажмите, нажмите, нажмите, гул.

Хм.

Программа контроля низкого уровня разбудила программу контроля более высокого уровня глубоко в полусонном кибер-мозге корабля и сообщила ему, что всякий раз, когда она щелкает, все, что она получает, это гул.

Программа контроля более высокого уровня спросила его, что она должна была получить, а программа контроля низкого уровня сказала, что она не может точно вспомнить, но подумала, что это скорее отдаленный удовлетворенный вздох, не так ли? ? Он не знал, что это был за гул. Нажми, гуди, щелкни, гуди. Это было все, что он получал.

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

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

Не удалось найти справочную таблицу.

Одд.

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

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

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

Это сделало всю проблему очень простой для решения. Замените центральный модуль миссии. Был еще один, резервная копия, точная копия оригинала. Его пришлось заменить физически, потому что по соображениям безопасности не было никакой связи между оригиналом и его резервной копией. Когда центральный модуль миссии будет заменен, он сам сможет контролировать реконструкцию остальной системы в каждой детали, и все будет хорошо.

Роботам было приказано доставить резервный центральный модуль миссии из защищенной сильной комнаты, где они его охраняли, в логическую камеру корабля для установки.

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

Это дало первый главный ключ к пониманию того, что было неправильно.

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

Первое, что нужно сделать, это попытаться закрыть дыру. Это оказалось невозможным, потому что судовые датчики не могли видеть, что там была дыра, и наблюдатели, которые должны были сказать, что датчики не работали должным образом, не работали должным образом, и продолжали говорить, что датчики были в порядке. Корабль мог вывести существование дыры только из того факта, что роботы явно выпали из него, забрав свой запасной мозг, который позволил бы ему увидеть дыру вместе с ними.

Корабль попытался разумно подумать об этом, потерпел неудачу и затем на некоторое время полностью отключился. Конечно, он не понимал, что он исчез, потому что он отключился. Было просто удивительно видеть, как звезды прыгают. После того, как в третий раз прыгнули звезды, корабль наконец понял, что он должен гаснуть, и что пришло время принять некоторые серьезные решения.

Это расслаблено.

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

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

"Твой !!!!! !!!!! !!!!! годовой миссией является !!!!! !!!!! !!!!! !!!!!, !!!!! !!!!! !!!!! !!!!!, земля !!!!! !!!!! !!!!! безопасное расстояние !!!!! !!!!! ..... ..... ..... ...., земля ..... ..... ..... контролировать его. !!!!! !!!!! !!!!! .. "

Все остальное было полным мусором.

Прежде чем окончательно отключиться, корабль должен будет передать эти инструкции, какими они были, своим более примитивным вспомогательным системам.

Он также должен оживить весь свой экипаж.

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

Незадолго до того, как он отключился в последний раз, корабль понял, что его двигатели тоже начинают выходить из строя.

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

...