Семь красных линий

Что такое ACID и зачем он нам Есть такие темы и области знаний, которые в реальной работе не сильно нужны, но их очень любят спрашивать на интервью и вообще считается, что нужно знать для общего понимая о том, как устроен мир. Одной из таких тем является ACID - набор требований к СУБД, соблюдение которых гарантирует надежность работы с данными. Сам термин (или набор принципов) был сформулирован еще в 1970х одним из сотрудников IBM, работавших над созданием одной из СУБД и затем стал своего рода знаком качества: если СУБД соответствует принципам ACID - хорошо, если нет - не очень хорошо. Правда, ситуация начала меняться с развитием и распространением распределенных систем - там этот принцип осознанно нарушается в угоду возможностям распределенной обработки. Вам, как пользователю СУБД, ничего специально делать не нужно: вы не можете "использовать в работе" ACID - это просто свойства вашей СУБД. Тем не менее, на техническом интервью вас запросто могут спросить, поэтому попробуем разобраться, что это такое (да и вообще, для общего развития полезно). Итак, аббревиатура ACID включает в себя следующее: 🔹 Atomicity (атомарность). Это значит, что если нужно выполнить набор операций, то СУБД гарантирует, что будут выполнены или все операции или не выполнена ни одна и состояние данных не изменится. По сути это поддержка механизма транзакций. Если в СУБД есть транзакции - требование соблюдается. 🔹 Consistency (согласованность). Вообще согласованность данных - это больше логическое понятие, то есть данные не противоречат по смыслу друг другу; например у человека не может быть трех родителей (программно это не запрещено, но абсурдно по сути). Но в нашем случае подразумевается, что после завершения транзакции новый набор данных гарантированно не будет противоречить установленным ограничениям (обязательность, типы полей, уникальность, ссылочная целостность и тд). Другими словами, это свойство системы гарантирует, что после завершения транзакции там точно не будет формально не валидных данных. 🔹 Isolation (изолированность). В СУБД может быть открыто несколько транзакций одновременно и операции могут выполняться над одними и теми же данными. Изолированность гарантирует, что данные операции из одной незавершенной транзакции не повлияют (и не будут видны ) в другой незавершенной транзакции. То есть после открытия транзакции все выглядит так, как будто других пользователей нет. Это довольно сложное в реализации и дорогое в плане ресурсов требование, поэтому в промышленных СУБД есть возможность изменять уровни изолированности для ускорения работы и если сам характер операций такое допускает. Но в самом строгом случае СУБД гарантирует полную изолированность. 🔹 Durability (долговечность). Это простое требование говорит о том, что все изменения, которые были сделаны в рамках успешной транзакции, должны быть сохранены в случае сбоя и последующего восстановления системы. Другими словами - данные должны сохраняться на диск, а не храниться в памяти. Если все эти требования попробовать выразить одной фразой, то получится что-то вроде: "СУБД умеет обрабатывать транзакции не ломая структуру таблиц и не мешая другим транзакциям, а все данные хранит на диске". Это нестрогая и упрощенная формулировка, но она может быть сработать как шпаргалка, если вы забыли, что значит бука I в аббревиатуре, например. Для тех кому нужны совсем простые примеры на пальцах, нашел неплохую статью на Хабре, посвященной ACID. #СУБД #Собеседование

