Битрикс - сложная система с множеством нюансов, горой настроек и множеством требований. С одной стороны это дает большие возможности. С другой стороны возрастают риски каких-то недоработок, вследствие упущения каких-то деталей.
Монитор качества - инструмент для проверки качества выполненного проекта перед сдачей его заказчику.
Он позволяет пройти по основным пунктам и проверить - ничего ли не забылось перед сдачей проекта. Например: у кого-то тестовые данные отображаются на сайте, где-то права не настроены, почта заблокирована на время теста...
На сентябрь 2021 года имеется 65 тестов в следующих категориях:
- Интеграция дизайна и разработка
- Безопасность
- Производительность
- Размещение на хостинге
- Сдача проекта
Разберемся со всеми пунктами по порядку.
Интеграция дизайна
Сайт проекта добавлен и корректно настроен (QD0010).
Описание
Сайт проекта добавлен и корректно настроен: выбран тип многосайтовой конфигурации, настроены доменные имена, кодировка сайта, формат даты и времени, язык.
Как тестировать
Проверяем настройки сайта(ов) проекта: "Рабочий стол > Настройки > Настройки продукта > Сайты > Список сайтов > Параметры сайта"
- У сайта должно быть понятное название, позволяющее отличить его от других сайтов проекта. "Site1" - пример не очень удачного названия.
- Тестовые доменные имена должны быть удалены.
- "Язык", "Формат даты", "Формат даты и времени", "Кодировка" - должны соответствовать ТЗ и учитываться при отображении информации в публичной части сайта.
- "URL сервера" и "E-Mail адрес по умолчанию" должны соответствовать ТЗ. Эти параметры Используются для идентификации отправителя в почтовых сообщениях проекта.
- Тестовые шаблоны должны быть удалены из списка шаблонов. Названия шаблонов должны отражать их предназначение: "Главная страница", "Страница для печати" и т.п. "Шаблон 1" - пример не очень удачного названия шаблона. Задание поля "Тип условия" должно однозначно определять, когда оно применяется. (Хотя иногда "сложные" условия будут заданы на языке PHP.)
Созданы и настроены шаблоны сайта (QD0020).
Описание
После согласования дизайна веб-проекта обычно следует этап верстки. После завершения верстки проводится интеграция верстки в шаблоны платформы Битрикс (а также шаблоны компонентов).
Как тестировать
После согласования дизайна веб-проекта обычно следует этап верстки. После завершения верстки проводится интеграция верстки в шаблоны платформы Битрикс (а также шаблоны компонентов).
Проверяем настройки шаблонов проекта: "Настройки > Настройки продукта > Сайты > Шаблоны сайтов > Настройки шаблона сайта". Для проверки требуются начальные знания языка разметки HTML и PHP.
- У шаблона должно быть понятное название, позволяющее отличить его от других шаблонов проекта. "Template1" - пример не очень удачного названия.
- В начале шаблона в элементе "" должна быть задана версия HTML, соответствующая ТЗ. Это очень важный элемент, влияющий на качество визуализации веб-сайта и его работу в текущих и будущих версиях браузеров.
- В элементе "<HTML>" должен быть задан язык шаблона, который берется из настроек сайта, например: <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="<?=LANGUAGE_ID?>" lang="<?=LANGUAGE_ID?>">
- Автоматизирована ли установка заголовка страницы, что позволит менять название веб-страниц сайта и заголовок браузера через административный интерфейс или "Эрмитаж", например: <title>$APPLICATION->ShowTitle()?></title>
- Автоматизирован ли вывод основных метатэгов веб-страницы (keywords, description, content-type, robots), стилей и скриптов, например: <?$APPLICATION->ShowHead();?>
- Задана ли "иконка" сайта, например:
<link rel="shortcut icon" type="image/x-icon" href="<?=SITE_TEMPLATE_PATH?>/favicon.ico" /></li> - Подключается ли автоматически административное меню, необходимое для управления сайтом, например: <body>…<div id="panel"><?$APPLICATION->ShowPanel();?></div>
- Номер телефона, год копирайта в подвале сайта и другие "включаемые области" - можно отредактировать во всплывающем окне над сайтом или через административный интерфейс без помощи программиста.
- В шаблоне сайта обозначены рекламные области, которые можно отредактировать без помощи программиста или через административный интерфейс: "Сервисы > Реклама > Баннеры".
- Вся "сложная" верстка веб-сайта должна быть убрана в верхнюю и нижнюю части шаблона. В рабочей области (WORK_AREA) оставлена только "простая" верстка, которую невозможно "сломать" редактору контента через визуальный редактор. Особенно это важно для главной страницы проекта.
- Стили сайта и стили шаблона (отображаемые на одноименных вкладках) - должны быть оформлены аккуратно и подробно документированы.
Если ваш шаблон расположен в папке local, то тут автотест выдаст ошибку. В этом случае вручную проверьте все рекомендации от Битрикс. В поле комментария укажите, что шаблон в папке /local/ и отметьте тест пройденным.
Настроены все типы меню (QD0030).
Описание
Настроены все типы меню. Рекомендуется использование стандартных компонентов (с кешированием) – «bitrix:menu».
Как тестировать
Проверяем настройки меню и свойств страниц и разделов: "Настройки > Настройки продукта > Настройки модулей > Управление структурой", вкладка "Настройки", подраздел "Настройки для сайтов".
- У каждого типа меню имеется понятное название, позволяющее отличить его от других типов меню проекта, например "Главное меню", "Левое меню". "menu1" - пример не очень удачного названия, которое усложнит доработку и поддержку проекта.
- У каждого типа свойств имеется понятное название, однозначно определяющее ее роль в конфигурации проекта, например "Описание", "Ключевые слова". "Prop1" - пример запутывающего названия свойства.
Рекомендуется использование стандартных компонентов (с кешированием) - "bitrix:menu", потому-что они максимально оптимизированы под высокие нагрузки и поддерживаются в актуальном состоянии через систему обновлений:
Поддерживаются технологии «Эрмитаж» (QD0040).
Описание
Поддерживается возможность редактирования объектов шаблона сайта в публичной части с помощью технологий "Эрмитаж" (не заходя в административный раздел).
Как тестировать
Технология "Эрмитаж" позволяет редактировать веб-проект не заходя в административный раздел - как бы "паря" над сайтом и настраивая параметры во всплывающих диалоговых окнах. Это позволяет более эффективно управлять информацией, т.к. не требуется переключаться в административный раздел.
Необходимо предусмотреть возможность редактирования контента и объектов "над сайтом" на ранних этапах верстки и интеграции верстки в шаблоны веб-сайта. Интерфейсы "Эрмитаж" предназначены для использования во всех популярных браузерах.
Технология Эрмитаж в Битрикс - это меню администратора над сайтом с множеством кнопок.
Если вы правильно добавили в шапку шаблона $APPLICATION->ShowPanel() и $APPLICATION->ShowHead(), то эрмитаж у вас должен работать.
Для всплывающих кнопок внутри сайта есть отдельный пункт Настроены интерфейсы «Эрмитаж» (QS0030).
Настроена цепочка навигации (QD0050).
Описание
Настроена цепочка навигации (строится автоматически). Рекомендуется использование стандартных компонентов – «bitrix:breadcrumb».
Как тестировать
Во многих веб-проектах используется цепочка навигации, отображающая текущий уровень посетителя в иерархии контента веб-сайта.
Обычно контент веб-проекта хранится в файловой структуре сервера, папки и файлы которой соответствуют разделам и элементам цепочки навигации (дополнительно в файловой системе сохраняется метаинформация о названии страниц и разделов на выбранном языке веб-сайта). Таким образом, создание веб-страницы в определенной папке веб-сервера автоматически определяет ее положение в цепочке навигации.
При необходимости, в дерево контента веб-проекта, соответствующее структуре файлов и папок веб-сервера, могут добавляться виртуальные динамические деревья - например, дерево каталога из инфоблока. В этом случае, при просмотре элемента каталога, в цепочке навигации показывается логический путь к элементу, состоящий из реальной (из файловой системы) и виртуальной (из иерархии инфоблока) частей.
Важно понимать логику работы цепочки навигации и учитывать ее особенности при проектировании веб-системы. Для создания цепочки навигации, автоматически строящей логический путь к веб-странице или объекту - рекомендуется использование стандартного компонента - "bitrix:breadcrumb".
- Создаются разделы и веб-страницы на разных уровнях иерархии контента веб-проекта. Цепочка навигации должна автоматически строить корректный путь к веб-странице/разделу.
- Создаются разделы и элементы в инфоблоке, структура которого отображается в логическую структуру контента веб-проекта, например каталога. Цепочка навигации должна автоматически строить корректный путь к элементу инфоблока.
- Необходимо проверить, что можно отредактировать названия частей пути цепочки навигации без помощи программиста.
- Необходимо удостовериться, что определена логика "кликательности" частей пути цепочки навигации. Т.е. если на любой части цепочки навигации можно "кликнуть" - должна открываться корректно оформленная страница (возможно обзорная) раздела веб-сайта. Если такой страницы нет, то иногда блокируют возможность нажатия на часть пути цепочки навигации и т.п.
Настроено формирование карты сайта (QD0060).
Описание
Настроено формирование карты сайта (строится автоматически). Рекомендуется использование стандартных компонентов – «bitrix:main.map».
Как тестировать
Карта сайта веб-проекта на платформе Bitrix Framework обычно строится автоматически на базе настроек типов меню ("Настройки> Настройки продукта > Настройки модулей > Главный модуль", вкладка "Настройки", подраздел "Карта сайта"). Важно обеспечить прозрачный механизм редактирования и настройки меню данных типов - например, описать логику формирования карты сайта в ТЗ, включив описание настройки динамических подразделов карты сайта (каталоги и т.п.).
Для создания карты сайта рекомендуется использовать стандартный компонент "bitrix:main.map".
Необходимо удостовериться, что карта сайта строится автоматически и проверить, как можно менять разделы и элементы карты сайта без привлечения программиста - путем редактирования меню, инфоблоков и т.п.
bitrix:main.map просто выводит в одном месте ссылки на все страницы сайта. Выглядит не очень красиво, поэтому используется редко. Если на вашем сайте такой страницы не предусмотрено - укажите в комментарий что страницы не требуется. Тест отметьте пропущенным.
Администратор сайта управляет свойствами веб-страниц и разделов (QD0070).
Описание
Свойства страниц и разделов, редактируемые администратором, позволяют управлять характеристиками веб-страниц проекта - названием, описанием, мета-тегами и т.п.
Как тестировать
Свойства веб-страниц и разделов позволяют управлять их различными характеристиками: название, описание, ключевые слова, название раздела в цепочке навигации. Также, свойства веб-страниц и разделов могут использоваться для управления другими характеристиками веб-сайта, например отображением блока информации в зависимости от установленного свойства раздела и т.п. Важно описать эти свойства, чтобы администратору веб-проекта и сотрудникам, управляющим веб-проектом, было ясно, где настраивается каждое свойство, как и на что оно влияет.
Специальные свойства, управляющие логикой отображения блоков, например, рекомендуется также описать в технической документации к веб-проекту.
Необходимо удостовериться, что свойства веб-страниц и разделов имеют понятные названия: "Настройки > Настройки продукта > Настройки модулей > Управление структурой/вкладка 'Настройки'/подраздел 'Настройки для сайтов/Типы свойств'", а предназначение свойств (где они используются и как) описаны в технической документации к веб-проекту.
Свойства из коробки настраивать не требуется, если в шаблоне вы использовали $APPLICATION->ShowHead(), то всё будет работать.
Если вы добавляли свои свойства - укажите для них название в настройках модуля Управление структурой.
Настроены шаблоны типовых страниц и включаемых областей (QD0080).
Описание
Настроены шаблоны типовых страниц и включаемых областей (для быстрого создания по шаблону) для удобства работы контент-редактора.
Как тестировать
В целях оптимизации работы редактора веб-сайта и уменьшения числа ошибок нередко целесообразно определить шаблоны типовых страниц и включаемых областей, например:
- Страница с текстом
- Страница с таблицами
- Страница с группой иллюстраций
- Страница с примерами форматирования
- Включаемая область со статической информацией
Необходимо проверить, что для наиболее часто создаваемых редактором типов страниц и включаемых областей созданы шаблоны.
Заданы имена стилям в визуальном редакторе (QD0090).
Описание
Заданы имена стилям, которые появляются в визуальном редакторе для удобства работы контент-редактора.
Как тестировать
В целях оптимизации работы редактора веб-сайта и уменьшения числа ошибок при форматировании контента в визуальном редакторе целесообразно определить часто используемые стили и дать им понятные названия на языке веб-сайта:
Редактор, без помощи верстальщика, сможет быстро выбрать и применить к тексту предопределенный стиль.
Необходимо проверить, что в визуальном редакторе заданы имена часто используемым стилям.
В визуальном редакторе настроены сниппеты (QD0100).
Описание
В визуальном редакторе настроены сниппеты - необходимые для эффективного создания контента.
Как тестировать
Технология сниппетов в визуальном редакторе ускоряет работу по наполнению веб-сайта информацией и позволяет снизить число оформительских ошибок. В качестве сниппета добавляют часто встречающиеся элементы контента:
- Таблицы разных типов
- Блоки оформления
- Динамические вставки
- Различные типы иллюстрирования контента
- элементы "сложной верстки" и т.п.
Необходимо проверить, что в визуальном редакторе определены часто используемые в контенте веб-проекта сниппеты.
Созданы группы редакторов контента (QD0110).
Описание
Созданы группы редакторов контента, которые имеют возможность создавать страницы и разделы, добавлять/изменять меню, изменять включаемые области, метаданные страницы, размещать на странице и редактировать настройки компонентов.
Как тестировать
Для эффективного управления информацией на сайте целесообразно выделить и аккуратно настроить группу редакторов контента - сотрудников, имеющих учетные записи в веб-проекте и выполняющих задачи:
- Создание/изменение веб-страниц и разделов, их свойств
- Создание/изменение пунктов меню
- Создание/изменение включаемых областей
- Создание/изменение разделов и элементов некоторых информационных блоков
- Размещение на страницах и редактирование настроек компонентов
- и т.п.
При этом важно, чтобы редакторы контента не имели доступ к критичным для работы веб-проекта данным и настройкам. Данный подход будет способствовать поддержанию информационной безопасности веб-решения на должном уровне.
Необходимо проверить, что в веб-проекте создана и настроена группа редакторов контента. Проверяются все действия, выполняемые данной группой: не должно быть ошибок, связанных с нехваткой прав, при редактировании страниц и включаемых областей и т.п.
Проверяется, что участникам данной группы недоступны "остальные" возможности системы, настройки модулей и т.п. К примеру, редактор контента не должен иметь прав на изменение системных настроек главного модуля, создание и изменение групп пользователей и их учетных данных, лицевых счетов покупателей интернет-магазина и т.д.
Настройки проекта - описаны в техдокументации (QD0120).
Описание
Управление специфичными для проекта свойствами страниц и разделов, включаемыми областями, расширенными свойствами меню - описаны в техдокументации к проекту.
Интеграция структур данных
Настроены инфоблоки (QM0010).
Описание
Созданы и настроены необходимые для проекта типы информационных блоков. Созданы и настроены необходимые для проекта информационные блоки. Путем анализа ожидаемого объема данных и нагрузки выбран подходящий тип инфоблоков (1.0 или 2.0), настроены свойства и другие параметры инфоблоков.
Как тестировать
Информационные блоки, сгруппированные по типам, хранят данные проекта: новости, каталоги и другие деревья/списки. От правильной настройки информационных блоков зависят не только удобство управления системой, но и производительность сайта и стоимость его поддержки и сопровождения. (Чем "прозрачнее" схема данных, тем проще ее поддерживать и развивать.) Неиспользуемые возможности желательно отключать.
Проверяем настройки типов информационных блоков: " Контент > Информационные блоки > Типы информационных блоков".
- Названия типов должны отражать их роль в проекте. Название "Type12" - неудачное, "Новости регионов" (содержит внутри инфоблоки новостей регионов) - говорит само за себя.
- В настройках каждого типа на вкладке "Основное" желательно указать названия разделов и элементов данного типа. Если элементами являются, допустим, товары, то название "Новости" для них явно некорректно.
- На вкладке "Дополнительно" проверяем, чтобы флаг экспорта в RSS был установлен, когда экспорт действительно необходимо выполнять.
Проверяем настройки каждого информационного блока: " Контент > Информационные блоки > Типы информационных блоков > Название инфоблока".
- Место хранения значений свойств (в общей таблице или отдельной таблице) выбирается в зависимости от решаемых задач и объема данных. Если в списке/дереве ожидается достаточно большой объем данных (сотни тысяч - миллионы элементов), рекомендуется хранить свойства в отдельной таблице. Для повышения эффективности выборок рекомендуется задавать для данных таблиц отдельные индексы на используемые в выборках поля.Однако, если число свойств у объектов может превысить максимальное число столбцов в таблице базы данных или требуются сквозные выборки объектов из множества инфоблоков, то рекомендуется использовать место хранения "в общей таблице".
- Проверяем, что инфоблок используется только на том сайте, на котором требуется выборка его данных.
- Индексация разделов и элементов для поиска включается тогда, когда планируется искать по информации в данном инфоблоке. В противном случае для повышения производительности индексацию рекомендуется отключить.
- Если объекты инфоблока не участвуют в документообороте или бизнес-процессах - рекомендуется отключить участие.
- Режим просмотра разделов и элементов выбирается исходя из удобства администрирования и ожидаемого объема данных. Если данных ожидается много (сотни тысяч объектов и разделов и больше) - рекомендуется использовать "раздельный" режим просмотра.
- На вкладке "Поля" проверяем значения свойств объектов по умолчанию. Правильная настройка значений по умолчанию повысит удобство администрирования системы и работы с данными.
- На вкладке "Свойства" обращаем внимание на удобочитаемые названия, адекватные решаемой задаче типы свойств и читаемые коды. Если для свойства задано название "Prop10" и код свойства "C9" - это легко запутает как менеджера сайта, так и в будущем программиста, осуществляющего доработку системы. Важно подобрать правильный тип свойства: например если требуется хранить дату, то обычно лучше использовать тип "Дата/Время", а не тип "Строка" и т.п.
- Если требуется фильтрация по свойству элемента инфоблока в административном разделе, целесообразно в настройках свойства разрешить его вывод в фильтре - это сделает работу редактора информации более эффективной (например, список Партнеров необходимо часто фильтровать по дате регистрации Партнера и его типу т.п. - настраиваем эту возможность).
- Аналогично проверяются настройки на вкладке "Поля разделов".
- На вкладке "Торговый каталог" значения должны быть установлены только в случае использования данных режимов в проекте. В противном случае, для улучшения производительности, их лучше отключить.
- На вкладке "Доступ" проверяем адекватность уровней доступа для групп пользователей. Например, инфоблок "Секретные ключи", не должен быть доступен группе "Зарегистрированные пользователи". Уровень доступа группы к инфоблоку также должен соответствовать решаемой группой задаче - например, если группа "Операторы ключей" должны только видеть ключи и не редактировать, то им не нужно предоставлять доступ "излишний" к инфоблоку - "Изменение" или "Полный доступ". Если требуется модерация внесенных данных перед их публикацией, то целесообразно назначить группе право на инфоблок - "Документооборот" (или использовать бизнес-процессы).
- На вкладке "Подписи" проверяем их логическое соответствие. Например, если в инфоблоке хранятся данные об автомобилях, то подписи не должны описывать апельсины.
- На вкладке "Журнал событий" можно включить регистрацию в системном журнале фактов модификации данных в инфоблоке. Если регистрация по, допустим, соображениям информационной безопасности, необходима, она должна быть включена.
- В больших проектах с десятками типов и сотнями инфоблоков рекомендуется составить логическую модель данных с названиями инфоблоков, их свойств и связей между ними (еще лучше ее распечатать и повесить на стену). Это существенно упростит ориентацию в проекте как редакторов сайта, так и разработчиков, сократив время на поиск нужной информации и минимизировав риск логических ошибок. Также модель также поможет ответить на вопрос, можно ли удалить данный элемент инфоблока без последствий (на элемент могут ссылаться другие элементы и при удалении исходного может нарушиться логика работы проекта).
Настроены интерфейсы редактирования инфоблоков (QM0020).
Описание
Настроены адаптированные под задачи проекта формы редактирования элементов инфоблоков и их списков в административном разделе, установленные по умолчанию для всех пользователей проекта.
Как тестировать
Инфоблоки веб-проекта, как правило, хранят базовые и наиболее часто редактируемые сотрудниками структуры данных. В эту категорию попадают такие данные, как «Новости», «Вакансии», «Справочники», древовидные каталоги и другая информация.
Технология настройки удобных, адаптированных под задачи веб-проекта форм редактирования объектов инфоблоков и их списков – повышает скорость и эффективность работы сотрудников с данными, сокращает число ошибок.
Рекомендуется настраивать под задачи проекта формы редактирования и списки информационных блоков для всех пользователей по умолчанию. Форму можно адаптировать скрывая «лишние» свойства, создавая новые вкладки, меняя названия вкладок и свойств на соответствующие тематике веб-проекта, распределяя свойства по вкладкам удобным для пользователя образом.
- Проверяется форма редактирования элемента каждого инфоблока, предназначенного для изменения сотрудником через административный интерфейс. Форма редактирования не должна содержать «лишних» технических и непонятных сотруднику свойств. Например, если элемент инфоблока хранит только название цвета, сотруднику не нужно показывать свойства типа «Описание для анонса», «Детальное описание», «Тэги» и т.п.
- Проверяются списки элементов информационных блоков. Списки должны содержать адаптированный к задачам веб-проекта набор колонок – остальные должны быть по умолчанию скрыты для всех пользователей.
Интеграция стандартных компонентов и модулей
Настроены стандартные модули (QS0010).
Описание
Настроены стандартные модули, требуемые для выполнения задач проекта.
Как тестировать
При проектировании веб-системы необходимо внимательно просмотреть настройки стандартных модулей Битрикс, используемых в проекте, и скорректировать их при необходимости.
Например, настраивая главный модуль (Настройки > Настройки продукта > Настройки модулей > Главный модуль) отвечаем на следующие вопросы:
- Используем ли мы единую авторизацию между сайтами веб-проекта ("Single Sign On") и необходимо распространять авторизационные куки на все домены, перечисленные в настройках сайта (Настройки > Настройки продукта > Сайты > Список сайтов")? Не остались ли там лишние тестовые домены?
- Задан ли корректный e-mail отправителя по умолчанию?
- Разрешать ли редактировать шаблоны сайта со сложной версткой через визуальный редактор?
- Позволяем ли мы пользователям регистрироваться самостоятельно, защищаем ли регистрацию по технологии CAPTCHA, проверяем ли E-mail на уникальность, в какую группу добавляем после регистрации и запрашиваем ли подтверждение регистрации по E-mail?
- Насколько предлагаемые по умолчанию периоды хранения служебных данных соответствуют задачам проекта ("Сколько дней хранить почтовые события", "Сколько дней хранить пользователей с неподтвержденной регистрацией", "Сколько дней хранить события" журнала событий и т.п.)? Время хранения событий особенно важно для высоконагруженных проектов.
- Включена ли ежедневная автоматическая проверка обновлений платформы - для оперативного исправления возможных системных ошибок, улучшения производительности, а также получения нового функционала?
Аналогично необходимо просмотреть другие модули платформы, проверить соответствие установленных настроек задачам веб-проекта.
Как тестировать:
Настройки каждого модуля веб-проекта в разделе Настройки > Настройки продукта > Настройки модулей проверены и соответствуют задачам веб-проекта.
Настроены стандартные компоненты (QS0020).
Описание
На страницах проекта размещены и настроены стандартные компоненты (рекомендуются компоненты 2.0). Установлено кеширование в режим "Авто+Управляемое" или "Авто".
Как тестировать
С платформой Bitrix Framework поставляются сотни (в зависимости от редакции) протестированных, безопасных и настроенных на максимальную производительность стандартных компонентов - например "Список новостей", "Меню", "Карта сайта" и т.п. Использование стандартных компонентов позволяет существенно сократить сроки на развертывание проекта, т.к. их адаптация под ТЗ заключается, как правило, в изменении оформления и, иногда, логики оформления. Также, стандартные компоненты (точнее ядро каждого компонента) обновляются по технологии SiteUpdate - что позволяет получать новый функционал, исправления ошибок и оптимизацию.
Тем не менее, при необходимости выполнения сложной кастомизации, требуется создание собственных компонентов, в которых обязательно предусматривается настройка их параметров в публичной части сайта, безопасность, высокая производительность и кеширование. Фактически, стандартные компоненты Битрикс являются примером того, как создавать собственные компоненты для проекта.
Веб-проект можно, в принципе, себе представить как набор веб-страниц с размещенными на них компонентами - большей частью стандартными и определенным количеством собственных.
- Целесообразно составить полный список компонентов, использованных в проекте. Этот список можно разделить на две части: стандартные компоненты (возможно с модифицированным внешним видом) и специфические для проекта компоненты (либо созданные для проекта, либо использованные готовые). Например, для проекта А было использовано 10 стандартных компонентов Bitrix Framework, 5 созданных конкретно для проекта и 10 собственных библиотечных компонентов, предоставленных разработчиком.
- Стандартные компоненты имеют префикс "bitrix:". Необходимо проверить работу настроек стандартных компонентов, доступную в публичной части сайта, и убедиться в их функционировании (при невнимательном изменении внешнего вида стандартного компонента есть риск нарушения логики работы его настроек). Если для списка, допустим, "Деталей", использован стандартный компонент "bitrix:news", то названия компонента и его настройки должны быть адаптированы для решаемой задачи. Например, не должно остаться настройки "Количество новостей на странице" и т.п. Лишние, неиспользуемые настройки, рекомендуется скрыть.
- В настройках стандартного компонента важно обратить внимание на режим кеширования в разделе "Настройки кеширования". Рекомендуется значение - "Авто + Управляемое" с большим временем кеширования. Следует понимать, что если кеширование компонента отключено, он будет выполнять запросы к базе данных - что отрицательно скажется на производительности веб-проекта и его устойчивости к высоким нагрузкам.
- Рекомендуется протестировать работоспособность стандартных компонентов Битрикс, в т.ч. стандартных компонентов с измененным внешним видом после обновления платформы. При соблюдении стандартов интеграции работоспособность не должна быть нарушена - т.к. строго соблюдается принцип сохранения логики работы стандартных компонентов (их ядра) при обновлении (если изменение внешнего вида компонента для проекта было выполнено согласно нашим рекомендациям).
Настроены интерфейсы «Эрмитаж» (QS0030).
Описание
Обеспечена работа интерфейсов "Эрмитаж" с компонентами в публичной части для редактора контента: добавление/редактирование объектов «над сайтом», редактирование параметров компонентов
Как тестировать
Технологии "Эрмитаж" позволяют редактировать веб-проект не заходя в административный раздел - как бы "паря" над сайтом и настраивая параметры во всплывающих диалоговых окнах. Это позволяет более эффективно управлять информацией, т.к. не требуется переключаться в административный раздел (хотя такая возможность всегда имеется и используется для более "детального" редактирования объектов и их групп).
Необходимо проверить, что редактору контента можно, не переключаясь в административный раздел, редактировать элементы списков (например, из списка новостей), добавлять элементы списков и разделы (например, добавить продукт в каталог), изменять включаемые области (например, поменять номер телефона или год копирайта) и меню:
Для работы интерфейса, в шаблоне компонента должны быть такие строки:
Скопировать код можно из стандартных шаблонов.
$this->AddEditAction(...) - добавляет кнопку редактирования
$this->AddDeleteAction(...) - добавляет кнопку удаления
id="GetEditAreaId($arItem['ID'])?>" - привязывает кнопки к конкретному блоку на странице.
Настроены шаблоны компонентов (QS0040).
Описание
Для изменения внешнего вида стандартных компонентов используется копирование шаблонов компонентов в шаблоны проекта и их модификация.
Как тестировать
Стандартные компоненты платформы Bitrix Framework обычно дорабатываются под нужды проекта путем редактирования их шаблонов (путем копирования и доработки) и создания новых шаблонов. Ядро стандартного компонента - не модифицируется и его можно продолжать обновлять по технологии SiteUpdate для получения нового функционала, улучшения производительности и исправления возможных ошибок.
- В публичной части можно посмотреть, какой шаблон использован в конкретном компоненте. Название шаблона должно быть понятным.
- Нередко необходимо использовать один компонент с разными шаблонами на разных страницах веб-проекта. Например, используем три шаблона карты сайта с выводом информации с разными уровнем детализации и возможностями интерфейса. Рекомендуется протестировать работу каждого шаблона не только на странице, на которой размещен компонент, но и на тестовой странице проекта (компонент и его шаблоны предназначены для размещения на любой странице веб-проекта).
Интеграция собственных компонентов и модулей
Разработаны собственные компоненты 2.0 проекта (QC0010).
Описание
Разработаны собственные компоненты 2.0 проекта, размещённые в отдельном пространстве имён.
Как тестировать
Для решения типичных задач веб-проекта обычно достаточно модифицировать шаблоны стандартных компонентов и создать несколько шаблонов сайта. Однако иногда возникают задачи, требующие разработки собственных компонентов 2.0 и размещения их на страницах веб-решения.
При разработке собственных компонентов 2.0, как правило, придерживаются следующей последовательности действий:
- В веб-проекте, при составлении ТЗ и проектировании, выявляют и описывают возможные виды собственных компонентов 2.0.
- Определяется пространство имен собственных компонентов 2.0, например, с использованием названия проекта. Системные компоненты Bitrix Framework размещены в пространстве имен "bitrix:", компоненты проекта могут размещаться в пространстве имен, к примеру, "citybank:".
- Определяется, какой стандартный компонент можно взять за основу для создания собственного компонента. В коде стандартных компонентов много примеров типичного и правильного использования API и техник программирования, поэтому рекомендуется брать их за основу.
- К каждому компоненту 2.0 продумывается интерфейс - какие параметры компонента должны быть доступны администратору веб-сайта для редактирования. Например, для компонента, отображающего прогноз погоды, можно в настройки для администратора вынести свойство "Адрес веб-сервиса" и "Таймаут соединения с веб-сервисом" и т.п.
- Определяется, в каком разделе дерева компонентов в визуальном редакторе необходимо разместить данный компонент.
- Компонент кодируется. Особое внимание уделяется настройте автокеширования компонента и профилированию его работы - он не должен выполнять запросы к базе данных в режиме кеширования, выполняет минимальное количество запросов к базе данных при устаревании кеша, хранит в кеше только необходимые данные, использует минимально возможный объем оперативной памяти (не сортирует массивы размером с десятки-сотни мегабайт и т.п).
Созданные для веб-проекта собственные компоненты 2.0 могут использоваться как основа для новых компонентов, а также, по причине модульной структуры и "отчуждаемости от проекта" - эффективно использоваться в других веб-решениях. Постепенно формируется и развивается библиотека собственных компонентов 2.0. Иногда целесообразно компоненты проекта хранить в одном пространстве имен, а используемые в разных проекта компоненты 2.0 - в специальном пространстве имен типа "library:".
- В папке веб-сервера "/bitrix/components/" должны присутствовать папки с названием пространства имен компонентов проекта, например "myproject" и "mylibrary". Иногда разработчики создают собственные пространства имен типа "pupkin" или "test123", которые остаются в веб-проекте после его ввода в эксплуатацию.
- В визуальном редакторе в дереве компонентов 2.0 собственные компоненты проекта размещены в отдельном подразделе дерева.
- Собственные компоненты 2.0 проекта имеют соответствующие настройки, доступные в публичной части сайта. Важно, чтобы все настройки были тщательно протестированы и описаны. Не должно быть лишних, технических, непонятных администратору настроек, типа "Глубина вложенности хэш-массива объектов реестра" в компоненте-информере текущей погоды.
Разработаны комплексные компоненты (QC0020).
Описание
Для создания сложного функционала или многостраничных представлений используются комплексные компоненты.
Как тестировать
Когда для веб-проекта создаются группы связанных между собой собственных компонентов 2.0 типа кастомной фотогалереи, их целесообразно оформить в один "комплексный компонент". Это упростит как процесс управления данным компонентом, так и его дальнейшее развитие и поддержку.
Проверяем, что группы связанных между собой собственных компонентов 2.0 веб-проекта оформлены как комплексные компоненты. Например, обычные компоненты 2.0:
- Список видеороликов
- Детальная видеоролика
- Загрузка видеоролика
- Модерация видеороликов
- Обзорная видеороликов
- и т.п.
Собраны и оформлены в виде комплексного компонента "Раздел видеороликов".
Настройки компонентов - отделены и описаны (QC0030).
Описание
Из компонентов вынесены в их настройки наиболее часто изменяемые параметры - для обеспечения повторного использования компонента в этом и других проектах без модификации кода компонента и его шаблона. Параметры компонентов и их допустимые значения – описаны либо в интерфейсе настройки компонента в публичной части сайта, либо в техдокументации к проекту.
Как тестировать
Должно быть понятно, как настраивать специально созданные для проекта компоненты 2.0 без привлечения программистов. Например, для проекта "myproject" были созданы 30 компонентов 2.0, из них компонент "Список зарегистрированных участников" в пространстве имен "myproject:members.list". Какие настройки нужны данному компоненту 2.0? Это зависит, конечно, от проекта и сценариев использования. Например, могут быть такие настройки:
- Число участников на страницу
- Формат отображения ФИО участника: полный/краткий
- Число слов в описании (после которого выводим троеточие)
- Выводить кодированный емейл
- Колонка для сортировки списка
и т.п.
Данные настройки, возможно, потребуются администратору и будут изменены в ходе эксплуатации проекта.
А данные настройки могут сбить администратора с толку, т.к. понятны только программистам:
- Алгоритм кеширования данных
- Формат JSON-запроса
- Группы пользователей, которым разрешено просматривать список
и т.п.
Если такие настройки нужны, их рекомендуется располагать группой обособленно, с описанием назначения каждого параметра и допустимых диапазонов параметров.
Если используется библиотечный, универсальный компонент, предназначенный для использования во многих веб-проектах – целесообразно вынести все необходимые настройки и сделать их доступными для редактирования как программистом, так и администратором и подробно описать каждую настройку. Если пишется узкоспециализированный для данного веб-проекта компонент, нет особого смысла делать его конфигурируемым и делать настройки доступными для редактирования.
Открывая настройки каждого собственного компонента 2.0 в публичной части проверяем, что каждая настройка имеет понятное название и подробно описана. Администратор проекта должен однозначно понять, может ли он менять значение настройки, в каких диапазонах и используя какой формат/тип данных или она предназначена для программистов. Рекомендуется проверить работоспособность каждой настройки, предназначенной для администратора.
Компоненты используют кеширование (QC0040).
Описание
В собственных компонентах используется управляемое кеширование в режиме "Авто+Управляемое" с установкой длительного периода кеширования (1-12 месяцев) или "Авто" кеширование.
Как тестировать
Для чего использовать кеширование в собственных компонентах 2.0? Ведь, казалось бы, проще всего обращаться напрямую через API в базу данных, получать информацию, форматировать ее в шаблоне компонента и отображать пользователю.
Все дело в производительности веб-проекта при одновременной работе с ним множества пользователей. Если компонент 2.0 отрабатывает без кеширования за 0.1 сек, выполняя, допустим, 100 запросов к базе данных, то, при одновременной работе 100 пользователей не только резко возрастет нагрузка на сервер базы данных, но и время отработки компонента может вырасти, к примеру, до 5-10 секунд!
Не менее важный момент, на который стоит обратить внимание - скорость отработки компонента при получении данных из кеша. Если без кеширования компонент отрабатывает за 2 сек. для каждого пользователя, то при использовании кеширования компонент для одного пользователя отработает за 2 сек., а для остальных 100 пользователей в ближайшие полчаса, допустим, будет отрабатывать 0.1 сек.
На какой период времени кешировать информацию в собственных компонентах 2.0? Если используется "Авто+Управляемое" кеширование - информация будет отдаваться из кеша до тех пор, пока она не поменяется в базе данных и кеш сбросится автоматически. Если используется "Авто" кеширование - рекомендуется устанавливать максимально допустимый с учетом бизнес-логики интервал кеширования. Например, для редко обновляемого "списка статей" можно установить интервал кеширования в 12 часов, а для часто обновляемого - 10 минут.
Таким образом, при использовании кеширования в собственных компонентах 2.0:
- резко увеличивается производительность веб-проекта и его устойчивость к нагрузкам, т.к. нагрузка на базу данных качественно минимизируется и веб-решение сможет обслужить уже, к примеру, не 50 000 пользователей в сутки, а 1 000 000 и больше.
- веб-страницы загружаются в браузер пользователя значительно быстрее (десятые доли секунды), т.к. информация для их построения сохранена на сервере и не берется из базы данных
Необходимо проверить в настройках каждого собственного компонента 2.0 в публичной части что кеширование включено и установлено адекватное решаемой задаче время кеширования.
Обычно настройки расположены в разделе "Настройки кеширования" и называются "Тип кеширования" и "Время кеширования (сек.)". Тип кеширования должен быть установлен в "Авто+Управляемое" или "Авто". Если тип установлен в значение "Кешировать" - рекомендуется для удобства администрирования системы поменять его на "Авто".
В административной части в разделе "Настройки > Настройки продукта > Автокеширование" на вкладке "Кеширование компонентов" должно быть включено автокеширование, а на вкладке "Управляемый кеш" должно быть включено управляемое кеширование (в большинстве типовых веб-проектов его рекомендуется не выключать).
Время кеширования для режима "Авто+Управляемое" - должно быть большим, к примеру, 1 год. Время кеширования для режима "Авто" зависит от частоты обновления информации - для некоторых компонентов 2.0 устанавливается период в 24 часа, а для часто обновляемых либо рекомендуется использовать управляемое кеширование или установить значение, к примеру, в 10 минут.
Нагрузка на БД - минимизирована (QC0050).
Описание
В режиме кеширования компоненты не выполняют запросы к базе данных или выполняют только те запросы, кеширование которых является нерациональным.
Как тестировать
При внедрении технологии кеширования в собственные компоненты 2.0 необходимо четко представлять решаемые задачи:
- В режиме кеширования компонент не должен выполнять запросы к базе данных. Все данные он получает из кеша. Иногда это правило нарушается (из-за ошибок разработчика или проектировщика) и в режиме кеширования компонент продолжает обращаться к базе данных.
- В режиме построения кеша компонент выполняет тщательно оптимизированные запросы к базе данных. Иногда по причине ошибок разработчиков в данном режиме компонент или страницы выполняют огромное число SQL-запросов, например 1000 запросов.
Рекомендуется внимательно анализировать запросы, выполняемые компонентом к базе данных и, оптимизируя режимы фильтрации, сортировки и число свойств для выборки - добиться максимальной скорости выполнения запросов, уменьшения их числа и количества обрабатываемых записей в базе данных.
Для анализа SQL запросов компонента удобно использовать SQL команду EXPLAIN. Также крайне важно, анализируя планы выполнения SQL запросов следить, что выборки используют индексы базы данных - что особенно актуально для инфоблоков 2.0, в которых можно добавлять индексы на используемые при фильтрации колонки таблицы свойств элементов инфоблоков.
Также следует закешировать и оптимизировать по вышеописанной методике запросы к базе данных через API, выполняемые из служебных и инициализационных файлов веб-проекта. Иногда бывает так, что на веб-странице размещен один компонент, не выполняющий запросы к базе данных, а в инициализационных файлах проекта для каждого обращения пользователя выполняется 500 SQL запросов, что существенно снижает производительность веб-решение и его устойчивость к нагрузкам.
Иногда составляют и заполняют таблицу со следующей структурой:
- Страница веб-проекта
- SQL-запросов страницы с отключенным кешированием
- Число SQL-запросов страницы при включенном кешировании
- Проводилась оптимизация SQL-запросов (согласно методике выше)
и проверяют все страницы веб-проекта, выявляя неоптимизированные страницы и компоненты на них. Цель - путем доработки и оптимизации добиться того, чтобы в колонке (3) присутствовало близкое к 0 число SQL-запросов (идеально - 0 запросов; число запросов может быть выше при использовании модуля "Веб-аналитика"), в колонке (2) число SQL-запросов было минимально необходимым (например, 150 запросов), а в колонке (4) кратко указано, что оптимизация проводилась.
Иногда подобная контрольная таблица составляется дополнительно для компонентов 2.0 веб-проекта - и в ней описываются характеристики каждого компонента после оптимизации с отключенным/включенным режимом кеширования.
- Необходимо составить и заполнить вышеописанную таблицу либо, при недостатке времени, выполнить аналогичные замеры на наиболее посещаемых страницах веб-проекта - и, при необходимости, минимизировать нагрузку на базу данных путем кеширования и оптимизации SQL-запросов.
- Необходимо удостоверится, что в инициализационных и служебных файлах веб-проекта (т.е. не в компонентах) были оптимизированы по вышеописанной методике все обращения к базе данных через API Bitrix Fraim . Обращения к базе данных напрямую, без использования API Битрикс - не допускаются, в т.ч. потому что данные запросы не "улавливаются" и не доступны для анализа встроенным профилировщиком SQL-запросов.
Объем кеша компонентов - оптимизирован (QC0060).
Описание
Компонент не сохраняет избыточные данные в кеш. При неверном ключе кеша – данные не кешируются и не используются повторно (для предотвращения переполнения кеша злоумышленником). Объем файла кеша компонента не превышает 1МБ.
Как тестировать
Кеширование собственных компонентов веб-проекта позволяет не только ускорить процесс создания веб-страницы, но и качественно снизить нагрузку на базу данных. Однако, если злоупотребить этой технологией, например, сохраняя в кеше результаты огромных выборок из базы данных - время создания веб-страницы и нагрузка программное и аппаратное обеспечение - могут серьезно возрасти и привести резкому снижению производительности веб-проекта.
Также существует риск постепенного накопления неиспользуемых и устаревших файлов кеша - возможный при использовании файлового кеширования и отсутствии периодического бизнес-процесса очистки устаревшего кеша в разделе "Настройки > Настройки продукта > Автокеширование > вкладка Очистка файлов кеша".
Рекомендуется не сохранять в кеш объекты размером более 1МБ - оптимизировав запросы к API , Bitrix Framework и усилив критерии фильтрации и выборки. Для защиты от разрастания общего объема файлового кеша рекомендуется периодически проверять размер системной папки: "/bitrix/cache", очищать устаревший кеш инструментами платформы ("Настройки > Настройки продукта > Автокеширование > вкладка Очистка файлов кеша") или операционной системы или использовать режим сохранения кеша в memcached (автоматически вытесняющий устаревший кеш).
- Во время нагрузочного тестирования веб-решения на объеме тестовых данных, приближенном к реальному (тысячи элементов в каталоге, десятки тысяч пользователей и т.п.), на каждой странице в публичной части при установленном режиме отладки "Суммарная статистика" - платформа отображает информацию по размеру кеша каждого компонента и суммарному размеру кеша веб-страницы:
Необходимо проверить все, либо наиболее посещаемые веб-страницы проекта. Если предварительно не добавить в веб-проект тестовые данные, можно не "отловить" превышения кешем допустимого размера.
- При использовании файлового кеша необходимо убедиться, что контролируется размер и число файлов и папок системной папки кеша "/bitrix/cache" (например, утилитой Nagios). Из-за ошибок интеграции возможно бесконтрольное увеличение размера данной папки (например, через полгода эксплуатации проекта в ней может оказаться миллион файлов размером 100ГБ). Также необходимо убедиться, что файловый кеш периодически, при необходимости, очищается с использованием инструментов платформы "Настройки > Настройки продукта > Автокеширование > вкладка Очистка файлов кеша" или утилит операционной системы.
Код компонентов - оптимизирован по памяти и процессорам (QC0070).
Описание
PHP-код компонента оптимизирован по расходу оперативной памяти и процессоров. На PHP не выполняются большие сортировки или обработки больших массивов. Компонент профилировался встроенным отладчиком платформы.
Как тестировать
После разработки собственного компонента рекомендуется проводить оптимизацию его кода на объемах тестовых данных, приближенных к реальным. Это не только улучшит текущую производительность веб-проекта, но и сдержит ухудшение характеристик производительности при увеличении объема информации в веб-проекте, а также сделает систему более устойчивой.
Оптимизацию по расходу компонентом оперативной памяти удобно проводить с помощью PHP функций "memory_get_usage" и "memory_get_peak_usage". Важно определить максимальный объем оперативной памяти, которую может использовать компонент.
Допустим, если веб-проекту выделен максимальный объем памяти в 64МБ, то, очевидно, ни один компонент не должен расходовать больший объем памяти - иначе выполнение веб-страницы завершиться ошибкой и посетителю отобразится белый экран в лучшем случае, а в худшем - из-за ошибки завершится важный бизнес-процесс и, возможно, потеряется часть данных.
Распространены следующие ошибки, связанные с перерасходом памяти и процессорных мощностей:
- Компонент сохраняет результаты запросов к базе данных (через API Bitrix Framework) в массивах PHP. При увеличении объема информации в базе данных размер массивов компонента может превысить выделенный веб-проекту объем оперативной памяти. Рекомендуется оптимизировать объем сохраняемой компонентом в оперативной памяти информации, например, используя временные таблицы базы данных, файлы, изменив характер запроса и т.п. - важно гарантировать, что при работе компонента не будет использовано более, например, 8МБ памяти вне зависимости от объема обрабатываемых компонентом данных.
- Компонент пытается объединить результаты запросов к API Bitrix Framework - сначала добавляя их в массивы, затем обрабатывая их в оперативной памяти. Фактически, компонент пытается средствами языка программирования "выполнить работу" базы данных по объединению информации (JOIN). Иногда данную задачу решают для соединения информации из нескольких информационных блоков. Рекомендуется использовать встроенные возможности информационных блоков по объединению (JOIN) выборок. Для достижения максимальной гибкости можно создать свои таблицы в базе данных, работать с ними через API Bitrix Framework и использовать встроенные средства БД по объединению данных.
- Компонент помещает в оперативную память для обработки файлы целиком. Разумеется, если файл окажется большим - работа компонента будет прекращена по ошибке. Рекомендуется обрабатывать большие файлы - по частям. Важно гарантировать, что при работе компонента не будет использовано более, например, 8МБ памяти вне зависимости от размера файла.
- Компонент выполняет интенсивные вычисления, нагружая процессоры и замедляя построение веб-страницы. Рекомендуется либо выполнять вычисления в фоновом, асинхронном режиме и отдавать пользователям результат вычислений , либо использовать кеширование.
К сожалению, иногда данные проблемы решаются путем выделения веб-проекту огромных размеров оперативной памяти - 512МБ и больше. Что, естественно, не только ухудшает стабильность и производительность веб-проекта, но и приводит к неэффективному использованию аппаратных возможностей сервера.
Рекомендуется, наоборот, уменьшать размер выделенной веб-проекту оперативной памяти до нахождения оптимального размера (рекомендованный размер оперативной памяти для платформы Bitrix Framework - не менее 64МБ).
- Необходимо убедиться, что при разработке собственных компонентов веб-проекта выполнены вышеперечисленные рекомендации.
- Необходимо совместно с системным администратором веб-проекта после проведения нагрузочного тестирования либо определенного периода эксплуатации (например, каждую неделю) - посмотреть лог ошибок PHP или веб-сервера на предмет наличия сообщений об ошибках, связанных с нехваткой веб-страницам оперативной памяти, найти причины и доработать компоненты. Постепенно все "проблемные" компоненты будут найдены и исправлены и веб-решение будет использовать небольшой фиксированный объем оперативной памяти. Это позволит выделить другому программному обеспечению: веб-сервер, база данных, файловый кеш операционной системы - больше места.
SQL-запросы - оптимизированы (QC0080).
Описание
Число и сложность запросов к базе данных в компоненте адекватны решаемой задаче (параметр замеряется при отключенном кешировании компонента). Выполняемые компонентом запросы профилированы встроенным SQL-отладчиком.
Как тестировать
Работа с БД - через API платформы (QC0090).
Описание
В компонентах и их шаблонах не используются прямые запросы к базе данных, в т.ч таблицам платформы. Работа с базой данных выполняется через API функции платформы Битрикс. Запросы к специфичным для проекта таблицам в базе данных выполняются через класс CDatabase (это необходимо для работы подсистемы отладки, мониторинга и кластеризации).
Как тестировать
Для обеспечения максимальной безопасности, прозрачности и высокой производительности веб-проекта, особенно в веб-кластерных редакциях, требуется, чтобы работа с базой данных осуществлялась с использованием инструментов платформы Bitrix Framework.
Инструменты платформы по работе с базой данных защищают ее от ошибок разработчиков (которые неизбежны). Эти ошибки могут привести к утечке информации и взлому проекта. Инструменты Bitrix Framework обеспечивают возможность увидеть и проанализировать каждый запрос проекта к базе данных, выполненный при создании любой страницы веб-сайта. Правильно оптимизированный веб-проект с включенным кешированием (и не использующий модуль "Веб-аналитика"), не должен выполнять не одного запроса к базе данных.
Для проверки добавленного при интеграции кода встроенными в платформу инструментами работы с базой данных, требуется аудит всего доработанного/созданного кода компонентов, шаблонов и вспомогательных файлов. Мы постараемся автоматизировать данную проверку.
Шаблоны компонентов - формируют верстку (QC0100).
Описание
Шаблон компонента максимально облегчен и содержит преимущественно логику для формирования верстки (представления).
Как тестировать
Шаблоны собственных компонентов веб-проекта, согласно общеизвестной логике шаблона проектирования "Model-View-Controller", должны содержать исключительно логику формирования верстки.
Controller - представлен ядром компонента . Задача "Контроллера" - обработать входные параметры, сделать их безопасными, обратиться к "Модели", обработать информацию и в подготовленном виде передать ее "Виду".
Model - представлена API модулей платформы Битрикс. Задача "Модели" - сохранить данные соответственно контексту предметной области, искать информацию по заданным критериям.
View - представлен шаблоном компонента. Задача "Вида" или шаблона - визуализировать информацию для Посетителя. В случае веб-приложений - сформировать верстку корректную.
Настоятельно рекомендуется в шаблонах компонентов заниматься исключительно формированием верстки на базе предоставленной "Контроллером" информации в виде массивов или объектов, не делать запросов к "Модели" и другим ресурсам. Код шаблона должен быть простым и понятным не только программисту, но и верстальщику.
Наличие в шаблоне компонента логики, присущей "контроллеру" или "модели" - ведет к дублированию, усложнению архитектуры и, соответственно, не только увеличивает вероятность ошибок при разработке, но и удорожанию развития и дальнейшей поддержке веб-решения.
Шаблоны собственных компонентов должны содержать простую логику, занимающуюся формированием верстки на основании предварительно подготовленных и переданных шаблону данных. Получение и обработка данных происходит вне шаблона компонента.
Определены и соблюдаются правила оформления кода (QC0110).
Описание
При разработке собственных компонентов 2.0 использовались рекомендации по написанию кода от Битрикс.
Как тестировать
При создании собственных компонентов и модулей веб-проекта настоятельно рекомендуется использовать согласованный со всеми разработчиками стандарт кодирования ("codestyle").
Правило простое - стандарт кодирования в любой форме должен быть и ему следуют все разработчики. В качестве отправной точки можно взять рекомендации Bitrix Framework , целесообразно также обратить внимание на стандарт кодирования ZendFramework и другие.
Использование стандарта кодирования при работе над проектом нескольких разработчиков значительно улучшает качество и читаемость кода, уменьшает число ошибок и удешевляет поддержку и развитие веб-решения. Игнорирование данной рекомендации может привести к созданию некачественного и запутанного кода веб-проекта, в котором смогут разобраться только его автор/авторы - развивать такой код чрезвычайно сложно и нередко единственным выходом остается полное переписывание заново.
Удостовериться, что у разработчиков, задействованных для интеграции веб-проекта, имеется и строго соблюдается единый стандарт кодирования, согласованный с рекомендациями Битрикс.
В php-коде отсутствуют предупреждения (E_WARNING) (QC0120).
Описание
При выполнении страниц и вспомогательных скриптов проекта отсутствуют предупреждения (E_WARNING) PHP
Как тестировать
В язык программирования PHP встроены инструменты автоматического контроля качества разрабатываемого кода. Для контроля качества создаваемого кода, увеличения скорости разработки, уменьшения числа ошибок, уменьшению риска при переходе на новые версии языка PHP рекомендуется проводить разработку собственных компонентов и модулей (в том числе для marketplace) в режиме "максимальной чувствительности" PHP к ошибкам и "небрежностям":
E_ALL & E_STRICT
Удостовериться, что разработка собственных компонентов и модулей ведется в режиме "максимальной чувствительности" PHP к ошибкам и "небрежностям" разработчиков.
Объемный php-код оформлен в виде модуля (QC0130).
Описание
Созданный для проекта программный код средней и высокой сложности оформлен в виде отдельного подключаемого модуля платформы Битрикс.
Как тестировать
При увеличении объема создаваемого для веб-проекта собственного кода рекомендуется оформить его в виде модуля Bitrix Framework. Это позволит структурировать код, снизит его сложность и повысит управляемость конфигурацией. Также нередко целесообразно распространять обновления собственных модулей через marketplace.
Если создается много кода и/или он достаточно сложный - рекомендуется, для снижения числа ошибок и удешевления его поддержки, использовать технологии объектно-ориентированного программирования (инкапсуляция, полиморфизм, наследование и др.) и доказавшие свою эффективность "шаблоны проектирования".
Иногда весь создаваемый для веб-проекта код помещают в инициализационные файлы (init.php и др.) - что, благодаря их "раздуванию", не только усложняет управление веб-решением и увеличивает число ошибок при разработке, но и снижает производительность конфигурации. Еще большее ухудшение производительности наблюдается в случае выполнения в данных инициализационных файлах интенсивных обращений к базе данных через API Bitrix Framework.
Удостовериться, что объемный собственный код не "размазан" по инициализационным файлам (init.php и др.), а структурирован в виде модуля Bitrix Framework.
Используются обработчики событий (QC0140).
Описание
Используются обработчики событий для расширения функционала платформы без модификации ядра. Обработчики описаны в техдокументации к проекту, либо тщательно документированы в файлах настройки проекта.
Как тестировать
Для расширения или изменения функционала ядра и модулей Bitrix Framework под нужды веб-проекта необходимо использовать стандартную технологию расширения функционала - создание обработчиков системных событий.
В большинстве случаев возможностей данной технологии достаточно для адаптации платформы Bitrix Framework к задачам конкретного веб-проекта. Однако, если требуется более "глубокая кастомизация" стандартного API и возможностей платформы- рекомендуется обратиться в службу технической поддержки и запросить добавление требуемых системных событий.
Запрещается изменение ядра платформы Bitrix Framework - т.к. это не позволит веб-проекту получать обновления (новый функционал и исправления ошибок) по технологии SiteUpdate без нарушения работы веб-проекта, либо потребует постоянной ручной адаптации измененного в ядре функционала после его обновления. Нужно либо использовать технологию обработчиков, либо реализовать собственный модуль со своими таблицами в базе данных.
Проверить, что имеется техническое описание обработчиков системных событий, переопределяющих и модифицирующих стандартное поведение Bitrix Framework. Данное описание должно поддерживаться в актуальном состоянии при доработке веб-проекта.
Не используются вставки php-кода (QC0150).
Описание
На контентных страницах проекта и во включаемых областях, доступных для редактирования визуальным редактором, отсутствует прямое включение PHP кода. Код должен находиться только внутри компонентов.
Как тестировать
На контентных страницах проекта и во включаемых областях, доступных для редактирования визуальным редактором, не должно быть прямых включений PHP кода. Код должен находиться только внутри компонентов. Это позволяет улучшить модульность системы, и, таким образом, удешевляет ее поддержку. Также, обработка страниц визуальным редактором - упрощается.
Проверить, что на контентных страницах веб-проекта и во включаемых областях, доступных для редактирования визуальным редактором, отсутствуют прямые включения PHP кода (кроме служебных блоков подключения пролога и эпилога ядра):
<?
Код PHP, не подключающий компоненты
?>
Вместо этого, в коде подключаются компоненты:
<?
$APPLICATION->IncludeComponent(…);
$APPLICATION->IncludeComponent(…);
…
?>
Компоненты возвращают целостный html-текст (QC0160).
Описание
Разметка, возвращаемая компонентом и включаемой областью, должна возвращать целостный html-блок с закрытыми тегами. Например, компонент должен возвращать таблицу целиком (неправильно, когда до вызова компонента вставляется заголовок таблицы, компонент возвращает строки и ячейки таблицы, а после вызова компонента вставлен закрывающий тег таблицы).
Как тестировать
Для упрощения редактирования веб-страниц проекта в визуальном редакторе, повышения модульности, простоты поддержки и развития функционала компонентов - рекомендуется из компонента и включаемой области возвращать целостный html-блок с закрытыми тэгами.
Например, компонент должен возвращать таблицу целиком (неправильно, когда до вызова компонента вставляется заголовок таблицы, компонент возвращает строки и ячейки таблицы, а после вызова компонента вставлен закрывающий тэг таблицы) или список ("OL"/ "UL") целиком со всеми вложенными тегами, а не отдельно только пункты списка ("LI").
Проверить шаблон каждого собственного компонента веб-проекта. Шаблон должен возвращать целостный html.
Дополнительно
Настроены агенты (QE0010).
Описание
Специфичные для проекта периодические операции (агенты) настроены, а рекомендации по интервалам их запуска описаны в техдокументации проекта.
Как тестировать
Во многих веб-проектах необходимо выполнять по расписанию периодические операции. Например, производить расчет баллов, удалять устаревшие данные или агрегировать их, закрывать заказы и т.п. В платформе Bitrix Framework, в разделе "Рабочий стол > Настройки > Инструменты > Агенты", настраиваются все подобные периодические задачи - агенты.
Если в веб-проекте имеются специфические задачи, требующие выполнения с определенным интервалом, рекомендуется зарегистрировать их в виде агентов, настроить интервал выполнения и подробно описать логику их работы в технической документации к проекту.
- В разделе "Настройки > Инструменты > Агенты" настроены агенты, необходимые для выполнения периодических задач веб-проекта. Также, они описаны в технической документации к проекту.
- В разделе "Настройки > Инструменты > Агенты" проверяем имеющиеся по умолчанию системные агенты, при необходимости корректируем интервал из запуска.
- Некоторые периодические задачи, ожидаемое время выполнения которых достаточно велико (минуты), вынесены в системный "cron" для запуска операционной системой по расписанию. Они также описаны в технической документации к проекту.
Используются мастера (QE0020).
Описание
Для комплексной настройки функционала проекта используется технология мастеров.
Как тестировать
Если в веб-решении используются комплексные процедуры настройки как административной части, так и публичного раздела веб-сайта, рекомендуется использовать технологию мастеров. Примеры установленных по умолчанию мастеров можно посмотреть в разделе "Настройки > Настройки продукта > Список мастеров". Примеры мастеров, которые могут быть созданы в веб-проекте:
- Добавление нового города и связанных с ним настроек и типов справочников в интернет-магазине
- Добавление сложного правила в систему расчета скидок группе пользователей
- Создание пользователя, с добавлением его в определенные группы, заполнением значениями нескольких инфоблоков/справочников, связанных с данным пользователем (упрощаем задачу администратора веб-проекта).
В раздел "Настройки > Настройки продукта > Список мастеров" добавлены специфические для веб-проекта мастера, позволяющие автоматизировать комплексные операции как в административной, так и публичной части веб-сайта.
Используются свои «админки» (QE0030).
Описание
Для управления нестандартными разделами и объектами проекта используется технология собственных административных разделов.
Как тестировать
Иногда для решения задач веб-проекта требуется создать свои "админки", т.к. возможности стандартного административного интерфейса Bitrix Framework уже использованы на 100%. Для сокращения времени и снижения рисков проектирования и разработки собственных "админок" рекомендуется использовать технологию "быстрой" разработки админок, подробно описанную в документации к Bitrix Framework и использующую все возможности платформы, такие как:
- Фильтрация данных в админке по различным критериям и гибкий интерфейс настройки фильтра
- Сортировка данных по различным свойствам и гибкий интерфейс настройки выводимых колонок в админке
- Возможность выполнять над списком объектов в админке групповые операции: активация, редактирование значение сортировки и другие, необходимые веб-проекту
- Использование "вкладок", настройка размещения редактируемых свойств на "вкладках" детальной страницы объекта в админке
- Эффективное использование технологий AJAX, JSON, XML
Использование технологии создания собственных "админок", не уступающих по функциональности и удобству стандартному административному интерфейсу Bitrix Framework, позволяет в несколько раз ускорить решение данной задачи.
Необходимо убедиться, что для создания собственных "админок" используются технологии административного раздела платформы Bitrix Framework - поэтому они обладают аналогичной функциональностью: гибкая и настраиваемая фильтрация списков, гибкая и настраиваемая сортировка списков, разбитый на вкладки интерфейс редактирования объектов с настройкой размещения свойств на вкладках и возможностью сохранения персональных настроек, AJAX/JSON/XML.
Настроено SEO URL и проведена поисковая оптимизация (QE0040).
Описание
Используются SEO URL в кастомных и стандартных компонентах. Проведена поисковая оптимизация.
Безопасность
Используется проактивная защита. Минимальный уровень - «Стандартный» (QSEC0010).
Описание
Система соответствует уровню безопасности – «Стандартный» (включен проактивный фильтр, контроль активности, повышенный уровень безопасности администраторов и т.п.) или выше.
Как тестировать
Релизы и обновления платформы Bitrix Framework тщательно тестируются отделом информационной безопасности. Тем не менее, остаются следующие угрозы:
- При создании решения на базе платформы Битрикс разработчиком в коде были допущены ошибки, использовав которые злоумышленник может похитить конфиденциальную информацию и попытаться "взломать" веб-проект.
- Пользователи веб-проекта при регистрации использовали запоминающиеся, но при этом "слабые" пароли ('123456' и т.п.), которые можно подобрать, взломав их аккаунт.
- Администраторы веб-проекта, обладающие повышенными привилегиями, могут использовать "слабые" пароли, которые могут попытаться автоматически подобрать. Также, злоумышленник может попытаться "подслушать" пароль администратора когда тот управляет веб-решением (например, из локальной сети дома, из интернет-кафе и т.п.)
- При нарушении конфигурации программного обеспечения злоумышленники на страницах веб-сайта могут увидеть подробные сообщения об ошибках, раскрывающие подробности внутреннего устройства веб-решения.
- В программном обеспечении веб-сервера, базы данных и др. могут содержаться пока неизвестные и неисправленные ошибки и бреши, которыми могут захотеть воспользоваться злоумышленники.
- и другие
Очевидно, что для адекватной защиты веб-решения требуется комплексный, многоступенчатый подход, подразумевающий использование различных инструментов, работающих в унисон. Если один инструмент и "пропустит" атаку, ее могут заблокировать другие инструменты.
Для минимальной адекватной защиты веб-проекта от вышеперечисленных угроз, мы рекомендуем настроить конфигурацию веб-решения до достижения уровня безопасности - "Стандартный" (включен проактивный фильтр, контроль активности, повышен уровень безопасности администраторов, при регистрации используется CAPTCHA, информация о системе в случае ошибок не отображается). Для защиты от взлома сессионных данных, фишинга, дополнительной защиты административного раздела, защиты паролей, вирусов - рекомендуется достичь уровней безопасности "Высокий", "Повышенный".
- В разделе "Настройки > Проактивная защита > Панель безопасности" проверяем текущий уровень безопасности и, если он ниже уровня "Стандартный" - выполняем рекомендации системы до достижения уровня "Стандартный".
- При необходимости выполняем рекомендации системы для достижения уровней безопасности "Высокий", "Повышенный".
Административные учетные записи - защищены (QSEC0020).
Описание
Административные учетные записи имеют повышенный уровень безопасности. По возможности, для них используется технология двухфакторной авторизации (OTP).
Как тестировать
Административные учетные записи, имеющие максимальные привилегии по управлению веб-проектом, нередко являются целью атак хакеров. Для защиты данной категории учетных записей мы рекомендуем использовать для них повышенный уровень безопасности группы и, по возможности, использовать двухфакторную авторизацию (OTP).
Выполнение данных рекомендаций существенно усложняет атаки на административные учетные записи и делает бесполезным похищение их паролей.
- В разделе "Настройки > Пользователи > Группы пользователей > Администраторы (ID группы = 1) на вкладке "Безопасность" в списке "Предопределенные настройки уровня безопасности" должно быть установлено значение "Повышенный" (или выше).
Там же на вкладке "Параметры" в разделе "Пользователи в группе" проверьте, какие учетные записи включены в группу "Администраторы". Для них необходимо включить использование одноразовых паролей.
- В разделе "Настройки > Проактивная защита > Одноразовые пароли" должно быть включено использование одноразовых паролей.
- В форме редактирования параметров каждой административной учетной записи: "Настройки > Пользователи > Список пользователей" на вкладке "Одноразовые пароли" должно быть настроено и включено их использование.
- Также рекомендуется, при необходимости, использовать повышенный уровень безопасности (и возможно одноразовые пароли) для учетных записей других привилегированных групп, таких как администраторы магазина, администраторы каталогов и т.п.
Группам пользователей предоставлены минимально необходимые права (QSEC0030).
Описание
Настроены права групп пользователей системы и протестированы их возможности в административном разделе системы после авторизации ("/bitrix/admin"). Все «лишнее» должно быть недоступно.
Как тестировать
Обычно проектом управляют несколько групп пользователей, во главе которых группа "Администраторы", обладающая максимальными полномочиями. Список групп и сценарии их работы определяются, как правило, в ТЗ на веб-проект. Для обеспечения максимальной защищенности веб-проекта от известных и будущих видов уязвимостей и вирусов, настоятельно рекомендуется дать каждой группе пользователей только те права, которые ей действительно нужны для выполнения бизнес задач по принципу увеличения привилегий - сначала удаляются все права, а затем добавляются только необходимые.
Например, если задача пользователя состоит в редактировании в подвале сайта номера телефона - для него создается группа, имеющая права ТОЛЬКО на редактирование данной информации и он не может отредактировать мимоходом пункт меню или страницу "О компании". Аналогично, если пользователь управляет двумя инфоблоками, допустим, новостями, он должен иметь возможность редактировать только эти два инфоблока, а не 50 других инфоблоков в придачу.
Для чего это делается?
1. Для того, чтобы ограничить информацию для сотрудника, управляющего частью сайта, самой необходимой. Для чего сотруднику просматривать лицензионные ключи, хранимые в инфоблоке, если его задача - добавлять страницы с контентом?
Учетная запись любого пользователя может быть теоретически взломана:
- пароль может быть "подслушан" вирусом-трояном, находящемся на компьютере пользователя, и передан на другой компьютер (особенно актуально, если пользователям разрешено работать из дома);
- пароль пользователя подсмотрен другим пользователем;
- пользователь может записать пароль на листике и потерять листик, или записать пароль на мониторе;
- пароль может быть перехвачен внутри локальной сети
- слабый пароль может быть подобран методом перебора
2. Так вот, полученные привилегии не должны быть критичными для безопасности веб-проекта. Одно дело - изменить телефон, другое - изменить информацию в 100 инфоблоках, а 50 - удалить.
Нередко эта практика нарушается, и большинство пользователей работают над веб-сайтом с правами администратора, что чрезвычайно опасно.
3. Смотрим, какие группы определены в системе в разделе: "Настройки > Пользователи > Группы пользователей". Необходимо проверить доступы в каждой группе списка, кроме "Администраторы" (ее проверяем отдельно).
4. Для каждой группы на вкладке "Доступ" проверяем уровень доступа ко всем модулям системы. Если стоит уровень доступа "по умолчанию", проверяем что значит это уровень в настройках модуля: "Настройки > Настройки продукта > Настройки модулей > Название модуля > вкладка 'Доступ'", значение свойства "По умолчанию".
Обычно выбрано консервативное значение этого свойства, например "Доступ запрещен". Однако важно проверить, что его никто не поменял на иное. Разумеется, перед тем, как настраивать права группы на модули, следует изучить в документации, какие операции внутри модуля соответствуют выбранному уровню прав. Например, какие операции разрешены учетной записи при уровне доступа к модулю "Интернет-магазин": "Обработка заказов" - означает ли этот уровень доступа возможность просматривать лицевые счета Покупателей или нет и т.п.
5. Если группа имеет доступ к модулю "Управление структурой" на уровне "Редактирование файлов и папок", необходимо тщательно проверить, к каким файлам и папкам группе предоставлен доступ в разделе "Контент > Структура сайта > Файлы и папки". Если группа по ТЗ имеет право только на редактирование файлов в папке "/about/company", то нужно убедиться что она не может ничего сделать в других папках сайтов. Аналогично проверяется доступ к другим файлам: меню, шаблоны сайта и т.д.
6. Просматриваем каждый инфоблок в проекте и проверяем права групп на него: "Контент > Информ. блоки > Типы информ. блоков > Название инфоблока > вкладка 'Доступ'". Если группе нужна информация из инфоблока, должен стоять уровень "Чтение", но никак не "Изменение", что очевидно.
7. Проверяем правильность настроенных прав группы в административном разделе, для чего авторизуемся под учетной записью группы в административную часть "/bitrix/admin" (если в ТЗ предусмотрена работа пользователей в административном разделе).
Пользователь должен увидеть только то, на что ему даны права, допустим инфоблоки, некоторые папки с файлами, некоторые модули - и ничего лишнего. Иногда становится неожиданностью, что Покупатель магазина оказывается может зайти по адресу: "/bitrix/admin" и в административной части, например, отредактировать свой профиль и т.п. Если это не нужно, доступ в административную часть нужно ограничить.
8. Проверяем правильность настроенных прав группы в публичной части сайта, для чего авторизуемся под учетной записью группы на сайте и выполняем предусмотренные для группы операции.
Например, если группа редактирует страницы в определенных папках на сайте - учетная запись должна суметь выполнить данные операции без ошибок. Нередко проверяют работоспособность учетной записи, находящейся временно в группе "Администраторы", а когда учетную запись переводят в настроенную для нее группу - начинаются ошибки нехватки выделенных прав.
9. Проверяем количество учетных записей, находящихся в группе "Администраторы" - заходим в группу, смотрим на вкладке "Параметры" в подраздел "Пользователи в группе". Всем ли учетным записям в этой группе нужны административные права? Нередко в этой группе можно встретить "забытые" после интеграции учетные записи редакторов контента и т.п., что опасно.
10. Полезно проверить, какую информацию может найти на сайте пользователь в группе. Если в результатах поиска появляется "закрытая" для него информация - необходимо ограничить доступ группы к ней.
В результате аудита и тестирования настраиваются минимально необходимые для работы права групп, остаются только те административные учетные записи, которые действительно нужны и, соответственно, безопасность веб-решения существенно возрастает.
Удалены тестовые данные (QSEC0040).
Описание
Удалены тестовые учетные записи разработчиков. Удалены тестовые данные и страницы.
Как тестировать
Нередко во время разработки решения на платформе Bitrix Framework разработчики и тестировщики создают тестовые учетные записи типа "test/123456" с административными правами, тестовые группы с высокими привилегиями. Создаются и тестовые страницы типа "test.php", выводящие, например, список сумм на лицевых счетах Покупателей, информацию о конфигурации системы и другую внутреннюю информацию. Иногда создаются страницы, при заходе на которые пользователь, без ввода пароля, становится администратором. Или разработчики для упрощения отладки в коде проекта вставляют инструкции, отправляющие им на личный email информацию и данные о работе и ошибках и т.п.
Очень важно удалить временные учетные записи со слабыми паролями и тестовые страницы перед вводом решения в эксплуатацию - чтобы ими не воспользовались злоумышленники.
- Проверить отсутствие тестовых учетных записей и групп.
- Проверить, чтобы у оставшихся "не тестовых" учетных записей были "сильные" пароли, длиной не менее 8 символов и состоящие из букв разного регистра, цифр и знаков препинания.
- Проверить отсутствие тестовых страниц и файлов.
Настроены политики безопасности по работе с БД (QSEC0050).
Описание
Для соединения с базой данных на хостинге используется сильный пароль, настроены необходимые проекту привилегии для работы с базой данных (работа не под root).
Как тестировать
Для соединения с базой данных веб-проекта должен использоваться сильный пароль, состоящий из букв разного регистра, цифр и знаков препинания, длиной не менее 8 символов. Это снизит риск взлома учетной записи в базе данных.
В самой базе данных должна быть создана учетная запись, обладающая необходимыми для корректной работы с базой данных веб-проекта, привилегиями (т.е. не "root").
- Проверить пароль подключения к базе данных в файле: "/bitrix/php_interface/dbconn.php" (переменная "$DBPassword").
- Привилегии учетной записи проекта в базе данных проверяются системным администратором.
Отключен вывод ошибок и предупреждений посетителям проекта (QSEC0060).
Описание
Отключен вывод ошибок и предупреждений посетителям проекта: $DBDebug - отключен (dev.1c-bitrix.ru/api_help/main/general/magic_vars.php); Настройки/Настройки продукта/Настройки модулей/Главный модуль: Режим вывода ошибок" -> "Не выводить"
Как тестировать
Необходимо запретить вывод технических сообщений об ошибках, содержащих служебную информацию о внутренней конфигурации системы, посетителям веб-проекта.
- Проверить в файле подключения к базе данных "/bitrix/php_interface/dbconn.php" значение переменной: "$DBDebug = false". Это запретит вывод посетителям подробных сообщений об SQL-ошибках.
- В разделе "Настройки > Настройки продукта > Настройки модулей > Главный модуль > вкладка 'Настройки'" в списке "Режим вывода ошибок" должно быть выбрано значение "Не выводить" или в настройках PHP ("Настройки > Инструменты > Настройки PHP") параметр "display_errors" должен иметь значение "Off".
Настроен журнал системных событий (QSEC0070).
Описание
Настроен журнал системных событий.
Как тестировать
Для обеспечения адекватного уровня информационной безопасности веб-проекта рекомендуется настроить и проводить периодический аудит событий и инцидентов, зарегистрированных в "Журнале событий".
В журнал, в зависимости от настроек, могут попадать уведомления об обнаружении вирусов на веб-страницах, попытках взлома (зарегистрированных проактивным фильтром "Web Application Firewall"), изменениях разделов и элементов информационных блоков, действиях модераторов форума, авторизациях, регистрациях и изменении учетных записей и групп Пользователей, изменениях доступа к модулям и файлам и т.п.
Прежде всего, нужно настроить время хранения зафиксированных событий в "Журнале событий". Для этого необходимо в разделе "Настройки > Настройки продукта > Настройки модулей > Главный модуль", на вкладке "Журнал событий" установить значение параметра "Сколько дней хранить события".
Выбор значения определяется установленным для проекта интервалом аудита безопасности. К примеру, можно проводить совместно с системным администратором еженедельный аудит всех событий и ежедневный аудит событий, связанных с детектированием вирусов и попытками вторжений. В этом случае можно порекомендовать хранить события 2-4 недели.
Далее необходимо настроить типы событий, регистрируемых в "Журнале событий".
Выбираем типы событий главного модуля в разделе "Настройки > Настройки продукта > Настройки модулей > Главный модуль" на вкладке "Журнал событий", в группе "События для записи в журнал". Рекомендуется выделить все типы событий.
Включаем, при необходимости, Веб-антивирус и выбираем режим регистрации вирусных заражений: "Настройки > Проактивная защита > Веб-антивирус". На вкладке "Веб-антивирус" включаем его, на вкладке "Параметры" выбираем одно из действий при обнаружении вируса и интервал оповещения.
Включаем "Проактивный фильтр" и выбираем режим регистрации попыток вторжений: "Настройки > Проактивная защита > Проактивный фильтр". На вкладке "Проактивный фильтр" включаем защиту, на вкладке "Активная реакция" включить "Занести попытку вторжения в журнал". При необходимости можно дополнительно выбрать режим временного блокирования IP-адреса атакующего.
Выбираем, при необходимости, регистрируемые типы событий изменения информационных блоков для каждого информационного блока: "Контент > Информ. блоки > Типы информ. блоков" на вкладке "Журнал событий". Рекомендуется регистрировать события изменения особо важных для веб-проекта инфоблоков, например инфоблока с каталогом цен и т.п.
После настройки регистрируемых событий проводится их периодический аудит в "Журнале событий": "Настройки > Инструменты > Журнал событий". По выявленным инцидентам принимаются соответствующие меры.
- Проверяем, что включены режимы регистрации важных системных событий и инцидентов безопасности в настройках модулей платформы:
- "Настройки > Настройки продукта > Настройки модулей > Главный модуль" на вкладке "Журнал событий",
- "Настройки > Проактивная защита > Веб-антивирус" на вкладке "Параметры",
- "Настройки > Проактивная защита > Проактивный фильтр" на вкладке "Активная реакция",
- "Контент > Информ. блоки > Типы информ. блоков > Конкретный инфоблок" на вкладке "Журнал событий".
- Проверяем, что имеется согласованная процедура периодического аудита специалистами (в т.ч. системным администратором) записей в "Журнале событий" и определен перечень предпринимаемых действий при возникновении разных типов инцидентов.
Например, если обнаружена атака, системный администратор блокирует IP-адрес атакующего; если обнаружено заражение веб-страницы вирусом, определяется, когда и с чьего компьютера произошло заражение и компьютер сотрудника "лечится" классическим антивирусом и т.п..
- "Настройки > Настройки продукта > Настройки модулей > Главный модуль" на вкладке "Журнал событий",
- "Настройки > Проактивная защита > Веб-антивирус" на вкладке "Параметры",
- "Настройки > Проактивная защита > Проактивный фильтр" на вкладке "Активная реакция",
- "Контент > Информ. блоки > Типы информ. блоков > Конкретный инфоблок" на вкладке "Журнал событий".
Например, если обнаружена атака, системный администратор блокирует IP-адрес атакующего; если обнаружено заражение веб-страницы вирусом, определяется, когда и с чьего компьютера произошло заражение и компьютер сотрудника "лечится" классическим антивирусом и т.п..
Проверена безопасность кода (статический анализ уязвимостей) (QSEC0080).
Описание
Проверка кода на очевидные уязвимости.
Чтобы разобраться в возможных уязвимостях, почитайте про HTML-инъекции, XSS, SQL-инъекции, CSRF.
За одно можно позаботиться защитой от Clickjacking, об этом читайте в статье Настраиваем Битрикс для Яндекс метрики с включенной защитой от фреймов.
Производительность
Используется производительная конфигурация (QP0010).
Описание
Для обеспечения максимальной производительности использован пакет «1С-Битрикс: Веб-окружение» (для Windows и Linux), либо «1С-Битрикс: Виртуальная машина», либо выбран тарифный план для Битрикс, предоставляемый одним из рекомендуемых хостинг-партнеров. Используется двухуровневая конфигурация фронтенд-бекенд.
Как тестировать
Для эффективной и производительной работы веб-проекта на платформе Bitrix Framework необходимо настроить серверное программное обеспечение. К сожалению, настройки по умолчанию программ (веб-сервер, база данных и др.) в дистрибутивах операционных систем не предполагают работу веб-проекта с высокими нагрузками и интенсивную конкурентную нагрузку.
Для упрощения и ускорения процесса настройки серверного программного обеспечения на оптимальную производительность рекомендуется использовать:
- либо пакет "1С-Битрикс: Веб-окружение" (для Windows и Linux, мастер установки автоматически настраивает серверное программное обеспечение),
- либо "1С-Битрикс: Виртуальная машина" (настроенная на максимальную производительность операционная система),
- либо выбран тарифный план для Битрикс, предоставляемый одним из рекомендуемых хостинг-партнеров (хостер настроил серверное программное обеспечение на максимальную производительность).
Квалифицированный системный администратор, изучив вышеперечисленные продукты, может вручную настроить серверное программное обеспечение на оптимальную производительность. Главное - хорошо понять, почему сделана та или иная настройка и на что она влияет. Но проще и надежнее, конечно, использовать предварительно настроенные и протестированные конфигурации.
Если не уделить достаточное внимание данному вопросу, профессионально разработанное веб-решение на платформе Bitrix Framework может, по причине неадекватной настройки серверного программного обеспечения, работать медленно и с перебоями.
- Необходимо удостоверится, что веб-сервер настроен на максимальную производительность.
- Необходимо удостоверится, что кеширующий прокси сервер (nginx или аналог) настроен на максимальную производительность для раздачи статического контента веб-проекта. Наличие настроенного кеширующего прокси-сервера значительно увеличивает производительность веб-проекта и его устойчивость к нагрузкам.
- Необходимо удостоверится, что веб-сервер (с кеширующим прокси-сервером) при увеличении нагрузки до максимума не вызовет коллапс серверного программного обеспечения (при использовании веб-сервера apache максимально доступное число слотов соединений выбрано с учетом среднего размера процесса и объема оперативной памяти сервера), а выстроит запросы в очередь. Рекомендуется использование двухуровневой конфигурации веб-приложения: фронтэнд (nginx или аналог) - бэкэнд (apache, FastCGI и т.п.).
- Необходимо удостоверится, что база данных настроена оптимально, для MySQL:
- Используется формат таблиц InnoDB (для нагруженных веб-проектов)
- Размер innodb buffer pool выбран достаточным с учетом объема данных веб-проекта и размера оперативной памяти, размеры других буфферов и другие параметры базы данных настроены в соответствии с рекомендациями Bitrix Framework, дисковая подсистема сервера настроена на максимальную производительность либо значение "innodb_flush_log_at_trx_commit" ориентировано на высокую скорость и меньшую надежность.
- В разделе "Рабочий стол/Настройки/Производительность/Сервер БД" отсутствуют замечания (выделены красным) или их число минимально.
- При использовании всех возможных соединений с базой данных на сервере останется достаточный объем оперативной памяти (Глобальные буферы + Буферы подключений * Подключения).
Вышеуказанные тесты можно не выполнять, если для настройки был использован пакет "1С-Битрикс: Веб-окружение" (для Windows и Linux) или использована "1С-Битрикс: Виртуальная машина" или использован тарифный план рекомендуемого хостинг-партнера, оптимизированный для максимальной производительности платформы Битрикс.
PHP сконфигурирован оптимально (QP0020).
Описание
PHP сконфигурирован оптимально. В административном разделе: "Настройки/Производительность/Панель производительности/Конфигурация" в строке «Конфигурация PHP» в колонке «Оценка» должно появиться значение - «оптимально». Обязательно использование прекомпилятора PHP с адекватным объемом памяти – eaccelerator, xcache, apc, ZendOptimizer+ (часто используемые исполняемые файлы проекта должны помещаться в opcode-кеш прекомпилятора).
Как тестировать
Платформа написана на языке программирования PHP и от оптимальности его настроек напрямую зависит производительность веб-проекта. Одним из важнейших условий обеспечения максимальной скорости работы веб-сайта является наличие прекомпилятора PHP (APC, ZendOptimizer+, eAccelerator, XCache, WinCache) и его адекватная настройка.
Рекомендуется также настроить административную страницу прекомпилятора, позволяющую в режиме реального времени оценивать характеристики его эффективности и, при необходимости, корректировать их - например, подобрать адекватный объему файлов веб-проекта размер кеша прекомпилятора, отследить "лишние" файлы, занимающее место в кеше и т.п. Не менее важным фактором обеспечения производительности PHP является оптимальная настройка таких параметров, как "open_basedir" и "realpath_cache_size" и других.
- В административном разделе: "Настройки > Производительность > Панель производительности > Конфигурация" в строке "Конфигурация PHP" в колонке "Оценка" должно появиться значение - "оптимально". Если это не так, необходимо доработать конфигурацию PHP и его модулей, следуя рекомендациям продукта.
- Необходимо убедиться, что выделенный для PHP объем оперативной памяти достаточен для выполнения задач веб-проекта. Для этого обычно включают логирование ошибок PHP веб-сайта в отдельный файл и затем отслеживают в нем появление ошибок, связанных с недостатком памяти PHP. В случае появления ошибок, объем памяти для PHP (memory_limit) - увеличивают. Однако следует понимать, что если веб-страницы или скрипты потребляют слишком много памяти (как правило, значения превышающие 128М) - то они нуждаются в доработке и оптимизации.
Включено «автокеширование» (QP0030).
Описание
Включено «Автокеширование» в разделе «Настройки/Настройки продукта/Автокеширование/Кеширование компонентов».
Как тестировать
Данная настройка является одной из ключевых для обеспечения высокой производительности веб-проекта.
Для создания веб-страниц проекта используются "строительные блоки" - Компоненты, например: "Карта сайта", "Список новостей", "Детальная страница каталога" и сотни других. В большинстве случаев Компоненты обращаются за необходимой информацией в базу данных. Если ожидается достаточно активная посещаемость веб-проекта, то, очевидно, нагрузка на базу данных существенно возрастет (подробнее).
Самое простое и эффективное, что можно сделать для снижения нагрузки на базу данных и повышения скорости работы веб-проекта - использовать кеширование в Компонентах (подробнее).
В стандартных компонентах платформы Битрикс кеширование используется очень активно - поэтому они работают всегда на пределе эффективности. Необходимо также проследить, чтобы кеширование аналогично использовалось в доработанных и/или созданных специально для проекта Компонентов.
Кеширование всех Компонентов проекта включается/выключается в административном разделе - проверим это.
В разделе "Настройки продукта > Автокеширование > Кеширование компонентов" должно быть включено "Автокеширование".
Рекомендуется дополнительно проверить, чтобы во всех Компонентах веб-проекта стоял режим кеширования "Авто+Управляемое" или "Авто" с большим временем кеширования (иногда при разработке в Компоненте могут временно сменить тип кеширования с "Авто"/"Авто+Управляемое" на "Кешировать" или "Не кешировать", или поставить время кеширования слишком маленьким или нулевым - и забыть вернуть настройки обратно):
Платформа Битрикс настроена на максимальную производительность (QP0040).
Описание
Инфраструктура платформы сконфигурирована для максимальной производительности. В административном разделе: "Настройки/Производительность/Панель производительности/Битрикс" в колонке «Рекомендации» должны быть выполнены все рекомендации по улучшению производительности платформы. Название вкладки станет - «Битрикс (оптимально)».
Как тестировать
Иногда требуется настроить веб-проект на наивысшую производительность, пожертвовав некоторыми возможностям платформы Bitrix Framework. Например, отключив фиксацию числа показов баннеров или упростив алгоритм морфологического поиска и т.п. В разделе "Настройки > Производительность > Панель производительности > вкладка Битрикс" будет выведена информация об опциях платформы, которые можно отключить.
В административном разделе: "Настройки > Производительность > Панель производительности > вкладка Битрикс" в колонке "Рекомендации" должны быть выполнены все рекомендации по улучшению производительности платформы. Название вкладки станет - "Битрикс (оптимально)".
Производительность конфигурации - адекватна проекту (QP0050).
Описание
Производительность конфигурации адекватна требованиям проекта и составляет #N# (#расшифровка#)* - «Настройки/Производительность/Панель производительности/Конфигурация»:- Нажимаем «Тестировать конфигурацию»;- Результат после проведения замеров появляется в колонке «Оценка» строки «Конфигурация»;* «Низкая» – (<=15), «Удовлетворительная» - >15 и <30, «Высокая» - >=30.
Как тестировать
Производительность конфигурации является обратной величиной к среднему времени "отработки" ядра платформы (1/ "Среднее время отклика"). Т.е. чем правильнее выполнены настройки системы: PHP, базы данных, файловой системы, кеширования и, чем "мощнее" аппаратная конфигурация, тем выше будет данный показатель.
Рекомендуется действовать в следующем порядке:
- На имеющейся аппаратной конфигурации провести тщательную оптимизацию настроек программного обеспечения, согласно нашим рекомендациям и добиться максимального показателя производительности конфигурации.
- Если, несмотря на проведенную в п. "а" оптимизацию, не удается добиться приемлемого значения производительности конфигурации, рекомендуется увеличить "мощность" аппаратной конфигурации.
- Для высоконагруженных веб-проектов рекомендуется добиться высокой производительности конфигурации (30 и выше) перед введением решения в эксплуатацию, а затем делать периодические замеры производительности конфигурации (не менее раза в месяц), стараясь поддерживать ее высокое значение путем анализа и оптимизации "тяжелых" веб-страниц, оптимизации таблиц в базе данных и т.п.
В разделе: "Рабочий стол > Настройки > Производительность > Панель производительности > Конфигурация" нажимаем "Тестировать конфигурацию". Результат после проведения замера появляется в колонке "Оценка" строки "Конфигурация".
Мы считаем производительность "низкой" при значении 15 и =30. Дополнительно рекомендуется ознакомиться с производительностью конфигурации (строка "Производительность" в таблицах тарифов) в списке сертифицированных и рекомендуемых хостинг-партнеров 1С-Битрикс: http://www.1c-bitrix.ru/partners/hosting.php
Тестировать сервер желательно в момент, когда на нем нет посетителей. Потому что хиты на сайте занимают ресурсы и оценка получается ниже.
Выполнен нагрузочный тест пиковой производительности (QP0060).
Описание
Выполнен нагрузочный тест максимальной производительности проекта - "Настройки/Производительность/Панель производительности/Масштабируемость" с исходными данными:- Начальное количество одновременных соединений = 1;- Конечное количество одновременных соединений = 5;- Шаг увеличения одновременных соединений = 1;- Максимальная продолжительность теста = 5 минут;- Страница = главная проекта (например - /index.php); Время генерации страницы не должно превышать 0.5 секунды и не должно деградировать при увеличении количества одновременных соединений во время теста. Число ошибок должно быть равно нулю. Минимальное число страниц в секунду должно соответствовать ожидаемой пиковой посещаемости проекта в сутки (хитов в сутки), деленной на 86400. Минимальное время получения страницы не должно превышать 1 секунды.
Как тестировать
Нередко требуется оценить максимальную производительность веб-проекта. Сколько можно "выжать" из данной конфигурации, не вызвав эффекта замедления загрузки веб-страниц в браузер посетителя?
Например, веб-проект был оптимизирован под высокую нагрузку и размещен на производительном аппаратном обеспечении. Нагрузочное тестирование веб-проекта показало адекватные результаты при эмулируемой посещаемости в 3 000 000 хитов в сутки: время генерации страницы на сервере в среднем 0.5 сек., время загрузки страницы в браузер посетителя в среднем 1 сек. Интересно, а каков предел производительности?
После выполнения данного теста можно узнать, к примеру, что предел производительности на текущей аппаратно-программной конфигурации составляет 5 500 000 хитов в сутки со средним временем генерации страницы на сервере 1 сек., и средним временем загрузки страницы в браузер посетителя - 3 сек. Данное значение позволяет рассчитывать на стабильную работу системы при всплесках нагрузки.
Выполнен нагрузочный тест максимальной производительности проекта - " Настройки > Производительность > Панель производительности > Масштабируемость" с исходными данными:
- Начальное количество одновременных соединений = 1
- Конечное количество одновременных соединений = 5
- Шаг увеличения одновременных соединений = 1
- Максимальная продолжительность теста = 5 минут
- Страница = главная веб-проекта (например - /index.php). Можно выбрать любую посещаемую страниц веб-проекта.
Время генерации страницы не должно превышать 0.5 секунды и не должно серьезно расти при увеличении количества одновременных соединений во время теста. Число ошибок должно быть равно нулю. Минимальное число страниц в секунду должно соответствовать ожидаемой пиковой посещаемости проекта в сутки (хитов в сутки), деленной на 86400. Время получения страницы не должно превышать 1 секунды.
Выполнен аудит производительности страниц (QP0070).
Описание
Выполнен аудит производительности основных страниц проекта: - На административной странице «Настройки/Производительность/Панель производительности» нажимаем «Тестировать производительность» в течение 10 минут; - Кликаем по основным страницам публичной части. Рекомендуется привлечь к тестированию как можно больше сотрудников или использовать инструменты нагрузки типа JMeter; - После завершения теста анализируем результаты на вкладке «Разработка»: результаты в колонке «Среднее время (сек)» не должны превышать 0.5 сек, в колонке «Ошибки разработки» не должно быть сообщений об ошибках.
Как тестировать
Даже если во время разработки веб-проекта постоянно думать об оптимизации и производительности и следить за тем, что:
- компоненты не выполняют в режиме автокеширования запросы к базе данных;
- в кеше компонентов не сохраняются лишние данные и объем кеша не превышает 1МБ;
- в теле компонентов не выполняются интенсивные вычисления и не практикуется интенсивное использование больших объемов оперативной памяти (подобные операции не должны выполнятся в момент построения страницы для передачи в бразуер Посетителя; рекомендуется их выносить в периодические cron-операции, выполняемые в фоновом режиме или по технологии асинхронных очередей)
То все равно остается риск "просачивания" медленных веб-страниц и компонентов в проект - из-за ошибки программиста, наложения внутренних технических сценариев выполнения веб-страницы, которые сложно спроектировать и предусмотреть заранее, непредвиденных эффектов совместной работы серверного программного обеспечения и т.п.
Для максимальной защиты веб-проекта от нестабильной работы при увеличении нагрузки, повышения запаса производительности, проверки устойчивости системы - настоятельно рекомендуется провести нагрузочное тестирование веб-проекта.
Для получения близких к реальным условиям эксплуатации результатов, желательно загрузить в веб-проект ожидаемый объем тестовых данных. Например, если в системе ожидается 2 миллиона учетных записей, 100 000 товаров в 10 000 разделах и форум, хранящий миллион сообщений с посещаемостью 500 000 хитов в сутки - необходимо импортировать в веб-проект тестовые данные в данном объеме. Также, что очевидно, следует проводить нагрузочные испытания на серверном оборудовании идентичном или максимально приближенном к реальному.
Сценарии нагрузочного тестирования различаются по степени сложности и варьируются от кратковременного коллективного тестирования веб-проекта сотрудниками компании ("коллеги, сегодня с 16 до 16:10, пожалуйста, походите по сайту, выполняя следующие действия …") до комплексных имитаций пользовательских цепочек на сайте с использованием таких инструментов, как JMeter, WAPT и т.п. Вот пример методики организации и проведения нагрузочного тестирования. В "крайнем" случае, при недостатке времени, можно провести "экспресс" нагрузочное тестирование после запуска веб-проекта в эксплуатацию и оперативно исправить возникшие недостатки.
- Убеждаемся, что веб-проект заполнен тестовыми данными в объеме, приближенном к реальным условиям эксплуатации и тестирование проводится на аппаратной конфигурации ,приближенной к реальной.
- На административной странице в разделе "Настройки > Производительность > Панель производительности" нажимаем "Тестировать производительность" в течение 10 минут (или более, для получения более качественных результатов).
- Создается нагрузка на веб-решение: или по сайту ходят сотрудники компании, выполняя заранее описанные действия, или хотят реальные пользователи, или нагрузку создает инструмент типа JMeter, WAPT и т.п. Желательно, чтобы уровень нагрузки и ее характер был приближен к реальному. Например, если ожидается миллион хитов в сутки, нужно постараться создать данную нагрузку.
- Во время нагрузки на веб-проект необходимо самостоятельно пройти по нескольким цепочкам и визуально оценить следующее:
- страницы веб-проекта открываются быстро, не зависают
- изображения веб-страницы загружаются визуально быстро.
- После завершения нагрузочного теста анализируем результаты на вкладке "Разработка" (Настройки > Производительность > Панель производительности):
- Просматриваем список "20 самых нагружающих страниц".
- Результаты в колонке "Среднее время (сек)", отображающие время построения страницы на сервере, не должны превышать 0.5 сек. Результаты в 1 и более секунды говорят либо о недостаточно оптимизированной веб-странице/конфигурации PHP, либо о недостаточной производительности аппаратной конфигурации - в общем, требуют вмешательства и исправления.
- В колонке "Ошибки разработки" не должно быть сообщений об ошибках. Найденные ошибки требуют исправления.
Расставлены индексы на инфоблоки 2.0 (QP0080).
Описание
Расставлены индивидуальные индексы в инфоблоках 2.0 для увеличения скорости выборки данных.
Как тестировать
Для хранения относительно большого числа объектов в инфоблоке во многих случаях целесообразно воспользоваться режимом хранения объектов инфоблока в отдельной таблице (технология "Инфоблоки 2.0"). Причем для изменения типа хранения объектов в инфоблоке практически не нужно модифицировать приложение (т.е. в большинстве случаев тип хранения можно поменять и после запуска веб-решения).
Хранение объектов инфоблока в отдельной таблице позволяет существенно уменьшить нагрузку на базу данных, сложность и число SQL-запросов, снизить до минимума операции присоединения таблиц - т.к. значения скалярных свойств объекта инфоблока хранятся в одной записи таблицы. Фактически для каждого инфоблока со своим набором свойств создается отдельная SQL-таблица.
Однако, если ожидается высокая частота запросов к данному инфоблоку с фильтрацией по определенным свойствам, эти свойства хорошо известны на фазе аналитики и проектирования, можно значительно повысить скорость запросов и снизить нагрузку на базу данных если добавить на эти свойства индексы в базе данных. При обновлениях платформы Битрикс добавленные индексы будут сохранены.
Ускоряя выборки из базы данных путем добавления индексов, не следует забывать о необходимости периодической оптимизации таблиц и индексов. Операцию можно выполнять периодически в разделе "Настройки > Инструменты > Оптимизация БД".
- На этапе проектирования, как правило, принимается решения хранить определенные объекты веб-проекта в инфоблоках 2.0.
- После выявления типичных запросов к данным веб-приложения, например: выборка описания товара по его идентификатору (70%), выборка списка товаров в разделе каталога (10%), фильтрация товаров по производителю (5%) и т.п., для каждого инфоблока 2.0 определяются свойства, по которым наиболее часто ожидается выполнение фильтрации. Например, в инфоблоке товаров ожидается интенсивная фильтрация по свойству привязки товара к инфоблоку производителей или по дополнительному коду сертификации и т.п.
Теперь необходимо проверить, что в таблице, хранящей значения свойств инфоблока товаров, имеется индекс на свойство на свойство, хранящее связь с инфоблоком производителей. В разделе "Контент > Информ. блоки > Типы информ. блоков > Товары" находим идентификатор свойства привязки на вкладке "Свойства" (первая колонка "ID") и на вкладке "Инфоблок" находим значение идентификатора инфоблока (свойство "ID"). Затем находим в базе данных таблицу, хранящую значения свойств инфоблока товаров. Таблицы называются по шаблону: "show create table b_iblock_element_prop_s#ИД инфоблока#", например "b_iblock_element_prop_s1" (s - таблица хранит значения скалярных свойств, m - таблица хранит множественные значение свойств).
Теперь нужно проверить, чтобы на нужное нам в таблице свойство был добавлен индекс. Выполняем запрос в разделе "Настройки > Инструменты > SQL запрос" (пример синтаксиса для MySQL):
show create table b_iblock_element_prop_s1
Возвращается структура таблицы, например:
CREATE TABLE `b_iblock_element_prop_s1` ( `IBLOCK_ELEMENT_ID` int(11) NOT NULL, `PROPERTY_11` text collate utf8_unicode_ci, `DESCRIPTION_11` varchar(255) collate utf8_unicode_ci default NULL, `PROPERTY_12` decimal(18,4) default NULL, `DESCRIPTION_12` varchar(255) collate utf8_unicode_ci default NULL, `PROPERTY_13` int(11) default NULL, `DESCRIPTION_13` varchar(255) collate utf8_unicode_ci default NULL, `PROPERTY_14` int(11) default NULL, `DESCRIPTION_14` varchar(255) collate utf8_unicode_ci default NULL, PRIMARY KEY (`IBLOCK_ELEMENT_ID`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci
Свойство привязки хранится в нашем случае, например, в колонке `PROPERTY_13`. Как видим, ключ в таблице пока только один:
"PRIMARY KEY (`IBLOCK_ELEMENT_ID`)".
Добавляем индекс на колонку:
alter table b_iblock_element_prop_s1 add index ix_prop13 (PROPERTY_13)
Теперь выполнив "show create table b_iblock_element_prop_s1" увидим добавленный на свойство индекс:
KEY `ix_prop13` (`PROPERTY_13`)
Более подробную информацию об индексах в таблице можно получить, выполнив запрос: "show indexes in b_iblock_element_prop_s1". Аналогично при необходимости добавляются индексы в таблицу, содержащую множественные значения свойств инфоблока. Таким образом, необходимо проверить наличие индексов на все интенсивно фильтруемые свойства инфоблоков, хранимых в формате "2.0".
- Необходимо удостовериться, что периодически выполняется оптимизация таблиц базы данных (и соответственно индексов) в разделе "Настройки > Инструменты > Оптимизация БД" или средствами системного администрирования (например автоматически). Частота оптимизации определяется объемом хранимых данных и интенсивностью их изменения/добавления. Нередко встречается практика оптимизации всех таблиц базы данных раз в месяц в период минимальной посещаемости веб-проекта.
Настроен веб-кластер в соответствии с руководством (QP0100).
Описание
Настроен и сконфигурирован веб-кластер в соответствии с руководством (для высоконагруженных проектов или систем, которым требуется высокая надежность).
Как тестировать
Перед настройкой веб-кластера для достижения высокой производительности и/или отказоустойчивости рекомендуется внимательно прочитать наши методические материалы, посмотреть статьи с примерами архитектур в зависимости от типа и требований веб-проекта.
Не следует сразу пытаться использовать все доступные возможности, предлагаемые веб-кластером и "стрелять из пушки по воробьям". Чем сложнее система, тем, как известно, ей труднее управлять. Рекомендуется взвешенный итерационный подход, при котором архитектура веб-кластера настраивается в несколько этапов, например:
- Изучаем руководство по настройке, статьи и примеры архитектур существующих проектов.
- Настраиваем кеширование данных в memcached, анализируем и выбираем оптимальный размер кеша (например, 128М в каждом запущенном сервере memcached).
- Настраиваем второй сервер приложений, синхронизацию контента с помощью csync (или другой технологии).
- Подключаем ко второму и остальным серверам приложений одну из систем мониторинга.
- Настраиваем балансировщик, SSL-терминацию (если необходимо), режим распределения сессий между серверами приложений: а) сессии общие и хранятся в базе данных, б) сессии пользователей распределяются в зависимости от их IP-адресов и хранятся отдельно и т.д.
- Настраиваем SQL репликацию. При необходимости используем вертикальный шардинг.
- И т.п.
- Необходимо удостоверится, что технические специалисты ознакомились с руководством по настройке веб-кластера и примерами имеющихся архитектур веб-кластерных решений на Битрикс.
- Необходимо удостоверится, что выбранная реализация архитектуры веб-кластера соответствует поставленным задачам по обеспечению доступности и/или производительности: аргументированно выбрано количество серверов приложений, режим работы балансировщика, режим репликации и число серверов базы данных и т.п. Рекомендуется составить мини-ТЗ, описывающее архитектуру веб-кластера с учетом требований данного веб-проекта.
Размещение на хостинге
Введена информация о хостинге (QH0010).
Описание
Введена информация о хостинге, тарифном плане и аппаратной конфигурации проекта.
Как тестировать
При размещении реализованного веб-проекта в сети Интернет чрезвычайно важно подобрать адекватную типу проекта и ожидаемым нагрузкам конфигурацию сервера/серверов, хостинг-провайдера. Рекомендуется пользоваться тарифными планами сертифицированных хостинг-провайдеров.
Тарифный план хостинг-провайдера должен быть сертифицированным для использования платформы Битрикс. Аппаратная конфигурация сервера(ов) должна соответствовать ожидаемым нагрузкам (настоятельно рекомендуется предварительное проведение нагрузочного тестирования на объеме данных, приближенным к реальным).
Вводится информация о хостинге и аппаратной конфигурации системы: тип сервера, тип и мощность процессоров, объем оперативной памяти, тип рейд-контроллера и режим его работы (используется ли батарейка для кеширования записи), объем и тип жестких дисков, скорость сетевого интерфейса, операционная система.
Тут не всем бывает понятку куда ввести информацию о хостинге. Ввести её надо прямо в поле комментария теста.
Настройки хостинга - оптимизированы под Битрикс и проект (QH0020).
Описание
Для правильной настройки программного обеспечения хостинга использован пакет «1С-Битрикс: Веб-окружение» (для Windows и Linux), либо «1С-Битрикс: Виртуальная машина», либо выбран тарифный план для Битрикс, предоставляемый одним из хостинг-партнеров.
Как тестировать
Необходимо либо самостоятельно оптимально настроить серверное программное обеспечение хостинга для веб-проекта, либо выбрать предварительно настроенный и оптимизированный под Bitrix Framework хостинговый тариф. Для обеспечения максимальной производительности рекомендуется выбрать тариф из списка рекомендуемых хостингов.
Для правильной настройки программного обеспечения хостинга обычно используется "1С-Битрикс: Веб-окружение" (для Windows и Linux), либо "1С-Битрикс: Виртуальная машина", либо хостинговой компанией производятся аналогичные настройки.
Чем выше ожидаемая нагрузка на веб-проект, тем с более высокой производительностью рекомендуется выбрать хостинговый тариф. Рекомендуется провести нагрузочное тестирование веб-проекта с близким к ожидаемому объемом тестового контента.
- Хостинговый тариф находится в списке рекомендуемых хостингов.
- Производительность выбранного хостингового тарифа соответствует веб-проекту, что подтверждено проведенным нагрузочным тестированием на объеме данных, приближенном к ожидаемому.
Тесты окружения платформы - пройдены (QH0030).
Описание
Отсутствуют замечания в разделе "Инструменты/Проверка системы" на вкладках: "Тестирование конфигурации", "Проверка доступа (полная проверка)".
Как тестировать
Платформа имеет встроенный набор автотестов для проверки внешнего программного окружения. Для корректной работы веб-проекта все тесты должны успешно выполниться.
В разделе " Настройки > Инструменты > Проверка системы":
- На вкладке "Обязательные параметры" - все требования должны быть выполнены, иначе корректная работа веб-проекта не гарантируется.
- На вкладке "Проверка доступа" - нужно пройти полную проверку. Не должно быть замечаний. Защищенные от записи файлы/папки нужно вынести за пределы веб-проекта.
- На вкладке "Тестирование конфигурации" - должны быть успешно выполнены все требования. В случае замечаний рекомендуется обратиться в службу технической поддержки Битрикс.
Если во время проверки появились замечания, их необходимо обязательно устранить ДО запуска веб-проекта.
Настроена передача IP-адреса клиента (QH0040).
Описание
При использовании двухуровневой конфигурации (напр. nginx+apache или балансировщика на веб-кластере) в модуль «Веб-аналитика» передается корректный IP-адрес клиента.
Как тестировать
При использовании многоуровневой конфигурации веб-приложения (frontend-backend, балансировщик) необходимо настроить корректную передачу IP-адреса клиента в веб-проект. Для этого часто используется техника установки HTTP-заголовка (X-Real-IP, X-Forwarded-For) на балансировщике или кеширующем прокси-сервере, а затем извлечение данных из этого заголовка в веб-сервере (mod_rpaf и т.п.) или веб-приложении.
В разделе "Настройки > Инструменты > Настройки PHP" проверяем значение параметра _SERVER["REMOTE_ADDR"]. Оно должно соответствовать вашему IP-адресу. Также, можно получить значение определяемого веб-проектом IP-адреса клиента в разделе: "Настройки > Проактивная защита > Защита административного раздела".
Выполняется резервное копирование (QH0050).
Описание
Проверено, что настроено и выполняется систематическое резервное копирование файлов и базы данных проекта.
Как тестировать
Веб-проект на платформе Битрикс хранит информацию:
- в файловой системе
- в базе данных (подробнее о структуре данных платформы можно прочитать тут).
Сделать копию всей информации веб-проекта можно вручную в административном разделе: "Настройки > Инструменты > Резервное копирование".
Однако для постоянной защиты данных проекта от потери в случае сбоев программного обеспечения и/или аварии оборудования настоятельно рекомендуется автоматизированное резервное копирование файлов и базы данных проекта как минимум один раз в сутки. Для обеспечения более высокой надежности и доступности веб-проекта рекомендуем воспользоваться технологиями веб-кластера.
- Необходимо убедиться, что делается периодическое резервное копирования файлов проекта и информации из базы данных.
Например, если резервное копирование делается вручную, то в разделе "Настройки > Инструменты > Резервное копирование" должны находиться резервные копии веб-проекта за определенное время (например, за неделю), а последняя резервная копия не должна быть старше, например, суток.
Если резервное копирование должно выполняться автоматизировано системными инструментами или хостером, необходимо убедиться, что резервные копии веб-проекта - действительно делаются - например, попросить показать их. Кроме этого, рекомендуется проследить, что процесс резервного копирования внезапно не "сломается" (т.е. существует система мониторинга подобной ситуации) или его по какой либо причине перестанут выполнять после сдачи чеклиста контроля качества внедрения.
- Необходимо удостовериться, что сохраненные в резервной копии данные:
- можно считать и
- можно восстановить из них веб-проект.
Резервное копирование может быть "настроено", но сохраняться будут не все данные веб-проекта, либо искаженные данные и т.п. Для уменьшения риска возникновения подобной ситуации рекомендуется периодически выполнять "учения по восстановлению", на которых восстанавливать веб-проект из резервной копии на отдельном сервере и проверять его работоспособность.
- Следует понимать, что если делать резервное копирование информации веб-проекта раз в сутки, то при восстановлении проекта могут быть потеряны все накопленные данные за последние сутки. Если для веб-проекта недопустимо терять, допустим, заказы интернет-магазина, финансовые транзакции и т.п. - рекомендуется настроить, при использовании базы данных MySQL, процесс репликации (подробнее).
Если критична потеря файлов проекта: загруженных документов/изображений, созданных веб-страниц за, к примеру, последние сутки, рекомендуется либо делать более частое резервное копирование файловой системы либо, если объем данных велик, использовать технологию "снепшотов" файловой системы (LVM, некоторые файловые системы: http://en.wikipedia.org/wiki/Comparison_of_file_systems, специализированные хранилища, сервисы в облачном хостинге aws.amazon.com и т.д.).
Например, если резервное копирование делается вручную, то в разделе "Настройки > Инструменты > Резервное копирование" должны находиться резервные копии веб-проекта за определенное время (например, за неделю), а последняя резервная копия не должна быть старше, например, суток.
Если резервное копирование должно выполняться автоматизировано системными инструментами или хостером, необходимо убедиться, что резервные копии веб-проекта - действительно делаются - например, попросить показать их. Кроме этого, рекомендуется проследить, что процесс резервного копирования внезапно не "сломается" (т.е. существует система мониторинга подобной ситуации) или его по какой либо причине перестанут выполнять после сдачи чеклиста контроля качества внедрения.
- можно считать и
- можно восстановить из них веб-проект.
Резервное копирование может быть "настроено", но сохраняться будут не все данные веб-проекта, либо искаженные данные и т.п. Для уменьшения риска возникновения подобной ситуации рекомендуется периодически выполнять "учения по восстановлению", на которых восстанавливать веб-проект из резервной копии на отдельном сервере и проверять его работоспособность.
Если критична потеря файлов проекта: загруженных документов/изображений, созданных веб-страниц за, к примеру, последние сутки, рекомендуется либо делать более частое резервное копирование файловой системы либо, если объем данных велик, использовать технологию "снепшотов" файловой системы (LVM, некоторые файловые системы: http://en.wikipedia.org/wiki/Comparison_of_file_systems, специализированные хранилища, сервисы в облачном хостинге aws.amazon.com и т.д.).
Настроена почтовая подсистема хостинга (QH0060).
Описание
Настроена почтовая подсистема хостинга. Успешно отправлено тестовое письмо через API платформы Битрикс.
Как тестировать
Веб-проект отправляет почтовые сообщения (email): уведомления о регистрации пользователя, о новом заказе и т.п. - используя средства операционной системы. Если процесс отправки почты не настроен или неправильно настроен, то отправленные веб-проектом письма могут попадать в спам, иметь некорректные заголовки и не доходить по Клиентов веб-сайта.
- Если в вашей редакции установлен модуль "Подписка, рассылки", то необходимо создать в разделе "Сервисы > Рассылки > Выпуски" тестовый выпуск, желательно с вложениями, и отправить его себе. Затем следует тщательно проанализировать заголовки полученного письма и доработать вместе с системным администратором, при необходимости, конфигурацию подсистемы отправки почты сервера.
- Если в вашей редакции не установлен модуль "Подписка, рассылки", можно отредактировать свою учетную запись и включить при сохранении чекбокс "Оповестить пользователя" (либо инициировать другое уведомление) - в этом случае вам придет письмо с уведомлением и проанализировать его.
- Можно попросить разработчика отправить вам тестовое письмо средствами PHP.
- Если отправленное письмо не приходит, вероятно, оно попало в спам.
Как проверить:
- Заходите в админке в Настройки - Инструменты - Командная PHP строка
- Вводите код:
echo CEvent::Send('USER_INFO', 's1', [
'EMAIL' => 'ваш@email.com',
'MESSAGE' => 'Тестовое сообщение'
])
Где ваш@email.com - ваша электронная почта, s1 - ID любого активного сайта.
4. Нажимаете Выполнить
5. Должно вывестить число и в почтовом ящике через несколько минут появиться письмо.
Если письма долго нет, проверьте папку Спам.
Я отправляю письма на свою почту на яндексе, там есть некоторые полезные метки:
- У письма должен быть зеленый знак замка
- При клике на замок в должен быть текст о том, что есть подпись и используется шифрование
Если замок красный, требуются доработки, иначе ваши письма часто будут уходить в спам.
Сдача проекта
Лицензионный ключ активирован (QJ0010).
Описание
Лицензионный ключ активирован, загружены исходные тексты ядра.
Как тестировать
Перед вводом веб-решения в эксплуатацию должен быть активирован лицензионный ключ используемой редакции "1С-Битрикс: Управление сайтом". Для обеспечения максимальной надежности и производительности, получения нового функционала рекомендуется также настройка периодической проверки обновлений и их установка.
При соблюдении стандартов интеграции и требований данного чеклиста контроля качества внедрения - установка обновлений платформы Bitrix Framework не нарушает работоспособность эксплуатируемого веб-проекта.
- В разделе "Настройки > Настройки продукта > Настройки модулей > Главный модуль" на вкладке "Система обновлений" проверяется наличие введенного лицензионного ключа.
Там же настоятельно рекомендуется проверить настройку периодичности проверки обновлений ("Автоматически проверять наличие обновлений"), т.к. в обновлениях исправляются ошибки, улучшается производительность и добавляется новый функционал. Рекомендуется проверять наличие обновлений каждый день.
- В разделе "Настройки > Обновления", подразделе "Ответ сервера обновлений" выводится подробная информация о лицензионном ключе, редакции продукта и доступном периоде обновлений.
- Подробную информацию о лицензионном ключе можно также посмотреть на странице регистрации и проверки лицензионного ключа:
Там же настоятельно рекомендуется проверить настройку периодичности проверки обновлений ("Автоматически проверять наличие обновлений"), т.к. в обновлениях исправляются ошибки, улучшается производительность и добавляется новый функционал. Рекомендуется проверять наличие обновлений каждый день.
Ядро проекта не модифицировалось (QJ0020).
Описание
Ядро проекта не модифицировалось. В любое время можно обновить платформу через систему обновлений, не нарушив работоспособности проекта.
Как тестировать
При создании решения на базе платформы Bitrix Framework не допускается модификация ядра платформы, т.к. это не позволит периодически обновлять платформу без угрозы нарушения работоспособности веб-проекта.
Иногда ядро платформы пытаются модифицировать не подозревая, что существуют встроенные технологии (обработчики событий), позволяющие добавить недостающий/изменить функционал без модификации ядра.
Если добавить/модифицировать функционал через события не получилось, то можно создать свой модуль, реализующий любой требуемый веб-проекту функционал - опять-таки без модификации ядра платформы Bitrix Framework.
- Используя данные от инструментов разработки (средства контроля версий файлов и базы данных) или автоматизированный тест, следует удостовериться, что ядро платформы Bitrix Framework не модифицировалось.
- Рекомендуется также после окончания работ по интеграции обновить платформу по технологии SiteUpdate до последней версии модулей и протестировать работоспособность решения.
Категорически запрещается производить доработки путем правки ядра. Это битрикс и проверяет.
Делает он это так:
- Определяет установленную версию всех модулей
- Получает контрольные суммы файлов с сервера битрикс, согласно версий модулей.
- Сверяет файлы на сайте согласно контрольным суммам.
Если Битрикс говорит что у вас есть модифицированные файлы, попробуйте найти бекап сайта (важно чтобы сайт в бекапе был той же версии, что и у вас), и взять файлы оттуда.
Введена информация об интеграторе решения (QJ0030).
Описание
Введена информация о партнере (произвольное текстовое поле и логотип) или компании, которая провела интеграцию и внедрение решения на платформе Битрикс.
Как тестировать
Проверить, что в файле /bitrix/php_interface/this_site_support.php введена контактная информация о Партнере, интегрировавшем данное решение.
В файл /bitrix/php_interface/this_site_support.php следует сохранить контент примерно следующего содержания:
Техподдержка: <a href="https://r-morozov.ru/" target="_blank">Моя компания</a>
После ссылка появится в футере на всех страницах:
Еще на рабочем столе есть виджет с информацией о сайте, если у вас такой есть, туда тоже следует ввести информацию о техподдержке.
Введена информация о техподдержке проекта (QJ0040).
Описание
Введена информация о техподдержке проекта (произвольное текстовое поле и логотип). Обычно техподдержку добавленного к платформе функционала оказывает Партнер 1С-Битрикс, который провел интеграцию решения.
Как тестировать
После ввода веб-проекта в эксплуатацию нередко у Заказчика сразу приходят идеи по оперативной доработке и развитию функционала, иногда возникают ошибки, требующие быстрого исправления. Разработка новых возможностей и исправление ошибок, как известно, должны проводиться отдельно от эксплуатируемого веб-решения, аккуратно тестироваться на отдельных конфигурациях и только после этого "выкладываться" в публичный доступ.
Для решения вышеперечисленных и других задач нередко пользуются услугой "Техническая поддержка" Партнера, сделавшего интеграцию веб-решения на платформе Bitrix Framework. Если планируется работа с другим Партнером, то ему обычно передается созданная на этапе интеграции техническая документация по архитектуре и эксплуатации веб-решения.
Исправления ошибок в ядре и новый функционал платформы Bitrix Framework доступны через систему обновлений SiteUpdate (после активации/продления лицензионного ключа, в течение года). Можно, например, договориться с Партнером, чтобы он проводил обновления платформы веб-решения в рамках услуги технической поддержки самостоятельно. Исправления модулей Партнера, как вариант, могут осуществляться через систему обновлений в Marketplace ("Настройки > Marketplace > Сторонние обновления").
Проверить, что в файле /bitrix/php_interface/this_site_support.php введена контактная информация о Партнере, оказывающем техническую поддержку веб-проекта.
Достаточно настроить предыдущий пункт QJ0030, после можно отмечать пройденым.
После прохождения теста
Когда все обязательные тесты будут пройдены, Битрикс предложит заполнить форму с данными человека, который проходил монитор.
После заполнения формы, отчет еще не отправится в Битрикс. Форма выше сохраняет монитор, изменить далее какой-то тест уже будет нельзя.
После, на странице монитора качества, у вас будет такая таблица:
Тут можно посмотреть статус тестов, нажав кнопку "подробности", кнопка Отправить отчет в «1С-Битрикс», снова ничего не отправляет, а открывает форму
Тут надо указать контактные данные клиента, который заказывал у вас сайт. Если вы делали сайт себе - пройти полностью монитор не получится.
Прежде чем заполнять форму с данными клиента, требуется создать карточку проекта в кабинете партнера на сайте Битрикс на странице https://partners.1c-bitrix.ru/personal/projects/
После можно заполнять форму, скрин которой выше. В форме есть поле, где можно указать время для звонка, вот только проблема - нет выбора даты. Из битрикс могут позвонить как через день, так и через неделю - с этим не угадаешь.
После прохождения опроса клиента монитор полностью пройден, вам добавятся баллы в кабинете партнера Битрикс.
Что далее?
Для чего нужны баллы в кабинете Битрикс?
Система баллов в партнерской программе компании «1С-Битрикс» введена для объективного представления компании в рейтинге партнеров и повышения статуса партнера с Бизнес-партнера на Сертифицированный партнер или с Сертифицированного партнера на Золотой сертифицированный партнер.
Что дает участие в программе помимо возможности построить внутренний процесс повышения качества?
За каждый проект, который вы сдадите по программе мониторинга качества, вам будут начислены баллы. Количество баллов зависит от редакции продукта, на которой был реализован проект. Например, 5 для "Старта", 28 для "Малого бизнеса" и т.п.
Кроме того, участие партнера в программе мониторинга качества внедрений отражается на его месте в общем рейтинге партнеров.
Из двух партнеров с одинаковыми параметрами, выше в списке будет выводиться тот, кто является участником программы.
Для клиентов, которые выбирают себе будущего разработчика по списку партнеров на нашем сайте, также предусмотрена подсказка: партнеры - участники программы - отмечены специальным знаком.
Надо ли иметь последнюю версию Битрикс для прохождения монитора качества?
Нет, последняя версия не требуется. Можно сдавать даже старые сайты, но важно что должна быть активна лицензия.
При этом минимальная версия модуля main для прохождения монитора - 12.0.5. На более старой у вас попросту не получится отправить отчет.
