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

Вебинар «Базы данных для системного аналитика на практике»

12 декабря я проведу бесплатный вебинар: «Базы данных для системного аналитика на практике», где я подробно разберу необходимые навыки для системного аналитика в практических задачах. Запись на вебинар доступна по ссылке.

Что будет на вебинаре:

• Разберем задачи, которые системный аналитик решает в базе данных

• Поговорим о необходимых навыках

• Рассмотрим проблемы, возникающие на практике

• Разберем подходы к их решению на примере реальных задач

Жду вас на вебинаре!

Снова о необходимости архитектурных схем

Продолжим пост об архитектурных схемах с более практической стороны.

– Как-то так повелось, что мы используем C4 model. Не нагромождённая и достаточно лаконичная. Если вдруг кому-то кажется, что C4 – это какая-то новомодная модель, спешу разочаровать. Придумана она была почти 20 лет назад.

– C4 model не предусматривает никакой описательной части, поэтому ко всем архитектурным схемам у нас имеется тезисное описание всех компонентов, изображённых на схеме.

– C4 несложная, но глаз может замылиться, а всё ли сделано правильно? На этот случай на официальном сайте есть чеклист (там же pdf), по которому можно быстро проверить вашу схему на соответствие правилам и адекватность.

– Хотя я очень люблю делать схемы в визуальных редакторах, но понимаю, что реюзабельность такого творчества страдает. Поэтому правильнее готовить такие схемы в виде кода. Хорошим решением будет Structurizr, опенсорсная self-hosted штуковина. Помимо самих схем, там же можно документировать своё решение.

– По моему опыту очень полезной может оказаться Deployment-диаграмма. Её можно немного извратить, отойти от канонов и получить примерно такое изображение:

Особенно удобно, когда существует целый зоопарк самых разнообразных сервисов. Все они в разных закрытых сетевых контурах, с разными командами поддержки. Кто-то должен предоставить вам кубер, кто-то базы, кто-то s3. Что-то будет в Harvester, что-то в Proxmox. Такая диаграмма поможет разобраться во всём этом и как-то структурировать. А новый девопс на вашем проекте скажет за такое большое человеческое спасибо.

DevFM

Пишем эффективные аналитические запросы: третья лекция курса в МГТУ им. Баумана

Третья лекция нашего курса «Deep dive into SQL and DWH» прошла 21 ноября — делимся видеозаписью!

Дата-архитектор Павел Ковалёв рассказал о внутреннем устройстве систем Greenplum и Clickhouse и возможностях, которые они предоставляют с точки зрения оптимизации запросов.

Посмотреть запись можно здесь:

• YouTube

• RUTUBE

• VK

Оставшиеся два занятия курса пройдут в формате очной практики. Видеозаписи трёх прошедших лекций доступны в отдельном плейлисте.

Кто и как создаёт архитектуру программного обеспечения, какими навыками должен обладать такой специалист и каковы его карьерные перспективы? Чему учиться и как развиваться мидлам и синьорам, чтобы начать работать с архитектурой?

Ответы на эти и другие вопросы дадут наши эксперты во время бесплатного вебинара «Карьерный маршрут: от мидла до архитектора ПО». 

Вы узнаете:

— как стать архитектором ПО;

— чего ждут работодатели;

— какие скилы будут полезны, даже если вы ещё не работали с архитектурой ПО;

— как себя чувствуют такие специалисты на рынке труда.

Спикеры ↓

Дмитрий Бардин
Ведущий разработчик в Кинопоиске

Артём Попов
Корпоративный архитектор, «Газпромбанк»

Иван Харкевич
Корпоративный архитектор, «Райффайзен Банк»

Ждём вас 29 ноября в 18:00 мск.

Нужно зарегистрироваться. В день вебинара мы пришлём ссылку на трансляцию.

Зачем фиксировать зоны ответственности разработки

Мы обсудили, как фиксировать зоны ответственности. А теперь обсудим несколько причин, почему это полезно:
– если проект долгоиграющий, то в целом хорошо бы понимать, кто за что отвечает, кто в чём разбирается. На длинной дистанции найдется достаточно количество заинтересантов, которые будут приходить с разными вопросами
– позволяет отслеживать bus factor. Табличка даёт очень наглядное представление, где у нас проблема с зонами ответственности, за какой функционал отвечает всего один человек, и нет у него никакой подмены
– более вдумчиво планировать отпуска. Сразу понятно, кого нельзя отправлять в отпуск одновременно
– и ещё один пункт, который совсем недавно поймали. У нас была проблема, что баги тестироващиками классифицировались по направлениям бек/фронт, но далее они падали на тимлидов, которые должны были вникать и распределять по ответственным и, самое печальное, – тратить свое драгоценное время. Потом мы показали тестировщикам табличку с зонами ответственности, они теперь дотошно диагностируют проблему и закидывают баг сразу на исполнителя. Получилось очень хорошо, ошибок минимальное количество

