Отказ AWS 20 октября стал мощным напоминанием о том, насколько взаимосвязанными стали сегодняшние приложения и сервисы. От банковского дела до потоковой передачи, от здравоохранения до логистики — организации всех размеров и отраслей полагаются на сложную сеть общедоступных облаков и других сторонних сервисов. Как мы видели, один сбой может быстро распространиться, затрагивая не только одну компанию, но и целые отрасли и миллионы конечных пользователей.
Столкнувшись с такими потрясениями, естественно задаться вопросом: почему больше компаний не могут создать эффективные резервы, чтобы оградить себя от подобных потрясений? Ответ кроется в сложности.
Скрытая сложность современных приложений
Беспрепятственный цифровой опыт, которого ожидают клиенты и сотрудники, обеспечивается плотной сетью компонентов инфраструктуры и услуг, часто полученных от третьих сторон. Современные приложения зависят от множества базовых сервисов, включая облачные платформы, управляемые базы данных, бессерверные функции и внешние API, которые сами могут полагаться на одних и тех же поставщиков облачных услуг или аналогичные внешние зависимости. Эта сложная сеть затрудняет создание полностью резервируемых систем с эксплуатационной и экономической точек зрения.
Даже при запланированном аварийном переключении, например переключении на другой регион поставщика облачных услуг, эти стратегии далеко не однозначны. Каждый дополнительный уровень избыточности создает свой собственный набор зависимостей и проблем управления.
Полное резервирование невозможно
Для организаций, в которых имеется некоторая избыточность, сложно определить, когда следует активировать аварийное переключение. Избыточность может быть реализована несколькими способами: поддержка нескольких отдельных зон отказа, когда экземпляры и рабочие нагрузки распределяются между разными поставщиками облачных услуг (мультиклауд), или использование архитектур «активный-активный», в которых рабочие нагрузки выполняются параллельно, и обслуживание может поддерживаться, если какой-либо из них становится недоступным. Например, платформа электронной коммерции может реплицировать свои критически важные базы данных и серверы приложений в двух разных регионах в рамках одного и того же поставщика облачных услуг, чтобы обеспечить непрерывность обслуживания, если в одном регионе произойдет сбой.
Однако аварийное переключение и действия по исправлению сами по себе могут оказаться разрушительными и потребовать времени для их выполнения. Согласованность данных, синхронизация состояния сеанса и задержки распространения DNS могут привести к осложнениям и потенциальному ухудшению качества обслуживания во время перехода. В некоторых случаях отработка отказа может создать новые проблемы, если вторичная среда не полностью обновлена или если она имеет общие скрытые зависимости с основной.
Принятие правильного решения зависит от понимания масштаба сбоя (локального или повсеместного), продолжительности (временной или продолжительной), поведения основных зависимостей и реального влияния на пользователей и бизнес-результаты. Без этого понимания исправление ситуации может быть отложено или даже ухудшено из-за нарушения работы пользователей или усугубления технических проблем.
Аргументы в пользу видимости и сопоставления зависимостей
Чтобы решить эти проблемы, организациям следует уделить приоритетное внимание улучшению прозрачности сред, от которых они зависят, независимо от того, управляются ли они самостоятельно или предоставляются третьими сторонами. Сопоставление зависимостей приложений и служб важно для выявления скрытых рисков, таких как неизвестные отдельные точки отказа, а также для формирования стратегий резервирования. Во время простоя понимание в режиме реального времени того, как работает каждая зависимость и как это влияет на конечных пользователей, становится критически важным для принятия быстрых и обоснованных решений.
Обновления статуса поставщика могут быть отложенными или слишком общими, чтобы учитывать ситуацию конкретной компании. Прямая видимость поведения служб и влияния пользователей позволяет организациям четко общаться и действовать решительно, сводя к минимуму сбои в работе бизнеса.
Роль цифровой устойчивости
Сбои в работе поставщиков облачных услуг напоминают нам, что устойчивость зависит не только от умной архитектуры, но также от интеллекта и прозрачности всей службы. Поскольку организации продолжают использовать облачные, SaaS, а теперь и рабочие нагрузки искусственного интеллекта, архитектура которых часто увеличивает сложность зависимостей, важно осознавать, что каждое из них открывает как огромные возможности, так и новые категории рисков.
Способность справляться с отключениями и другими сбоями зависит не только от резервирования, которое никогда не может быть идеальным, но и от того, насколько эффективно организации могут видеть, понимать и реагировать на свою среду в условиях стресса. Экологическая осведомленность требует сквозной прозрачности, что делает ее краеугольным камнем цифровой устойчивости.
ТЕНДЕНЦИОННЫЕ ИСТОРИИ YOUTUBE.COM/THENEWSTACK Технологии развиваются быстро, не пропустите ни одной серии. Подпишитесь на наш канал YouTube, чтобы смотреть все наши подкасты, интервью, демонстрации и многое другое. ПОДПИСАТЬСЯ Группа, созданная в Sketch. Джо Ваккаро — вице-президент и генеральный менеджер подразделения Cisco ThousandEyes. Он отвечает за общую стратегию и рост ThousandEyes, платформы, которая обеспечивает сквозную прозрачность и аналитику в каждой сети, что важно для обеспечения… Подробнее от Джо Ваккаро
