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

Если вкратце: в одном из немаленьких банков из-за проблем с операционной и аналитической базами данных падает  Data Mart (компонент системы записи Nice Engage от западного вендора Nice Systems). В результате 250 супервайзеров по 15 минут каждый час остаются слепы и глухи: система  не дает прослушать и оценить разговоры операторов с клиентами, соответственно, супервайзеры не могут отследить, соблюдаются ли скрипты, есть ли негатив или какая-то критическая ситуация, которая грозит потерей клиента. Если раньше система отрабатывала почти мгновенно, то теперь виснет при каждой операции. Инженеры внутренней техподдержки (то есть заказчика) ни в первом, ни во втором, ни в третьем приближении никаких багов не находят. Отрицание, гнев, торг, депрессия…, звонок сервисному партнеру.  Четыре ночи танцев с бубном и баг находится в самом неожиданном месте. А теперь давайте обо всем по порядку.

Понедельник. Московское время — 8:50 утра. Толком не проснувшийся супервайзер садится за свое рабочее место в офисе крупного банка. Супервайзер следит за взаимодействиями операторов контакт-центра с абонентами, выявляет критические ситуации и риски, дает операторам обратную связь, при необходимости корректирует скрипты – в общем, старается, чтобы клиенты были довольны. 

В 8:55 супервайзер, назовем его Вася, наливает кофейку на кухне, заходит в свою учетку на компе и привычно открывает ноут, чтобы посмотреть как работают операторы. Но ничего не открывается. Интерфейс с воспроизведением записей и оценкой операторов не работает. На экране крутится клепсидра – система долго и усиленно думает, но ничего не происходит. К слову, о масштабах проблемы: супервайзеров в компании примерно 250 человек. И для всех утро началось не очень.

В 9:00 Вася звонит коллегам в техподдержку первой линии. Его просят написать заявку. В 9:05 он ее пишет. Точнее, все 250 человек звонят в поддержку и пишут заявки просто потому, что без работающей системы они тупо не могут исполнять свои обязанности.

В этой компании специалисты технической поддержки первой линии обычно решают самые простые, я бы даже сказал бытовые, запросы. Например, проблемы с удаленным подключением и минимальной настройкой АРМ. Поскольку наша задачка явно посложнее, инженеры первой линии собираются уже «перебрасывать мячик» дальше – на вторую линию, которая тоже на стороне банка. Но тут случается чудо!

В 9:15 система заработала. Все супервайзеры подключились, стали смотреть записи и все, что успели пропустить за последние 15 минут. Ффух! Можно выдохнуть. Все хорошо, что хорошо кончается. Заявки на первую линию закрываются с пятью звездочками. Ура! Конец.

Хотя нет, не конец. В 10:00 проблема повторяется. Опять все то же самое: система лежит, супервайзеры начинают конкретно так терять терпение, пишут еще раз в техподдержку. Те уже точно собираются отдавать заявку на вторую линию, но через 15 минут все опять заработало.

В 11:00 опытным путем выясняется, что теперь система работает по-новому, ею учрежденному графику, т.е. устраивает себе сиесту первые 15 минут каждого часа. Вторая линия вступает в дело. Там есть крутой спец по этой системе, он смотрит, что да как, но не находит ровным счетом никаких проблем. Смотрит второй раз и третий. Все по-прежнему прекрасно по логам, но система по-прежнему падает на четверть часа с завидной регулярностью. Через сутки танцев с бубнами инженер второй линии отправляет заявку сервисному партнеру – сторонней компании, с которой есть контракт на оказание услуг технической поддержки. Решение, в какой момент обратиться к сервисному партнеру в каждой ситуации решается  индивидуально, поскольку контракт завязан на часы работы инженеров партнера. В данном кейсе у заказчика были довольно прокаченные инженеры, которые хорошо разбирались в своей инфраструктуре и многие инциденты решали самостоятельно. Но здесь это сыграло злую шутку, потому что проблема оказалась не в инфраструктуре, а непосредственно в БД. И время было потеряно напрасно. Но лучше поздно, чем никогда. 

Вторник 9:00. Первая линия сервисного партнера получает заявку от заказчика, оценивает ее и передает на свою вторую линию – инженеру, который со стороны сервисного партнера специализируется как раз по базам данных, и вообще, собаку на них съел, и даже не одну. 

А в это время у заказчика уже весело. 250 супервайзеров опять пишут в свою техническую поддержку первой линии, первая линия пишет второй, а вторая говорит, мол, только отправили сервисному партнеру, ждите. Дальше обратно по цепочке предложение «обождать» возвращается к супервайзерам. Те на радостях эскалируют проблему своему начальству. Начальство идет выше, добирается до ИТ-директора, а ИТ-директор призывает к ответу своих подчиненных – инженеров первой и второй линии, на что специалист второй линии опять просит всех подождать. Самое время добавить сюда фото ждуна. 

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

Вторник, ночь первая. Даня идет от простого к сложному. Сначала гигиенические процедуры: очистка кэша и перезапуск сервисов на сервере приложений, просто чтобы их исключить как потенциальный источник проблемы. Опять-таки днем этого делать нельзя, поэтому все происходит ночью.  Утром просим заказчика проверить систему под нагрузкой  – проблема сохраняется. Среда, ночь вторая. Очистка кэша и рестарт сервисов, связанных с Data Mart. Проблема все та же.

Днем Даня смотрит журналы и выполняемые задачи, в том числе журналы сервера приложений и сервера баз данных. На последнем – куча БД: есть база данных администратора, база данных взаимодействий, база данных QM, база данных ИБ и еще несколько БД, связанных с интеграцией внешних взаимодействий. В основном Даня смотрит на базы данных взаимодействий и оценок. Кажется, что все нормально. Не видно проблем ни с хранимыми процедурами, ни с самими задачами. То есть они выполняются достаточно быстро, с нормальной архивацией и оптимизацией. Соответственно, все задачи, которые выполнялись в привязке к базе данных взаимодействия, были ОК.

Четверг, ночь третья. Не зная уже на что грешить, Даня выполняет пересборку (ребилд) всех индексов всех таблиц в привязке к базе данных взаимодействия, причем вручную. Можно было, конечно, написать скрипт, но Даня побоялся, что если запустить скрипт, то база упадет, потому что этот процесс занимает много времени и потребляет порядочное количество ресурсов сервера базы данных. Пришлось вручную прокликать больше сотни таблиц, в каждой выбрать нужные параметры и запустить пересборку – на все про все ушло 6-8 часов в третью ночь. Утром звонок заказчику. У заказчика проблема сохраняется. На той стороне руководство уже рвет и мечет, а у Дани практически не осталось идей, что еще могло пойти не так….

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

В какой-то момент глаз цепляется за странную задачу в базе оценок. Пару часов подряд одна и та же задача очень долго выполняется и потом заканчивается сбоем. Комплексная экспертиза по базам данным, то есть нехилый опыт вкупе с недавно пройденным обучением затем и нужен, чтобы у эксперта в нужный момент возникло непонятное и невыразимое словами ощущение дискомфорта, или попросту что-то екало. У Дани-таки екнуло и полез он в эту странную задачу разбираться, что да как. Затем нашел хранимую процедуру, связанную с задачей, и начал ее анализировать. В задаче нашел SSIS пакеты и стал смотреть их код и код хранимых процедур, которые связаны с этими пакетами.

Выяснилось, что в коде задачи, на минутку, вендорском коде (!), этот самый вендор прописал, чтобы каждый час выбирались последние 100 млрд строк из основной базы и копировались в архивную.  

А перед копированием в архивную все 100 млрд сначала попадали в оперативную память, то есть фактически все исторические данные, которые были в БД, каждый час попадали в ОЗУ. Когда объем обрабатываемых данных превысил определенный порог, возникли проблемы с производительностью: оперативная память (RAM) стала переполняться, а файл журнала транзакций (transaction log) превысил отведенный ему лимит на диске. Переполнение ОЗУ вызвало сбой в системе, и в начале каждого часа, когда система в очередной раз пыталась отправить данные в архивную БД, проблема повторялась. 

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

Заключение

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