Транзакции и транзакционность Продолжаем разбирать термины и понятия, с которыми возникают сложности у ребят на собеседованиях. Сегодня - пару слов о транзакциях в БД. Даже если вы не программируете и не пишете много SQL кода, понимание механизма транзакций важно для проектирования устойчивых приложений. Транзакцию можно описать как совокупность операций с БД, которые выполняются как единое целое. То есть, если нам нужно из одной таблицы что-то считать, в другую таблицу добавить несколько строк, в третьей что-то изменить, а в четвертой таблице удалить строку и все эти операции имеют смысл, только будучи выполнены вместе, то мы должны все эти операции выполнить в рамках одной транзакции. Выполнение всех операций в рамках одной транзакции гарантирует нам, что операции будут или выполнены все вместе, или не будет выполнена ни одна из них. Для того, чтобы это было возможным, СУБД должна обеспечивать (или обладать таким свойством как) транзакционность. Это довольно непростая задача, однако во всех промышленных реляционных СУБД она решена. В общем случае транзакционностью обладают не только только СУБД - это могут быть брокеры сообщений или любые другие системы, которые обеспечивают хранение и изменение данных. Системы, обладающие этим свойством, называют транзакционными. Обработка любых операций с транзакционных СБУД происходит следующим образом (клиент отправляет команды, БД их выполняет): 1️⃣ Начинается (или открывается) транзакция. Это техническая операция, которая говорит системе, что дальше будет одна или более операций, которые должны быть выполнены вместе. 2️⃣ Выполняются необходимые операции (чтение, вставка, изменение записей). Их может быть много и они могут разнесены во времени. 3️⃣ Транзакция подтверждатется (commit) или отменяется (rollback). Если транзакция подтверждена, то все изменения фиксируются в БД и становятся доступны другим пользователям. Если транзакция отменена, то СУБД возвращается к состоянию, которое было до начала транзакции. Транзакция может быть отменена из-за ошибки (кончилась память) или по требованию клиента (под клиентом подразумевается пользователь или приложение, взаимодействующее с БД). Но что если нам нужно сделать транзакционные изменения в двух независимых СУБД? Или, например, вычитать сообщение из очереди и затем сохранить его в базу? Когда вы вычитываете сообщение из очереди (и завершаете операцию), оно из очереди удалится, но если сохранить его не удалось, оно должно там остаться для повторной попытки. В этом случае нам необходимо выполнить распределенную транзакцию. Распределенная транзакция - это две и более транзакций, выполняемых в разных системах, которые должны быть или выполнены все вместе или не выполнена ни одна из них. Самое важное, что вам нужно знать о распределенных транзакциях - не существует способа ее гарантированного выполнения. Системы между собой не связаны и каждая из них (включая вашу, клиентскую) систему может отказать в тот момент, когда в одной СУБД транзакция уже подтверждена, а вторая система стала недоступна. При этом, отменить изменения в первой БД может не получиться - ваши данные могли быть уже прочитаны или изменены другим клиентом. ‼️Важно! Если вы описываете сценарий, в котором необходимо сделать изменения в двух БД (или любых других транзакционных системах), всегда рассматривайте вариант, при котором первое изменение пройдет успешно, а второе нет и нужно что-то делать. И обычно это приводит к выбору, какая транзакция "важнее" и какую надо завершать первой. В случае с нашим примером выше нужно понять, что страшнее: записать сообщение в БД два раза или потерять его и не записать вовсе. Оба варианта не очень, но придется выбирать из двух зол и принимать какие-то дополнительные меры, чтобы нивелировать влияние этого сбоя на процесс. #СУБД #Собеседование

