Процесс работы над проектом при поддержке.

Учет задач мы ведем в bitrix24.
Простая структура.
Каждый проект - это группа.
Название группы - адрес проекта.
Задача - задача :)

Задачи маркируются тегами:

- support - общий тег для задач на поддержке. Задача может быть не отмечена таким тегом, тогда она не попадет в отчет;
- bugs - ошибки, которые произошли в результате предыдущих или текущих изменений, не по вине клиента, в отчете они не учитываются;
- feature - задачи на доработку, разработку нового функционала, т.е основные задачи по поддержке;
- hot fix - задачи, которые идут в работу в течении 2-3 часов после поступления;
- pool - задачи, попадающие в пул по общему времени прогноза.

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

Чтобы не запутаться во всем этом, при оказании услуги по поддержке сайтов, мы разработали собственное приложение для bitrix24 - "Монитор тех. поддержки".
В мониторе автоматически формируются группы pool задач, поднимаются задачи с подходящим к deadline сроком - формируется оперативная картина технической поддержки сайтов.

Краеугольный камень поддержки по часам - это сами часы.

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

• При накрутке долго не поработаешь - рано или поздно это становится понятным даже неподготовленному клиенту.
  Репутация намного важнее, основной поток клиентов приходит по рекомендации, "сарафанное радио" сработает быстро.
• Менеджер при приемке задачи старается ставить себя на место клиента.
  Дополнительно менеджер имеет доступ к системе контроля версий и может посмотреть фактические изменения по задаче в коде проекта.
  
  
• Также дополнительные "неоправданные" часы могут быть вызваны частой сменой контекста разработчика.
Это когда на погружение в задачу требуется время.
Например, 15 минут/час на изучение сложной поставленной задачи, после которых разработчика отвлекают на другую задачу или оценку.
Скорее всего, это время потребуется потратить снова. Мы стараемся избегать таких ситуаций. Задача поступила в работу - dev занят.

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

Задачи могут поступать в разном виде. Задача менеджера привести формулировку в тот вид, при котором у разработчика будет минимум вопросов.

Почему требуется оформить задачу, а не передавать ее на словах?

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

При описании ошибки важна схема воспроизведения.
Уже в заголовке задачи должна быть кратко изложена суть.
Заголовок "Ошибка в обратной связи" не информативен.
Заголовок "Страница контактов. Форма обратной связи. Отправка сообщения. Письмо приходит в нечитаемой кодировке." информативен

Общая структура задачи, которой руководствуется QA-менеджер:
- Что вижу;
- Что не так;
- Как должно быть;
- Вариант исправления;

Часто, точнее описать проблему помогает визуализация процесса воспроизведения.
Мы используем joxi для описания в виде изображения.
С помощью joxi, добавив комментарии прямо поверх скриншота, постановку целого ряда задач можно свести к заголовку и одной картинке.
В случае, когда воспроизвести проблему можно только последовательностью действий, удобнее записать анимированный gif, мы используем LICEcap для показа последовательного воспроизведения.

Для описания логики задач, общей схемы работы используются блок схемы и диаграммы состояний.
Для описания структур разделов, структур данных мы используем mindmaps. Результат в mindmap может быть как эскизом, так и детально проработанной структурой.

Чек листы.

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

Например, для верстки мы используем такой чек-лист

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

Cамо по себе регрессионное тестирование не вызывает затруднений при таком подходе.

Минус в таком подходе только один - время. Разработка и поддержка таких тестов требует больше времени.
Нужно соблюдать баланс. При частой смене сценариев или при отсутствии четких бизнес-процессов в проекте такой подход становится финансово неоправданным.

В качестве инструментов для автоматических тестов мы используем codeception и Selenium IDE.



Дополнительно перед публикацией изменений проект проходит монитор качества битрикс - это позволяет избежать грубых ошибок в рамках framework.

