Доброе утро!

Сегодня проходит международная конференция по системному и бизнес-анализу Analyst Days 15.
На ней я хочу раскрыть особенности работы с очередями для системных аналитиков:
👩‍💻 Доставить и не потерять: синхронизация данных в распределенных системах
🔗 Подробности здесь
⏰ Начало: 4 ноября в 14:35
Встречаемся с участниками конференции в прямом эфире!
Промокод на скидку 15%: GetAnalyst

Всю эту неделю я посвятила подготовке и репетициям доклада.

Для участников Analyst Day-15 я подготовила подарок:
🎁 Мои презентации всегда больше в версии 1 - сохранила и делюсь
🎁 Собрала подборку книг по проектированию и архитектуре
🎁 Карта навыков - как расти системным аналитикам

P.S. А еще готовлю для вас вебинар по тестированию API через Postman, который проведу на следующей неделе 😉

Примерно в этот момент я закончила мое выступление на Analyst Days 15 👩‍💻

🎁 Бонус для участников конференции и подписчиков канала GetAnalyst 🎁

1. Подборка книг по проектированию и архитектуре информационных систем
2. Полная версия презентации
3. Карта навыков системного аналитика

Получить 🔗

Скучаю по мероприятиям с вами, поэтому готовимся к следующей неделе: буду делиться скилом работы с Postman в прямом эфире! Расскажу теорию за 15 минут и сразу же погружу в практику 😉

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

По такой схеме действует API — запрос - обработка - ответ.

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

Принцип простой: отправляешь входные данные в запросе и проверяешь верность выходных данных в ответе.

Для тестирования используют специальные инструменты. Наиболее популярным считается Postman. Он позволяет:
✅ отправлять на сервер запросы и обрабатывать ответы,
✅ сохранять запросы в коллекции,
✅ создавать разные окружения,
✅ добавлять к вызову API контрольные точки.

Плюсы Postman:
+ простой и удобный интерфейс
+ имеет внушительный набор функций
+ подходит для разработки и тестирования API
+ поддерживает исследовательские и автоматизированное тестирования
+ позволяет работать на любой ОС
+ бесплатный для личного пользования

Минусы:
Пока не нашла 🙂

Postman используют тестировщики, разработчики, и аналитики в процессе разработки. В каждой второй вакансии системного аналитика навык работы с Postman указан как обязательный. Рассказать как они его используют? Ставь 👍

Цели тестирования API

🔹 Для тестировщика - выявить баги и создать задачи к исправлению для разработчиков Backend.

🔹 Для разработчика Backend - проверить, что он верно реализовал метод, настроить автотесты, и поделиться коллекцией с разработчиками клиентов (Frontend), тестировщиками и аналитиками.

🔹Для разработчика Frontend - получить по сути интерактивную API-документацию для проверки API-методов, которые должны быть встроены в приложение (мобильное, сайт или другое).

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

Я хочу на практике показать, как работать с инструментом тестирования API - Postman. И объяснить, зачем и когда он нужен аналитикам. Показывать буду на примере тестирования REST API. И попрошу вас практиковаться вместе со мной 😉

Уже завтра! Бесплатный вебинар:
🚀 Postman: навык тестирования REST API за вечер
🗓 9 ноября (ср), 19:30-21:00 (Мск)
🔗 Регистрация здесь

Жду вас в прямом эфире! 👩‍💻

Уже через 3 часа! Вебинар Екатерины Ананьевой
📹 Postman: навык тестирования REST API за вечер
⏰ 19:30 - 21:00 Мск

Ссылку на трансляцию пришлем в канал за 15 минут до начала.

❗️До начала вебинара 15 минут ❗️

Присоединяйтесь😉
https://pruffme.com/webinar/?id=eb037c3c0bdffeaa32daee5fed0eb6c6

Это был очень крутой вебинар! 🦊 Практика! По шагам разбирали работу с Postman!

