Наверх

ECM-Journal обновился!

Если вы ещё не зарегистрированы на сайте, сделайте это прямо сейчас. Если у вас уже есть профиль, то просто обновите пароль.

План переноса ЕСМ-системы на внешний хостинг

Архив
Время чтения: 3 минуты
7
План переноса ЕСМ-системы на внешний хостинг

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

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

Этап 1. Подробный анализ текущей инфраструктуры (1-2 недели).

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

Этап 2. Подробный анализ требований к новой инфраструктуре в ЦОД (2-3недели).

На данном этапе формируются требования к новой инфраструктуре, расположенной в центре обработки данных (ЦОД). Здесь необходимо выработать требования к новой инфраструктуре. В первую очередь, это требования к безопасности (на случай чрезвычайных ситуаций: пожар, затопление, кто в этих случаях будет иметь физический доступ к серверу). Затем сформулировать требования к отказоустойчивости и времени восстановления инфраструктуры (например, наличие кластера, репликация данных на резервный сервер и др.).

Этап 3. Выбор подходящего ЦОД (2-3 недели).

В соответствии с заявленными требованиями выбираем ЦОД. ЦОД должен в максимальной степени выполнять наши требования.

Этап 4. Реализация новой инфраструктуры в ЦОД (3 недели).

Данный этап зависит от выбранного типа реализации инфраструктуры:

- мы арендуем виртуальные сервера;

- мы арендуем физические сервера;

- мы покупаем физические сервера.

На данном этапе производится первичная настройка инфраструктуры. Этап реализации - один из самых длительных этапов проекта и может длиться до 3 недель. Итогом этого этапа будет уже готовая к эксплуатации инфраструктура.

Этап 5. Тестирование новой инфраструктуры в ЦОД (1 неделя).

Тестирование и проверка инфраструктуры на устойчивость и безотказность в работе займут около 1 недели.

Этап 6. Создание плана переноса инфраструктуры (1 неделя).

По результатам тестирования создается план переноса инфраструктуры в ЦОД. План содержит этапы переноса, в соответствии с конкретными календарными датами.

Этап 7. Тестирование процесса переноса инфраструктуры (1 неделя).

Для эффективного переноса инфраструктуры в ЦОД осуществляется тестирование процессов, обеспечивающих этот перенос.

Этап 8. Перенос инфраструктуры (1 неделя).

И, конечно же, завершающим этапом будет сам перенос инфраструктуры. Перенос осуществляется в соответствии с планом, разработанным и утвержденным ранее.

Итого, перенос ЕСМ-системы на внешний хостинг состоит из 8 главных этапов и может занять в среднем 11 недель.

Но, конечно же, как вы сами понимаете, каждый случай индивидуален и может повлиять как на этапы проведения проекта, так и на их длительность.

Чтобы прочитать эту статью до конца,
или зарегистрируйтесь

Комментарии 7

Итого, перенос ЕСМ-системы на внешний хостинг состоит из 8 главных этапов и может занять в среднем 11 недель.
А может и не 11.
Иван, сколько различных систем (кроме, понятное дело, DIRECTUM) ты переносил на внешний хостинг, чтобы делать столь далеко идущие выводы?

Не понятно что такое

Перенос инфраструктуры

что туда входит? Это только миграция базы или что-то еще?

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

Вы смогли смигрировать всех пользователей за неделю? Сколько их было?

Далее

Тестирование новой инфраструктуры в ЦОД
На сколько я понимаю, основной момент в этом тестировании - создание нагрузки, эквивалентной той, что есть на текущей системе. Если честно, то не очень верю, что это можно организовать за 1 неделю. Более того, то, что мы заказываем готовый сервер, не произведя должного тестирования вызывает скорее недоумение.
Здесь необходимо выработать требования к новой инфраструктуре. В первую очередь, это требования к безопасности (на случай чрезвычайных ситуаций: пожар, затопление, кто в этих случаях будет иметь физический доступ к серверу).
Иван, мы говорим о публичном ЦОД или внутрикорпоративном? Если о публичном, то кто нам позволит вмешиваться во внутренние вопросы работы ЦОД? Я могу ошибаться, но, на мой взгляд, противопожарные меры и вопросы disaster recovery - внутренние дела ЦОД? Для нас ЦОД - это набор сервисов, нам не важно, как обеспечивается бесперебойная работа, нам нужна непрерывнось сервиса. Или я что-то не понимаю?

Опять возникло много вопросов, которые я изложил в отдельном посте: http://www.pcweek.ru/ecm/blog/ecm/2972.php

Спасибо за оставленные комментарии и терпение, с которым вы ждете мои ответы.

Когда я писал свои статьи, главной целью ставил сформировать некоторое видение относительно  переноса ЕСМ-системы в облака. В статье я выделил лишь основные этапы переноса и ориентировочные сроки выполнения работ. Соглашусь с Андреем, время переноса системы может быть как больше, так и меньше 11 недель, это некий план, своего рода ориентир, который зависит от множества факторов.

Михаил, под переносом инфраструктуры здесь понимается миграция базы данных и перенос самого приложения, т.е. ЕСМ-системы и сервисов, необходимых для работы.

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

Сергей, в своей статье я говорю о публичном ЦОД. Конечно же, мы не собираемся вмешиваться в ЦОД, здесь я говорю о том, что первоначально надо сформировать требования к ЦОД, и, учитывая эти требования, выбирать ЦОД.

Полностью согласен с комментариями Андрея, отраженными в блоге. Конечно же, перед тем, как решится на этот проект, необходимо выделить критерии эффективности, проанализировать его целесообразность. Полностью поддерживаю Ваше мнение в вопросе о целесообразности этого проекта. Для меня он остается достаточно неоднозначным.

Возможно Андрей, вы правы и этапы, предложенные мной этапы переноса ЕСМ-системы в облака, будут применимы и для других систем.  Но так как я работаю с ЕСМ-системой, а с системами других классов не знаком, то я ничего не могу сказать по этому поводу.

Этап опытной эксплуатации обязателен и он подразумевается в этапе 5. Возможно, я не совсем точно выразился, но именно в этом этапе я подразумевал опытную эксплуатацию инфраструктуры.

Абсолютно согласен с Вами, Андрей, относительно вопроса аварийного возврата к начальному варианту. Спасибо за предложение, это следует добавить 9 этапом. Вместе с созданием плана переноса обязательно должен быть и план возврата. Полностью поддерживаю.

В статье я выделил лишь основные этапы переноса и ориентировочные сроки выполнения работ.

Иван, я все время считал, что ты публикуешь реальные цифры по итогам реального переноса системы на внешний хостинг.

Я ошибался? А если нет, то почему сроки и суммы только примерные?
 

Чтобы прокомментировать, или зарегистрируйтесь