Назад | Перейти на главную страницу

Как изящно модернизировать критически важные системы до совершенно разных систем?

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

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

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

Однако это не значит, что все равно не будет.

Скажите, что вы переходите с Exchange на Exim (или даже просто из Sendmail в Exim). Как ты с этим справляешься?

Это сложный вопрос, который зависит от конкретной ситуации. Ключевые вопросы:

  • иметь запасной план Что бы вы ни делали, имейте план, как быстро вернуться к старым системам. Если вы не можете этого сделать, то требуется дополнительное тестирование.
  • тестирование наиболее распространенных функций. Посмотрите свои журналы или определите, какие функции используются чаще всего и являются более важными. Проверьте эту функциональность более тщательно.
  • Пусть несколько пользователей, в том числе и вы, «проживут» на новом сервере несколько дней. Продолжительность времени должна зависеть от того, насколько радикальны изменения. (т.е. «вы должны быть первым тестировщиком»)
  • по возможности запускайте новую службу параллельно со старой. Если вы можете поместить прокси посередине и пересылать определенные запросы или пользователей, это может помочь.
  • работать в кластере с балансировкой нагрузки. Это похоже на предыдущее утверждение. Если вы можете запустить обе службы с балансировкой нагрузки, попробуйте это. Вы можете постепенно избавляться от старого сервиса, так как дела идут гладко.
  • Оставьте старые серверы на несколько недель или больше. Я хранил старые серверы месяцами, когда не был уверен, что мне придется их использовать. Выключите их или отсоедините сетевой кабель, чтобы убедиться, что на сервере нет скрытых зависимостей.
  • Убедитесь, что новый сервис справится с нагрузкой. Развертывайте его постепенно и отслеживайте производительность системы, постепенно перемещая больше трафика в новую систему.
  • делая что-то, убедитесь, что сбои видны и незамедлительно. вы хотите, чтобы сбои возникали на ранней стадии и их можно было легко идентифицировать.

Используйте DNS в своих интересах. Настройте обе службы, чтобы они отвечали на одно и то же DNS-имя, но чтобы DNS указывал на одно или другое (или на оба как на циклический). Используйте файл локальных хостов в Linux и Windows, чтобы переопределить DNS и иметь возможность проверить настройку перед развертыванием и после. Это также упрощает устранение неполадок после развертывания. Просто измените файл локальных хостов на старый сервер и посмотрите, не работает ли что-то на проблемной машине. Установите низкий TTL, чтобы можно было быстро вернуться в исходное состояние. Для этого можно использовать балансировщики нагрузки, такие как Cisco GSS. Я могу использовать iptables для извлечения определенного хоста с балансировкой нагрузки из пула.

Для Apache использование обратного прокси-сервера - хороший способ поэтапной миграции сайта. Для других используйте DNS, прокси-сервер или, возможно, поле iptables, чтобы дать вам варианты управления переходом.