Тестирование и проверка рабочих нагрузок операторского уровня

Непрерывное тестирование и проверка могут обнаруживать и устранять проблемы, прежде чем они станут потенциально опасными для жизни. Рассмотрим хорошо известные методики тестирования, такие как тестирование хаоса. Тестирование следует проводить на протяжении всего времени существования приложения, так как среда развертывания является сложной и многоуровневой.

Важно!

Дополнительные сведения о том, как реализовать непрерывную проверку для критически важных рабочих нагрузок, см. здесь.

Кроме того, поддержка должна быть строгой на протяжении всего времени существования приложения. Высокодоступные системы зависят от высококачественных групп поддержки, способных быстро реагировать и устранять проблемы на местах, проводить анализ первопричин и искать систематические недостатки проектирования.

Чтобы доказать, что приложение хорошо спроектировано, требуется тестирование. В идеале используйте платформу хаотического тестирования, чтобы избежать предвзятости при тестировании. Эта методология имитирует сбои всех зависимых элементов. Надежное и регулярное тестирование должно подтвердить проект и проверить исходный анализ режима сбоя.

Флаг предупреждения должен быть поднят для любого приложения или службы, для которых невозможно проверить избыточность или устойчивость, так как они считаются слишком рискованными.

Если меры избыточности и устойчивости не проверяются, единственное допустимое предположение с критической точки зрения безопасности заключается в том, что эти меры не будут работать при необходимости. Использование общих путей для обновлений программного обеспечения, обновлений конфигурации и восстановления сбоев, например, обеспечивает хороший механизм проверки того, что меры будут работать.

Ошибка из-за действий человека

Опыт telcos заключается в том, что до 60% всех сбоев на самом деле являются результатом человеческой ошибки. Хорошо спроектированное приложение распознает это и стремится компенсировать это. Ниже приведены некоторые предлагаемые подходы, но список не является исчерпывающим, и то, что применимо к определенной рабочей нагрузке, необходимо рассмотреть в индивидуальном порядке.

• Максимальное использование автоматизации позволяет избежать необходимости вводить длинные и сложные команды или выполнять повторяющиеся операции в нескольких элементах. Однако необходимо учитывать радиус взрыва, так как существует риск того, что автоматизация фактически увеличит последствия ошибки конфигурации, что позволит ей развернуться по глобальной сети за считаные секунды. Рекомендуется использовать надежные сдержки и противовесы, такие как шлюзы принятия решений, требующие одобрения человека перед переходом к следующему шагу.
• Использование средств проверки синтаксиса и средств моделирования сводит к минимуму вероятность ошибок или непредвиденных побочных эффектов от внесения изменений в широко распространенное производство.
• Использование тщательно контролируемых канареечного развертывания гарантирует, что влияние изменений в полной рабочей среде можно наблюдать и проверять при ограниченном область.
• Обеспечение того, чтобы интерфейсы и процессы управления, необходимые для восстановления сбоя, совпадали с теми, которые используются в повседневной работе, избежать того, чтобы операторы не сталкивались с незнакомыми экранами и едва используемыми методами процедур (MOP) в периоды пиковой нагрузки.

Клиенты

Общие клиентские библиотеки также являются частью комплексной системы и нуждаются в эквивалентном анализе и тестировании. Проблемы с программным обеспечением в общем клиентском коде, которые одновременно влияют на часть системных клиентов, влияют на общую доступность так же, как и проблемы на стороне сервера приложений.

Следующий шаг

Вернитесь к пяти основным аспектам архитектуры, чтобы сформировать прочную основу для рабочих нагрузок операторского уровня.

Azure Well-Architected Framework