"Важно организовать ИТ-инфраструктуру таким образом, чтобы при возникновении внештатных ситуаций, в том числе сбоев, неисправностей оборудования или отказов в работе ПО, непрерывность работы сохранялась. Если раньше в первую очередь задумывались о физической инфраструктуре — серверах, сетевом резервировании, внешних и внутренних каналах связи, то сейчас, с более широким внедрением виртуализации, добавились хлопоты, непосредственно связанные с программной частью", — пояснил директор департамента медицинских решений "ЛАНИТ-ТЕРКОМ" Александр Евдокимов.
"Чтобы добиться этого, нужно ответственно подходить к проектированию и архитектуре, выбору соответствующих технологий, уделять внимание сопровождению и проактивной работе по предотвращению инцидентов", — уверен Евдокимов.
"Нулевой простой был достигнут благодаря стратегии параллельного запуска. Новая инфраструктура была полностью развернута в удаленных центрах обработки данных параллельно с работающей системой", — рассказал он.
"Не пытайтесь мигрировать все сразу — выберите некритичный сегмент бизнеса для пилотного проекта. Это позволит вашей команде получить реальный опыт, понять специфику работы с отечественным ПО, выявить подводные камни в безопасной среде", — советует Александр Чербунин.
"Сразу после этого мы готовим будущую целевую архитектуру и набор необходимых требований к планируемым системам, которые определят вектор реализации проекта", — рассказал он.
"Совместно с фокус-группой мы начинаем точечно переносить определенное количество сервисов, в онлайн-режиме мониторить, как они себя чувствуют, и получаем оперативную обратную связь от заказчика. Постепенно в рамках утвержденного плана мы продолжаем переносить всю инфраструктуру заказчика", — пояснил Чупрунов.
"Если мы выбираем самый некритичный сервис, то это не дает никакой гарантии для заказчика, что миграция пройдет успешно. Напротив, самый важный сервис напрямую влияет на выручку компании, и его изменение несет большие риски", — пояснил он.
"В случае возникновения сложностей или непредвиденных сценариев при эксплуатации новых информационных систем мы всегда остаемся на связи, подключаемся и консультируем", — подчеркнул Чупрунов.
"Самым важным в этот момент является создание стенда, на котором проводятся синтетические тестирования. Фактически мы в рамках этой задачи стараемся максимально воссоздать тот сценарий, который будет потенциально реализовываться в инфраструктуре заказчика", — пояснил он.
"Она может увеличиваться постепенно, когда наращивается количество виртуальных пользователей сервиса. А можно переходить сразу к пиковым нагрузкам, когда выбрасывается максимальное число виртуальных пользователей", — рассказал Чупрунов.
"Во время нее мы точечно рассматриваем наиболее критичные сервисы, в реальном времени собираем обратную связь по их отработке. На этом этапе мы обычно понимаем, есть ли какие-то отклонения и как их можно скорректировать", — пояснил Чупрунов.
"Это может быть переключение потоков данных между стендами, изменение настроек, выполнение специфических скриптов или миграции, восстановление из резервных копий. Иными словами, любые действия, которые будут направлены на откат к предыдущему состоянию. Без такого плана мы можем получить состояние, когда система уже не работает по-старому, не получается заставить ее работать по-новому и решительно непонятно, что с этим делать", — пояснил эксперт.
"При наличии двух версий одной системы идеальным решением будет заранее предусмотреть возможность их работы с одним набором данных. Но если используются разные приложения, и одно из них может выступать в качестве так называемой мастер-системы и предоставлять необходимую часть данных остальным, то это тоже хороший вариант", — рассказал Евдокимов.
"Новая инфраструктура была смонтирована во всех дата-центрах постепенно, в режиме совмещения с плановыми переездами между резервными и основными ЦОД. Начиная с ограниченного числа систем, осуществлялось переключение обращений на модернизированный сервис", — рассказал Александр Чербунин.
"Мы не могли позволить себе просто вносить изменения параллельно в обеих базах данных. При любой потенциальной поломке, недоступности, откате транзакций и т. д. такая цепочка просто рассыпалась бы. Именно поэтому мы разработали специальный механизм, который работал на уровне метаданных СУБД и позволял в любой момент переключить обработку запросов между разными системами. Для пользователей эта замена произошла совершенно незаметно", — рассказал он.