Home

Автор: Кристин Джеквони (Kristin Jackvony)
Оригинал статьи
Перевод: Ольга Алифанова

На этой неделе я расскажу о трех вещах, которые нечасто ассоциируются с тестированием: это логирование, мониторинг и предупреждения. Возможно, вы пользуетесь логами, тестируя, однако мониторинг и предупреждения – проблемная область в IT и DevOps. Но ведь приложение без багов не стоит ничего, если ваши пользователи не могут до него добраться, потому что сервер упал! Поэтому очень важно разбираться в логировании, мониторинге и предупреждениях, чтобы мы, как тестировщики, могли участвовать в обеспечении качества наших приложений.

Логирование

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

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

Хорошие сообщения логов должны быть удобопонятны и давать полезную информацию. Очень раздражает, когда видишь сообщение об ошибке, говорящее "Произошла неизвестная ошибка", или "Ошибка TSGB-45667". Спросите разработчика, может ли он предоставить внятные уведомления в логах о том, что пошло не так, и в какой части кода это случилось.

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

Мониторинг

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

Вот для чего нужен мониторинг:

• Время отклика сервера
• Нагрузка на сервер
• Серверные ошибки – например, уровня 500
• Загрузка процессора
• Использование памяти
• Пространство на диске.

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

Предупреждения

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

Это могут быть, например, такие события:

• Загрузка процессора или памяти превысила определенный уровень.
• Пространство на диске ниже определенного уровня.
• Количество ошибок 500 выше определенного уровня.
• Проверка здоровья дважды провалена.
• Время отклика ниже, чем ожидалось.
• Нагрузка больше, чем обычно.

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

Вы, возможно, говорите себе "Но я тестировщик! Настраивать логирование, мониторинг и предупреждения для компнаии – не моя задача!" Здоровье вашего приложения – это зона ответственности всех, кто над ним работает, включая вас! У вас, возможно, нет полномочий заказывать ПО для мониторинга сервера, но вы можете спросить команду вот о чем:

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

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

Обсудить в форуме