Как перенять web-проект. Чек-лист для пошагового перехода

Как перенять web-проект. Чек-лист для пошагового перехода

О чём поговорим:

Проблема

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

В этот раз сразу что-то пошло не так и простого бесшовного перехода не получилось.

Для того, чтобы не вставать на те же «грабли» ещё раз, решено было записать детали проблемы и сделать работу над ошибками. Результат превратился в чек-лист для дальнейшей работы. 

Каждый пункт содержит описание и объяснение, почему именно это важно, какие могут быть «подводные камни» и какие сложности могут возникнуть.

Если появится что-то новое, чек-лист будет расширяться и дополняться.

Немного терминов

  • Заказчик — организация, компания, государственный орган, физическое лицо и т.п. Словом тот человек, ради интересов которого мы сейчас начинаем действовать.
  • Исполнитель — в этом материале тот, кто принимает сайт на обслуживание.
  • Прежний Исполнитель — в этом материале компания или человек, которые ранее работали с сайтом или поддерживали его.

Чек-лист по приёмке веб-сайта, интернет-магазина или портала.














Детали

 

1. Выяснить на кого оформлен хостинг

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

Встречаются веб-проекты, у которых хостинг оформлен не на компанию-заказчика или физическое лицо (если сайт принадлежит частному заказчику). Хостинг может быть оформлен на компанию/фрилансера/частника, который делал сайт.

На этапе обсуждения проекта могла быть договорённость в стиле: «Мы в этом ничего не понимаем, вы всё сами сделайте, а мы уже примем работу». 

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

Итак, выясняем у Заказчика:

  1. На кого оформлен хостинг?
  2. Есть ли доступ в личный кабинет хостинга?
  3. Есть ли у заказчика договор на хостинг?
  4. Оплаты происходят непосредственно в хостинг или: «Мы всё платим там нашему программисту, а он всё делает»

Что делать, если контакта с исполнителем нет?

Если Заказчик никак не контактирует с прежним Исполнителем, задача может немного осложниться. В таких ситуациях не стоит рисковать. Нужно действовать последовательно, быстро и осторожно:

  • Выясняем, есть ли у Заказчика какие-то резервные копии. Сгодятся любые, даже старые.
  • Если резервных копий нет и нет доступа к хостингу, проверяем доступы к сайту. Большинство ходовых систем управления сайтами имеют в своём составе встроенные средства для создания резервных копий. Если такая возможность есть, делаем резервную копию.

Здесь у нас есть материал о том, как можно попытаться понять, на каком хостинге сейчас работает сайт (статья откроется в новом окне):  

 

2. Выяснить наличие доступов к аккаунтам

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

Нужно проверить:

  • Доступ в личный кабинет хостинга — если туда есть доступ, на отсутствие остальных можно не обращать внимание. Всё можно сбросить через конфигурационные файлы, консоль управления базой данных или хостингом.
  • Доступ к консоли управления доменом — нужен, если домен приобретён отдельно и не отображается в личном кабинете хостинга. Может потребоваться при изменении DNS-записей. Наличие такого доступа важно,прежде всего, самому заказчику. Домен должен принадлежать ему, а не какому-то третьему лицу.
  • Доступы по FTP, доступы к СУБД — не очень большая проблема. Меняются либо через консоль управления хостингом, либо через консоль виртуального/выделенного сервера.

 

3. Выяснить наличие доступов в административную часть

Почему это важно: наличие логина и пароля экономит время. Если они есть — хорошо. Только после получения от Заказчика их нужно сразу проверить. Бывает так, что Заказчик не проверил при получении, а они неверные. 

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

 

4. Возложить на прежнего исполнителя перенос сайта на новую площадку

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

Если новый Исполнитель переносит проект своими силами, есть очень большой риск, что все негативные моменты, которые могли возникнуть в результате переноса, будут восприняты Заказчиком, как неумение или недоработки именно нового Исполнителя.

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

Часто ситуация выглядит так, что веб-проект или другая платформа работает не на виртуальном хостинге, а на выделенном сервере. Это ещё больше усложняет ситуацию:

  1. Прежний Исполнитель может не передать документацию на проект. Невозможно определить связи, зависимости пакетов и другие тонкости сервера.
  2. Если проект работает на виртуальном хостинге, но требует передачи, лучше всего будет зарегистрировать точно такой же хостинг у того же поставщика услуг. Это может снизить риск появления проблем при переезде.
  3. На виртуальном сервере могут быть развёрнуты дополнительные пакеты для операционной системы, например, для работы с SFTP через скрипты. Случаются ситуации, когда на новом виртуальном сервере вообще нет возможности установить пакеты в обычном режиме. Потребуется привлечение дополнительных системных администраторов или расходы на услугу администрирования сервера у поставщика виртуального сервера.
  4. В иностранных компаниях часто DNS-записи для домена контролируются не из России. Потребуется долгая переписка для замены name-серверов, особенно при замене хостинга или поставщика услуг