Индексы в БД на пальцах На последних нескольких интервью, к моему удивлению, кандидаты не смогли внятно ответить на вопрос, что такое индекс в бд. Поэтому хочу привести несколько базовых тезисов и в конце - довольно интересную статью с Хабра, где рассказано о разных типах индексов. 🔹 Что такое индекс? Это вспомогательная структура данных, которая создается средствами СУБД и хранит информацию о расположении (или адресе) строки в таблице с некоторым значением поля. Индексы строятся для каждого поля отдельно: можно построить по индексу на каждое поле таблицы, если в этом есть необходимость. 🔹 Зачем нужны индексы? Для ускорения поиска. Без индекса СУБД вынуждена перебирать все строки в таблице в поисках нужной; индекс позволяет быстро узнать местоположение этой строки и перейти сразу к ней. Аналог из жизни - статья в журнале или глава из книги: вместо того, чтобы перелистывать все страницы, вы ищете название в оглавлении и переходите к нужной странице. 🔹 Как работают индексы? Индексы можно упрощенно представить себе как отсортированные копии полей (столбцов таблицы). Поиск значения в отсортированной структуре происходит очень быстро - вы быстрее найдете старницу номер 742 в книге из 1000 страниц, чем бубновую девятку в перетасованной колоде карт, потому что карты нужно перебирать, а номера страниц отсортированы. Найдя значение поля в индексе, СУБД получит информацию об адресе всей строки таблицы (которая там была сохранена при создании индекса), то есть "перейдет по номеру страницы", если сравнивать с книгами. 🔹Минусы и особенности. Помимо очевидноно плюса в виде ускорения поиска, есть ряд особенностей, которые нужно иметь ввиду. 1. Индексы - это дополнительные структуры данных, которые нужно хранить, следовательно, они занимают дисковое пространство, особенно это важно учитывать при работе с большими таблицами (хотя именно там они наиболее эффективны). 2. Если мы меняем значения в таблице (включая добавление и удаление строк), то это будет происходить в двух местах: в самой таблице и в индексе, то есть у нас немного замедляется модификация таблиц. Для задач с большим количеством изменений это может быть ощутимо. 3. Неправильно выбранный тип индекса может замедлить поиск. Например, индексы в виде деревьев неэффективны для столбцов с низкой мощностью множества* 🔹Когда использовать индексы? Строить индексы нужно только по тем полям, по которым осуществляется поиск. Идеальный случай - данные в таблице меняются редко, а запрашиваются часто. Контрпример - таблица, которая представляет собой журнал аудита, куда данные пишутся постоянно всей системой, а читаются только в случае инцидентов и нет высоких требований к скорости поиска. В этом случае использование индекса только навредит: будет тратиться лишнее дисковое пространство и запись будет чуть медленнее. * Мощность множества или Cardinality - это характеристка, показывающая уникальность данных, входящих в множество. Если у нас есть миллион строк для поля Gender, которые содержат только значения Male и Female, то говорят, что у такого множества низкая мощность. А поле Email с уникальными данными будет иметь высокую мощность. Подробнее о типах индексов можно почитать в этой статье на хабре #СУБД #собеседование

Как понять, что вы хороший аналитик? Существуют различные методики качества требований, зрелости процессов и прочих метрик, которые, конечно, хорошо бы все знать и применять. Но если нужно быстро и индикативно понять, все ли я делаю правильно, я пользуюсь небольшим чеклистом, который не покрывает все множество ситуаций, но для быстрой оценки подходит. Готов порекомендовать его и начинающим коллегам, чтобы как-то начать ориентироваться. Он дискуссионный, но точно рабочий. 📦Я правильно понял бизнес задачу. Это подтверждение от заказчика или иного стейкхолдера, что вы правильно поняли бизнес задачу. Не требования записали, а именно бизнес задачу поняли ("Выкопать яму" - это бизнес задача, а "сделать двухштыковую лопату с фарами, чтобы ночью копать" - это требование к решению, которое может быть и не самым лучшим). Все ваши требования вы должны оценивать по степени удовлетворения бизнес задачи, а не записывать за заказчиком его видение решения. 📋Разработчику понятно, что нужно делать. Разработчик, прочитав вашу документацию, должен подтвердить, что ему все понятно. Это могут быть требования, схемы, диаграммы, псевдокод - что угодно, главное, чтобы разработчик, как один из основных потребителей ваших артефактов, сказал: "все понял, сделаем". Это не гарантирует, что разработчик все понял правильно и не будет ошибок, это само по себе не гарантирует, что заказчику понравится, но если у разработчиков нет к вам вопросов, то это это уже очень хорошо. 💰 Я не нашел решения дешевле. Любое решение имеет стоимость разработки (сколько часов разработки/тестирования на это ушло), стоимость поддержки (как много ресурсов, людских и аппаратных нужно, чтобы решение продолжало работать) и стоимости использования (сколько сил/времени/денег потратит бизнес, прежде чем получит желаемый результат от вашей фичи или решения). Можно пробовать переводить все в деньги, можно оценить качественно: например, ручной ввод данных стоит лишние 20 секунд оператора, а автоматизированное заполнение данных требует лишние 2 спринта команды разработки. Очевидно, что ручной ввод выглядит дешевле. Если вам удастся это донести до заказчика, то вы молодец: вы сделали решение, которое в итоге сэкономило бизнесу деньги.