Пропустили или не удалось досмотреть до конца? Зарегистрируйтесь здесь и пришлем информацию про повтор в почту ✉️

До встречи ☀️
Про путешествия лисы и тюленя - подписывайтесь на Instagram.com/katherine__aa 🦊 🦭

В книге Release IT Майкла Нейгарда по проектированию архитектуры, в главе 16, есть крутая история про ЧЕРНУЮ ПЯТНИЦУ. Он описывает во всех подробностях, как в этот день покупатели создают пиковую нагрузку и убивают Интернет-магазин.

Прекрасные цитаты:

Черная пятница. Число покупателей в магазинах за сутки может увеличиться в 4 раза. Трафик в интернет-магазинах может возрасти на 1000 %. И это настоящее нагрузочное тестирование, единственное тестирование, которое имеет реальное значение.

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

На следующее утро, в Черную пятницу, я перед завтраком снова побрел в родительский кабинет, взглянуть на статистику. Количество заказов почти побило вчерашние показатели. Число сеансов было большим, но период ожидания страницы все еще не превышал 250 миллисекунд — установленную нами норму.

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

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

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

Так что у кого-то в ЧЕРНУЮ ПЯТНИЦУ радость, а у команды разработки и аналитиков торговых систем рука на пульсе 🙂

Сегодня, 11.11.22, как раз ЧЕРНАЯ ПЯТНИЦА! И в честь этого события я дарю вам
‼️ СКИДКУ 30% на любой практический курс GetAnalyst в продаже
🟢 ПРОМОКОД: 111122
⏰ до 12 ноября 23:59 (Мск)

Сегодня самая лучшая возможность получить знания в GetAnalyst!

Интеграция — что это такое?

Ситуация: вам нужно купить билет на самолёт. И вместо того, чтобы гулять по сайтам авиакомпаний в поисках нужной цены, вы заходите в одно приложение и просто вбиваете пункты А-В и желаемые даты. Это приложение называется Агрегатор.

Агрегатор выдаёт все возможные варианты, вы выбираете приемлемую цену и совершаете заказ. Согласитесь, это очень удобно!

Аналогично работают приложения Госуслуги, банки, сервисы по доставке еды и многие другие. Все возможности через единое окно!

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

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

Как итог, пользователю не приходится обращаться к множеству ресурсов - всё в одном месте ✅

В чём сложность работы аналитика с интеграциями?

1️⃣ Каждый раз новые задачи по проектированию
Всегда возникают особенности. Да, есть определенные шаблоны, которые приходят на помощь архитекторам и разработчикам, но с точки зрения аналитика, таких шаблонов нет.

2️⃣ Данные беспорядочны и не структурированы
Форматы условий бывают разные, а порой и несовместимые. Аналитик решает эту задачу.

3️⃣ Старые системы не упрощают интеграцию
Даже если при реинжиниринге процессов выяснится, что старые системы дают вполне хорошие показатели, можно столкнуться с проблемами их использования.

4️⃣ Требования могут меняться прямо в процессе работы
Особенно если надо интегрироваться с государственными системами (выходят поправки в действующее законодательство, меняются бизнес-процессы)

5️⃣ Работа с повышенной защитой информации
Информация — один из важнейших активов бизнеса. При передаче персональных и финансовых данных нужно решать вопросы с её безопасностью.

В каждом интеграционном кейсе будут свои подводные камни. Будьте готовы, что придётся максимально точно поработать с документацией (ТЗ, ЧТЗ, СТП, API). Важно, как можно подробно, описать то, что требуется сделать разработчикам. От этого будет зависеть конечный результат👌

Тема интересная и не такая сложная, если разобраться что за ней стоит 😉 Делитесь в комментариях, что еще вам хочется узнать про интеграции!

В предыдущем посте в качестве примера интеграций я уже затронула тему покупки билетов в онлайн через агрегатор ✈️🚌🚞

