Концепция анализа первопричин - История изменений

IKuznetsov в 10:17, 28 мая 2026

2026-05-28T10:17:28Z

IKuznetsov в 16:21, 3 января 2025

2025-01-03T16:21:02Z

← Предыдущая версия		Версия от 16:21, 3 января 2025
Строка 1:		Строка 1:
	'''''[[Применение АппОптима]] / Анализ проблем / Концепция анализа первопричин'''''		'''''[[Применение АппОптима]] / [[Применение АппОптима\|Анализ проблем]] / Концепция анализа первопричин'''''

	Поскольку архитектуры динамических систем становятся все более сложными и масштабируемыми, ИТ-команды сталкиваются с растущей необходимостью быстро находить критически важные для бизнеса инциденты и реагировать на них в своих мультиоблачных средах. Инциденты могут повлиять на один или несколько ИТ-компонентов, что в конечном итоге приведет к крупномасштабным сбоям в работе, приводящим к отключению критически важных бизнес-сервисов и приложений. Такие сервисы и приложения (например, системы бухгалтерского учета или интернет-магазины) состоят из множества различных компонентов, надежная работа которых зависит друг от друга и обеспечение превосходного пользовательского опыта. Если критический компонент выходит из строя, волновой эффект отрицательно влияет на многие другие зависимые компоненты, вызывая огромные инциденты.		Поскольку архитектуры динамических систем становятся все более сложными и масштабируемыми, ИТ-команды сталкиваются с растущей необходимостью быстро находить критически важные для бизнеса инциденты и реагировать на них в своих мультиоблачных средах. Инциденты могут повлиять на один или несколько ИТ-компонентов, что в конечном итоге приведет к крупномасштабным сбоям в работе, приводящим к отключению критически важных бизнес-сервисов и приложений. Такие сервисы и приложения (например, системы бухгалтерского учета или интернет-магазины) состоят из множества различных компонентов, надежная работа которых зависит друг от друга и обеспечение превосходного пользовательского опыта. Если критический компонент выходит из строя, волновой эффект отрицательно влияет на многие другие зависимые компоненты, вызывая огромные инциденты.

IKuznetsov: /* Анализ дерева ошибок */

2024-12-17T13:26:31Z

Анализ дерева ошибок

Внесённые изменения

ENetrebin в 14:31, 12 сентября 2024

2024-09-12T14:31:33Z

← Предыдущая версия		Версия от 14:31, 12 сентября 2024
Строка 1:		Строка 1:
			'''''[[Применение Ключ-АСТРОМ]] / [https://doc.ruscomtech.ru/index.php/Применение_Ключ-АСТРОМ#.D0.90.D0.BD.D0.B0.D0.BB.D0.B8.D0.B7_.D0.BF.D1.80.D0.BE.D0.B1.D0.BB.D0.B5.D0.BC Анализ проблем] / Концепция анализа первопричин'''''

	Поскольку архитектуры динамических систем становятся все более сложными и масштабируемыми, ИТ-команды сталкиваются с растущей необходимостью быстро находить критически важные для бизнеса инциденты и реагировать на них в своих мультиоблачных средах. Инциденты могут повлиять на один или несколько ИТ-компонентов, что в конечном итоге приведет к крупномасштабным сбоям в работе, приводящим к отключению критически важных бизнес-сервисов и приложений. Такие сервисы и приложения (например, системы бухгалтерского учета или интернет-магазины) состоят из множества различных компонентов, надежная работа которых зависит друг от друга и обеспечение превосходного пользовательского опыта. Если критический компонент выходит из строя, волновой эффект отрицательно влияет на многие другие зависимые компоненты, вызывая огромные инциденты.		Поскольку архитектуры динамических систем становятся все более сложными и масштабируемыми, ИТ-команды сталкиваются с растущей необходимостью быстро находить критически важные для бизнеса инциденты и реагировать на них в своих мультиоблачных средах. Инциденты могут повлиять на один или несколько ИТ-компонентов, что в конечном итоге приведет к крупномасштабным сбоям в работе, приводящим к отключению критически важных бизнес-сервисов и приложений. Такие сервисы и приложения (например, системы бухгалтерского учета или интернет-магазины) состоят из множества различных компонентов, надежная работа которых зависит друг от друга и обеспечение превосходного пользовательского опыта. Если критический компонент выходит из строя, волновой эффект отрицательно влияет на многие другие зависимые компоненты, вызывая огромные инциденты.

