Команда Power BI рассказала, как она обеспечивает надёжную, производительную и масштабируемую работу своего сервиса. В этой статье вы узнаете, как в Power BI устроен мониторинг состояния сервиса, как SRE команды устраняют инциденты и принимают меры по улучшению сервисов.

Предыстория

Power BI — это облачный сервис, который работает по всему миру. Если в количественных показателях, то он:

обслуживает 260 000 организаций и 97 % компаний из списка Fortune 500;
развёрнут в 52 регионах Azure по всему миру;
обрабатывает около 20 миллионов запросов в час на пике;
загружает более 90 петабайт данных в месяц в семантические модели клиентов;
использует 149 кластеров, работающих на более чем 350 000 ядрах.

Несмотря на шестилетний трехзначный рост и постоянное расширение, сервис Power BI демонстрирует высокую надёжность и операционную эффективность. Такой сервис нуждается в исключительной надёжности. Ниже приведены результаты надёжности, которые удалось достичь внедряя инновационные инженерные решения, инструменты и культуру за последние несколько лет.

Команда Power BI добилась экспоненциального роста и быстрых циклов обновления без увеличения общих затрат и нагрузок на менеджмент. На следующем графике вы можете увидеть постоянное и значительное снижение стоимости услуг Service Reliability Engineering в расчёте на одного ежемесячного активного пользователя (MAU).

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

Кроме того, всё больший процент инцидентов на рабочем сайте Power BI теперь может быть решён частично или полностью с помощью автоматизации. На приведённой ниже диаграмме показано снижение Time to Mitigate (TTM) инцидентов на 90 % за последние два года, в то время как использование сервиса выросло более чем в три раза. За тот же период было введено оповещение с помощью автоматизации, которое отклонило более 82 % инцидентов.

В результате этих усилий надёжность сервиса для клиентов значительно повысилась и достигла почти четырёх девяток (99,99 %).

Далее в статье описывается подход и лучшие практики Power BI, которые позволили команде SRE достичь этих результатов. Рассказывается о типах инцидентов, процессах расследования, лучших практиках для масштабирования этих процессов и ключевых результатах деятельности (OKR), которые команда использует для оценки успеха.

Почему происходят инциденты и как с ними жить

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

Инциденты на рабочем сайте можно разделить на несколько категорий:

Проблемы с зависимыми сервисами (такими как Microsoft Entra ID, Azure SQL, Storage, virtual machine scale set, Service Fabric).
Отключение инфраструктуры (например, отказ оборудования, отказ центра обработки данных).
Проблемы с конфигурацией среды Power BI (например, недостаточная мощность).
Регрессии кода сервиса Power BI.
Неправильная конфигурация клиента (например, недостаток ресурсов, некорректные запросы/отчёты).

Снижение количества инцидентов — это один из способов снизить нагрузку на рабочий сайт и улучшить удовлетворённость клиентов. Однако это не всегда возможно, поскольку некоторые категории инцидентов находятся вне прямого контроля команды. Кроме того, по мере того как зона покрытия сервиса расширяется, вероятность возникновения инцидента из-за внешних факторов увеличивается. Большое количество инцидентов может возникать даже в случаях, когда в сервисе Power BI минимальные регрессии кода сервиса и он соответствует или превышает целевые показатели уровня обслуживания (SLO) для общей надёжности на уровне 99,95 %. Это привело к тому, что команда Power BI выделила значительные ресурсы, чтобы снизить затраты на инциденты до такого уровня, который будет приемлемым как с финансовой точки зрения, так и с точки зрения инженерии.

Процесс работы с инцидентами

При расследовании инцидентов на рабочем сайте команда Power BI следует стандартному операционному процессу, который является общим для Microsoft и отрасли. На следующем изображении представлен стандартный жизненный цикл обработки инцидентов на рабочем сайте.

На первом этапе, который является этапом мониторинга сервиса, команда SRE работает с инженерами, менеджерами программ и высшим руководством, чтобы определить индикаторы уровня обслуживания (SLIs) и целевые показатели уровня обслуживания (SLOs). Они определяются как для основных сценариев, так и для второстепенных. Эти цели относятся к различным метрикам сервиса:

надёжность сценария/компонента;
производительность сценария/компонента (или задержка),
потребление ресурсов.

Затем команда рабочего сайта и команда продукта создает оповещения, которые отслеживают индикаторы уровня обслуживания (SLIs) по сравнению с согласованными целями. При обнаружении нарушений срабатывает оповещение и начинается расследование.

