{"id":13503,"url":"\/distributions\/13503\/click?bit=1&hash=a6a620b0b3e1c075f1e83feddacf93e193aeb4143fb6c4c0845bea8392031afd","title":"\u0414\u043e\u0440\u043e\u0433\u0438\u0435 \u0433\u043e\u043b\u043e\u0441\u043e\u0432\u044b\u0435 \u0440\u043e\u0431\u043e\u0442\u044b vs. \u043d\u0435\u0434\u043e\u0440\u043e\u0433\u0438\u0435 \u0433\u043e\u043b\u043e\u0441\u043e\u0432\u044b\u0435 \u0440\u043e\u0431\u043e\u0442\u044b","buttonText":"\u041a\u0442\u043e \u043f\u043e\u0431\u0435\u0434\u0438\u0442?","imageUuid":"f51d1df3-c90f-5d41-a4ff-0d0fa66a34ac","isPaidAndBannersEnabled":false}

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

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

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

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

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

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

Не удивительно, что при таком раскладе многие руководствуются формулой “не трогай, пока работает”. Так и живём ((

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

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

PS. Если вы уже сейчас понимаете, что вам необходим опытный «провожатый», обращайтесь – [email protected] ru

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

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

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

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

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

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

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

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

  • Автотесты

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ну а если понадобится опытный «провожатый», обращайтесь – [email protected] ru. Мы этой дорогой уже ходили и можем помочь.

0
Комментарии
Читать все 0 комментариев
null