Добрый день, уважаемые коллеги!
Как вы считаете необходимо ли ревалидировать ПО, которое установлено на компьютере, если было выполнено обновление ОС с версии 8.1 до 10. Как быть в случае если с определенной периодичностью происходит установка обновлений ОС. При установке каждого обновления также необходимо ревалидировать?
Добрый день!
По личному опыту могу сказать, что при каждом обновлении любого ПО смыла ревалидировать как такового нет.
Обновление или установку патчей целесообразно рассматривать как изменения. В таких случаях необходимо использовать процедуры управления изменениями, управление рисками, и периодический обзор КС, то есть:
- Зафиксировать изменение(я).
- Оценить риски при внедрении изменения (на основании оценки рисков можно собственно и обосновать необходимость ревалидации).
- В рамках периодического обзора, согласно плану провести ревалидацию основываясь на зафиксированные изменения в рамках планового периода и оценку рисков).
Возможно более опытные коллеги поправят, но на данные момент применяем такой алгоритм.
![](https://pharm-community.com/wp-content/litespeed/avatar/92f6e2c4825a54e9944b363fb7af7dc7.jpg?ver=1725642749)
Спасибо! Если я правильно понял, то правильный анализ рисков может избавить от повторной ревалидации, например, если показать, что обновления ОС не затрагивают файлы программы и программа не использует какие-либо важные системные файлы. Тогда наверное надо связаться с поставщиком софта, чтобы он предоставил информацию касательно того, что системные файлы не затрагиваются программой.
Хотя такое сложно представить. Ведь любая программа, которая работает в среде ОС взаимодействует с теми или иными системными файлами, даже та же операция чтения/записи файла, все-равно идет через системные библиотеки.
В анализе рисков надо выделить критичные риски в отношении ОС и перепроверять те функции, с которыми связаны эти риски при каждом обновлении?
![](https://pharm-community.com/wp-content/litespeed/avatar/d0aff4343142be858f704218ccb1468e.jpg?ver=1725658817)
Управление рисками это вообще хитрая и полезная штука, если ее правильно использовать то можно и прикрыть тыл перед любым аудитором и извлечь реальную пользу для системы в целом. Избавится вообще от ревалидации нельзя но аргументировать ее проведение не каждый раз а в четко заданный период это "+".
Перепроверять при каждом обновлении не стоит, но если Вы показываете что есть высокие уровни риска, то лучше проверить минимум 3 раза и снизить их до приемлемого уровня (то есть сыграть на оценке вероятности возникновения и обнаружения)в итоге если после 3х проверок у Вас уровень не увеличивается, а находится в допустимом пределе или даже снижается можно смело утверждать что «Да, риски есть, но они приемлемые и мы ними управляем».
Насчет поставщиков софта это конечно на уровне фантастики, хотя можно попробовать (смотря какой софт) но лучше самим составить такой тест-кейс чтобы проверить и доказать что обновление не влияет на целостность данных и тд. или влияет но несущественно/минимально/приемлемо.
![](https://pharm-community.com/wp-content/litespeed/avatar/01375b6b696f3fb3b45aaa6d105fc483.jpg?ver=1725592939)
На самом деле штука действительно стремная - никто ничего гарантировать при обновлении ОС просто не может - вон при обновлении не только Win 8.1 - Win 10, а уже при обновлении самой Win10 вылетали драйвера МФУ Canon, причем хитро, с печатью всё ок, а вот со сканом случались баги. Впрочем вероятность обнаружения - 100 % 🙂 Нет ни единой гарантии, что что-то будет работать устойчиво, кроме тотального отключения от всего внешнего мира. Т.е. только использование системы в режиме stand alone - именно по этой причине и валидацией и системным администрированием могут заниматься только люди с крепкой нервной системой - нет ни единого примера более подверженных к изменениям объектов валидации, чем КС в сопряжении с непрерывными патчами. Ключевой водораздел по анализу рисков я бы вел по линии "блокировка бизнес-процесса"/"кривой бизнес-процесс". В первом случае риски большей частью приемлемы, т.к. в случае блокировки мы попросту ничего не сделаем. Например, не распечатаем извещение или не подпишем сертификат качества. Во втором случае, конечно, сложнее. Но и встречаться ситуация такая будет реже, например, когда после обновления MS Excel перестанет считать правильно среднее значение или улетит логика типа if ... then... else и т.п.
Касательно ревалидации в ходе обновлений, я бы не уходил от этой практики. Со своего опыта, могу сказать что не все обновления применяются безболезненно.
Нужно ли валидировать систему – ответ на этот вопрос очень прост, да если она манипулирует GxP данными. В большинстве случаев, поставщик представляет пакет документации для обновление. Все зависит от того, какой договор у вас с поставщиком и что вы прописали в SLA.
Касательно ОС, нужно иметь квалификацию версии, так как у нас есть четкое указание «инфраструктура должна бить квалифицирована, ПО – валидировано», ну и читать release notes. В идеале, нужно иметь тестовою машину, где было бы не плохо протестировать билд и его совместимость с критичным ПО. Наша инфраструктура так делает каждый раз перед обновлением. Ну и чтобы не было много не нужных заданий, полено составить план обновлений и смотреть что ставить что нет. Например, минорные билды можно пропускать, если для вас там нет ничего полезного особо.
Миграция со старых ОС на новые – это болезненная тема, особенно когда речь идет о QC и заводе – некоторый старенький софт не умеет пока работать с новыми ОС. Можно оставить их на ХР и пока не патчить, но тут нужны дополнительные меры безопасности, так как такие машины наиболее уязвимы для взлома.
Касательно анализа рисков, можно так ними «наприкриватся», что половина софта будет работать з багами. Надо быть осторожным.
![](https://pharm-community.com/wp-content/litespeed/avatar/01375b6b696f3fb3b45aaa6d105fc483.jpg?ver=1725592939)
Очень рациональный пост, кстати, именно по причинам, которые совершенно уместно актуализировал Владимир.
![](https://pharm-community.com/wp-content/litespeed/avatar/2afc2aadebdc31601292c703939a4663.jpg?ver=1725594494)
Спасибо, Александр.
Еще немного дополню свой предыдущий комментарий.
Обновления не так уж и страшны для большинства современных ПО. Как правило, есть практика иметь весь перечень существующих критических систем и в этом же перечни иметь информацию, с какими ОС они совместимы и какие технологии с какими версиями им нужны для надлежащей работы.
Также, есть одно «золотое» правило – одна система одна виртуальная машина, одна база данных – один SQL сервер (ну с этим посложнее, практика иметь shared SQL очень популярная, сейчас уходим от неё). Плюс, должна быть как минимум одна дополнительная среда – для разработки (DEV) или для квалификации (QUAL/TEST).
И чтобы все это правильно использовать, нужно описать в процедуре жизненный цикл ПО включительно с обновлениями самого софта и ОС + включить пакет валидационной документации от паставчика ПО на каждое обновления, если возможно. Тогда можно и обновлять все что надо и не сильно рисковать производственными системами.
С облачными технология такой же подход, но надо использовать более строгие правила безопасности – always on VPN, SSO, чуть ограничить пользователей в возможностях браузера и можно наслаждаться жизнью и технологиями ?
Этот подход используется у меня на работе, работает как часики, два дня назад все пользователи получили обновления ОС, сервера также обновляются согласно некому графику, это позволяет повышать безопасность и отказоустойчивость всей инфраструктуры и бизнес приложений.
Конечно, есть и исключения ? не все можно легко пропатчить или перейти на более новую ОС, у всех причины разные и каждую нужно рассматривать отдельно – несовместимость ПО с новыми ОС, ПО «прибито» до ОС и после обновления нужно будет идти к поставщику, ПО после переустановки будет нуждаться в переустановке и валидации которую проводить только поставщик и так далее. Лучше изолировать и оставить как есть пока не будет глобального проекта по обновлению ОС и ПО параллельно.
Настроить все это в компании довольно трудоемкий и довольно нервозный проект, ну лучше это делать потихоньку.
Надеюсь комментарии немного пролили света на тёмные айтишные вопросы ?
Microsoft has stopped the support for Windows 7. Java Appelets and support are no longer free and many people have moved to HTML 5.0...с такой фразы начался диалог с разработчиком ПО реализующего архивацию данных технологического процесса. И самое главное необходима замена ПО поддерживающее Win10. Понятно что жизнь не стоит на месте и в любом изменении присутствуют как плюсы так и минусы и неизбежны риски «сырого» ПО.
Вопрос возможно банальный. Быть или не быть миграции или отложить на долгую перспективу... как говорится лучшее враг хорошему и не надо лезть в налаженный годами механизм. Понятно что придется потрудится чтобы вписаться в действующую ФСК вот это и хотелось бы обсудить.
![](https://pharm-community.com/wp-content/litespeed/avatar/94fa5cad1896de3ce786a8305041799e.jpg?ver=1725594494)
@dreambelarus
Java Appelets and support are no longer free and many people have moved to HTML 5.0.
А вот на это можно пруфлинк? Когда это апплеты стали платными? И прям таки не поддерживаются Осликом, который до сих пор есть в той же Вин 10? Вот не поверю, что Майки выстрелят себе в ноги. У Вин 7 была эмбед версия для встраивание в устройства и неужели все эти устройства завтра перестанут работать. Думаю, что нет. У вас есть стабильно работающий процесс и устройство, пусть работают. У меня есть живые примеры установок, которые до сегодняшнего дня работают на древних пентиумах с Вин 95 или 486-х процах с Вин 3.11 и их не списывают, потому что удобные и все работает как часы. Поменять всегда успеете.