Json зачем нужен системному аналитику
Перейти к содержимому

Json зачем нужен системному аналитику

  • автор:

REST, что же ты такое? Понятное введение в технологию для ИТ-аналитиков

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

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

Выясним, почему существует терминологическая путаница вокруг REST и как нам научиться лучше понимать коллег.

Поговорим о том, как связаны HTTP и REST. А также почему REST противопоставляют SOAP.

Терминология

Формат представления данных

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

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

Но я мог бы написать это и на английском: blue, green, red, white, black.

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

  • Plain text — это обычный текст, который я использовал при написании письма;
  • XML — язык разметки информации;
  • JSON — текстовый формат обмена данными;
  • Binary — бинарный формат.

Давайте запомним из этой части статьи что XML и JSON — это форматы представления данных.

Протокол передачи данных

Я написал письмо и теперь хочу его отправить. Что мне нужно для этого сделать? Как правило, я кладу письмо в конверт. В нашем случае таким конвертом будет такое понятие, как протокол передачи данных.

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

Аналогия протокола передачи данных с письмом в конверте

Если продолжать рассматривать аналогию с письмом, то стоит обратить, что:

1. конверт имеет структуру;

2. я наклеиваю на конверт марки, указываю определённую информацию: от кого письмо, куда я его отправляю, адрес и т.д.

Транспорт

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

Транспорт — это подмножество сетевых протоколов, с помощью которых мы можем передавать данные по сети.

Такими протоколами могут быть, например: HTTP, AMQP, FTP.

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

Чтобы указать, что данные в определенном формате передаются с помощью некоторого транспорта, часто используют запись вида over .

  • JSON over HTTP
  • XML over HTTP
  • XML over MQ

Протокол HTTP

HyperText Transfer Protocol (HTTP) — это протокол передачи данных. Изначально для передачи данных в виде гипертекстовых документов в формате HTML, сегодня — для передачи произвольных данных.

Этот протокол имеет две особенности, которые должны учитывать все, кто работает с этим протоколом: ресурсы и HTTP-глаголы.

Ресурсы

Чтобы разобраться с понятием ресурса, давайте представим, что у нас имеется некоторая ссылка: http://webinar.ru/schedule/speech.

Это как раз и есть тот самый URL, который мы используем поверх HTTP. Рассмотрим, из чего состоит эта ссылка:

А вот как нам работать с этими объектами, нам говорят HTTP-глаголы (методы).

HTTP-глаголы

HTTP-глаголы — это элемент протокола HTTP, который используется в каждом запросе, чтобы указать, какое действие нужно выполнить над данным ресурсом.

  • GET/schedule/speech/id413 — получить информацию об объекте

Здесь мы видим некоторый объект (ресурс) с конкретным идентификатором с номером 413. Я могу использовать HTTP-глагол GET для, того чтобы получить информацию о выступлении 413.

Я могу воспользоваться каким-либо другим HTTP-глаголом, если мне необходимо выполнить какие-либо другие действия.

  • PUT/schedule/speech/id413 — создать или перезаписать объект

Или удалить объект:

  • DELETE/schedule/speech/id413

Главное здесь то, что мы рассматриваем некоторые объекты (ресурсы) и совершаем над ними некоторые действия, которые определены в протоколе списком HTTP-методов: GET, PUT, POST, DELETE и т.д.

Что такое REST?

Какое же определение в понятие REST заложил его основатель Рой Филдинг?

Representational State Transfer — это архитектурный стиль взаимодействия компонентов распределённого приложения в сети. Архитектурный стиль – это набор согласованных ограничений и принципов проектирования, позволяющий добиться определённых свойств системы.

Но зачем нам REST? Зачем нам этот стиль? Что нам даст применение принципов REST?

Если мы обратимся опять же к первоисточнику — к работе Филдинга, то мы выясним, что назначение REST в том, чтобы придать проектируемой системе такие свойства как:

  • Производительность,
  • Масштабируемость,
  • Гибкость к изменениям,
  • Отказоустойчивость,
  • Простота поддержки.

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

Принципы REST

Каким образом REST может помочь нам достичь этих свойств и реализовать эти нефункциональные требования?

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

6 принципов REST:

  1. Клиент-серверная архитектура
  2. Stateless
  3. Кэширование
  4. Единообразие интерфейса
  5. Layered system
  6. Code on demand

Далее мы рассмотрим эти шесть принципов поподробнее.

Принцип 1. Клиент-серверная архитектура

Сама концепция клиент-серверной архитектуры заключается в разделении некоторых зон ответственности: в разделении функций клиента и сервера. Что это означает?

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

Что мы этим добиваемся и как могло бы быть иначе? Давайте представим, что клиент и сервер у нас объединены. Тогда, если мы говорим о мобильном приложении, каждое мобильное приложение каждого клиента должно было бы быть абсолютно самодостаточной единицей. И тогда, поскольку у нас единого сервера нет для получения/отправки информации, у нас получилась бы какая-то сеть единообразных компонентов – например, мобильные приложения общались бы друг с другом – такая распределённая сеть равноценных узлов.

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

Клиент-серверная архитектура

Также сервер может иметь базу данных (см. рисунок ниже). В данном случае надо понимать, что пара «сервер и БД» тоже будет парой «клиент-сервер». Только в данном случае сервером будет БД, а сам сервер — клиентом.

Трёхзвенная архитектура

Что дает клиент-серверная архитектура и зачем она нужна?

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

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

Конечно, есть и минусы. В случае с клиент-серверной архитектурой мы понимаем, что у нас есть единая точка отказа в виде сервера. Если отказал сервер и у нас нет дополнительных инстансов, то для нас это будет означать неработоспособность системы.

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

Принцип 2. Stateless

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

Пример реализации принципа Stateless. Запрос погоды на 20.06 в Москве

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

Что мы делаем в случае, если мы работаем с Stateless? Мы отправляем запрос «Какая погода?», отправляем место, где хотим погоду узнать, и дату. Соответственно, прогноз погоды отвечает нам — «Будет жарко».

Если я захочу узнать, какая будет погода через день, то опять укажу место, где хочу узнать погоду, укажу другую дату. Сервер получит этот запрос, обработает и сообщит мне, что там уже будет очень жарко.

Пример реализации принципа Stateless. Запрос погоды на 21.06 в Москве

Рассмотрим ситуацию: что было бы, если бы у нас не было Stateless? В таком случае у нас бы был Stateful. В этом случае сервер хранит информацию о предыдущих обращениях клиента, хранит информацию о сессии, какую-то часть контекста взаимодействия с клиентом. А затем может использовать эту информацию при обработке следующих запросов.

Приведём пример на рисунке:

Пример реализации принципа Stateful

Я всё так же хочу узнать, какая погода будет завтра: отправляю запрос, сервер его обрабатывает, формирует ответ и, помимо того, что он возвращает ответ клиентам, он еще сохраняет какую-то информацию (часть или всю) о том, какой запрос он получил. В случае, если я захочу узнать, какая погода будет через день, я могу сделать такой вызов: «А завтра?». Не сообщая ничего о месте и о дате.

