Разработка и поддержка интернет-магазиновработаем так, чтобы магазин опережал конкурентов

Технологии и фреймворки

Программно-аппаратная часть сервиса, отвечающая за функционирование его внутренней части.

Пользовательский интерфейс, видимая пользователям часть сайта или приложения

TESTRAIL (REST API)

Отчётность и логи

Java / Python / C#

Уже на старте проекта мы знакомим Заказчика с командой.

Типичный состав:

• менеджер проекта
• аналитик
• технический писатель
• 2-3 программиста
• арт-директор + дизайнер
• 1-2 QA-специалиста.

Менеджер — центральное звено проекта: помнит всё, отвечает за всё и остаётся с Вами при дальнейшем развитии проекта.

Как обычно, всё это поддерживается топ-менеджментом: техническим- и аккаунт-директорами.

Старт проекта

Аналитика и предпроектное исследование

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

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

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

Проводим анализ систем веб-аналитики и технического состояния сайта на предмет ошибок интерфейса и функционала, составляем список рекомендаций.

Техническое задание и прототипы

Мы берём интервью у рабочей группы заказчика, собираем брифы и общаемся с IT-службой клиента.

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

Методология разработки

Разработка ведётся по одной из 3 методологий:

1. Последовательная модель разработки:

   • ТЗ
   • прототипы
   • дизайн
   • верстка
   • программирование
   • 2 цикла тестирования и сдача.
     Пример: портал HOFF Time с несколькими интеграциями, онбордингом и геймификацией. Запустили портал за 5 месяцев.

2. Параллельная модель разработки:

   • отрисовав только главную страницу сайта, мы уже отдаем ее на верстку.
   • сверстав половину макетов — начинаем их внедрение.
     Позволяет сэкономить срок в два раза, но и стоит на 50-100% дороже.
     Пример: eCom для VIVO — параллельная разработка сайта и личного кабинета + параллельное выполнение этапов работ (2 и 3 месяца соответственно на сайт и ЛК).

3. Гибкая методология, Agile:

   • идеально подходит для корпоративных порталов, где правильнее утверждать и делать по одной задаче, чем полгода проектировать то, что к моменту утверждения устареет.
     Agile состоит из недельных спринтов, причем каждую неделю можно управлять разработкой и менять вектор развития проекта.
     Пример: Личный кабинет Центра Международной Торговли — 2 месяца первичной разработки и далее постепенное встраивание новых интеграций и бизнес-процессов.

Сдача проекта и сопровождение

Мы пишем специальный документ: программу и методику испытаний. По ней проводится сдача системы. Также при сдаче проекта мы пишем автотесты (Selenium), далее в Allure смотрим наглядные отчеты по их прохождению.

Нагрузочное тестирование выполняется на сервере Заказчика, мы используем Яндекс.Танк и еще ряд сервисов.

После сдачи мы сопровождаем проект, используя Jenkins для continuous integration — непрерывной отгрузки обновлений, и GIT для контроля версий.

Контроль рисков

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

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

При сдаче проекта мы применяем как автоматическое, так и ручное тестирование, чтобы все предусмотреть.

Интеграция сайта с 1С и другими системами

На этом этапе мы работаем с IT-службой Заказчика: разрабатываем API обмена, проектируем каналы обмена данными. Результат: одно- или двусторонний обмен с 1С, ERP, AXAPTA, SAP и еще 20+ менее известными системами учета и автоматизации.

Интеграция с CRM

Мы настроим Вам CRM (Битрикс24, AMOCrm или RetailCRM), после чего у Вас будут детальные отчеты по продажам, «нарезка» по разным типам Клиентов — для SMS и e-mail рассылок, а также аналитика по прибыли в разрезе источников рекламы и типов товаров/услуг.

DevOps и highload

У нас свои инженеры DevOps: построим оптимальную схему развертывания обновлений, настроим кластер, проведем нагрузочное тестирование. А после запуска проекта – обеспечим надзор 24/7.

Стандарты качества

С помощью соблюдения внутренних стандартов нам удается поддерживать высокое качество продуктов.

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