На втором этапе, который является этапом реагирования на инциденты, процессы структурированы так, чтобы обеспечить следующие результаты:

Немедленное и целенаправленное уведомление клиентов о любом соответствующем воздействии.
Анализ затронутых компонентов сервиса и рабочих процессов.
Целенаправленное смягчение воздействия инцидента.

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

Наши методы мониторинга сервиса

Команда Power BI исповедует последовательный, основанный на данных (data-driven) и ориентированный на клиента (customer-centric) подход к работе. Команда определяет индикаторы уровня обслуживания (SLIs) и в соответствии с ними внедряет алерты для мониторинга рабочего сайта. Это один из критериев, по которым утверждается любая новая функция Power BI при включении в продакшн. Инженеры группы продуктов также используют инструкции по расследованию и устранению инцидентов с помощью шаблона «Руководство по устранению неисправностей» (Troubleshooting Guide, TSG). Затем они передают их команде обеспечения надёжности сервиса (Site Reliability Engineering, SRE).

В команду SRE Power BI входят специалисты с опытом в архитектуре сервиса, автоматизации и управлении инцидентами. Они непосредственно участвуют в разрешении инцидентов и доводят процесс до конца. Этот подход отличается от ротационного, когда лидеры разработки из группы продуктов берут на себя роль менеджера инцидентов всего на несколько недель в году. Команда SRE Power BI следит за тем, чтобы одна и та же группа людей отвечала за улучшение рабочего сайта. Также они следят за тем, чтобы уроки, извлечённые из предыдущих инцидентов, учитывались в будущем. Команда SRE также помогает проводить масштабные учения, которые проверяют возможности сервиса в области обеспечения непрерывности бизнеса и аварийного восстановления (Business Continuity and Disaster Recovery, BCDR).

Члены команды SRE используют свои уникальные навыки, богатый опыт работы с рабочим сайтом и сотрудничают с командами разработки. Их задача — улучшить SLI и алертинг различными способами. Вот некоторые из этих способов:

Алерты об аномалиях. Специалисты SRE разрабатывают систему мониторинга, которая учитывает типичное использование и рабочие шаблоны в данной производственной среде. Когда происходят значительные отклонения, прилетает алерт. Пример: увеличивается задержка обновления семантических моделей на 50 % по сравнению с аналогичными периодами использования.
Алерты для конкретных клиентов или конкретного окружения. Специалисты SRE разрабатывают систему мониторинга для конкретных клиентов, конкретных мощностей или кластеров. Когда их поведение отклоняются от ожидаемого, прилетает алерт. Пример: одна мощность, принадлежащая клиенту, не может загрузить семантические модели для запросов.
Тонко настроенные оповещения. Специалисты SRE выявляют подгруппы пользователей, которые могут столкнуться с проблемами, которых нет у основной массы пользователей. Для таких случаев создаются специальные алерты, которые срабатывают, если происходят редкие сбои. Пример: не удаётся обновить семантические модели, использующие коннектор GitHub.
Алерты о воспринимаемой надёжности. Это оповещения о проблемах у клиента. Такие проблемы могут быть связаны с ошибками пользователя, проблемами с документацией или с любым другим пользовательским опытом. Часто такие ошибки классифицируются как ошибки пользователя. Но среди них есть и системные ошибки, о которых инженер должен получить уведомление. Пример: сбой обновления семантической модели из-за неверных учётных данных.

Ещё одна важная роль команды SRE заключается в максимально возможной автоматизации. Команда автоматизирует действия из «Руководства по устранению неполадок» (Troubleshooting Guide, TSG) с помощью Azure Automation. В случае, если полная автоматизация невозможна, то команда SRE старается сделать алертинг максимально полезным, чтобы он работал со специфичной диагностической информацией. Это помогает ускорить последующее расследование. Если инженеры обладают богатым набором полезной информации, то им легче предпринять конкретные действия для смягчения инцидента, либо быстро передать проблему специалистам с большим опытом. Такие «оповещения с обогащением» также могут быть полностью автоматизированы, если это рентабельно и соотносится с объёмом/серьёзностью инцидентов.

В результате этих усилий более 82 % инцидентов устраняются без какого-либо взаимодействия с людьми. Для оставшихся инцидентов собирается богатый набор информации и сопроводительной документации. Это позволяет справиться с ними без привлечения специалистов с большим опытом в 99,7 % случаев.

Специалисты SRE рабочего сайта также обеспечивают качество оповещений несколькими способами:

