Общие сведения о проектировании для обеспечения устойчивости
Корпорация Майкрософт определяет устойчивость как "способность бизнес-процесса или службы соответствовать ожиданиям клиентов перед лицом сбоев и проблем с нормальной работой". В масштабе Microsoft Online Services устойчивость имеет решающее значение для поддержания доступности наших веб-служб. Мы создаем наши службы устойчивыми, так как знаем, что:
- Сбои оборудования неизбежны. Предположим, что средняя наработка на отказ (MTFB) составляет для жесткого диска 100 000 часов. Для одного жесткого диска это вполне управляемый один сбой каждые 11,5 лет. Но если у вас 10 000 000 жестких дисков, это соответствует одному сбою примерно каждые 30 секунд. Устойчивость к сбою распространенных аппаратных компонентов является ключевой функцией проектирования и создания веб-служб.
- Люди будут совершать ошибки. Предположим, что человек в типичной ИТ-реализации выполняет 100 операций в день в системе из 100 серверов. При точности 99 % это по-прежнему составляет одну ошибку в день. При масштабировании до 250 000 серверов это составляет 2500 ошибок в день.
- Программное обеспечение будет содержать ошибки. Обновления программного обеспечения необходимо развертывать постоянно, чтобы поддерживать службы в актуальном состоянии. Отказоустойчивые службы должны защищать себя как от новых, так и от ранее необнаруженных ошибок в программном обеспечении.
Мы реагируем на эти вызовы, используя гипермасштабируемое облако Майкрософт и применяя автоматизацию служб, чтобы сделать наши службы устойчивыми к нескольким режимам сбоев.
Дизайн службы типа "активный-активный"
По возможности мы гарантируем, что наши службы разработаны и развернуты с использованием режима устойчивости "активный-активный". Это означает, что в случае сбоя критического компонента службы доступен идентичный компонент для его замены без потери доступности. Развертывания типа "активный-активный" заменяют старые модели типа "активный-пассивный", в которых пассивным компонентам требовалось время, чтобы принять на себя рабочую нагрузку в случае сбоя активных компонентов, что временно нарушало доступность служб и целостность данных. Дизайн службы типа "активный-активный" представляет собой значительное улучшение по сравнению с другими моделями развертывания и обеспечивает устойчивость ко многим типам сбоев служб.
Изоляция сбоя
Изоляция сбоя повышает устойчивость службы, предотвращая распространение сбоя в одном компоненте на другие компоненты. Изоляция сбоя дополняет дизайн службы типа "активный-активный" путем уменьшения области, требующей автоматического восстановления после сбоев компонентов. Корпорация Майкрософт постоянно работает над тем, чтобы уменьшить размер зон сбоя в наших облачных службах, чтобы предотвратить распространение сбоев и влияние на другие компоненты системы.
Вот некоторые стратегии, которые используются для изоляции сбоя:
- Детальное управление сбоями внутри и между компонентами служб. Например, группы доступности баз данных Exchange Online ограничивают влияние сбоев в службе определенными группами доступности.
- Управление несколькими протоколами для доступности служб. Например, инцидент, влияющий на доступ к файлам в Teams, можно устранить путем обеспечения доступности файла с помощью SharePoint Online.
- Регионализация и детальный дизайн системы. Дизайн нашей системы разделяет логическую и физическую инфраструктуру служб на меньшие блоки. Это позволяет нам надлежащим образом реагировать на инциденты в зависимости от их области действия, используя гибкость управления службами в небольшом и крупном масштабе.
- Балансировки нагрузки и регулирование. Наши службы регулярно перемешивают трафик и данные между компонентами системы в рамках обычной работы службы. Некритичный трафик на стороне службы регулируется в пользу критически важного трафика, например для доставки почты. Это позволяет нашим системам автоматически делать приоритетными критически важные службы в случае сбоя компонента или инцидента службы.
Уменьшение радиуса воздействия
С изоляцией сбоя тесно связана концепция "радиуса взрыва" инцидента. При возникновении инцидента радиус взрыва определяет, насколько широко инцидент влияет на наши онлайн-службы. Корпорация Майкрософт постоянно работает над уменьшением радиуса воздействия возможных инцидентов. Когда последующий анализ реагирования на инцидент выявляет тип инцидента с неприемлемым радиусом воздействия, мы отвечаем на это путем инвестиций в обновления служб, предназначенные для снижения влияния похожих инцидентов в будущем.
Непрерывное улучшение
Когда возникают инциденты, наш процесс реагирования на инциденты обеспечивает управление каждым инцидентом до разрешения. Мы используем стандартизированные метрики для отслеживания влияния инцидентов на доступность и производительность служб. Инциденты со значительным влиянием на клиентов подвергаются проверке после инцидента. Ключевые результаты и меры снижения влияния, определенные в результате проверки после инцидента, публикуются на панели мониторинга работоспособности служб, чтобы их могли просмотреть затронутые клиенты.
Проверки после инцидентов помогают выявить улучшения устойчивости, которые могут заблокировать или ограничить область воздействия похожих проблем в будущем. Уроки, полученные в результате инцидентов, распространяются в командах обслуживания, поэтому каждая команда может реализовать улучшения, не сталкиваясь напрямую с похожим инцидентом.