5. Работа с ошибками

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

# Для просмотра списка релизных версий, выполните команду
git tag

# Для отката на предыдущую ревизию, выполните команду
git co <код релиза>

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

5.1. Резервное копирование и восстановление системы после сбоя

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

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

2) Исходный код конфигурации и ядра системы Отдельных мероприятий этот пункт не требует, код конфигурации и ядра находятся под системой контроля версий git (также можно использовать и другие системы). В случае сбоя необходимо клонировать репозиторий и загрузить из него последний релиз master-ветки.

3) Медиа-данные - файлы, которые появляются в результате работы системы (загружаются пользователями, генерируемые или получаемые файлы писем электронной почты eml, файлы лога о активностях системы, которые требуется хранить). Рекомендуется воспользоваться утилитой rsync для инкрементного копирования файлов на удаленый сервер. В случае сбоя, используя эту же утилиту, необходимо переместить файлы обратно на сервер с восстановленным экземпляром

Более подробно это описано в разделе обслуживания системы

5.2. Ошибки в настройке бизнес-логики

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

5.3. Ошибки технические (код)

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

В записи лога команда поддержки сможет увидеть информацию о контексте этого события (url / данные POST и GET / IP адрес / email и ФИО оператора и прочее). Также доступна цепочка вызовов (Traceback), которая привела к этой ошибке с указанием файлов, функций и классов в них с номерами строк в них для каждого кадра stack-а вызовов

При необходимости, есть возможность запуска системы в отладочном режиме с получением более подробных данных и выполнением произвольных команд python online в любом кадре стека. Для этого, необходимо перейти в директорию с приложением, активировать виртуальное окружение и запустить сервер. Если запуск производится на удаленном сервере (не компьютере разработчика), то требуется использовать указание прослушивать запросы со всех адресов (а не только локального) «-h 0.0.0.0»

cd <project_dir>
source ~/.virtualenv/sphere/bin/activate
./manage.py runserver -h 0.0.0.0

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

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