Чи повинні ми розробляти програми, щоб випадковим чином себе вбити? [зачинено]

Якщо коротко, ми повинні проектувати смерть у наші програми, процеси та нитки на низькому рівні, для блага загальної системи?

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

Макро-приклад цієї концепції - Хаоська мавпа Netflix , яка випадковим чином припиняє випадки AWS у деяких сценаріях. Вони стверджують, що це допомогло їм розкрити проблеми та побудувати більш зайві системи.

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

Чи має це поняття вже назву? Це вже використовується в галузі?

EDIT

На основі коментарів та відповідей, я боюся, що я не зрозумів у своєму питанні. Для наочності:

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

Для пояснення я хотів би провести аналогію з багатоклітинними організмами.

У природі організми складаються з багатьох клітин. Клітини розщеплюються, щоб створити надмірність, і вони зрештою гинуть. Але для функціонування організму завжди повинно бути достатньо клітин правильного виду. Ця надмірна система також полегшує оздоровлення при травмах. Клітини гинуть, так живе організм.

Включення випадкової смерті в програму змусить більшу систему приймати стратегії надмірності, щоб залишатися життєздатними. Чи допомогли б ці самі стратегії залишатися стабільними в умовах інших видів непередбачуваних збоїв?

І якщо хтось спробував це, як це називається? Я хотів би прочитати більше про це, якщо він уже існує.

Немає.

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

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

З Вікіпедії:

Техніка впорскування несправностей сягає 1970-х років, коли її вперше застосовували для індукції несправностей на апаратному рівні. Цей тип впорскування несправностей називається апаратним введенням несправностей (HWIFI) та намагається імітувати апаратні збої в системі. Перші експерименти з введення технічної несправності в апараті включали не що інше, як укорочення з'єднань на платах та спостереження за впливом на систему (усунення несправностей). Він використовувався в першу чергу як перевірка надійності апаратної системи. Пізніше було розроблено спеціалізоване обладнання для розширення цієї методики, наприклад пристрої для бомбардування конкретних ділянок плати сильним випромінюванням. Незабаром було встановлено, що несправності можуть бути викликані програмними методами і що аспекти цієї методики можуть бути корисними для оцінки програмних систем.

Так. Ні, можливо.

Періодичне припинення - меч з двома кінцями. Ви збираєтесь вдаритись одним або іншим краєм, і яке менше на два зло залежить від вашої ситуації.

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

Інший край - це також надійність: якщо ви не дозволяєте програмі довго працювати, ви ніколи не знайдете помилок, які виявляться з часом. Коли ви нарешті натрапите на одну з цих помилок, набагато більше шансів змусити програму повернути неправильну відповідь або взагалі не повернути її. Гірше, якщо ви запускаєте багато ниток однієї роботи, помилка, спричинена часом або рахунком, може вплинути на дуже велику кількість завдань одночасно і спричинити за собою поїздку в офіс за 3 години ранку.

У налаштуваннях, де ви запускаєте багато одних і тих же потоків (наприклад, на веб-сервері), практичним рішенням є застосування змішаного підходу, що призводить до прийнятного рівня відмов. Якщо ви запускаєте 100 ниток, співвідношення коротко до довгого 99: 1 означає, що лише один буде виявляти довгострокові помилки, а інші продовжують робити все, що вони роблять, не виходячи з ладу. На противагу цьому, якщо ви працюєте на 100% завдовжки, де ви маєте набагато більший ризик того, що всі потоки вийдуть з ладу одночасно.

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

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

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

Ви справді маєте на увазі випадкові? Наявність у вашому програмному забезпеченні випадкового вбивства себе здається жахливою ідеєю. Якому моменту це послужило б?

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

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

Я не працював у цьому районі деякий час, тому не знаю, чи все ще так.

Я бачу проблему в тому, що якщо така програма вмирає, ми просто скажемо «О, це просто чергове випадкове припинення - нічого страшного». Але що робити, якщо є реальна проблема, яка потребує виправлення? Це буде проігноровано.

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