IKuznetsov: Создание

2024-06-10T17:31:00Z

Создание

Внесённые изменения

IKuznetsov: Создана пустая страница

2024-06-10T16:40:06Z

Создана пустая страница

Новая страница

← Предыдущая версия		Версия от 10:17, 28 мая 2026
Строка 10:		Строка 10:
	Инцидент — это аномалия в вашей среде — в приложении, инфраструктуре и т. д. Проблема — это объект , который представляет инцидент в среде АппОптима. Проблема является результатом автоматического анализа первопричин и последствий инцидента с помощью искусственного интеллекта. Проблемы (как и основные инциденты) могут охватывать множество зависимых компонентов, имеющих одинаковое воздействие и основную причину.		Инцидент — это аномалия в вашей среде — в приложении, инфраструктуре и т. д. Проблема — это объект , который представляет инцидент в среде АппОптима. Проблема является результатом автоматического анализа первопричин и последствий инцидента с помощью искусственного интеллекта. Проблемы (как и основные инциденты) могут охватывать множество зависимых компонентов, имеющих одинаковое воздействие и основную причину.

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

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

	== События ==		== События ==
Строка 26:		Строка 26:
	Чтобы определить основную причину проблем, одной временной корреляции недостаточно. Среда АппОптима использует контекстно-зависимый подход, обнаруживая взаимозависимые события во времени, процессах, хостах, службах, приложениях, а также с точки зрения вертикального и горизонтального топологического мониторинга. Этот подход объединяет несколько отдельных аномалий в одну последовательную проблему, что значительно снижает нагрузку на оповещения.		Чтобы определить основную причину проблем, одной временной корреляции недостаточно. Среда АппОптима использует контекстно-зависимый подход, обнаруживая взаимозависимые события во времени, процессах, хостах, службах, приложениях, а также с точки зрения вертикального и горизонтального топологического мониторинга. Этот подход объединяет несколько отдельных аномалий в одну последовательную проблему, что значительно снижает нагрузку на оповещения.

	На изображении ниже показано, как ИИ анализирует все горизонтальные и вертикальные зависимости проблемы. В этом примере приложение демонстрирует ненормальное поведение, в то время как базовый вертикальный стек работает нормально. Анализ отслеживает транзакции приложения, выявляя зависимость от службы (<code>Service 1</code>), которая также демонстрирует ненормальное поведение. В свою очередь, все зависимости службы также ведут себя ненормально и являются частью одной и той же проблемы.		На изображении ниже показано, как Fedor анализирует все горизонтальные и вертикальные зависимости проблемы. В этом примере приложение демонстрирует ненормальное поведение, в то время как базовый вертикальный стек работает нормально. Анализ отслеживает транзакции приложения, выявляя зависимость от службы (<code>Service 1</code>), которая также демонстрирует ненормальное поведение. В свою очередь, все зависимости службы также ведут себя ненормально и являются частью одной и той же проблемы.

	[[Файл:Анализ проблемы ИИ.png\|граница\|1045x1045пкс]]		[[Файл:Анализ проблемы ИИ.png\|граница\|1045x1045пкс]]

	ИИ включает все соответствующие отклонения и ранжирует все основные причины, определяя, какое из них является основным негативным воздействием. Вы можете перейти к уровню компонента и проанализировать основную причину вплоть до уровня исходного кода. Например, среда АппОптима может показывать ошибочные методы в коде вашего сервиса или высокую активность GC в базовых процессах Java.		Fedor включает все соответствующие отклонения и ранжирует все основные причины, определяя, какое из них является основным негативным воздействием. Вы можете перейти к уровню компонента и проанализировать основную причину вплоть до уровня исходного кода. Например, среда АппОптима может показывать ошибочные методы в коде вашего сервиса или высокую активность GC в базовых процессах Java.

	=== Почему важна контекстная корреляция ===		=== Почему важна контекстная корреляция ===
