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

В плане работ-более 100 пунктов на год, более 40 исполнителей —сотрудников других подразделений и организаций.

Перевод СЭД в новую, более защищённую сеть (5 пунктов из 100) происходил так:

1. Администратор сети прописал на всех VipNet новый IP-адрес СЭД. 10000 пользователей из 3000+ юридических лиц, многие работают с 2–3 устройств, т е 20000+ устройств. Если в момент рассылки обновления на ViPNet он был отключён и на нём не последняя версия ПО (нет договора на ТП, поэтому ПО не обновлялось) — обновление не установилось. Отдел сетей прописал новый адрес на оборудовании. Это заняло 1 месяц.

2. Отдел тп2L и разработчик настроили новую виртуалку в новой подсети.

3. На сайт выложена инструкция «Как проверить доступность нового адреса СЭД».

По сути, пункты 3-6-это проведение массового тестирования при сохранении работы СЭД: люди работают с СЭД по старому адресу и тестируют доступность нового адреса. Пользователи использованы как распределенная система тестирования и переведены из разряда «проблема» в разряд «команда» и инструмент диагностики. Это - Change Management, только через прямой контакт с людьми, а не через приказы.

4. В СЭД на неделю вывешен баннер о том, что в час Х СЭД будет переключёна на новый адрес и вы в нее не попадёте, если ПК не имеет доступа. Проверьте. И инструкция.

5. То же предупреждение разослано по почте.

6. После опубликования пошли звонки по результатам тестирования с мест на прямой телефон руководителя работ. Это сделано не случайно: ТП не знала всей картины, куда копать и какие вопросы задавать, чтобы в режиме реального времени решить проблему — это мог сделать тот,кто видел всю картину и знал, какие симптомы вызваны какими инфраструктурными проблемами. Всего на этапе решено более 1000 случаев. Часть причин была в сфере ТЗИ, по ним точечно вносились коррективы в конкретные ViPNet. Часть — в локальных сетях участников СЭД, и тогда велась работа с админами сетей на местах: мы вместе вертели варианты, почему их сеть не видит новый адрес СЭД. 200 заявок каждый день из 5,в каждом случае причины индивидуальны. Было очень интересно.

7. К часу Х тестовым путём подтверждена доступность нового адреса СЭД на 99% устройств. Это —действия на опережение. Если бы мы переключили систему на новый адрес без пунктов 3-6 — многие не смогли бы работать в ней, а система критична, без нее работа организаций парализована.

8. В час Х переключаем СЭД — и начинается странный хаос: СЭД работает, но как-то не так. У части юрлиц все штатно, у части — непонятные симптомы. Все заявки на них передаются руководителю работ -сотрудники техподдержки L1 и L2 проинструктированы заранее. Через час становится ясно: проблема есть. Даётся распоряжение откатить систему на прежнюю виртуалку, команда анализирует симптомы, принимается во внимание даже адрес офиса, по которому они возникли.

9. Тогда было проведено 5–6 итераций пункта 8. Мы ломали головы, выдвигали гипотезы — и при каждой итерации опытным путём отбрасывали их. Было организовано точечное тестирование с ПК в тех юрлицах, где были проблемы, с мониторингом движения данных отделом сетей и ЦОДа.

10. В итоге нашли проблему: взятый в тест новый межсетевой экран. Он глотал пакеты данных. Вывод: при планировании подобных проектов вводить регламентный запрет несогласованного изменения оборудования, участвующего в работе систем. Руководитель работ должен знать всё. Только тогда он сможет соединить неочевидные симптомы в цельную картину и продумать все корневые причины. СЭД вывели из-под экрана— и переключились на новый адрес.

Вопрос.

А у вас были случаи, когда оборудование тихо ломает работу системы? Поделитесь опытом подобных проектов? Интересно.

#Управление #ИТ #СЭД #ПроектноеУправление #ЦифроваяТрансформация #экспертизаБорисовской