Как начать думать о Chaos Engineering
Chaos Engineering - это метод экспериментов с системой
, призванный укрепить уверенность в ее способности
противостоять турбулентным условиям в процессе производства. - https://principlesofchaos.org/
Современные компьютерные системы очень сложны и широко распространены. Архитектура микросервисов может быстро превратиться в гигантские груды лего на полу, что приведет к трудностям при устранении неисправностей, увеличению времени простоя при возникновении инцидентов и увеличению беспокойства при внесении изменений в производственную среду. Chaos Engineering может вывести вашу платформу на новый уровень за счет повышения отказоустойчивости самой платформы, повышения готовности разработчиков и операторов к реагированию на производственные инциденты и повышения уверенности разработчиков в том, что они вносят изменения в производственную среду.
Пришло время навести порядок и создать прочную производственную среду, в которой разработчики уверены. Итак, как же начать программу создания хаоса в своей организации, особенно если вы беспокоитесь о том, чтобы разрушить свой карточный домик? Приступая к работе с хаос-инженерией, следует помнить о многих важных идеях. Идея ломать что-то поначалу может показаться пугающей, но поверьте мне, вы уже намеренно ломаете что-то каждый раз, когда разрабатываете новый код.
Разработка через тестирование - первое, что я узнал во время введения в курс создания программного обеспечения в колледже. Никогда не пишите ни строчки кода для своей программы, пока не получите набор функциональных тестов. Ваши наборы тестов должны включать тестовые векторы, предназначенные для взлома вашего кода. Ни один набор тестов не будет полным без тестирования того, что происходит, когда вы вводите недопустимые входные данные или снабжаете программу массой крайних аномалий. Никто никогда не ожидает, что эти проблемы будут возникать часто, но любой хороший программист понимает, что пользователь сделает что-то неожиданно, и, если вы не проверили это, ваш код сломается или, по крайней мере, будет работать неожиданно.
Если вы собираетесь протестировать свой код, почему бы не проверить, как он работает в производственной среде? Производственная среда сейчас настолько велика и сложна, что никто не может быть уверен в том, как что-то будет вести себя при любых обстоятельствах. Вы знаете, что произойдет с вашим сервисом, если база данных, на которую он опирается, больше не будет доступна? Что, если вдруг на выполнение просто запросов уйдет больше времени? Что происходит с вашим сервисом, когда зависимость прерывается для зависимости вашего сервиса? Ни у кого не будет этого ответа, но вы можете найти ответы и начать развивать понимание новых свойств вашей производственной среды с помощью хаотической инженерии и тестирования сценариев сбоев.
Проверка на наличие сбоев - важный этап в цикле разработки. Избежание тестов на сбой только приведет к большей неопределенности в вашем коде, меньшей уверенности в внесении изменений и увеличению времени до разрешения инцидентов, к которым вы не были готовы реагировать. Следующий вопрос: если ломать что-то так важно, как мне начать ломать что-то ответственно?
Начиная с Chaos Engineering, начните с малого. Многие инженеры Хаоса назовут эту идею ограничением радиуса взрыва. Идея проста: минимизировать влияние неудачного теста. При разработке сценария сбоя для проверки не начинайте с теста черной дыры, чтобы увидеть, что произойдет, когда AWS отключит S3. Начни с малого. Разработайте тест, который влияет только на поведение вашего сервиса. Если вы не уверены, что тест не повлияет на восходящую или нисходящую зависимость или систему, не выполняйте тест. Увеличивайте радиус взрыва только после проверки устойчивости всего в радиусе взрыва.
Наблюдательность абсолютно необходима для Chaos Engineering. Когда вы начнете что-то ломать в производстве, вам захочется увидеть, что сломано. Будут вещи, которые вы ожидаете сломать, а также вещи, которые вы не ожидаете сломать. Если что-то неожиданное сломается, это будет почти невозможно исправить без всякого наблюдения. Я предлагаю иметь три формы наблюдаемости:
- Наблюдаемость: представление вашей инфраструктуры в паутине. Необходимо видеть, что на чем работает, где все эти вещи и с чем они связаны.
- Прослеживаемость: стиль диаграммы пламени или любая другая визуальная форма, которая позволяет вам видеть всю цепочку вызовов по запросу. Если вызов проходит через несколько микросервисов, в чем проблема?
- Временные ряды: графики только самого важного. Необходимы дашборды, отображающие состояние вашей платформы. Будьте осторожны, делая их слишком сложными, так как слишком много информации может ошеломить пользователей, а не помочь им.
Chaos Engineering может вывести вашу платформу на новый уровень за счет повышения отказоустойчивости платформы, а также готовности разработчиков и операторов к реагированию на производственные инциденты. Введя здоровую дозу хаоса в свои системы, вы можете начать экспериментировать с возможными сбоями, которые повлияют на вашу платформу. Это укрепит ваше доверие к платформе, помогая понять новые свойства платформы.
В целом, проходя этот процесс хаос-инжиниринга, вы с каждым днем становитесь все более подготовленными к решению реальных производственных проблем. Хаос-инжиниринг позволит вам избежать будущих производственных проблем, которые вы можете предвидеть, а также сократить время, необходимое для решения производственной проблемы, которую вы не предвидели. Существует множество ценных способов внедрения и внедрения технологии хаоса в вашей организации, и многие компании и организации сочли эти методы ценными и успешными.