Строка 39:		Строка 39:
	Что, если события в последовательности развития проблемы будут более тонкими и открытыми для интерпретации? Что, если, например, у службы <code>Booking</code> уже давно есть проблемы с производительностью? Без полного контекста становится невозможным сделать окончательный вывод о том, что замедление работы <code>Booking</code> службы вызвано замедлением работы службой <code>Verfication</code>. Существует вероятность того, что у службы <code>Booking</code> возникла другая проблема с производительностью, не связанная с <code>Verfication</code>.		Что, если события в последовательности развития проблемы будут более тонкими и открытыми для интерпретации? Что, если, например, у службы <code>Booking</code> уже давно есть проблемы с производительностью? Без полного контекста становится невозможным сделать окончательный вывод о том, что замедление работы <code>Booking</code> службы вызвано замедлением работы службой <code>Verfication</code>. Существует вероятность того, что у службы <code>Booking</code> возникла другая проблема с производительностью, не связанная с <code>Verfication</code>.

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

	== Анализ дерева ошибок ==		== Анализ дерева ошибок ==
	Контекстная модель ИИ построена на основе известной информации о зависимостях из ЕдиныйАгент и облачной интеграции. ИИ использует эту информацию для быстрого анализа дерева ошибок, анализа миллионов зависимостей и определения наиболее вероятной основной причины проблемы.		Контекстная модель Fedor построена на основе известной информации о зависимостях из ЕдиныйАгент и облачной интеграции. Fedor использует эту информацию для быстрого анализа дерева ошибок, анализа миллионов зависимостей и определения наиболее вероятной основной причины проблемы.

	== Анализ последствий ==		== Анализ последствий ==
Строка 65:		Строка 65:

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

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

	* Каждое событие имеет свои собственные временные метки начала и окончания.		* Каждое событие имеет свои собственные временные метки начала и окончания.
Строка 79:		Строка 79:
	* '''Конец анализа триггерного события''' — это момент времени, когда собраны все необходимые образцы нарушений и обнаружена проблема.		* '''Конец анализа триггерного события''' — это момент времени, когда собраны все необходимые образцы нарушений и обнаружена проблема.
	* Поскольку каждое событие, связанное с проблемой, использует скользящее окно, каждая проблема имеет завершающий период, в течение которого закрытая проблема может быть открыта повторно. Это называется '''периодом повторного открытия''', и его максимальная продолжительность составляет 30 минут.		* Поскольку каждое событие, связанное с проблемой, использует скользящее окно, каждая проблема имеет завершающий период, в течение которого закрытая проблема может быть открыта повторно. Это называется '''периодом повторного открытия''', и его максимальная продолжительность составляет 30 минут.
	* Если проблема остается открытой более 90 минут, после 90-минутной точки в нее не добавляются новые события. Это не позволяет ИИ собирать несвязанную информацию о длительных инцидентах (например, синтетический тест постоянно терпит неудачу и проблемы остаются открытыми в течение нескольких недель).		* Если проблема остается открытой более 90 минут, после 90-минутной точки в нее не добавляются новые события. Это не позволяет Fedor собирать несвязанную информацию о длительных инцидентах (например, синтетический тест постоянно терпит неудачу и проблемы остаются открытыми в течение нескольких недель).

	==== Краткое описание временного цикла проблемы: ====		==== Краткое описание временного цикла проблемы: ====