Пост-знакомство

Привет! Меня зовут Тимофей, я Senior System Analyst с суммарным опытом в IT около девяти лет. Это мой канал-визитка, который я планирую использовать для развития своего профессионального бренда. Добро пожаловать!

Пара фактов обо мне:
👩‍🎓 Я окончил магистратуру в РГУ нефти и газа по специальности "Автоматизированные системы управления";
💻 Работал бизнес-, системным и fullstack аналитиком в разных доменах: ERP (🖥, 💛 и вот это вот все), немного Fintech, сейчас работаю с Computer Vision 📹 + ML (нынче это модно);
🏆 Когда-то в течение года я лидил небольшую support-команду;
🇩🇪 А ещё некоторое время я жил в Германии (Wie geht es dir?).

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

На этом канале я планирую делиться своим профессиональным опытом, рабочими кейсами, образовательными статьями, наблюдениями и мыслями о профессии и в целом рынке труда. Так что если разработка сложных информационных систем в сфере ваших интересов, или если вы планируете погружаться в сферу бизнес-/системного анализа, то здесь для вас найдется много полезного (я надеюсь).
Кстати, ссылка на мой LinkedIn: тык.
Собственно я: @tekhazanov1

Умный учится на своих ошибках, а мудрый — на чужих: как плохое #API партнеров помогает мне проектировать наши интеграции правильно. 🌐

Так получается, что на текущем проекте частенько приходится подключаться к партнерским да и просто публичным API, и вот, что я думаю, анализируя некоторые API: принципы REST не просто так придуманы. Нет, я, конечно, за гибкость и адаптивность, а не за слепое следование правилам, но полное игнорирование best practice приводит к костылям и велосипедам🩼🚴‍♂️ (экспоненциально разрастающемуся хаосу).
Я не спорю, разработка ПО — процесс нелинейный, но иногда стоит пожертвовать скоростью поставки новой фичи в угоду проработанной архитектуре.

Итак, что довелось повидать (названия эндпоинтов вымышлены, но суть передают):

🚩Эндпоинты-загадки: GET /get_data, POST /process_records. Что за data? Какие records? Пути ничего не говорили о ресурсе. (Это я уж молчу про то, что в названии эндпоинта не принято указывать действие, оно и так обозначено в методе, в данном случае get).
🚩Игнор всех методов, кроме POST: Всё через POST, даже для простейшего получения данных. POST /getUserOrders вместо логичного GET /users/{id}/orders. Да, бывают кейсы, когда использование POST для получения данных можно обосновать. Например, получить данные по сотне-другой заявок, которые так удобно передать через Body, чего не сделаешь в GET. Я все равно при проектировании стараюсь использовать именно GET для получения, а список каких-нибудь id пробую передавать через query (благо нынче можно позволить вызывать очень длинные HTTP-запросы). Тем не менее, для таких исключительных кейсов это вопрос дискуссионный, но не всегда же! 🙈
🚩Коды ошибок, как отдельный вид извращений искусства: В ответе приходил статус 200 OK, а в теле:

{ "status": "error", "code": 47 }

Что за код 47? Это надо было угадать или искать в недоступной документации. Ну или что-то, как на картинке в посте. 🤡

Какие для себя на основе этого я делаю выводы, чтобы не допускать такого? Удивительно, но, видимо, стоит просто следовать принципам REST, которые всем уже оскомину набили.

💚Ресурсы, а не операции. Путь — это существительное, которое отвечает на вопрос «Что?».
Плохо: POST /calculateTotal
Хорошо: GET /cart/{id}/total
💚HTTP-методы — это наши глаголы. Используем их по назначению, это снимает 50% вопросов.
GET /orders (получить)
POST /orders (создать)
PUT /orders/{id} (заменить)
PATCH /orders/{id} (частично обновить)
💚Честные статусы. Если ресурс не найден — это 404, а не 200 с текстовой ошибкой. Если ошибка в данных клиента — 400 с понятным описанием в теле.

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

#REST #API #HTTP #интеграция

Размышления о GraphQL

Сегодня снова об интеграциях: подавляющее большинство интеграций в современных ИТ-продуктах и сервисах реализовано с использованием REST-подхода (мысли про который как раз писал в предыдущем посте). Однако не смотря на популярность этого архитектурного стиля, все равно не получится закрыть глаза на явные недостатки в виде over-fetching и under-fetching (иными словами избыточное и недостаточное извлечение данных), на которые я в том числе планирую сегодня ворчать.
Long Story Short: в очередной раз при проектировании сервиса и проработке его интеграций, когда понадобилось подключиться к другому нашему МС по готовому методу, возникли вот эти раздражающие мысли из серии "Мы сделаем 10 запросов к сервису, чтобы получить две нужные строчки на экран, но при этом получим кучу данных, которые нам, собственно, и не нужны". Так мне и пришла идея сделать ход конем — вкрутить саморезы гаечным ключом "А давайте замутим новую интеграцию через GraphQL 💻 и будем забирать только то, что нам нужно одним запросом!"
GraphQL для меня, как Биткоин. 💰 Он такой стильный, современный, все говорят, что за ним будущее, что вот-вот и фиатные деньги будут заменены им, ведь это удобно, децентрализованно и безопасно, но по факту реально расплатиться им ты можешь только в каком-нибудь Эквадоре, да и то при условии, что тебя после этого не подстрелят. Также и GraphQL — вроде что-то на прогрессивном и современном, но по данным на 2022 год (сорян, актуальнее данные не нашел не искал) подход используется всего-лишь в 0,4% сайтов. Почему так?

Пример полностью вымышленный, но похож на мой кейс (проект связан с парковками и видеонаблюдением):
GET /parkings/{parking_id} — тут получаем информацию по парковке, состоящую из огромного JSONа, 💻 берем отсюда только ID в системе Моспаркинга, все остальные данные нам не нужны;
GET /parkings/{parking_id}/address — тут получаем адрес.

С GraphQL это выглядело бы так:

query {
  parking(id: parking_id) {
    mospark_id
    email
    address {
      city
      street
      building
    }
  }
}

В целом нормально, можно использовать: минимальное количество запросов к API, только необходимый набор данных. 💻 Тем не менее, могут возникнуть следующие сложности:

⚠️Один запрос на GraphQL может породить десятки SQL-запросов, если не использовать DataLoader. В REST эта проблема часто менее выражена, так как с предсказуемыми эндпоинтами он проще в управлении нагрузкой. Не надо одним запросом GraphQL дергать сотню полей с пятью уровнями вложенности... 🙏
⚠️Кэшировать GET-запросы по URL в REST легко. Кэшировать уникальные GraphQL-запросы на уровне HTTP — сложно. Для этого потребуются дополнительные инструменты, тот же DataLoader, например.

Собственно, GraphQL полезен в следующих кейсах 📈:
✅Много разных клиентов (мобильное приложение, веб, smart-TV) с разными потребностями.
✅Данные сильно связаны, и клиенту нужна гибкость в их получении.
✅Скорость разработки на клиенте критически важна (фронтенд может сам собирать свои данные).

Когда лучше выбрать что-то другое 📉:
🚩В случае простого CRUD-сервиса без сложных связей.
🚩Производительность и кэширование — главный приоритет, а команда не готова к сложностям.
🚩Нужны простые и стандартные мониторинг и логирование.

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

Зафиналим философским выводом: GraphQL — это не «лучшая версия REST», а принципиально другой инструмент для других задач.

#GRAPHQL #API #HTTP #интеграция

To be honest, для следующего поста у меня была идея порассуждать на тему soft skills, но мой неугомонный кот в очередной раз устроил мне ночное пробуждение своим мяуваньем, поэтому сегодня будет пост про брокеры сообщений. Фото нарушителя приложено в комментарии,👨 а к посту мемчик на тему: Kafka и RabbitMQ. 🐇 Критерии выбора при декомпозиции монолита на примере сервиса обработки медиафайлов.

