Ссылка на статью в формате PDF

Оглавление

1. Введение.
2. Создание МК. Пошаговая инструкция.
3. Тестовый запуск.
4. Боевой запуск. Проверки.
5. Операционный Мониторинг.
6. Устранение инцидентов.
7. Заключение.

Введение

При работе с маркетинговыми кампаниями (далее МК) цена ошибки очень высока, а допустить ошибку можно довольно легко, например, разослать некорректное предложение или ошибочно начислить баллы. Думаю, многие сталкивались с EMAIL\PUSH\SMS-сообщениями, где начислялось 0 баллов или просто писали test.  Подобные ошибки приводят к репутационным и финансовым потерям для компании.

Обычна ситуация, когда при внедрении SAP CRM функции мониторинга ограничивается записью логов в SLG1 и разными ad hoc решениями. Понимание, что этого недостаточно обычно приходит только после инцидентов. Работая в консалтинге я не обращал на это большого внимания, однако работа in-house надежность вышла на первое место по приоритетам (новые фичи идут следующим пунктом)

Данный материал может быть полезен читателям, работающим не только в SAP CRM Marketing, но в более новых продуктах, таких как SAP Marketing и в других маркетинговых продуктах. Написан он с минимумом специфической технической терминологии.

Отдельно хочется поблагодарить Дмитрия Новикова, чьим abap-мастерством удалось реализовать данную систему и Светлану Пасько за организацию работы, которая позволила выработать данное решение, а также Петра Цветникова и Анастасию Чищанову за использование и ценные замечания по усовершенствование архитектуры.

Описанная ниже многоуровневая система защиты от ошибок, мониторинга и устранения инцидентов позволяет себя довольно спокойно чувствовать, запуская довольно сложные МК.

В результате анализа опыта по настройке сложной механики МК, а также передаче функционала в эксплуатацию бизнесу пришли к следующей схеме работы с МК (Рис.1):

1. Создание МК. Пошаговая инструкция

Т.к. при создании маркетинговой кампании велик риск человеческой ошибки, то при создании МК сделали максимальное кол-во проверок для уменьшения вероятности ошибки по невнимательности.

Создание формуляра сообщения.

При создании формуляра указывается, для какого типа клиентов данный формуляр актуален, например, только для VIP-клиентов. Указывается, для какого типа сообщений используется данный формуляр SMS\PUSH\EMAIL, также есть возможность указания, что формуляр закрыт для использования.

При указании на элементе формуляра проверяется, что тип клиентов на формуляре соответствует типу на МК, что провайдер для отправки сообщений на элементе МК соответствует указанному на формуляре (SMS\PUSH\EMAIL) и формуляр не закрыт.

Указание максимального кол-ва клиентов.

На элементе обязательно указывается максимальное кол-во клиентов, планируемое для запуска.

Указание задания по сегментации данной МК.

Если МК планируется как периодическая, то нужно указать задание, которое отвечает за генерацию целевых групп. Подробности см. в разделе 4.Мониториг.

Указание типа клиентов, которые участвуют в данной МК.

На МК обязательно указывается для какого типа клиентов работает данная МК. Например, только для VIP-клиентов. Данный тип должен соответствовать типу на шаблоне и типу клиентов в целевой группе ( далее ЦГ).

Проверка на дубли.

Если есть понимание, что клиент не может попасть в МК несколько дней подряд. Например, у клиента не может быть 2 дня рождения подряд. То можно указать здесь проверку на дубли.

Проверка на дату запуска

Если дата и время запуска меньше текущей, то при попытке сохранения элемента система выдаст ошибку.

В интерфейс кампании добавили кнопку “Проверить”, пользователь перед запуском кампании нажимает её и сразу получает результат по проверкам, которые можно получить без запуска МК. Например, если превышено кол-во клиентов в ЦГ или не отработало указанное задание по сегментации, то ошибка отобразится сразу (Рис.2), что даст возможность пользователю исправить параметры МК. Дополнительно данная кнопка также запускает ренамберинг моделей сегментации, указанных в МК.

Например:

 

2. Тестовый запуск

Обычно этап проверки заключается в том, что:

1. На тестовом ландшафте создаются клиенты, на которых должна отработать механика (так же со случаями, когда не должна).
2. Если на тестовом ландшафте есть клиентская база, то кампания запускается и по ней.
3. Производится запуск на продуктивном ландшафте на контрольной ЦГ.

При этом возникают следующие проблемы:

