Не совсем так. Традиционные тестирования закладываются с известными переменными, в то время как хаос призван выявлять непредвиденные ситуации. Может не совсем удачный пример, но попробую привести пример с кнопкой. Для тестирование кнопки задают выходные значения - кнопка нажалась, кнопка не нажалась. Ок, кнопка нажимается. Деплоим в прод. В проде кнопка нажимается, и даже выдает нужный результат. Но разработчик разрабатывал кнопку с правилом, что сеть всегда 100% доступности с бесконечной скоростью. А что если вдруг результат от нажатия кнопки задерживается, запаздывает? Пользователь начинает паниковать, жмет кнопку ещё 100 000 раз, и вот у вас уже очередь копится запросов))) Дальше больше, и тут вы уже не уверены как будет вести себя ваша система. Это и пытается донести chaos engineering
Вы совершенно правы, инструментарий это только вершина. Но именно оно, одно из самых больших заблуждений, с которыми сталкиваются начинающие. Они берут инструментарий, видят там "подготовленные" сценарии (для "чужих" систем) и запутавшись в организации процесса, отталкивают саму идею. Но вот про управление рисками, тут я с вами к сожалению не соглашусь. CE в основном применим к распределенным системам, где последняя разрастается семимильными шагами, и оценивать риски, как и контролировать систему становится всё сложнее и сложнее. В любом случае, на мой взгляд стоимость самого CE переоценена, она может стать на много дешевле, если изначально понять азы и подойти с нужного ракурса.
Подскажите, в чем практический смысл Service Monitor, если можно через Service Discovery настроить любой scrape
Обязательно поправлю. Благодарствую.
Не совсем так. Традиционные тестирования закладываются с известными переменными, в то время как хаос призван выявлять непредвиденные ситуации.
Может не совсем удачный пример, но попробую привести пример с кнопкой. Для тестирование кнопки задают выходные значения - кнопка нажалась, кнопка не нажалась. Ок, кнопка нажимается. Деплоим в прод. В проде кнопка нажимается, и даже выдает нужный результат. Но разработчик разрабатывал кнопку с правилом, что сеть всегда 100% доступности с бесконечной скоростью. А что если вдруг результат от нажатия кнопки задерживается, запаздывает? Пользователь начинает паниковать, жмет кнопку ещё 100 000 раз, и вот у вас уже очередь копится запросов))) Дальше больше, и тут вы уже не уверены как будет вести себя ваша система. Это и пытается донести chaos engineering
Вы совершенно правы, инструментарий это только вершина. Но именно оно, одно из самых больших заблуждений, с которыми сталкиваются начинающие. Они берут инструментарий, видят там "подготовленные" сценарии (для "чужих" систем) и запутавшись в организации процесса, отталкивают саму идею.
Но вот про управление рисками, тут я с вами к сожалению не соглашусь. CE в основном применим к распределенным системам, где последняя разрастается семимильными шагами, и оценивать риски, как и контролировать систему становится всё сложнее и сложнее.
В любом случае, на мой взгляд стоимость самого CE переоценена, она может стать на много дешевле, если изначально понять азы и подойти с нужного ракурса.