В этом случае у сервера хранится некоторый контекст. Он понимает, что я у него спрашиваю про 21-е число и могу дать ответ на основе информации, хранимой у него в БД или в кэше. Один из примеров, где можно встретить подход Stateful в жизни — это работа с FTP-сервером.

Вернёмся к Statless-подходу. Почему в REST-архитектуре мы должны использовать именно Statless-подход?

Какие он даёт плюсы?

  • Масштабируемость сервера,
  • Уменьшение времени обработки запроса,
  • Простота поддержки,
  • Возможность использовать кэширование.

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

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

Также подход Stateless позволяет использовать кэширование.

Какие проблемы может создать Stateless-подход?

  • Усложнение логики клиента (именно на стороне клиента нам нужно хранить всю информацию о состоянии, о допустимых действиях, о недопустимых действиях и подобных вещах).
  • Увеличение нагрузки на сеть (каждый раз мы передаём всю информацию, весь контекст. Таким образом, больше информации гоняем по сети).

Принцип 3. Кэширование

В оригинале этот принцип говорит нам о том, что каждый ответ сервера должен иметь пометку, можно ли его кэшировать.

Что такое кэширование?

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

Например, клиент обратился к серверу с запросом «Хочу узнать погоду». Что делает сервер?

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

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

Пример реализации архитектуры с использованием кэширования

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

Какие у кэширования плюсы?

  • Уменьшение количества сетевых взаимодействий.
  • Уменьшение нагрузки на системы (не грузим их дополнительными запросами).

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

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

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

Принцип 4. Единообразие интерфейса. HATEOAS

Hypermedia as the Engine of Application State (HATEOAS) — одно из ограничений REST, согласно которому сервер возвращает не только ресурс, но и его связи с другими ресурсами и действия, которые можно с ним совершить.

Рассмотрим пример. Возьмём HTTP-запрос, в котором я хочу получить определенный ресурс:

Пример запроса ресурса

Здесь мы используем HTTP-глагол GET, то есть хотим получить ресурс. Обращаемся к некоторому счёту с номером 12345.

Если бы мы не использовали подход HATEOAS, то получили бы примерно такой XML-ответ:

Пример ответа без использования принципа HATEOAS

Здесь указан номер счёта, баланс и валюта.

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

Пример ответа с использованием принципа HATEOAS

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

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

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

Принцип 5. Layered system (слоистая архитектура)

В предыдущих схемах мы рассматривали сторону клиента и сторону сервера, но не думали, что между ними могут быть посредники.

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

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

Модель слоистой архитектуры

Знания балансировщика в этой схеме об участниках конкретно этой цепочки вызовов должны заканчиваться proxy-сервером слева и сервером справа. О клиенте он уже ничего не знает.

Если изменяется поведение proxy-сервера (балансировщика, роутера или чего-то ещё), это не должно повлечь изменения для клиентского приложения или для сервера. Помещая их в эту цепочку вызовов, мы не должны замечать никакой разницы. Это позволяет нам изменять общую архитектуру без доработок на стороне клиента или сервера.

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

Принцип 6. Code on done (код по требованию)

Идея передачи некоторого исполняемого кода (по сути какой-то программы) от сервера клиенту.

Модель архитектуры, реализующей принцип

Представьте, что клиент — это, например, обычный браузер. Клиент отправляет некоторый запрос и ждёт ответа — страницу с определённым интерактивом (например, должен появляться фейерверк в том месте, где пользователь кликает кнопкой мышки). Это всё может быть реализовано на стороне клиента.

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

Что мы за счёт этого получаем? Отчасти, это схоже с принципом HATEOAS. Мы позволяем клиенту стать гибче. Если мы захотим изменить цвет фейерверка, то нам не нужно вносить изменений на клиенте — мы можем сделать это на сервере, а затем передавать клиенту. Пример такого языка — javascript.

Насколько же сходятся идеи, которые вложил Рэй Филдинг в концепцию REST, с восприятием REST аналитиками?

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

1. Ограничения REST опциональны (необязательны)

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

2. REST — протокол передачи данных

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

Но, в целом, REST — это концепция, парадигма, но не протокол. В отличие от HTTP, который действительно является протоколом.

3. REST — это всегда HTTP

С одной стороны, ни один из архитектурных принципов REST не говорит нам о том, какой транспорт мы должны использовать — HTTP или очереди.

Но при этом в жизни очень часто встречаются люди, для которых REST и HTTP — это аксиома.

Поэтому, если сказать человеку, что REST — это необязательно HTTP, то вас могут посчитать сумасшедшими.

Почему же все считают, что REST — это HTTP? Здесь нужно сделать ремарку, что одним из главных авторов протокола HTTP — это Рэй Филдинг, автор концепции REST. Рэй Филдинг стремился спроектировать HTTP так, чтобы с помощью него концепцию REST было максимально удобно реализовывать.

4. REST — это обязательно JSON

Почему так сложилось? Главная причина в том, что какое-то время назад сервисы вида JSON over HTTP стали противопоставлять SOAP. JSON одновременно стал популярным и стал антагонистом XML, как SOAP подходу. JSON использовался, потому что это не SOAP.

Модель зрелости REST-сервисов

Модель зрелости REST-сервисов Ричардсона

Ричардсон выделил уровни зрелости REST-сервисов. Выделение происходило исходя из подхода, что REST — это, с точки зрения протокола, всё-таки HTTP. Соответственно, он спроектировал модель, по которой можно понять: насколько сервис REST или не REST.

Уровень 0

В первую очередь, он выделил нулевой уровень. К нему относятся любые сервисы, которые в качестве транспорта используют HTTP и какой-то формат представления данных. Например, когда мы говорим про JSON over HTTP – мы говорим про нулевой уровень.

Если более наглядно «пощупать ручками» с точки зрения использования протокола HTTP, то можно представить, что мы выставляем некоторый API. Мы начинаем с того, что объявляем единый путь для отправки команд и всегда используем один и тот же HTTP-глагол для совершения абсолютно любых действий с любыми объектами. Например: создай вебинар, запиши вебинар, удали вебинар и т.д. То есть мы всегда используем один и тот же URL и всегда используем один и тот же HTTP-метод, обычно POST.

Как один из примеров:

Пример 0-го уровня соответствия REST

Уровень 1

Следующий уровень — первый. Мы уже научились использовать разные ресурсы и делаем это не по одному URL. Но при этом всё ещё игнорируем HTTP-глаголы.

Мы просто разделяем явно наши объекты, как некоторые ресурсы. Например: спикер, курс, вебинар. Но, независимо от того, что мы хотим сделать — удалить, создать, редактировать, мы всё равно используем один и тот же HTTP-глагол POST.

Пример 1-го уровня соответствия REST

Уровень 2

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

Например, если есть спикер, то, чтобы создать спикера и получить информацию о нём, я использую соответствующий глагол: GET, POST. Когда хочу создать или удалить спикера — я использую глаголы: PUT, DELETE.