Зарплаты и вакансии аналитиков Инфографика на основе данных с сайта hh.ru по состоянию на май 2023. Воспринимать их нужно как индикативные показатели, особенно зарплаты - более чем в половине вакансий з/п вообще не указана или указаны суммы "от". Но для общего представления о рынке можно использовать.

Иллюстрации к предыдущему посту про оркестрацию и хореографию - кажется, так будет нагляднее. На них изображен пример возможного порядка взаимодействия между микросервисами: оркестрация через REST API, хореография - через топики Kafka или другого брокера.

Оркестрация и Хореография В микросервисных приложениях при подготовке ответа на клиентский запрос, как правило, задействованы несколько микросервисов (например, в интернет-магазине это могут быть авторизция, корзина, промо, рекомендованные товары, отзывы и т д) - каждлый из них выполняет свою задачу, а вместе они обрабатывают сложный пользовательский запрос. Существует два основных шаблона, как организовать взаимодействие между микросервисами. 🤵‍♂Оркестрация. Этот шаблон предполагает, что формированием ответа для клиента занимается один микросервис ("оркестровщик"): он знает, как устроен процесс обработки запроса, сам по очереди обращается ко всем остальным микросервисам, получает от них какие-то данные, при необходимости принимает решение о том, к какому сервису обратиться следуюшим, и в конце из всех полученных данных формирует ответ для клиента и возвращает его. Это наиболее распостраненный шаблон - он простой и понятный и подходит для большинства случаев. Мнемоническое правило: Дирижер в оркестре: он один определяет, кто сейчас будет играть и он отвечает за итоговый результат. 👯‍♀ Хореография. Этот шаблон предполагает, что все микросервисы сообщают в некоторый "эфир" информацию о произошедших событиях, слушают события от других микросервисов и сами принимают решение, как и что обрабатывать. Популярный пример: микросервисы публикуют информацию о том, какие действия они выполнили, а модуль логирования по всем этим операциям сохраняет информацию в журнал событий. Проектировать взаимодействие, основанное только на хореографии - намного сложнее и для этого должны быть веские причины. Обычно так делают, когда одни микросервисы зависят от данных, которые контролируются другими микросервисами. Хореография звучит круто и красиво, но без явной небоходимости лучше не злоупотреблять: ее сложнее проектировать и сложнее сопровождать. Мнемоническое правило: танцорами на сцене никто не управляет, они смотрят друг на друга и понимают, что делать так, чтобы вместе получился какой-то рисунок. В реальных системах обычно используются оба шаблона: для обработки клиентских запросов - почти всегда оркестрация, для взаимодействия продуктовых (или доменных) и служебных микросервисов между собой - часто используется хореография. #интеграции #собеседование

Немного инфографики по месседжингу вам в пятничную ленту. Это основные тезисы для понимания, что могут очереди и топики ActiveMQ, Kafka и других брокеров. На практике там все чуть более сложно и сильно зависит от настроек, но для первого ознакомления должно промочь. #интеграции

Большинство статей про REST, что я встречал, дают некоторое знаниче о базовых принципах этого подхода, но не дают общего понимания, что же это такое. Большинство аналитиков на собеседовании не могут внятно объяснить, что такое REST, замолкая на фразе "REST - это архитектурный стиль.." Этому термину много лет, но он все еще вызывает большое непонимание, хотя на устах буквально у всех, кто занимается проектированием интеграций. Так что с ним не так? Почему никто не может внятно объяснить суть, но при этом все считают, что проектируют REST API? Я провел небольшое исследование с погружением в исторический контекст и подготовил материал, который, как мне кажется, расставляет все точки над i, объясняет, почему возникают сложности с определением и понимаением сути термина и, собственно, дает это определение. Материал сравнительно большой, но должен быть полезен всем, кто хочет до конца разобраться с термином. Читать полный текст #интеграции

