Тысячи людей одновременно пытаются купить билеты. У одного сайт открывается без проблем, у второго возникает задержка, а у третьего страница перестает загружаться. Сервис остается тем же, но один сбой приводит к разным последствиям для пользователей. Это продемонстрировал сбой CrowdStrike в июле 2024 года: ошибка затронула 8,5 млн устройств с Windows, то есть менее 1% устройств под управлением этой операционной системы, но последствия распространились на авиакомпании, банки, ритейл и другие отрасли. С ростом аудитории увеличивается количество комбинаций устройств, сетей, внешних сервисов и пользовательских сценариев, которые приходится учитывать.
О том, почему один и тот же сервис может работать по-разному для разных пользователей и как компании реагируют на подобные проблемы, рассказал Федор Плотников, Principal DevOps & Cloud Infrastructure Leader с более чем 20-летним опытом работы в IT.
Что меняется, когда одним сервисом одновременно пользуются миллионы людей?
С ростом аудитории увеличивается количество запросов. Вместе с ним растет количество устройств, сетей, интеграций и зависимостей между сервисами. Пользователи ищут товары, оформляют заказы, оплачивают покупки и подключаются к сервису через разные сети и устройства.
Для пользователя интернет-магазин выглядит как один сайт, но на каждом этапе работают отдельные сервисы. Проблема с рекомендациями может остаться незамеченной, тогда как сбой платежной системы напрямую повлияет на возможность завершить покупку.
Во время работы в Globant я сталкивался с подобной сложностью в инфраструктуре AWS для регулируемого банковского сектора. Она была распределена между более чем 10 учетными записями. Изменение в одной среде могло повлиять на связанные системы, поэтому его приходилось оценивать с учетом цепочки зависимостей.
Почему один и тот же сбой по-разному влияет на пользователей?
Все зависит от функции компонента. Для одного пользователя это может быть небольшая задержка, для другого - недоступность отдельной функции, а в некоторых случаях сервис может полностью перестать отвечать.
Поэтому при разборе сбоя важно смотреть не только на техническую причину, но и на то, какие пользовательские сценарии затронуты. Для технической команды это один инцидент, но для клиентов последствия будут разными.
Почему с ростом аудитории становится сложнее заранее предвидеть все варианты работы сервиса?
Сложность возникает, когда совпадают несколько факторов: система работает под большой нагрузкой, внешняя служба отвечает с задержкой, а пользователь подключается через сеть со сбоями.
В проектах с распределенной инфраструктурой я сталкивался с ситуациями, когда именно сочетание таких условий приводило к сбою. Каждый фактор в отдельности команда уже проверяла, но проблема проявлялась только при их совместном действии.
Описать все варианты заранее сложно. Поэтому команда выделяет условия, влияющие на ключевые сценарии, и проверяет их по отдельности.
ЧИТАЙТЕ ТАКЖЕ: YouTube Premium Lite запустили в Украине: сколько стоит смотреть видео без рекламы
Почему доступность на уровне 99,99 % не всегда означает, что сервис надежен для клиента?
Сервис может быть доступен, но при этом отдельная операция может не работать.
Представим банковское приложение, которое открывается, показывает баланс и принимает запрос на перевод. Если перевод выполняется с задержкой, приложение формально продолжает работать, но пользователь не получает результат вовремя.
Поэтому смотреть только на доступность недостаточно. Важнее понять, выполняет ли пользователь нужное действие, сколько времени оно занимает и где возникает задержка.
Что делать, если сохранить работу всех функций во время сбоя невозможно?
Функции имеют разный приоритет для пользователя и бизнеса. Второстепенную функцию во время сбоя можно временно отключить, чтобы сохранить работу ключевых операций.
В таких ситуациях важно понимать, какие компоненты действительно критичны для работы сервиса, а где допустимы ограничения или оптимизация. Во время работы над инфраструктурой глобальной платформы для VPN и мобильной безопасности в AdTranquility мне также приходилось оценивать потребность в ресурсах и их доступность и с учетом этого расставлять приоритеты между некоторыми функциями. В результате нам удалось оптимизировать инфраструктуру и снизить затраты на 40%.
Такой подход позволяет сохранять ресурсы для действительно критически важных операций и не пытаться поддерживать все компоненты на одном уровне.
Можно ли заранее проверить все сценарии, в которых окажется пользователь?
Проверить все комбинации условий чрезвычайно сложно. Поэтому часть сбоев и задержек воспроизводят специально.
Например, команда может искусственно создать задержку во внешнем сервисе или проверить работу системы при нестабильном соединении, чтобы понять, как это повлияет на другие компоненты.
Когда таких сценариев становится слишком много, часть процессов приходится автоматизировать. Например, можно создать платформу, которая будет отвечать за обновление инфраструктуры. При таком подходе даже системы с более чем 5000 серверов, как это было в нашей работе с Syniverse, можно обновлять без значительного увеличения объема ручной работы. В данном случае это позволило сократить время развертывания изменений в 8 раз, а количество инцидентов после развертывания - на 80%.
Как понять, какие изменения в работе сервиса уже требуют вмешательства?
Условия подключения и использования могут различаться. В таких случаях в первую очередь стоит обращать внимание на то, что меняется для пользователя. Если небольшая задержка не влияет на ключевой сценарий, она может оставаться приемлемой. Если из-за нее часть аудитории не может завершить оплату или другую важную операцию, проблему уже стоит разбирать.
В высоконагруженных системах я сталкивался с ситуациями, которые проявлялись лишь у части аудитории: в конкретном регионе, при определенном типе подключения или при определенной последовательности действий. Такие различия помогали локализовать проблему.
Надежность сервиса нельзя оценивать только по общей доступности. Нужно учитывать конкретные операции и то, как их выполняют различные группы пользователей.
1 
24
Комментарии