При поддержке проекта мы используем обновление через контроль версий.
Инструмент - git. Схема - gitflow.
Любые изменения происходят в рамках конкретной задачи.
В каждом commit указывается ссылка на задачу в трекере - любая измененная строчка кода имеет зафиксированное основание.
Всегда при анализе можно посмотреть в каком контексте произошли изменения, получить информацию об ответсвенных.

Изменение структуры данных фиксируются в файлах миграций.

У каждого разработчика есть своя копия проекта, с которой он работает, периодически вливая свои изменения в общую dev ветку.
Из dev ветки функицонал переводится в релизную ветку.
Перед публикацией изменений на production происходит слияние релизной и master ветки под контролем team лидера и qa менеджера,
с обязательным прохождением автоматических и ручных проверок.
На production попадают только проверенные изменения.

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

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

В подавляющем числе случаев на небольших проектах вирусная атака происходит в результате компрометации доступов.

Причины:
- незащищенное хранилище доступов;
- слабые пароли, подверженные bruteforce по словарям;
- вирусы на ЭВМ, на которых хранятся реквизиты доступов;
- ошибки серверных настроек;
- грубые нарушения безопасности при разработке проекта;

Основная цель атак - это размещение вредоносного кода в файлах проекта.
Это может быть размещение кода биржи ссылок, редиректы на сторонние ресурсы, код рассылки спама, xss-атаки на машины клиентов, дефейсы В проект могут быть встроены элементы удаленного управления backdoor shell.

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

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

Меры, которые мы принимаем при поддержке проекта, позволяют избегать подобных проблем:

• хранение доступов в безопасных хранилищах, типа keepass;
• настройка проактивной защиты;
• контроль административного доступа в cms - ограниченное кол-во пользователей, усиленная политика безопасности для административной группы, контроль "силы" паролей;
• запуск сканера безопасности при обновлениях функционала проекта;
• при использовании контроля версий, мы всегда видим изменения, которые были произведены в файлах, несанкционированные изменения сразу привлекают к себе внимание разработчиков;
• резервные копии позволяют спокойно восстановить утерянную информацию, если до этого дошло...

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

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

Если это не было сделано ранее, это всегда дает приятный эффект при относительно небольших трудозатратах:)
- атоматическое кеширование;
- закрытие всех пунктов в секции "проверка сайта" (то что можно сделать на хостинге);
- включение cdn;
- оптимизация индексов БД;
- настройка композита;
- смена тарифного плана shared-хостинга или перевод проекта на выделенный сервер.

Индекс производительности системы гарантировано поднимем > 100 при эталонных 30.

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

Нагрузочное тестирование ответит на вопросы:
- как быстро работает система;
- есть ли запас прочности и когда он кончится;
- где узкие места проекта.


В зависимости от задачи, сложности проекта мы можем использовать различный инструментарий.
Для тестирования в лоб, конкрентных разделов и страниц используется встроенный в битрикс инструмент тестирования нагрузки или apache benchmark.


Для большего приближения теста к реальной эксплуатации, формируются тестовые сценарии имитирующие реальное поведение пользователей (например, на основе логов посещений или конверсионных путей) с помощью JMeter.
В результате мы получим список "узких" мест проекта, которые будут профилированы и изучены детально.

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



Для отслеживания более подробного состояния системы во время нагрузки могут быть использованы zabbix или nagios.
В результате рассматривается возможность рефакторинга функционала, изменения серверных настроек для изменения полученных показателей.
В результате анализа часть функционала может быть переписана или переведена на другие языковые платформы, например nodejs.
Может быть пересмотрена общая архитектура системы, применен вертикальный шардинг для бд, когда отдельные таблицы отдельных модулей выносятся на отдельные сервера.

Отдельные части проекта могут быть вынесены на разные сервера. Часть задач может быть переведена в фон с помощью серверов очередей gearman или rabbitmq.
Часть данных, скорость доступа к которым критична, могут быть переведены в key-value хранилище. При рефакторинге фиксируется стабильные показатели до и после, для определения эффективности.

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