Pavel, Suheyl, Nikita, Hassan
- Добро пожаловать
- Бизнес-кейс
- Системные требования
- Текущая архитектура
- Целевая архитектура
- Архитектура переходного периода (Transition Architecture)
- Записи об архитектурных решениях
Все в архитектуре программного обеспечения является компромиссом.
Первый закон архитектуры программного обеспечения
Добро пожаловать на Архитектурный ката Sysops Squad, проводимый компанией O'Reilly в апреле - мае 2021 года.
Эта страница представляет собой архитектурную документацию для предложения решения от Команды Семь.
Penultimate Electronics - это крупный электронный гигант, у которого имеется множество розничных магазинов по всей стране. Когда клиенты покупают компьютеры, телевизоры, стереосистемы и другую электронную технику, они могут выбрать план поддержки. Технические эксперты, работающие с клиентами («Sysops Squad»), затем приезжают на дом клиента (или в офис) для устранения проблем с электронным устройством.
Существующая система управления заявками представляет собой большое монолитное приложение, разработанное много лет назад. Клиенты жалуются, что консультанты никогда не приходят из-за потерянных заявок, а часто приходит неправильный консультант, который не разбирается в проблеме. Клиенты и сотрудники колл-центра жалуются, что система не всегда доступна для ввода заявок через веб или звонки. Внесение изменений в этот большой монолит является сложным и рискованным процессом - каждое изменение занимает слишком много времени, а часто что-то ломается. Из-за проблем с надежностью монолитная система часто "зависает" или выходит из строя - это обычно происходит из-за резкого увеличения использования и числа клиентов, пользующихся системой. Если что-то не будет сделано в ближайшее время, Penultimate Electronics будет вынуждена отказаться от этой очень прибыльной линии бизнеса и уволить всех экспертов.
Желаемое решение с функциональной точки зрения представлено на следующей диаграмме marketecture.
Бизнес-факторы
Какие бизнес-факторы мы можем выявить из данной ситуации:
- Низкая производительность системы отслеживания заявок.
- Возможность полного прекращения данной линии бизнеса.
- Многие люди находятся под угрозой потери своих рабочих мест.
Бизнес-цели
Компания устанавливает следующую бизнес-цель для улучшения ситуации:
- Разработать новую систему отслеживания заявок, которая будет удовлетворять требуемым характеристикам.
Компания страдает от неэффективной системы поддержки клиентов, что может привести к прекращению данной линии бизнеса. Они хотят разработать новую надежную и высокопроизводительную систему, которая позволит им остаться в бизнесе и обеспечить будущий рост.
В этом разделе описываются ключевые заинтересованные стороны системы и их архитектурные проблемы.
-
SH-1: Администратор (Administrator) (security)
- безопасность - это второе имя администратора; эти люди занимаются учетными записями пользователей и системой выставления счетов.
-
SH-2: Клиент (Customer) (availability, performance, scalability, robustness)
- клиенты хотят, чтобы система, к которой они обращаются, была доступна в любое время, когда им нужно ее использовать, и чтобы она быстро реагировала на их действия;
- они также не хотят, чтобы их заявки обрабатывались и не терялись.
-
SH-3: Эксперт (Expert) (availability, performance)
- каждый раз, когда эксперт работает на месте, успех разрешения проблемы может зависеть от того, имеет ли он доступ к базе знаний системы заявок;
- неэффективная система может существенно влиять на разрешение проблемы и тратить время клиента и эксперта.
-
SH-4: Менеджер (Manager) (reportability)
- данным людям необходимо тщательно следить за происходящим: есть ли недовольные клиенты, заявки, для которых слишком долго не назначается эксперт, возникли ли какие-либо проблемы с выставлением счетов и т.д.
-
SH-5: Служба технической поддержки (Helpdesk) (availability, performance)
- это первая линия поддержки для клиентов, поэтому им необходимо иметь доступ к статьям по устранению неполадок и заявкам клиентов во время звонков;
- они предоставляют прямую телефонную поддержку, поэтому ответы должны быть найдены как можно быстрее.
-
SH-6: Команда разработки (Development team) (extensibility)
- у этих специалистов возникают сложности с развертыванием изменений в продакшн-среде из-за высокой связности и недостаточной модульности текущей системы.
-
UC-1: Управление пользователями:
- Администратор поддерживает внутренние учетные записи пользователей (SH-1);
- Администратор поддерживает навыки, местоположение и доступность экспертов (SH-1);
-
UC-2: Регистрация клиента:
- Клиенты регистрируют свои профили, кредитные карты и планы поддержки (SH-2);
-
UC-3: Рабочий процесс заявок:
- Клиенты отправляют заявки через веб-интерфейс или по телефону (SH-2, SH-5);
- Эксперты используют мобильное приложение для чтения заявок и изменения их статуса (SH-3);
- Эксперты могут использовать мобильное приложение для поиска в базе знаний (SH-3);
-
UC-4: Отправка опросов:
- Клиенты заполняют и отправляют опросы о удовлетворенности (SH-2);
-
UC-5: Обновление базы знаний:
- Эксперты обновляют базу знаний (SH-3);
-
UC-6: Формирование отчетов:
- Менеджеры отслеживают операции с заявками (SH-4);
- Менеджеры создают отчеты: финансовые, о производительности экспертов, о заявках (SH-4);
-
UC-7: Выставление счетов:
- Клиентам автоматически выставляются счета ежемесячно (SH-2);
- Клиенты могут просматривать историю и выписки по счетам (SH-2);
- Администратор управляет процессом выставления счетов для клиентов (SH-1);
-
UC-8: Уведомления:
- Клиенты получают SMS или электронное письмо о назначении эксперта (SH-2);
- Клиенты получают электронное письмо с ссылкой на веб-форму опроса (SH-2);
- эксперты получают SMS-уведомление о назначении заявки (SH-3);
-
UC-9: Поиск заявок:
- Сотрудникам службы технической поддержки необходим доступ к базе заявок для уточнения их статуса (SH-5);
-
QA-1: доступность (scalability) (UC-3)
- География национального масштаба (США?);
- Количество клиентов - миллионы; Количество заявок на клиента <= 100 (допустим, что-то экстремальное);
-
QA-2: доступность (availability) (UC-2, UC-3, UC-4)
- Клиентские сервисы и база знаний должны быть высокодоступными, поскольку сбои окажут негативное влияние на бизнес;
- 99,9% кажется разумным в данном случае;
-
QA-3: производительность (performance) (UC-2, UC-3, UC-6)
- Время отклика < 2 секунд для загрузки страницы;
- Время поиска в базе знаний несколько секунд;
- Генерация отчетов не должна занимать чрезмерное количество времени;
-
QA-4: надежность (robustness) (UC-3)
- Потерянные заявки или неправильно назначенные эксперты могут привести к закрытию бизнеса;
-
QA-5: безопасность (security) (UC-2, UC-7)
- Личная информация клиентов и данные кредитных карт должны храниться в безопасном и соответствующем требованиям PCI формате;
-
QA-6: расширяемость (extensibility) (all use cases, SH-6)
- Одна из ключевых проблем текущей системы заключается в том, что внесение изменений занимает слишком много времени, а что-то обычно ломается. Это заставляет задуматься о улучшенной модульности новой системы.
- CON-1: Интеграция? Облако/локальное развертывание? Стек технологий?
- ASM-1: Мобильное приложение является частью системы и может быть изменено.
- ASM-2: Помощники службы поддержки (также известные как колл-центр) нуждаются в доступе к подсистеме заявок и некоторой информации о клиентах (контакты, возможно, информация о поддержке). Они также являются пользователями системы, хотя и не указаны в "Основных четырех пользователях" изначальных требований.
- ASM-3: Система отслеживания вызовов (call tracking system) не является частью системы Sysops Squad.
- ASM-4: Компания хранит информацию о кредитных картах клиентов локально и не взаимодействует с третьей стороной (например, authorize.net в США).
В данном разделе описывается архитектура текущей системы заявок.
Обратите внимание, что все представления документируются в стиле C4 model, хотя представлены только системная контекстная, контейнерная и динамическая представления. Большинство диаграмм используют неформальный стиль обозначений. Все диаграммы сопровождаются легендой, объясняющей значение каждой формы на диаграмме.
Текущая система заявок проявляет очень слабые характеристики доступности, поддерживаемости, развертываемости и производительности. Нашей целью является разработка новой системы, которая решает вышеупомянутые проблемы.
Далее изображена диаграмма контейнеров текущей системы заявок:
В данном разделе описывается целевая архитектура программного обеспечения.
Обратите внимание, что все представления документируются в стиле C4 model, хотя представлены только системная контекстная, контейнерная и динамическая представления. Большинство диаграмм используют неформальный стиль обозначений. Все диаграммы сопровождаются ключом, объясняющим значение каждой формы на диаграмме.
На следующей диаграмме показано соответствие требований к архитектурным характеристикам к основным случаям использования на основе требований:
Диаграмма контекста системы ниже отображает основных пользователей системы и ее внешние зависимости:
Следующая диаграмма контейнеров показывает общую структуру архитектуры программного обеспечения и распределение ответственности между контейнерами. Она также показывает основные технологические выборы и способы взаимодействия между контейнерами.
Архитектура построена вокруг четырех основных доменов, которые были обнаружены во время анализа проблемы:
- (customer-facing) отправка заявок, профили клиентов, отправка опросов и т. д.;
- (expert services) принятие заявок и поиск в базе знаний;
- (administration services) отчетность, анализ опросов, отслеживание заявок и т. д.;
- (billing service) выставление счетов, требует особого внимания к безопасности.
Используемый здесь архитектурный стиль - это сервисно-ориентированная архитектура (см. ADR-1 для получения подробностей).
В данном разделе объясняются некоторые ключевые случаи использования для демонстрации того, как соответствующие рабочие процессы проходят через контейнеры.
Следующая диаграмма последовательности подчеркивает некоторые ключевые запросы, которые клиент выполняет во время регистрации в системе. Особое внимание следует уделить регистрации кредитной карты. В базе данных клиентов мы храним только минимальные данные кредитной карты, чтобы клиент мог определить, какая карта уже зарегистрирована. Все данные о кредитной карте зашифрованы и безопасно передаются в систему биллинга (см. ADR-4).
Следующая диаграмма иллюстрирует процесс регистрации заявки на техническую поддержку клиентом.
Важно отметить, что запрос успешно выполняется после сохранения заявки в базе данных клиента и генерации соответствующего события для области обработки заявок. Таким образом, клиент сможет видеть новую заявку сразу после обновления страницы и не будет ждать дополнительных действий по заявке.
Диаграмма ниже объясняет, как система обрабатывает новую заявку и назначает на нее эксперта.
Поскольку обработка заявок - это задание, которое выполняется периодически, заявки, которые в данный момент не могут быть назначены, никогда не будут потеряны и будут обработаны при следующем запуске задания.
Также обратите внимание, что назначение является отдельной сущностью. Таким образом, мы можем хранить историю назначений.
Эта диаграмма продолжает рабочий процесс заявки и показывает, как обрабатывается событие "Заявка назначена" пользователем Sysops Expert.
Операция эксперта выполняется сразу после сохранения статуса заявки в базе данных. И в случае принятия заявки генерируется соответствующее событие для области клиента.
Эта диаграмма демонстрирует, как клиент уведомляется о том, что заявку принял Sysops Expert.
Важно отметить, что заявка сохраняется в базе данных клиента перед событием уведомления, чтобы клиент увидел фактический статус заявки после получения уведомления.
Эта диаграмма объясняет процесс, когда Sysops Expert решает проблему и помечает заявку как завершенную.
Эта диаграмма иллюстрирует, как клиент получает уведомление о разрешении заявки и ссылку на форму опроса.
Сначала статус заявки должен быть обновлен в базе данных клиента, чтобы клиент увидел фактический статус заявки на портале клиента при получении уведомления.
И, наконец, последний шаг в потоке разрешения заявки - отправка опроса клиентом.
С точки зрения клиента, это событие "записать и забыть", поэтому операция выполняется сразу после нажатия кнопки "Отправить".
API аналитики может выполнять предварительную обработку опроса при необходимости или просто хранить его в базе данных для отчетности.
Диаграмма иллюстрирует процесс ежемесячного выставления счетов.
Обратите внимание, что цвета не имеют особого значения, они просто используются для различения элементов друг от друга.
Стратегия развертывания здесь является облачно-независимой и предполагает, что вы можете использовать любого облачного провайдера по вашему выбору или оставаться полностью внутри предприятия. Исключение составляют элементы биллинга, которые рекомендуется все равно оставить внутри предприятия из соображений безопасности.
Решение, предложенное в разделе Целевая архитектура, является окончательной целью, которая решает большинство проблем и рисков, но может потребовать значительных усилий для разработки из-за необходимости разделения базы данных. Поэтому мы можем разделить всю работу на две фазы:
- Решение критических проблем и использование монолитной базы данных до тех пор, пока она не станет узким местом.
- Дальнейшая миграция к целевой архитектуре для решения всех оставшихся рисков.
Вот предложение по архитектуре переходного периода, которое решает критические проблемы, но оставляет некоторые риски (анализ приведен ниже). Обратите внимание, что мы все еще используем асинхронное сообщение для обработки заявок на обслуживание, чтобы обеспечить независимое масштабирование и доступность разных частей системы. В этом случае сообщения могут содержать гораздо меньше информации, потому что все детали могут быть получены получателем из базы данных.
Поскольку у нас есть единая монолитная база данных, мы можем сэкономить некоторые усилия на дополнительной маршрутизации сообщений и репликации.
Вот возможные высокие риски переходной архитектуры.
Поскольку это монолитная база данных, она может стать узким местом производительности. Такая же проблема возникает в отношении единственного шлюза API - если он не масштабируется должным образом, то может стать узким местом.
Единый шлюз API может стать единой точкой отказа для всей системы (см. ADR-12).
Существует риск того, что сотрудники администрации получат доступ к данным кредитных карт клиентов. Мы, конечно же, хотим предотвратить это, извлекая биллинг в отдельный архитектурный квант (см. ADR-4) и изолируя его в отдельной зоне сети с жесткими правами доступа.
То же самое относится к услугам для клиентов - мы не хотим разрешать злоумышленнику получить доступ к остальной части системы. Значительное улучшение безопасности заключается в миграции услуг и данных для клиентов в отдельный квант и изоляции его в отдельной зоне сети (см. ADR-5).
Дополнительные проблемы, касающиеся шлюза API:
- Увеличивает связность между шлюзом и внутренним сервисом.
- Если разрабатывается одной командой разработчиков, может стать узким местом.
Почему важнее, чем как. Второй закон архитектуры программного обеспечения
- ADR-1 Использовать архитектурный стиль на основе сервисов (Service-based) в качестве основного стиля.
- ADR-2 Использовать очереди сообщений с гарантированной доставкой для рабочего процесса с тикетами.
- ADR-3 Извлечь назначение тикетов в отдельную пакетную задачу.
- ADR-4 Извлечь биллинг в отдельный архитектурный квант.
- ADR-5 Извлечь архитектурный квант для клиентов.
- ADR-6 Использовать отдельную базу данных для клиентов.
- ADR-7 Отделить аналитику и отчетную базу данных.
- ADR-9 Извлечь сервис уведомлений.
- ADR-10 Использовать разделение поддоменов для проектирования сервисов.
- ADR-11 Извлечь обработку платежей в отдельный компонент (задача по обработке платежей).
- ADR-12 Перенести операционные задачи на API Gateways.