Шаблоны взаимодействия систем В индустрии выделяют 3 основных шаблона, по которым строится обмен сообщениями между системами и модулями. Ниже - краткое описание, подробнее готов рассказать в комментариях. 📩 Запрос-ответ (он же Request-Resonse), самый простой и популярный шаблон. Потребитель (consumer) отправляет запрос, поставщик (provider) шлет ответное сообщение. Так работает HTTP (а значит и почти весь интернет), так работает API между беком и фронтом, так могут взаимодействовать микросервисы. В качестве канала может использоваться как HTTP, так и очереди сообщений или шины данных. 📣 Издатель-подписчик (он же Publish-Subscribe или PubSub). Для реалиации нужно промежеточное ПО, например Kafka, которое содержит информационные каналы (топики). Система-издатель публикует сообщение в некоторый топик, которое могут получить все системы-подписчики, подключенные к этому топику. Никаких запросов нет, издатель не знает, какие системы получат сообщение и получат ли вообще. Такой подход удобен тем, что одно и то же сообщение могут получить сразу несколько систем, причем именно те, которые подписаны на нужный топик. Часто используется в микросервисной событийно-ориентированной архитектуре. Пример: банковские системы - если у банковского счета изменились реквизиты, об этом нужно проинформировать большое количество систем; все они подписаны насоответствующий топик и при наступлении события смогут получить сообщение и обработать его. 📬 Уведомление (Notification или Subscribe-Notify). Похож на предыдущие два шаблона и заключается в том, что система-подписчик шлет запрос на получение сообщений определенного вида и после этого система-поставщик направляет сообщения конкретному подписчику по мере их появления. Не самый распространенный, но довольно удобный в ряде случаев шаблон. Например, так может быть организовано автообновление ленты новостей или переписки в групповом чате. После того, как подписчик (клиентское приложение) подключился к серверу, он говорит: "Я онлайн, если будет что-то для меня - присылай". И сервер будет присылать сообщения по мере их появления без дополнительных запросов. Такое взаимодействие можно организовать и через очереди сообщений (mq) и черерз веб сокеты, то есть промежуточное ПО не нужно. #собеседование #интеграции

Аналитик - несуществующая профессия? Больше половины своей карьеры я работаю системным аналитиком и всю дорогу сталкиваюсь с дискриминацией нашего брата по различным признакам. Поэтому, считаю необходимым предупредить молодых коллег о возможных издержках. 🔸 У нас нет однозначного названия. Мастей аналитиков - просто громадье: системные, бизнес-, аналитики данных, продуктовые аналитики, отраслевые аналитики (которые вообще не IT). Если сказать постороннему наблюдателю "я работаю аналитиком в банке" - подумают, что ты рынки ценных бумаг анализируешь. Буквально только что, в процессе написания поста, пришло приглашение на позицию "Agile-аналитик по информационной безопасности" (это не шутка)! Это вообще кто такой? Каждый раз приходится уточнять, что ты системный аналитик, но это не совсем то, что написавано в вики в статье Системный анализ, то есть вроде то, но чуть другое и вообще давайте приведу аналогию на кошках. 🔸 У нас нет технологического стека, как у других профессий. Разработчик, аднимистратор, тестировщик - все могут написать в резюме, каким стеком владеют. А у нас что? Визио, конфлюенс и ворд? Если сеньор, то Миро и Фигма. Есть, конечно, postman и еще несколько утилит, но на профессиональный стек не тянет все равно. Обидно немного. 🔸 У нас нет красивого, короткого и однозначного англоязычного сокращения. Dev, test, admin, devops, finops, frontend, backend, DBA - устоявшиеся и всеми понятные террмины. У нас есть только SA (sa? Sa?) но это не так вкусно, да и вообще, см. пункт про то, что аналитик - это кто угодно. 🔸У нас сильно плавает набор обязанностей: в разных компаниях перечень обязанностей может сильно различаться. Это не плохо само по себе, но еще один пунктик за то, что "аналитик это непонятно кто". В ряде компаний вообще не понимают, зачем им аналитик (а там прям видно, что им нужно). 🔸 Нас частенько разработчики дразнят гуманитариями, хотя если взять какого-нибудь среднестатистического банковского мидла разраба, который пишет на высокоуровневом фреймворке маленький микросервис по предоставленной ему спецификации, то уровень инженерного разумения у него послабее будет, чем у аналитика, который это все проработал. Но нет, разработчик - это инженер, а аналитик - гуманитарий. Так что, если вы решили встать на этот благородный, но тернистый путь, будьте готовы)

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