1. На составление возможных успешных и неуспешных сценариев уходит много времени, причем это не гарантирует, что будут покрыты все возможные сценарии. При этом обычно МК нужно запускать как можно быстрее т.к. они уже в планах бизнеса, то времени на полноценное тестирование недостаточно.
2. Не все возможные сценарии можно проверить, возможно, в данную выборку не попадут клиенты с данными, на которых сценарий сломается. К тому же практически нигде не бывает актуальных клиентских данных на тестовом ландшафте.
3. При запуске на продуктивном ландшафте на контрольной ЦГ возникают аналогичные проблемы рассмотренные выше.
4. Сложно заранее протестировать событийные кампании, которые отрабатывают в режиме онлайн.

Поэтому было принято следующее решение:

1. На продуктивной системе создать копии продуктивных таблиц (либо в продуктивные таблицы добавить флаг тест и записи с данным флагом обрабатывать особым образом) для генерации баллов, отправки сообщений;
2. При запуске кампаний в тестовом режиме записывать реальные данные в эти таблицы по всем клиентам;
3. После запуска собирать по ним статистику, анализировать и если все ок, то уже запускать кампанию в боевом режиме (также есть возможность переноса данных из тестовых таблиц в продуктивные).

Получился отдельный тестовый контур внутри продуктива, идеологически наверно не совсем корректный, однако практичный и надежный.

Данная архитектура хорошо помогает также в тестировании событийных кампаний, когда можно запустить кампанию по определенной ЦГ и в онлайн-режиме проверять корректность начисления тестовых данных в течении необходимого времени.

Также при тестовом запуске запускаются все проверки, как и при боевом запуске, поэтому все ошибки по сообщениям\начислению и т.д. будут сразу доступны для анализа на данном этапе.

3. Боевой запуск. Проверки.

Проверка на максимальное кол-во клиентов на элементе.

Может возникнуть ситуация, когда произошел сбой в генерации модели или при создании модели была допущена логическая ошибка, которую не обнаружили на этапе тестирования или просто указали не ту ЦГ.

При планировании и запуске кампании пользователи всегда имеют представление о примерном кол-ве клиентов, которые попадут в данную кампанию, поэтому они могут указать на элементе верхний предел, превышение которого свидетельствует об ошибке.

Данный параметр обязателен и пользователь не сможет сохранить элемент МК, если не укажет его. Проверка осуществляется в момент запуска элемента, рассчитывается общее кол-во клиентов по всем ЦГ в элементе МК, и при превышении производится запись в таблицу ошибок об отмене запуска элемента МК.

Проверка на корректную генерацию модели сегментации.

Для периодических кампаний, по которым модель генерится ежедневно, может возникнуть ошибка, когда JOB, отвечающий за данную модель не отработает к моменту запуска МК. В этом случае МК отработает по устаревшим клиентам

На МК указывается название JOB, который генерит соответствующую модель. В момент запуска МК проверяется, что последний за сегодня JOB с таким названием отработал успешно. В противном случае, производится запись в таблицу ошибок об отмене запуска элемента МК.

Проверка на 3-сигма.

Т.к. в проверке на максимальное кол-во клиентов пользователь вводит значение вручную, то есть вероятность ошибиться. Данная проверка идет как дополнительная проверка к максимальному кол-ву.

Проверка работает автоматически и не требует от пользователя каких-либо действий, работает только для периодических МК.

При запуске элемента МК проверяются последние N запусков и смотрится на кол-во клиентов, после чего рассчитываются показатели для формулы по 3-сигмы (т.е. вероятность того, что любая случайная величина отклонится от своего среднего значения больше чем на 3-сигмы очень мала).

В случае, если кол-во клиентов на элементе больше чем предполагаемое в 3-сигмах, то производится запись в таблицу ошибок об отмене запуска элемента МК.

Данная проверка некорректно работает на маленьких кол-вах клиентов, например, если у вас в среднем попадает 10 клиентов, а в один день попало 20, то это обычно означает ложное срабатывание. Поэтому используется специальный параметр в TVARV, который указывает, при каком кол-ве клиентов в ЦГ необходимо осуществлять данную проверку. В нашем случае эмпирическим путем было найдено кол-во порядка 10.000.

Проверка на корректный тип клиента.

Пользователь при запуске кампании указывает тип клиента, например, данная МК только для VIP-клиентов.

При запуске МК для каждого клиента проверяется, соответствует ли он указанному типу на МК. Если на клиенте указан ошибочный тип, то по данному клиенту МК не выполняется и производится запись в таблицу ошибок.

Проверка на наличие пустых атрибутов в формулярах сообщений.

При формировании сообщения email\sms\push проверяется, что атрибут не равен пусто или 0. Например, невозможна отправка сообщения, что клиенту начислено 0 бонусов.

Если какая-то проверка на атрибут не прошла, то данное сообщение помечается как ошибочное и не отправляется клиенту. Данная ошибка отображается в часовом мониторинге.

Запрет множественного запуска

При работе столкнулись с проблемой, что если указать время запуска в прошлом и запустить МК, то она будет отрабатывать каждые n минут (зависит от настройки соответствующего JOB), поэтому при запуске МК проверяем, что если период кампании день, то за сегодня не должно быть запуска МК.  В противном случае, производится запись в таблицу ошибок об отмене запуска МК.

Проверка на максимальное кол-во начисляемых бонусов

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

4. Операционный Мониторинг

Каждый час команде поддержки SAP приходит email с отчетом о состоянии системы, возникших ошибках, запусках МК и т.д. Ниже приведено общее описание такого отчета.

Проверки на ошибки ZERR_LOG

Все ошибки по запуску МК или работе программа записываются в таблицу ZERR_LOG. Формат этой таблицы:

• Код
• Подкод
• Описание
• Таймстемп

Например: Код 121 Подкод 2 Для клиента %номер клиента% в МК %ид. кампании% пустой атрибут.

В мониторинге выводятся все новые ошибки за последний час.

Функциональные проверки

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

Например, у клиента не может быть двух промокодов с одним типом или в настройках TVARV некорректно заполнен один из параметров настройки, или у клиента нет приветственного бонуса и т.д.

Проверка на дампы (ST22)

Проверяется наличие новых дампов в системе, если есть, то в отчете приходит сообщение со списком дампов.

Проверка на отмененные задания (SM37)

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

Проверка на размер очередей (SMQ1\2)

Каждые 5 минут работает программа, которая записывает в отдельную таблицу текущее кол-во очередей.

При запуске мониторинга проверяется было ли превышение на кол-во очередей в течении часа, если было то в отчете это отображается как ошибка и дальше анализируется что привело к такой ситуации.

Проверка интеграции

Сделана отдельная настройка, в которой указаны таблицы и время мониторинга по каждой из них в минутах. Например, but000 – 10 минут, это значит. что в момент запуска мониторинга в данной таблице должна быть хоть одна новая или обновленная запись за последние 10 минут. Если новых или обновленных данных нет, это в отчете отображается как ошибка в интеграции.

Проверка на дубли в МК

В силу ряда технических особенностей не получается проверять на дублирование клиентов по МК в момент запуска. Поэтому была сделана программа, которая проходит по всем МК, на которых указаны проверки на дублирование и проверяет, не участвовали ли уже данные клиенты в этой МК вчера. Если такие клиенты найдены, то происходит запись в таблицу ошибок и техподдержка получает список этих клиентов в мониторинге.

 

Проверка на запущенные МК

Отображается список МК запущенных за последний час.

Проверка на наличие в МК не деблокированных элементов

 Обычно МК выглядит следующим образом (Рис.3):

 

Чтобы МК корректно отработала, МК и все элементы должны быть в статусе деблокировано. Если элементов много, то пользователь может ошибиться и забыть деблокировать один из элементов МК, обычно это происходит при добавлении нового элемента в уже деблокированную МК. В этом случае данный элемент не отработает, а также не отработают, элементы, следующие за ним.

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

5. Устранение инцидентов

Для устранения инцидентов были написаны отдельные программы для отмены начисления баллов, ручного начисления баллов,  удаления ошибочных сообщений и прочих технических задач.

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

6. Дальнейшее развитие

В настоящий момент данная система позволяет защищаться от грубых ошибок при запуске и работе, однако не всегда хватает более тонкого контроля на уровне исполнения.

Для планирую ввести на каждую МК ряд дополнительных параметров для контроля и проверок такие как:

• Минимальное и максимальное кол-во, отправляемых сообщений;
• Минимальное и максимальное кол-во, начисляемых бонусов;
• Проверка на максимальную сумма бонуса по МК

Скорее всего для этого необходимо делать отдельную настроечную таблицу.

Довольно большое кол-во ложных срабатываний, поэтому нужно разделить сообщения на ошибочные, по которым нужна быстрая реакция и предупреждения.

Заключение

Мониторинг\предотвращение ошибок это постоянно расширяющаяся система, с внедрением нового функционала список проверок и возможных защитных механизмов постоянно увеличивается.

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