Pull to refresh

Comments 78

Главное в production не забыть выключить.
тут фишка именно что это работает постоянно и на рабочих серверах. толку в тестовом режиме?
Фишка в том, что это до поры до времени. Рано или поздно сработает принцип Мёрфи.
Фишка в том, чтобы принцип Мёрфи сработал как можно позже.
Не прокатит. Ваша фишка противоречит самой сущности данного принципа.
Наверное, что-то напомнило :)
так сказать, за живое… :)
В этом и суть, что в каждый момент времени один узел production выключен.
главное чтобы недовольные клиенты потом никого не поубивали, если все упадет ))
А что происходит, когда «злая обезьянка» таки находит незакрытую дыру? Ведь это может привести к печальным последствиям…
"-А что было бы если бы костюм не выдержал выстрел из пистолета?
+О, это была бы большая потеря… Для фирмы-производителя. Мы перестали бы пользоваться её услугами"

В том то и задача — пораньше найти незакрытую дыру, пока этого не сделал вирус\хакер\пьяный админ\слепая случайность. Это будет прекрасно, если обезьяна найдет такую дыру. В том и задача.
Тут меня все немного не так поняли видимо…
Вот внизу 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 они случайным образом замораживают счета.
Да уж, PayPal этим славится.
Кстати, интересно было бы ввести добрую обезьянку — которая наоборот поднимала бы наугад всякие процессы…
Главное при этом «rm -rf /» не научить запускать.
Ага. Рутовый шел на непривелегированном порту например
Это будет оооочень добрая обезьянка.
IRC, например, или шелл-хостинг :)
что будет если обезьянка убьет один и тот же критичный процесс процесс одновременно на всех нодах кластера?
UFO just landed and posted this here
Кластер должен будет перезапустить этот критичный процесс. Вполне, кстати, встречающаяся ситуация.
Пока она будет их убивать в AWS, успевают подняться ранее убитые.
Идея-то ладно. Вот с генерацией инфоповодов у них очень все хорошо. Один Netflix Prize на всю планету прогремел.
Интересно, на сколько обезьянка подвержена суициду? Хотя возможно этот процесс так же дублируется.
Проблема в том, что в редких случаях эти ошибки сложатся. Обезьянка убьет один сервер БД и накроется винт на втором.
Значит останутся работать ноды с 3 по 568.
Это AWS, dude!
Обезьянка — не самая большая беда. Если хорошо подойти к проектированию системы, то 90% всех глобальных фейлов повиснет именно на действиях сисадминов. А вырубать рандомные ноды… думаю, есть куда более цивилизованные способы проверки работы кластера.
Суть как раз в том, чтобы проверить «нецивилизованные» способы. На практике реальный отказ редко когда происходит «вовремя» и «соблюдая все правила вежливости».
Нормальная практика. Я тоже такое делал однажды, когда лень было профайлить кто мои процессы вешает или память подъедает. Потом проблемы с кодом исправил и теперь аптайм процессов вновь исчисляется месяцами.
Ну, в концепции осознанной необходимости периодически производить тестирование и моделирование аварийных ситуаций на инфраструктуре (одновременно с тестированием/тренингом персонала) особо ничего нового нет. Но метод выбран интересный, это да…
мартышка и очки :)
идея конечно интересная, но это не ученая обезьянка — это робот :) обезьянка может такого натворить… ух… на такую идею еще должен быть и бюджет хороший… вдруг обезьянка станет более злее (ошибка программиста)…
Круто, «любопытная „Блондинка“ в серверной» уже и в виде приложения.
Представил любопытную блондинку, крадущуюся к консоли и посылающую SIGKILL случайным процессам.
как удалить файлик с пробелом?
усе
сцука
как востановить то?
fix:
Paradise> как удалить файлик с пробелом?
Paradise> усе
Paradise> сцука
Paradise> как востановить то?
Проще было техничку в серверную пустить…
Техничка недостаточно рандомна.
Отстреливал автоматом отъевшиеся рабочие процессы у апача, ибо неконтролируемые утечки памяти и расход CPU в PHP4 случались. Про ulimit знаю, но были побочные эффекты.

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

Сейчас, пока, обхожусь.
Угу, в винмобайле так звонилка каждые полчаса отстреливалась. Ребята напоролись, когда свою сделали, и заметили, что дефолтная постоянно запускается через равные промежутки времени.
у нас этим занимаются индусы, вот только не «специально», а потому что идиоты — то сервак перезапустят случайно, то накатят патчи и опять таки перезапустят сервак, предупредив за 10 минут.
мне как то надоело просыпаться по ночам — переписали систему так, что любой блейд можно хоть в окно выбросить — система будет стабильна. так что да, такой подход гениален.
Практически любое «свежее» решение бесспорно хорошо хотя бы потому, что оно практически обязательно влечет за собой массу уникального материала для анализа. Такого, который никогда не появится, происходи всё по заранее заготовленным схемам.
Почему слово «свежее» в кавычках? Да потому, что это, собственно, принцип «случайного тестирования». Правда в несколько прикольной форме :)
Злая обезьянка Monkey эволюционировала в злую человекообразную обезьяну Ape. Следующая стадия — Homo Lamerus.
Со второй стороны — а как теперь они будут обнаруживать проблемы, которые случаются после долгого времени работы (по аналогии с memleaks — вроде все идеально работает, но через месяц аптайма — проблема).

А снова с первой — а кого волнуют такие проблемы, если инстанс в принципе долго не живет? Обезьянка просто изменила требования к системе, сделав упор на «рестартуемости», и убрав требования о длительной беспроблемной работе каждого инстанса.
UFO just landed and posted this here
А можно поподробнее про эту фичу?
Там это баг, а не фича :)
Однажды она убьёт процесс, а следом произойдёт настоящий сбой. И вот тогда они проклянут день, когда эта макака родилась на свет. Нельзя такие вещи делать в боевой системе.
А чем отличается «настоящий сбой» от действий обезьянки?
Тем, что макака убивает ОДИН процесс, и скорее всего не любой. А тут макака прибьёт какой-нибудь процесс, отвечающий за резервное копирование (например, поддерживающий зеркало, какой-нибудь базы), а следом случится аппаратный сбой и база поляжет и потеряются данные транзакции на сто-пицот тыщ. Система, как бы обычно проектируется на одиночный отказ. И проверяют они его своех обезъяной на одиночный отказ. А как оно себя поведёт при двойном отказе они не знают и не проверяли.
«скорее всего», «какой-нибудь», «обычно»… пока одни догадки :)
Откуда вы знаете, что они не знают и не проверяли двойной отказ? Тройной? Мне кажется, что эту обезьянку не дураки писали

> Система, как бы обычно проектируется на одиночный отказ

Это вы их обычно проектируете на одиночный отказ? Я сталкивался с несколько другими вариациями
Такими «методами» можно далеко зайти. Может, иногда просто отключать внешний фаервол? Получится этакая аутсорс-Обезьянка =).
Only those users with full accounts are able to leave comments. Log in, please.