‼️Топ пять ошибкок на собеседовании Простите за кликбейтный заголовок, не смог отказать себе в удвольствии. Итак, список основных ошибок или антипаттернов на собеседованиях аналиитков, которые, по моей практике, снижают шанс успешного прохождения интервью. 1️⃣ Не рассказывайте про свои бывшие проекты, рассказывайте про свое в них участие. Фраза "Я участвововал в проекте по созданию системы, которая.." и дальше 10 минут про то, какая крутая была система, не даст никакой информации о вас, но потратит время и утомит собеседника. Лучше сказать "Делали крупную учетную систему для страховой, я собирал требвоания, описывал процессы в BPMN, проектировал предметную область" и т. д. 2️⃣ Не пытайтесь угадать ответ на вопрос. Не знать чего-то не так страшно, как выйти за границы своей компетенции и с серьезным видом выдавать отсебятину. Это очень тревожный звонок для интервьюера, так как выглядит как "Он и в работе, если чего-то не знает, начнет придумывать, чтоб не выглядеть дураком". Это очень плохо. 3️⃣ Не молчите, когда пытаетесь решить какую-то задачу или кейс, проговаривайте мысли вслух. Тестовая задача на собеседовани должна выявить ваш подход к решению, ответ сам по себе не так ценнен. Особенно это актуально и полезно, если вы не знаете как решить: тогда вы сможете показать, как вообще вы подходите к сложным задачам, что пробуете, как размышляете. Это сильно лучше, чем молча морщить лоб и нервничить из-за повисшей тишины. 4️⃣ Избегайте споров на неоднозначные темы и не вступайте в холивары с интервьюером. Собеседование - не лучшее место для попыток унизить своего будущего лида, это лучше делать после прохождения испыталки. 5️⃣ Фразу "Все зависит от ситуации" нельзя заканчивать точкой - нужно привести хотя бы пару примеров. Тот, кто задал такой вопрос, знает, что все зависит от ситуации и задал его, чтобы узнать, с какими ситуациями вы сталкивались. Часто кандидаты такой фразой пытаются уйти от ответа - лучше так не делать. #собеседование

