Многие ИТ-структуры наслышаны о смелых подходах в обеспечении безопасности и тестировании стрессоустойчивости в таких крупных американских компаниях, как Amazon или Netflix. Существует целое направление для стресс-тестирования всей ИТ-инфраструктуры, называемое Chaos-Engineering. Это подход, при котором принимается решение направить на важнейшие кластеры ИТ-инфраструктуры реальные, но контролируемые разрушительные действия, чтобы проанализировать последствия разрушений и улучшить ИТ-систему.
Самые крупные сбои, например на ключевых дата-центрах, можно пережить с минимальными потерями, если начать с разработки особой микросервисной архитектуры и создания специализированных инструментов для тестирования — chaos testing. В этом также может помочь переход на облачную инфраструктуру. Все эти решения, безусловно, эффективны, но стоят немало и требуют значительных временных затрат и большой высококвалифицированной команды.
Российские ИТ-компании среднего и малого масштаба крайне редко могут в полную мощь использовать опыт зарубежных гигантов. Однако взять на вооружение некоторые практики будет нелишним. Самое важное — понимать принцип и главную цель хаос-инжиниринга: своевременно и регулярно обнаруживать проблемы, которые не устраняются должным образом, и обезопасить пользователей от влияния сбоев в ИТ-системах.
В малых и средних командах внедрением и использованием best practice хаос-инжиниринга может заняться QA-команда, которая будет организовывать и поддерживать процессы тестирования инфраструктуры, разрабатывать сценарии отказа системы, анализировать и фиксировать возникшие проблемы, выставлять приоритеты и продумывать поведение системы.
Применение хаос-инжиниринга при тестировании медицинского ПО
Рассмотрим на реальном примере, как QA-команда может организовать хаос-инжиниринг при тестировании микросервисного приложения.
Это веб-проект для врачей крупной клиники, где одной из ключевых фич приложения является аудиозапись с применением специализированного устройства с микрофоном в браузере через специальный плагин. Критичной ситуацией для данной фичи будет потеря данных при записи, поскольку доктор диктует диагноз пациента, анамнез или схему лечения. Такие случаи, когда врач надиктовывает информацию, а затем обнаруживает, что запись не ведется или потеряна, должны быть полностью исключены.
Для наглядности рассмотрим архитектурную схему фичи (схема представлена не в полном виде из-за NDA. — Прим. ред.).
Для эффективного проведения стресс-тестирования необходимо определить точки отказа. Этот термин применяется к программным компонентам, при отказе которых система принимает нерабочее состояние. В нашем случае точками отказа являются компоненты, поломка которых может привести к потере записи аудио:
- База данных
- Сервер
- Веб-клиент
- Аудио-плагин
- Протокол связи
- Пользовательский ПК
В соответствии с принципами хаос-инжиниринга важно сформировать ряд гипотез, отображающих поведение системы при самых разных сбоях. Ниже приведем несколько возможных проблем, а также предположения, как должна вести себя система.
Точка отказа
Возможная проблема
Поведение системы
Протокол связи
Что будет, если у пользователя пропадет интернет-соединение.
Аудио должно сохраниться на сервер, при сбое потеря аудио не должна превышать 1 секунду.
Система уведомит пользователя о потере соединения.
Система не позволит пользователю продолжить запись.
Система будет выполнять попытки восстановить соединение
Сервер
Что будет, если при сохранении аудиофайла сервер будет недоступен.
Аудио должно сохраниться на сервер, при сбое потеря аудио не должна превышать 1 секунду.
Система уведомит пользователя о потере соединения с сервером.
Система не позволит пользователю продолжить запись.
Система будет выполнять попытки соединиться с сервером.
Веб-клиент
Что будет, если во время записи произойдет падение браузера.
Аудио должно сохраниться на сервер, при сбое потеря аудио не должна превышать 1 секунду.
Система позволит пользователю прослушать и завершить запись при входе в систему.
Пользовательский ПК
Что произойдет, если во время записи отключится электричество.
Аудио должно сохраняться в процессе записи...
