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

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

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

Проблема

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

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

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

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

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

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

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

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

На кого оформлен хостинг (?)
Доступ к аккаунтам (?)
Доступ к административной части проекта (?)
Возложить на прежнего Исполнителя перенос сайта на новый сервер (?)
Получить параметры сервера или хостинга, на котором в данный момент работает сайт (?)
Получить список скриптов и регулярных заданий, который запускаются в Cron (?)
Выяснить на кого активирована лицензия, если CMS коммерческая (?)
Запросить документацию на сайт (?)
Запросить список изменений, которые сделал старый исполнитель за время обслуживания (?)
Кто именно контролирует DNS-записи для домена сайта (?)
Какие записи есть в DNS (?)
Довести информацию о рисках до Заказчика (?)

Детали

 

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. Выяснить на кого активирована лицензия, если CMS коммерческая.

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

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

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

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

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

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

 

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

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

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

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

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

 

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

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

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

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

 

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

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

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

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

 

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

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

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

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

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

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

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

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

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

 

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

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

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

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

 

Выводы

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

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

 

Автор фото: fauxels

Технологии

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