❓ Какие существуют способы интеграции? Как правило, выделяют 4 способа интеграции приложений: 🟥 1. Прямое подключение по HTTP или REST API Используется прямое сетевое подключение по TCP (строго говоря, может использоваться не только для HTTP). Хорошо подходит для быстрого обмена небольшими сообщениями (сотни килобайт) в режиме запрос-ответ ➕ Плюсы - Быстрый, легко разворачивается - Не требует дополнительных вспомогательного ПО/серверов - Можно передавать любые типы данных - Удобен для подключения к внешнему API ➖ Минусы - Не очень подходит для больших блоков данных. Сам HTTP не имеет лимитов, но на практике ПО, публикующее API, имеет ограничения - Не подходит для надежного обмена сообщениями между системами с разным режимом доступности: нельзя отправить сообщение в сервис, который в данный момент недоступен - Если принимающая запросы система довольно слабая, то большое количество запросов приведет к DDOS и недоступности 🟩 2. Месседжинг Для взаимодействия двух систем требуется система-посредник: менеджер очередей. Обеспечивает гарантированную доставку сообщения от одной системы к другой за счет того, что сообщения в менеджере очередей сохраняются до тех пор, пока не будут получены другой стороной. ➕ Плюсы - Гарантированная доставка: сообщения можно отправлять и получать вне зависимости от того, доступна ли система получатель или отправитель в этот момент. - Позволяет копить сообщения в очереди, что даст возможность слабой и медленной системе-получателю пережить пик нагрузки: она вычитает постепенно сообщения из очереди и не упадет - Позволяет нескольким системам получать одно и то же сообщение (шаблон издатель-подписчик) ➖ Минусы - Работает медленнее, чем прямое HTTP соединение - Требует развертывания и поддержки дополнительного ПО (и оборудования) - менеджера очередей - Высокие требования к надежности оборудования, на котором развернут менеджер очередей, иначе он будет дополнительной точкой отказа 🟦 3. Взаимодействие через общий файловый ресурс В основном используется для обмена файлами большого объема (логи, снапшоты, в ряде случаев медиаконтент), а также иногда для интеграции с системами, у которых нет API и нет возможности их доработать ➕ Плюсы - Позволяет надежно передавать файлы большого объема - Позволяет решать специфичные задачи по интеграции с legacy ПО, не имеющим API - В ряде случаем позволяет выровнять нагрузку на сеть (большие файлы можно перекачивать по ночам, когда нагрузка меньше) ➖ Минусы - Медленный, не очень подходит для real-time взаимодействия - Сложнее контролировать и управлять, так как нужно учитывать возможности и особенности файловой системы, нужно следить за своевременным удалением файлов и т д. - Не безопасный 🟪 4. Взаимодействие через общую СУБД Позволяет нескольким приложениям читать данные из одной СУБД. Специфичный способ, используется для интеграции с системами, не имеющими API (читаем данные непосредственно из БД этой системы) или для репликации данных (перекладываем данные из чужой СУБД в свою и дальше работаем со своими данными) ➕ Плюсы - Позволяет решать специфичные задачи по интеграции с legacy ПО, не имеющим API - Позволяет строить витрины данных, не нагружая СУБД мастер-системы (например, для тяжелых аналитических отчетов) - Для репликации данных имеются готовые решения - Можно довольно быстро сделать временное решение, доработав только одну из систем ➖ Минусы - Небезопасно с точки зрения целостности данных, если две системы будут записывать данные в одну БД - Противоречит сервисной модели (хранение данных отделено от представления данных) и несет дополнительные затраты по сопровождению таких взаимодействий, если интеграция изменится - Сложно обеспечить гибкое разграничение доступа к данным (только теми средствами, что предоставляет СУБД, а их часто недостаточно) #собеседование #интеграции

❓ Что такое синхронное и асинхронное взаимодействия? 👉Прежде всего нужно подчеркнуть, что синхронность или асинхронность это не свойство канала связи, а способ обращения от одной системы к другой (например, вызов API). 🔹Синхронным называется такой вызов, при котором процесс в вызывающей системе который отправил запрос, не движется дальше, пока не получит ответ на этот запрос. 🔹Асихнронным называется такой вызов, при котором процесс отправил запрос и не ждет ответа, а движется дальше. Ответ придет позднее и он будет обработан. Пример синхронного вызова - спросить у человека, который час. Задав вопрос, вы стоите и ждете, пока вам не ответят и не принимаете дальнейшего решения. Пример асинхронного вызова - подача заявления на загранпаспорт: вы его подали и не ждете готового паспорта: как будет готов, так можно будет брать билеты. При асинхронном взаимодействии ответ можно получить двумя способами: - Polling (опрос на предмет готовности) - это когда вы, имея ну руках номер вашего запроса, периодически спрашиваете “Готов ли результат?” - Callback (обратный вызов) - это когда система, получив и обработав ваш запрос, сама каким-то образом сообщит результат (вызовет ваш API или отправит ответ в очередь) Синхронность вызова не зависит от способа передачи: можно делать асинхронное взаимодействие по HTTP, причем как с поллингом, так и коллбеком, равно как и синхронное взаимодействие можно делать через mq очереди: отправить сообщение и ждать ответа во входящей очереди. Выбор способа зависит от: 🔸 решаемой задачи: может ли процесс продолжать работу до получения ответа 🔸 возможностей вызывающей системы: далеко не все системы готовы делать HTTP callback, так как им для этого необходимо знать URL вашего API, который нужно вызвать, когда ответ будет готов 🔸 потенциального времени обработки ответа: если известно, что вызывающая система выполняет тяжелые вычисления и ответ займет несколько минут, то нет смысла делать синхронный вызов и ждать все это время. #собеседование #интеграции

