Анализ и проектирование систем *

Не откладываем рефакторинг в долгий ящик, чтобы сэкономить на поддержании продукта. Иначе – риск израсходовать горы бюджета, когда рефакторить будет слишком поздно.

В М2 большой объём письменной коммуникации с клиентами. Это и ответы на общие вопросы — о компании, процессах подбора и покупки недвижимости, — и обсуждение конкретных деталей запущенных сделок. К примеру, клиенты хотят знать, в каком отделении банка они будут подписывать документы, пришли ли деньги продавцу, прошёл ли объект недвижимости проверки перед продажей.

Работа с вопросами происходит в тикет-системе клиентской поддержки (UseDesk). Для каждого вопроса через любой канал коммуникации (e-mail, мессенджеры, чат на сайте) заводится обращение, и сотрудник экспертной поддержки отвечает на него с определённым SLA. 

Для оптимизации работы с обращениями процесс разделён на 3 линии поддержки. Первая линия отвечает только на вопросы без привязки к продукту и не знает о конкретных сделках. Она обрабатывает порядка 10 000 обращений в месяц. Вторая линия знает о продуктах и отвечает на вопросы по сделкам, таких обращений около 3 000 в месяц. Третья линия — это уже команды продуктов, до них доходят единичные вопросы.

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

Так выглядел контекст проблемы, с которой вышла на внутренний хакатон наша команда из трёх человек. 

Кстати, интересно ваше мнение, как бы вы подошли к решению задачи по автоматизации такого бизнес-процесса? Напишите в комменты или личку. 

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

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

Здравствуйте, меня зовут Дмитрий Марков. Я архитектор направления в Альфа-Банке. В этой статье мы поговорим об архитектуре, как ни странно. Без космических «прорывов» и «аналоговнет». Всё жизненно. 

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

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

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

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

За окном 2023 год, а среди разработчиков только и разговоров, что про микросервисы да API First. Несмотря на то, что эти темы не новы, похоже, что их актуальность даже набирает обороты.

Про микросервисы уже много написано и теоретического и практического. Есть у этого подхода и свои евангелисты (Microservice Architecture) :) В целом это тема достаточно холиварная, особенно при крайних точках зрения. Сегодня мы ее отложим, но обязательно вернемся в контексте темы этой статьи. Конечно, это будет не менее обсуждаемая история, посвященная методологии API First и программным интерфейсам (прежде всего, web, но не только) при проектировании и разработке современных информационных систем :)

Меня зовут Антон, я руководитель Архитектурного комитета в компании SimbirSoft. Мы используем подход API First для проектов самой разной направленности, где есть несколько команд разработки (как минимум Backend и Frontend), а также при высокой неопределенности на этапе реализации (быстроменяющиеся требования и цели, параллельные процессы проектирования и реализации, высокие запросы к TTM и так далее).

Поскольку API First не является чем-то новым для многих команд разработки, то мы решили не писать про то, что все уже знают, а остановиться на отдельных вопросах и разобраться в практическом аспекте применения методологии API First в части проектирования, прототипирования и разработки.

Этот материал открывает цикл статей, посвященных практическому внедрению методологии API First в разработку наших команд. Если быть точным, то мы отдаем предпочтение «младшему брату» API First, практикующему  проектирование (design), — известному как Design API First. Чтобы избежать путаницы, далее термин «API First» будет обозначать подход к разработке ПО, а термины «Design API First» и «Design First» – проектирование ПО в рамках подхода API First.

Центр управления данными нашей компании занимается построением хранилищ, Data Lake, платформ данных и BI-систем. ETL — неотъемлемая часть нашей работы. Сегодня мы рассмотрим актуальные подходы к созданию подобных решений и расскажем о двух проектах, где они были реализованы нестандартными способами.

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

Ключевая фраза здесь — «без дополнительных усилий». ПО, несомненно, можно расширить и приложив к этому некоторые усилия по разработке. Вопрос в том, сколько усилий это потребует. 

Как метаданные могут помочь сократить эти усилия? Давайте разберемся.

В бэкграунде отличное знание XLST, XLS, XPath, XML (Дошел до Yandex по этой ветке). И декларативный подход стал частью моего мировоззрения, из-за логичного и лаконичного разделения представления и данных.

Angular 2.0 меня полностью устраивает своей законченностью. Просьба без hollywar про React и др. Единственное что мне было неудобно, так это нечеткая граница между представлением информации и данными. It's under template layer.

C 2016 года успешно (есть действующие бизнес проекты) использую декларатативный подход в архитектуре angular application.

Main Goals and Features

Привет, Хабр! Меня зовут Сергей Дербуш, я архитектор в компании «СмартАп Технолоджи».

Это третья часть из цикла статей о SSP (Supply‑Side Platform). В предыдущих статьях мы рассказывали о том, как поднимали систему и как боролись с проблемой несоответствия. В этой статье коснемся архитектуры и того, как от ее выбора зависит стоимость трафика. Всех, кому данная тема интересна, жду под катом!

Когда: 21 июня (среда), 17:30 — 21:30 (СПб)

Формат: офлайн (СПб) и онлайн 

Задать вопросы спикерам и узнать больше о докладах можно в Telegram-чате.

Регистрация на митап тут

Послушаем спикеров из Samokat.tech, Почтатех и USABILITYLAB. Поговорим об изменениях в жизни аналитиков и разработчиков при переходе на микросервисы, совместной работе юзабилити-исследователя и бизнес-аналитика, а также инструментах для моделирования сквозных процессов между продуктовыми командами.

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

Привет, Habr! Совсем недавно я опубликовал статью про Self-Service BI: что же это такое и зачем он нужен крупным компаниям. Но теперь хочется немного отойти непосредственно от Self-Service и вернуться в целом к построению BI-систем. В 2021 году я выступал на Analyst Days с одноименным докладом. Запись выступления ниже (казалось бы, причем тут автомобили?):

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

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

Лично мне завесу тайны приоткрыл Альфа-Банк, здесь документация ведется рядом с кодом, и схемы логичнее описывать тоже кодом. Но это не так страшно и не так сложно (почти) как кажется. Давайте я приоткрою ящик Пандоры и сниму кармическое проклятье с  этого инструмента. 

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

Будет затронута тема очередей, асинхронного логирования, параллельного программирования на CPU и использования каналов (сhannel) для взаимодействия между процессами (thread - ветками) на языке программирования PHP (аналогичный функционал есть в языке GO).

Рассмотрим тему модернизации ИТ-инфраструктуры для растущего бизнеса, использующего 1С:Предприятие в качестве учетной системы.

Автор статьи: Артем Михайлов

Открыт приём заявок на новый поток Академии Аналитиков Авито. В этом году мы набираем студентов сразу на два направления: будем учить аналитиков данных и Data Science-инженеров. Обе программы бесплатные. 

Подать заявку можно до 13 июня. Занятия начнутся в сентябре, а вся программа продлится 13 месяцев — до конца сентября 2024 года. За это время студенты-аналитики освоят основные навыки от прикладной статистики и SQL до ML и теории экспериментов. Будущие DS-инженеры тоже разберутся с ML, а также алгоритмами и датасетами. 

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

Поговорим как рассеять облако страхов и расслабить клапана, чтобы фляга не засвистела.

Привет, Хабр!

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

В данной статье рассмотрены пройденные этапы становления нового уклада, и дан прогноз следующего витка его развития.