> For the complete documentation index, see [llms.txt](https://docs.itgrix.ru/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.itgrix.ru/blog/itgrix-db.md).

# БД Itgrix

Пользуясь опытом работы с крупными клиентами, у которых каждый звонок на счету, мы пересмотрели способ хранения данных в Itgrix для приближения к 100% успеху своевременной обработки всех звонков.

Начиная с версии Itgrix bx [3.13.0](https://docs.itgrix.ru/blog/pages/-M0SZwZn5pERjpAzqeP-#id-3.13.0), файл состояния `state.json` заменён на собственную SQLite базу данных приложения `state.db`.

<figure><img src="/files/hkFm2fgSKwIrLF2xnMUb" alt=""><figcaption><p>Страница интерфейса настрой "БД Itgrix"</p></figcaption></figure>

Это предоставляет целый ряд преимуществ:

* Все данные приложения сохраняются в реальном времени без задержки, что устраняет возможность потери данных даже при неожиданной остановке приложения
* Хранение результата выполнения каждого шага обработки звонка предотвращает дублирование данных в CRM даже если звонок обрабатывается повторно
* Звонки, при обработке которых возникли ошибки, автоматически переобрабатываются по расписанию
* Переобработка звонков по расписанию и до-обработка звонков при восстановлении работы приложения выполняются в отдельном потоке с меньшим приоритетом для обеспечения обработки текущих звонков без задержек
* Регулярное резервное копирование базы данных ежедневно создаёт точки восстановления, которыми можно воспользоваться даже при повреждении актуальной базы данных
* Централизованное хранение актуальных данных звонков позволило уменьшить объём логирования по умолчанию
* Интерфейсы для работы с базой данных (в админке и в командной строке) позволяют специалистам техподдержки легко находить любые проблемные звонки и точечно применять специфические решения для каждой ситуации
* Данные об успешной обработке звонков позволяют быстро найти какие действия были выполнены с CRM на конкретном звонке или выяснить статистику по сценариям звонков

Про некоторые из этих изменений мы бы хотели рассказать подробнее.

## Результаты обработки каждого звонка

Критически важное отличие от предыдущего способа работы с данными звонков состоит в том, что завершение обработки звонка более не приводит к удалению данных о звонке:

* если звонок обработан успешно, то он удаляется только через 7 дней;
* звонки с ошибками хранятся до 30 дней.

Вместе с содержанием звонка (номера, разговоры, время ответа и т.д.) теперь также сохраняется результат выполнения каждого шага обработки звонка, в том числе данные всех созданных и изменённых объектов в CRM или причины не выполнения шага обработки (например, если номер в чёрном списке).

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

## Переобработка звонков по расписанию

Хранение звонков с ошибками в течение 30 дней даёт время на коррекцию ошибок при помощи автоматической переобработки, а данные об уже выполненных действиях предотвращают дублирование при переобработке.

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

Этот механизм позволяет достичь успеха обработки звонков даже при продолжительных сетевых сбоях и других временных проблемах.

## Настраиваемый объём логирования

Ранее логирование данных звонков было организовано путём вывода всех данных звонка на каждом событии звонка. Это позволяло всегда знать самое последнее состояние звонка, независимо от того, в какой момент могла прерваться работа приложения. Но, в зависимости от настроек Asterisk, могут существовать звонки с сотнями событий, и с каждым событием объём данных звонка увеличивается. Иногда это приводило к росту объёма логов до нескольких гигабайт и даже к риску переполнения диска.

Новый способ хранения данных в `state.db` перезаписывает данные звонка на актуальные, вместо добавления данных, поэтому найти самое актуальное состояние звонка можно даже если данные звонка совсем не выводились в лог, и объём данных растёт гораздно медленнее.

Теперь доступно три варианта вывода данных звонка в лог:

* никогда,
* только в конце звонка (по умолчанию),
* на каждом событии (как ранее).

Настройка доступна в админке на странице настроек модуля.

<figure><img src="/files/bTz2cnQUbCT8KpGE7Oxr" alt=""><figcaption><p>Блок настроек частоты логирования данных звонка</p></figcaption></figure>

{% hint style="success" %}
Мы стремимся достичь 100% успешной обработки звонков с минимальными задержками. Новый способ хранения данных значительно приближает нас к этой цели, повышая надёжность работы приложения и скорость обработки звонков.

Будем рады вашим отзывам и предложениям по улучшению работы приложения!
{% endhint %}