среда, 28 января 2015 г.

Для клиента создали индивидуальные правила расчетов с водителями.

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

пятница, 28 ноября 2014 г.

Нехватка оперативной памяти тормозила работу системы

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

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

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

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

Следующий шаг – была проведена оптимизация сетевого стека операционной системы:
  • проведен мониторинг потоков, затрагивающих драйверы сетевого стека TCP/IP и Windows Socket;
  • произведена корректировка параметров протокола передачи данных по сети;
  • выполнены поиск и оптимизация тегов, которые занимали наибольший объем невыгружаемой оперативной памяти.
В итоге, быстродействие системы было полностью восстановлено. Как мы уже упоминали, основной причиной сбоев были ошибки, возникшие в результате аварийной остановки сервера. Впоследствии это вызывало переполнение памяти, что и привело к медленной работе программного комплекса.

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

*В целом работа комплекса Такси-Мастер включает в себя активное использование сети. Каждое новое подключение, инициированное системой, занимает сокет. Когда количество свободных сокетов заканчивается, операционная система, чтобы разгрузить канал, закрывает некоторые из них. В то же время закрытые сокеты «повисают» в оперативной памяти, а именно в невыгружаемом пуле памяти. В итоге количество невыгружаемой занятой памяти постоянно растет.


пятница, 31 октября 2014 г.

Служба такси получила возможность экономить на исходящих звонках.

Один из пользователей программы Такси-Мастер решил оптимизировать затраты на исходящие звонки. Так как в сутки через диспетчерскую проходили тысячи заявок, ежедневная сумма расходов на услуги связи оказывалась весьма значительной.
Именно поэтому служба такси обратилась в наш отдел технической поддержки с просьбой найти решение, которое позволит им экономить.
Проанализировав запрос, специалист службы технической поддержки Дмитрий Бушмелев пришел к выводу, что самым лучшим решением будет настроить маршрутизацию исходящих вызовов по типам операторов связи. К тому же у клиента был установлен GSM-шлюз на несколько сим-карт.
Для этого в настройках call-центра Oktell был изменен служебный сценарий, позволяющий выбирать оператора связи при звонке автоинформатора. К примеру, если пассажир вызывает такси с номера определенного оператора, автоинформатор осуществляет ответный звонок с сим-карты того же самого оператора связи.
Таким образом, при каждом звонке система автоматически стала выбирать нужную сим-карту, что дало возможность экономить на связи внутри сети. 

вторник, 30 сентября 2014 г.

Как сделать бэкап базы данных и зачем это нужно

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

Итак, создаем бэкапы.

Начиная с версии FB 2.5 в стандартной поставке появилась стабилизированная утилита nbackup. Название говорит само за себя - позволяет делать инкрементные бэкапы базы. В отличие от gbak работает не просто быстро, а очень быстро. Скорость ограничена лишь пропускной скоростью сети или носителя. Если gbakтребуется несколько минут для архивации базы в 2-3 ГБ, то nbackup справляется с задачей менее, чем за минуту. По сути, nbackup делает снимок базы, с учётом заданного уровня бэкапа (см. ниже).
1. Создание бэкапа
nbackup -B level /путь/к/базе/данных
level:
0 - полный бэкап
1 - суточный бэкап
2 - бэкап с последнего бэкапа с level=2
Что при этом происходит. Текуший файл БД блокируется и доступен только на чтение. Все изменения БД (ведь юзеров мы не выгнали!) записываютя во временный /путь/к/базе/данных.delta (добавляется расширение delta), а основной файл БД физически копируется в текущий каталог (путь к базе задаётся полный в параметрах nbackup, см. выше). После выполнения указанной команды необходимо разблокировать основной файл БД. Делается это командой
nbackup -N /путь/к/базе/данных
Утилита выполняется на сервере FB, т.к. ей требуется прямой доступ к файлу (к слову сказать, возможно размещение БД на raw-разделе HDD).
При этом произойдёт слияние /путь/к/базе/данных и /путь/к/базе/данных.delta в /путь/к/базе/данных и дальнейшая работа производится с основной БД.
(Полный перечень параметров nbackup можно узнать, выполнив nbackup -?.)

Рабочий bash-файл для Linux:

#!/bin/bash
ISC_USER='SYSDBA'
ISC_PASSWORD='masterkey'
# Параметры
DB_FILE="/var/lib/firebird/tme_db.fdb" # База данных
BLEVEL=-1
TLEVEL="Инкрементный бэкап "
case $((`date +%H`)) in
  0) # 00:00 Часов
    BLEVEL=2;;&
  4) # 04:00 Часов
    BLEVEL=1
    TLEVEL= "Суточный бэкап "
    # 04:00 - Полный суточный иэкап
    if [[ "`date +%w`" == "0" ]] ; then
      # Если это воскресеньне - полный бэкап
      BLEVEL=0
    fi
    ;;&
  8) # 08:00 Часов
    BLEVEL=2 ;;&
  12) # В Москве полдень!
    BLEVEL=2 ;;&
  16) # И т.д.
    BLEVEL=2 ;;&
  20)
    BLEVEL=2 ;;&
esac

if [[ `date +%d` == '01' ]] ; then
  # Если первое число месяца - полный бэкап
  TLEVEL="Полный бэкап"
  BLEVEL=0
