Обеспечение бесперебойности работы — различия между версиями

Текущая версия на 11:16, 17 декабря 2014

Наверх

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

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

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

Общие проблемы оборудования (плат CTI или составляющих блоков серверной станции)

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

Стоит помнить, что перечисленные варианты - возможное решение лишь аппаратных проблем.

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

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

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

Проблемы связи сервера с провайдерами, с интернет и другими блоками комплекса (АТС, шлюзами, телефонными аппаратами, компьютерами)

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

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

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

Изменения в составе операционной системы (изменение перечня или активности прочего программного обеспечения)

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

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

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

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

Рекомендуется настраивать запись на дополнительные жесткие диски вместо стандартного системного диска с ОС. Периодически отслеживать изменения и заблаговременно менять или очищать диск от уже неактуальных данных. В систему встроен режим автоматического удаления записанных разговоров (в разделе общих настроек), а также профилактической очистки БД. При необходимости длительного хранения записей используйте внешние носители. Поскольку 1МБ вмещает 10 минут звукозаписи, то современные жесткие диски позволяют достаточно длительный срок вмещать информацию всего офиса. Периодическая смена жестких дисков или архивирование на внешний носитель позволит существенно раздвигать сроки нормальной эксплуатации в этой части.

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

В процессе работы (особенно в режиме call-центра) при плотной активной работе базы данных постепенно наполняются большим объемом разнородной статистической информации. Часть ее используется системой при построении стандартных встроенных отчетов, часть может быть использована при создании пользовательских отчетов. Однако в ряде случаев при конкретной настройке комплекса большой объем данных хранится напрасно. Это занимает место на диске, но еще больше мешает серверу баз данных осуществлять быстрый поиск и размещение в оперативной памяти. Разрастание данных в основных таблицах тем пагубнее, что при использовании определенных настроек (таких как, например, поиск наименее занятого оператора) комплекс в реальном времени использует статистическую информацию для маршрутизации. Так, при каждом переключении абонента на задачу неизбежно увеличивается время поиска по статистическим таблицам. Этот процесс плавно ведет к «застреванию» звонков на входе в задачу, и при пересечении допустимой границы ожидания массовым обрывам со стороны абонентов. Рекомендуется полностью формировать проекты перед тем, как осуществлять их настройку и активирование в системе. В ряде случаев информация, собираемая комплексом неинтересна, и можно продлить «легкую» работу, настроив автоматическую очистку таблиц. Также можно пользоваться встроенным режимом удаления данных старее указанной даты из всех оперативных таблиц и автоперестройкой индексов.

Чрезмерная перегрузка одной из составляющих систем выполняемыми одновременно задачами

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

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

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