Статья для тех, чьей задачей является обеспечение бесперебойности работы IT-системы пищевого предприятия. А также для тех, кто инициирует изменения в этой области и заинтересован в безопасности их проведения.
Автор статьи – Екатерина Немцова, руководитель департамента сервисного сопровождения компании «Константа».
Сложно представить современное предприятие без информационной системы (ИС) или систем. Посредством ИС реализуется исполнение массы процессов – от взаимодействия с покупателем до сдачи итоговой отчётности в контролирующие органы.
Многолетняя практика не дает нам сомневаться в том, что единожды внедрённая на предприятии система не может оставаться статичной. Если система остается в первозданном виде продолжительное время, значит что-то пошло не так. Система живет и меняется вместе с предприятием, учитывая и поддерживая изменения физических процессов организации. Помогает реализовывать внутренние инициативы и соответствовать требованиям внешних контролеров. И предприятия пищевой отрасли, которые традиционно являются объектом пристального внимания извне, особенно показательны в этом плане.
Вместе с тем каждый первый ответственный за бесперебойное функционирование ИС на пищевых предприятиях знает: внедрение изменений в работу системы сродни взлёту или посадке самолёта – самый аварийно-опасный момент. Одновременно запускаются сотни процессов и вероятность отказа существенно возрастает. А если учесть специфику работы производителей продуктов питания (производство и отгрузки 24/7, жесткие требования по срокам и объемам поставки и т.д.), то изменения становятся поводом для беспокойства.
Что же может помочь соблюсти баланс между «живой» системой и рисками изменений?
Приведем часть используемых нами мер по повышению безопасности процессов изменений.
Технические меры
Даже не будем широко комментировать такие вещи как наличие свежего бэкапа перед обновлением и нежелательность динамических обновлений. Первое обязательно должно быть, второго быть не должно.
1. Тестирование, тестирование и еще раз тестирование
- Ручное тестирование
Название говорит само за себя. Осуществляется вручную как группой разработки и сотрудниками первой линии поддержки, так и функциональными заказчиками в зависимости от организационных процессов, принятых на предприятии. Осуществляется в режимах локального тестирования конкретных изменений, по факту их разработки и в режиме сквозного тестирования всего перечня разработок перед передачей в обновление.
Процедура исторически самая понятная, но при этом регулярно упирающаяся в пресловутый человеческий фактор. Даже самый опытный и сообразительный сотрудник любого из уровней не может гарантированно ничего не забыть и провернуть в голове все сценарии связанных изменений.
- “Дымовые” тесты
Утилитарное тестирование. Позволяет быстро и широким охватом защититься от очень явных ошибок наподобие “не открывается и не проводится документ”.
- Автотесты
Это некоторый скрипт, записанный человеком, имитирующий нужный порядок действий в системе и анализирующий результат этих действий. Автотест – это гарантия того, что записанный сценарий будет проверен. Это оправдано в случае, если мы имеем сложную систему, вероятность успешного ручного тестирования которой стремится к нулю.
Принимая решение о необходимости автотестов, нужно учитывать, что функционал, который хочется покрыть автотестами, должен быть относительно стабилен, потому что каждый раз при изменении функционала, соответствующий автотест должен быть переписан. Если в какой-то области происходят активные изменения, то с написанием автотестов попросту не будут успевать. Ну и трудозатрат на постоянную актуализацию не мало. Да, покрытие автотестами – история трудозатратная, а стопроцентное покрытие системы выглядит вообще утопично. Поэтому рекомендуется выбрать ключевые сценарии, связанные с наибольшими рисками, покрыть их автотестами и регулярно следить за их актуальностью.
2. Фича-флаги
Это настройки, позволяющие в пользовательском режиме включить или отключить определенные возможности системы.
Разработка изменений в таком режиме может потребовать несколько бОльших трудозатрат, нежели при классическом вживлении кода в систему, но выглядит вполне оправданной при:
- изменении высоконагруженных функций;
- изменении функций, влияющих на другие процессы;
- применении венчурных решений (мы до конца не понимаем, то ли это, что нам нужно);
- использовании там, где возможности тестирования ограничены, например, при реализации изменений, связанных с боевыми контурами каких-нибудь ГИС, типа Меркурия и Честного знака, где достоверно протестировать просто невозможно.
Неплохо применять при задачах, на которых организационно удобно управлять включением изменений нажатием одной кнопки.
Организационные меры
- Техника “Три Амиго”
Суть техники: дабы исключить неоднозначность и расхождения в видении реализации задачи, в постановке задачи участвуют трое: тот, кто заказывает изменения на уровне “бизнеса”, тот, кто будет разрабатывать решение и тот, чьими руками будет проводиться тестирование готовности решения. Так мы сближаем картины мира заинтересованных сторон, понижаем “транзакционные” потери, исключаем “глухой телефон”.
- Выбор времени для технологических окон
Крайне желательно, чтобы обновления проходили в одно и то же время. Но не в дни, предшествующие праздничным и выходным дням, не перед запуском ключевых/объемных процессов. Т.е. стихийное обновление 31 декабря прямо перед стартом отгрузки на складе вероятно заставит кого-то понервничать, даже если не повлечет каких-то последствий. А если повлечёт, то времени и возможностей для маневра не останется совсем.
- Информированность потребителей
Периодически мы сталкиваемся с ситуациями, когда праведный гнев у людей “на местах”, регулярно использующих функционал системы, вызван даже не поломкой системы, а ее изменениями, о которых никто не предупреждал, не обучал, не показывал, не информировал. И вроде всё работает так как хотел идеолог изменений, и вроде технически всё сделано грамотно, но простые пользователи в панике. Хорошим тоном со стороны разработчика системы является передача перечня изменений системы специалистам первой линии поддержки, а оттуда, соответственно, оповещение ключевых пользователей конкретных функций об изменениях в понятной им форме.
- Описание структуры системы
С точки зрения повышения безопасности изменений полезно иметь описание системы. Это описание служит инструментом, позволяющим оценить влияние меняющейся логики на имеющееся решение. Но тут также, как и с автотестами, главное – найти оптимальный баланс достаточного и полезного. Описывать всё и постоянно – не оправдано с точки зрения трудозатрат, да и верхнеуровневой картинки подробное описание не даёт. А вот иметь описанный костяк системы, позволяющий в целом видеть набор задач, реализованных в системе, – история крайне полезная. При необходимости описание такого “костяка” можно расширять и дополнять информацией о ключевых особенностях системы применительно к конкретным ее частям.
Дорогу осилит идущий
Мы понимаем, что путь изменений настолько же тернист, насколько необходим. Безопасность изменений – это единство:
- грамотно выбранной стратегии тестирования,
- инструментов, страхующих процедуры разработки и доставки изменений,
- продуманной организационной политики при планировании изменений и подготовленности к использованию новшеств.
