"-А что было бы если бы костюм не выдержал выстрел из пистолета?
+О, это была бы большая потеря… Для фирмы-производителя. Мы перестали бы пользоваться её услугами"
В том то и задача — пораньше найти незакрытую дыру, пока этого не сделал вирус\хакер\пьяный админ\слепая случайность. Это будет прекрасно, если обезьяна найдет такую дыру. В том и задача.
Тут меня все немного не так поняли видимо…
Вот внизу habrahabr.ru/blogs/sysadm/111473/#comment_3557454 уважаемый Sap_ru правильно высказал мою мысль!
Позволю себе процитировать:
«Однажды она убьёт процесс, а следом произойдёт настоящий сбой. И вот тогда они проклянут день, когда эта макака родилась на свет. Нельзя такие вещи делать в боевой системе.» Вот я именно об этом и говорил!
Понятно, что это хорошо, когда эта ваша обезъянка найдёт дыру, которая не приведёт к печальным последствиям, и вы её пофиксите, и будет профит.
Но если действия обезъянки случайно совпадут с другими какими-то событиями — и в результате мы получим даун системы или какого-то сервиса — вот тогда будет печаль. Вы как-бы провоцируете сбой такими действиями.
Я считаю, что такие жёсткие тестирования должны проводиться на стенде, но никак не на продакшене.
Сорри если кого обидел.
Ну убивает то она не прям рандомный процесс.
А тот, который с той или иной вероятностью «надо было бы убить». К примеру который стал кушать больше памяти чем стандартно какое-то более продолжительное время чем обычно, но другой процесс, который должен быть увеличиться вместе с ним остался неизменным.
Откуда информация? В оригинальной статье (http://techblog.netflix.com/2010/12/5-lessons-weve-learned-using-aws.html) ничего не нашел.
Да и смысла в этом нет — проблемные процессы надо не убивать, а наблюдать (а потом уже убивать :) ). А тут именно рандомное убийство чего угодно с целью убедиться, что оно переподнимется само/другая нода подхватит функции убитой.
каэш… когда в simsity всё было слишком благополучно, можно было вручную подсунуть годзиллу или уронить пепелац на город. или одновременно. тоже открывало глаза на более рациональное расположение экстренных служб.
Предлагаю послать в Кремль годзиллу или смерч! :) Может получиться построить там потом хорошую клинику, детские сады, пожарную часть и на парковки останется место!
Насколько мне известно в #yandex периодически отключают целые дата центры для тестов аварийных ситуаций. Однозначно правильный подход для больших и важных сервисов!
Можно сделать офлайновый вариант, раз в месяц злая обезьяна с бейсбольной битой ломает ногу дизайнеру, программисту или менеджеру и сразу видно кто в конторе не имеет «избыточное дублирование».
Напомнило злобную обезьянку в шкафу в комнате Криса из Гриффинов. :)
Правильный подход, по-настоящему подготовиться к нештатной ситуации можно только побывав в ней.
Обезьянка — не самая большая беда. Если хорошо подойти к проектированию системы, то 90% всех глобальных фейлов повиснет именно на действиях сисадминов. А вырубать рандомные ноды… думаю, есть куда более цивилизованные способы проверки работы кластера.
Суть как раз в том, чтобы проверить «нецивилизованные» способы. На практике реальный отказ редко когда происходит «вовремя» и «соблюдая все правила вежливости».
Нормальная практика. Я тоже такое делал однажды, когда лень было профайлить кто мои процессы вешает или память подъедает. Потом проблемы с кодом исправил и теперь аптайм процессов вновь исчисляется месяцами.
Ну, в концепции осознанной необходимости периодически производить тестирование и моделирование аварийных ситуаций на инфраструктуре (одновременно с тестированием/тренингом персонала) особо ничего нового нет. Но метод выбран интересный, это да…
мартышка и очки :)
идея конечно интересная, но это не ученая обезьянка — это робот :) обезьянка может такого натворить… ух… на такую идею еще должен быть и бюджет хороший… вдруг обезьянка станет более злее (ошибка программиста)…
Отстреливал автоматом отъевшиеся рабочие процессы у апача, ибо неконтролируемые утечки памяти и расход CPU в PHP4 случались. Про ulimit знаю, но были побочные эффекты.
Насчет минусов такого террора я в курсе, но появилось больше свободного времени и меньше замечаний — а, всяко, это плюс.
Угу, в винмобайле так звонилка каждые полчаса отстреливалась. Ребята напоролись, когда свою сделали, и заметили, что дефолтная постоянно запускается через равные промежутки времени.
у нас этим занимаются индусы, вот только не «специально», а потому что идиоты — то сервак перезапустят случайно, то накатят патчи и опять таки перезапустят сервак, предупредив за 10 минут.
мне как то надоело просыпаться по ночам — переписали систему так, что любой блейд можно хоть в окно выбросить — система будет стабильна. так что да, такой подход гениален.
Практически любое «свежее» решение бесспорно хорошо хотя бы потому, что оно практически обязательно влечет за собой массу уникального материала для анализа. Такого, который никогда не появится, происходи всё по заранее заготовленным схемам.
Почему слово «свежее» в кавычках? Да потому, что это, собственно, принцип «случайного тестирования». Правда в несколько прикольной форме :)
Со второй стороны — а как теперь они будут обнаруживать проблемы, которые случаются после долгого времени работы (по аналогии с memleaks — вроде все идеально работает, но через месяц аптайма — проблема).
А снова с первой — а кого волнуют такие проблемы, если инстанс в принципе долго не живет? Обезьянка просто изменила требования к системе, сделав упор на «рестартуемости», и убрав требования о длительной беспроблемной работе каждого инстанса.
Однажды она убьёт процесс, а следом произойдёт настоящий сбой. И вот тогда они проклянут день, когда эта макака родилась на свет. Нельзя такие вещи делать в боевой системе.
Тем, что макака убивает ОДИН процесс, и скорее всего не любой. А тут макака прибьёт какой-нибудь процесс, отвечающий за резервное копирование (например, поддерживающий зеркало, какой-нибудь базы), а следом случится аппаратный сбой и база поляжет и потеряются данные транзакции на сто-пицот тыщ. Система, как бы обычно проектируется на одиночный отказ. И проверяют они его своех обезъяной на одиночный отказ. А как оно себя поведёт при двойном отказе они не знают и не проверяли.
«скорее всего», «какой-нибудь», «обычно»… пока одни догадки :)
Откуда вы знаете, что они не знают и не проверяли двойной отказ? Тройной? Мне кажется, что эту обезьянку не дураки писали
> Система, как бы обычно проектируется на одиночный отказ
Это вы их обычно проектируете на одиночный отказ? Я сталкивался с несколько другими вариациями
Злая обезьянка повышает аптайм