Размер шрифта
Цвет фона и шрифта
Изображения
Озвучивание текста
Обычная версия сайта
Портал пищевой промышленности foodsmi
Новости и стандарты
пищевой отрасли 12+
+7 4822 68-06-99
Подписаться на новости
Новости
События
Обучение
  • Безопасность пищевой продукции и упаковки
  • Менеджмент качества
  • Экологический и энергетический менеджмент, охрана труда
  • Гибкие навыки (soft skills)
О портале
  • О портале
  • Лицензии
  • Партнеры
  • Сотрудники
  • Вопрос эксперту
  • Реквизиты
  • Реклама
Контакты
...
Войти
Портал пищевой промышленности foodsmi
Новости и стандарты
пищевой отрасли 12+
Новости
События
Обучение
  • Безопасность пищевой продукции и упаковки
    Безопасность пищевой продукции и упаковки
  • Менеджмент качества
    Менеджмент качества
  • Экологический и энергетический менеджмент, охрана труда
    Экологический и энергетический менеджмент, охрана труда
  • Гибкие навыки (soft skills)
    Гибкие навыки (soft skills)
О портале
  • О портале
  • Лицензии
  • Партнеры
  • Сотрудники
  • Вопрос эксперту
  • Реквизиты
  • Реклама
Контакты
    Подписаться на новости
    Портал пищевой промышленности foodsmi
    Новости
    События
    Обучение
    • Безопасность пищевой продукции и упаковки
      Безопасность пищевой продукции и упаковки
    • Менеджмент качества
      Менеджмент качества
    • Экологический и энергетический менеджмент, охрана труда
      Экологический и энергетический менеджмент, охрана труда
    • Гибкие навыки (soft skills)
      Гибкие навыки (soft skills)
    О портале
    • О портале
    • Лицензии
    • Партнеры
    • Сотрудники
    • Вопрос эксперту
    • Реквизиты
    • Реклама
    Контакты
      Подписаться на новости
      Портал пищевой промышленности foodsmi
      Портал пищевой промышленности foodsmi
      • Новости
      • События
      • Обучение
        • Обучение
        • Безопасность пищевой продукции и упаковки
        • Менеджмент качества
        • Экологический и энергетический менеджмент, охрана труда
        • Гибкие навыки (soft skills)
      • О портале
        • О портале
        • О портале
        • Лицензии
        • Партнеры
        • Сотрудники
        • Вопрос эксперту
        • Реквизиты
        • Реклама
      • Контакты
      Подписаться на новости
      • Кабинет
      • +7 4822 68-06-99 Редакция портала
        • Телефоны
        • +7 4822 68-06-99 Редакция портала
      • 170019, г. Тверь, ул. Маяковского, 33, офис 66
      • mail@foodsmi.com
      • Пн. – Пт.: с 9:00 до 18:00

      Как повысить безопасность обновлений при эксплуатации IT-системы пищевого предприятия?

      Главная
      —
      Прикладные решения
      —Как повысить безопасность обновлений при эксплуатации IT-системы пищевого предприятия?
      Как повысить безопасность обновлений при эксплуатации IT-системы пищевого предприятия?
      Прикладные решения
      17.06.2022 09:00
      198

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

      Автор статьи – Екатерина Немцова, руководитель департамента сервисного сопровождения компании «Константа».

      Сложно представить современное предприятие без информационной системы (ИС) или систем. Посредством ИС реализуется исполнение массы процессов – от взаимодействия с покупателем до сдачи итоговой отчётности в контролирующие органы. 

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

      Вместе с тем каждый первый ответственный за бесперебойное функционирование ИС на пищевых предприятиях знает: внедрение изменений в работу системы сродни взлёту или посадке самолёта – самый аварийно-опасный момент. Одновременно запускаются сотни процессов и вероятность отказа существенно возрастает. А если учесть специфику работы производителей продуктов питания (производство и отгрузки 24/7, жесткие требования по срокам и объемам поставки и т.д.), то изменения становятся поводом для беспокойства.

      Что же может помочь соблюсти баланс между «живой» системой и рисками изменений? 

      Приведем часть используемых нами мер по повышению безопасности процессов изменений.

      Технические меры 

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

      1. Тестирование, тестирование и еще раз тестирование 

      • Ручное тестирование

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

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

      • “Дымовые” тесты

      Утилитарное тестирование. Позволяет быстро и широким охватом защититься от очень явных ошибок наподобие “не открывается и не проводится документ”. 

      • Автотесты

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

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

      2. Фича-флаги

      Это настройки, позволяющие в пользовательском режиме включить или отключить определенные возможности системы.

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

      • изменении высоконагруженных функций;
      • изменении функций, влияющих на другие процессы;
      • применении венчурных решений (мы до конца не понимаем, то ли это, что нам нужно);
      • использовании там, где возможности тестирования ограничены, например, при реализации изменений, связанных с боевыми контурами каких-нибудь ГИС, типа Меркурия и Честного знака, где достоверно протестировать просто невозможно.

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

      Организационные меры

      • Техника “Три Амиго”

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

      • Выбор времени для технологических окон

      Крайне желательно, чтобы обновления проходили в одно и то же время. Но не в дни, предшествующие праздничным и выходным дням, не перед запуском ключевых/объемных процессов. Т.е. стихийное обновление 31 декабря прямо перед стартом отгрузки на складе вероятно заставит кого-то понервничать, даже если не повлечет каких-то последствий. А если повлечёт, то времени и возможностей для маневра не останется совсем.

      • Информированность потребителей

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

      • Описание структуры системы

      С точки зрения повышения безопасности изменений полезно иметь описание системы. Это описание служит инструментом, позволяющим оценить влияние меняющейся логики на имеющееся решение. Но тут также, как и с автотестами, главное – найти оптимальный баланс достаточного и полезного. Описывать всё и постоянно – не оправдано с точки зрения трудозатрат, да и верхнеуровневой картинки подробное описание не даёт. А вот иметь описанный костяк системы, позволяющий в целом видеть набор задач, реализованных в системе, – история крайне полезная. При необходимости описание такого “костяка” можно расширять и дополнять информацией о ключевых особенностях системы применительно к конкретным ее частям.

      Дорогу осилит идущий

      Мы понимаем, что путь изменений настолько же тернист, насколько необходим. Безопасность изменений – это единство:

      • грамотно выбранной стратегии тестирования,
      • инструментов, страхующих процедуры разработки и доставки изменений,
      • продуманной организационной политики при планировании изменений и подготовленности к использованию новшеств.
      Дополнительно
      Новости
      Назад к списку
      • Законодательство 348
      • Международные стандарты 156
        • HACCP
        • ISO 22000
        • FSSC 22000
        • IFS
        • BRC
        • Global Red Meat Standard
        • GLOBALG.A.P
        • Global Aquaculture Aliance BAP
        • SQF 2000
        • GMP+
        • ISO 9001
        • ISO 14001
        • ISO 18188
        • ISO 14644
        • ISO 45001
        • ISO 13485
        • UTZ Certified
        • MSC
        • ISO 31000
        • ISO 26000
        • FAMI-QS
        • Freshcare
        • Интегрированные системы менеджмента
      • Международные организации 16
      • Статистика и исследования 425
      • Прикладные решения 46
      • Новости компаний 44
      • Интервью 3
      COVID-19 ORGANIC Аллергены ГОСТ Здоровое питание Импортозамещение Культура пищевой безопасности Международный стандарт GLOBALG.A.P Меркурий Нацпроекты Новости Пищевые отравления Санкции Сертификация Техрегламент Халяль Цифровизация Честный ЗНАК Экология
      FOODMEET FOODMEET
      Техноавиа Техноавиа
      Новости
      События
      Обучение
      О портале
      Контакты
      +7 4822 68-06-99
      mail@foodsmi.com
      170019, г. Тверь, ул. Маяковского, 33, офис 66
      © 2022

      Учредитель ООО «ИнтерКонсалт». Сетевое издание «Портал пищевой промышленности «Foodsmi» зарегистрировано в Федеральной службе по надзору в сфере связи, информационных технологий и массовых коммуникаций (Роскомнадзор) 10 ноября 2015 года. Свидетельство о регистрации Эл № ФС77-63654

      Политика конфиденциальности
      Версия для слабовидящих
      Карта сайта
      Новости События Обучение Вопрос эксперту Эксперты Поиск Кабинет