Простыми словами:  как устроена аутентификация/авторизация через Keycloak

При работе с микросервисной архитектурой, тем более в финтехе, системный аналитик рано или поздно столкнется с межсервисной аутентификацией и авторизацией и системами, их обеспечивающими. У нас это Keycloak.

Оказалось, этот зверь полезный, и среди его достоинств - opensource и дружелюбные взаимоотношения с Java.

Keycloak позволяет создавать для разных систем и сред realms, к которым добавляют сущности клиентов (других систем) с присвоением определенных прав. Схема аутентификации/авторизации через Keycloak несложная и чем-то напоминает аутентификацию по сертификатам. Нужно создать клиента системы А в realm системы B, добавить определенные роли и не забыть получить client_secret, по которому система А будет аутентифицироваться уже в самом Keycloak.

А теперь процесс по порядку:

1. Система А делает запрос на токен в Keycloak (аутентификация по client_id и client_secret).

2. Keycloak отдает JWT-токен, в котором имеется вся необходимая информация, включая роли и все, что нужно для проверки валидности токена.

3. Система А передает запрос с указанием в заголовке токена в систему B.

4. Система B проверяет валидность токена (либо напрямую обращаясь к Keycloak, либо при помощи ранее полученного сертификата).

5. Если все в порядке и с токеном, и с правами – система B отдает ответ системе А.

   Совсем не страшно. Но деталей хватит и на целую статью. Какие вопросы лучше затронуть в ней? Обсудим в комментариях.

Как фиксировать зоны ответственности разработки

Продолжая тему архитектурных схем. Ещё одним полезным артефактом команды разработки проекта является табличка с зонами ответственности и компетенциями. И вроде банально, но смотрел в разные проекты и не везде подобное видел.

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

Конечно, такая табличка может разрастаться на другие области: бизнес-анализ, тестирование, дизайн. Но это уже пусть руководители проектов ведут. Я тут делаю акцент на команде разработки. Чтобы к пуговицам претензий не было.

Пишем эффективные аналитические запросы: вторая лекция курса в МГТУ им. Баумана

Делимся лекциями курса «Deep dive into SQL and DWH» от Павла Ковалёва, дата-архитектора Сравни.

Вторая лекция прошла 14 ноября; предлагаем посмотреть её видеозапись.

Внутри — обзор инструментов построения DWH/Data Lake, в том числе: Hadoop, Spark, Trino, Databricks, Amazon Athena, Amazon Redshift и Google BigQuery.

Посмотреть можно здесь:

✅YouTube

✅RUTUBE

✅VK

Следующая лекция курса будет посвящена техникам оптимизации аналитических SQL-запросов и состоится уже в ближайший четверг, 21 ноября, с 17:25 до 19:00.

Присоединяйтесь в зуме!

Для чего нужны архитектурные схемы

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

Для чего конкретно нам нужна архитектурная схема? Конечно, кроме того, что это просто красиво.

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

Обсуждение работ со смежными командами. Обычно разрабатываемая система работает не в соло. И есть соседние сервисы, с которыми нужно интегрироваться. Первичные обсуждения всегда удобно делать с наглядной картинкой.

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

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

Как документировать архитектуру?

Пишем эффективные аналитические запросы: первая лекция курса в МГТУ им. Баумана

Делимся лекциями курса «Deep dive into SQL and DWH» от Павла Ковалёва, дата-архитектора Сравни.

Первая лекция прошла 7 ноября — предлагаем посмотреть её видеозапись.

Внутри лекции:

• Обзор основных понятий курса (OLTP и OLAP, хранилище данных, его базовые слои, архитектуры обработки данных и т.д.)

• Устройство DWH — на примере компании Сравни

• Основы оптимизации аналитических SQL-запросов

• Как решать проблемы с неэффективными запросами: практические кейсы

Посмотреть запись можно здесь:

✅YouTube

✅RUTUBE

✅VK

Следующая лекция курса, посвященная архитектурному обзору инструментов для построения DWH, пройдёт уже в ближайший четверг, 14 ноября, с 17:25 до 19:00. Присоединяйтесь в онлайне!

***

Больше информации о наших лекциях, митапах, статьях и других полезных материалах про ИТ, в тг-канале Sravni Tech.

Как документировать архитектуру

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

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

