Комментарии 37
Будут ли здесь приведены примеры конкретных систем, способов и принципов их построения?
Что то я вообще ничего не понял. Эти картинки из статьи, они имеют отношение к работе системного аналитика?
И если да, то наверное вы не стой стороны начали рассказывать об основах работы системного аналитика для "новичков в IT-индустрии".
Эти картинки из статьи, они имеют отношение к работе системного аналитика?
Да, либо к нему либо к архитектору.
Вас же не про архитектора спрашивали :-) К работе системного аналитика точно нет (про уровни сетевых стеков которые сугубо теория и в жизни не встречается - особенно прекрасно)
Согласен с тем, что модель OSI и TCP/IP это сугубо теория, но в статье и говорится о том, что это «база», которую необходимо знать.
Как минимум для того, чтобы потом не спроектировать какой-нибудь стриминговый сервис, который будет работать по TCP ;-)
В статье было много картинок. Те картинки, которые показывают, как что взаимодействует, вполне имеют отношение.
Я считаю, что нет. Автор считает иначе
Если вы имеете в виду картинки с абстрактным примером распределённой системы, то, на мой взгляд, они имеют прямое отношение к работе системного аналитика, поскольку хороший аналитик помимо выявления и описания требований к разработке (как своей прямой задачи) может и должен уметь проектировать солюшен архитектуру или хотя бы HLD.
А этими картинками я как раз и хотел продемонстрировать этот артефакт работы аналитика, поскольку предполагаю, что многих заинтересует как может выглядеть архитектура абстрактной системы.
Остальные картинки просто являются иллюстрацией тех или иных теоретических выкладок.
С тем, что для «новичков» это может быть сложно для восприятия я полностью согласен, но это лишь первая обзорная статья из запланированной мной серии.
Ох уж эта "системная аналитика" :(
От тестировщиков устали уже, теперь системные аналитики выходят на передний план😄
С "системной аналитикой", к сожалению, действительно все очень печально обстоит в индустрии. По крайней мере в РФ. Специалистов не хватает, а компании предлагают довольно существенные з/п на этой позиции.
Литературы минимально, в ВУЗах на это если и учат, то крайне избирательно (в целом позиция СА на мой взгляд - это скорее набор хард/софт навыков, нежели специализация), а завеса тумана, особенно для новичков, присутствует.
Именно поэтому я и пытаюсь изложить свои знания, чтобы помочь другим получить представление о профессии или узнать что-то новое.
К тому же невозможно расти в замкнутой среде, поэтому статьи на Хабр - один из способов профессионального развития и для меня в том числе.
Почему по вашему взаимодействие через SOAP не может быть асинхронным?
Потому что выполнение вызывающей процедуры приостанавливается с момента запроса и возобновляется только после возврата из вызываемой процедуры.
Можно конечно изобретать асинхронные варианты с коллбэками, но тут уже вопрос целесообразности.
На уровне реализации можно с любым запросом поработать асинхронно. Например: с использованием того же REST отправили запрос с клиента на сервер о генерации какого-либо отчета, получили ответ - запрос в обработке; поместили сообщение в очередь, обработали и прислали результат. Почему так не может быть? Запрос по факту может обработаться асинхронно.
Если про асинхронность в вашем тексте читать, то лично у меня, какая-то путаница возникает. Может быть стоит внести какие-то уточнения, что вы имеете ввиду. Мне кажется, привязывать какие-то технологии и протоколы к понятию синхронности/асинхронности нет смысла.
На уровне реализации можно с любым запросом поработать асинхронно. Например: с использованием того же REST отправили запрос с клиента на сервер о генерации какого-либо отчета, получили ответ - запрос в обработке; поместили сообщение в очередь, обработали и прислали результат. Почему так не может быть?
Вы полностью правы, именно такой подход я и имел в виду, когда отвечал о вариантах с коллбэками на предыдущий комментарий выше. Дополню статью этой выкладкой.
В статье я указывал, что примером синхронного взаимодействия может быть REST или gRPC, там есть слова, явно об этом говорящие.
Привязка конкретных технологий/протоколов к понятию синхронности/асинхронности действительно имеющий место быть вопрос. Но на мой взгляд, удобнее и логичнее использовать технологии по их прямому назначению, нежели изобретать велосипед, оборачивая синхронные взаимодействия во что-либо еще. Опять же - это архитектурный вопрос компромиссов и рисков.
Где такие картинки рисуете?
Про модели сетевого взаимодействия - откуда вы взяли, что у вас пакеты ходят на каждом уровне? Понятие пакеты относится только к сетевому уровню - IP.
А что "информация разделяется на пакеты, каждый из которых получает свой уникальный IP-адрес, указывающий на конечную точку доставки" - это вообще нонсенс :)
откуда вы взяли, что у вас пакеты ходят на каждом уровне? Понятие пакеты относится только к сетевому уровню - IP.
Я этого и не утверждал
информация разделяется на пакеты, каждый из которых получает свой уникальный IP-адрес, указывающий на конечную точку доставки" - это вообще нонсенс :)
Слово "пакет" в контексте абзаца использовалось исключительно как обозначение некой структуры данных. Но спасибо, что обратили внимание, я исправил, дабы не вносить смуту.
Спасибо. Хорошая статья
Судя по статье никто не понимает что за хрень вся эта системная аналитика. В 80% случаях вообще ничего из описанного не пригодится.
Системная аналитика возможна только когда человек является экспертом в каком то домене, а не вся эта хрень с бесполезным Rest и тупыми вопросами про Кафку.
Системная аналитика возможна только когда человек является экспертом в каком то домене, а не вся эта хрень с бесполезным Rest и тупыми вопросами про Кафку.
Абсолютно не согласен. Во-первых экспертиза не возникает на пустом месте, а во-вторых основы функционирования и принципы проектирования информационных систем универсальны и плюс-минус едины относительно любого домена.
Судя по статье никто не понимает что за хрень вся эта системная аналитика. В 80% случаях вообще ничего из описанного не пригодится.
В заголовке статьи указано, что она является обзорной и вводной статьей из запланированной мной серии, поэтому ваши реакционные выводы слишком поспешны, на мой взгляд.
По ощущениям, статья сделана из школьного реферата с добавлением прикольных, но абсолютно бесполезных картинок.
Спасибо за статью! Картинки - класс, говорят сами за себя вместо тысячи букв.
Как я поняла, вы планируете цикл статей, пожалуйста, пересмотрите их очередность, потому что для "новичков в IT", которые заявлены в начале статьи как целевая аудитория - эта статья будет очень сложной для восприятия и пугающей. Представьте, что вы выпускник универа, который не дал вам такого рода базу или человек, желающий "войти в IT", который рассматривает для себя возможность стать системным аналитиком, он натыкается на эту вводную статью и мягко сказать удивлен, что все это с порога нужно знать. Плюс не всегда системный аналитик настолько хардовый нужен на проекте, очень сильно зависит от потребностей команды/проекта, тем более, если на проекте есть архитектор.
Моё пожелание относительно текста статьи - хотелось бы чуть более подробного описания про синхронные и асинхронные взаимодействия, чтобы четко понимать плюсы и минусы каждого и применимость в зависимости от ситуации. Предлагаю на парочке кейсов это рассмотреть.
Спасибо за конструктивный совет!
Дополнил статью в соответствии с вашими предложениями.
Год работаю в компании, но только после вашей статьи понял, связь между кластерами, почему kafka и зачем микросервисы (если кратко).
Спасибо, жду продолжения.
Просто изумительная статья и визуализация! Спасибо большое автору! Единственное, что смутило: сложность возрастала изначально плавно, а к концу статьи понеслась по экспоненте.
Спасибо за статью, интересно было почитать. 1.5 года работаю SA, почти со всем перечисленным сталкиваюсь.
Кстати, заметил в разделе "Формат обмена данными. JSON" в примере на картинке указано, что "age": "3" // <-- число, но в данном случае вы "3" передаете строкой.
Являясь мидл+ системным аналитиком могу сказать, что статья огонь
Спасибо автору за вклад в развитие
Системный аналитик. Краткий гайд по профессии. Часть 1. Основы взаимодействия систем