Да, это довольно частая ситуация.в этом же и проблема. В то время когда потребителем мониторинга инфраструктуры является только одна команда (или несколько), то observability платформы используют сразу разные смежные подразделения - разработчики видят как работает их код, техподдержка фиксирует инциденты и сразу понимают к кому идти, бизнес следит за SLO, аналитики смотрят пользовательский путь и все это они делают в одной системе. Инфраструктуру мониторить легко и многие инструменты это делают. Но проблемы на проде - это обычно ошибки в коде, интеграции, настройка garbage collector, логические ошибки. и при этом, зачастую, с инфраструктурой все прекрасно. Объединить всю информацию о системе и найти там проблему, а еще дать информацию для бизнеса - это и есть наблюдаемость (observability)
Понял мысль. В целом хотел описать как меняется подход к анализу инцидентов и мониторингу, может получилось слишком просто. Окей, статья вводная, для начала. К технической части тоже перейду — там уже будет больше конкретики. Про «передёргивания» интересно — можете указать конкретный кусок?
Согласен, в B2B вопрос доверия и ответственности за решение критичный.
Я в статье скорее разбирал, что происходит уже после выбора, когда система живет в проде: поддержка, изменения, разбор инцидентов. Там как раз и видна разница между подходами.
Статья в первую очередь для тех, кто уже сталкивался с мониторингом на практике — собирал стек на open-source или разбирал инциденты в проде. С главной все ок, скорее всего, у вас включен впн :)
Да, это довольно частая ситуация.в этом же и проблема. В то время когда потребителем мониторинга инфраструктуры является только одна команда (или несколько), то observability платформы используют сразу разные смежные подразделения - разработчики видят как работает их код, техподдержка фиксирует инциденты и сразу понимают к кому идти, бизнес следит за SLO, аналитики смотрят пользовательский путь и все это они делают в одной системе. Инфраструктуру мониторить легко и многие инструменты это делают. Но проблемы на проде - это обычно ошибки в коде, интеграции, настройка garbage collector, логические ошибки. и при этом, зачастую, с инфраструктурой все прекрасно. Объединить всю информацию о системе и найти там проблему, а еще дать информацию для бизнеса - это и есть наблюдаемость (observability)
Понял мысль. В целом хотел описать как меняется подход к анализу инцидентов и мониторингу, может получилось слишком просто. Окей, статья вводная, для начала. К технической части тоже перейду — там уже будет больше конкретики. Про «передёргивания» интересно — можете указать конкретный кусок?
Согласен, в B2B вопрос доверия и ответственности за решение критичный.
Я в статье скорее разбирал, что происходит уже после выбора, когда система живет в проде: поддержка, изменения, разбор инцидентов. Там как раз и видна разница между подходами.
Статья в первую очередь для тех, кто уже сталкивался с мониторингом на практике — собирал стек на open-source или разбирал инциденты в проде.
С главной все ок, скорее всего, у вас включен впн :)