В качестве структурного шаблона для документирования предлагается использовать arc42. Для визуализации — C4 model. Кстати, C4 оказалась вполне удобной, и мы активно применяем её у себя.

Из приятного — для arc42 и C4 автор приводит ссылки на хорошие примеры реализации.

В конце автор рассказывает, как можно всё описанное организовать, применяя подход — documentation as code, а так же приводит полезные тулзы для этого.

Валера Бабушкин в новом Sravni Podcast: «Выйдет GPT-5, и я стану плотником!»

Поговорили с Валерой Бабушкиным — экспертом в области ML и анализа данных, автором книги о проектировании ML-систем. 

Обсудили будущее машинного обучения, сложности с поиском хороших инженеров и менеджеров, несовершенство собеседований и специфику работы в big tech. А ещё разыгрываем книгу Валеры — смотрите выпуск до конца и участвуйте в конкурсе!

Также в этом выпуске:

• Неизвестный бэкграунд Валеры: чем занимался ранее?

• Компетенции и карьерный путь ML-специалистов

• Как успешно управлять командами в ИТ

• Кто самый крутой в ML прямо сейчас — среди отдельных специалистов и компаний

Посмотреть или послушать подкаст можно здесь:

• YouTube

• RUTUBE

• VK

• Яндекс Музыка

Оперативно узнавать о наших новых подкастах, докладах, лекциях и других полезных ИТ-материалах, можно в тг-канале Sravni Tech.

Визуализация данных для аналитиков

Аналитики часто сталкиваются с необходимостью представлять сложные данные в простой и понятной форме. Визуальные инструменты, такие как дашборды, диаграммы и нотации, помогают систематизировать информацию, улучшая процессы принятия решений. Эта подборка объяснит ключевые принципы визуализации и способы их использования в бизнесе.

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

Дашборды — что это, какие бывают и как их строить.

UML — язык моделирования для создания схем.

ER‑диаграммы — пригодятся системным аналитикам, чтобы определить, с какими данными предстоит работать и как они связаны между собой перед разработкой ПО.

BPMN 2.0 — инструмент для создания моделей бизнес-процессов.

Диаграммы последовательности — способ управления процессами для аналитиков.

Приглашаем на Alfa Analyze IT Meetup. В программе: генерация документации, LLM и уязвимости

5 ноября в 18:30 проведём третий на тему искусственного интеллекта. Расскажем и покажем, как применять его в работе, а ещё обсудим, какие потенциальные угрозы могут нести большие языковые модели. После докладов оставим время на афтерпати и нетворкинг. 

В программе:

№1. Генерация документации на API-сервис рядом с кодом

Как ИИ-агенты могут облегчить формирование системной документации на микросервисы.

Спикер: Иван Шелапутов, руководитель направления

№2. LLM для системных аналитиков на практике

Онлайн-демонстрация работы системного аналитика с ChatGPT на реальной задаче.

Спикер: Андрей Кнутсон, старший системный аналитик.

№3. Уязвимости приложений с LLM

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

Спикер: Артем Гринько, главный технический лидер разработки

Зарегистрироваться на митап по можно по ссылке ❤️

Зарплаты аналитиков по городам

Привет. Меня зовут Настя, я занимаюсь контентом Хабр Карьеры. Недавно мы посмотрели, сколько зарабатывали аналитики в первой половине этого года. 

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

Теперь к зарплатам аналитиков по городам:

Самый высокий рост показали оклады аналитиков из Екатеринбурга (+51%) — до 169 тыс. руб. На втором месте зарплаты в Нижнем Новгороде (+45%) — до 150 тыс. руб. На третьем — рост зарплаты аналитиков из Санкт-Петербурга (+32%), до 185 тыс. руб. 

В целом, медианная зарплата аналитиков выросла во всех городах, кроме Челябинска — там она снизилась на 2%, до 140 тыс. руб.

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

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

СУБД для аналитиков

В этой подборке мы рассмотрим назначение баз данных, их разные типы, особенности и инструменты для работы с ними. Это поможет выбрать подходящее решение для вашей задачи. Ловите статьи по ссылкам:

Как СУБД помогают аналитикам и маркетологам — найти, сохранить и защитить данные.

DBeaver — помощник аналитика данных. Как пользоваться программой.

PostgreSQL — почему её стоит выбрать для работы с данными и как установить.

Redis — ещё одна СУБД. Как с ней работать, где применять, преимущества и недостатки.

MongoDB — база для хранения неструктурированных данных.

Вебинар: «Быстрая работа с документами с технологией IDP. Профит в кадровых процессах, работе с первичными документами, корреспонденцией и договорами»

