Представьте ситуацию: у вас есть ИТ-продукт. Все данные о его работе уходят в логи (текстовый файл, куда автоматически записывается важная информация о работе системы или программы), которые вы анализируете. Но иногда что-то идет не так, и обнаружить эту проблему автоматически бывает сложно. И вот клиент сообщает о сбое. Вам нужно быстро решить эту проблему не только для этого клиента, но и для всех остальных, у кого был уже такой сбой, но они не писали вам об этом.
К тому же важно как можно быстрее закрыть инцидент. Здесь на помощь приходит инцидент-менеджмент — это определенный набор правил для команды, который помогает эффективно справиться с такими ситуациями и восстановить нормальную работу системы.
Обработка инцидентов в бизнесе: от клиента до аналитика
Обычно процесс обработки инцидентов в бизнесе начинается с жалобы клиента. Но если один пользователь столкнулся с проблемой, скорее всего, она затронула и других. Поэтому жалоба направляется аналитику. Это специалист, который углубляется в базу данных, анализирует информацию, создает запросы и пытается найти источник проблемы.
Аналитик полагается на свой опыт и интуицию, пытается понять, что могло пойти не так, и дает подсказки разработчикам для поиска проблемы. Если продукт работает уже долгое время, у разработчиков может быть слишком много кода и переменных, и без аналитика они не смогут понять, где искать корни проблемы.
Аналитик, применяя разные подходы и проверяя разные гипотезы, находит изменения в системе, определяет, какие метрики изменились, и передает свои выводы разработчикам. Это помогает им быстрее найти проблему в коде и исправить ее.
Но этот процесс занимает много времени и требует от аналитика большого профессионализма. Аналитик должен хорошо разбираться в продукте и быть готовым к тому, что проблема может возникнуть в любой момент, даже когда он в отпуске. И это может стать преградой.
Глубокий анализ данных при расследовании инцидентов
Анализ данных играет ключевую роль при расследовании любого инцидента. Особенно важно смотреть на ситуацию через призму категориальных и числовых переменных. И тут возникает вопрос: как можно заменить работу опытного аналитика или хотя бы быть менее зависимым от него?
Аналитики часто придумывают метрики и разрезы прямо на ходу. Например, они могут анализировать скорость ответа сервиса клиенту в миллисекундах (метрика) по странам (разрез). Или они могут проверить процент оплативших (метрика) по месяцу регистрации пользователя (разрез). Но таких метрик и разрезов может быть почти бесконечное количество.
Можно попробовать охватить максимальное количество разрезов и метрик с помощью дашбордов, созданных на основе анализа логов нашего продукта. Логи — это записи всех действий в продукте. Если мы проанализируем эти записи, увидим, что у некоторых полей много уникальных значений, а у некоторых — мало.
Например, когда вы открываете эту статью, у аналитиков появляется запись «Пользователь 007 из Грузии открыл статью в 10:45». Время, когда вы открыли статью — это метрика, потому что тысячи пользователей открывают статью в разное время. Страна, из которой вы открыли статью — категория, разрез, через который мы можем смотреть на данные. Например, на время открытия статьи или время прочтения статьи по странам. Стран всего около 200, не очень много уникальных значений. Так, мы можем быстро понять, например, что наш сайт недоступен в какой-то стране или найти другие технические проблемы.
Мы можем пометить каждое поле как «много уникальных значений» и создать на его основе метрики, или как «мало уникальных значений» и использовать его для создания разрезов, через которые мы будем смотреть на метрики.
В результате мы получим дашборды с основными метриками по всем ключевым разрезам данных. Это поможет быстрее обнаруживать проблемы и в некоторых случаях позволит обойтись без участия аналитика.
Эффективное расследование инцидентов: сокращаем время работы аналитиков
С помощью дашбордов, где собраны основные метрики по ключевым разрезам, мы можем улучшить процесс расследования инцидентов и сократить время, которое тратят на это аналитики.
Аналитики могут использовать эти дашборды для быстрой проверки своих идей и гипотез. Вместо того чтобы проверять каждую отдельную мысль, они смогут сразу увидеть общую картину и определить, в какую сторону двигаться дальше. Это может помочь им быстрее найти источник проблемы или даже сразу ее устранить.
К тому же, для простых случаев даже новички в аналитике смогут использовать эти дашборды. Они смогут увидеть, какие метрики изменились, и предложить возможные направления для дальнейшего исследования. Это снижает требования к уровню их квалификации и позволяет более опытным специалистам сосредоточиться на улучшении системы, а не на расследовании каждого инцидента.
Таким образом, мы ускоряем процесс расследования инцидентов, сокращаем время работы аналитиков и позволяем им сконцентрироваться на более значимых задачах.
Преимущества автоматизированного инцидент-менеджмента: техподдержка и продакт-менеджеры в роли детективов
Автоматизированный инцидент-менеджмент открывает множество возможностей. С помощью подробных дашбордов и их постоянной оптимизации мы можем охватить большинство основных случаев инцидентов. Это позволяет быстрее реагировать на проблемы и часто обходиться без участия аналитиков.
При получении жалобы от пользователя, продакт-менеджер, техподдержка или даже разработчики могут открыть эти дашборды, просмотреть все метрики в разных разрезах за последние дни и быстро понять, что произошло. Они могут определить, столкнулся ли только один клиент с проблемой или она затронула целую группу пользователей. Разработчик, заметив изменения в определенном разрезе, может сразу узнать, в какой части кода были внесены изменения, и быстро решить проблему.
Конечно, будут случаи, когда без помощи аналитика не обойтись. Но если такие инциденты станут исключением, а не правилом, аналитики смогут сосредоточиться на улучшении продукта, экспериментах и повышении уровня удовлетворенности клиентов. Вместо того, чтобы тратить часы на поиск причин ошибки, они смогут работать над тем, чтобы эти проблемы не возникали вовсе.
Оптимизация процесса расследования инцидентов: ключевые выводы
Давайте подведем итоги: если вы хотите ускорить процесс расследования инцидентов и сократить время, которое аналитики тратят на их решение, стоит рассмотреть подход, описанный в этой статье. Он поможет существенно уменьшить время расследования инцидентов и во многих случаях вовсе исключить из этого процесса аналитиков.
Этот подход особенно эффективен на стабильных частях продукта, где структура данных не меняется слишком часто. На динамических частях продукта, которые постоянно обновляются и меняют структуру данных, создание таких дашбордов может быть менее эффективно, так как при каждом изменении структуры данных придется пересоздавать дашборд.
Если этот подход вас заинтересовал, отправьте эту статью своему начальнику отдела аналитики. Если он готов выделить ресурсы и потратить время на реализацию такого подхода, ваши инциденты могут быть решены быстрее и эффективнее.
Важно понимать, что это не панацея. Будут случаи, когда без участия аналитика не обойтись. Но этот подход позволит аналитикам сконцентрироваться на улучшении продукта и проведении экспериментов, вместо того чтобы тратить часы на решение проблем.