По сути, второй уровень зрелости — это то, что чаще всего называют REST.

Надо понимать, что, с точки зрения изначальной концепции, если мы дошли до второго уровня зрелости, то это еще не означает, что мы спроектировали REST-систему/ REST-сервис. Но в очень распространённом понимании соответствие 2-ому уровню часто называют RESTfull сервисом.

RESTfull-сервис — это такой сервис, который спроектирован с учётом REST-ограничений. Хотя, в целом, правильнее сервис такого уровня зрелости называть HTTP-сервисом или HTTP-API, нежели REST-API.

Пример 2-го уровня соответствия REST

Уровень 3

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

Пример 3-го уровня соответствия REST

Выводы, которые мы можем сделать из модели зрелости

Итак, как нам эта модель может помочь понять то, что наши коллеги называют RESTом в каждой отдельно взятой компании? REST у вас или не REST?

Первая распространенная трактовка термина REST — всё, что передаётся в виде JSON поверх HTTP.

Вторая, не менее популярная версия, REST — это сервис второго уровня зрелости, то есть HTTP-API, составленное в соответствии со спецификацией HTTP-протокола. Если мы правильно выделяем ресурсы, правильно используем HTTP-глаголы, а также выполняем некоторые требования HTTP-протокола, то у нас REST.

Что называют RESTом?

Подведём итоги

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

Во-вторых, принципы REST мы часто применяем в жизни. Они очень полезны для осмысления. Кэширование, STATELESS и STATEFUL, клиент-серверная модель или код по требованию — это те вещи, которые аналитику полезно знать для понимания.

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

1. Способы описания API

  • https://swagger.io/specification/
  • https://raml.org

2. Инструменты для тестирования API

  • https://www.postman.com
  • https://www.soapui.org

3. Большой список открытых API

4. Ещё открытые API

  • https://jsonplaceholder.typicode.com
  • https://dadata.ru/api/
  • https://coda.io/developers/apis/v1
  • https://developer.kontur.ru/doc/focus?about=2

Вопросы участников вебинара и ответы на них Андрея

Что входит в задачи системного аналитика при проектировании REST-сервиса?

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

Кто-то проектирует архитектуру сервиса, кто-то только формирует API. Наиболее часто аналитик готовит описание REST-сервиса с помощью каких-нибудь формализованных языков (например, Swagger или JSON-схемы).

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

В каких программах можно потренироваться новичкам и разобраться в командах, взаимодействиях REST (возможно, SOAP)?

Первое, о чём хочется рассказать сказать, это об инструменте Postman. Его можно как скачать и установить на ПК, так и работать онлайн. Postman — это некоторая утилита, которая позволяет вызывать внешние сервисы, внешние API, реальные REST-сервисы (которые работают поверх протокола HTTP) и используется для тестирования.

Также можно упомянуть SOAP UI и Swagger UI. Кстати, Swagger — это не только некоторый язык формального описания API, но ещё и редактор, с помощью которого можно вызывать реальные сервисы.

Какую последовательность действий можно посоветовать?

  1. Найти общедоступное API;
  2. Выбрать одну из утилит (я бы рекомендовал начать с Postman);
  3. Тренироваться.

Как определить необходимую детализацию описания требований REST API в конкретном проекте? Есть ли хорошие шаблоны описания?

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

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

Какую документацию по интеграции должен уметь делать аналитик?

Ответ такой же, как и в предыдущем вопросе. Всё зависит от проекта и от того, как вы договоритесь с командой.

Если говорить про описание API, то это могут быть разные формальные языки. Описание REST API с помощью Swagger, описание транспортов/протоколов с помощью JSON-схемы, с помощью XSD + WSDL, если это SOAP-сервисы.

Ещё аналитик проектирует взаимодействие между системами или сервисами. Очень часто это визуализируют с помощью диаграммы последовательности (sequence diagram). Также можно использовать use case для описания взаимодействий не только пользователь-система, но и для описания интеграций. Также используют диаграмму потоков данных и компонентные схемы.

Об авторе

Андрей Бураков

Разработчик, аналитик и product owner в кровавом энтерпрайзе и продуктовой разработке

  • Создал отдел системного и бизнес анализа VK Pay;
  • Автор телеграм-канала об анализе и архитектуре Yet another SA channel;
  • Автор и ведущий курсов по системной интеграции.

Эффективный системный анализ в больших продуктовых компаниях. Как появился системный анализ в Parimatch Tech

Я занимаю позицию Lead Systems Analyst в продуктовой компании Parimatch Tech (ранее — PMLAB) около года, в самой компании работаю около 4 лет. Также на сегодня я создал эффективную работу направления Systems Analysis в таких компаниях как Wirex, Betinvest, Terrasoft и других в сфере Fintech. Общий стаж работы в IT более 10 лет. Занимал в компаниях разные должности — РМ / РО / SA / BA, но всегда с уклоном в системный анализ. Руководящая позиция более 8 лет.

Кто такой SA? Зачем нужен SA?

SA — Systems Analyst.
Давайте обратимся за расшифровкой терминологии к Wiki:

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

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

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

SA — это довольно «молодая» профессия в украинской IT— индустрии, но формально эта профессия всегда существовала, «отвечая» в первую очередь за автоматизацию, постановку требований (ТЗ) и описание сложных технических процессов.
Но все же фактическое отсутствие SA на рынке Украины обусловлено тем, что эту роль выполняли другие сотрудники. Раньше системам не было присуще такое большое количество технических подходов и принципов, разноплановых интеграций, что позволяло комбинировать роль системного аналитика вместе с ВА / PM / PO.

6 лет назад я пришел в стартап, где хотели создать небольшой коммерческий банк, где требовалось создать весь Digital с нуля и где девиз был «как у Приват24». Мы работали так: утром согласовывали договоры, бюджеты и тендеры, а вечером переходили к системному анализу и проектированию архитектуры. За 2 года нам удалось создать конкурентоспособный интернет-банкинг с полным предоставлением услуг 24/7, сервисы Р2Р переводов, ESB для интеграции решений, свою сеть терминалов, пополнение банковских карт в АТМ без наличия пластиковой карты, виртуальные карты и личный кабинет дня них.

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

Но сегодня мир заставляет нас отдельно выделить SA для решения таких проблем:
— Выполнение декомпозиции работ на компоненты — мы можем иметь в различных MSA более 150 сервисов, которые имеют API и параллельно взаимодействуют c MQ и данная паутина сервисов между собой умудряется взаимодействовать, но чем больше архитектура, тем сложнее развивать такую архитектуру. Системный анализ позволяет учитывать особенности интеграций сервисов между собой и декомпозировать работы для избежания несогласованности той или иной доработки.

— Сокращение затрат на внедрение. Системный анализ — это дисковый сервис. Мы покрываем большинство проблем, накапливаем базу знаний и понимание архитектурных особенностей продукта.