Гарантируют, что «Руководства по устранению неполадок» (Troubleshooting Guide, TSG) включают анализ воздействия и политику эскалации — то есть правила по которым для разрешения инцидента привлекают специалистов разного уровня и различной специализации.
Гарантируют, что оповещения срабатывают за максимально короткий промежуток времени и способствуют быстрому обнаружению.
Гарантируют, что оповещения используют пороговые значения надёжности вместо абсолютных ограничений, учитывают масштабирование кластеров.

Наши методы реагирования на инциденты

Когда для сервиса Power BI создаётся автоматическое оповещение о происшествии, для клиентов сразу создается уведомление. Оно должно сообщить им о возможных проблемах. В Azure целевое время уведомления составляет 15 минут. Но достичь его сложно, если оповещения рассылаются менеджерами вручную. Сообщения в таких случаях могут опаздывать или содержать неточную информацию из-за ручного анализа.

Azure Monitoring предлагает централизованные решения для мониторинга и оповещения. Они могут обнаруживать влияние на определённые показатели в течение этого промежутка времени. Однако Power BI — это SaaS-предложение с комплексными сценариями и взаимодействиями с пользователями. Их сложно смоделировать и отслеживать с помощью таких систем оповещения.

Поэтому команда Power BI разработала новаторское решение под названием TTN0.

TTN0 (время до уведомления «0») — это полностью автоматизированный сервис уведомлений об инцидентах, который использует внутреннюю систему оповещения для выявления конкретных сценариев и клиентов, на которых повлиял недавно созданный инцидент. Он также интегрирован с внешними агентами мониторинга за пределами Azure. Это помогает обнаруживать проблемы с подключением, которые иначе могли бы остаться незамеченными. С помощью TTN0 клиенты получают электронное письмо, когда TTN0 обнаруживает сбой или ухудшение работы сервиса.

С помощью TTN0 команда Power BI может отправлять адресные уведомления в течение 10 минут с момента начала воздействия инцидента. Это на 33 % быстрее, чем целевое время в Azure. Поскольку решение полностью автоматизировано, риск человеческой ошибки или задержек минимален.

По состоянию на май 2021 года более 8000 компаний зарегистрировались для получения оповещений TTN0.

Как упоминалось в предыдущем разделе, философия рабочего сайта Power BI делает упор на автоматическое разрешение инцидентов. Акцент на автоматизации позволяет смягчать последствия в больших масштабах и может потенциально избежать дорогостоящих откатов или рискованных ускоренных исправлений производственных систем. Это благоприятно влияет и на саму SRE команду.

Когда требуется ручное исследование, Power BI использует многоуровневый подход с первоначальным расследованием, которое проводит специальная команда SRE. Она имеет опыт в управлении инцидентами. Её задача — облегчить взаимодействие между командами и смягчить последствия. В случаях, когда кто-то из команды SRE нуждается в дополнительной информации об инциденте или затронутом компоненте, он может привлечь эксперта по этому вопросу (SME) для получения инструкций. Кроме этого, SME проводят учения. Они симулируют сбои в системных компонентов, которые помогают понять и смягчить проблемы до возникновения реального инцидента.

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

Активация параллельной инфраструктуры развёртывания. Power BI поддерживает запуск разных версий рабочих нагрузок в одном кластере. Это позволяет команде запускать новую (или предыдущую) версию определённой рабочей нагрузки для определённых клиентов без запуска полномасштабного развёртывания (или отката). Этот подход может сократить время смягчения последствий до 15 минут и снизить общий риск развёртывания.
Запуск процесса восстановления (Business Continuity/Disaster Recovery, BCDR). Он позволяет команде переключать основные рабочие нагрузки на эту альтернативную среду за три минуты. BCDR также может использоваться, когда факторы окружения или зависимые сервисы мешают основному кластеру или региону работать в обычном режиме.
Использование устойчивости зависимых сервисов. Power BI активно инвестирует в обеспечение устойчивости и резервирования для всех зависимых сервисов (таких как SQL, Redis Cache, Key Vault). Устойчивость включает в себя достаточный мониторинг компонентов для обнаружения регрессий вверх и вниз по потоку, а также локальное, зональное и региональное резервирование (где это применимо). Инвестирование в это гарантирует, что существует инструментарий для автоматического или ручного запуска операций восстановления для смягчения последствий от затронутой зависимости.

Наши практики непрерывного улучшения

Команда Power BI ревьювит все инциденты, повлиявшие на клиентов, во время еженедельного обзора сервиса. В нём принимают участие представители всех инженерных групп, которые вносят свой вклад в сервис Power BI. В рамках этого обзора ключевые выводы из инцидента доводятся до руководства всей организации. Так удаётся закрывать пробелы и устранять неэффективность.