Какие ещё бывают интеграции, с которыми мы можем встретиться в жизни?

◾️ Терминал для покупки билетов на поезд / автобус
Есть терминал на вокзале. Человеку нужно купить билет: ввести пункты отправления и прибытия, найти рейсы, указать дополнительные данные, оплатить, получить распечатанный билет. Оплата может выполняться с подключением к оборудованию работы с картами и банком - это интеграция. Поиск билетов может быть не только в системе одного вокзала, но и в других источниках данных - тоже интеграция.

◾️ Системы аналитики
Для того, чтобы отслеживать действия пользователя на сайте или в приложении могут подключать Яндекс.Метрику и Google Analytics. Это нужно для построения отчетов по активности пользователей. По нажатию на определенные кнопки, либо при получении определенных данных пользователем, действия из нашей системы могут передаваться в эти системы аналитики. Процесс передачи данных о них - интеграция.

◾️ Интеграция бухгалтерской системы с банком
Необходимо подгружать из банка актуальный реестр платёжных документов - счетов. Для этого бухгалтерская система выполняет запросы к банковской, чтобы узнать у нее - появились новые документы или нет. Процесс запроса и получения данных - интеграция.

Согласитесь, всё это напоминает простое общение между людьми.
Системы общаются между собой, как и люди коммуницируют друг с другом. В каждом случае, чтобы договориться о чём-либо, нужен индивидуальный подход:
✅ Задаем правильные вопросы - запросы к системе, из которой хотим получить данные
✅ Получаем ответы - система, у которой мы попросили данные, "думает", а затем возвращает ответ. Успешный, удовлетворяющий наши ожидания, или не очень - ошибка 😅

Каждая интеграция между системами имеет уникальные особенности. Процесс взаимодействия систем необходимо прорабатывать, опираясь на конкретный контекст. Только опыт аналитика позволяет быстро решать интеграционные задачи, видеть все "подводные камни", и делать лучшие решения! Но все же я нашла общие подходы в решении интеграционных задач, и делюсь ими со своими учениками 🙌

Привет!

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

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

Для меня получать новые задачи всегда сравнимо с увлекательным приключением. Предвкушение новых знаний! Разбираться и погружаться в детали проектирования. Честно, могу зависнуть в работе на десятки часов, и даже этого не заметить. Это как игра: получится или нет?!

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

У нас в проекте уже был поисковой движок, который позволял получать данные о перевозках из нашей базы данных (БД) и показывать их пользователям. По сути нужно было просто добавить к нам проект а-ля чужую БД и показывать из нее данные вперемешку с нашими.

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

Самой главной преградой было: с чего начать-то?

В итоге я начала с того, что посмотрела на функции пользователей в нашей системе. Взяла для старта поиск пунктов отправления / прибытия и поиск рейсов. Затем посмотрела на содержание API-документации автовокзала. И дала разработчикам задачи формате:
📝 Поддержите загрузку пунктов отправления / прибытия из системы вокзала. Метод загрузки данных возьмите из раздела документации автовокзала, пункт такой-то.
📝 Поддержите загрузку рейсов из системы вокзала. Метод загрузки данных возьмите из раздела документации автовокзала, пункт такой-то.
Ничего умнее я не придумала. Мне показалось, что этого достаточно.

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

Во что обернулись первые постановки задач?
Я скопировала методы из этой API-документации в наши постановки задач как есть, потому что даже толком не понимала, как её читать. Структуру примерно улавливала, но как с этим работать до конца не осознавала. Задачи ушли в разработку.

После этого на меня обрушились уточняющие вопросы от разработчиков 🤦‍♀️ А как? А куда? Какие данные брать? Как состыковать время по часовым поясам в нашей системе, что делать, если дубликаты остановочных пунктов?

Шаг за шагом со всем разбилась. Гуляла по граблям от вопроса к вопросу, не понимала, что делать, и только уточняла-уточняла-уточняла.

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