Ниже приведены (частично) регламенты из наших внутренних документов.

Регламент качества кода

Установка продукта. Настройка основной площадки перед началом работ

Перед стартом начала работ важно правильно настроить основную площадку (main), чтобы при создании площадок для разработки уже всё было настроено.

Становка и проверка bitrix перед стартом работ

Сразу после установки необходимо в robots.txt прописать правило:

#Все другие правила удалить – запрещена индексация сайта; во время запуска сайта файл должен быть изменен (должны быть запрещены к индексации только системные папки, такие как bitrix, upload, auth и т.п.).

Становка модуля миграций сущностей БД

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

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

Становка и настройка GIT на проекте

Становка и настройка PHP Linter на проекте

В современных реалиях без GIT не может существовать не один проект, даже очень маленький. Все аргументы разработчиков не использовать GIT говорят лишь о незнаниях данной системы и о низкой квалификации данного разработчика. GIT — это не только правило хорошего тона, но и суровая необходимость современного подхода к разработке. Сразу после установки надо установить GIT на проект и настроить правильно .gitignore. Пример настройки .gitignore:

### Становка и настройка PHP Linter на проекте

На каждом проекте в обязательном порядке устанавливается — Linter: Code Sniffer.

Правила разработки продукта

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

### Равила написания PHP-кода на проекте.

В общем случае обязательно использование API Bitrix (вместо PHP-кода). Если у bitrix есть функционал заменяющий чистый PHP, то надо использовать именно первое. Пример: $\_GET, $\_POST, $\_REQUEST - использовать запрещено! Прямые запросы к БД - использовать запрещено! 

При разработке использовать ядро D7, т.к. старое ядро устарело и битрикс настаивает на использовании именно его. Названия переменных должны быть осмысленные, переменных типа a, tempconst и т.п. быть не должно. ПРОВЕРКА: достаточно посмотреть /local/php_interface/ – и файлы php внутри. В компонентах недопустимо использовать ID-инфоблоков и ID-свойств. Необходимо динамически через хелпер получать по коду инфоблока или по коду свойства ID инфоблока или свойства (про свойство если такое надо) Необходимо придерживаться строгому регламенту стиля написания кода – Регламент по стилю написания кода (ТО) Придерживание MVC-подхода, если такой не противоречит общим правилам разработки Bitrix.

### Инфоблоки и их создание и настройка

### Настройка инфоблока
В настройках инфоблока необходимо выбирать хранение свойств в отдельной таблице. Все инфоблоки – каталог, новости и т.п., должны быть изначально настроены с ЧПУ (автоматическая транслитерация русских слов), используя штатные средства Битрикс.

