Comments 78
Главное в production не забыть выключить.
главное чтобы недовольные клиенты потом никого не поубивали, если все упадет ))
А что происходит, когда «злая обезьянка» таки находит незакрытую дыру? Ведь это может привести к печальным последствиям…
"-А что было бы если бы костюм не выдержал выстрел из пистолета?
+О, это была бы большая потеря… Для фирмы-производителя. Мы перестали бы пользоваться её услугами"
В том то и задача — пораньше найти незакрытую дыру, пока этого не сделал вирус\хакер\пьяный админ\слепая случайность. Это будет прекрасно, если обезьяна найдет такую дыру. В том и задача.
+О, это была бы большая потеря… Для фирмы-производителя. Мы перестали бы пользоваться её услугами"
В том то и задача — пораньше найти незакрытую дыру, пока этого не сделал вирус\хакер\пьяный админ\слепая случайность. Это будет прекрасно, если обезьяна найдет такую дыру. В том и задача.
Тут меня все немного не так поняли видимо…
Вот внизу habrahabr.ru/blogs/sysadm/111473/#comment_3557454 уважаемый Sap_ru правильно высказал мою мысль!
Позволю себе процитировать:
«Однажды она убьёт процесс, а следом произойдёт настоящий сбой. И вот тогда они проклянут день, когда эта макака родилась на свет. Нельзя такие вещи делать в боевой системе.» Вот я именно об этом и говорил!
Понятно, что это хорошо, когда эта ваша обезъянка найдёт дыру, которая не приведёт к печальным последствиям, и вы её пофиксите, и будет профит.
Но если действия обезъянки случайно совпадут с другими какими-то событиями — и в результате мы получим даун системы или какого-то сервиса — вот тогда будет печаль. Вы как-бы провоцируете сбой такими действиями.
Я считаю, что такие жёсткие тестирования должны проводиться на стенде, но никак не на продакшене.
Сорри если кого обидел.
Вот внизу habrahabr.ru/blogs/sysadm/111473/#comment_3557454 уважаемый Sap_ru правильно высказал мою мысль!
Позволю себе процитировать:
«Однажды она убьёт процесс, а следом произойдёт настоящий сбой. И вот тогда они проклянут день, когда эта макака родилась на свет. Нельзя такие вещи делать в боевой системе.» Вот я именно об этом и говорил!
Понятно, что это хорошо, когда эта ваша обезъянка найдёт дыру, которая не приведёт к печальным последствиям, и вы её пофиксите, и будет профит.
Но если действия обезъянки случайно совпадут с другими какими-то событиями — и в результате мы получим даун системы или какого-то сервиса — вот тогда будет печаль. Вы как-бы провоцируете сбой такими действиями.
Я считаю, что такие жёсткие тестирования должны проводиться на стенде, но никак не на продакшене.
Сорри если кого обидел.
Ну, по меньшей мере, эту штуку всегда можно выключить и есть надежда, что что-то заработает стабильнее. :)
Ну убивает то она не прям рандомный процесс.
А тот, который с той или иной вероятностью «надо было бы убить». К примеру который стал кушать больше памяти чем стандартно какое-то более продолжительное время чем обычно, но другой процесс, который должен быть увеличиться вместе с ним остался неизменным.
А тот, который с той или иной вероятностью «надо было бы убить». К примеру который стал кушать больше памяти чем стандартно какое-то более продолжительное время чем обычно, но другой процесс, который должен быть увеличиться вместе с ним остался неизменным.
Откуда информация? В оригинальной статье (http://techblog.netflix.com/2010/12/5-lessons-weve-learned-using-aws.html) ничего не нашел.
Да и смысла в этом нет — проблемные процессы надо не убивать, а наблюдать (а потом уже убивать :) ). А тут именно рандомное убийство чего угодно с целью убедиться, что оно переподнимется само/другая нода подхватит функции убитой.
Да и смысла в этом нет — проблемные процессы надо не убивать, а наблюдать (а потом уже убивать :) ). А тут именно рандомное убийство чего угодно с целью убедиться, что оно переподнимется само/другая нода подхватит функции убитой.
Гениально! Надо взять на заметку.
каэш… когда в simsity всё было слишком благополучно, можно было вручную подсунуть годзиллу или уронить пепелац на город. или одновременно. тоже открывало глаза на более рациональное расположение экстренных служб.
Действительно гениально.
Обезьянка мне напомнила Дарт Вейдера. Теперь и Дарт Вейдер у меня будет ассоциироваться с IT технологиями и повышением аптайма((
Я бы не лег оперировать сердце, если бы знал, что оборудование усовершенствовано такой обезьянкой…
Насколько мне известно в #yandex периодически отключают целые дата центры для тестов аварийных ситуаций. Однозначно правильный подход для больших и важных сервисов!
Можно сделать офлайновый вариант, раз в месяц злая обезьяна с бейсбольной битой ломает ногу дизайнеру, программисту или менеджеру и сразу видно кто в конторе не имеет «избыточное дублирование».
Напомнило злобную обезьянку в шкафу в комнате Криса из Гриффинов. :)
Правильный подход, по-настоящему подготовиться к нештатной ситуации можно только побывав в ней.
Правильный подход, по-настоящему подготовиться к нештатной ситуации можно только побывав в ней.
Я слышал такие же обезьянки работают в PayPal, только вместо инстансов AWS они случайным образом замораживают счета.
Кстати, интересно было бы ввести добрую обезьянку — которая наоборот поднимала бы наугад всякие процессы…
что будет если обезьянка убьет один и тот же критичный процесс процесс одновременно на всех нодах кластера?
Идея-то ладно. Вот с генерацией инфоповодов у них очень все хорошо. Один Netflix Prize на всю планету прогремел.
Интересно, на сколько обезьянка подвержена суициду? Хотя возможно этот процесс так же дублируется.
Проблема в том, что в редких случаях эти ошибки сложатся. Обезьянка убьет один сервер БД и накроется винт на втором.
Обезьянка — не самая большая беда. Если хорошо подойти к проектированию системы, то 90% всех глобальных фейлов повиснет именно на действиях сисадминов. А вырубать рандомные ноды… думаю, есть куда более цивилизованные способы проверки работы кластера.
Нормальная практика. Я тоже такое делал однажды, когда лень было профайлить кто мои процессы вешает или память подъедает. Потом проблемы с кодом исправил и теперь аптайм процессов вновь исчисляется месяцами.
Ну, в концепции осознанной необходимости периодически производить тестирование и моделирование аварийных ситуаций на инфраструктуре (одновременно с тестированием/тренингом персонала) особо ничего нового нет. Но метод выбран интересный, это да…
МЕГАКОСТЫЛЬ
мартышка и очки :)
идея конечно интересная, но это не ученая обезьянка — это робот :) обезьянка может такого натворить… ух… на такую идею еще должен быть и бюджет хороший… вдруг обезьянка станет более злее (ошибка программиста)…
идея конечно интересная, но это не ученая обезьянка — это робот :) обезьянка может такого натворить… ух… на такую идею еще должен быть и бюджет хороший… вдруг обезьянка станет более злее (ошибка программиста)…
Круто, «любопытная „Блондинка“ в серверной» уже и в виде приложения.
Проще было техничку в серверную пустить…
Отстреливал автоматом отъевшиеся рабочие процессы у апача, ибо неконтролируемые утечки памяти и расход CPU в PHP4 случались. Про ulimit знаю, но были побочные эффекты.
Насчет минусов такого террора я в курсе, но появилось больше свободного времени и меньше замечаний — а, всяко, это плюс.
Сейчас, пока, обхожусь.
Насчет минусов такого террора я в курсе, но появилось больше свободного времени и меньше замечаний — а, всяко, это плюс.
Сейчас, пока, обхожусь.
у нас этим занимаются индусы, вот только не «специально», а потому что идиоты — то сервак перезапустят случайно, то накатят патчи и опять таки перезапустят сервак, предупредив за 10 минут.
мне как то надоело просыпаться по ночам — переписали систему так, что любой блейд можно хоть в окно выбросить — система будет стабильна. так что да, такой подход гениален.
мне как то надоело просыпаться по ночам — переписали систему так, что любой блейд можно хоть в окно выбросить — система будет стабильна. так что да, такой подход гениален.
Практически любое «свежее» решение бесспорно хорошо хотя бы потому, что оно практически обязательно влечет за собой массу уникального материала для анализа. Такого, который никогда не появится, происходи всё по заранее заготовленным схемам.
Почему слово «свежее» в кавычках? Да потому, что это, собственно, принцип «случайного тестирования». Правда в несколько прикольной форме :)
Почему слово «свежее» в кавычках? Да потому, что это, собственно, принцип «случайного тестирования». Правда в несколько прикольной форме :)
Со второй стороны — а как теперь они будут обнаруживать проблемы, которые случаются после долгого времени работы (по аналогии с memleaks — вроде все идеально работает, но через месяц аптайма — проблема).
А снова с первой — а кого волнуют такие проблемы, если инстанс в принципе долго не живет? Обезьянка просто изменила требования к системе, сделав упор на «рестартуемости», и убрав требования о длительной беспроблемной работе каждого инстанса.
А снова с первой — а кого волнуют такие проблемы, если инстанс в принципе долго не живет? Обезьянка просто изменила требования к системе, сделав упор на «рестартуемости», и убрав требования о длительной беспроблемной работе каждого инстанса.
UFO just landed and posted this here
Плагиат! Еще на ЛОРе пару лет назад баловались аналогичной штукой — русской рулеткой для админов.
Однажды она убьёт процесс, а следом произойдёт настоящий сбой. И вот тогда они проклянут день, когда эта макака родилась на свет. Нельзя такие вещи делать в боевой системе.
А чем отличается «настоящий сбой» от действий обезьянки?
Тем, что макака убивает ОДИН процесс, и скорее всего не любой. А тут макака прибьёт какой-нибудь процесс, отвечающий за резервное копирование (например, поддерживающий зеркало, какой-нибудь базы), а следом случится аппаратный сбой и база поляжет и потеряются данные транзакции на сто-пицот тыщ. Система, как бы обычно проектируется на одиночный отказ. И проверяют они его своех обезъяной на одиночный отказ. А как оно себя поведёт при двойном отказе они не знают и не проверяли.
«скорее всего», «какой-нибудь», «обычно»… пока одни догадки :)
Откуда вы знаете, что они не знают и не проверяли двойной отказ? Тройной? Мне кажется, что эту обезьянку не дураки писали
> Система, как бы обычно проектируется на одиночный отказ
Это вы их обычно проектируете на одиночный отказ? Я сталкивался с несколько другими вариациями
Откуда вы знаете, что они не знают и не проверяли двойной отказ? Тройной? Мне кажется, что эту обезьянку не дураки писали
> Система, как бы обычно проектируется на одиночный отказ
Это вы их обычно проектируете на одиночный отказ? Я сталкивался с несколько другими вариациями
Такими «методами» можно далеко зайти. Может, иногда просто отключать внешний фаервол? Получится этакая аутсорс-Обезьянка =).
Sign up to leave a comment.
Злая обезьянка повышает аптайм