Как я уже упоминал в каком-то посте, на проекте, в котором я задействован, сейчас вовсю идет распилинг монолита на микросервисы, а заодно часть МС мигрируют с Python 👩‍💻 на Rust💻. Собственно, данный процесс уже давно идет и в рамках инфраструктуры активно используется RabbitMQ, так что есть повод порассуждать, почему именно такой выбор был сделан (к сожалению не мной, я пришел на все готовенькое, так что буду просто умничать на эту тему).
Очевидно, что брокер сообщений выбирается исходя из задач, которые будет выполнять система. В нашем случае мы имеем систему видеонаблюдения и распознавания. Грубо говоря, если ваша ТС оказалась в зоне, просматриваемой камерами, вы будете жестко сфотографированы📸, засняты на видео, а если вы что-то нарушили и дело дойдет до суда, то сурово наказаны как раз эти фоточки окажутся на столе у судьи. 👮‍♀️ На самом деле, в системе много МС и каждый делает что-то свое: сегментирует ТС, распознает ГРЗ, формирует разные отчеты по фиксациям и отправляет их во внешние системы, стримит видео и т.д. Упростим для примера: комплекс снимает фото и передает его какому-нибудь МС в облако, а МС что-нибудь с этим кадром делает (отчет, например) и назовем его, например, Video Analyzer (название вымышлено).

Когда нужно наладить асинхронную передачу данных между микросервисами, первое архитектурное решение — выбор между RabbitMQ и Kafka. Ключевое различие между ними в том, как сообщения попадают к потребителю.

Основное отличие: Push против Pull
✍️RabbitMQ работает по push-модели. Как только сообщение появляется в очереди, брокер немедленно проталкивает его на одного из доступных потребителей.
✍️Apache Kafka использует pull-модель. Потребители сами периодически опрашивают брокера, готовы ли новые сообщения к обработке.

Почему же в моем кейсе RabbitMQ предпочтительнее:
💪Мгновенная доставка (Push). Камера отправляет кадр в RabbitMQ, и брокер сразу же проталкивает его на свободный экземпляр Video Analyzer. Это обеспечивает минимальную задержку между съемкой и началом анализа, что критично для систем реального времени.
💪Балансировка нагрузки из коробки. RabbitMQ автоматически распределяет кадры между всеми работающими экземплярами Video Analyzer. Это не требует дополнительной логики на стороне потребителей.
💪Идеальное соответствие модели «задача-результат». Обработка каждого кадра — это отдельная, атомарная задача. RabbitMQ гарантирует, что каждый кадр будет обработан, а в случае сбоя обработчика будет перенаправлен другому.

Простой пример сообщения, которое можно передать в брокер, чтобы забрать картинку с S3:

{
  "image_path": "s3://camera-bucket/entrance/2023-10-26/cam_01_15-30-00.jpg",
  "camera_id": "cam_entrance_01",
  "timestamp": "2023-10-26T15:30:00Z",
  "analysis_type": "object_detection"
}

А что по Кафке?

Поскольку Kafka имеет pull-модель, микросервис Video Analyzer будет вынужден ее постоянно опрашивать: «Есть ли новые кадры?». Это создает дополнительную нагрузку и может увеличить задержку. Kafka великолепна там, где нужна гарантированная доставка и сохранение потока событий (например, телеметрия или логи), где можно обрабатывать данные пачками. Но для нашего сценария, где важна скорость реакции на одиночное событие, это избыточно.

Как обычно, глубокий вывод в конце:
RabbitMQ (Push) — ваш выбор, когда события требуют немедленной реакции и вы работаете с отдельными, важными задачами. Как в нашем случае с передачей кадров. 🧐
Kafka (Pull) — ваш выбор, когда вы имеете дело с непрерывным потоком данных, который нужно надежно хранить и иметь возможность переигрывать. 😎

#MessageBrokers #Kafka #RabbitMQ #Microservices #Architecture

Каждый раз к концу рабочего дня в офисе у меня на столе собирается вот это 👆 (на фоточке). 😵‍💫
На самом деле, по моему договору на текущем месте у меня фулл-удаленка, даже привязки к конкретной стране нет, что по нынешним временам дорогого стоит. 😎 Тем не менее, пару раз в неделю я езжу в офис: так принято в текущей команде, и я понимаю, почему. Онбординг проходит легче, а погружение в процессы быстрее, взаимодействие между людьми выстраивается лучше, да и вообще, мне кажется, люди друг к другу теплее относятся, когда видят друг друга вживую, а не через фасад аватарок в маттермосте.
Надо сказать, что с начала пандемии я ни разу не работал в гибридном режиме — только удаленка. При этом, вроде как, все получалось: и со стейкхолдерами общаться, и с коллегами взаимодействовать, собственно, и задачи закрывались. Тем не менее, сейчас я часто ловлю себя на том, что часть вопросов просто удобнее обсудить face-to-face. Начинается вот такое: "Ты же в среду будешь в офисе? Ну давай тогда как раз обсудим это/посмотрим то." И вот с одной стороны на среду уже накидано несколько очных встреч, но с другой стороны они проходят продуктивно и наглядно. Особенно, если нужно что-то вместе посмотреть и пощелкать в какой-нибудь системе. Да, конечно, очень не хватает возможности сделать запись экрана во время встречи, чтобы потом отстенографировать ее какой-нибудь нейронкой и иметь уже перед глазам основные тезисы, но в остальном оно все равно удобнее лично общаться.
В целом, конкретно на текущем месте мне мотыляться в офис по кайфу, тут есть ряд перков:
🌟 Мне очень повезло с коллективом: все классные, всякие хиханьки, хаханьки и смехуечки — это святое дело тут;
🌟 Он близко к моему дому;
🌟 Регулярное приятное чувство смены обстановки (возможно это уйдет со временем, но пока есть);
🌟 Мой рабочий день в офисе стоит на 700 рублей дороже, чем удаленный. 🤑 У нас это компенсация за питание, приятный бонусик. Если в день, когда я в офисе, я поел меньше, чем на 700 рублей, то этот день я считаю профицитным. 📈 К сожалению, такого еще не случалось ни разу, так как я очень много жру...
🌟 Бесплатный невкусный кофе. Если бы он еще и вкусным был, я бы вообще спился бы... 🍵
Минусы:
1. Дождь на улице. ⛈

Возможно, оно так комфортно воспринимается мной, так как нет чувства обязаловки, да и по факту получается гибрид. Посему объявляю голосование. Мотаться в офис: стрем или норм? 👇

#работа #гибрид #удаленка #системныйанализ

По ту сторону баррикад требований
Довелось мне тут давеча побывать в роли капризного стейкхолдера, который пока не определился с тем прекрасным будущим, которое он хотел бы видеть. В чем суть: так получилось, что в моей текущей компании я первый системный аналитик, поэтому процесс работы, практики и ритуалы приходится выстраивать с нуля. Собственно, по началу я немного даже провалился между стульев: де-юре я был причислен к архитектурному отряду, по факту работал с продуктовой командой. 🍔
Тем не менее, было принято волевое решение сформировать R&D отряд, в котором в том числе оказался и я (с продуктовой командой продолжаю работать). Так вот мне и было поручено заняться проработкой процесса работы: в том числе поставить задачу на ITSM по настройке проекта в Jira. 👩‍💻 Если в создании пространства в Confluence 🖼️ каких-то сложностей нет, то в случае с Jira нужно точно понимать, что ты хочешь.
Итак, что у меня было для постановки задачи:
☑️ 2 пакета травы, 75 табле...
☑️ Примерное представление, что у нас проект будет разделен на две Канбан-борды (для аналитики и разработки);
☑️ Список необходимых статусов, но без четкого понимания статусной схемы;
☑️ Видение интеграции с доской продуктовой разработки.
В задаче на ITSM команду я честно старался не писать в стиле "деловойте хорошевое плоховое не делойте", но все равно не получилось. Были какие-то слепые пятна, про которые я малодушно думал: "ну, там ребята сами как-нибудь придумают, чтобы красиво было". 🙏

В чем собственно моя проблема? Их две.
1️⃣ Отсутствие четкого видения процесса: как все должно быть в итоге;
2️⃣ Отсутствие знания всех возможностей Jira.