Я не бачу нічого поганого в випадковому знищенні процесів у тестовому середовищі під час тестування надлишкової системи (це має відбуватися більше, ніж це є), але не у виробничому середовищі. Чи витягуватимемо пару жорстких дисків із системи живого виробництва кожні кілька днів, або деактивуємо один із комп'ютерів на літаку, оскільки він летить повним пасажирами? У сценарії тестування - добре. За сценарієм живого виробництва - я б краще цього не зробив.

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

У роботі з мережами необхідно моделювати ненадійну мережу заради перевірки виконання протоколу. Це не вбудовується в протокол; його можна моделювати на рівні драйверів пристрою або з деяким зовнішнім обладнанням.

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

Якщо це призначено для виробництва, я не можу повірити, що це серйозно!

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

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

Можливо, ви зможете уникнути положень ліцензійної угоди, які відмовляються від цивільної відповідальності від будь-яких збитків, що виникають внаслідок експлуатації програмного забезпечення, але якщо ці збитки є конструктивними, ви не зможете відмовитися від кримінальної відповідальності.

Навіть не думайте про такі трюки: змушуйте його працювати максимально надійно, і вкладайте підроблені сценарії відмов лише в спеціальні збірки або конфігурації.

Можливо, ви хочете шукати " проактивне відновлення " та " омолодження " в контексті розподілених систем, що мають відмову від неполадок, щоб боротися з довільними помилками (тобто не тільки збоями, але зіпсованими даними та потенційно шкідливою поведінкою). Було проведено багато досліджень щодо того, як часто і в яких умовах слід перезапустити процес (в абстрактному розумінні насправді це може бути ВМ або хост). Інтуїтивно ви можете зрозуміти переваги підходу як перевагу мати справу з мертвим процесом, ніж із процесом зрадника ...

Це насправді не відрізняється від тестування. Якщо ви розробляєте завжди доступне рішення для відмови (наприклад, Netflix), то так - вам слід перевірити його. Я не знаю, що випадкові виходи, посипані по всій базі коду, є відповідним способом перевірити це. Якщо ви дійсно не маєте наміру перевірити, чи ваш дизайн стійкий до того, щоб стріляти в ногу, здається, що це доцільніше перевірити його, маніпулюючи оточенням навколо коду та перевіряючи, чи він веде себе належним чином.

Якщо ви не проектуєте надлишкові системи, то ні - вам не слід додавати цю функцію, оскільки ви додали кілька випадкових виходів. Вам слід просто видалити випадкові виходи, і тоді у вас не виникне такої проблеми. Навколишнє середовище на вас все ще може вийти з ладу, і тоді ви будете або замітати його як непідтримуваний / не виправить, або загартуєте ваш код проти цієї помилки та додасте тест на нього. Зробити це досить часто, і ви зрозумієте , що ви на самому справі є проектуванням надлишкової системи - див сценарію # 1.

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

Єдине цікаве в прикладі Netflix - це те, що вони проводять ці тести у виробництві. Це має певний сенс - деякі помилки насправді виробляють лише речі, які дуже важко або неможливо імітувати в ізольованому середовищі. Я підозрюю, що Netflix довгий час проводив у тестових умовах, перш ніж їм було достатньо комфортно, щоб це зробити у виробництві. І насправді все, що вони роблять, - це намагання статися до збоїв у робочий час, що має певний сенс для їхнього ринку, але не для багатьох інших.

Термін, який ви шукаєте, нещодавно придумав Нассім Ніколас Талеб: Антигрибкість. Його книга « Антифрагіл» , безумовно, рекомендується. Він ледь не згадує про ІТ, але невимовлені, очевидні паралелі найбільше надихають. Його ідея - розширити масштаб крихкої <-> міцної до крихкої <-> міцної <-> антифрагільної. Неміцний розрив з випадковими подіями, надійне управління з випадковими подіями та антикрихкий виграш із випадковими подіями.

