Особенности обновления IT-системы пищевого предприятия

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

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

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

Что же может помочь соблюсти баланс между «живой» системой и рисками изменений? Вопрос объемный. В этой статье мы не преследуем целей “открытия Америки” и не пытаемся научить всех всему на свете. Скорее, приводим пример некоторых действий, которые помогают в работе нам, и, возможно, помогут и вам.

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

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

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

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

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

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

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

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

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

• Автотесты

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Источник: MilkLife.ru по материалам компании Константа