Создание информационных панелей для операционного контроля

Все мы постоянно запускаем приложения на ноутбуках, планшетах и смартфонах. Нам не сложно определить, включено ли устройство и есть ли подключение к сети Wi-Fi. Мы знаем, что на экране отображаются все важные оповещения, например о нехватке свободного места на диске. Хорошим индикатором наличия на устройстве ресурсов (памяти, ЦП и т. п.), необходимых для запуска приложений, обычно является скорость работы и реакция пользовательского интерфейса.

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

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

Как Amazon может убедиться, что все облачные сервисы, работающие в нескольких зонах доступности во множестве регионов по всему миру, работают правильно? Автоматизированные решения для мониторинга, устранения проблем (например, для переключения маршрутизациии трафика) и развертывания играют важную роль в процессах обнаружения и устранения основной массы проблем на этом глобальном уровне. Однако по множеству причин нам до сих пор нужна возможность видеть, что делают в каждый момент времени наши сервисы, рабочие процессы или развертывания.

Мы используем информационные панели как механизм, позволяющий контролировать деятельность наших облачных сервисов. Информационные панели дают возможность оценить работу систем, предоставляя сжатую сводку по поведению систем и важнейшим метрикам, журналам, трассировкам и оповещениям.

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

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

Такие предупреждения могут активировать автоматизированный процесс устранения неполадок и уведомлять операторов о проблеме. Уведомление содержит ссылки на конкретные информационные панели и конкретные руководства по устранению проблем, которые нужно использовать в конкретном случае. Если в период моего дежурства система оповещений сообщает мне о наличии проблем, я могу быстро проверить соответствующие информационные панели для оценки влияния проблем на клиента, проверки или выявления первопричин, устранения проблем и снижения времени, необходимого на восстановление. Даже если предупреждение уже запустило автоматизированный процесс устранения неполадок, мне важно контролировать этот процесс и его влияние на систему, а в крайних случаях поддержать этот процесс путем подтверждения наиболее важных для безопасности этапов.

При любых экстренных ситуациях Amazon привлекает к решению сразу многих дежурных операторов. По мере продвижения по цепочке задач операторы могут использовать разные информационные панели. К таким задачам обычно относятся оценка влияния на клиентов, сортировка и отслеживание нескольких сервисов для выявления первопричин события, наблюдение за автоматизированными процессами устранения проблем, выполнение и проверка шагов процедур по устранению неполадок. В то же время информационные панели используются рядовыми сотрудниками и руководителями для оценки влияния аварийных событий. Разные группы участников взаимодействуют с помощью инструмента управления инцидентами, чат-комнат (с AWS Chatbot и другими ботами), и конференц-связи. Каждая из заинтересованных сторон имеет свой взгляд на данные, отображаемые на информационных панелях.

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

Кроме того, при долгосрочном планировании и прогнозировании мощности Amazon использует информационные панели с метриками бизнес-целей, потребления и мощности, обобщенными на высшем уровне за длительные периоды времени.

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

Информация, получаемая разными лицами на разных информационных панелях, может очень существенно различаться. Мы давно поняли, что при разработке информационной панели важно учитывать задачи конкретной целевой аудитории. Выбор данных, которые будут отображаться на каждой конкретной информационной панели, определяется тем, кто и для чего будет ее использовать. Возможно, вы уже слышали, что Amazon основывает свою работу на интересах клиента. Создание информационных панелей отлично иллюстрирует этот подход. Мы создаем информационные панели на основе потребностей и требований потенциальных пользователей.

Следующая схема демонстрирует, как разные информационные панели предоставляют разные взгляды на систему в целом.

В Amazon самыми важными и самыми используемыми являются информационные панели обслуживания клиентов. Они разрабатываются для использования широкой аудиторией пользователей, включая операторов сервисов и многими заинтересованными сторонами. Они эффективно демонстрируют метрики общей работоспособности сервисов и соблюдения поставленных целей. На них отображаются данные мониторинга, полученные от самого сервиса, а также клиентских инструментов, средств непрерывного тестирования (например, каналов Amazon CloudWatch Synthetics) и средств автоматизированного исправления проблем. Также эти информационные панели содержат данные для оценки глубины и широты влияния проблем. Например, здесь можно получить ответы на вопросы «Сколько клиентов затронула проблема?» или «Кто пострадал больше всех?»

