Должны ли мы разрабатывать программы, чтобы случайно убить себя? [закрыто]

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

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

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

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

У этой концепции уже есть имя? Это уже используется в промышленности?

РЕДАКТИРОВАТЬ

На основании комментариев и ответов, я боюсь, что я не был ясен в моем вопросе. Для ясности:

• да, я имею в виду случайно,
• да, я имею в виду в производстве, и
• нет, не только для тестирования.

Чтобы объяснить, я хотел бы провести аналогию с многоклеточными организмами.

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

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

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

Нет.

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

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

Из Википедии:

Техника введения неисправностей восходит к 1970-м годам, когда она впервые использовалась для выявления неисправностей на аппаратном уровне. Этот тип внедрения ошибок называется аппаратным внедрением ошибок (HWIFI) и пытается имитировать аппаратные сбои в системе. Первые эксперименты по внедрению аппаратных неисправностей включали не что иное, как замыкание соединений на платах и ​​наблюдение за воздействием на систему (устранение неисправностей). Он использовался в первую очередь для проверки надежности аппаратной системы. Позже было разработано специальное оборудование для расширения этой техники, например устройства для бомбардировки определенных областей печатной платы сильным излучением. Вскоре было обнаружено, что неисправности могут быть вызваны программными методами и что аспекты этой техники могут быть полезны для оценки программных систем.

Да. Может быть

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

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

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

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

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

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

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

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

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

Я считаю, что еще в конце 90-х веб-сервер Apache использовал что-то подобное. У них был пул рабочих процессов (не потоков), и каждый рабочий процесс был бы уничтожен после фиксированного срока службы. Это предохраняло сервер от монополизации рабочими процессами, которые застряли в каком-то патологическом состоянии.

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

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

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

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

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

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

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

Если это предназначено для производства, я не могу поверить, что это серьезно!

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

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

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

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

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

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

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

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

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

Термин, который вы ищете, был недавно введен Nassim Nicholas Taleb: Antifragility. Его книга Antifragile определенно рекомендуется. Это едва упоминает ИТ, но невысказанные, очевидные параллели являются наиболее вдохновляющими. Его идея состоит в том, чтобы расширить масштаб хрупкого <-> робастного до хрупкого <-> робастного <-> антихрупкого. Хрупкие разрывы со случайными событиями, надежное управление случайными событиями и антихрупкое усиление со случайными событиями.

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

Обычно процедуры обработки ошибок являются худшей проверенной частью кода - хотя это кажется простым, трудно симулировать, что недостаточно памяти или отсутствует какой-то важный файл. По этой причине я читаю тексты, предлагающие ядру Unix случайно выполнять некоторые системные вызовы. Однако это усложнит написание простых программ (если мне понадобится подключить 3 библиотеки C ++ для запуска программы на 2 файлах, если я не хочу беспокоиться об обработке ошибок). Даже с исключениями, GC вам нужно убедиться, что вы оставили непротиворечивое состояние (представьте исключение в середине добавления узла в связанный список).

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

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

Сервер IIS имеет настраиваемую функцию, которая автоматически перезапускает рабочие процессы либо после того, как они использовали определенный объем памяти, либо после обслуживания определенного количества запросов, либо после того, как они были активны в течение указанного промежутка времени. ( http://msdn.microsoft.com/en-us/library/ms525803(v=vs.90).aspx ) и ( http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/ 1652e79e-21f9-4e89-bc4b-c13f894a0cfe.mspx? Mfr = true )

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

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

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

Существует литература, относящаяся к этой идее, она называется Crash-Only software (также Recovery Oriented Computing), и вы можете начать с этой статьи с использованием Canna & Fox 2003 года. Вместо случайных убийств, автор утверждает, что вы можете повысить надежность системы только когда-либо останавливая свои программы, убивая их, вы получаете один переключатель уничтожения в качестве кнопки выключения и один хорошо проработанный путь запуска для восстановления.

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

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

Это зависит от типа приложения, которое вы разрабатываете.

Случайные сбои - отличный способ проверить и улучшить надежность распределенных (сетевых) систем.

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

Как ты это делаешь? Добавление избыточности и масштабирования является распространенным решением.

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

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

Вот некоторые дополнительные комментарии к концепции Chaos Monkeys http://www.codinghorror.com/blog/2011/04/working-with-the-chaos-monkey.html

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

Тем не менее, это невозможно исправить на 100%, и повреждение памяти все еще может вызвать проблемы, и эти проблемы все еще происходят ( с очень низкой вероятностью ).

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

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

Это не кажется нелепой идеей.

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