Лучше 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. Выясняем, всё ли в порядке с отображением сайта. Кроме внутренних процессов у сайта есть ещё и внешний вид — то, как он отображается у ваших клиентов. За внешний вид отвечает тема оформления. Как правило, при её разработке используется препроцессор — специальный язык программирования и инструментарий. И если в начале создания использовали препроцессор, а после работали без него, то в коде сайта будет трудно ориентироваться. Есть риск потери всех внесённых изменений, если их внесли не туда или препроцессор запущен неправильно. Препроцессоров много, поэтому мы выясняем, какой именно был использован и как продолжить с ним работать.
Надеюсь мне удалось доступно объяснить, почему онбординг так важен. По сути, это тот же приём смены, как на любом производстве. Мы ценим комфорт и скорость, ведь это нужно и нам, и клиенту. Четыре часа времени, чтобы потом спокойно работать в «полевых» условиях. Поверьте, оно того стоит.
Я правильно понимаю, что этот внушительный фронт работ исполняется и оплачивается заказчиком исходя из ориентира 4 нормочаса?
В целом да, минимум 4 часа. Но если по результатам диагностики нужны дополнительные работы, например устранение хаков, композеризация, исправление ошибок, покрытие тестами и т.д., то это время согласовывается и оплачивается отдельно.
Есть конечно исключения. Некоторые проекты так сложны, что за 2 часа не сделать рабочую копию с учетом всех интеграций и инфраструктуры.
Жаль клиенты не упомянуты, интересно было бы прочитать
Список наших клиентов тут https://drupal-coder.ru/happy-customers
Для такого объема работ хватает 4 часа? Чисто интуитивно по количеству занятых специалистов фактически получается, наверное, больше?
Вся диагностика и подготовительные работы по чеклисту укладываются обычно в 2 часа DevOps + 2 часа разработчика. Время работы менеджеров мы в данном случае в 4 часа не включаем и клиентам не выставляем, за счет Initlab делаем. Как уже писал выше, бывают исключения и дополнительные работы по согласованию с клиентом по результатам онбординга для приведения сайта в порядок.