— Выполнение роли предварительного технического анализа — бизнес всегда хочет получать продукты быстро и дешево, но все мы знаем, что это желание на практике не реализуемое. Системный анализ позволяет предварительно разбить большую задачу на «важные» и «неважные» этапы реализации, а также помочь минимизировать затраты на внедрение. Часто бывает, что фича может принести бизнесу много денег, но цена ее разработки отбивает желание ее реализовывать. Если правильно «вклинить» ее в архитектуру и отказаться от определенных желаний, фича может быстро принести доход, при этом не быть реализованной в полном объеме. Сделать это можно с помощью SA.

— Поддержка актуальной архитектуры и знаний про сервисы компании. Это позволяет упростить:
* вхождение новых сотрудников в курс дел;
* аудиты и сертификации;
* анализ дефектов и поиск проблем;
* целостность и доступности информационной базы продукта.

Что делает SA в Parimatch Tech?

Все, что описано выше, но есть и особенность: у нас SA перерос в независимый сервис Pre-prod, в который входит BA / SA / Дизайн. Изначально SA были частью команд и это не позволяло выполнять комплексный анализ за рамками доверенного сервиса или продукта. Было принято решение создать кросс-команду SA, которая начала выполнять экспертно-аналитическую миссию по контролю всех компонентов компании и их интеграций, при этом ВА оставались частью конкретных стримов или команд и не выходили за рамки своего продукта, но часто взаимодействовали с SA.
Некоторое время мы выполняли работу в таком режиме, и подобный подход позволял работать эффективно, но все мы знаем, что если компания растет, требуется выполнять оптимизацию и адаптацию процессов, и анализ тому не исключение. Мы создали кросс-функциональную команду Pre-Prod, где объединили UX/UI, бизнес- и системных аналитиков.

Какую проблему решает Pre-Prod?

Мы получили внешний сервис, который используют РО для реализации своих проектов.
Сервис не является обязательным для прохождения через него всех задач компании, и это позволило сконцентрироваться на сложных и комплексных задачах.
Зона покрытия увеличилась — теперь все отвечают за продукт в целом, а не за компонент, и как результат, мы получаем максимальную вовлеченность и ответственность за фичу.
Мы смогли ускорить весь процесс анализа и передачи задачи в Delivery, чем снизили затраты компании на анализ, а также увеличили качество анализа за счет постоянной синхронизации дизайнеров и BA / SA.

Как Pre-Prod планирует свою работу?

Мы используем Scrum и двухнедельные спринты, которые начинаются и заканчиваются параллельно с Delivery, и наша основная цель — обеспечить Delivery на два спринта работы.

Почему вы обеспечиваете работой на два спринта?

Мы проводили исследование по «протуханию» задач. Parimatch Tech — «строительная» продуктовая компания, которая развернула свои паруса в сторону технологичности. Такой курс всегда приводит к беспрерывной интеграции и изменениям консистентности архитектурных структур, где технологичность соединена с гибкостью бизнеса — такая гремучая смесь всегда приводит к устареванию требований, которые лежат в шкафу.

Наша цель не хранить, утилизировать! Мы выполняем контроль и изучение наших бэклогов через компонент Jira — TimeStatus, и выводим все, что происходит на Dashboard. Если задача уже не актуальна — мы должны уточнить у РО, для себя разобраться в причинах и принять решение об утилизации.

Какой состав команды Pre-prod?
* SA — 5 человек;
* BA — 5 человек;
* UX / UI — 8 человек.

Parimatch Tech — это большая компания и потому у нас есть BA и SA, которые находятся за рамками Pre-Prod, и остались в функциональных стримах — это вызвано необходимостью и автономностью данных стримов. Пример: наша компания имеет внутренние продукты, которые предоставляют данные для наших платформ и эти продукты могут жить независимо, и оказывать сервис как В2С, так и В2В.

Как работал SA в других компаниях?

Ожидания у компаний всегда разные, но принцип работы одинаковый. SA отвечает за требования и декомпозицию. Многие компании привлекают SA как драйвера планирований команды, а также точку получения оценки.
Краткая формулировка — SA пишет техническое задание, ВА — пишет бизнес-задание, дизайнер — реализует визуализацию требований для конечного потребителя.

Получается, SA — это какой-то ботан?

Я думаю, что SA всегда должен иметь точку взаимодействия со всеми этапами жизненного цикла продукта, а это требует постоянной коммуникации и общительности. Есть стереотип, что системный аналитик — это ботан в очках, который не умеет разговаривать, но это не про нас : )
Я бы характеризовал SA так: это «несложившиеся» разработчики, но не потому что им не хватило знаний, а потому что SA дает в первую очередь возможность абстрактно мыслить и системно подходить к проектированию, мы выполняем роль «придумать и подумать». Также наши взгляды, скажем, более широкие, так как разработчик Backoffice не знает, как устроен логин на сайте для пользователя, но знает только логин Backoffice. Он не выходит за рамки своей работы, в то время как SA знают все про систему и платформу.

Какие подходы к документации системы вы используете?

Мы всегда анализируем мировые практики и пытаемся из них почерпнуть максимально полезную информацию для развития наших подходов, потому мы используем:

— индивидуальный шаблон BRD, который частично забрал рекомендации из IEEE 830 Software requirements specification/IEEE 1012 Software verification and validation;
— для моделирования бизнес-процессов BPMN 2.0;
— отображение интеграции сервисов и их архитектуры UML 2.0.

Имплементационная документация всегда доступна на Swagger при переходе на сервис, что позволяет отобразить структуру контроллера. Также мы используем интегрированную выгрузку данных в Postman.
Сама документация и архитектура всей платформы хранится на Confluence.

Если я хочу стать SA, что вы посоветуете?

Я сам проходил сложный, но интересный путь познания мира SA, и первое, что я учил, — это был SQL. Современный мир изменился и знаний SQL уже недостаточно, здесь нужно понимать:
— принципы ООП;
— Какие бывают архитектуры? Что такое MSA?
— Какие уровни модели OSI бывают и зачем они нужны?
— Что такое протокол прикладного уровня?
— Зачем нужна Json schema?
— Какое отличие между noSQL и SQL? Какие правила индексации?
— Как рисовать UML диаграмму последовательностей?
— Как использовать MQ?
— Зачем нужен подход в интеграции сервисов по принципу Event Sourcing?

Советую начинать свой путь с бизнес-анализа и плавно переходить в системный анализ. Когда вы научились слушать, чувствовать систему, понимать принципы интеграции и системного взаимодействия — вы уже SA. Достичь подобных знаний вам может помочь команда. Развивайте свои коммуникационные навыки и интересуйтесь у команды что и как работает, как FE ходит на BE. Научитесь говорить словами разработчиков и вы сможете стать SA.

Почему круто быть SA?

