Ещё одним распространённым "камнем преткновения", который "лежит на поверхности", является резервное копирование, но не само по себе, а именно в формулировке Приложения 11 GMP:
Тот факт, что резервные копии делать нужно - вопросов не вызывает. Иначе есть риск в один не очень прекрасный момент просто встать "в ноль". А вот второй вопрос, что нужно проверить работоспособность резервных копий в ходе валидации...
Ну, скажем так, для клиент-серверных решений типа 1С (ERP, EDMS, LIMS - нужно подчеркнуть) это не вызывает столь острой проблемы. В конечном счете сварганив (зачастую встроенными средствами) резервную копию её можно развернуть в специальный тестовый VLAN (виртуальный сегмент локальной сети предприятия, специально выделенный для таких нужд) - там вполне себе можно проверить работоспособность таких комп. систем, проведя хоть 100% тестирование основного функционала (ну, разумно, конечно, выборочно).
А вот как быть с комп. системами, управляющими работой парового стерилизатора, например. Предположим, что архитектура стандартная - на базе контроллеров тех же Siemens (S7 200/300/400). Если сбросить через TIA Portal/Step 7/WinCC резервные копии (и такая возможность заложена изначально - тогда с контроллеров/панелей эти копии можно скинуть) - то первая часть будет реализована. Но возникает следующий вопрос: как проверить работоспособность этих резервных копий?
Технически залить бекап обратно на оборудование проблем нет. Проблема в другом, что если что-то пойдёт при этом не так, а, к примеру, к моменту такового тестирования паровой стерилизатор уже отработал несколько лет, содержит не один рецепт и далеко не один прошедший цикл в памяти, то валидатора начальник цеха "порежет на ленточки для бескозырок" 🙂 И будет по большому счёту прав. Ибо умозрительный риск покоцать ранее безупречно работающее оборудование гораздо менее приемлем, чем если в будущем программа "слетит" и будет использован "последний шанс" в виде попытки залить резервную копию, но уже в рамках аварийного восстановления.
Ведь аналога тестовой среды для технологического оборудования я в своей практике не встречал. Во всяком случае, в странах бывшего СССР. Может у кого есть прецеденты таких решений из "солнечной" Норвегии или Ирландии? Как за рубежом именно для технологического оборудования этот пункт реализуют? Ведь никто же не будет создавать "эмулятор стерилизатора"? Для систем SCADA, работающих под Windows аналогичный вопрос. Конечно, не проблема ACronis'ом создать целиком образ, но проверить его работоспособность где? Можно, конечно, на тестовой машине, развернуть удастся без проблем - как убедиться, что резервная копия сможет управлять системой вентиляции или системой водоподготовки без, собственно, подключения, к соответствующей системе вентиляции или системе водоподготовки?
Из моей практике в подобных случаях достаточным было убедиться в наличии резервной копии (и возможности снять новую/залить назад существующую), а тестовое восстановление в соответствующих СОП регламентировалось только аварийное. У кого какой опыт на этот счет? Какие будут мысли?
Если я верно понял суть проблемы, то ответом может быть "никак" для не нового оборудования, и часть FAT для нового, чтобы вендор мог все вернуть и научить ваших сотрудников как делать процедуру бекапирования и восстановления.
Для старого оборудования почему никак, да потому что если у вас есть задокументированная полная конфигурация всех режимов стерилизации, то инженер сможет все настроить где-то за полчаса-час. Если поменяли контролёр или пришлось сбросить все до заводских настроек, то собственно это займёт меньше времени и сил нежели думать как сделать бекап из того, где он попросту не предусмотрен.
Заметьте, речь о данных стерилизации не идёт. Это другой случай.
Вопрос вызывает понятие "данные". Требует уточнения вопрос о каких данных в данном документе идет речь. Вики трактует:
Понятие "данные" вопросов не вызывает - и Вики-трактовки тут избыточны - есть отраслевое определение MHRA "GxP" Data Integrity Guidance and Definitions:
Вызывает вопрос только их GxP-релевантность. В определении MHRA (которое охотно подхватывают руководства ISPE GAMP) GxP-релевантные данные - это те данные, которые позволяют реконструировать GxP-деятельность.
А вот теперь уже интерпретация этих определений на примере. Но прежде чем в это влезть ещё одно определение из MHRA - что такое целостность данных:
Обращаю Ваше самое пристальное внимание на оборот "is the degree to which data are" - т.е. степень, в которой данные <полны, последовательны, точны и т.п.> - у меня пару лет назад была очень жесткая заруба с американскими SME Pfizer на эту тему - формулировки MHRA пришлись весьма кстати - там речь шла о contemporaneous, т.е. о своевременности регистрации данных для восстановления GxP-активности. По итогу реконструировать цикл стерилизации удалось, причем отбив именно параметр своевременности.
Дам свежий пример как раз по стерилизации (на этой неделе). Откровенно говоря, возьмем банальную распечатку со стерилизатора BMT Unisteri (серийный номер стерилизатора намеренно обрезан):
Получается, что мы получили прямое доказательство, позволяющее реконструировать GxP-деятельность. Даже если у нас контроллер стерилизатора после этого навернулся "наглухо", то при условии сохранения распечатки (или её true copy) у нас сохранены все существенные данные - выделены красными рамками - основные параметры цикла стерилизации, подтверждение по температурам фазы экспозиции с временными отметками и формальное заключение об успешности пройденного цикла.
Понятно, что в памяти стерилизатора сохранялись все данные по циклу и их можно было бы распечатать повторно. Но если что-то пошло не так (хотя в данном оборудовании на контроллере есть слот с SD-картой, где всё эти данные сохраняются) - то мы реконструируем деятельность по этой распечатке.
В случае epic-fail мы в общем то можем заменить контроллер и если у нет резервной копии его прошивки, то данные рецептур можно восстановить с нуля. Но тут нужно быть внимательным. Вот данные по циклу - которые видит оператор:
А вот данные в сервисном меню (фрагмент):
С одной стороны данные параметров рецептур не так важны именно для реконструирования GxP-деятельности - тут важна сама распечатка с регистрацией параметров прошедшего цикла (а также табличные данные по таким циклам, графики и т.п.). Но если слетела прошивка контроллера, то тут вопрос не реконструкции, а продолжения дальнейшей деятельности - т.е. о непрерывности бизнеса.
Вот на данном примере и показан вариант "всамделишнего" анализа рисков и оценки согласно Приложения 11 GMP "необходимых данных" для резервного копирования.
Если бизнес принимает решение, что при слёте контроллера он согласен всё восстанавливать с нуля (остановив работу на неопределенное время), то, по сути, это его право при условии сохранения всех ретроспективных распечаток.
Если все ретроспективные распечатки не сохранены (так или иначе - в бумажном виде, в специализированном ПО BMT Print Archive, на SD-карте) - то нет возможности реконструировать GxP-деятельность.
Повторюсь, курсивом выделен пример и моя частная, субъективная интерпретация. Выше, с ссылками на MHRA - регуляторные требования.
Качественной интерпретации способствуют в т.ч. тексты некоторых FDA Warning Letters в части data integrity :))
Бэкап каждый день с кодированием файлов. Бэкап происходит в не рабочее время, хранится данная копия не менее 1-го месяца, всё зависит от сервера. В случае выхода из строя компьютера, есть возможность восстановить полностью все файлы с последнего копирования.
Александр Белинский Автор темы 22.01.2021 21:10 @s_mono, вы предполагаете ежедневный бекап с паровых стерилизаторов stand alone? Впрочем, мой магистральный вопрос в другом - проверка восстановления с резервных копий для технологического оборудования.
Хороший практический аспект, когда первоначально элемент КС (контроллер) не был разработан для т.н. регулируемого окружения. Я считаю, что необходимо задавать такой вопрос напрямую его разработчику. Возможно, решение уже есть.
И добавлю свои 5 копеек - толку от бэкапов ноль, если процедура тестового восстановления опасна для данных, имеющихся в системе (например, те же настройки режимов, хотя и они должны быть в резервной копии). Ведь, копия может быть тупо "битой".
Резервирование ради резервирования - это тоже встречается. Например, копирование на пленку. И на вопрос: как проверить возможность восстановления из копии? был ответ: нам никогда не ставилась такая задача.
Александр Белинский Автор темы 23.01.2021 06:02 @microb, на самом деле никаких проблем собственно с PLC Siemens S7/200/300/400 нет - процедура тестового восстановления даже описана в мануалах. Рискнувших её выполнить "просто так", спустя N лет безупречной работы оборудования в моём референс-листе нет. Вот отсюда и возник вопрос про "солнечные" Норвегии. Стерилизаторы SBM, например, сами австрийцы "тестово восстанавливают" в той же Австрии в таких случаях? 😉 Или ограничиваются резервными копиями? На наших заводах устоявшаяся практика если и делать такие копии (что уже плюс), то только на случай, если сгорел контроллер и его заменили.
Александр Белинский Автор темы 23.01.2021 07:23 И на вопрос: как проверить возможность восстановления из копии? был ответ: нам никогда не ставилась такая задача
Выше стоит - выделена красным в стартовом сообщении 🙂
Рискнувших её выполнить "просто так"
Запоздавшая валидация и невозможность оценить работоспособность копии - замечательное сочетание).
Александр Белинский Автор темы 28.01.2021 18:42 @microb, о да, при этом в наших широтах - наиболее распространённое на данный момент для stand alone legacy systems 😉 не буду цитировать возможные ответы начальников цехов, если вы как внутренний валидатор или как аутсорсер предложите восстановиться с резервной копии на 5-7 лет безупречно работающий стерилизатор или систему вентиляции:)
Александр Белинский Автор темы 28.01.2021 18:49 @microb, правда, на днях узнал, что у Siemens для их контроллеров вроде бы есть решения с эмуляцией оборудования, но на практике с этим пока не сталкивался.
Тот факт, что резервные копии делать нужно - вопросов не вызывает.
Вопрос вызывает понятие "данные". Требует уточнения вопрос о каких данных в данном документе идет речь. Вики трактует: Данные — зарегистрированная информация представление фактов, понятий или инструкций в форме, приемлемой для общения, интерпретации, или обработки человеком или с помощью автоматических средств (ISO/IEC/IEEE 24765-2010). Мое мнение "акцент" Приложения 11 GMP на данные формируемые системами, это могут быть логи, протокола, база данных SCADA и т.д. но не как не исходный код(автоматических средств) в котором может быть и интеллектуальная со́бственность и т.д. Поправьте если не прав.
Володимир Коваль 11.02.2021 10:35 @dreambelarus В плане резервных копий, сами системы так же важны. Например что то случилось с системой и она стала не работоспособной, переустановка в нуля, крайне не эффективна, даже если у вас есть все резервные копии баз данных и логов, так как сложные системы могут иметь крайне сложную конфигурацию и как часто бывает в ходе жизненного цикла системы, могут быть какие-то изменения, которые попросту отсутствуют в инсталляционном пакете, чтобы добавить их, нужна хорошенько постараться и проанализировать все изменения которые были. С большой долей вероятности, найти все не удастся.
По этому, данные могут оказаться частично бесполезными а восстановления работоспособности может занять значительное время. А это уже может быть недопустимо с точки зрения непрерывности бизнеса.
А если уж говорить о таких системах как LIMS, EMPOWER, TrackWise, DrugTrack & DocuBridge, SAP, SAP S/4HANA, прочих ERP или Т&T системах, та даже и систем поменьше, так отсутствие бэкапа системы может очень болеть в критический момент.
Но так же с вами соглашусь, для большинства аудиторов важна резервная копия самих данных (результаты анализов, контрольный след…), но для бизнеса все наоборот – ему нужна бесперебойная работа всех ИТ систем.
Оптимальный вариант – иметь синхронный срез данных и системы. Тогда с большой долей вероятности восстановление будет быстрым и не таким болезненным для бизнеса. А вот что нужно бэкапить, с какой переодичностю, типы бэкапов - это уже целая история 🙂
Например что то случилось с системой и она стала не работоспособной,
И что мы тут хотим валидировать???? 🙂
По этому, данные могут оказаться частично бесполезными а восстановления работоспособности может занять значительное время.
Данные во имя которых все и затевается которые будут служить доказательством что вся производимая продукция контролировалась на всех этапах не могут быть бесполезными, а подмена понятий не может оправдывать действия, которые могут привести к ситуации, когда интересы бизнеса станут превыше интересов пациента...день когда это наступит, будет днем заката....
но для бизнеса все наоборот – ему нужна бесперебойная работа всех ИТ систем.
Если нужна бесперебойная работа пусть вкладывается... Сам занимаюсь с недавних пор к сожалению данной темой. Как и на уровне восстановления рабочих проектов от оборудования, не переданного по различным причинам производителями так и в соответствии с новыми реалиями возникла необходимость удаленного управления оборудованием. Тут не все однозначно, кто-то охотно идет на контакт, где-то полнейшее игнорирование, приходится порой через их партнеров направлять на путь истинный 🙂 ... кто-то выставляет космические ценники желая заработать на ситуации и путем длительных переговоров охлаждаем горячие головы, но все по моему мнению необходимо проводить через легальное русло контроля изменений, иначе ваши резервные копии с " не помню что делал, но работает же" не "бесценны" а "грош им цена"... но боюсь "бизнес" этого не пойме...или не хочет замечать...так меньше затрат и больше прибыль.
Володимир Коваль 13.02.2021 15:52 @dreambelarus Не могу говорить за всех, но я делаю и требую тестирование бэкапа при первичной валидации системы, у нас и аварийное восстановление так же является частью первичной валидации.
Это связано с тем, что не все результаты анализов, документы разные, есть в печатном виде. Ведь в 21 столетии живем, зачем держать все на бумаге, когда есть различные комп системы?
А бэкап системы нужен для того, чтобы можно было корректно отобразить и прочесть данные. (Это как раз ответ, почему часть данных может стать бесполезной: ведь не всегда структура «одной» записи в какой то системе, является одним полем в таблице баз данных, в большинстве случаев, то что можно увидеть на мониторе, например результаты анализов в LIMS по какойто партии, запись о каком то несоответствии в системе по управлении изменениями и отклонениями и т.д., будет подтягиваться из разных таблиц базы данных, в некоторых случаях из разных баз или даже с разных серверов. Хотел бы я посмотреть, как кто то будет делать восстановление таких данных (GxP related) и собирать по все по кусочку (требование о архивации данных никто не отменял), если резервная копия будет сделана не синхронно со всей системой или же даже без бэкапа самой системы. Это будет больно.)
Без этого, всегда есть риск простоя бизнеса и соответственно поставок ЛС на рынок. А так, восстановления данных из бэкапа, и восстановление системы с нуля уже протестировано, ответственный персонал с IT Infra I BA уже знает как чинить ту или иную систему (GAMP хорошо описывает ети процессы). Все процессы и персонал который ответственный за ту или иную систему, задокументированы. Все по фен Шую)
Как вы упомянули, бесперебойная робота систем стоит денег. Но это может окупиться в один миг, после одной кибер атаки (вспомните только вирус Петя в 2017 году). К счастью, наш "бизнес" это хорошо осознает.
Если бизнес принимает решение, что при слёте контроллера он согласен всё восстанавливать с нуля (остановив работу на неопределенное время), то, по сути, это его право при условии сохранения всех ретроспективных распечаток.
Мое мнение "бизнеса" должен брать в расчет все варианты. Если мы про PLC проекты то шансов найти на рынке контролер с такой же прошивкой как у "7-летнего контролера" практически равен нулю, а все что выше необходимо подымать версии(применительно не только к TIA...) среды разработки, для этого необходимы исходники "рабочие проекты"+ желательно "сертифицированный" инженер:)... или обратится к производителю(если он еще в "адеквате" и получить ценник на все это с 4 а то и 5 нулями:)))
На наших заводах устоявшаяся практика если и делать такие копии (что уже плюс), то только на случай, если сгорел контроллер и его заменили.
Чтобы это работало на 99,9% при закупке оборудования необходимо по моему мнению покупать еще два контролера и две панели оператора:)... один комплект для оперативной замены (с установленными и протестированными на заводе прошивками), и один комплект электроникам поиграться:)... но никак не меньше... бо второй комплект будет через пару лет бесследно утерян:)
все существенные данные
🙂 вот и вы Александр понимаете что само определение "данные" требует уточнения применительно к конкретному случаю... спасибо за развернутый ответ.
