Журнал "Information Security/ Информационная безопасность" #4, 2022

Знакомьтесь: хаос-инжиниринг Представим, что у нас имеется неболь- шой абстрактный сервис (см. рис. 1) с рядом зависимостей. Для большинства проектов это типичный случай, особенно для микросервисной экосистемы. Коли- чество зависимостей не имеет принци- пиального значения. Предположим, что сервис готов: при- ложение подготовлено к релизу, систе- ма достаточно стабильна, проект устой- чив к проблемам – пришло время раз- вернуть его на новой машине, то есть задеплоить, для непосредственного производства. Но прежде чем запустить сервис в широкое пользование, необхо- димо учесть распространенные про- блемы. Не существует сервисов, у которых не возникает сбоев – они не просто возможны, а обязательно будут. Поэтому проект дол- жен быть хорошо протестирован. Конечно, 100%-ная проверка перед запуском невоз- можна, но обязательно нужно тестировать следующие системы и структуры, наиболее подверженные уязвимостям и рискам: l внешние сервисы, которые живут своей жизнью и развиваются по собст- венному таймлайну: могут внезапно перестать работать, у них может поме- няться время ответа, формат ответа и т.д. Код таких сервисов лучше заранее сделать более гибким; l сеть, диски, базы данных; l инфраструктура ИТ (организационные структуры, а также подсистемы, обес- печивающие функционирование, разви- тие киберпространства системы и средств информационного взаимодействия); l человеческие ресурсы (так называе- мый человеческий фактор). Необходима постоянная работа с сотрудниками ком- пании на предмет ИТ- и ИБ-грамотности, ведь кто угодно может допустить логи- ческую ошибку, из-за которой что-то начнет работать не так. Перечисленные пункты представляют далеко не весь список рисков, которые сложно покрыть юнит- или интеграционным тестированием, – это только верхушка айсберга. Например, распределенные DDoS-атаки, происходящие с завидной регулярностью, относятся к тем вариантам рисков, которые невозможно предсказать с помощью тестирований. Что же такое контролируемый хаос? Тут на сцену выходит хаос-инжини- ринг – дисциплина, которая помогает подготовить приложение к тому, что реа- лизация киберрисков возможна всегда. В соответствии с сутью хаос-инжи- ринга перед нами встает задача построить приложение так, чтобы оно было готово к проблемам. Мы не будем маскировать проблемы тестами, а под- готовим проект, устойчивый к любым сбоям, которые обязательно случатся. Хаос-инжиниринг представляет собой набор экспериментов над системой/про- ектом/сервисом, включающий в себя в том числе контролируемые сбои, для выявления потенциальных проблем, которые могут возникнуть в продакшн- окружении 1 . Первоначально понятие и дисциплину создал Грегори С. Орзелл (Gregory S. Orzell) для тестирования миг- рации из центра обработки данных ком- пании Netflix в облачные технологии в 2011 г. Netflix – достаточно крупная компания, можно себе представить, чего им стоило перенести весь огромный объем своих компонентов в облако. 44 • ТЕХНОЛОГИИ Хаос-инжиниринг для обеспечения отказоустойчивости в облаке вторы книги “Неуязвимость. Отчего системы дают сбой и как с этим бороться” Андраш Тилчик и Крис Клирфилд указывают на сложность систем как на одну из причин возникновения аварий. Речь идет о масштабных системах, сложность которых неизбежно возрастает по мере перехода большинства компаний на микросервисы и прочие распределенные технологии. Избавиться от нее невозможно, но при помощи хаос-инжиниринга (Chaos Engineering) можно обнаружить уязвимости и предотвратить сбои до того, как они окажут воздействие на пользователей. А Александр Бердюгин, младший научный сотрудник департамента информационной безопасности Финансового университета при Правительстве РФ Рис. 1 1 Production-окружение – это окружение развертывания программного обеспечения, то есть рабочее, так называемое боевое, окружение, в котором производится работа с реальными клиентами и актуальными данными.