Вы становитесь независимым специалистом, так как SA может проектировать и проводить анализ на любом проекте и в любой системе. Нам все равно, это СRM или система платежей. Сегодня я анализирую процессинговый центр, а завтра работаю на платформе расчета рисков при строительстве мостов. Технические подходы практически одинаковые в разных сферах, а ваша ценность определяется знанием данных технологий и способностью их применить. Если мы сравним ВА — то бизнес-аналитики часто ограничены стажем работы в той или иной сфере. Существует фреймворк универсальности работы ВА, но чаще всего работодатель подбирает ВА, который уже имел опыт работы в его сфере, а с разработчиками, SA и архитекторами, как вы знаете, не так. Уровень компенсации SA выше, чем у ВА, и иногда равен позициям РМ / РО.

Вы получаете максимальную техническую экспертизу, но вместе с тем и большую ответственность. Меня привлекает ответственность — она показывает твою полезность в процессе. Когда тебе не доверяют ответственных дел, ты мысленно становишься ненужным и не сильно важным. Потому многие гонятся за ответственностью, а в SА её хватает.
Возможность менять и автоматизировать процессы бизнеса, что сказывается на эффективности компании в целом. Ваши действия могут увеличивать доходы компании в разы и каждое системное действие улучшает тот или иной функционал.

Я уже SA. Хочу работать у вас. Что сделать?

�� Подобається Сподобалось 0

До обраного В обраному 2

Что нужно знать системному аналитику уровня Middle и Senior: план развития Hard Skills

Решил составить для себя план развития (я в IT с 2007, как аналитик — с 2017). Что получилось: некий чек-лист с перечислением 13 блоков (от работы с требованиям до безопасности) с описанием, что обязательно и желательно знать/уметь.

С чего все началось. Я недавно менял работу, поэтому готовился к техническим собеседованиям. Для удобства составил шпаргалку частых вопросов по основным темам. Когда проходил собеседования и видел, чего я не знаю, то дописывал это в свою шпаргалку. А немного позже решил составить для себя что-то наподобие плана развития. При создании плана использовал личный опыт, опыт коллег, ряд статей, учебные планы нескольких школ, требования из вакансий.

В каждом блоке выделил обязательные знания/умения и дополнительные (в тексте это выделено как «Продвинутый уровень»).

  • «Обязательно» — это то что системному аналитику точно нужно знать (с моей точки зрения).
  • «Продвинутый уровень» — это дополнительные знания уровня Senior, либо это требуется из-за специфики проектов конкретного специалиста (например, мобильная разработка).

Из каких блоков состоит план

  1. Процесс разработки
  2. Работа с требованиями
  3. Моделирование систем
  4. Модели данных
  5. Пользовательский интерфейс (UI/UX)
  6. Интеграция систем
  7. Интеграция систем: архитектура REST
  8. Интеграция систем: протокол SOAP
  9. Интеграция систем: шина данных (ESB, MOM, MQ)
  10. Анализ данных
  11. Безопасность
  12. Тестирование
  13. Основы программирования

1. Процесс разработки

Обязательно

  • Типы ПО и их особенности (системное/прикладное/инструментальное, индивидуальное/групповое, web/desktop/app).
  • Жизненный цикл разработки программного обеспечения (Software development lifecycle — SDLC): сбор и анализ требований, проектирование, разработка, тестирование, внедрение, сопровождение.
  • Основные модели управления разработкой ПО (водопадные, итерационные). Основные гибкие методологии (Agile, Scrum, Kanban).
  • Основные участники команды разработки и сопровождения IT-проектов, их роли (разработчик, аналитик, тестировщик, product и project менеджер, сетевой инженер, DevOps). Разные виды аналитиков и чем они занимаются (системный, бизнес, продуктовый, веб, BI, аналитик данных).
  • Виды документации и их назначение (BRD, FSD/SRS, руководства пользователя, инструкции, регламенты, база знаний и т.д.).
  • Понятие «фреймворк».
  • Суть концепция CI/CD.
  • Общее представление о системе контроля версий.
  • Выстраивать взаимодействие и совместную работу с заказчиками, командой, экспертами и другими участниками процесса создания, развития и сопровождения проектов.
  • Планировать и выстраивать процесс работы; выделять, декомпозировать и приоритизировать задачи, управлять сроками и рисками.
  • Создавать разные виды проектной документации.

Продвинутый уровень

  • Прочие модели, методологии, подходы к управлению разработкой ПО (инкрементная, V-образная, Domain-driven design (DDD), Lean и т.д.).
  • Планировать процесс разработки фич и проектов, декомпозировать сложные процессы и задачи, ставить задачи другим участникам проекта.
  • Руководить реализацией отдельной фичи, руководить проектом, руководить другими сотрудниками. Планировать ресурсы. Управлять рисками.

2. Работа с требованиями

