Эксплуатация программного обеспечения Solomon

На этой странице

Документ описывает порядок эксплуатации медицинской информационной системы Solomon: резервное копирование и восстановление данных, обновление версии, контроль состояния системы и действия при нештатных ситуациях.

1. Резервное копирование

1.1 Состав копии

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

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

Отдельно от базы данных резервируются:

• ключ электронной подписи сеансовых токенов;
• файл параметров окружения, содержащий реквизиты доступа.

1.2 Периодичность и хранение

Копия создаётся ежедневно в часы, когда медицинская организация не работает. Срок хранения копий — 30 дней, задаётся параметром и может быть изменён.

Требования к хранению резервных копий приведены в документе «Установка и настройка».

1.3 Контроль создания копий

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

Указанные проверки подтверждают читаемость копии, но не её пригодность к восстановлению. Пригодность подтверждается только фактическим восстановлением.

2. Восстановление из резервной копии

Восстановление выполняется в следующем порядке:

1. Проверка копии до остановки системы. Копия разворачивается во временную базу данных, где сверяются состав схем и число таблиц. О непригодности копии необходимо узнать, пока система работает.
2. Остановка прикладных сервисов. База данных остаётся запущенной.
3. Переименование текущей базы данных. Действующая база сохраняется под именем с отметкой времени и не удаляется: данные, поступившие после снятия копии, содержатся только в ней.
4. Развёртывание копии в базу данных под рабочим именем.
5. Повторная выдача прав учётным записям сервисов. База данных создана заново, ранее выданные права в неё не переносятся.
6. Запуск сервисов и проверка доступности в порядке, приведённом в документе «Установка и настройка».

Сохранённая база данных удаляется вручную после подтверждения результата восстановления.

2.1 Проверка результата

Проверяется не факт завершения процедуры, а состояние данных: записи расписания, содержимое карточек пациентов и медицинских документов, счета и оплаты, остатки материалов, возможность входа в систему.

Проверка восстановления входит в приёмку системы и выполняется на испытательном стенде. Фиксируется время, затраченное на восстановление: оно определяет длительность перерыва в работе медицинской организации при нештатной ситуации.

3. Обновление версии

3.1 Порядок

Остановка сервисов, резервное копирование, применение миграций, выдача прав, запуск, проверка. Последовательность изменению не подлежит.

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

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

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

3.2 Проверка после обновления

Выполняются проверки состояния контейнеров и доступности сервисов, приведённые в документе «Установка и настройка», после чего проверяются журналы.

3.3 Контроль соответствия версии схемы базы данных

При запуске каждый сервис сравнивает номер применённой миграции с номером, ожидаемым его версией. При несовпадении в журнал записывается предупреждение alembic_revision_stale с указанием обоих номеров.

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

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

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

Предупреждение alembic_revision_check_failed означает, что проверка не выполнена — например, база данных была недоступна в момент запуска. Состояние схемы в этом случае остаётся непроверенным и требует такого же разбирательства.

3.4 Возврат к предыдущей версии

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

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

3.5 Предварительная проверка обновления

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

4. Контроль состояния системы

В ходе эксплуатации контролируются:

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

Журналы действий пользователей и история изменений медицинских документов не удаляются, объём базы данных возрастает непрерывно.

5. Действия при нештатных ситуациях

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

5.1 Сервис не запущен или недоступен

Признак: контейнер сервиса отсутствует в состоянии running либо обращение к служебному адресу сервиса не возвращает код 200.

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

5.2 База данных недоступна

Признак: прикладные сервисы не переходят в рабочее состояние; в журналах — ошибки подключения к базе данных либо предупреждение alembic_revision_check_failed.

Порядок действий: проверить состояние контейнера системы управления базами данных и его журнал. Прикладные сервисы запускаются только после готовности базы данных, поэтому до её восстановления повторный запуск сервисов результата не даёт.

5.3 Исчерпание дискового пространства

Признак: прекращение записи в базу данных, ошибки записи в журналах, отсутствие новых резервных копий.

Порядок действий: освободить место, удалив резервные копии с истёкшим сроком хранения, после чего проверить состояние базы данных и работоспособность системы.

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

5.4 Предупреждение о несоответствии версии схемы

Признак: предупреждение alembic_revision_stale в журнале сервиса. Порядок действий приведён в разделе 3.3.

6. Сопровождение

Плановые операции — резервное копирование, обновление, восстановление — выполняются персоналом медицинской организации в порядке, установленном настоящим документом.

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

Требования к персоналу, обеспечивающему эксплуатацию, приведены в документе «Требования к обслуживающему персоналу».

7. Сведения о документе

Программное обеспечение: Solomon, медицинская информационная система

Правообладатель: Общество с ограниченной ответственностью «Феникс Медика Групп», ОГРН 1092635012986, ИНН 2635129057, адрес: 355011, Ставропольский край, г. Ставрополь, ул. 50 лет ВЛКСМ, д. 91

Версия документа: 1.0