Уведомления

Ревалидация при обновлении всей ОС или установке патчей ОС

   RSS

0

Добрый день, уважаемые коллеги!

Как вы считаете необходимо ли ревалидировать ПО, которое установлено на компьютере, если было выполнено обновление ОС с версии 8.1 до 10. Как быть в случае если с определенной периодичностью происходит установка обновлений ОС. При установке каждого обновления также необходимо ревалидировать?

3 ответа(-ов)
2

Добрый день!

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

Обновление или установку патчей целесообразно рассматривать как изменения. В таких случаях необходимо использовать процедуры управления изменениями, управление рисками, и периодический обзор КС, то есть:

  1. Зафиксировать изменение(я).
  2. Оценить риски при внедрении изменения (на основании оценки рисков можно собственно и обосновать необходимость ревалидации).
  3. В рамках периодического обзора, согласно плану провести ревалидацию основываясь на зафиксированные изменения в рамках планового периода и оценку рисков).

Возможно более опытные коллеги поправят, но на данные момент применяем такой алгоритм.

Спасибо! Если я правильно понял, то правильный анализ рисков может избавить от повторной ревалидации, например, если показать, что обновления ОС не затрагивают файлы программы и программа не использует какие-либо важные системные файлы. Тогда наверное надо связаться с поставщиком софта, чтобы он предоставил информацию касательно того, что системные файлы не затрагиваются программой.

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

В анализе рисков надо выделить критичные риски в отношении ОС и перепроверять те функции, с которыми связаны эти риски при каждом обновлении?

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

Перепроверять при каждом обновлении не стоит, но если Вы показываете что есть высокие уровни риска, то лучше проверить минимум 3 раза и снизить их до приемлемого уровня (то есть сыграть на оценке вероятности возникновения и обнаружения)в итоге если после 3х проверок у Вас уровень не увеличивается, а находится в допустимом пределе или даже снижается можно смело утверждать что «Да, риски есть, но они приемлемые и мы ними управляем».

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

На самом деле штука действительно стремная - никто ничего гарантировать при обновлении ОС просто не может - вон при обновлении не только Win 8.1 - Win 10, а уже при обновлении самой Win10 вылетали драйвера МФУ Canon, причем хитро, с печатью всё ок, а вот со сканом случались баги. Впрочем вероятность обнаружения - 100 % 🙂 Нет ни единой гарантии, что что-то будет работать устойчиво, кроме тотального отключения от всего внешнего мира. Т.е. только использование системы в режиме stand alone - именно по этой причине и валидацией и системным администрированием могут заниматься только люди с крепкой нервной системой - нет ни единого примера более подверженных к изменениям объектов валидации, чем КС в сопряжении с непрерывными патчами. Ключевой водораздел по анализу рисков я бы вел по линии "блокировка бизнес-процесса"/"кривой бизнес-процесс". В первом случае риски большей частью приемлемы, т.к. в случае блокировки мы попросту ничего не сделаем. Например, не распечатаем извещение или не подпишем сертификат качества. Во втором случае, конечно, сложнее. Но и встречаться ситуация такая будет реже, например, когда после обновления MS Excel перестанет считать правильно среднее значение или улетит логика типа if ... then... else и т.п.

1

Касательно ревалидации в ходе обновлений, я бы не уходил от этой практики. Со своего опыта, могу сказать что не все обновления применяются безболезненно.
Нужно ли валидировать систему – ответ на этот вопрос очень прост, да если она манипулирует GxP данными. В большинстве случаев, поставщик представляет пакет документации для обновление. Все зависит от того, какой договор у вас с поставщиком и что вы прописали в SLA.

Касательно ОС, нужно иметь квалификацию версии, так как у нас есть четкое указание «инфраструктура должна бить квалифицирована, ПО – валидировано», ну и читать release notes. В идеале, нужно иметь тестовою машину, где было бы не плохо протестировать билд и его совместимость с критичным ПО. Наша инфраструктура так делает каждый раз перед обновлением. Ну и чтобы не было много не нужных заданий, полено составить план обновлений и смотреть что ставить что нет. Например, минорные билды можно пропускать, если для вас там нет ничего полезного особо.

Миграция со старых ОС на новые – это болезненная тема, особенно когда речь идет о QC и заводе – некоторый старенький софт не умеет пока работать с новыми ОС. Можно оставить их на ХР и пока не патчить, но тут нужны дополнительные меры безопасности, так как такие машины наиболее уязвимы для взлома.

Касательно анализа рисков, можно так ними «наприкриватся», что половина софта будет работать з багами. Надо быть осторожным.

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

Спасибо, Александр.
Еще немного дополню свой предыдущий комментарий.
Обновления не так уж и страшны для большинства современных ПО. Как правило, есть практика иметь весь перечень существующих критических систем и в этом же перечни иметь информацию, с какими ОС они совместимы и какие технологии с какими версиями им нужны для надлежащей работы.
Также, есть одно «золотое»  правило – одна система одна виртуальная машина, одна база данных – один
SQL сервер (ну с этим посложнее, практика иметь shared SQL очень популярная, сейчас уходим от неё). Плюс, должна быть как минимум одна дополнительная среда – для разработки (DEV) или для квалификации (QUAL/TEST).
И чтобы все это правильно использовать, нужно описать в процедуре жизненный цикл ПО включительно с обновлениями самого софта и ОС + включить пакет валидационной документации от паставчика ПО на каждое обновления, если возможно. Тогда можно и обновлять все что надо и не сильно рисковать производственными системами.

С облачными технология такой же подход, но надо использовать более строгие правила безопасности – always on VPN, SSO, чуть ограничить пользователей в возможностях браузера и можно наслаждаться жизнью и технологиями 😊

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

Конечно, есть и исключения 😊 не все можно легко пропатчить или перейти на более новую ОС, у всех причины разные и каждую нужно рассматривать отдельно – несовместимость ПО с новыми ОС, ПО «прибито» до ОС и после обновления нужно будет идти к поставщику, ПО после переустановки будет нуждаться в переустановке и валидации которую проводить только поставщик и так далее. Лучше изолировать и оставить как есть пока не будет глобального проекта по обновлению ОС и ПО параллельно.

Настроить все это в компании довольно трудоемкий и довольно нервозный проект, ну лучше это делать потихоньку.

Надеюсь комментарии немного пролили света на тёмные айтишные вопросы 😊

0

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. Понятно что жизнь не стоит на месте и в любом изменении присутствуют как плюсы так и минусы и неизбежны риски «сырого» ПО.
Вопрос возможно банальный. Быть или не быть миграции или отложить на долгую перспективу... как говорится лучшее враг хорошему и не надо лезть в налаженный годами механизм. Понятно что придется потрудится чтобы вписаться в действующую ФСК вот это и хотелось бы обсудить.

@dreambelarus

Опубликовано: @dreambelarus

Java Appelets and support are no longer free and many people have moved to HTML 5.0.

А вот на это можно пруфлинк? Когда это апплеты стали платными? И прям таки не поддерживаются Осликом, который до сих пор есть в той же Вин 10? Вот не поверю, что Майки выстрелят себе в ноги. У Вин 7 была эмбед версия для встраивание в устройства и неужели все эти устройства завтра перестанут работать. Думаю, что нет. У вас есть стабильно работающий процесс и устройство, пусть работают. У меня есть живые примеры установок, которые до сегодняшнего дня работают на древних пентиумах с Вин 95 или 486-х процах с Вин 3.11 и их не списывают, потому что удобные и все работает как часы. Поменять всегда успеете.


Подписывайтесь на каналы PHARM COMMUNITY:

   
Поделиться: