Rivalry2

HTML Diff

0 added 0 removed

Original 2026-01-01

Modified 2026-03-10

1 <ul><li><a>Проблематика: технологические ограничения роста СУБД</a><ul><li><a>Риски</a></li>

2 <li><a>Технический долг</a></li>

3 </ul></li>

4 <li><a>Бизнес-модель и мотивация компании</a></li>

5 <li><a>Выбор ERP-системы</a></li>

6 <li><a>Инфраструктура ERP-системы</a></li>

7 <li><a>Отказоустойчивость</a></li>

8 <li><a>Производительность</a></li>

9 <li><a>Стейкхолдеры</a></li>

10 <li><a>Механизм архитектурного надзора</a></li>

11 <li><a>Интеграционная модель</a></li>

12 <li><a>План действий и дорожная карта</a></li>

13 <li><a>Вывод</a></li>

14 </ul><p>Предлагаем вашему вниманию проектную работу Джамшеда Якубова, выпускника курса<em><a>"Enterprise Architect"</a>.</em></p>

15 <p><strong>Цели итогового проекта:</strong></p>

16 <ul><li>разделить монолит на сервисы</li>

17 <li>обеспечить масштабируемость и качество</li>

18 <li>обеспечить стабильность при переходе</li>

19 <li>нормализовать данные</li>

20 <li>запустить новые сервисы</li>

21 </ul><h2>Проблематика: технологические ограничения роста СУБД</h2>

22 <p>Бизнес-стратегия компании подразумевает кратный рост. Но из-за технологических ограничений и технического долга, СУБД монолитной системы не сможет обеспечить высокий уровень отказоустойчивости. Необходимо разделить монолит на отдельные сервисы.</p>

23 <h3><strong>Риски</strong></h3>

24 <strong>Фактор риска</strong><strong>Вероятность</strong><strong>Цель и последствия</strong><strong>Величина риска</strong><strong>Меры</strong>Падение базы данных из-за роста продаж, технологические ограничения хранения75% через 1 год 100% через 2 годаРост продаж (невозможность достижения целей компании)50 млрд.руб Разбить монолит на отдельные сервисы: ЭДО, финансовый учёт, регламентированный учёт, хранение файлов, перенос интеграций на событийный брокер (160 млн. руб.)Репутация (задержки выплат курьерам, отчётность бенефициарам, взаиморасчеты с контрагентами)100 млн.руб.Своевременная налоговая и регламентированная отчетность (штрафы)5 млн.руб. вынести регламентированный учёт в отдельную базу (1 млн. руб.)<h3><strong>Технический долг</strong></h3>

25 <strong>Технический долг</strong><strong>Решение</strong>Хранение бинарных файлов ЭДО по каждой операции в СУБДЗапустить сервис S3, вынести "бинарники" из СУБДВсе сервисы в одной СУБД (монолит)Разбить на отдельные сервисыРазнородные интеграцииПерейти на брокер (Kafka)<h2>Бизнес-модель и мотивация компании</h2>

26 <a></a><a></a><a></a><h2>Выбор ERP-системы</h2>

27 <p>В длинном списке было 14 систем. В короткий попало 5.</p>

28 <a></a><a></a><h2>Инфраструктура ERP-системы</h2>

29 <p>Центральную архитектуру решения необходимо строить на базе технологической платформы"<strong>1С: Предприятие 8.3"</strong>. Можно использовать несколько конфигураций 1С: Предприятие 8.3, а также вспомогательные решения на других платформах. </p>

30 <p>Имеется в виду использование<strong>только облачных ресурсов.</strong></p>

31 <a></a><h2>Отказоустойчивость</h2>

32 <ul><li>Система относится к второму уровню критичности.</li>

33 <li>Доступность: 95%.</li>

34 <li>Среда тестирования должна быть идентична продуктивной среде.</li>

35 <li>Продуктовая среда "отсечена" от остальных сред на сетевом уровне.</li>

36 <li>Постоянный мониторинг продуктовой и тестовой сред с оповещением ответственных команд по следующим показателям для серверов: "СУБД", "Приложения", "Веб".</li>

37 </ul><h2>Производительность</h2>

38 <ul><li>Количество одновременно работающих пользователей: 250. </li>

39 <li>Общее количество пользователей: 500.</li>

40 <li>Общее количество транзакций: до 2 млн в день.</li>

41 <li>Максимальное количество транзакций на пике: до 5 млн в день. Допустимо отложенное отражение в учёте в течение 24 часов.</li>

42 </ul><h2>Стейкхолдеры</h2>

43 <a></a><h2>Механизм архитектурного надзора</h2>

44 <ul><li>Формализация функциональных требований в Confluence.</li>

45 <li>Согласование функциональных требований с группой функционального контроля: руководителем проекта, бизнес-аналитиком, системным аналитиком.</li>

46 <li>Формирование проектных решений на основе функциональных требований в Confluence</li>

47 <li>Согласование проектных решений в архитектурном комитете: с архитектором, ИТ-директором, девопсом, руководителем проекта, системным архитектором</li>

48 <li>Проектирование интерфейсов и формирование технических заданий на основе проектных решений в Confluence</li>

49 <li>Согласование технических заданий с группой технического контроля: системным архитектором, системный аналитиком, разработчиком</li>

50 <li>Разработка и тестирование MVP-решений</li>

51 <li>Архитектурный контроль</li>

52 <li>Реализация и запуск стабильного решения </li>

53 </ul><h2>Интеграционная модель</h2>

54 <a></a><p>В интеграционный ландшафт входят:</p>

55 <ul><li>Событийные паттерны и "точка-точка"</li>

56 <li>Асинхронные и синхронные взаимодействия</li>

57 </ul><h2>План действий и дорожная карта</h2>

58 <a></a><a></a><h2>Вывод</h2>

59 <ul><li>Некоторые требования к системе не давали уложиться в сроки.Эти требования будут выполнены на следующих стадиях развития системы</li>

60 <li>Обеспечены масштабируемость и устойчивость системы</li>

61 <li>Обеспечены быстрый деплой, независимость компонентов и гибкость в выборе технологий</li>

62 <li>Технический долг погашен, удалось избежать рисков</li>

63 <li>Удалось достичь поставленных целей (с допустимой погрешностью)</li>

64 </ul>