- Определение уровня sla
- Учет и выполнение задач
- Контроль качества выполнения
- Контроль изменений кода проекта
- Обеспечение защиты от вирусов
- Обеспечение производительности проекта
- Обеспечение резервного копирования проекта
В общем случае, уровень поддержки (sla) определяется такими характеристиками, от которых зависит когда задача пойдет в работу:
Например, если по sla время начала работ - 5 дней, а максимальный пул работ - 10 часов, общее время прогноза - 2 часа, то задача будет запущена в работу если:
Учет задач мы ведем в bitrix24.
Простая структура.
Каждый проект - это группа.
Название группы - адрес проекта.
Задача - задача :)
При выполнении каждой задачи работает таймер.
Общее время по задачам в конце месяца идет в отчет. На основе часов выставляется счет за поддержку.
Краеугольный камень поддержки по часам - это сами часы.
Первый вопрос клиента, который возникает - как можно быть уверенным в том, что таймер не был включен, когда работа фактически не велась?
Ответ - никак :)
Один из определяющих моментов в показателе качества выполнения задачи - это соответствие результата выдвинутым требованиям.
Чем понятнее и подробнее задача поставлена, тем понятнее как сделать задачу качественно.
Задачи могут поступать в разном виде. Задача менеджера привести формулировку в тот вид, при котором у разработчика будет минимум вопросов.
Преимущество перед простыми чек-листами:
Например сценарий и признаки успешного выполнения могут быть такими:
При поддержке проекта мы используем обновление через контроль версий.
Инструмент - git. Схема -
Любые изменения происходят в рамках конкретной задачи.
В каждом commit указывается ссылка на задачу в трекере - любая измененная строчка кода имеет зафиксированное основание.
Всегда при анализе можно посмотреть в каком контексте произошли изменения, получить информацию об ответсвенных.
Изменение структуры данных фиксируются в файлах миграций.
У каждого разработчика есть своя копия проекта, с которой он работает, периодически вливая свои изменения в общую dev ветку.
Из dev ветки функицонал переводится в релизную ветку.
Перед публикацией изменений на production происходит слияние релизной и master ветки под контролем team лидера и qa менеджера,
с обязательным прохождением автоматических и ручных проверок.
На production попадают только проверенные изменения.
Правки на production непосредственно в шаблонах, компонентах, модулях практически исключены.
При таком подходе снижается риск некомпетентного и неконтролируемого изменения в коде, приводящего к возникновению фатальных ошибок, останавливающих работу проекта.
Изменения контента клиентом, изменения статей, текстовой информации, описание товаров могут проводиться непосредственно на production без необходимости прохождения обязательного flow.
Перед началом поддержки все подобные действия регламентируются.
Для seo специалистов клиента мы предоставляем отдельную dev копию на своих серверах и следим за изменениями, которые они производят.
В подавляющем числе случаев на небольших проектах вирусная атака происходит в результате компрометации доступов.
Причины:
- незащищенное хранилище доступов;
- слабые пароли, подверженные bruteforce по словарям;
- вирусы на ЭВМ, на которых хранятся реквизиты доступов;
- ошибки серверных настроек;
- грубые нарушения безопасности при разработке проекта;
Основная цель атак - это размещение вредоносного кода в файлах проекта.
Это может быть размещение кода биржи ссылок, редиректы на сторонние ресурсы, код рассылки спама, xss-атаки на машины клиентов,
При пассивном отношении результаты атаки могут быть выявлены далеко не сразу, атакующему выгодно не проявлять заметной активности.
Вам могут об этом сообщить клиенты, получив уведомление от десктопных антивирусов.
В поисковиках проект может быть отмечен как содержащий вредоносный код.
Производительность проекта может существенно снизиться - время генерации страниц увеличится.
Негативные последствия могут быть различные - от потери лояльности посетителей веб сайта и снижения позиций в поисковиках, до потери самого проекта :(
Меры, которые мы принимаем при поддержке проекта, позволяют избегать подобных проблем:
Вопрос производительности может возникнуть сразу при начале поддержки проекта (проблема очевидна), так и в процессе эксплуатации, когда есть прогноз на эффект от маркетинговых действий в виде скачка посещаемости проекта.
Обеспечение производительности - это всегда комплекс мер.
В части случаев, на проектах с небольшой посещаемостью, проблема решается правильной настройкой уже встроенного в 1с-битрикс инструментария для обеспечения производительности.
Если это не было сделано ранее, это всегда дает приятный эффект при относительно небольших трудозатратах:)
- атоматическое кеширование;
- закрытие всех пунктов в секции "проверка сайта" (то что можно сделать на хостинге);
- включение
- оптимизация индексов БД;
- настройка композита;
- смена тарифного плана shared-хостинга или перевод проекта на выделенный сервер.
Индекс производительности системы гарантировано поднимем > 100 при эталонных 30.
В случае, если проблема требует более основательного подхода и только когда имеет реальную потребность, например, подтвержденную зависимость и влияние на бизнес показатели проекта (процент отказов, конверсия или промежуточные маркетинговые метрики ), мы проводим детальный анализ проекта.
В результате которого возникает план работ, по повышению производительности.
Нагрузочное тестирование ответит на вопросы:
- как быстро работает система;
- есть ли запас прочности и когда он кончится;
- где узкие места проекта.
В зависимости от задачи, сложности проекта мы можем использовать различный инструментарий.
Для тестирования в лоб, конкрентных разделов и страниц используется встроенный в битрикс инструмент тестирования нагрузки или apache benchmark.
Для большего приближения теста к реальной эксплуатации, формируются тестовые сценарии имитирующие реальное поведение пользователей (например, на основе логов посещений или конверсионных путей) с помощью JMeter.
В результате мы получим список "узких" мест проекта, которые будут профилированы и изучены детально.
Для профилирования мы используем
Это отлично зарекомендовавший себя профилировщик, который можно использовать даже на production.
Анализ происходит в рамках одного хита. Анализируется стек вызова.
Анализируется кололичество вызвов функций, время исполнения, потребляемый ресурс.
Для отслеживания более подробного состояния системы во время нагрузки могут быть использованы zabbix или nagios.
В результате рассматривается возможность рефакторинга функционала, изменения серверных настроек для изменения полученных показателей.
В результате анализа часть функционала может быть переписана или переведена на другие языковые платформы, например nodejs.
Может быть пересмотрена общая архитектура системы, применен вертикальный шардинг для бд, когда отдельные таблицы отдельных модулей выносятся на отдельные сервера.
Потеря информации - это неприятно.
Резервные копии проекта в облаке битрикс, на сервере клиента, наших серверах, в удаленном репозитрии позволяют спокойно восстановить утерянную/поврежденную информацию.
При поддержке разрабатывается регламент действий при возникновении ситуации, требующей "отката".