fi

if [[ "$BLEVEL" != "-1" ]] ; then
  echo "`date +%c:` $TLEVEL" >> /var/log/tm_backup.log
  bmonth=`date +%m`
  bday=`date +%d`
  byear=`date +%Y`
  bpath="/mnt/tm_backups/$byear/$bmonth/$bday"
  mkdir -p $bpath # Создать путь YYYY/MM/DD
  cd "$bpath" # Переходим в папку, куда сложим бэкап

  # Выполняем бэкап согласно заданным параметрам
  time nbackup -B $BLEVEL $DB_FILE >> /var/log/tm_backup.log
  # Снимем блокировку с БД
  nbackup -N $DB_FILE # Не забыть разблокировать базу!
  # Здесь, при необходимости, можно утрамбовать полученный файл.nbk любимым архиватором...
  echo "`date +%c:` $TLEVEL выполнен..." >> /var/log/tm_backup.log
fi

Запуск осуществляется по cron каждые 4 часа.
2. Восстановление из бэкапа
nbackup -R <database> [<backup0> [<backup1> [...] ] ]
Первым параметром указывается файл создаваемой БД (<database>), далее перечисляются доступные бэкапы:
последний полный бэкап (backup0 level=0)
список суточных бэкапов (backup1 level=1. Их может быть несколько)
список бэкапов level=2
К счастью, командой восстановления за полтора года воспользоваться ни разу не пришлось :). Но PostgreSQL всё же лучше - бесплатненько, интерпрайзненько, нагрузочно. Да и бэкапы реализованы без блокировки БД.

Посмотреть текущее состояние блокировки (и не только) можно командой
gstat -h /путь/к/базе/данных
(Разумеется, прочие возможности gstat можно узнать командой gstat -?)
В строке Attributes будет указано текущее состояни БД. Если там пусто, то БД находится в обычном рабочем режиме. Если вы увидели там "backup lock" (возможны и другие значения) - значит, выполняется nbackup -B level..., либо не снята блокировка и все изменения пишутся в .delta файл.

Вот в целом и все! Попытался рассказать только самое важное.

Подробности: http://www.firebirdsql.org/manual/nbackup-backups.html




четверг, 14 августа 2014 г.

Прокси-сервер блокировал доступ к онлайн картам.

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

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

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


пятница, 25 июля 2014 г.

Наши специалисты успешно справились с DDoS-атакой на диспетчерскую.

В процессе работы специалистам БИТ «Мастер» приходиться решать весьма необычные задачи. А этот случай почти детективный.
У одного из пользователей Такси-Мастер была полностью парализована работа телефонии. На номер телефона диспетчерской одновременно поступало огромное количество звонков неизвестных абонентов. При этом операторы слышали лишь молчание в телефонной трубке. Из-за этого фактически никто из клиентов не мог дозвониться в службу такси.
Честно говоря, столкнулись мы с этим впервые, и версии были одна интереснее другой. Ясно было одно – кто-то очень нехорошо пошутил, и нужно было спасать диспетчерскую.
После анализа текущих возможностей телефонии было принято наиболее оптимальное решение – изменить некоторые сценарии настроек call-центра.
На время атаки в сценарий телефонии была добавлена проверка наличия номера телефона абонента в базе.
Иными словами, после каждого входящего звонка следовало обращение системы к базе данных Такси-Мастер. Если выяснялось, что номер принадлежал клиентам, сотрудникам и водителям службы такси, звонок доходил до диспетчера. 
Все другие номера просто-напросто блокировались. 
Конечно же, и у этой ситуации были свои минусы, однако диспетчерская смогла функционировать в обычном режиме и сохранить своих постоянных клиентов. А через несколько дней DDoS-атака прекратилась и работа call-центра вновь была переведена в штатный режим. 

пятница, 20 июня 2014 г.

Удар молнии вызвал нарушения в работе call-центра.

Этот курьезный случай произошел в городе Новомосковске. В результате удара молнии в офисное здание на одном из компьютеров в диспетчерской перестал работать интернет. Соответственно рабочее место оператора не могло подключиться к серверу Такси-Мастер.
Сразу же после обращения клиента в службу техподдержки начались поиски решения проблемы.
Первые предположения – вышла из строя сетевая карта ПК, либо был поврежден сетевой кабель. 
Чтобы определиться с версией наши сотрудники посоветовали подключить патч-корд к другому компьютеру. Выяснилось, что кабель был в исправном состоянии. В итоге машина была отправлена на диагностику, где выяснилось, что проблема действительно была в сетевой карте. А тем временем рабочее место оператора перенесли на сервер.
Правда, на этом трудности не закончились. Удар молнии и последовавший за ним сбой системы нарушили работу call-центра. Во время запуска программы не регистрировался GSM-шлюз. Так как все вызовы передаются на GSM-шлюз, диспетчерская не могла принимать и совершать звонки.
Проблему решили максимально оперативно. Шлюз был отключен от питания и подключен вновь. После перезапуска системы все линии заработали в штатном режиме. Заключительный этап – на пострадавший из-за грозы компьютер была установлена другая сетевая карта, после чего его вернули на свое законное место.

комментарии