Экосистема пользователя услуг сотовой связи

1. Архитектура и Инфраструктура
ЭС представляет из себя мобильное приложение, обменивающееся сообщениями с базой данных с помощью API. База данных установлена на сервере, находящимся на территории Российской Федерации. Мобильное приложение можно скачать из официальных магазинов приложений App Store и Google Play.

Масштабируемость
Мобильное приложение работает на платформах iOS и Android.

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

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

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

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

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

• Обследование объекта и обоснование необходимости создания ПО;
• Построение бизнес-процессов, которые будут автоматизированы при внедрении ПО;
• Формирование бизнес-требований к разрабатываемому ПО;
• Формирование требований к элементам системы;
  
• Формирование требований к дизайн-системе ПО;
  
• Формирование требований к среде разработки ПО;
  
• Предварительный анализ сроков по реализации ПО.
  

• Разработка и утверждение технического задания на создание ПО
• Определение рабочей группы, ответственной на разработку
• Построение план-графика по отчетным встречам разработки ПО

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

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

• Разработка методов, сервисов, программ
• Настройка сетевой безопасности
• Подготовка резервированной БД
• Подготовка пресс релизной версии
• Аудит ПО на предмет соответствия требованиям

• Тестирование безопасности
• Функциональное тестирование
• Тестирование производительности
• Юзабилити тестирование
• Подготовка отчета о тестировании

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

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

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

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

• Процесс управления документацией
• Определение критериев для сопровождения документации
• Актуализация и доработка документации при изменении ПО
• Управление конфигурацией ПО
• Контроль модификаций и версий ПО
• Подготовка технической документации по релизу версии ПО
• Исправление ошибок и нестыковок с новыми версиями стороннего ПО
• Плановая модернизация

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

• Debian 8 Linux;
• Ubuntu 18.04 или выше.

• Open-source ПО Rsyslog
• Open-source ПО ELK
• GIT (с системой автоматической установки и обновления кода через GitLab)
• Asterisk 18.0 и выше

• Windows (10, 11)
• Mac OS (Big Sur, Monterey, Ventura)

• Dart

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

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

• расширение функционала ЭС в соответствии с собственным планом доработок и/или на основе отзывов пользователей;
• разработки новых методов API, служащих для организации взаимодействия ЭС с базой данных и другими информационными системами;
• устранение сбоев и технических проблем, выявленных в процессе эксплуатации ЭС;
• внесение изменений в ЭС с целью оптимизации его работы (улучшение взаимодействия, повышение эффективности использования серверных ресурсов, повышение удобства пользовательского интерфейса и др.);
• осуществление поддержки пользователей по вопросам эксплуатации ЭС.

3. Как построен процесс разработки
Разработка осуществляется средствами разработчика с помощью ПО VisualStudio Code или Android Studio. Хранение кодовой базы на серверах компании в дата-центре Selectel (https://selectel.ru/).

4. Как обрабатываются процессы, на каких серверах
Обработка и хранение данных осуществляется силами backend-отдела компании на серверах дата-центра Selectel. В качестве интерфейса взаимодействия используется Rest API. Для хранения временных данных используется внутреннее хранилище устройства пользователя.

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

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

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

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

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

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

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

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

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

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

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

• Периодическое:
• опрос пользователей в определенные периоды по электронной почте и телефону (ежемесячно);
• сбор данных и решение вопросов совместимости по электронной почте и телефону при выходе плановых обновлений ЭС (по мере выхода обновлений);
• Непериодическое:
• сбор отзывов пользователей об ЭС по электронной почте (регулярно, круглосуточно);
• сбор данных и решение вопросов совместимости по электронной почте и телефону при выходе новых версий ЭС или существенных обновлений для устранения обнаруженных ошибок;
• сбор данных и решение вопросов совместимости по электронной почте и телефону при обновлении пользователями приложений;
• Аварийное:
• взаимодействие с пользователями при возникновении аварийной ситуации, по электронной почте, телефону;

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

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

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

• Ошибка авторизации в системе
• Не запускается приложение
• Ошибки в верстке
• Некорректная работа фильтров
• Не приходят push-уведомления
• Некорректно отображается баланс номера
• Ошибка выбора даты в календаре
• Некорректное отображение новостей
• Ошибка при обновлении приложения
• Ошибки в пагинации
• Зависание экранов приложения
• Некорректный формат отображения сумм
• Некорректное отображение темной темы
• Серый экран при переходе между разделами
• Не отображается главное меню
• Вход без обязательной установки чекбоксов согласий

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

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

• знание API ЭС;
• знание функционала и настроек базы данных.

• знание функциональных возможностей ЭС;
• знание API ЭС;
• знание функционала и настроек базы данных.