Лучше 4 часа потратить и за 5 минут долететь: зачем нужен обязательный онбординг на сайте клиента

Привет! Меня зовут Сергей Синица. Я руковожу разработкой сайтов в компании Initlab. Мы занимаемся разработкой и поддержкой сайтов на Drupal, поддержкой инфраструктуры веб-проектов и DevOps. Для оказания качественной услуги внутри компании действуют множество процессов, правил, регламентов, инструкций, скрытых от внешних наблюдателей. Я решил приподнять завесу секретности и начать писать здесь заметки по мотивам наших внутренних инструкций. Надеюсь эти статьи будут интересны не только нашим клиентам, но и коллегам по цеху. Первый пост про онбординг Drupal-сайтов на поддержку.

Некоторые компании, когда берут сайты на поддержку, требуют переезда на свои серверы и свою инфраструктуру. Чаще всего они берут за эту работу деньги. Мы в Initlab поддерживаем сайты на Drupal на серверах наших клиентов, не требуем переезда, а значит и денег за этот переезд. Вместо этого у нас обязательный онбординг. В этой статье я объясню, для чего он нужен и какие преимущества даёт.

Многие заказчики пугаются, когда мы едва начали сотрудничать, а в задачах уже прописано 4 часа работ. Ещё и слово «онбординг» не совсем понятно, что это и зачем оно? Вот будут задачи по сайту, тогда и начнёте часы считать!

Всё очень легко объяснить на простой аналогии. Клиент — владелец корабля, на который он нанимает команду Initlab. А хорошая команда обязательно проверяет судно перед плаванием. Нужно устранить недочёты, навести порядок, принести своё оборудование и т.д. Вычёрпывать кружкой воду из трюма в середине пути можно, но разве не проще сразу залатать дыру и покойно плыть?

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

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

Задачи менеджеров

На наших менеджерах лежит не только будущая коммуникация с клиентом — им предстоит следить за общим порядком на проекте и контролировать все процессы. Их задачи во время онбординга:

  • Получить у клиента доступ SSH и в админку сайта, добавить логины и пароли в PassPack. Для спокойной работы нашим сотрудникам нужен безопасный доступ на сервер/хостинг — SSH. Мы стараемся работать через SSH и через консоль в целях безопасности и экономии времени. Затем менеджеры проверяют корректность паролей и заносят их в PassPack. Это зашифрованное хранилище паролей — такие данные мы никогда не пересылаем через почту или переписки. Только PassPack. Он гарантирует полную сохранность и конфиденциальность доступов к сайту.
  • Оформить проект в RedMine. RedMine — это система управления проектами, где расположены все задачи по сайту. Для клиента заводится аккаунт. Он может отслеживать затраченное рабочее время, присылать задачи, просматривать их приоритеты и сотрудников, которые над ними работают.
  • Завести задачу и проконтролировать её выполнение. Наши менеджеры обучают клиентов пользоваться RedMine и проверяют, всё ли работает корректно — уведомления приходят, задачи ставятся, разработчики их получают и выполняют. Дальнейшая слаженная работа с клиентом — наш приоритет.
  • Предложить дополнительные услуги: бекапы, администрирование, SEO-аудит. Нет, не в смысле навязать услуги. Наши менеджеры выясняют, что нужно вашему сайту и считаете ли это нужным именно вы. Сначала они проконсультируются с теми, кто будет работать с вашим сайтом, узнают дополнительные потребности сайта и предложат только необходимое.