Вывод: если есть возможность — перекладываем заботы по «переезду» проекта на плечи прежнего Исполнителя.

 

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

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

Если подобрать такой же хостинг нет возможности или есть иные причины, стоит обратить внимание на следующее:

  1. Прежде всего — берегите собственную репутацию. Все неверные шаги, некорректный выбор и любые ошибки будут отнесены на ваш счёт. Хорошо, если будет демо-период на хостинге и попытки «переехать» будут предприниматься в этот промежуток. А когда Заказчик уже оплатил деньги за другой хостинг, обратного пути не будет, придётся работать с тем, что есть.
  2. Проверить, есть ли на виртуальном хостинге или виртуальном сервере все необходимые для проекта пакеты.
    Пример из жизни — в проекте, на основе которого появилась эта статья, требовался пакет для работы с SFTP-сервером. Уже в процессе перемещения площадки вдруг выяснилось, что так просто установить нужный пакет не получится. Поддержка хостинга сразу предложила, купить пакет по администрированию сервера с расширенными возможностями. Нам удалось ситуацию быстро исправить, благодаря большому опыту нашей группы системного администрирования. Но ситуация могла сложиться по другому.
  3. Производительность серверов у разных провайдеров, даже при одинаковом «железе» может быть разная. Мы сталкивались с ситуациями, когда на более мощном по параметрам сервере, проект работал заметно медленнее. Замедление работы обязательно скажется на общем фоне, особенно если это какой-то e-commerce проект и требуется минимальное время отклика на любое действие пользователя.
  4. Многие хостинговые компании могут сами развернуть проект. Этим можно смело пользоваться, по крайней мере, в случае каких-то проблем развёртывания, причины можно будет хоть как-то обосновать.

Если можете, берите всё точно такое же, как было.

Если нет — максимально похожее и обязательно с проверкой совместимости.

 

6. Получить список скриптов и регулярных заданий, который запускаются в Cron

Почему это важно: на регулярные задания могут быть частями бизнес-процессов, загружать данные, обновлять остатки, передавать заказы и т.д.

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

 

