Биллинг, вокруг
которого строится
оператор связи

СОДЕРЖАНИЕ

АННОТАЦИЯ

Программа для ЭВМ «АСР Биллинг — коммерческая комплексная программная платформа для реализации электронно-цифровых сервисов» (далее — Биллинг) создается в целях предоставления виртуальным операторам услуг сотовой связи возможности управлять номерной емкостью, пользователями, финансами, тарифами и услугами через интернет. Биллинг состоит из отдельных модулей, реализующих различные функции системы и независимых друг от друга. Каждый модуль Биллинга имеет собственный программный интерфейс на основе API, позволяющий осуществлять интеграцию модулей между собой и с внешними системами.

В результате развития ЭС будет содержать следующие подсистемы:

• Подсистема управления номерами

• Подсистема управления финансами

• Подсистема управления тарифами

• Подсистема управления дилерами

• Подсистема управления задачами

• Подсистема управления складом

• Подсистема создания отчетов

• Подсистема администрирования

• Подсистема управления кол-центром

• Подсистема управления масками

• Подсистема управления категориями номеров

• Подсистема перевыпуска номеров

1. Архитектура и Инфраструктура

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

Масштабируемость

Биллинг работает на сервере под управлением Linux:

Debian 8 Linux

Ubuntu 18.04 или выше

1.2 Основные подсистемы

В настоящее время реализован функционал следующих подсистем ЭС:

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

Подсистема управления финансами

Подсистема управления тарифами

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

Подсистема управления задачами

Подсистема управления складом

Подсистема создания отчетов

Подсистема администрирования

Подсистема управления кол-центром

Подсистема управления масками

Подсистема управления категориями номеров

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

2. Процессы жизненного цикла программного обеспечения

2.1 Жизненный цикл ПО

Жизненный цикл разработки ПО основан на ГОСТ 34.601-90.

Формирование требований к программному обеспечению

• Обследование объекта и обоснование необходимости создания ПО

• Построение бизнес-процессов, которые будут автоматизированы при внедрении ПО

• Формирование бизнес-требований к разрабатываемому ПО

• Формирование требований к элементам системы

• Формирование требований к дизайн-системе ПО

• Формирование требований к среде разработки ПО

• Формирование требований к архитектуре ПО

• Предварительный анализ сроков по реализации ПО

Разработка технического задания

• Разработка и утверждение технического задания на создание ПО

• Определение рабочей группы, ответственной на разработку

• Построение плана-графика по отчетным встречам разработки ПО

Эскизный проект

• Разработка предварительных проектных решений по системе и её частям

• Разработка документации и комментирование кода

Рабочая документация

• Разработка рабочей документации на АС и её части

• Разработка API методов

Разработка и адаптация программ

Разработка методов, сервисов, программ

Настройка сетевой безопасности

Подготовка резервированной БД

Подготовка пресс-релизной версии

Аудит ПО на предмет соответствия требованиям

Тестирование ПО

Тестирование безопасности

Функциональное тестирование

Тестирование производительности

Юзабилити-тестирование

Подготовка отчета о тестировании

Ввод в эксплуатацию

• Обучение персонала

• Сбор обратной связи от персонала

Сопровождение ПО

• Выполнение работ в соответствии с гарантийными обязательствами

• Послегарантийное обслуживание

2.2 Данные о процессе разработки ПО

Данные о персонале, задействованном в процессе разработки, приведены в главе 4.

Аппаратная среда разработки описана в главе 2.4.

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

2.3 Процессы поддержки ПО, в которые вовлечены разработчики

• Процесс управления документацией

• Определение критериев для сопровождения документации

• Актуализация и доработка документации при изменении ПО

• Управление конфигурацией ПО

• Контроль модификаций и версий ПО

• Подготовка технической документации по релизу версии ПО

• Исправление ошибок и нестыковок с новыми версиями стороннего ПО

• Плановая модернизация

2.4 Рекомендуемые ТТХ ПК

Разработка ведется в изолированном сегменте офисной сети с 9 АРМ разработчиков и одним выделенным сервером.

Аппаратная часть:

Язык программирования, применявшийся при разработке ПО — PHP 7.4 и выше, фреймворк Yii2.

Среда разработки ПО:

Изолированная подсеть на основе ОС Ubuntu 20.04, в составе сервера, 9 АРМ программистов.

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

Минимальные требования к системе:

• Процессор, 4-х ядерный;

• 4 Gb RAMM доступной памяти на 1 ядро системы;

• 100Gb SSD;

Поддерживаемые ОС:

Debian 8 Linux

Ubuntu 18.04 или выше

Необходимое ПО сторонних производителей:

Open-source Mysql MariaDB

Open-source ПО GrayLog

GIT (с системой автоматической установки и обновления кода через GitLab)

Composer

Docker

Операционные системы:

Windows (10, 11)

Mac OS (Big Sur, Monterey, Ventura).

Языки программирования:

PHP 7.4 и выше

Используемые библиотеки:

"bezlimit/models": "~2.1",

"bezlimit/package-notify": "~1.1",

"bezlimit/yii2-grid": "1.0.8",

"bezlimit/yii2-theme": "1.0.4",

"bezlimit/package-mobile-api": "~1.1",

"bezlimit/package-dictionary": "~1.1",

"bogdaan/viber-bot-php": "^0.0.14",

"bower-asset/bootstrap": "3.4.1",

"bower-asset/bootstrap-duallistbox": "4.0.1",

"bower-asset/bootstrap-timepicker": "0.5.2",

"bower-asset/chart.js": "2.9.1",

"bower-asset/cropperjs": "1.5.6",

"bower-asset/devbridge-autocomplete": "1.4.10",

"bower-asset/dropzone": "4.3.0",

"bower-asset/fancybox": "3.5.7",

"bower-asset/jquery.easy-pie-chart": "2.1.6",

"bower-asset/jstree": "3.3.8",

"bower-asset/leaflet": "1.5.1",

"bower-asset/raty": "2.7.0",

"bower-asset/seiyria-bootstrap-slider": "9.7.0",

"creocoder/yii2-nested-sets": "0.9.0",

"enqueue/amqp-lib": ">=0.9.14",

"ext-curl": "*",

"ext-iconv": "*",

"ext-intl": "*",

"ext-json": "*",

"ext-mbstring": "*",

"ext-mysqli": "*",

"ext-openssl": "*",

"ext-simplexml": "*",

"ext-soap": "*",

"kartik-v/yii2-date-range": "1.7.1",

"kartik-v/yii2-detail-view": "1.8.2",

"kartik-v/yii2-editable": "1.7.8",

"kartik-v/yii2-export": "1.4.0",

"kartik-v/yii2-field-range": "1.3.5",

"kartik-v/yii2-grid": "~3.3",

"kartik-v/yii2-mpdf": "^1.0",

"kartik-v/yii2-password": "1.5.4",

"kartik-v/yii2-widget-datepicker": "1.4.7",

"kartik-v/yii2-widget-typeahead": "1.0.4",

"kartik-v/yii2-widgets": "3.4.1",

"longman/telegram-bot": "^0.70.1",

"mlocati/ip-lib": "1.9.0",

"php": ">=7.4",

"phpoffice/phpspreadsheet": "1.17.1",

"phpoffice/phpword": "0.16.0",

"picqer/php-barcode-generator": "0.2.2",

"sanmai/cdek-sdk": ">=0.6.36",

"unclead/yii2-multiple-input": "2.21.5",

"vova07/yii2-imperavi-widget": "1.3.2",

"yii2tech/csv-grid": "1.0.4",

"yii2tech/spreadsheet": "1.0.5",

"yiisoft/yii2-bootstrap": "2.0.10",

"yiisoft/yii2-imagine": "2.2.0",

"yiisoft/yii2-jui": "2.0.7",

"yiisoft/yii2-mongodb": "2.1.8",

"yiisoft/yii2-redis": "2.0.10",

"yiisoft/yii2-sphinx": "2.0.12",

"yiisoft/yii2-swiftmailer": "2.0.7",

"ext-imagick": "*",

"nex/yii2-graylog2": "dev-master",

"npm-asset/jquery-viewer": "^1.0",

"npm-asset/viewerjs": "^1.10",

"whichbrowser/parser": "^2.1",

"hflabs/dadata": "^20.12",