Кто проводит: эксперты компаний «Первая Форма» и Dbrain

Кому полезно: техническим директорам, бизнес-аналитикам, директорам по ИТ и инновациям, а также сотрудникам компаний, где в бизнес-процессах много бумажной работы.

Почему это важно:

Ручная обработка документов отнимает много времени и ресурсов компании. Это приводит к снижению эффективности работы, увеличению количества ошибок и задержкам в бизнес-процессах. Автоматизация работы с документами с помощью технологии умного распознавания (IDP) в BPM-системе позволяет значительно сократить время на рутинные операции и повысить эффективность работы всей организации.

Чему научатся участники:

• Узнают, как автоматизировать категоризацию первичных документов.

• Рассмотрят процесс автосоздания задач на основе входящей корреспонденции.

• Изучат, каким способом можно заполнять анкеты сотрудников без ручного ввода.

• Познакомятся с возможностями упрощённого поиска по электронному архиву.

Как попасть:

Участие бесплатное, по предварительной регистрации. Вебинар состоится 31 октября в 11:00.

Спикеры вебинара:

• Хайрова Дарья, тимлид партнёрского направления «Первой Формы»

• Александр Ляхович, менеджер по развитию бизнеса в Dbrain

Присоединяйтесь, рассмотрим, как технология IDP может трансформировать работу с документами в вашей компании. 

Предлагаем решить математическую задачу из двух частей. Первая — вполне реальная, вторая — фантастическая. Но просим вас к обеим отнестись серьёзно!

1. В город N приехал столичный чиновник. На собрании в 9:00 он по секрету рассказал важную новость двум местным сотрудникам. В течение часа каждый из них по секрету рассказал эту новость ещё троим жителям этого города. В течение следующего часа — каждый из этих новоузнавших передал эту новость ещё троим новым и т.д.

Сколько жителей города N будут по секрету знать важную новость в 21:00 этого дня?

2. Помимо секретов чиновник привёз в командировку коробку с печеньками. Они были настолько вкусные, что в первый день он съел аж 8 штук. Ему хотелось растянуть печенье до конца командировки, поэтому он решил держать себя в руках и есть каждый следующий день в полтора раза меньше печенек, чем в предыдущий (кусочки печенек тоже считаются).

Проблема в том, что чиновник попал в пространственно-временную аномалию и застрял в городе N навечно! Но это был очень последовательный чиновник — он продолжал выполнять своё обещание и каждый день ел всё меньше и меньше печенек.

Можно ли узнать, сколько всего печенек он съест за время своего бесконечного пребывания в городе N? Если да, то хватит ли ему коробки с 50 печеньками?Поделитесь размышлениями ответами в комментариях.

→ Больше подобных задач в бесплатном тренажере «Основы математики для цифровых профессий».

Используем PlantUML не по назначению: рисуем маппинг данных с помощью диаграммы класса

Когда у вас docs as code, хочется, чтобы все было прямо по «докс экс кодовски», в частности, чтобы диаграммы и схемы тоже рисовались кодом.

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

Вот так выглядит код (если нужны пояснения, обращайтесь):

@startuml

hide circle
left to right direction

class Structure_1 {
  field_1
  --
  field_2
  --
  field_3
}

class Structure_2 {
  field_1
  --
  field_2
  --
  field_3
}

package transform <<Rectangle>> #yellow {
  
}

package "addition data" <<Rectangle>> #purple {
  
}

package "data transform" <<Rectangle>> #blue {
  
}

Structure_1::1 -down[#white]-> transform
Structure_1::1 -down-> transform
Structure_1::1 -down[#white]-> transform

transform -down-> Structure_2::1

Structure_1::2 -> Structure_2::2

Structure_1::3 -down-> "data transform"

"data transform" -down-> Structure_2::3

"addition data" -down-> 

А так — результат (маппинг данных):

Какие нюансы нужно учесть:

1. Активно «играйте» связями: они помогают двигать объекты на диаграмме.

2. Используйте невидимые элементы и связи.

Сначала это кажется сложно. Но позже, когда освоишь ухищрения и «костыли», рисовать настоящие шедевры. И тогда у час будет полнейший docs as code.

Похожее можно рисовать и в graphviz, но там синтаксис потяжелее будет. Как? Могу показать.

Все думал как представить модель IDEF0 так чтобы человеку была видна вся модель УФМТП. Если просто PDF прикладывать, не все додумываются скачать. Думаю в таком виде будет более понятен масштаб.

Что скажете?

Про использование этой модели можете почитать тут Концепция IDEF0