Задачи DevOps, системных администраторов

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

  • Установить Drush на проде. Drush — это команда, с помощью которой быстро выполняются действия на сайте: сбросить кэш, подключиться к базе данных, включить-выключить модули. С помощью неё можно не заходить в админку каждый раз. Это упростит выполнение базовых задач и сэкономит часы, а значит и деньги клиента.
  • Настроить копию для демонстрации, сохранить доступы в PassPack. Мы всегда делаем рабочую копию сайта, обычно на своих серверах. Это необходимо для демонстрации промежуточных результатов работ — сдать сложную задачу по частям, согласовать изменения, чтобы не ломать основной сайт. Копию мы закрываем отдельным паролем заводим в PassPack чтобы обезопасить от утечек и обеспечить разработчикам постоянный доступ.
  • Настроить Git. Git — это система контроля и хранения версий файлов. Обязательный для всех разработчиков сервис. Все изменения с сайта фиксируются здесь — кто, когда, и что поменял. Чтобы в случае чего можно было откатить до старой версии или найти время внесения изменений.
  • Настроить CI. CI помогает быстро переносить изменения с копий сайта на его рабочую версию. Ручной перенос занимает куда больше времени и труда. Мы привыкли всё упрощать и ускорять, так легче для всех, включая клиента. Дополнительно настройка CI даёт возможность внедрить автоматическую проверку кода на соответствие стандартам Drupal и автоматизировать тестирование сайта при переносе изменений, а также актуализировать копию сайта по нажатию одной кнопки. Проверка кода и автоматическое тестирование необходимы на сложных проектах в больших командах разработки и не обязательны для всех. Но на масштабных проектах мы их крайне рекомендуем — так будет меньше багов и глюков. Внедряются они по согласованию с клиентом.
  • Архивация копии базы данных сайта перед началом работ. Сайт состоит из файлов и базы данных — в файлах картинки и код сайта, скрипты, а в базе данных — контент, пользователи, заказы магазинов. Перед началом работы копию базы данных мы архивируем и размещаем на архивном сервере, чтобы в случае форс-мажора можно было всё вернуть или сравнить с исходной версией. Все обнаруженные на копии сайта ошибки DevOps указывают в тикете для дальнейшего анализа разработчиками. Наши разработчики подключаются и помогают развернуть полноценную работоспособную копию сайта для разработки.
  • Постановка сайта на мониторинг. Эта услуга согласовывается с клиентом. Мы мониторим доступность сайта, наличие обновлений безопасности. Это необходимо, чтобы мы могли оперативнее исправлять проблемы на сайте.

Задачи разработчиков

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

1. Общая оценка качества сайта для упрощения дальнейшей оценки (кастом + Hacked + Schema + Watchdog). Это нечто похожее на диагностический осмотр врача. Разработчики изучают «анамнез» вашего сайта — что с ним было до этого, как он был создан и поддерживался ранее. На этом этапе есть 4 обязательных пункта проверки:

  • Делал ли кто-то кастомные модули. Drupal такая система, где можно пользоваться готовыми модулями, а можно писать свои. Как правило, 99% функционала можно реализовать на готовых решениях. Но многие разработчики об этом не знают, поэтому, что называется, изобретают велосипед. Мы проверяем сайт на наличие «самописных» частей, чтобы взять их под контроль, а в будущем, по возможности исправить.
  • Меняли ли разработчики до нас ядро Drupal. Иногда разработчики по разным причинам (не умеют, не хотят, верят, что так быстрее) вносят изменения сразу в ядро Drupal. Это как сломать руку и вместо того, чтобы поставить гипс, просто отрубить её. Поэтому наши разработчики проверяют ядро на наличие таких самовольных изменений в ядре Drupal. Это всё та же работоспособность сайта и сэкономленное в будущем время.
  • Меняли ли структуру базы данных. В этом случае могут не применяться обновления Drupal. Поэтому мы корректируем описание структуры базы данных, чтобы не было проблем с обновлениями безопасности. Либо документируем найденные изменения, чтобы учитывать в будущем.
  • Просматриваем Watchdog. Это встроенный модуль Drupal, который фиксирует ошибки. Если их много, то сайт будет работать медленно и дальнейшая его поддержка будет усложнена — придётся тратить время на выяснение причин впоследствии. Мы просматриваем страницы сайта на наличие ошибок в журнале Watchdog. Если всё выполнено по стандартам Drupal, то там не будет ничего лишнего. Если же работал непрофессиональный или неопытный разработчик, то в журнале Watchdog будут записи об ошибках. Иногда их слишком много, именно поэтому в них нужно разобраться сразу.

