Как вы изящно модернизируете критически важные системы до совершенно разрозненных систем?
За 12 с лишним лет моей карьеры мне еще предстоит преодолеть это препятствие, и я подозреваю, что ответ просто не прост или даже невозможен, поэтому я прошу всех присутствующих здесь поделиться своим опытом.
Скажем, вы сталкиваетесь с вопиющими проблемами, которые могут быть решены только путем перехода с одной платформы на другую - либо из-за ошибки в выборе платформы, которая была выбрана несколько лет назад, либо просто из-за того, что система изначально была разработана. Вы точно знаете, что накопившаяся с течением времени пропасть неизбежно будет означать, что почти невозможно будет проверить все вещи, которые, безусловно, приведут к адской технической поддержке - что, как мы все знаем, ведет к потере клиентов. Не то чтобы клиенты уже не жаловались на вопиющие проблемы, которые уже существуют!
Наилучший возможный способ, который я обнаружил до сих пор, - это, возможно, разработать план перехода, протестировать его на нескольких клиентах, протестировать на дюжине клиентов, протестировать на сотне клиентов, а затем, наконец, завершить переход для всех и молитесь, чтобы вы исправили все ошибки с этими первыми двадцатью и что побочные продукты животного происхождения не будут поражать вентиляционную систему самым впечатляющим способом.
Однако это не значит, что так или иначе не будет.
Скажем так, вы переходите с Exchange на Exim (или даже просто с Sendmail на Exim). Как вы справляетесь с этим?
1 ответ
Это сложный вопрос, который варьируется в зависимости от конкретной ситуации. Ключевые вопросы:
- иметь запасной план Что бы вы ни делали, имейте план, как быстро вернуться к старым системам. Если вы не можете сделать это, тогда требуется дополнительное тестирование.
- тестирование вашей наиболее распространенной функциональности. Посмотрите в своих журналах или определите, какие функции используются чаще всего и являются более важными. Проверьте эту функциональность более тщательно.
- Несколько пользователей, включая вас, "живут" на новом сервере несколько дней. Продолжительность времени должна зависеть от того, насколько радикальными будут изменения. (т.е. "ты должен быть первым тестером")
- Запустите новый сервис параллельно со старым, если это возможно. Если вы можете поставить прокси посредника и переадресовывать определенные запросы или пользователей, это может помочь.
- работать в кластере с балансировкой нагрузки. Это похоже на предыдущее утверждение. Если вы можете запустить обе службы с балансировкой нагрузки, попробуйте это. Вы можете постепенно избавиться от старого сервиса, поскольку все идет гладко.
- Держите старые серверы в течение нескольких недель или дольше. Я держал старые серверы месяцами, когда не был уверен, что мне придется их использовать. Выключите их или отсоедините сетевой кабель, чтобы убедиться, что на сервере нет скрытых зависимостей.
- Убедитесь, что новый сервис может справиться с нагрузкой. Постепенно развертывайте его и следите за производительностью системы, постепенно перемещая больше трафика в новую систему.
- при выполнении действий убедитесь, что сбои видны и немедленно. Вы хотите, чтобы сбои произошли рано и были легко идентифицированы.
Используйте DNS в ваших интересах. Настройте обе службы так, чтобы они отвечали на одно и то же DNS-имя, но чтобы DNS указывал на один или другой (или оба в циклическом порядке). Используйте файл локальных хостов в Linux и Windows, чтобы переопределить DNS и иметь возможность проверить настройки до развертывания и после. Это также облегчает поиск неисправностей после развертывания. Просто измените файл локальных хостов на старый сервер и посмотрите, не все ли на проблемной машине. Установите низкий уровень TTL, чтобы обеспечить быстрый откат. Для этого можно использовать балансировщики нагрузки, такие как Cisco GSS. Я могу использовать iptables, чтобы вывести конкретный хост с балансировкой нагрузки из пула.
Для Apache использование обратного прокси-сервера - это хороший способ миграции сайта по частям. Для других: используйте DNS, прокси-сервер или, возможно, поле iptables, чтобы указать варианты управления переходом.