#### Проверка
1. Контент – инфоблоки – типы инфоблоков.
2. Поле URL страницы детального просмотра и URL раздела – адреса должны быть ЧПУ-вида (без знаков вида ?ID=#ID#).
3. При создании нового инфоблока настроить административную панель: 
   - Отображение только реально применяемых свойств.
   - Группировка свойств, если применимо.
   - Назвать свойства понятно, например: описание товара в карточке товара.

### Аблоны сайта и интеграция верстки
Разработка на сайте ведется в папке /local, папка /bitrix должна быть в .gitignore. Удалить все ненужные страницы и разделы перед началом работы. 

#### Проверка
1. В разделе Настройки - Сайты посмотреть используемые шаблоны.
2. Проверить и описать лишнее в папке /bitrix/templates/.
3. При интеграции вёрстки разместить файлы стилей, скриптов, картинок в папке шаблона.
4. Изменения в файлы css верстальщика вносить нельзя, создавать новый файл для стилей.
5. Блоки типа телефона, рекламного текста сделать включаемой областью.

### Одули (свои и стандартные – все)
В модулях использовать сервисный подход.

### Омпоненты (свои и стандартные – все)

В компонентах недопустимо использовать ID-инфоблоков и ID-свойств. Необходимо динамически через хелпер получать по коду инфоблока или по коду свойства ID инфоблока или свойства (про свойство если такое надо). При интеграции шаблона компонента на сайт необходимо поддерживать интерфейс «Эрмитаж» (чтобы в режиме редактирования сайта можно было удалять, редактировать и добавлять элементы ИБ прямо на сайте, вне админки). ПРОВЕРКА: в режиме редактирования идем на страницу с инфоблоками – списки элементов, деталки элемента. При наведении мышки кроме штатной «шестеренки» настроек компонента должны появляться кнопки «добавить» «редактировать», «удалить» элемент. Пространство имен должно называться extyl-pro’ Нестандартные модули и компоненты должны быть кратко документированы. Пример: Компонент extyl-pro:news.list (/local/components/), отличается от стандартного тем, что собирает данные из двух инфоблоков и внешней RSS-ленты. ПРОВЕРКА: идем в папку /bitrix/components/ – внутри, кроме папок «bitrix» не должно быть иных папок. Исключение – сторонние модули Marketplace. Смотрим их наличие в ТЗ или уточняем у менеджера проекта. Все собственные компоненты создаём в папке /local/components/extyl-pro/* Необходимо избегать кастомизацию компонентов в тех ситуациях, когда есть возможность обойтись без неё. В папке local/components/bitrix/ – не должно быть пространства имён bitrix ПРОВЕРКА: пробежаться по нестандартным компонентам – по названию должно быть понятно, где используются, и сравнить с ТЗ – где действительно они нужны.

Ормы обратной связи и т.п.

Формы обратной связи и т.п. запросов – все – должны работать через модуль «Вебформы». В шаблонах web-форм не должно быть привязки к id-полей форм. ID-ники должны проставляться динамически. При переносе настроек web-форм мигратором id-на площадке разработки и бою будут различаться. Во всех формах нажатие кнопки «Enter» должно приводить к отправке формы, если в конце формы есть одна кнопка отправки (т.е. нет выбора отправить так или эдак). ПРОВЕРКА: зайти в «Сервисы» и далее соответственно в веб-формы или в баннеры. Увидеть там все формы и все баннеры сайта.

Аннеры

Все баннеры и т.п. сменяющиеся элементы (например, фон экрана) – должны работать через модуль «Баннеры». Исключения оговариваются до реализации, а не после.

Апча

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

Аиболее частые ошибки

Перед стартом работ Тимлид в обязательном порядке оценивает (в часах) предстоящие работы.

Код-ревью на проектах

Код-ревью на проектах закреплен отдельным регламентом, который не противоречит общепринятыми правилами разработки.

Промежуточные тестирования и тестирования перед сдачей проекта

Если в процессе тестирования делается заказ или регистрируется пользователь или заполняется формочка – обязательно в заказе/ФИО/форме писать «Тест», «Тестовый» и т.д. При создании страниц и разделов необходимо указывать их заголовки. Например, если создаётся раздел сайта «Новости», то в свойствах раздела и страницы следует указать название «Новости». ПРОВЕРКА: проверяем заголовки страниц сайта, чтобы не было ерунды и они не были пустыми.

Астройки пользователей пользователей для проведения тестирования

Пароль у главного администратора не должен быть простым. ПРОВЕРКА: простой пароль – это «123123», пароль, равный адресу почты и т.д. При необходимости – сменить пароль самостоятельно, отписать в задачу. Для синхронизации с 1С создается ОТДЕЛЬНЫЙ пользователь, по имени которого ясно, зачем он существует. ПРОВЕРКА: запросить менеджера, какой аккаунт используется для синхронизации с 1С. Лишние пользователи к моменту сдачи проекта должны быть удалены. ПРОВЕРКА: посмотреть, что по каждой группе, кроме «обычных» юзеров, есть не более 1 пользователя (учитывая, разумеется, пункт выше про 1С-пользователя). Группы пользователей должны соответствовать ТЗ — лишние должны быть удалены.

Естирование скорости работы сайта

При сдаче проекта должны быть включены критические настройки сайта – 3.1. Перед проведением тестирования на сайте проверка критически важных настроек bitrix. Если ТЗ предусмотрен композит, то необходимо удостоверится, что он работает. ПРОВЕРКА: в настройках – автокэширование. Композит – внизу любого композитного сайта должен висеть шильдик («Быстро с 1С-Битрикс»). Если он не висит, то композит не работает. Работу композита нужно проверить установкой в браузер Chrome расширения "Bitrix Composite Notifier".

Роверка оптимизации запросов к БД

При сдаче проекта необходимо запустить отладку количества запросов к БД и объем используемого кеша. В интернет-магазине на главной странице под кешем, если больше 20 запросов к БД, то нужно оптимизировать кеширование и сами запросы. Без кеша более 200 запросов считается уже много. Избыточный кеш у компонента может так же тормозить проект, т.к. перед выводом система его парсит. У каждого показатели запросов и использования кода могут разнится в зависимости от ситуации. На картинке ниже мы видим, что можно отследить как общую статистику, так и статистику по каждому отдельному компоненту.

Роверка оптимизации изображений на сайте

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

Роверка общего размера страницы на сайте

Вес страницы может зависеть от размера изображений, видео, js и css файлов. Пример проверки скорости загрузки и веса страницы. Если общий вес страницы превышает 2 мегабайта (усредненное значение), в редких случаях за 5 и более, то изображения и скрипты не оптимизированы.

Роверка общей производительности разделов и скорости работы сайта штатными средствами bitrix и использовании JMeter. Обязательный минимум

Инструкция по установке — https://loadtestweb.info/2017/10/17/install-apache-jmeter/ . В офисе уже есть заряженный компьютер для нагрузочного тестирования. Если есть проблемы с установкой JMeter, то можно воспользоваться им (в том числе удаленно).

Одготовка сценария тестирования для JMeter

Пример запросов (для интернет-магазинов запросы должны содержать в том числе значения умного фильтра):

"GET /delivery/ "GET /pay/ "GET /exchange-and-return/ "GET /about/ "GET /offer/ "GET /catalog/ "GET /catalog/metallicheskie-kanaly/legkie-listovye-lotki-s3-combitech/ "GET /catalog/metallicheskie-kanaly/legkie-listovye-lotki-s3-combitech/lotok-perforirovannyy-50kh50-l3000/ "GET /catalog/molniezashchita-i-zazemlenie/ "GET /catalog/molniezashchita-i-zazemlenie/vneshnyaya-molniezashchita-i-zazemlenie-jupiter/ "GET /catalog/molniezashchita-i-zazemlenie/vneshnyaya-molniezashchita-i-zazemlenie-jupiter/?PAGEN_1=2 "GET /catalog/molniezashchita-i-zazemlenie/vneshnyaya-molniezashchita-i-zazemlenie-jupiter/?PAGEN_1=4 "GET /catalog/metallicheskie-kanaly/provolochnye-lotki-f5-combitech/filter/price-base-from-56/section-is-%D0%B0%D0%BA%D1%81%D0%B5%D1%81%D1%81%D1%83%D0%B0%D1%80%D1%8B%20%D0%B4%D0%BB%D1%8F%20%D0%BC%D0%BE%D0%BD%D1%82%D0%B0%D0%B6%D0%B0/etim_ef000008-is-44/apply/ "GET /catalog/metallicheskie-kanaly/provolochnye-lotki-f5-combitech/filter/clear/apply/ "GET /catalog/molniezashchita-i-zazemlenie/vneshnyaya-molniezashchita-i-zazemlenie-jupiter/soedinitel-prutok-polosa-57kh80-mm/ "GET /catalog/molniezashchita-i-zazemlenie/vneshnyaya-molniezashchita-i-zazemlenie-jupiter/khomut-na-metallicheskie-truby-d20-80-mm/ "GET /catalog/molniezashchita-i-zazemlenie/vneshnyaya-molniezashchita-i-zazemlenie-jupiter/

Апуск процесса тестирования

Проходим следующие тесты:

Интеграция стандартных компонентов и модулей:

Интеграция собственных компонентов и модулей:

Бщие нюансы проверки всех сайтов

Список товаров: должны быть предусмотрены ситуации, когда товара нет в наличии, или когда нет цены – или товар не показывается, или отображается иконка/заглушка. Также в тестовых целях должны быть представлены (если есть в ТЗ): товар со старой ценой, акционной ценой, спецпредложение (шильдик в углу фотки товара или что-то подобное) – то есть все виды «спец» товаров. Карточка товара: должны быть предусмотрены ситуации, когда какое-либо из полей не заполнено. Также не должно быть пустых вкладок (если в карточке товара есть вкладки).

Проверка работы системы после переноса сайта на бой

Соблюдены все правила — 3.1. Перед проведением тестирования на сайте проверка критически важных настроек bitrix.

Роверка правильности настройки robots.txt и sitemap.xml на бою

Необходимо, что бы на бою был корректно настроен robots.txt и sitemap.xml сразу как заказчик даст отмашку открыть сайт для индексации поисковыми роботами. Можно уточнить у менеджера.

Правило оценки задач

Если вы выполняете задачу с чужой оценкой, то вы согласны с ней.

Правила разработки проектов

Chrome, Firefox, Safari, Edge

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

По умолчанию должна быть обеспечена поддержка двух последних версий браузеров.

Сайт должен быть адаптивный

Дополнительные требования для SPA проектов

Контроль версий проекта: регламент работы с GIT

Перед началом работы

Мы работаем строго с GIT. Без GIT работа не производится.

Требования по настройке git

На общем хосте (main) должна быть включена ветка stage. Ветка master используется только для боевого хоста. Использовать только для перехода на новую строку. Проверьте, чтобы .gitignore был правильно настроен. Пример настройки .gitignore:

Если в .gitignore положили всю папку /bitrix, но нам нужно работать с каким-то шаблоном, то его можно вернуть в git при помощи: !/bitrix/templates/learning_10_0_0/ .gitignore может быть изменен и дополнен в зависимости от потребностей проекта. В GIT не должны попадать отладочные скрипты, логи, медиафайлы регистрируемые в БД и др. Все наработки проверяет тимлид / старший программист проекта. Уточнять главного программиста у менеджера. Разработчик не меняет в обход тимлида ветки master, stage, layout-master, layout-stage и ветки, созданные другими разработчиками. 1 разработчик – 1 хост. Если на проекте должно одновременно работать несколько разработчиков, то количество хостов на проекте должно быть равно количеству разработчиков + 1 (общий хост на который сливаются все изменения). За этим следит менеджер проекта, и ему надо сообщать, если требование не соблюдается. Все наработки разработчика сначала вливаются в stage, затем в master. Ничего не вливается сразу в master. Все новые ветки для выполнения новых задач начинаются от текущего stage. Доставкой изменений на бой занимается тимлид на проекте или его старший программист проекта.

Про перенос наработок и деплоев

Во вторник и четверг обязательный слив всех наработок в удаленный репозиторий. Наработки сливаются по мере готовности и в обязательном порядке во ВТ и ЧТ, даже если не закончен блок. Ответственный за контроль – Тимлид. Исполнитель данного мероприятия – разработчик. Разработчик до 19:00 во вторник и четверг должен отправить все наработки в репозиторий. Тимлид, в зависимости от потребности проекта, может изменить частоту обязательных сливов в репозиторий. Сделать чаще. Реже нельзя. Если нет дополнительных требований от тимлида, то обязательные сливы в репозиторий во вторник и четверг. За нарушение данного требования будет произведено депремирование. Если между дедлайнами сливов был непрерывный простой, то данное требование не работает.

Еплои на бой

Дни для деплоя – Пн, Вт, Ср, Чт с 10:00 до 16:00. Пт с 10:00 – 15:00. Исключения возможны только при выполнении срочных задач и по согласованию с менеджером проекта.

Создание и актуализация новой ветки перед выполнения новой задачи

Правила именования веток описаны в пункте 6. Актуализируем локальную ветку stage из удаленного репозитория. Cоздаем локальную ветку для разработки от stage.

Правила переноса наработок на бой

Название веток должны содержать номер задачи и чек-лист, в рамках которой выполняется работа и пункт чек-листа. То есть при выполнении задачи, ветка будет выглядеть следующим образом: ih/номерЗадачи-ЧекЛист/краткоеОписаниеЗадачи

Пример правильно названной ветки: ih/54361-3/updateCatalogStyles В ветках важно в коммитах писать номера задач и чек-листов: git commit -m "task-22333, buglist-1,2"

Сли чек-листы маленькие и эти чек-листы не надо по отдельности переносить

Название веток должны содержать номер задачи. То есть при выполнении задачи, ветка будет выглядеть следующим образом: ih/номерЗадачи/краткоеОписаниеЗадачи

Пример правильно названной ветки: ih/54361/updateCatalogStyles В ветках важно в коммитах писать номера задач и чек-листов git commit -m "task-22333, buglist-1,2"

Азвание ветки с багами

#Данная ветка используется при массовой починке багов ih/54361/bugFix

Редельная ситуация при названии ветки

В случае, если работа по какой-то причине не привязана к конкретной задаче, именование следующее: ih/годмесяц/краткоеОписаниеЗадачи Пример альтернативно названной ветки если нет задачи под неё: ih/2107/checkoutRefactoring

Если редактируемый файл не правильно отформатирован (PSR, переносы)

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

Работа с версткой и стилями

Бэкендер не правит прямо в back-end ветке стили или вёрстку. Для работы с версткой используется отдельный репозиторий. Соблюдение правил работы со сборщиками.

Уточнения к правилам переноса правок на бой (частный случай к пункту 5)

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

Надо находиться в ветке, в которую хотите перенести коммит командой git cherry-pick коммит. Если переносимого коммита нет в вашем локальном git, то надо сперва подтянуть изменения из других веток к себе в гит (команда в вашу ветку из других веток ни чего не вольёт) git fetch origin git fetch – забирает данные в ваш локальный репозиторий, но не сливает их с какими-либо вашими наработками и не модифицирует то, над чем вы работаете в данный момент. Вам необходимо вручную слить эти данные с вашими, когда вы будете готовы.

Команды, полезные тимлиду

Команда полезная, но не простая. После этого не получится push изменения в репозиторой. Сперва придется сделать pull и решить конфликты в добавленном файле

Иное

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

Общие требования

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

Идентификация и аутентификация

Для идентификации пользователей при доступе каждому пользователю должен быть назначен уникальный персональный идентификатор.

Доступ пользователей должен осуществляться посредством парольной аутентификации.

Должна обеспечиваться защита обратной связи при вводе аутентификационной информации.

Локальная парольная политика должна удовлетворять требованиям:

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

Авторизация пользователей на доступ должна производиться только после прохождения процедур идентификации и аутентификации.

Поддержка механизмов многофакторной аутентификации.

Управление доступом

Должна использоваться система ролевого управления доступом для управления правами доступа пользователей Поддержка возможности наследования прав доступа.

Подсистема разграничения доступа должна позволять предоставлять права доступа в минимально необходимом объеме.

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

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

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

Должно обеспечиваться ограничение неуспешных попыток входа.

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

Регистрация и учет событий ИБ

Наличие механизмов регистрации и учета событий ИБ.

Должен быть предусмотрен централизованный интерфейс для работы с журналами событий безопасности.

Подсистема регистрации и учета событий ИБ должна обеспечивать:

Должен использоваться уникальный идентификатор для каждого типа событий.

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

При превышении установленного периода, выделенного для хранения журналов регистрации событий ИБ, должна производиться перезапись событий.

Журналы событий ИБ должны быть защищены от несанкционированного просмотра и внесения изменений.

Защита программного обеспечения

Должна поддерживаться совместная работа с антивирусным программным обеспечением.

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

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

Все встроенные учетные записи должны иметь возможность блокировки.

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

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

Обеспечение целостности

Обеспечение контроля целостности на уровне программных компонент и файлов конфигураций.

Должна иметься возможность реализации в отказоустойчивом исполнении.

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

Сетевая безопасность

Должно обеспечиваться безопасное сетевое взаимодействие (возможность фильтрации) между компонентами.

Должно обеспечиваться безопасное сетевое взаимодействие (возможность фильтрации) с внешними системами.

Криптографическая защита

Пароли (ключи) от УЗ должны храниться и передаваться в зашифрованном/хешированном виде.

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

Должно обеспечиваться шифрование канала связи на уровне доступа пользователя.

Должно обеспечиваться шифрование канала связи при внутрисистемном взаимодействии компонент.

Возможность интеграции с существующей инфраструктурой открытых ключей.

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

Контроль НДВ

Отсутствие НДВ, выявляемых методами анализа исходного кода (применимо при наличии исходного кода).

Отсутствие НДВ, выявляемых методами статического и динамического анализа ПО.

Чем мы выделяемся

Клиенты видят всю команду в системе Интранет: все задачи, чеклисты, отчеты и обсуждение. Договоренности фиксируются в задачах, информация не теряется (в отличие от почты или телефона).

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

Без взломов и утечек данных

В 2022 получили лицензии ФСБ и ФСТЭК (деятельность по технической защите конфиденциальной информации) и готовы строить защищенные системы или провести аудит вашей. За 16 лет работы компании у нас не было ни одного случая взлома или утечки информации.

В каких случаях мы наиболее эффективны

посчитаем смету и дадим рекомендации по архитектуре.

Работаем так, чтобы магазин опережал конкурентов

минут скорость реакции на новую задачу

часа, чтобы начать работу над новой задачей

параметров магазина можем улучшить

рост конверсии после редизайна карточки товаров

ускорили работу карточки товара, оптимизировав SQL-запросы

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

Генеральный директор Kanzler

Решаем важные задачи для интернет-магазина

Внедрение нового функционала

Обеспечение актуальности цен и остатков

Ускорение загрузки страниц

Отслеживание и быстрое исправление ошибок

Автоматизация работы с маркетплейсами

Помогаем ecom-проектам увеличить конверсию и прибыль командой профессионалов

максимальная скорость реакции

от постановки задачи до старта работ

в неделю на связи с клиентом

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

Работаем по выстроенным процессам в «Яндекс.Трекере», чтобы видеть общую картину, следовать срокам и учитывать пожелания клиента.

Предлагаем идеи для развития проекта, тестируем задачи и гипотезы, снимаем метрики, сравниваем результаты — принимаем решения, основываясь на данных.

Соблюдаем стандарты разработки по PSR, работаем через Git, делаем код-ревью, ведем документацию, улучшаем кодовую базу.

Стабильная работа и SLA

время реакции на инцидент

время промежуточных статусов

max время решения инцидента

Мониторим доступность сервера каждую минуту.

Технологии: Yandex.Cloud, Selectel

Отслеживаем ошибки в программном коде

Снижаем время неопределенности проблем и сроков их решения для менеджеров и клиентов.

Ежедневно и в автоматическом режиме проверяем стабильность ключевых узлов магазина имитируя поведение пользователя. Трехэтапное тестирование на реальных устройствах Win, PC, Mac, мобильных устройствах и эмуляторах.

Технологии: Cypress, Ghost Inspector, BrowserStack

Рост конверсии

Каждая задача измерима. Все гипотезы оцениваются до и после реализации

Сделаем UX/UI аудит магазина

Аудит покажет точки роста, по которым можно контролировать разные аспекты сайта и выдвигать гипотезы по его улучшению

Аудит с отметкой по 4-балльной шкале по каждому пункту. Будет видно работа над какими узлами проекта покажет наибольший результат.

Аудит с гипотезами для улучшения сайта. На выходе — список задач для развития сайта.

Бесшовно подключаемся к команде проекта

Умеем настроить работу с текущей командой на проекте: инхаус или совместно с другим подрядчиком.

Золотой сертифицированный партнер Битрикс

Опыт работы с десятками магазинов на CMS 1С-Битрикс — разработка интернет-магазина как с нуля, так и поддержка крупных проектов.

Оставьте заявку

Расскажите о задаче, мы проведем исследование проекта и предложим решение