Автор: Джон О'Ши

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

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

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

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

Отображение информации в компании Amazon

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

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

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

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

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

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

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

Типы информационных панелей

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

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

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

Типы информационных панелей

Информационные панели высокого уровня

Информационные панели обслуживания клиентов

В Amazon самыми важными и самыми используемыми являются информационные панели обслуживания клиентов. Они разрабатываются для использования широкой аудиторией пользователей, включая операторов сервисов и многими заинтересованными сторонами. Они эффективно демонстрируют метрики общей работоспособности сервисов и соблюдения поставленных целей. На них отображаются данные мониторинга, полученные от самого сервиса, а также клиентских инструментов (например, метрики AWS SDK), средств постоянного тестирования (например, каналов 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 (максимальная).

Мы не ожидаем, что пользователь точно знает значение каждой метрики и каждого виджета

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

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

Мы используем состояния оповещений, простые числа и (или) виджеты с временными рядами там, где это уместно

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

Используйте простые числе везде, где это уместно

Мы стараемся избегать графиков, которые отображают метрики с большим разбросом данных

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

Мы добавляем дополнительные графики для метрик по каждой модели

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

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

Обслуживание информационных панелей

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

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

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

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

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

Выводы

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

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


Об авторе

Джон О'Ши – главный инженер в Amazon Web Services. В данный момент он занимается Amazon CloudWatch и другими внутренними сервисами мониторинга и контроля поведения.