📣 Запускаем новую рубрику - #собеседование ! Это серия коротких постов с ответами на популярные вопросы на тенихческих собеседованиях для аналитиков. Посты будут сгруппированы по темам и иметь теги, по которым можно их будет найти. Первый блок - #интеграции

Соглашение о наименовании - это штука из мира разработчиков, она нужна для того, чтобы было удобнее работать с кодом. Но аналитики код не пишут, однако знать и применять основные тезисы соглашения, которыми пользуется ваша команда разработки, все равно полезно. Разбираемся, что нам это дает. Зачем аналитику знать соглашение о наименовании? Есть такая штука, как соглашение о наименовании, или naming convention. Это своего рода набор правил хорошего тона при оформлении кода, который говорит о том, как программистам писать названия функций, переменных и прочих элементов кода. При этом, практически во всех командах эти правила имеют статус закона, то есть ваш код не будет принят, если вы назвали свои объекты или функции не по правилам. Эти соглашения, как правило, вырабатываются и поддерживаются всем сообществом, использующим какой-то язык программирования, то есть для тех, кто пишет на Java и для тех, кто пишет на PHP эти правила могут быть разные. Обычно, соглашение включает в себя нотацию и некоторые правила, описывающие, как называть однотипные объекты. Читать полный текст

Хочу рассказать кулстори о том, что бывает, когда "в заказчиках согласья нет" и интересы участников конфликтуют. Сейчас вспоминать ту историю весело, но тогда это был настояший стресс с настоящими слезами наших менеджеров. Если вы заказчик - пожалуйста, не делайте так, а если исполнитель - будьте бдительны) Читать полный текст

Почти любое собеседование аналитика включает в себя техническую часть. У аналитиков нет своего родного стека технологий, как у разработчика или DevOps инженера, поэтому спрашивают почти обо всем. Разбираем основные технические знания и навыки, которые нужны аналитику и какие преимущества это ему даст. Какие хард скиллы нужны аналитику? Сегодня поговорим о хард скиллах для системного аналитика, включая некоторый "инженерный минимум", который не мешало бы аналитику знать. Но перед этим нужно понять, зачем они ему? Ведь материалы и статьи по управлению требованиями ничего такого не требуют, сами требования формируются простым и понятным человеческим языком совместно в заказчиками, которые не оперируют техническими деталями, да и разработчики вполне понимают язык бизнес требований. Но при этом любое собеседование системного аналитика, скажем, в банк, обязательно включает в себя техническую часть и там мало просто наболтать, там часто требуется прям показать глубокое понимание. И я тоже на собеседованиях всегда требовал; более того, интервью с этой части начиналось, так как если там все плохо, дальше не имело смысла тратить время человека. Так зачем? Есть несколько более или менее очевидных причин, попробуем их разобрать. Читать полный текст

В современной разработке ПО методология Scrum воспринимается как что-то само собой разумеющееся, гарантированно работающее и эффективное. При этом, как правило, чем крупнее компания, тем хуже в ней обстоят дела со скрамом и тем меньше реальность похожа на то, что написано в руководстве. Попробуем разобраться, почему скрам не работает в вашей компании. Как понять, что вам не нужен Scrum Кто не знает скрам? Скрам знают все: спринты, стори поинты, беклог, дейли стендапы и вишенка на торте - потрындеть на ретро. Скрам используют с разной степенью эффективности большие и маленькие компании, крупные корпорации и банки, заказная и собственная разработка, потому что это кажется удобным и понятным: вот задачи, вот спринт, вот красивый Только в большинстве случаев это не скрам. Да, внешне похож, церемонии соблюдаются, спринты есть и прочее, но за внешними признаками ускользает сама идея... Читать полный текст