2. Изучаем состояние Composer и конфигурации для сайтов на Drupal 8+ и Features для Drupal 7. Всё это необходимо для того, чтобы:

  • не конфликтовать с тем, как работали на сайте до нас, иначе есть риск многое сломать;
  • быстро обновить или установить нужный модуль на сайт;
  • записать историю изменений настроек сайта;
  • быстро переносить изменения с копий сайта на основной сайт;
  • уменьшить количество ошибок (это делает робот, а не человек, который не совершенен).

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

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

Надеюсь мне удалось доступно объяснить, почему онбординг так важен. По сути, это тот же приём смены, как на любом производстве. Мы ценим комфорт и скорость, ведь это нужно и нам, и клиенту. Четыре часа времени, чтобы потом спокойно работать в «полевых» условиях. Поверьте, оно того стоит.

0
14 комментариев
Написать комментарий...
Henadzi Koltun

Я правильно понимаю, что этот внушительный фронт работ исполняется и оплачивается заказчиком исходя из ориентира 4 нормочаса?

Ответить
Развернуть ветку
Сергей Синица
Автор

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

Ответить
Развернуть ветку
Сергей Синица
Автор

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

Ответить
Развернуть ветку
Вера Пугачева

Жаль клиенты не упомянуты, интересно было бы прочитать

Ответить
Развернуть ветку
Сергей Синица
Автор

Список наших клиентов тут https://drupal-coder.ru/happy-customers

Ответить
Развернуть ветку
Вера Пугачева

Спасибо! А если не секрет для эвереста что делали?)

Ответить
Развернуть ветку
Сергей Синица
Автор

Поддержка сайта

Ответить
Развернуть ветку
Пётр Селфин

Для такого объема работ хватает 4 часа? Чисто интуитивно по количеству занятых специалистов фактически получается, наверное, больше?

Ответить
Развернуть ветку
Сергей Синица
Автор

Вся диагностика и подготовительные работы по чеклисту укладываются обычно в 2 часа DevOps + 2 часа разработчика. Время работы менеджеров мы в данном случае в 4 часа не включаем и клиентам не выставляем, за счет Initlab делаем. Как уже писал выше, бывают исключения и дополнительные работы по согласованию с клиентом по результатам онбординга для приведения сайта в порядок.

Ответить
Развернуть ветку
К р а с н о в о с т и . р ф

Всё тоже самое "глобальное обновление", "апдейт", только теперь в новой, более удобной "упаковке" - онбординг!
За слово обновление, к которому все привыкли уже много денег не сорвёшь, а вот за "онбординг" - это да!

Ответить
Развернуть ветку
Сергей Синица
Автор

А еще мы после обновлений тестируем сайты и веб-сервисы. Автоматически и вручную. А не просто накатил и запушил на прод :)

Ответить
Развернуть ветку
К р а с н о в о с т и . р ф

Конечно! Вы первые. Раньше до вас этого (тестируем) ни кто не делал, до и после апдейтов. О локальных серверах вообще ни кто не знал в наше время... (2000-2020 годы)
Даже не смотрели чего там произошло. Ткнули "Update" и ушли, забыли на годы...
Маркетинг ваше всё. Продолжайте. Вас ни кто не останавливает.

Ответить
Развернуть ветку
web user

Сколько вообще стоит техподдержка?
Я за месячную абонентку семерки беру 800 руб.
В эту сумму входит поддержка кодовой базы в актутальном состоянии, т.е. слежу за обновлением, обновляюсь драшем и скрипт на баше делает каждое утро свои бекапы базы и файлов сайта.
Какие то добавления функционала на сайта уже за доп. оплату.

Ответить
Развернуть ветку
Сергей Синица
Автор

У нас тарифицируется техподдержка серверов (виртуальных или физических). За техподдержку сайта отдельно сейчас денег не берем. Все работы по сайтам оплачиваются в почасовку. Цены лучше в отделе продаж уточнить для конкретного проекта: https://drupal-coder.ru/contacts

Бекапы у нас делает отдельный сервер бекапов с безопасным подключением по SSH и хранением срезов за 30 дней в облаке Amazon S3 чтобы на случай взлома или повреждения сервера бекапы остались невредимыми. Стоимость в год от объема данных зависит: https://drupal-coder.ru/backup

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

Ответить
Развернуть ветку
Читать все 14 комментариев
null