Как все это решилось? Профессионализмом ITSM-команды. Ребята не стали городить что-то от себя, а провели со мной две огромные интервью-сессии часа по полтора для выявления требований, где мы сформулировали в деталях весь процесс, посмотрели возможности Jira, прогнали несколько вариантов процессов и в итоге замутили обалденную двойную борду (а точнее две доски в одном проекте) с проработанным workflow и интеграцией с другим проектом. ✨

Философский вывод (ну как обычно): профессиональное выявление требований — это не просто выслушать хотелки , чтобы задокументировать их. Это еще и помочь стейкхолдеру сформировать видение, которое учитывает баланс между потребностью, рисками, бюджетами и техническими возможностями. Побывав в роли "заказчика" прям чувствуешь это на себе.

#SystemAnalysis #Agile #Scrum #Kanban #Jira #СистемныйАнализ #ITSM #ЛичныйОпыт

Слепые пятна в подробнейшей документации и Client-Side Data Enrichment в микросервисной архитектуре

Я стараюсь очень подробно писать все свои доки. Так, чтобы максимально исключить возможность неоднозначных трактований, вопросы и неопределенности. Тем не менее, бывают случаи, что вопросы все-таки возникают там, где вроде бы все ну очень понятно. ❓ Собственно, про один такой случай я и хочу рассказать. 💖

Преамбула: есть микросервис (назовем его Микросервис1) и БД 📂, которую он обрабатывает, назовем ее, допустим DB лол, в данной БД есть таблица object с полями id (это пусть наш первичный ключ), полем name, ну и всякими прочими полями, которые нам для примера не нужны (изобразил на картинке ER схематичненько). 🖼 У нас тут микросервисная архитектура, вот это вот все, поэтому к DB имеет доступ только Микросервис1 и все данные этой базы мы должны обрабатывать через него. Я же разрабатываю Микросервис2, которому в какой-то момент потребуется поле object.name, чтобы что-нибудь с этим полем сделать (а именно наложить в качестве метаданных на монтируемое Микросервисом2 видео). 🐸

Ну, вроде, все понятно, поэтому переходим к сути:
В спеке у меня описание POST запроса от FE к Микросервису2, body которого по описанию должен выглядеть примерно вот так:

{
    "object_id": 123,
    "object_name": "Какое-то_имя_объекта_тут",
    "request_datetime": "2025-11-03T10:12:31"
...
}

Ну и так далее, всякие поля дальше идут. Пишет мне фронтендер и спрашивает:

"Амиго, а зачем мы тут имя объекта передаем, если у нас есть его id?" ❔

А я смотрю и реально не понимаю, на кой хрен я тут пытаюсь передавать имя, которое правильнее было бы просто по ключу из БД забирать... 🔨 Какой кринж и как я вообще мог так затупить? Я посчитал, что я ошибся, и согласился с разработчиком, что лучше это поле убрать отсюда и забрать на бэкенде, после чего пошел заниматься другими делами. Правда минут через 15 в голову пришла не сразу оформившаяся мысль в формате:

"Так, блэт, минуточку!.." 🌳

Перелистал еще раз спеку и вспомнил, что моя задумка была такая: передать сразу с фронтенда на уровень Микросервиса2 те данные, что нам нужны и уже есть на фронтенде, чтобы избежать большого количества запросов уже со стороны Микросервиса2 к Микросервису1. Например, чтобы получить имя объекта. Поэтому, Андрюха, по коням, у нас труп Client-Side Data Enrichment! 😁 Мы передаем избыточные данные с FE и, возможно, дублируем их на уровне БД микросервиса для того, чтобы уменьшить количество запросов между нашими сервисами. (Имя объекта в запрос вернули, все хорошо).

К чему я все это? К тому, что вся эта ситуация случилась через 5 дней после того, как я закончил писать эту спеку. Вот так мало времени потребовалось мне (автору доки, если что), чтобы какие-то нюансы просто вывалились из головы.

Философское завершение: лучше больше документации, чем меньше документации. Все классные идеи будут либо задокументированы, либо забыты, потому что у всех у нас место в голове до конца жизни уже занято чит-кодами для гта, а для всего остального есть Confluence. 🖼️ AEZAKMI

#интеграция #API #REST #HTTP #системныйанализ #json