"mohorev/yii2-upload-behavior": "^0.2.3",

"smalot/pdfparser": "^2.2",

"halaxa/json-machine": "^1.1"

Как построен процесс разработки

Разработка осуществляется средствами разработчика с помощью ПО PhpStorm или другого редактора PHP. Хранение кодовой базы на серверах компании в дата-центре Selectel [https://selectel.ru/](https://selectel.ru/).

Как обрабатываются процессы, на каких серверах

Обработка и хранение данных осуществляется силами backend-отдела компании на серверах дата-центра Selectel. В качестве интерфейса взаимодействия используется любой веб-браузер, точка входа [https://bill.bezlimit.ru/](https://bill.bezlimit.ru/). Для хранения данных используются базы данных MariaDB(MySQL), ClickHouse, Redis (open-source edition).

2.5 Поддержание жизненного цикла системы

Поддержание жизненного цикла программного обеспечения обеспечивается за счет следующих процессов:

• Расширение функционала Биллинга в соответствии с собственным планом доработок и/или на основе отзывов пользователей.

• Разработки новых методов API, необходимых для организации взаимодействия Биллинга с базой данных и другими информационными системами.

• Устранение сбоев и технических проблем, выявленных в процессе эксплуатации Биллинга.

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

• Осуществление поддержки пользователей по вопросам эксплуатации Биллинга.

3. Порядок технической поддержки ПО

3.1 Формирование заявки

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

Регистрацию обращений в Битрикс выполняют преимущественно специалисты 1-й линии технической поддержки, кроме случаев выявления проблем инженерами других линий (2, 3 линии).

3.2 Обработка заявки специалистом servicedesk (1-я линия)

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

Специалист 1-й линии выполняет работы по обращениям и инцидентам всеми доступными ему силами и средствами (собственные навыки, консультации с другими сотрудниками IT-инфраструктуры, знания, получаемые из иных компетентных источников).

О ходе работ и способах решения проблемы делает соответствующие примечания в комментарии в Битриксе. После выполнения работ по обращению и уточнения у заявителя решена ли задача по обращению, заявка в Битриксе переводится в статус «решена». Инцидент или обращение так же после этого считается закрытым.

3.3 Эскалация заявки

Эскалация заявки с 1-й линии технической поддержки на вторую происходит в следующих случаях:

Для выполнения заявки требуются доступы к базе данных, которых нет у специалистов 1-й линии технической поддержки.

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

3.4 Обработка заявки 2-й линией

Инженеры 2-й линии технической поддержки:

Решают инциденты, переданные с первого уровня. Если для первого уровня поддержки ожидается, что он решает 80% инцидентов, то от второго уровня поддержки ожидается, что он решает 75% инцидентов, переданных ему первым уровнем, то есть 15% от числа зарегистрированных инцидентов. Остальные инциденты передаются на третий уровень.

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

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

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

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

3.5 Механизм эскалации инцидента со 2-й линии на 3-ю

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

3.6 Данные о процессе поддержки

Данные о персонале, задействованном в процессе поддержки, приведены в главе 4.

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

3.7 Порядок взаимодействия службы поддержки с пользователями

Получение жалоб и пожеланий пользователей:

Периодическое:

• Опрос пользователей в определенные периоды по электронной почте и/или телефону (ежемесячно).

• Сбор данных и решение вопросов совместимости по электронной почте и телефону при выходе плановых обновлений Биллинга (по мере выхода обновлений).

Непериодическое:

• Сбор отзывов пользователей о Биллинге по электронной почте (регулярно, круглосуточно).

• Сбор данных и решение вопросов совместимости по электронной почте и телефону при выходе новых версий Биллинга или существенных обновлений для устранения обнаруженных ошибок.

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

Аварийное:

• Взаимодействие с пользователями при возникновении аварийной ситуации, по электронной почте, телефону.

Обработка жалоб персоналом:

• Сообщение заказчика заносится в систему Битрикс, где его статус меняется по мере устранения проблемы и сохраняется как «решенная проблема» после устранения. В процессе устранения задействуется как сервисный специалист, имеющий навыки системного администратора и минимальные навыки разработчика, так и специалисты разработки системы при необходимости, согласно этапам п. 3.1—3.5.

3.8 Возможные ошибки

Ошибка авторизации в системе

Переполнение визуального блока

Не запускается приложение

Ошибки в верстке

Некорректная работа фильтров

Не приходят Push-уведомления

Ошибка выбора даты в календаре

Некорректный формат отображения сумм

4. Требования к персоналу

4.1 Персонал, обеспечивающий техническую поддержку и модернизацию

Общие требования к специалистам, обеспечивающим техническую поддержку, интеграцию и развитие «АСР Биллинг — коммерческая комплексная программная платформа для реализации электронно-цифровых сервисов» на первой линии поддержки:

• Знание функциональных возможностей Биллинга.

Общие требования к специалистам, обеспечивающим техническую поддержку, интеграцию и развитие «АСР Биллинг — коммерческая комплексная программная платформа для реализации электронно-цифровых сервисов» на второй линии поддержки:

• Знание API Биллинга.

• Знание структуры, функционала и настроек базы данных.

Общие требования к специалистам, обеспечивающим техническую поддержку, интеграцию и развитие «АСР Биллинг - коммерческая комплексная программная платформа для реализации электронно-цифровых сервисов» на третьей линии поддержки:

• Знание функциональных возможностей Биллинга.

• Знание API Биллинга.

• Знание структуры, функционала и настроек базы данных.

• Знание архитектуры Биллинга.

4.2 Уровень подготовки пользователя

Пользователь «АСР Биллинг — коммерческая комплексная программная платформа для реализации электронно-цифровых сервисов» должен иметь опыт работы со смартфоном и с мобильными приложениями.

4.3 Данные о персонале, задействованном в процессе разработки (количество, квалификация)

4.4 Данные о персонале, задействованном в процессе тестирования, отладки и установки ПО (количество, квалификация)

4.5 Данные о персонале, задействованном в процессе поддержки, эксплуатации и модернизации ПО (количество, квалификация)

5. Дорожная карта проекта (ключевые ближайшие 3 года)

Предполагается поэтапная реализация следующих подсистем:

5.1 Подсистема логистики (ориентировочно по июнь 2023 года)

Подсистема логистики предназначена для создания заказов доставки SIM-карт и управления ими.

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

• ФИО;

• контактного номера;

• заказанного номера;

• города;

• адреса пункта выдачи;

Отображение списка адресов пунктов выдачи;

Отображение списка заказов для самовывоза со следующими полями:

• дата создания;

• трек-номер;

• ФИО;

• контактный номер;

• адрес пункта выдачи;

• заказанный номер;

• планируемая дата доставки;

• номер SIM-карты;

• статус заявки;

• автор заявки;

Отображение списка заказов для доставки в пункт выдачи со следующими полями:

• дата создания;

• трек-номер;

• ФИО;

• адрес доставки получателя;

• стоимость доставки;

• контактный номер;

• адрес пункта выдачи;

• заказанный номер;

• планируемая дата доставки;

• количество SIM-карт;

• статус заявки;

• автор заявки.

5.2 Подсистема управления маркетплейсами (ориентировочно по декабрь 2023 года)

Подсистема управления маркетплейсами предназначена для создания маркетинговых материалов для размещения на маркетплейсах OZON, Wildberries, Яндекс.Маркет, СберМегаМаркет.

Подсистема должна обеспечивать:

• создание шаблонов маркетинговых материалов с указанием:

• рекламного слогана;

• абонентской платы;

• размера шрифта;

• рекламного изображения;

• отображение списка шаблонов;

• фильтрацию списка шаблонов;

• редактирование шаблонов;

• удаление шаблонов;

• выгрузку маркетинговых материалов в формате ZIP.

5.3 Подсистема управления поставщиками услуг (ориентировочно по июнь 2024 года)

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

Подсистема должна обеспечивать:

Отображение главной очереди задач со следующими полями:

• ID задачи;

• номер;

• бан;

• статус;

• код услуги;

• новый номер SIM;

• связанная задача;

• источник заявки;

• статус в очереди;

• код ответа;

• номер запроса;

• контрольная проверка;

• дата создания;

• дата обновления;

• автор;

Отображение очереди задач по смене статуса со следующими полями:

• ID задачи;

• номер;

• бан;

• статус;

• код услуги;

• связанная задача;

• источник заявки;

• статус в очереди;

• код ответа;

• номер запроса;

• контрольная проверка;

• дата создания;

• дата обновления;

• автор.

Отображение очереди задач по смене SIM со следующими полями:

• номер;

• статус;

• автор;

• новый номер SIM;

• комментарий;

• статус заявки;

• кто изменил статус;

• дата создания;

• дата обновления;

• статус в очереди.

5.4 Подсистема управления бонусными баллами (ориентировочно по декабрь 2024 года)

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

Подсистема должна обеспечивать:

• отображение списка бизнес-единиц со следующими полями:

• название организации;

• реквизиты;

• фактический адрес;

• юридический адрес;

• генеральный директор ФИО;

• должность (по документам);

• бухгалтерия;

• менеджер;

• возможность редактировать информацию по бизнес-единице;

• возможность удаления бизнес-единиц;

• возможность добавления бизнес-единиц;

• возможность фильтрации списка бизнес-единиц;

• отображение списка контрагентов со следующими полями:

• сервис-провайдер

• название организации;

• реквизиты;

• фактический адрес;

• юридический адрес;

• генеральный директор ФИО;

• должность (по документам);

• email;

• менеджер;

• возможность редактировать информацию по контрагенту;

• возможность удаления контрагента;

• возможность добавления контрагентов;

• возможность фильтрации списка контрагентов;

• отображение списка групп номеров со следующими полями:

• название группы номеров;

• тип оповещения;

• контактное лицо;

• главный номер группы;

• контактный телефон;

• email;

• комментарий;

• возможность редактировать информацию по группе номеров;

• возможность удаления групп номеров;

• возможность добавления групп номеров;

• возможность фильтрации групп номеров;

• возможность экспорта списка групп номеров;

Отображение списка транзакций юрлиц со следующими полями:

• год;

• месяц;

• сервис-провайдер;

• название организации;

• сумма счета;

• сумма неоплаченных счетов;

• баланс компании;

• сумма платежей;

• статус оплаты счета;

• отправка в 1С;

• комментарий.

• возможность добавления транзакций;

• возможность фильтрации транзакций;

• возможность экспорта списка транзакций;

• возможность формирования документов по транзакции;

Отображение списка транзакций по группам номеров со следующими полями:

• год;

• месяц;

• название организации;

• тип оповещения;

• количество номеров;

• сумма счета;

• баланс группы;

• сумма платежей;

• к оплате;

• статус оплаты счета;

• возможность просмотра детализации;

• возможность фильтрации транзакций;

• возможность экспорта списка транзакций;

Отображение списка платежей со следующими полями:

• тип организации;

• дата зачисления платежа;

• номер;

• организация;

• сумма платежа;

• комментарий;

• дата создания;

• автор;

• тип платежа.

• возможность редактирования информации по платежам;

• возможность удаления информации по платежам;

• возможность добавления платежей;

• возможность фильтрации платежей;

• возможность экспорта списка платежей.

Игровая подсистема (ориентировочно по декабрь 2025 года)

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

Подсистема должна обеспечивать:

• отображение количества активных пользователей мобильного приложения по дням;

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

• отображение суммы скачиваний мобильного приложения по дням;

• отображение количества регистраций по дням;

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

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

Предварительные условия:

ОС:

Debian 8 Linux или выше

Ubuntu 18.04 или выше

MacOS

Установленные и настроенные

Nginx(Apache2)

php 7.4 и выше

База данных MariaDB (MySQL)

Установить репозиторий Dockers:

git@gitlab.bezlimit.ru:bezlimit/dockers.git

Установить репозиторий My:

git@gitlab.bezlimit.ru:bezlimit/my.git billing

*Обратите внимание, что клонируем в директорию billing. Такая директория указана в настройках Docker и поэтому такое имя понадобится нам позже.*

Копируем: cp .env.example .env
Изменяем настройки в .env на нужные

Пример:

\# ip-адрес для привязки домена к конкретному ip-адресу

DOCKER_HOST_IP=127.0.0.1

WHATSAPP_SERVER_HOST_IP=127.0.0.1

LK_API_HOST_IP=127.0.0.1

\# Путь к проектам на локальной машине

PROJECTS_DIR=/home/dev/www/bezlimit

\# локальный путь к данным БД (mariadb)

DB_LOCAL_DIR_DATA=/home/dev/www/bezlimit-data/db

\# локальный путь к файлам логов db (mariadb)

DB_LOCAL_DIR_LOGS=/home/dev/www/bezlimit-data/logs/mysql

\# путь к локальной директории composer.json (для прокидывания файла auth.json)

COMPOSER_LOCAL_DIR=/usr/local/bin/composer

\# путь к директории с ssh ключами для скачивания приватных библиотек с bitbucket

SSH_LOCAL_DIR=/home/dev/.ssh

docker-compose up -d –build

Устанавливаем зависимости:

~/www/bezlimit/my/yii2$ composer install -ignore-platform-reqs

или

~/www/bezlimit/my/yii2$ make composer

Копируем конфиги:

~/www/bezlimit/my/yii2/config$ cp console-local-example.php console-local.php
~/www/bezlimit/my/yii2/config$ cp main-local-example.php main-local.php
~/www/bezlimit/my/yii2/config$ cp params-local-example.php params-local.php
~/www/bezlimit/my/yii2/config$ cp test-local-example.php test-local.php
~/www/bezlimit/my/yii2/config$ cp web-local-example.php web-local.php

или

~/www/bezlimit/my/yii2$ make configs

Создаем необходимые директории:

chmod 777 -R web/assets/
chmod 777 -R runtime/

или

~/www/bezlimit/my/yii2$ make dir

Правим конфиги:

В main-local.php настраиваем подключение к базе

'db' => [
'class' => 'yii\\\\db\\\\Connection',
'dsn' => 'mysql:host=db;dbname=db',
'username' => '',
'password' => '',
'charset' => 'utf8',
'tablePrefix' => 'tbl_',

],

В web-local.php и настраиваем логи. Перезаписываем 'targets', чтобы локальная установка не стучалась в телегу с ошибками.

// web-local.php

'components' => [

// ......

'log' => new \\yii\\helpers\\ReplaceArrayValue([
'targets' => [

[

'class' => 'yii\\log\\FileTarget',
'levels' => ['error', 'warning'],
'exportInterval' => 1,

],

[

'class' => 'yii\\log\\FileTarget',
'logFile' => '@app/runtime/logs/web-all.log',
'levels' => ['error', 'warning', 'info'],
'exportInterval' => 1,

],

],

]),

// ......

],

В console-local.php аналогично

'log' => new \\yii\\helpers\\ReplaceArrayValue(

[

'targets' => [

[

'class' => 'yii\\log\\FileTarget',
'levels' => ['error', 'warning', 'info'],
'except' => [],
'logFile' => '@app/runtime/logs/console.log',

],

[

'class' => 'yii\\log\\FileTarget',
'levels' => ['error', 'warning', 'info', 'trace'],
'categories' => [],
'logFile' => '@app/runtime/logs/soap-all.log',

],

],

]

),

Создаем схему my_db и пользователя:

CREATE USER 'myuser'@'%';
CREATE USER 'myser'@'127.0.0.1’;

GRANT ALL PRIVILEGES ON db.* TO 'myser '@'%';
GRANT ALL PRIVILEGES ON db.* TO ' myser'@'127.0.0.1’;

Заливаем дамп и проверяем работу сайта

[http://bill.bezlimit.local](http://bill.bezlimit.local/)

Логин:

Пароль: ;

Если получаем ошибку Notice: Undefined index: authorization in /var/www/bezlimit/my/yii2/config/common/di.php on line 220,

добавляем параметр authorization в param-local.php

'apps' => [
'lkApi' => [
'host' => '',
'authkey' => '*',
'authorization' => '*',

],

Возможные ошибки

Exception 'RuntimeException' with message 'RD_KAFKA_VERSION constant is not defined. Phprdkafka is probably not installed'

Решение: установить rdkafka

MacOS:

brew install librdkafka
sudo pecl install rdkafka
php -m | grep kaf

rdkafka

PHP: syntax error, unexpected end of file, expecting ']' in /usr/local/etc/php/conf.d/browscap.ini on line 2364

Решение: использовать правильный browscap.ini.