7. Какие есть дополнительные модули (доставка, оплата и т.д.

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

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

 

8. Выяснить на кого активирована лицензия, если CMS коммерческая.

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

Проблема проявится, когда вы предпримите попытку изменить регистрационные данные лицензии. И вот тут часто, ничего нельзя сделать и придётся оплачивать полную версию продукта вновь.

Пример из жизни — в одном из проектов лицензия была приобретена не на организацию, которая заказала сайт, а на генерального директора, который в тот момент управлял организацией. И вот незадача: генеральный директор ушёл из компании, причём, ушёл не «гладко», а с определённым скандалом. И у компании внезапно возникли риски — по правилам лицензионного соглашения, генеральный директор мог отозвать лицензию, получить доступ к сайту. Компания оценила риски и приняла решение купить новую лицензию — остановка или проблемы с сайтом могли обернуться миллионными убытками, что не шло ни в какое сравнение со стоимостью лицензии на систему управления.

Дело можно поправить, если лицензия была зарегистрирована на корпоративный почтовый ящик. Администратор почтовых ящиков просто разблокирует (или заново создаёт) почтовый ящик с точно таким же адресом. И уже после этого производится сброс паролей от личного кабинета, в котором хранится лицензия. После этих процедур можно вступить в переписку с технической поддержкой или отделом лицензирования и спокойно, без рисков, провести переоформление. 

Но если лицензия зарегистрирована на чей-то персональный мейл, остаётся только вариант договориться.

А если договориться невозможно — купить новую лицензию.

 

9. Запросить документацию на сайт

Почему это важно: документация это очень важная часть любого проекта. И документацию нужно обязательно получить от старого Исполнителя.

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

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

Если нет документации, нужно просить техническое задание на разработку. Если и его нет — документ с описанием функционального дизайна, бэклог, по которому прежний Исполнитель вносил корректировки и дорабатывал проект. Любые документы, которые могут хоть как-то описать сайт, его функционал и код, будут крайне полезными.

 

10. Запросить список изменений, которые были выполнены на сайте в процессе эксплуатации

Почему это важно: список изменений (бэклог) поможет выявить те изменения, которые были сделаны на сайте отдельными работами. Знание изменений поможет в нестандартных ситуациях, внезапных «багах» или недокументированных «возможностях» сайта.

Выгрузка может быть из Trello или любой другой системы, в которой ведётся учёт изменений. Если изменения согласуются, их можно найти в документах и актах выполненных работ.

Может так случиться, что список получить не удастся. Такое бывает, когда старый Исполнитель не ведёт список.

 

11. Кто именно контролирует DNS-записи для домена сайта

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

Особенно внимательно нужно отнестись к этому пункту если:

  • Домен и хостинг находятся на разных аккаунтах
    Подобная ситуация довольно частая, когда хостинг или сервер размещается у прежнего Исполнителя, или когда сначала был куплен домен, а потом уже были куплены услуги хостинга. Стоит обратить внимание и на тот факт, что у некоторых крупных российских хостеров управление доменной зоной оплачивается отдельно. В таких случаях делегирование управления доменной зоной будет вынужденной процедурой.
  • Доменные зоны контролируются иностранными администраторами
    Довольно типичная ситуация для больших организаций, особенно международных с филиалами и представительствами в России. Если брендом владеет иностранная компания, домены, в том числе и в зоне .ru будут находится под иностранным контролем. Любые изменения в таких ситуациях будут происходить через переписку с иностранными администраторами.
  • Для обработки почты используются внешние почтовые серверы типа «Яндекс», « Mail.ru» и подобные.
    Какой бы ни был внешний сервис для обработки почты — это означает лишь одно: в зоне прописана MX-запись для функционирования почты. И эта запись может так же быстро «пропасть» из зоны, как нерадивый Исполнитель. И тогда у клиента перестанет работать корпоративная почта. Для многих организаций корпоративная почта это основной инструмент коммуникаций. Не стоит навлекать на себя беду, лучше всё несколько раз проверить и задать вопросы ответственному представителю Заказчика, прежде чем совершать какие-либо действия с доменами и их записями.
  • Используются какие-то дополнительные записи в зоне.
    Такими записями могут быть тестовые записи для подтверждения домена или владения сайтом для сторонних сервисов, записи для почтовых рассылок и подобные.

 

12. Какие записи есть в DNS

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

Можно попробовать командой посмотреть состав зоны, чтобы самостоятельно разобраться с записями, но, как правило, такие опции на стороне DNS-сервера отключены из-за соображений безопасности.

Нужно задать наводящие вопросы представителю Заказчика:

  • Как они получают почту: веб-интерфейс или почтовый клиент? Если веб-интерфейс, какой у него адрес? Если почтовый клиент, какой адрес SMTP-сервера?
    По адресам веб-интерфейса или SMTP-сервера можно понять как и кто обрабатывает почтовый поток. Если это внешние публичные сервисы, значит есть MX-запись. Если это внутренние серверы, возможно, в организации есть системный администратор и он контролирует домен. Даже если не контролирует, с ним можно обсудить особенности структуры и получить точные технические комментарии.
  • Используются ли какие-то дополнительный сервисы? Антиспам, рассылки, защита от DDOS?
    Для работы дополнительных служб может потребоваться создать запись в доменной зоне. Этот вопрос стоит детально обсудить. Можно поговорить или сделать запрос в службы технической поддержки подобных сервисов, для того, чтобы уточнить типы и содержимое записей, которые им требуются.

Пример из практики: как незаметно «потерялся» почтовый обмен.

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

Проблема скрывалась в мелочах: вся переписка, в том числе, с представителем Заказчика происходила через электронную почту, а как выяснилось уже при ретроспективе проблемы — доменная зона для корпоративной почты была в зоне .com. Российская версия сайта работала в зоне .ru

Ну и конечно же, при изменении name-серверов никто и не вспомнил о том, что в зоне есть MX-запись для того, чтобы обслуживать технические почтовые ящики, от имени которых сайт присылал уведомления клиентам. И вот как раз эти-то почтовые ящики были в домене зоны .ru. Внутри организации никто не получал писем от сайта: отдел e-commerce постоянно работал с админкой и отслеживал заказы там, директор направления получал копии писем на свой корпоративный ящик. После изменения name-серверов клиенты и покупатели просто перестали получать письма с подтверждением заказов, служебные письма о для восстановления пароля и другие сервисные сообщения. И проблема была обнаружена только спустя несколько дней, по причине отсутствия контроля и деталей технической реализации со стороны Заказчика. 

 

13. Корректно ли происходит перезагрузка

Почему это важно: важно, особенно если сервер виртуальный.

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

 

14. Довести информацию о рисках до Заказчика

Почему это важно: нужно как можно раньше известить Заказчика о проблемах и рисках, которые были обнаружены в результате проверки по чек-листу.

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

Главный источник конфликтов с клиентами — несовпадение ожидания и реальности. Чтобы конфликтов было меньше, важно постоянно говорить клиенту, что происходит и когда что будет. Не надо молча делать блестящую работу: лучше делать средне, но обо всём ставить в известность.
Книга «Бизнес без MBA» от Тинькофф

 

Выводы

Эта заметка не претендует на полноту или уникальность. Это ретроспектива ситуации.

Мы постарались проделать работу над ошибками, сделать выводы и поделиться тем чек-листом, который получился у нас. 

 

Автор фото: fauxels

Технологии

Техническое обслужвание сайта