Согласен. Но в данном кейсе задача мониторинга была на стороне заказчика (условия контракта). Сервисный партнёр подключается уже по факту инцидента. По итогам инцидента заказчику были переданы рекомендации по до настройке мониторинга
Я бы назвал это не ошибкой, а симптомом: ошибка в логе (например, нехватка памяти) — это симптом. Целью было — найти причину. В данном случае причиной был некорректный код вендора.
Инцидент произошел не в основной операционной базе, а в модуле аналитической обработки данных (Data Mart), который технически включает в себя отдельный сервер БД (на скрине с ошибкой база nice_dw ко к раз оттуда). Этот модуль выполнял фоновые ETL-процессы и, что ключевое, не был включен в перечень критически важных компонентов для мониторинга ни у заказчика, ни у сервисного партнера.
Вся архитектура мониторинга была заточена под основные базы и сервисы. Проблема же была в «слепой зоне» — фоновом процессе, который работал с архивной аналитической БД. Когда он падал, он вызывал цепную реакцию из-за повторяющейся большой нагрузки на БД.
Поэтому инженеру пришлось: Локализовать эту «слепую зону». Вручную мониторить процессы и логи именно этой базы данных. Обнаружить и исправить ошибку в коде вендора.
У них есть свой небольшой штат, они занимаются инфраструктурными задачами и сложными тикетами, которые можно решить только на месте, либо с высоким уровнем доступов к системам. А всю операционку отдали нам. Для бизнеса это дешевле и проще, снимаются вопросы по найму, содержанию, обучению, увольнению, плюс всегда можно быстро расширить или наоборот уменьшить объем услуг.
Заявки переносятся руками, далее в тикете указывается почта заявителя и уже в дальнейшем все комментарии специалист поддержки оставляет в jira, а пользователю приходят оповещения на почту, где он ответным письмом может добавлять свои комментарии. При необходимости шарится оригинальный тикет.
Согласен. Но в данном кейсе задача мониторинга была на стороне заказчика (условия контракта). Сервисный партнёр подключается уже по факту инцидента. По итогам инцидента заказчику были переданы рекомендации по до настройке мониторинга
Я бы назвал это не ошибкой, а симптомом: ошибка в логе (например, нехватка памяти) — это симптом. Целью было — найти причину. В данном случае причиной был некорректный код вендора.
Инцидент произошел не в основной операционной базе, а в модуле аналитической обработки данных (Data Mart), который технически включает в себя отдельный сервер БД (на скрине с ошибкой база nice_dw ко к раз оттуда). Этот модуль выполнял фоновые ETL-процессы и, что ключевое, не был включен в перечень критически важных компонентов для мониторинга ни у заказчика, ни у сервисного партнера.
Вся архитектура мониторинга была заточена под основные базы и сервисы. Проблема же была в «слепой зоне» — фоновом процессе, который работал с архивной аналитической БД. Когда он падал, он вызывал цепную реакцию из-за повторяющейся большой нагрузки на БД.
Поэтому инженеру пришлось:
Локализовать эту «слепую зону».
Вручную мониторить процессы и логи именно этой базы данных.
Обнаружить и исправить ошибку в коде вендора.
Спасибо за внимательность, поправил
У них есть свой небольшой штат, они занимаются инфраструктурными задачами и сложными тикетами, которые можно решить только на месте, либо с высоким уровнем доступов к системам. А всю операционку отдали нам. Для бизнеса это дешевле и проще, снимаются вопросы по найму, содержанию, обучению, увольнению, плюс всегда можно быстро расширить или наоборот уменьшить объем услуг.
Заявки переносятся руками, далее в тикете указывается почта заявителя и уже в дальнейшем все комментарии специалист поддержки оставляет в jira, а пользователю приходят оповещения на почту, где он ответным письмом может добавлять свои комментарии. При необходимости шарится оригинальный тикет.
Да, заменили то, что перестало работать, это услуги 1-ой и 2-ой линии поддержки. Задачи более сложного уровня были и остались за штатными инженерами.
Все проще. Сработала теория теория шести рукопожатий. Команда большая, мир тесен, найти коллег о цеху не составило большого труда)