Перед обзором команда SRE готовит материалы для постмортемов и предварительно определяет для команды разработки, что в рабочем сайте нужно ремонтировать. Это могут быть исправления кода, расширенная телеметрия или обновления алертинга/TSGs. Сотрудники SRE Power BI часто вносят коррективы в режиме реального времени, реагируя на активный инцидент. Это помогает гарантировать, что изменения будут включены в систему вовремя, чтобы обнаружить повторение подобной проблемы. В случаях, когда инцидент был результатом эскалации со стороны клиента, команда SRE корректирует существующие автоматические оповещения и SLIs.

Примерно 0,3 % инцидентов требуют привлечения эксперта по определённому компоненту или сценарию (SME). Команда SRE Power BI ищет способы, как обрабатывать подобные инциденты в будущем без привлечения экспертов. Детальный анализ команды SRE помогает команде разработки продукта создавать более надёжный, масштабируемый и удобный в обслуживании продукт.

Помимо рассмотрения конкретных постмортемов, команда SRE также генерирует отчёты по совокупным данным об инцидентах. Это помогает определить возможности для улучшения сервиса. Например, для будущей автоматизации смягчения последствий инцидентов или исправления продукта. В отчётности могут быть данные из нескольких источников, включая команду поддержки клиентов, автоматические оповещения и телеметрию сервиса. Это обзор даёт представление о тех проблемах, которые наиболее негативно влияют на работу сервиса и команды. Затем команда SRE определяет приоритеты для потенциальных улучшений на основе общего ROI. Например, если определённое оповещение срабатывает слишком часто или вызывает непропорциональное влияние на надёжность сервиса, команда SRE вместе с командой разработки начинает работать над соответствующими улучшениями качества. Это способствует улучшению показателей сервиса и рабочего сайта и напрямую способствует достижению ключевых результатов организации (OKR). В случаях, когда SLI постоянно соблюдается в течение длительного периода времени, команда SRE может предложить увеличение SLO сервиса, чтобы обеспечить улучшенный опыт для клиентов.

Измерение успеха с помощью ключевых результатов (OKR)

Команда Power BI использует полный набор ключевых результатов (OKR), чтобы обеспечить общее здоровье сервиса, удовлетворённость клиентов и счастье инженеров. OKR можно разделить на две категории:

Ключевые результаты (OKR) для здоровья сервиса. Эти OKR прямо или косвенно измеряют состояние сценариев или компонентов сервиса. Часто они отслеживаются с помощью мониторинга и оповещений. Пример: сбой загрузки семантических моделей для запросов у одного из клиентов.
Ключевые результаты (OKR) для здоровья рабочего сайта. Эти OKR прямо или косвенно измеряют эффективность и результативность действий по устранению инцидентов и отключений сервиса. Пример: время уведомления (TTN) клиентов об инциденте, который на них влияет.

В следующей таблице показаны основные ключевые результаты (OKR) для здоровья рабочего сайта.

Время, которое требуется команде Power BI для реакции на инциденты, значительно превышает значения TTN, TTA и TTM. Автоматизация оповещений напрямую связана со способностью команды обеспечивать экспоненциальный рост сервиса. Одновременно команда SRE в Power BI поддерживает или превышает целевые показатели времени отклика на оповещения об инцидентах, уведомления и смягчение последствий.

За двухлетний период команда SRE в Power BI добавила автоматизацию, чтобы отклонить более 82 % инцидентов. Ещё 6% были обогащены дополнительной информацией. Это позволяет инженерам быстро принимать меры по смягчению последствий инцидентов, когда они происходят. Такой подход также позволяет узким SME специалистам сосредоточиться на функциях и упреждающих улучшениях качества вместо того, чтобы снова и снова участвовать в срочных расследованиях инцидентов.

Вышеуказанные OKR активно отслеживаются командой рабочего сайта Power BI и командой высшего руководства. Это гарантирует, что команда соответствует базовым требованиям, может поддерживать рост сервиса, устойчивую рабочую нагрузку и обеспечивать высокую удовлетворённость клиентов.

Что дальше

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

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

Если вы планируете внедрять SRE-практики в вашей компании, приходите в Слёрм на курс SRE: data-driven подход к управлению надежностью систем. На время обучения вы станете SRE для сервиса покупки билетов в кинотеатр. Решая предложенные кейсы, вы получите представление, чем занимается SRE в реальности.

? Посмотреть программу курса.

Как реализован SRE подход в Power BI