60
---
- hosts: all
become: yes
handlers:
- name: Restart postfix
service: name=postfix state=restarted
- name: Restart sshd
service: name=sshd state=restarted
- name: Copy rsync default config
copy: src=files/etc/rsyncd.conf.tmpl dest=/etc/rsyncd.conf.tmpl
owner=root mode=0644
- name: Bind rsync to management interface
shell: ip=$(ip a s | grep 'inet ' | grep '10\.' | awk '{print $2}' |
awk -F '/' '{print $1}') && cat /etc/rsyncd.conf.tmpl | sed 's/IPADDRESS/$ip/'
> /etc/rsyncd.conf
- name: Remove unneeded rsync template
shell: rm -f /etc/rsyncd.conf.tmpl
- name: Restart rsyncd service
service: name=rsyncd state=restarted
tasks:
- name: Update all packages with 'yum update'
yum: name=* state=latest
- name: Disable root login in sshd
lineinfile: dest=/etc/ssh/sshd_config insertafter='^#PermitRootLogin
yes' line='PermitRootLogin no'
- name: Disable DNS lookups in sshd
lineinfile:
state: "present"
dest: "/etc/ssh/sshd_config"
insertafter: '^#UseDNS yes'
line: 'UseDNS no'
notify: "Restart sshd"
- name: Bind listen dns to management interface
61
lineinfile: state=present dest=/etc/ssh/sshd_config
insertafter='^#ListenAddress 0.0.0.0' line='ListenAddress {{
ansible_ens19.ipv4.address }} '
- name: Enable iptables
service: name=iptables enabled=yes
- name: Fix aliases
lineinfile:
state: present
dest: /etc/aliases
line: 'root: noc@psk.noc'
- name: Regenerate aliases
shell: newaliases
- name: Fix postfix protocols
lineinfile:
state: "absent"
dest: "/etc/postfix/main.cf"
regexp: "^inet_protocols = all"
- name: Fix postfix protocols
lineinfile:
state: "present"
dest: "/etc/postfix/main.cf"
line: "inet_protocols = ipv4"
notify: Restart postfix
- name: Disable Zeroconf network
lineinfile:
state: "present"
dest: "/etc/sysconfig/network"
line: "NOZEROCONF=yes"
- name: Install rsync
yum: name=rsync
notify:
- Copy rsync default config
- Bind rsync to management interface
- Remove unneeded rsync template
- Restart rsyncd service
62
- name: Copy rsync default config
copy: src=files/etc/rsyncd.conf.tmpl dest=/etc/rsyncd.conf.tmpl
owner=root mode=0644
- name: Bind rsync to management interface
shell: ip=$(ip a s | grep inet | grep '10\.' | awk '{print $2}' | awk
-F '/' '{print $1}') && cat /etc/rsyncd.conf.tmpl | sed 's/IPADDRESS/$ip/' >
/etc/rsyncd.conf
- name: Restart rsyncd service
service: name=rsyncd state=restarted
- name: Install mariadb
yum: name=mariadb
- name: Install mariadb-server
yum: name=mariadb-server
- name: Configuring mysql
lineinfile: dest=/etc/my.cnf.d/server.cnf regexp="^\[server\]"
insertafter="\[server\]" line="bind-address=127.0.0.1"
Незначимые файлы для этого скрипта не приводятся для экономии места.
Скрипт запускается с рабочего места инженера командой:
ansible-playbook -l otrs-db.psk.noc otrs-db.yml –K
После чего ansible самостоятельно авторизуется на хосте otrs-db.psk.noc,
выполняет несколько повторных проверок на соответствие требуемой
конфигурации хоста, затем добавляети настраивает демон rsync для выгрузки
резервных копий, настраивает демон postfix для отправки почтовых уведомлений
группе инженеров, устанавливает и настраивается сервер баз данных MySQL.
Скрипт для установки OTRS выглядит аналогично, поэтому приводить его
листинг не вижу смысла. В нем устанавливается сервер apache2, интерпретатор
perl, модуль для apache mod_perl и около десятка perl модулей, требуемых для
корректной работы OTRS.
4. Пишется скрипт резервного копирования динамических данных на хосте.
На хосте с базой данных, это непосредственно содержимое самой базы
63
данных. Для хоста с OTRS системой это вся директория в которой работает
OTRS - /opt/otrs и настройки сервера apache в директории /etc/httpd
Скрипты на всех хостах должны размещаться в директории /noc/bin/,
резервные копии должны складываться в директорию /noc/backup.
Скрипт резервного копирования базы данных MySQL:
#!/bin/bash
BACKUPDIR="/noc/backup/mysql"
SQLPASS="NOT_SHOWN_HERE"
DATE=`date "+%Y-%m-%d"`
TIME=`date "+%H_%M"`
DEPTH=14
mysqldump="/usr/bin/mysqldump -eQ -p$SQLPASS"
if [ ! -d "$BACKUPDIR/$DATE/$TIME" ]; then
mkdir -p $BACKUPDIR/$DATE/$TIME
fi
log () {
logger --tag "backup.sh" $1
}
make_backup() {
dbhost="localhost"
base=$1
cd $BACKUPDIR/$DATE/$TIME
_ret=`$mysqldump --host=$dbhost $base > $base.dump`
if [ $? != 0 ]; then
log "backup $base FAIL"
else
log "backup $base ok"
fi
[ -e "$base.dump.bz2" ] && /bin/rm -f $base.dump.bz2
bzip2 $base.dump
}
make_rotate() {
64
cd $BACKUPDIR
totaldirs=`ls | wc -l`
if [ $totaldirs -gt $DEPTH ]; then
toremove=`echo $totaldirs-$DEPTH | bc`
removedirs=`ls | sort -r | tail -$toremove`
for folder in $removedirs; do
[ -n "$folder" ] && /bin/rm -rf $folder
log "Remove dir: $filder"
done
fi
}
sql="SHOW DATABASES"
dbs=`/usr/bin/mysql -p$SQLPASS -s -e "$sql"`
dbs_excl="test lost+found performance_schema information_schema"
for base in $dbs; do
if [[ " $dbs_excl " =~ " ${base} " ]]; then
log "SKIPPING: $base"
else
log "BACKING UP: $base"
make_backup $base
fi
done
make_rotate
В начале вычисляется текущие дата и время в удобном формате и в
директории бэкапов создается две директории по шаблону $DATE/$TIME (год-
месяц-день/часы_минуты), т. е. мы получим полный путь архивирования
/noc/bin/2018-10-12/20_22. Затем из mysql получается список всех баз данных за
исключением системных perfomance_schema и information_schema, после чего
делается их дамп. После архивирования свежего дампа, выполняется удаление
однозначно устаревших резервных копий. Количество оставляемых резервных
копий регулируется переменной DEPTH в самом начале скрипта, для нас 14
резервных копий вполне достаточно.
65
5. Настраивается системный планировщик задач cron из которого в
определенное время (например, в 2 часа ночи) вызываются скрипт
резервного копирования.
6. В 5 часов утра, когда все работы по архивированию на хостах уже точно
выполнены, на центральном хранилище запускается скрипт,
опрашивающий и выгружающий по rsync с каждого хоста свежие
резервные копии. Возможность выгрузки резервных копий с самих хостов
принудительно заблокирована в целях безопасности.
В соответствии с этим регламентом, восстановление виртуальной машины
будет выполняться по следующему сценарию:
1. Установка из шаблона чистой операционной системы и назначения ip
адресов
2. Запуск описанного ansible скрипта для установки необходимого списка ПО
3. скачивание с центрального хранилища свежей копии и разворачивание ее
на хосте.
Обычно вся процедура выполняется за 20-30 минут.
Следующий три уровня относятся и управляются непосредственно самой
системой OTRS.
Администратор OTRS.
Это человек, настраивающий логику работы самой системы OTRS через веб
интерфейс программы.
Агент OTRS
Любой из сотрудников технической поддержки или менеджеров компании.
Они имеют очень ограниченные возможности по настройке логики работы
системы, разве что указать время своего отсутствия в офисе или перемещения
заявки из одной очереди в другую.
Клиент
Это наши клиенты, права которых в системе минимальны: создать заявку,
прочитать историю своих заявок.
66
2.2 Информационное обеспечение задачи
2.2.1 Информационная модель и её описание
Информационная модель включает в себя несколько справочников:
Список клиентов.
В нем должны содержаться номера договора, имена, фамилии, контактные
данные типа телефона, адреса и т. д. Необходимы для однозначной
идентификации клиента.
Список сервисов или услуг
Услуги, которые предоставляет компания в принципе. Например,
телефония, широкополосной доступ в интернет, объединение офисов, хостинг и
т.д.
Список оборудования
Тут необходимо разделить оборудование на магистральное и оконечное - с
помощью которого предоставляется услуга, такое как коммутаторы, VoIP шлюзы
или домашние маршрутизаторы. Магистральные маршрутизаторы находятся под
постоянным пристальным вниманием инженеров и службы мониторинга,
оповещение о проблемах придет напрямую инженерам на телефоны и будут сразу
взяты в работу независимо от появления заявок клиентов.
Список агентов
Сотрудники компании, работающие с системой заявок
Список заявок. Собственно, сами заявки к которым будут привязываться
все остальные списки.
Статус заявок
Имеется ввиду статус в системе. Может быть «Новая», «Открыта»,
«Ожидает ответа клиента», «Закрыта» и т.д.
Список очередей обработки заявок. Зависит от группы или агента,
обрабатывающего заявку.
Все эти данные должны храниться в базе данных системы обработки заявок.
67
2.2.2 Характеристика нормативно-справочной, входной и
оперативной информации
В систему обработки заявок информация может поступать только двумя
способами:
Электронное письмо, в котором клиент сам описывает свою просьбу
В ручном режиме. Используется при приеме заявки по телефону. В этом
случае создается заявка и информация от клиента вписывается в нее
вручную.
Никакой из этих вариантов получения информации не может быть в
обязательном порядке снабжен необходимым набором полей. Фактически мы
можем только идентифицировать клиента либо через его адрес электронной
почты, либо спросив кто он в разговоре. Остальная необходимая для диалога
информация может быть получена из справочников по номеру договора клиента:
Список услуг, предоставляемых клиенту
Параметры этих услуг, такие как номера телефонов, ip адреса голосовых
шлюзов, ip адрес хостинга, привязанное доменное имя и т. д.
Оборудование, обеспечивающее предоставление услуги. Для различных
услуг разное — для предоставления услуг интернет — это будет
маршрутизатор и список коммутаторов, для хостинга — сервер и сетевое
оборудование в серверной и т. д.
Но все эти данные не хранятся в нашей системе обработки заявок. Для их
получения будет необходимо обратиться к биллингу.
68
2.2.3 Характеристика результатной информации
К результатной информации можно отнести как различные статистические
отчеты, так и результаты работы модулей.
В работе возникает ситуация, когда необходимо поднять историю переписки
за несколько лет. По этой причине все данные этих таблиц должны сохраняться
на протяжении всего времени существования информационной системы. Так же
эта информация необходима для формирования статистики.
Выходные данные:
1. Список необработанных заявок, индикатором которого является
идентификатор автоматически назначаемой очереди Raw.
Формируется из таблиц queue и ticket, включает в себя следующие поля:
queue_id — идентификатор очереди
tn — номер заявки
title — заголовок заявки
create_time — время создания заявки
В интерфейсе агента результат этого запроса отображается как показано на
рисунке 2-5
Рис 2-5. Список новых заявок в интерфейсе агента
2. Список заявок в каждой из очередей (очередей несколько, но запросы для
них идентичны, за исключением идентификатора очереди. Будет приведен
пример только для одной очереди). Формируется из таблиц queue и ticket,
включает в себя следующие поля:
queue_id — идентификатор очереди
tn — номер заявки
title — заголовок заявки
ticket_state_id — состояние заявки
user_id – идентификатор сотрудника компании
69
customer_user_id — идентификатор пользователя (сотрудник компании)
create_time — время создания заявки
ticket_lock_id — состояние блокировки заявки, предотвращающее
возможность начать над ней работу другому агенту.
На рисунке 2-6 показан пример этой выборки:
Рис 2-6. Выборка по очереди Raw
3. Общие статистические данные. Сколько сообщений находится в очередях
и их состояние
Используемые таблицы queue и ticket. Список полей:
queue — очереди и идентификаторы
ticket_state_id — состояние заявки
Пример работы этого запроса в интерфейсе OTRS:
Рис. 2-7. Выборка статистических данных по очередям
Как упоминалось ранее, основной задачей автоматизации обработки заявок
в ООО «ПСК» является повышение наглядности переписки с клиентом,
сортировки по отделам и слежение за «зависшими» письмами. Иными словами,
поднимается уровень эффективности работы с клиентами. Определенные
критерии оценки качества так же отсутствуют, необходимо было сделать лучше,
чем есть сейчас.