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

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

Например, вы можете просто контролировать доступность веб-страницы входа в систему. Для начала неплохо, но так вы не проверите доступность API для аутентификации клиентов. Если двинуться дальше и использовать для входа тестовую учетную запись, то вы подтвердите возможность аутентификации; однако проверяет ли это работоспособность основного сервиса? Можете ли вы запрашивать еще какие-то API, которые будут выполнять запросы (только легкие) к основной базе данных? Мы добавили всего пару дополнительных шагов, но посмотрите, насколько больше всего теперь проверяется: и сеть, и API, и база данных. Выполняйте проверку каждые 5-30 минут (в зависимости от потребностей), и, если что-то из указанного выше перестанет работать, вы очень быстро об этом узнаете.

Теперь продумайте отправку оповещений. Логично отправлять их в электронном письме, но как конкретно? Если электронная почта работает в той же сети, которая контролируется, то существует риск, что письмо не будет доставлено, потому что та же проблема, которая мешает работе сервиса, может препятствовать и отправке электронной почты. Это еще одна веская причина использовать электронную почту Google или Microsoft – независимо от того, что происходит в вашей сети, почта всегда будет доступна. Если же вы поддерживаете и используете собственный почтовый сервер, то все равно настройте для оповещений адрес не на вашем основном домене, а на бесплатном сервисе (Gmail, Yahoo и т. д.), чтобы он пересылал письма нужным людям.

Заметки с полей

Ручное обновление страницы состояния

Одна компания, с которой я работал, взаимодействовала со своим поставщиком через API. У этого поставщика был ужасно нестабильный сервис, но при этом его страница состояния всегда оставалась зеленой. Как оказалось, ее обновляли вручную, и только после того, как проходило собрание и на нем принимали решение опубликовать информацию о сбоях. Компания не хотела показывать, насколько плохой была работа их API. Вести такие игры бесполезно, особенно с учетом популярности публичных сервисов проверки, таких как Downdetector и IsItDownRightNow. Все, чего они в результате достигли, – это доказали, что их компании нельзя доверять. Нельзя скрыть что-то в мире технологий, особенно надолго.

При использовании стороннего сервиса электронной почты придерживайтесь той же схемы: создайте группу или алиас «alert», письма на который будут пересылаться всем, кому нужно. Гораздо проще управлять списком рассылки, чем отправлять письма отдельным получателям.

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