Стартовыми точками взаимодействия с веб-сервисами обычно являются конечные точки пользовательского интерфейса и API, поэтому специализированные информационные панели уровня системы должны содержать достаточно данных, чтобы оператор мог контролировать работу системы в целом и конечных точек, с которыми взаимодействуют клиенты. Эти информационные панели демонстрируют в первую очередь данные мониторинга на уровне интерфейсов. На этих информационных панелях вы найдете данные мониторинга трех основных категорий по каждому API:

• Данные мониторинга входных каналов. Сюда могут относиться сведения о количестве поступивших запросов, полученных из очередей и потоков заданий, процентном распределении размеров запросов, количестве ошибок при аутентификации и авторизации.
• Данные мониторинга вычислительных ресурсов. Сюда могут относиться сведения о количестве запусков логических путей или ветвей в мультимодальных системах, количестве запросов и сбоев и задержках на внутреннем микросервисе, выходные данные журнала сбоев и ошибок, трассировки запросов.
• Данные мониторинга выходных каналов. Сюда могут относиться сведения о количестве ответов разных типов (с разбивкой по ответам с ошибками, переданным клиентам), о размере этих ответов и процентном распределении времени на получение первого байта ответа и последнего байта ответа.

В целом мы стремимся сохранять для информационных панелей взаимодействия с клиентом и системного уровня максимально возможный уровень обобщения. Мы старательно избегаем соблазна добавлять на них дополнительные данные, так как перегруженность информацией может отвлекать от самых важных выводов, для которых создаются эти информационные панели.

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

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

Для долгосрочных целей мы создаем информационные панели планирования и прогнозирования ресурсов, которые помогают нам визуализировать темпы роста сервисов.

API Amazon обычно создаются для централизованного управления запросами к нескольким внутренним микросервисам. Это могут быть микросервисы, обслуживаемые разными подразделениями, и каждый из них отвечает за определенный аспект обработки запроса. Например, одни микросервисы занимаются аутентификацией и авторизацией, другие – регулированием и контролем ограничений, оценкой потребления, созданием, обновлением и удалением ресурсов, получением ресурсов из хранилищ данных или запуском асинхронных потоков. Разработчики обычно создают хотя бы одну информационную панель для каждого микросервиса, выводя на нее метрики по каждому API или блоку работы, если этот сервис выполняет обработку данных асинхронно.

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

Наши сервисы работают на основе инфраструктуры AWS, которая создает свой набор метрик, что позволяет нам применять специализированные информационные панели инфраструктуры. Эти информационные панели в первую очередь отображают метрики, создаваемые вычислительными ресурсами наших систем, такими как инстансы Amazon Elastic Compute Cloud (EC2), контейнеры Amazon Elastic Container Service (ECS)/Amazon Elastic Kubernetes Service (EKS) и функции AWS Lambda. На таких информационных панелях часто отображаются метрики загрузки ЦП, сетевого трафика, работы с диском и свободного места на диске, а также многие метрики кластеров, автомасштабирования и применения квот, которые имеют отношение к соответствующим вычислительным ресурсам.

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

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

При разработке информационных панелей очень частой проблемой является недооценка или переоценка знакомства целевого пользователя с предметной областью. Очень легко создать информационную панель, которую хорошо понимает ее разработчик. Но такая панель не всегда будет полезна реальным пользователям. Для устранения этой проблемы мы применяем методы разработки, основанные на потребностях клиента (в этом случае – оператора информационной панели).

Мы внедрили конвенцию разработки, устанавливающую стандарт отображения данных на информационной панели. Информационная панель отображается сверху вниз, и пользователи обычно считают самые верхние графики (которые первыми появляются при загрузке панели) самыми важными. Поэтому в нашей конвенции принято размещать в верхней части информационной панели самые важные данные. Мы выяснили, что для веб-сервисов самыми ценными являются обобщенные графики процентного распределения доступности и суммарной задержки.

Вот пример снимка экрана с верхней частью информационной панели для гипотетического сервиса Foo:

Если на графике отображается сразу несколько метрик, его легенда не должна сжимать графические данные вертикально или горизонтально. Если для графика применяется поисковый запрос, мы обязаны обеспечить отображение более крупного набора результатов.

Это позволяет избавиться от горизонтальной прокрутки. Дежурному оператору в 3 часа ночи не всегда легко заметить на экране ноутбука полосу горизонтальной прокрутки, если мы не предоставим ему очевидной подсказки, что справа есть дополнительная информация.

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

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

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

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

• За 1 час с разбивкой по 1 минуте (60 точек данных) – удобно для детального просмотра текущих событий.
• За 12 часов с разбивкой по 1 минуте (720 точек данных).
• За 1 день с разбивкой по 5 минут (288 точек данных) – полезно для анализа ежедневных тенденций.
• За 3 дня с разбивкой по 5 минут (864 точки данных).
• За 1 неделю с разбивкой по 1 часу (168 точек данных) – полезно для анализа еженедельных тенденций.
• За 1 месяц с разбивкой по 1 часу (744 точки данных).
• За 3 месяца с разбивкой по 1 дню (90 точек данных) – полезно для анализа ежеквартальных тенденций.
• За 9 месяцев с разбивкой по 1 дню (270 точек данных).
• За 15 месяцев с разбивкой по 1 дню (450 точек данных) – полезно для долгосрочного анализа мощности.
  

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

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

Такая ситуация неприятна тем, что может снизить заметность колебаний одной или нескольких из этих метрик. Например, если на одном графике отображаются значения задержки p0 (минимальные) и p100 (максимальные), которые отличаются друг от друга на несколько порядков.

Если на вертикальной оси присутствуют только значения, соответствующие текущим точкам данных, быстрый взгляд на такой график даст ложное ощущение существенных колебаний значения.

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

• доступность в процентах (отношение неудачных запросов к общему числу запросов * 100);
• значения задержки p10, среднее и p90;
• значения задержки p99,9 и p100 (максимальная).
  

Это особенно важно в отношении метрик, зависящих от реализации. Мы стремимся предоставить в подписях на информационной панели достаточно сведений о контексте, например текстовое описание рядом с каждым графиком или под ним. Этот текст позволит оператору разобраться в назначении соответствующей метрики. Так ему будет легче понять, какие значения считаются «нормальными» и что означает отклонение от них. В этот текст мы включаем ссылки на соответствующие ресурсы, которые помогут оператору определить первопричину проблем. Вот несколько примеров объектов, ссылки на которые мы предоставляем в описании:

• пошаговые руководства. Для экспертов в предметной области роль руководства может выполнять сама информационная панель;
• информационные панели «углубленного изучения»;
• аналогичные информационные панели для других кластеров или разделов;
• конвейеры развертывания;
• контактные данные по зависимостям.
  

В зависимости от сценариев использования, на которые рассчитана информационная панель, виджет с одним числом (например, с последним значением метрики) или состоянием оповещения может быть более уместным, чем отображение сложного графика с временными рядами для всех последних точек данных.

Неплотными называются такие метрики, значения для которых создаются только при наличии состояния сбоя. Иногда создание метрик только по мере необходимости позволяет повысить эффективность работы, но пользователей информационных панелей могут запутать графики, на которых нет или почти нет данных. Если при разработке информационной панели мы встречаем такую метрику, обычно в сервис вносятся изменения, чтобы он создавал для такой метрики безопасные значение (например, нуль) при отсутствии состояния сбоя. Это позволяет операторам быстро понять, что отсутствие данных означает сбой в создании телеметрии.

Это применяется в тех случаях, когда отображаемые на графиках метрики объединяют в себе поведение нескольких моделей в системе. Например, такой подход применим в следующих случаях.

• Если сервис поддерживает запросы переменного размера, мы создаем график для общей задержки по всем запросам. В дополнение к нему создаются графики с отображением метрик по малым, средним и крупным запросам.
• Если сервис обрабатывает запросы разными способами в зависимости от значений или сочетания значений входных параметров, мы можем добавить графики для метрик по каждому из этих режимов обработки.