История изменений
Исправление router, (текущая версия) :
Но я не могу ответить на вопрос бизнеса «модуль такой-то работает?» ответить что nginx отдаёт 200ок. Это не ответ.
А это и нельзя полностью сваливать на систему мониторинга. Тут много работы для разработчика и тестировщика.
Разработка огромных боевых человекоподобных скриптов, которые полностью эмулируют действия пользователя, потребует гораздо больше времени, чем разработка бизнес-критичного сервиса.
Перед деплоем на продакшн, тестировщики должны проверить логику работы приложения - это их работа, а не мониторинга.
При разработке критичного к простою приложения разработчики должны сами продумать возможность мониторинга наиболее проблемных частей кода. API для проверки работы, получения метрик производительности, вот это всё.
http code 200 означает, что при генерации страницы проблем не было. Этого достаточно для проверки того, что а, веб-сервер и сервер приложений работают, б, контейнер с приложением тоже жив. В мониторинг добавляются все тестовые url. Если приложение отдаёт например xml, json или что там ещё с метриками производительности и результатами самотестирования, его нужно разбирать внешними скриптами
Серьёзно, добавить автоматическую проверку логики работы средствами одной системы мониторинга это здорово. Но гораздо больший эффект будет, если разработчики тоже озаботятся таким вопросом, а перед деплоем на продуктив всё проверяется на QAS'е
Вот как с разработчиками договариваться - это отдельная тема %)
Исправление router, :
Но я не могу ответить на вопрос бизнеса «модуль такой-то работает?» ответить что nginx отдаёт 200ок. Это не ответ.
А это и нельзя полностью сваливать на систему мониторинга. Тут много работы для разработчика и программиста.
Разработка огромных боевых человекоподобных скриптов, которые полностью эмулируют действия пользователя, потребует гораздо больше времени, чем разработка бизнес-критичного сервиса.
Перед деплоем на продакшн, тестировщики должны проверить логику работы приложения - это их работа, а не мониторинга.
При разработке критичного к простою приложения разработчики должны сами продумать возможность мониторинга наиболее проблемных частей кода. API для проверки работы, получения метрик производительности, вот это всё.
http code 200 означает, что при генерации страницы проблем не было. Этого достаточно для проверки того, что а, веб-сервер и сервер приложений работают, б, контейнер с приложением тоже жив. В мониторинг добавляются все тестовые url. Если приложение отдаёт например xml, json или что там ещё с метриками производительности и результатами самотестирования, его нужно разбирать внешними скриптами
Серьёзно, добавить автоматическую проверку логики работы средствами одной системы мониторинга это здорово. Но гораздо больший эффект будет, если разработчики тоже озаботятся таким вопросом, а перед деплоем на продуктив всё проверяется на QAS'е
Вот как с разработчиками договариваться - это отдельная тема %)
Исходная версия router, :
Но я не могу ответить на вопрос бизнеса «модуль такой-то работает?» ответить что nginx отдаёт 200ок. Это не ответ.
А это и нельзя полностью сваливать на систему мониторинга. Тут много работы для разработчика и программиста.
Разработка огромных боевых человекоподобных скриптов, которые полностью эмулируют действия пользователя, потребует гораздо больше времени, чем разработка бизнес-критичного сервиса.
Перед деплоем на продакшн, тестировщики должны проверить логику работы приложения - это из работа, а не мониторинга.
При разработке критичного к простою приложения разработчики должны сами продумать возможность мониторинга наиболее проблемных частей кода. API для проверки работы, получения метрик производительности, вот это всё.
http code 200 означает, что при генерации страницы проблем не было. Этого достаточно для проверки того, что а, веб-сервер и сервер приложений работают, б, контейнер с приложением тоже жив. В мониторинг добавляются все тестовые url. Если приложение отдаёт например xml, json или что там ещё с метриками производительности и результатами самотестирования, его нужно разбирать внешними скриптами
Серьёзно, добавить автоматическую проверку логики работы средствами одной системы мониторинга это здорово. Но гораздо больший эффект будет, если разработчики тоже озаботятся таким вопросом, а перед деплоем на продуктив всё проверяется на QAS'е
Вот как с разработчиками договариваться - это отдельная тема %)