Це залежить. Я помітив, що програмісти, як правило, надмірно узагальнюють методи, що застосовуються до їх конкретного домену, ігноруючи всі інші. Наприклад, вивільнення програми за рахунок виправлення всіх помилок може бути хорошим ... якщо ви не запрограмували контролер літака, ядерний реактор тощо. "Не оптимізуйте - вартість програміста більша, ніж вартість запущеної програми" не потрібно. діє для 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 = вірно )

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

Ми вже працюємо над ненадійними шарами (апаратне забезпечення, мережа), тому я ніколи не напишу жодного коду, який випадково вбиває його нитки або процеси навмисно. Випадкове вбивство - це також погана ідея з економічної точки зору - ніхто не використовував би мій API, якби вони подумали, що я запрограмував його на випадковий збій. Нарешті, якби я споживав API чи використовував систему із випадковими руйнуючими нитками, мені доведеться витратити багато грошей, щоб створити достатньо надійний механізм моніторингу для нього, щоб я міг спокійно спати вночі.

Натомість Якби я розробляв систему чи API, я писав би сценарії або використовував джгут, який би робив це суто для того, щоб перевірити стійкість системи. І я б зробив такий тестовий запуск на всіх складах, щоб виявити погані складання. Однак, хоча це буде необхідним тестом, воно ніколи не може бути "достатнім" тестом.

Існує література, пов’язана з цією ідеєю, її називають програмним забезпеченням, призначеним лише для краху (також відновлення орієнтованих обчислень), і ви можете почати з цього паперу Usenix від Candea & Fox з 2003 року. Замість випадкових вбивств автор вважає, що ви можете підвищити надійність системи лише коли-небудь зупиняючи ваші програми, вбиваючи їх, тому маючи єдиний перемикач вбивства як кнопку вимкнення та єдиний добре здійснений пусковий шлях до відновлення.

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

Справді випадковим чином немає. Але, мабуть, є хорошою ідеєю, щоб довгі запущені процеси / потоки виходили / перезапускалися через заданий інтервал, або після того, як вони були бездіяльні протягом заданої тривалості (але залежно від певних критеріїв), або після виконання певного завдання. Тривалі процеси нарощування стану, що неминуче включають несвіжі речі, імовірно, можуть зависати в пам'яті, запобігаючи звільненню місця обміну, що все очищається (або повинно бути очищено), коли вони виходять, покращуючи загальну стабільність системи.

Це залежить від типу програми, яку ви розробляєте.

Випадкові збої - прекрасний спосіб перевірити та покращити надійність розподілених (мережевих) систем.

У прикладі Netflix, коли ваша програма залежить від віддалених служб, які можуть вийти з ладу з різних причин, які не знаходяться під вашим контролем (жорсткий диск виходить з ладу, втрата електроенергії, метеор впадає в центр обробки даних тощо). Однак ваш сервіс все ще повинен якось продовжувати працювати.

Як ти це робиш? Додавання надмірності та масштабування є загальним рішенням.

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

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

Ось додатковий коментар до концепції Chape Monkeys http://www.codinghorror.com/blog/2011/04/working-with-the-chaos-monkey.html

Цілком можливо, що випадковий відбиток бітів відбувається через космічне випромінювання . Цю проблему було визнано, і були розроблені різні методи , щоб не допустити перегортання бітів.

Однак це неможливо виправити на 100%, і пошкодження пам’яті все ще може спричинити проблеми, і ці проблеми все ще трапляються ( з дуже низькою ймовірністю ).

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

Якщо вам потрібно розробити звичайну програму для настільних ПК, тоді вам слід розглядати випадкові збої як помилки у вашому коді.

Це не здається, що дурна ідея.

ОС Android випадковим чином постійно вбиває та перезавантажує користувацькі програми / послуги. З мого досвіду, це, безумовно, допомогло мені глибше задуматися про умови помилок, а також створити більш надійні архітектури.