Комплесная платформа для реализации электронно-цифровых сервисов

СОДЕРЖАНИЕ

АННОТАЦИЯ

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

Для корректной работы с платформой необходима следующая конфигурация автоматизированного рабочего места пользователя:
Поддерживаемые ОС:
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/.

Как обрабатываются процессы, на каких серверах
Обработка и хранение данных осуществляется силами backend-отдела компании на серверах дата-центра Selectel. В качестве интерфейса взаимодействия используется любой веб-браузер, точка входа 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
Логин: ******
Пароль: ******;

Если получаем ошибку 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.