Обязательно

  • Что такое требования к разработке ПО. Виды требований (бизнес/пользовательские/системные, функциональные/нефункциональные и т.д.).
  • Источники требований, способы и инструменты сбора требований:
    • интервью, опросы, анкетирование
    • наблюдение за процессом
    • анализ внутренних документов компании (бэклог, планы развития, обращения в тех.поддержку и т.п.)
    • анализ требований законодательства и других внешних для компании документов
    • анализ текущих решений (собственных и внешних), систем-аналогов, ранних версий, прототипов
    • фокус-группы, мозговой штурм
    • анализ предметной области
    • сбор требований
    • анализ, выстраивание приоритетов и устранение противоречий
    • согласование
    • моделирование системы, описание процессов
    • ревью и итоговое согласование
    • сопровождение и управление изменениями
    • тестирование функционала, презентация результатов
    • Выделять заказчиков, лиц принимающих решения, заинтересованных лиц проекта, экспертов, пользователей, специалистов создания, внедрения и сопровождения данного проекта.
    • Выделять источники и собирать требования разными способами (особенно через интервью).
    • Выявлять истинные причин появления проекта и требований:
      • почему появилась задача: какую проблему решаем или что хотим улучшить
      • зачем это реализовывать: ради какого измеряемого результата
      • определение цены и ценности: какой результат получить реально в рамках данного проекта и имеющихся ресурсов, устроит ли он, стоит ли он потраченного времени и других ресурсов.
      • определять границы проекта: что будет, а что не будет реализовано в текущем проекте, выделать MVP

      Продвинутый уровень

      • Расширенные знания стандартов описания требований: ГОСТ 19, ГОСТ 34, EARS (The Easy Approach to Requirements Syntax) и т.п.
      • Выделять и описывать job story (Jobs-To-Be-Done).
      • Строить Impact Map (структура «зачем, кто, как, что»).

      3. Моделирование систем

      Обязательно

      • Основные виды архитектур, их описание, преимущества и недостатки, когда используются (локальная, монолитная, клиент/сервер/БД, SOA: сервис-ориентированная, MSA: микросервисная).
      • Понятия «хореография» и «оркестрация».
      • Понятия «фронтенд» и «бэкенд».
      • Описание процессов с помощью блок-схем (Flowchart).
      • Описание процессов в нотации BPMN
      • Описание процессов и системы в нотации UML:
        • Диаграмма вариантов использования — Use Case Diagram
        • Диаграмма активностей — Activity Diagram
        • Диаграмма состояний — State Machine Diagram
        • Диаграмма последовательностей — Sequence Diagram
        • Моделировать системы и описывать их с помощью разных нотаций (Flowchart, BPMN, UML) и разных способов (тексты, таблицы, схемы, диаграммы и т.п.).
        • Описывать бизнес-процессы, поведение пользователей и отклик системы, системные функции (процессы, осуществляемые системой без участия пользователя).

        Продвинутый уровень

        • Более глубокие знания архитектур (многослойная, многоуровневая, MVC: Model-View-Controller, клиент-серверная, файл-серверная, облачная, событийно-ориентированная, микроядерная, модульный монолит, peer-to-peer и т.д.)
        • Особенности реализации web, desktop и мобильных приложений. Кроссплатформенная разработка.
        • Расширенные знания нотации BPMN и UML.
        • Знание других нотаций, стандартов, фреймворков (IDEF0, IDEF3, EPC, DMN, VAD, SIPOC, BABOK и т.п.).
        • Модель С4 архитектуры программного обеспечения.
        • Описывать более сложные процессы в нотации BPMN.
        • Описывать более сложные процессы в нотации UML, использовать прочие виды диаграмм (Deployment Diagram, Component Diagram и т.д.).

        4. Модели данных

        Обязательно

        • Что такое концептуальная, логическая и физическая модели данных.
        • Структурированные, неструктурированные и слабоструктурированные данные.
        • Что такое и как между собой связаны: сущности (объекты), атрибуты, связи.
        • Основные принципы ООП. Понятия «класс», «объект», «экземпляр».
        • Типы баз данных (реляционные, объектно-реляционные, нереляционные — NoSQL, колоночные, текстовые). Когда какие используются. Популярные систем управления баз данных (СУБД) для каждого типа.
        • Как организованы реляционные базы данных, правила проектирования:
          • Основные принципы реляционных баз данных
          • Типы данных
          • Способы реализации связей
          • Нормализация: что это, зачем нужна, 3 формы
          • Первичный ключ, составной первичный ключ, внешний ключ, суррогатный ключ
          • NULL и пустые значения
          • Ограничения (NOT NULL, UNIQUE, PRIMARY KEY, FOREIGN KEY, CHECK, DEFAULT, INDEX, AUTO INCREMENT)
          • Создавать ER-диаграммы.
          • Проектировать простые базы данных.

          Продвинутый уровень

          • Более глубокие знания в проектировании реляционных БД
            • Представление (виртуальная таблица). Виды представлений.
            • Индексы
            • Триггеры
            • Транзакции. ACID-требования к транзакциям и CAP-теорема.
            • Временные таблицы (таблицы для промежуточных данных)
            • Хранимые процедуры
            • Сериализация данных
            • Что такое подмножества и какие бывают (DDL, DQL, DML, DCL, TCL).
            • SQL-инъекции
            • Чем отличаются и когда какую СУБД лучше выбрать (PostgreSQL, MySQL, Oracle, MS SQL, MongoDB, ClickHouse, DB2, Greenplum, SQLite, Elasticsearch, Cassandra и т.д.)
            • Описывать классы в UML: Class Diagram.
            • Проектировать более сложные реляционные базы данных.
            • Проектировать нереляционные базы данных.
            • Составлять логические модели по существующей базе данных.
            • Осуществлять реинжиниринг модели данных.

            5. Пользовательский интерфейс (UI/UX)

            Обязательно

            • Основы UI/UX, правила построения интерфейсов (принципы, этапы разработки, критерии качества).
            • Типовые элементы (экранные формы, модальные окна, хлебные крошки, пагинация и т.д.).
            • Понимание принципов адаптивной верстки.
            • Понимание, что такое «клиентский путь».
            • Создавать наброски и схемы графических интерфейсов системы.
            • Взаимодействовать с UI/UX специалистами.

            Продвинутый уровень

            • Расширенные знания UI/UX. В том числе в разных направления (web, app и т.д.).
            • Создавать макеты графического интерфейса системы (с помощью Figma или других специальных инструментов).
            • Создавать интерактивные прототипы графических интерфейсов.
            • Разрабатывать карты клиентского пути (CJM — Customer Journey Map).

            6. Интеграция систем

            Обязательно

            • Виды интеграций информационных систем (API, шина данных — ESB/MOM/MQ, общая база данных, файловый обмен). Их описание, преимущества и недостатки разных способов, что когда используется.
            • Pull-модель (первоначальный запрос производится клиентом) и push-модель (данные поступают от поставщика к пользователю на основе установленных контрактов).
            • Синхронное, асинхронное и реактивное взаимодействие.
            • Концепции stateful и stateless (с сохранением и без сохранения состояния на стороне сервера).
            • Основы синтаксиса JSON и XML.
            • Типы API (REST, SOAP, JSON:API, GraphQL, RPC, API нативных библиотек), их общее описание.
            • Веб-сервисы. Webhook.
            • Протокол HTTP
              • структура запроса и ответа (стартовая строка, HTTP-заголовки, тело сообщения)
              • основные методы в HTTP запросах, их назначение (GET, POST, PUT, DELETE, PATCH), концепция CRUD
              • структура URL (протокол, хост, порт, путь до ресурса, запрос/параметры)
              • коды состояния (1хх, 2хх, 3xx, 4xx, 5xx)
              • как передать html документ, json-файл
              • что такое HTTPS, отличие от HTTP
              • Проектировать интеграционные взаимодействия:
                • диаграммы потоков данных (DFD)
                • диаграммы последовательности (Sequence Diagram)
                • описание передаваемых и принимаемых данных
                • обработка ошибок и нештатных ситуаций, журналирование
                • ограничения на интеграцию
                • требования к качеству интеграций
                • описание преобразований данных
                • регламент передачи данных

                Продвинутый уровень

                • Уровни сетевого взаимодействия: модель OSI, TCP/IP, UDP, FTP, SSH, SFTP, WebSocket и т.п.
                • Какие есть сложности и проблемы при интеграции систем. Закон дырявых абстракций.
                • Что такое идемпотентность. Какие HTTP методы являются идемпотентными, а какие нет, почему.
                • Разрабатывать требования интеграции систем через GraphQL и JSON:API.

                7. Интеграция систем: архитектура REST

                Обязательно

                • Принципы REST архитектуры.
                • Отличие от SOAP.
                • Особенности применения REST в HTML (нельзя отправлять PUT и DELETE запросы из HTML-формы).
                • JSON Schema.
                • Понимать документацию с описанными REST API (в том числе в Swagger).
                • Проектировать и описывать интеграции REST API.
                • Работать с Postman

                Продвинутый уровень

                • Отличие от JSON:API.
                • Описывать интеграции REST API через OpenAPI и Swagger
                • Работать с cURL.

                8. Интеграция систем: протокол SOAP

                Обязательно

                • Основы протокола SOAP. Структура сообщения (XML файла). WSDL
                • XSD схема (XML Schema).
                • Понимать документацию с описанными SOAP API.

                Продвинутый уровень

                • Расширенные знания протокола SOAP (пространство имен, индикаторы элементов, XSLT, XPATH и т.д.).
                • Проектировать и описывать интеграции SOAP API, XSD схемы.
                • Работать с SOAP UI и Postman (для SOAP).

                9. Интеграция систем: шина данных (ESB, MOM, MQ)

                Обязательно

                • Что из себя представляет ESB (Enterprise Service Bus — сервисная шина предприятия), MOM (Message-oriented Middleware — ПО, ориентированное на обмен сообщениями в распределенном окружении), MQ (Message Queue — очередь сообщений, брокер сообщений).
                • Отличие ESB от MQ. Отличие ESB от ETL.
                • Понятия «топик» (издатель-подписчик) и «очередь» (отправитель-получатель).
                • Какие брокеры сообщений чаще всего используются (RabbitMQ и Kafka).
                • Понимать документацию с описанием интеграций через шину.
                • Описать документацию при использовании интеграции через шину.

                Продвинутый уровень

                • Разница между RabbitMQ и Kafka. Когда что лучше выбрать.
                • Как брокер сообщений (RabbitMQ и Kafka) гарантирует доставку сообщений.

                10. Анализ данных

                Обязательно

                • Основы анализа данных.
                • Знать что такое Big Data, BI, Data Science, ML.
                • Анализировать данные, находить ответы на вопросы, формировать отчеты, уметь их презентовать.
                • Работать с простыми SQL запросами
                  • CRUD-операции: SELECT, UPDATE, INSERT, DELETE
                  • Создание и удаление таблиц: CREATE, DROP, TRUNCATE
                  • Ограничение и сортировка: WHERE, LIMIT, DISTINCT, ORDER BY
                  • Дополнительные условия: = != <> >< AND, OR, BETWEEN, IN, IS NULL, IS NOT NULL, LIKE, NOT LIKE
                  • Арифметические операции: + — * / %
                  • Агрегирование данных: GROUP BY, AS, AVG, COUNT, MAX, MIN, SUM, HAVING
                  • Вложенные запросы (в части SELECT, FROM, WHERE)
                  • Объединение запросов: UNION, UNION ALL
                  • Объединение таблиц: JOIN (INNER, LEFT, RIGHT, FULL, CROSS)
                  • Комментарии

                  Продвинутый уровень

                  • Основы статистики.
                  • Основы продуктовой аналитики (продуктовые и маркетинговые метрики, CustDev, А/В тестирование, Unit-экономика и т.д.)
                  • Что такое OLTP (обработка транзакций в реальном времени), OLAP (интерактивный анализ данных — кубы), ETL (извлечение, преобразование, загрузка), ELT (извлечение, загрузка, преобразование), DWH (хранилище данных).
                  • Понимание принципов построения хранилищ данных.
                  • Основные системы аналитики данных.
                  • Проводить более сложный анализ данных, находить инсайты, аномалии. Формировать дашборды, визуализировать данные.
                  • Работать с более сложными SQL запросами
                    • Сложные составные запросы (в том числе с EXISTS, ANY, ALL, CASE, IF)
                    • Встроенные функции: ROUND, DATE, TIME, DATETIME, SUBSTR и т.д.
                    • Оконные функции (OVER)

                    11. Безопасность

                    Обязательно

                    • Что такое аутентификация, примеры способов аутентификации (пароль, ЭЦП, SMS, push уведомление, биометрия, многофакторная), что такое идентификация.
                    • Что такое авторизация, ролевая модель информационной системы.
                    • Что такое хеширование, как и где применяется (особенно для паролей).
                    • Что такое электронная подпись. Зачем и как используется.

                    Продвинутый уровень

                    • Что такое криптография, для чего используется. Симметричное и асимметричное шифрование. Открытый и закрытый ключи. TLS/SSL в HTTPS.
                    • Контрольная сумма: что это, как используется.
                    • Основные схемы и протоколы аутентификации (базовая аутентификация, аутентификация по cookies, аутентификация по предъявлению цифрового сертификата, аутентификация с помощью ключа API, OpenID/OAuth/JWT и т.д.)
                    • Что такое верификация и валидация.
                    • Принципы работы электронной подписи, виды (простая, неквалифицированная, квалифицированная), их отличия.
                    • Основные уязвимости веб сервисов и мобильных приложений.

                    12. Тестирование

                    Обязательно

                    • Процесс тестирования, тест кейсы и чек листы.
                    • Разрабатывать критерии и процесс проведения приемочного тестирования.
                    • Организовывать и проводить приемочное тестирование.

                    Продвинутый уровень

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

                    13. Основы программирования

                    Обязательно

                    • Какие основные языки программирования существуют, где применяются.
                    • Основы программирования (переменные, операторы, ветвление, циклы, функции и т.п.).
                    • Основы языка разметки документов HTML.
                    • Написать простую программу на любом ООП языке программирования.

                    Продвинутый уровень

                    • Более глубокое знание хотя бы одного из популярных ООП языков.
                    • Понимание основ HTML/CSS/JavaScript.
                    • Понимание ООП в программировании.
                    • Написать более сложную программу на любом ООП языке программирования.

                    Итоги

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

                    Какие знания и навыки нужны, и к какому уровню их отнести — это очень дискуссионный вопрос. Опять же, в каких-то блоках у меня знаний и опыта больше, а в каких-то меньше. Поэтому буду рад вашему мнению и вашим советам, особенно если что-то упустил (можно в комментариях, можно лично vk.com/chizhovav88).

                    Отдельная просьба — поделиться ссылками на митапы/форумы/каналы/соцсети, где происходит активное общение и публикуются полезные материалы по темам «аналитика», «управление IT-проектами», «запуск и развитие IT-проектов». Это тоже важная часть развития, которая у меня несколько просела.

                    • системный анализ
                    • обучение
                    • карьера в it
                    • Анализ и проектирование систем
                    • Учебный процесс в IT
                    • Карьера в IT-индустрии

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

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

                    Мы каждый день пользуемся электроникой с программным обеспечением (ПО): смартфонами, «умной» бытовой техникой, банкоматами и прочим. Созданием ПО занимается проектная команда, а системный аналитик — её участник. Он изучает проблемы пользователей и пытается понять, как их решить с помощью разработки ПО.

                    О том, что это за профессия и какие для неё нужны навыки, рассказывают продуктовый менеджер и один из авторов курса «Системный аналитик» Яндекс Практикума.

                    Инна Тетюлина
                    продуктовый менеджер курса по системной аналитике в Яндекс Практикуме
                    Дарья Борисова
                    один из авторов курса по системному анализу в Яндекс Практикуме, Tech lead в UniCredit Bank

                    Кто такой системный аналитик

                    Основная задача системного аналитика — помочь пользователям и проектной команде понять друг друга. Зачастую пользователи сами не могут описать, что им нужно, а проектная команда не может их понять. Это происходит потому, что пользователи хорошо ориентируются в своей предметной области. Например, для архивиста очевидно, чем «единица хранения» отличается от «единицы учёта». Разработчик же таких тонкостей не знает. И тут на помощь приходит системный аналитик, который разбирается:

                    • в предметной области пользователей. Говорит с ними на одном языке;
                    • в разработке ПО. Он общается с разработчиками, инженерами по тестированию и другими членами проектной команды.

                    Системный аналитик переводит слова пользователей на язык, понятный проектной команде, и наоборот.

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

                    Грейды

                    Чтобы понять, насколько востребована профессия системного аналитика, следует упомянуть о делении на грейды в мире IT.

                    • Junior (джуниор, опыт: 0–1 год) — из-за отсутствия опыта решает простые задачи под присмотром более опытных коллег. Обладает начальными знаниями по профессии.
                    • Middle (мидл, опыт: 1–3 года) — решает стандартные задачи самостоятельно, но всё ещё находится под присмотром старших. Может отвечать за крупные задачи, но иногда требуется помощь более опытных коллег.
                    • Senior (сеньор, опыт: 3+лет) — ключевой человек в команде, как правило — тимлид. У него прокачаны soft skills и hard skills. Занимается архитектурой, взаимодействием систем и другими высокоуровневыми вещами. Ментор/наставник для младших коллег.

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

                    Универсальный специалист

                    У системного аналитика есть преимущество перед разработчиками благодаря его универсальности. Например, разработчики специализируются на одном–двух языках программирования или конкретной технологии. Это ограничивает разнообразие проектов, на которых может работать такой специалист. У системного аналитика такой проблемы нет: он универсален, если обладает достаточными навыками и не боится погружаться в разные предметные области.

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

                    Системный аналитик уровня middle — универсальный боец в ИТ. На его стороне идеальное сочетание гибкости, навыков, опыта и цены.

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

                    Скилсет

                    Мы изучили вакансии за сентябрь 2022 г. hh.ru и выделили навыки, которые ценятся работодателями в системных аналитиках.

                    Soft skills

                    • Коммуникация с заказчиком и разработчиком. Аналитик большую часть времени общается либо с заказчиком, задавая ему вопросы, либо с разработчиком, объясняя ему, что хочет заказчик. Важно, чтобы любая коммуникация была эффективной.
                    • Умение работать в команде. Разработкой ПО занимается команда специалистов. Важно знать, какое место в ней занимает аналитик. Он – негласный «центр» команды, потому что 80% вопросов проходит через него.
                    • Готовность к обучению. На этапе, когда опыта в профессии мало или он отсутствует, важно стремиться к знаниям. В IT стремление к повышению своих компетенций возведена в абсолют – всегда есть область, в которой можно разобраться.
                    • Инициативность. Важный фактор во время становления в профессии. Приводит к расширению опыта и кругу полезных знакомств.
                    • Ответственность. Работодателю важно, чтобы специалист мог сам принять решение и взять ответственность за результат.
                    • Принципы управления проектом и людьми. Здесь имеются в виду организаторские способности. Они пригодятся при согласовании требований, постановке и распределении задач.
                    • Аналитическое мышление. Качество, которое позволяет выстраивать причинно-следственные связи и делать это быстро. Его можно воспитать — нужно лишь задаться такой целью.
                    • Планирование. Аналитик планирует не только свою работы, но и работу команды. Есть очень много факторов, которые аналитику нужно учитывать в своей работе.
                    • Внимательность. При сборе требований важно ничего не упустить и описать все возможные сценарии поведения системы и ошибки.
                    • Публичные выступления. Умение презентовать свои идеи или результаты работы помогает в продвижении по карьерной лестнице.

                    Hard skills

                    • SQL. Навык написания несложных запросов, чтобы самостоятельно проверять работоспособность кода и искать ошибки в логике.
                    • Принципы проектирования баз данных. База данных есть в любом проекте. Определение сущностей и связей — основная задача аналитика в этом процессе.
                    • Интеграция по REST API и протоколу SOAP. Потребности в функционале систем увеличиваются. Бывает, что такой функционал уже реализован во внешних сервисах, и эти решения нужно уметь внедрять путём интеграции. Указанные технологии — самые популярные способы передачи данных между системами.
                    • Знание жизненного цикла разработки ПО. Помогает понять, кому и для чего необходим результат работы аналитика, как и кем он верифицируется, зачем нужно управление требованиями и многое другое.
                    • Опыт работы с документацией. Системный аналитик должен грамотно структурировать документацию и постоянно актуализировать её. Чем лучше она организована, тем меньше времени тратится на актуализацию.
                    • Тестирование/координация тестирования. Результат своей работы аналитик передаёт не только разработчикам, но и тестировщикам. Аналитик — уникальный носитель экспертизы по части работы продукта. Именно к нему приходят с вопросами все члены команды, включая тестировщиков. Бывает, что тестировщиков и вовсе не на проекте, тогда эту роль выполняет аналитик.
                    • Знакомство UML и BPMN. Это самые популярные нотации, с которыми приходится работать аналитику при составлении диаграмм.

                    Где нужны системные аналитики

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

                    Количество вакансий по секторам, от общего рынка вакансий:

                    • Банковский сектор — 30%
                    • Ритейл — 15%
                    • Телеком — 15%
                    • Финтех — 10%
                    • Страхование — 8%
                    • Прочее (IT-продукт в не-IT-компании) — 22%

                    Цифровой банковский сектор в России — один из самых развитых в Европе, и он продолжает двигаться вперёд. В этих компаниях самый большой спрос на системных аналитиков. Сегодня банки развивают множество параллельных продуктов, не связанных с денежно-кредитной сферой.

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

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

                    Какие навыки нужны

                    У каждой компании свой набор желаемых навыков и «портрет» кандидата. Но можно проследить тенденции в каждом секторе. Мы собрали в таблицу данные по распределению определённых навыков в тех или иных секторах.

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

                    *Проценты упоминания навыков в одной из сфер

                    Анализ этой матрицы позволяет сделать несколько выводов:

                    1. Проектирование и SQL — наиболее востребованный навык. Особенно на него обращают внимание в банках. В этой сфере важна надёжность при проектировании, а цена ошибки слишком высока.
                    2. Второй по значимости навыков — интеграция. Большего всего его ценят в банках и финтех-проектах. В этих областях денежные потоки участвуют почти во всех сферах жизни, и их необходимо интегрировать в сопутствующие продукты.
                    3. В интеграции отдельную степень занимают вечные соперники REST и SOAP. Но их не всегда можно противопоставлять друг другу, так как эффективны в разных задачах. SOAP более старый, но в финансовой сфере его ценят за надёжность. Если есть желание попасть в эту сферу, то при изучении протоколов на него стоит обратить внимание.
                    4. Если вы обладаете навыком прототипирования пользовательских интерфейсов, то в банковском и финтех секторах вам будут особенно рады.

                    Следите за новыми постами по любимым темам

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

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *