Обеспечение бесперебойной работы

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

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

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

1. Отказ оборудования

Единственный способ сократить простой — дублирование узлов. Варианты по возрастанию стоимости:

  • Запас комплектующих — платы CTI, материнские платы, модули памяти, телефонные аппараты.
  • Отказоустойчивая станция — серверная материнская плата, несколько блоков питания.
  • Дублирующий сервер в запасе — точная копия основного с настроенными узлами. При критической проблеме выполняется полное холодное переключение с сохранением всех настроек, имени и IP-адреса в сети.
Аргумент за вынос базы на отдельный сервер Если база данных живёт на другой машине, переключение на резервный сервер телефонии становится на порядок проще: не нужно переносить настройки и восстанавливать резервные копии базы.

Дополнительно:

  • регулярное резервное копирование сценариев, баз данных и внешних информационных блоков, участвующих в работе;
  • источник бесперебойного питания — но помните, что для продолжения обработки вызовов питание нужно и всем узлам связи: свитчам, модемам, шлюзам, АТС;
  • альтернативная схема сценариев обработки вызовов на случай отсутствия операторов и связи с внешними узлами.
Важная оговорка Всё перечисленное решает только аппаратные проблемы. Против программных сбоев дублирование железа не помогает.

2. Проблемы связи

Доступ в интернет, связь с SIP-провайдером и потоки E1 полностью на системном администраторе. Здесь важно заранее ответить на вопрос: что вы будете делать, если провайдер затянет устранение неисправности?

Одни провайдеры реагируют мгновенно, и тогда проблема некритична. Другие по договору или по факту способны тянуть неделями. Оцените ситуацию и подготовьте план: альтернативный канал, второй провайдер, порядок эскалации.

Отдельно стоит предусмотреть резервные ветки в сценарии приёма звонков — чтобы вызовы корректно обрабатывались, когда рисковый канал недоступен.

3. Изменения в операционной системе

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

  • вредоносная модификация файлов комплекса, .NET Framework или самой ОС;
  • чрезмерная нагрузка на процессор, кэш диска, сетевые интерфейсы;
  • блокирующие действия брандмауэров и файрволов на этапе обмена данными.

Правила гигиены после настройки сервера:

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

4. Нехватка дискового пространства

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

Что делать заранее:

  • писать записи не на системный диск, а на дополнительные;
  • периодически отслеживать заполнение и заблаговременно чистить неактуальные данные;
  • включить встроенное автоматическое удаление записанных разговоров — оно настраивается в общих настройках, — и профилактическую очистку базы;
  • для долгого хранения выносить записи на внешние носители.
Ориентир для расчёта Один мегабайт вмещает 10 минут звукозаписи. От этой цифры считайте, на сколько хватит диска при вашем объёме разговоров.

5. Переполнение базы данных

Это самый коварный пункт списка, потому что деградация наступает постепенно и выглядит не как отказ, а как «что-то стало медленно».

В режиме call-центра базы наполняются большим объёмом статистики. Часть её нужна для встроенных и пользовательских отчётов, но при конкретной настройке комплекса значительная часть хранится напрасно. Это не только занимает место, но и мешает серверу базы данных быстро искать и размещать данные в оперативной памяти.

Как это приводит к обрывам Некоторые настройки — например поиск наименее занятого оператора — используют статистику в реальном времени, при маршрутизации. С разрастанием таблиц каждое переключение абонента на задачу занимает всё больше времени. Звонки начинают «застревать» на входе в задачу, и после пересечения допустимой границы ожидания начинаются массовые обрывы со стороны абонентов.

Меры:

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

6. Перегрузка одновременными задачами

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

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

Что помогает:

  • анализировать и распределять виды работ ещё при формировании проекта;
  • выносить часть данных на другие серверы и строить отчёты там;
  • использовать внешние базы и разделять работу тех, кто трудится в реальном времени, и тех, кто может подождать спада активности;
  • минимизировать время пребывания в модулях call-центра «Индикаторы», «Ресурсы» и «Статистика» — а при необходимости отключить там наполнение на основе статистических данных.
Связь двух последних пунктов Перегрузка редко возникает сама по себе — обычно она следствие разросшихся оперативных таблиц. Лечить симптом бесполезно: смотрите на ситуацию целиком и оптимизируйте работу базы данных комплексно.