Встроенная устойчивость службы в Microsoft 365
Корпорация Майкрософт признает необходимость предоставления решений, которые работают согласованно и остаются высокодоступными таким образом, чтобы наши клиенты могли полагаться на них. Если какая-либо служба недоступна, это называется простоем. Определение простоя варьируется для каждой службы Microsoft 365, но как правило, под простоем понимается любой период времени, в течение которого пользователи не могут использовать основные функции службы. Например, вот определение простоя для SharePoint, взятое из соглашения об уровне обслуживания Microsoft 365:
"Простой SharePoint: любой период времени, когда пользователи не могут читать или записывать любую часть семейства веб-сайтов SharePoint, для которой у них есть соответствующие разрешения".
Определения простоя для каждой службы можно найти в Соглашениях об уровнях обслуживания.
Чтобы свести к минимуму простои, как запланированные, так и непредвиденные, службы Microsoft 365 разработаны и работают таким образом, чтобы обеспечивать высокую доступность и устойчивость к сбоям, при этом в них сделан акцент на четырех областях:
Структура "активный-активный"
В Microsoft 365 мы движемся к тому, чтобы все службы были спроектированы и работали в активной и активной архитектуре, которая повышает устойчивость. Такая конструкция означает, что всегда существует несколько экземпляров службы, которые могут отвечать на запросы пользователей и размещаются в географически распределенных центрах обработки данных. Весь пользовательский трафик поступает через службу Microsoft Front Door и автоматически направляется в оптимально расположенный экземпляр службы, что обеспечивает устранение любых сбоев службы, чтобы предотвратить или уменьшить влияние на наших клиентов.
Сокращение масштаба инцидента
Масштаб инцидента, связанного со службой, измеряется на основе его серьезности, времени его продолжительности, а также количества затронутых им клиентов. Мы стремимся ограничить масштаб всех инцидентов следующими средствами:
- обеспечение нескольких экземпляров каждой службы, отделенных друг от друга;
- развертывание обновлений контролируемым и дифференцируемым способом с использованием «колец проверки», чтобы любые проблемы, которые могут возникнуть в результате обновления, можно было обнаружить и устранить на ранних этапах процесса развертывания. Такая конструкция обеспечивает регрессию обновления при необходимости и сначала происходит в небольшой группе внутри Корпорации Майкрософт (внутренний круг), прежде чем оно будет развернуто для более крупных групп, таких как все 140 000 сотрудников Майкрософт (круг 2), затем для ранних кругов последователей (круг 3) и, в конечном итоге, для всех клиентов во всем мире (круг 4).
- Стимулирование улучшений мониторинга с помощью автоматизации. Microsoft 365 — это большая служба, и целевое время доступности соглашения об уровне обслуживания является высоким. Говоря о самом начале инцидента обслуживания, если бы в процесс обнаружения и отклика были вовлечены люди, то мы не смогли бы быстро реагировать достаточно быстро, чтобы соответствовать требованиям соглашения об уровне обслуживания. Автоматизация — это ключ к быстрому и эффективному обнаружению инцидентов обслуживания и реагированию на них. Чем раньше мы узнаем о каких-либо проблемах, тем быстрее это можно исправить.
Наряду с возможностями "активный-активный", встроенными в архитектуру службы Microsoft 365, эти усилия снижают серьезность, длительность и количество затронутых клиентов во время инцидента службы.
Локализация отказов
Подобно тому как службы разрабатываются и работают в режиме “активный-активный”, будучи отделенными друг от друга, чтобы предотвратить влияние сбоя одной службы на другую, база кода службы разрабатывается с использованием аналогичных принципов секционирования, называемых локализацией отказов. Меры по локализации отказов — это добавочные средства защиты, реализуемые в самой базе кода. Такие меры помогают предотвратить распространение проблемы в одной области на другие области работы.
Меры изоляции ошибок применяются на нескольких этапах разработки и доставки службы, включая разработку кода, развертывание службы, балансировку нагрузки и репликацию базы данных.
Жизненный цикл разработки защищенных приложений (Майкрософт) (SDL) еще больше способствует повышению устойчивости. Он состоит из набора методов, которые поддерживают требования безопасности и соответствия требованиям. SDL помогает нашим разработчикам создавать надежные, безопасные и отвечающие требованиям службы. Ключевые элементы SDL включают проверки кода, моделирование угроз, тестирование возможностей проникновения и стандартизованные процессы реагирования на инциденты в облаке Microsoft.
Службы Microsoft 365 сильно взаимосвязаны, но системы и технологии, стоящие за ними, спроектированы таким образом, чтобы ограничить влияние одного инцидента службы от перетекания в другие службы. Например, проблема, затрагивающая Exchange, не повлияет на основные функции Teams или проблема с функциями поиска в SharePoint не повлияет на возможность пользователей отправлять или скачивать файлы.
Непрерывное улучшение обслуживания
Когда у нас имеет место инцидент, мы относимся к нему серьезно. К тому же, наша избыточная облачная архитектура и жесткие внутреннее обслуживание призваны обеспечить доступность наших служб. Во время инцидента наш мониторинг быстро обнаруживает затронутые службы, и, если ваш клиент затронут, вы будете уведомлены по различным каналам. Одновременно инженеры следуют четко определенным процессам, чтобы рассмотреть проблему и принять необходимые меры для скорейшего восстановления нормальной работы. После того как служба возобновит нормальную работу, мы проводим проверки после инцидента в рамках цикла непрерывного улучшения обслуживания. В ходе проверки после инцидента мы выявляем основные причины инцидента, а также меры, потребовавшиеся для устранения проблем. Затем мы усваиваем уроки, извлеченные из ситуации, и применяем их к структуре и работе всего нашего набора предложений. С помощью этих знаний мы можем предотвратить влияние той же первопричины на другие службы и дополнительных клиентов.