Двухфазный коммит (2PC, Two-Phase Commit)

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

Однако, у нас это не было предусмотрено, потому что изначально мы делали распределенную систему, в которой эти объекты не должны были зависеть друг от друга - но что-то пошло не так, как это часто бывает =)

Поэтому пришлось в спешке придумывать различные варианты решения данной проблемы, пока на проде не столкнулись с последствиями. Выбор был между SAGA-паттерном, оркестрацией или хореографией (об это я где-то давно рассказывал в канале) и двухфазным коммитом. Выбрали последнее, т.к. посчитали это более надежным решением, потому что SAGA-паттерн подразумевает следующее:
Мастер-система отправила событие в два топика подсистем о необходимости сохранить данные;
Одна из подсистем ответила успехом и отправила уже свои события своим потребителям, а вторая ответила ошибкой;
Мастер-система это обработала и отправила компенсационное сообщение в подсистему, которая ответила успехом;
Подсистема обработала, удалила\откатила изменения и отправила сообщение об откате транзакции своим потребителям.
И проблема подхода в нашем случае в том, что т.к. у нас безумная нагрузка и большое количество сообщений, то между 2 и 4 пунктом может пройти достаточное количество времени и всё это время у потребителей будет некорректная информация.

Поэтому от такого подхода отказались и пришли к 2PC.

Если упрощенно, то он работает следующим образом:
Мастер-система отправляет сначала события в подсистемы, начиная распределенную транзакцию. Подсистемы вычитывают эти сообщения, проверяют все бизнесовые валидации\штуки, которые должны проверить, но пока не публикуют результаты своих действий, держа эти события "в уме" (а по факту в отдельных табличках, в которых эти объекты хранятся до следующего шага);
Начинается Фаза Голосования: мастер-система отправляет команду-опрос, спрашивая: "Ребята, готовы ли вы окончательно закоммититься под этими сообщениям? Выполните все необходимые проверки\действия, чтобы в этом убедиться";
Мастер-система собирает ответы подсистем и приступает к Фазе Решения:
Если все участники ответили "Да", то мастер-система сохраняет к себе эти ответы (на случая какого-то сбоя, чтобы потом эту транзакцию можно было восстановить) и отправляет команду commit подсистемам;
Подсистемы окончательно переносят данные из временных хранилищ в основные таблицы и публикуют эти события, отправляя их своим потребителям. Также отвечают мастер-системе успехом, что данные закоммичены;
Если хотя бы один участник ответил "Нет", то мастер-система сохраняет к себе эти ответы и отправляет команду rollback тем подсистемам, которые ответили "Да".
Подсистемы откатывают изменения, удаляют данные из временных хранилищ.

У этого подхода есть свои недостатки, потому что достаточно сильно усложняется логика и увеличивается время обработки каждой транзакции. Однако, т.к приоритет был именно на обязательном одновременном сохранении транзакции в двух подсистемах, то пришлось этим жертвовать.
Вообще было очень интересно с разработчиками\архитекторами брейнштормить эту задачу, было придумано множество супер-интересных решений, которые тоже могли бы подойти, но в силу их минусов пришлось от них отказаться.
Я изначально предложил именно SAGA-паттерн, но потом посчитали нагрузку, потенциальные проблемы с неконсистентными данными у потребителей и продолжили штормовать эту тему, пока не пришли к единому варианту.

Приходилось ли вам на практике использовать какие-нибудь из перечисленных выше паттернов?

Рост внутри компании vs рост через рынок. Продолжение

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

Как происходит в нормальном случае:

Ты понимаешь, что перерос текущий грейд и хочешь расти дальше. Ты идешь к своему руководителю (твой тимлид в команде, руководитель практики твоей профессии, HR, тут смотря как принято конкретно у вас, сути это не меняет), говоришь ему об этом и вы обсуждаете процесс повышения;
Руководитель собирает по тебе обратную связь;
Если она нормальная, то дальше назначается ассесмент (внутреннее собеседование). А если тебе еще и очень повезло, то в твоей компании есть матрица компетенций и ты точно знаешь, какие темы тебе нужно подтянуть, чтобы подготовиться к этому интервью. Например, если ты сейчас просто системный аналитик, а хочешь стать ведущим, то тебе нужно подтянуть такие-то темы (чем миддл отличается от сеньора на мой взгляд поговорим в следующий раз);
Проходит ассесмент и интервьюер дает по тебе письменную обратную связь, на основании которой руководителем делается вывод о том, готов ли ты к повышению прямо сейчас или нет. Если нет, то по тебе составляется ИПР (индивидуальный план работ), в рамках которого фиксируется список тем, которые тебе нужно подтянуть\список пробелов в конкретных вопросах, которые надо закрыть.
Ты готовишься, закрываешь этот ИПР и либо проводится повторный ассесмент (если было прям плохо всё на первом) или просто он формально закрывается и ты официально переходишь на следующую ступеньку, получая почет и уважение (и деньги, хотя и не всегда).

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

Сотрудник вообще не тянет на следующий грейд и не очень понятно как он прошел изначальное собеседование. Но так как это не полноценное внешнее собеседование, то тебе нужно не унизить (так вообще делать не надо), а дать ему развивающую обратную связь, причем такую, чтобы он и не уволился, и не оскорбился, и продолжил перформить и еще и развивался. В общем это не просто) ;
Сотрудник немного не дотягивает, но он реально старается, по нему суперская обратная связь и он реально хорош, просто где-то с чем-то не сталкивался. Тогда его и самому хочется дотянуть до следующей позиции и он этого заслуживает. В этом случае можно сделать формальный ИПР, он его закроет через какое-то время, когда подтянет знания и пройдет дальше;
Сотрудник вроде бы по всем параметрам дотягивает, но сейчас у компании нет возможности (бюджета) для его повышения. И вот начинается хождение по лезвию, когда надо с этим что-то сделать. Ну сами догадайтесь что, не буду озвучивать;
Либо если все звезды сошлись, по человеку крутая обратная связь, бюджет есть, ассесмент прошел круто - вуаля, ты пишешь хорошую обратную связь и все получается.

Так что можно сделать несколько выводов:
— Важно попасть в нужное время, которое вообще от тебя и твоих желаний не зависит;
— Важно (очень важно) получить хорошую обратную связь, а для этого должны быть хорошие отношения с лидом и командой. Но, в общем-то, у СА должны быть хорошие софт скиллы, поэтому это не должно быть проблемой;
— Важно хорошо подготовиться к интервью и произвести хорошее впечатление, подкрепляющую ОС от команды, как человека и профессионала.

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

А как вы в последнее время повышались? Изнутри или через рынок?

Рост внутри компании vs рост через рынок. Предыстория

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

Но из-за этого родилась тема этого поста, потому что она, как минимум, актуальна для очень многих сейчас. Вообще, если сделать два шага назад - то могу сказать, что я очень рад тому, что заходил в IT уже почти 10 лет назад, когда о позиции СА\БА даже в айтишке особо не знали и не выделяли ее отдельно почти нигде. Да и в плане зарплат, стажа работы\опыта и роста в целом - не было такого бума, как сейчас, и вообще представления о том, что такое возможно.

И я напомню для тех, кто не застал старые-добрые времена или предпочел забыть их как страшный сон - как происходил рост тебя, как специалиста, и твоей зарплаты. Тебе сначала надо было что-то сделать СВЕРХ того, что ты уже делаешь как сотрудник, доказать свою полезность и только потом (возможно) тебе давали повышение.
Я как сейчас помню, что когда я отработал год в компании на позиции СА и пришел к руководству с запросом на повышение - меня спросили: "А что ты сделал для этого?". Я ответил что: "мук-пук, ну я же работаю уже год, работаю хорошо, выполняю свои функции и так далее". На что руководство мне, вполне логично, на мой взгляд, ответило: "Ну так мы и платим тебе зарплату за то, что ты уже делаешь и спасибо, конечно, что делаешь это хорошо. Но если хочешь повышения, то ты должен сделать что-то еще".

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

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

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

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

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

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

to be continued...

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

Как вы думаете, на каком этапе разработки фичи по отправке смс-уведомления должны были заметить такое поведение системы и исправить его? И как вы думаете, почему это могло случится, с точки зрения аналитики или разработки фичи?

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

Но всегда возможен вариант с ошибкой при проработке ТЗ - возможно, неправильно указан источник для получения данных. Например, поле в БД называется не license_plate, а как-то по-другому. Тут, конечно, разработчик в любом случае должен был бы это провалидировать, но это всегда происходит, как мы знаем)

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

Но, в конечном итоге это в любом случае должны были отловить на этапе тестирования, потому что это даже не какой-то хитрый корнер-кейс, а вполне обычный прямой кейс той US, которую ребята реализовывали.
Поэтому я вполне понимаю те процессы, когда команда разработки сильно перестраховывается, и разработчик полностью покрывает автотестами свой код и (возможно), после разработки локально тыкает свой код. И СА проводит приемочное тестирование фичи, в рамках которого крупными мазками проверяет то, что функционал реализован в духе и здравом смысле написанного ТЗ и после этого еще тестирование проверяет фичу до мелочей и всех корнер-кейсов. Хоть это и сильно сжирает ресурсы команды.

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

Встречались ли вы с подобными ситуациями, в роли пользователя какого-либо продукта или системы?

OpenAPI

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

Получилось душевно, с интересными вопросами, в том числе из разряда "А это вообще реально применить у нас и договориться с разработчиками об использовании такого подхода?" Что, кстати, является весьма важным поинтом, потому что без их участия это все бессмысленно - особенно если они будут игнорировать описанные контракты и делать отсебятину, без оповещения аналитика об изменениях. Но на этот вопрос у меня не было ответа)

Планирую провести на эту тему воркшоп в следующем месяце. Когда подготовлю кейсы и буду готов - сделаю дополнительный анонс.

Я уже рассказывал про Swagger\OpenAPI вот в этом посте. Сейчас хочу более подробно раскрыть те блоки, из которых состоит контракт, описанный в спецификации OpenAPI, и что в них нужно указывать.

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

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

Список корневых элементов контракта:

➖openapi: 3.0.0
Это обязательный атрибут спецификации, без которого она не будет считаться валидной. Тут указывается именно версия спецификации, не контракта вашего сервиса.

➖info:
Этот блок также является обязательным. В нем мы задаем наименование нашего сервиса, его версию, описание и различную контактную информацию (например, какая команда им владеет, чтобы можно было понять, к кому обращаться с вопросами).

➖externalDocs:
В этом блоке можем дать различные ссылки на документацию сервиса, например на описание его логики работы в конфлюенсе.

➖servers:
Тут мы можем указать массив ссылок на сервера, на которых крутится описываемый сервис. Например его хосты с прода и теста.

➖tags:
В этом блоке мы можем задать массив тэгов, которые потом сможем присваивать нашим endpoint'ам. Тэги — это просто визуальная группировка наших методов по бизнес-юниту, по какому-то техническому признаку или вашему хотению. Например, если ваш микросервис работает с заявкой на кредит, то вы можете выделить тэги LoanApplication, ApplicationOffers, ApplicationStatus, ApplicationScore и т.д. И каждому методу, который вы будете далее описывать присвоить один или несколько из этих тэгов.

➖components:
Это очень важный блок, в котором вы описываете модель данных, с которой работают ваши методы. Это необходимо для того, чтобы в рамках контракта один раз задать какие-либо сущности и потом просто ссылаться на них, вместо того, чтобы объявлять в рамках каждого метода одни и те же объекты. Например, у вас есть метод, который возвращает список заявок и метод, который возвращает одну конкретную. Модель данных у них будет почти одинаковая, кроме того, что в первом случае будет массив заявок. И вот вместо того, чтобы в двух местах описывать все сотни атрибутов, которыми обладает заявка - мы делаем это один раз и потом ссылаемся на эти сущности.

➖paths:
Самый важный и тоже обязательный блок. Именно в рамках него мы описываем все имеющиеся endpoint'ы и все их методы. Как это сделать - расскажу в следующем посте.

Итого: для проектирования контракта нужно минимально иметь блок openapi, info и paths. Остальные опциональные (но очень желательно их тоже описывать).

Postman и его практическое применение

Postman — один из основных инструментов тестировщиков, который позволяет тестировать API.

Вообще этот сервис предоставляет больше функций, чем просто тестирование — это еще и создание, публикация, документирование API, но в основном он используется именно для тестирования, т.к. позволяет "дергать" ручки ваших сервисов.

Как он работает?

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

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

Но я предлагаю воспользоваться API, которые уже есть в свободном доступе, например, с помощью ресурса DaData. Этот сервис предоставляет тонну апишек, которые можно подергать бесплатно, для этого достаточно просто зарегистрироваться (это необходимо, чтобы вам присвоили secret key и token без которого вы будете получать 401 ошибку).

После регистрации выбираете любую понравившуюся вам ручку для использования (можно хоть все). Пусть будет ручка стандартизации адресов (которой, кстати, пользуются много компаний, как и вообще DaDat'ой в целом). Тут вы можете почитать спецификацию этой ручки, посмотреть с каким request\response она работает, посмотреть корнер-кейсы и в целом варианты использования. Спецификация специфичная (сорри за тавтологию), но это один из вариантов того, как можно их писать — и, в целом, по ней все понятно.

После этого вам нужно скопировать cURL этой ручки и вставить ее в вашу коллекцию в Postman через кнопку Import. После вставки Postman сразу "кушает" cURL и преобразует его в понятный вид, подставляя в заголовки ваш токен и ключ, а в тело сообщения дефолтный пример, предложенный самой DaData. Собсна, вы можете сразу нажать на кнопку Send и отправить запрос с дефолтными параметрами, которое было зашито в cURL, и посмотреть какой результат вам вернется.

После этого, я обычно рекомендую своим ученикам, поиграться с Headers и Body, редактируя их по своему усмотрению. Например, выключая передачу токенов, передавая пустое тело (или нулловое), передавая массив строк в теле и так далее. И смотреть как ответы меняются в зависимости от того, что вы передали.

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

P.S. Приходилось ли вам использовать Postman не просто в образовательных целях, но и вполне в рабочих? Для тестирования, например?

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

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

О чем она?

Модель зрелости REST API - концепция, которая оценивает API по нескольким параметрам и определяет, насколько этот интерфейс соответствует принципам REST. Т.е. является ли ваш сервис простым RPC или он уже эволюционировал в полноценный REST. Чем выше "уровень" вашего сервиса, тем лучше (по мнению Ричардсона) он спроектирован.

Уровни зрелости модели

Уровень 0: API как RPC

Сервис имеет единственный URI, который использует единственный HTTP-метод (в основном POST). Т.е. API является точкой входа, которая принимает параметры и возвращает результат.По сути используется просто как обертка для вызова удаленных процедур (т.е. стандартный RPC), не используя RESTful принципы вообще.

Например: POST /api, в теле которого передается {"action": "deleteOrder", "data": {id: "123", ...}}.
Как видим из примера, запрос обрабатывается не как операция с ресурсом (как мы привыкли), а как действие.

Уровень 1: Resources

Сервис на этом уровне имеет несколько URI, каждый из которых использует только один HTTP метод. Разница между нулевым и первым уровне заключается в том, что на первом уровне сервис выставляет множество логических ресурсов, а на нулевом уровне сервис объединяет все взаимодействия через единственный (и намного более сложный) ресурс.

Кроме этого, в сервисах этого уровня имена операций, параметров и даже действий зашиты в сам URI.

Например: POST /deleteOrder. Или POST /getOrders.

Уровень 2: HTTP-verbs

Сервис на этом уровне имеет много URI-адресуемых ресурсов и использует несколько HTTP-методов для каждого из них. Тут мы начинаем работать с концепцией CRUD, т.е. с управлением состояния ресурса (бизнес-сущности) через отдельные ручки.

То есть тут уже используется все многообразие методов (GET, POST, PUT, PATCH, DELETE), используем корректные коды ответа (200, 201, 404 и т.д.).

Например:

GET /orders/123
DELETE /orders/123

Уровень 3: HATEOAS

Самый высокий уровень зрелости в рамка этой модели.

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

По-другому это называется HATEOAS (Hypermedia as the Engine of Application State) — характеристика веб-сервиса возвращать действия, которые могут быть выполнены с ресурсом, в виде URL

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

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

{

  "orders": [

    {

      "id": 1,

      "goodsName": "Table",

      "status": "PAID",

      "_links": {

        "self": "/orders/1",

        "update": "/orders/1/update",

        "delete": "/orders/1/delete"

      }

    },

    ...

self — ссылка на текущий ресурс;
update — ссылка на ресурс обновления заказа;
delete — ссылка на ресурс удаления заказа.

P.S. А у вас сервисы какого уровня? Оценивали ли вы их?
Лично я на своей практики ни разу, кажется, на видел сервисов выше 2 уровня. Зачастую, это может быть излишне и в большинстве случаев просто нет такой необходимости. Но если кто-то сталкивался с таким - расскажите про свой опыт, пожалуйста.

Про отпуск и отдых в целом

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

Но не об этом, на самом деле хотел поделиться одной мыслью - оказывается можно просто уйти в отпуск, ничего не планировать и отдыхать. Ужс, да? Лично для меня - да.

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

И так выдалось, что всю позапрошлую неделю я был в отпуске и у меня не было абсолютно никаких планов ��. Когда наступил понедельник я даже растерялся и начал по привычке читать все рабочие чаты, продумывать как я буду решать после отпуска свои рабочие задачи - в общем абсолютно не мог замедлиться и переключиться с работы на отдых.
Забавное состояние на самом деле, поймал себя на нем и понял что это отдельный повод для рефлексии)

Но потом к середине недели я уже привык, абстрагировался от работы и начал спокойно проходить FF XVI и вторую Готику, еще больше читать и ходить на тренировки. О работе напоминал только голос жены, которая постоянно вела свои консультации из своего кабинета (вот он - минус работы на себя).

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

В качестве заключения могу сказать, что для себя понял - насколько важно просто ничего не делать (хотя бы иногда), отключать мозг совсем или переключать его с рабочих и достигаторских задач на какие-то нейтральные.
Раньше еще я был большим любителем в принципе не ходить в отпуск и после увольнения с работы у меня было по 40+ неистраченных отпускных дней. Сейчас я уже слишком стар для этого и так не могу, хотя вижу по коллегам, что они до сих пор продолжают так делать (а потом выгорают и увольняются).

P.S. А как вы ходите в отпуск? Или тоже "храните" деньги в отпускных днях?

Сообщество аналитиков на Пикабу

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

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

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

Ироничное про людей

Вчера написал пост на Пикабу, который уже вам писал чуть ранее, про пример практической задачи на собеседовании. И я там привык к стандартной токсичности какой-то (пожалуй, не маленькой) и комментариям:

➖ "А что, тебя на хабре уже забанили, да?" (Это раньше был топ-1 комментарий, который появлялся почти под каждым моим постом);
➖ "А нафига ты сюда это пишешь? Пикабу это развлекательный ресурс, нам эта "твая тиория" не нужна тут";
➖ Комментарии с недовольством того, что я ссылку на ТГ-канал вставляю в свои посты (но это ладно, это я не осуждаю, очевидно что 70% постов на Пикабу пишутся только для того, чтобы привлечь кого-то куда-то, поэтому это всех достало);
➖"шитпост! автор убейся" (эх, а я еще помню времена когда всего лишь вежливо просили автора выпить яду);

И много чего еще, достаточно стандартного, того к чему авторы уже давно привыкли. Но были и забавные комментарии, мемы и так далее, формата: "Как пропатчить KDE2 под FreeBSD?" — это все одобряем.

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

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

К чему я все это пишу. В комментарии ко вчерашнему посту, почти что спустя наносекунду после его размещения, ворвался, видимо, "Рыцарь Свежего" и призвал модератора удалить мой пост на основании того.. Ну, вы готовы, да? (голосом Задорнова).. что я жирным выделяю и явно рекламирую сайт. Это он про дневник.ру, если что.
Такого со мной еще не было, но на тот момент я, с одной стороны, выпал в осадок, с другой прям очень пожалел, что министерство образования РФ не знает об этом и не доплачивает мне за каждый собес, на котором я упоминаю этот сайт. И за эти посты тоже, к сожалению(

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

И сколько раз такое бывало, что происходит разбор какого-то бага и тебе разработчик или тестер говорит: "Ну вот в требованиях написано вот так, а оно работает не так\я реализовал по требованиям". И ты прям на созвоне вслух зачитываешь требование, которые ты написал и человек такой: "А, ну да.. Чет вообще не так понял, пойду править".

Ну и не буду строить из себя непогрешимого, это вполне работает и в обратную сторону. Когда ты читаешь какое-нибудь БТ, читаешь через одно место, пишешь ТЗ соответственно неправильно и потом к тебе точно также приходят и тыкают носом. Бывает всякое, я без осуждения)

P.S. А что вы думаете об этом всем? Сталкиваетесь ли в своей работе с такой разницей восприятия на, казалось бы, очевидные вещи?

↕️
Теперь к сути, что конкретно по применяемым технологиям я еще хочу услышать. Желательно, чтобы было предложено несколько вариантов решения, как синхронных, так и асинхронных.

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

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

Можно предложить реализовать какую-то джобу или на стороне биометрии или на стороне дневника, которая раз в N времени (хоть каждую секунду, хоть раз в сутки ночью) ходит в тот или другой сервис и забирает или отдает данные за минуту\час\день.

Можно подумать на тему гарантированной доставки данных и прийти к брокерам. Реализовать по триггеру отправку данных в исходящий топик сервиса биометрии и вычитывать его в сервисе дневника, сохраняя данные к себе. Можно порассуждать на тему, какой именно брокер тут лучше подойдет и почему (например, лучше выбрать кролика, потому что объемы данных тут не большие, даже пиковая нагрузка слабенькая и он к тому же опенсорсный - поэтому как будто бы большая kafka тут и не нужна). Можно сюда с жиру докрутить еще transactional outbox pattern на стороне биометрии, вдобавок к кролику - чтобы прям точно данные не потерялись, ну прям никак.

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

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

P.S. Как вам такой формат, если мы периодически будем разбирать какие-то интересные задачки с собесов? Судя по количеству комментариев и реакций - вполне зашло, но если дадите еще обратной связи, я буду только рад.

Ответ на практическую задачу

Для начала - спасибо всем, кто писал свои ответы, я это ценю. Под последними постами получались хорошие дискуссии и это не может меня не радовать как автора.

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

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

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

Лайк за то, что подумали про экономию денег для школы и выбор более дешевого варианта. Например, выбор RabbitMQ вместо kafka. Это не наша прямая обязанность, но проектировать решения с учетом бюджета заказчика - хороший скилл.

Лайк за то, что превентивно думает про требования к безопасности и о том, что безопасники (хотя в условном примере и в условной школе их может и не быть вовсе) могу "забрить" ваше решение. Видимо кто-то много обжигался на этом)

Лайк за проработку корнер-кейсов формата: "А что будет, если ученик забыл палец дома и он пройдет по биометрии другого человека? Как нам обрабатывать эту ситуацию". "А что будет, если он приложит палец, но не пройдет через турникет и убежит?". Отсюда родились, я считаю, вообще гениальные подробности на тему того, что турникеты имеют такую систему, что если его разблокировали, но при этом не прошли - то он удаляет запись о проходе (или что-то в этом духе).

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

Сорри за оффтоп и очередное напоминание.

Пост получается слишком длинным и не влезает в формат телеги, поэтому мои предложенные решения в следующем.
↕️

Пример практической задачи на интервью

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

Представим такой случай - вы СА на проекте "Школа" (обычная общеобразовательная). У школы есть сайт, что-то вроде дневник.ру, на котором можно посмотреть различные табели, оценки в разрезе классов, информацию об учителях, учениках - в общем что угодно. И директор, который является вашим заказчиком, заказал установку системы биометрического отслеживания прихода\ухода учеников. Условно говоря это сканеры отпечатков пальцев на турникетах у входа в школу, которые записывают время прихода\ухода учеников или учителей, в момент когда они прикладывают палец к сканеру. Эти данные хранятся в системе биометрии.

Суть задачи: директор очень хочет видеть табель прихода\ухода учеников и учителей на своем аналоге дневника.ру.
Для упрощения - вы владеете обеими системами и можете дорабатывать их как хотите, идентификаторы людей в дневнике и биометрии идентичны. На данный момент никакой интеграции между ними нет и системы не знают друг о друге. Соответственно у дневника.ру есть свой фронт и бэк, у системы биометрии есть только свой бэк и вот их надо подружить друг с другом таким образом, чтобы данные из биометрии каким-то чудом оказывались у директора "на столе" на его фронте.

Какой способ интеграции вы выберите, почему именно такой и как вы его реализуете?

Непосредственно на интервью я даю пару минут на подумать, позадавать вопросы мне, как к заказчику и после этого готов слушать ответ.

Давайте подискутируем в комментариях - как бы вы отвечали на такой вопрос на собеседовании, интересно послушать ваши варианты. Я с удовольствием отвечу на ваши вопросы или прокомментирую ответы.

Mock Interview

Только что проводил очередное мок-интервью и по горячим следам могу выделить следующие преимущества работы в таком формате:

Самый большой бонус в том, что можно отработать свои нервы, переживания, стресс в комфортной и неформальной обстановке, понимая при этом, что если ты сейчас ошибешься в ответе на вопрос, то не лишишься "последнего" шанса устроится на работу мечты;

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

Своеобразный подпункт о таймингах. Это очень важно (!). Не просто так я упомянул про 5-7 минут самопрезентации, потому что это идеальное время, в которое очень желательно уложить рассказ о себе. Никто не хочет слушать дополнительные 5 минут про не интересный и не актуальный опыт (относительно той позиции, на которую вы претендуете) десятилетней давности. Поэтому важно подсобрать весь ваш опыт и научиться его презентовать в короткие сроки;

В процессе интервью определяем слабые места и нехватку теории\практики в определенных темах, чтобы закрыть их к "реальному" собеседованию;

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

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

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

P.S. Был ли у вас опыт "прохождения" мок-интервью? Понравилось ли вам или было ли это полезно?

ТЗ. Норм или стрём?

В прошлом посте я, на свою голову, упомянул про ТЗ, которое написал в рамках обучения мой ученик и это привело к большому количеству вопросов формата: "А что это было за ТЗ такое волшебное, дай посмотреть". Чему я, на самом деле, удивлен. Кому-то, кстати, я наверняка забыл скинуть из просивших - прастите.

Но вообще меня это натолкнуло на написание этого поста и породило вопрос - а как вы оцениваете чьи-то ТЗ? Или своё, например? Какие у вас в голове есть критерии "приемки" своего ТЗ, перед тем как вы его покажете на-гора команде? Напишите в комментариях, очень интересно обсудить это.

Со своей стороны скажу, что я уже не задумываюсь об этом, я просто пишу на автомате текст, стираю, снова пишу и повторяю так пока не получится определенный набор структурированных (или не очень ��) требований\описаний контрактов\whatever.

А вот когда провожу ревью чужих ТЗ, то обращаю внимание на следующие критерии:
➖Орфография (это не важно на самом деле, но я прям стал grammar nazi после перехода в СА. Профдеформация, чтоб ее);
➖Логичность написанного;
➖Непротиворечивость самому себе\бизнес-требования\логике системы в целом. Это частая проблема СА, что хочется сделать красиво и правильно, но твое решение, допустим, начинает противоречить текущей архитектуре системы (какой бы она не была). Или упускаешь какой-то кусок бизнес-требований, что бывает;
Понятность написанного. Очень частая боль требований в том - что они могут казаться автору понятными и логичными, но при прочтении их со стороны просто ломается мозг в попытке разобраться о чем вообще речь.

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

Делитесь своими мыслями на эту тему в комментариях.

Я прошел собес на СА, но ничего не понимаю - памагите �� (с)

Сегодня хочу поделиться несколькими историями из моей менторской практики, которые сводятся примерно к одному: "Я устроился на работу системным аналитиком, но практических знаний нет, а дедлайны по рабочим задачам уже горят прям сейчас. Сможешь помочь?".

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

Один человек перешел из поддержки в СА в достаточно небольшую компанию, где почти не было понимания кто такие СА, поэтому получилось пройти собес;
Один человек переквалифицировался из "бизнесовой" (не IT) позиции, в СА внутри компании;
Еще один, будучи начинающим БА, резко взял на себя задачи еще и СА после его увольнения и ему пришлось в очень большой спешке доучиваться на ходу;
И еще один тоже пришел извне рынке в одну IT-компанию каким-то образом и тоже нужно было как-то выполнять свои задачи, без, почти что, минимального понимания.

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

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

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

К слову сказать, это был мой первый опыт работы с человеком, который развивается в СА именно с бизнесовой позиции той же отрасли, и я был просто в восторге. Менти работал в сфере, связанной с аэропортами и обслуживанием воздушных судов. И я до сих пор, даже спустя эти три года, предлагаю его ТЗ, разработанное в рамках обучения, в качестве примера для своих текущих менти, потому что это техническое задание на "Контроль наземного обслуживания воздушных судов" написано настолько мощно с точки зрения требований, что не все миддловые+ БА могли бы это повторить.

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

Были ли у вас такие случаи, что вы устроились на работу и потом в очень напряженном темпе приходилось осваивать какие-то новые навыки?

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

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

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

Поделитесь своими переживаниями\кейсами\информацией в комментариях - пообщаемся. А я поделюсь своим мнением и информацией, собранной из разных (неофициальных) источников.

Примеры тестовых заданий для джунов

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

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

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

Поэтому буду благодарен тем, кто откликнется ��.

Модель OSI (Open System Interconnection), часть 2

Продолжаем разговаривать про уровни модели OSI.

3 уровень OSI - Сетевой уровень (Network Layer)

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

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

4 уровень OSI - Транспортный уровень (Transport Layer)

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

Т.к. передача данных происходит по сети, то используются, как правило, два главных протокола TCP и UDP (о них еще поговорим).

⃣ 5 уровень OSI - Сеансовый уровень (Session Layer)

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

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

⃣ 6 уровень OSI - Уровень представления данных (presentation layer)

Уровень отвечает за преобразование данных в формат, подходящий для приложения или сети. Сюда же включаются задачи по шифрованию\дешифрованию, сжатию и преобразованию данных.

Например, полученные данные могут превратиться в GIF или MP4 формат. Или в обратном порядке, если пользователь отправляет файл другому человеку - в этом случае данные сначала конвертируются в биты и сжимаются, а потом уже передаются на транспортный уровень.

⃣ 7 уровень OSI - Прикладной (application layer)

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

Прикладной уровень похож на некий графический интерфейс для всей модели OSI - с его помощью пользователь взаимодействует с другими уровнями, причем даже не подозревая об этом. Этот интерфейс называется сетевым. Самые популярные из сетевых интерфейсов - это HTTP, HTTPS, FTP, SMTP.

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

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

Модель OSI (Open System Interconnection), часть 1

Сегодня мы опустимся на несколько уровней ниже классического системного анализа и рассмотрим модель OSI. Это эталонная модель взаимодействия открытых систем, которая описывает, как устройства в локальных и глобальных сетях обмениваются данными и что с этими самыми данными происходит. Ее предложили в 1984 году инженеры из Международной организации по стандартизации (небезызвестной нам ISO), которая в то время работала над единым стандартом передачи данных по интернету.

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

Так вот, сама по себе эталонная модель - это не стандарт интернета, как TCP/IP, скорее в рамках эдакой "коробки" OSI доступны различные веб-стандарты, такие как UDP, HTTP, FTP и другие (всего порядка сотни штук).
И наша модель разделяет процесс сетевого взаимодействия на семь взаимосвязанных слоев (уровней), каждый из которых выполняет свою четко определенную функцию и взаимодействует с уровнями, которые выше и ниже. Если упростить, то эти уровни работают с одними и теми же данными, но по-разному. Например, кабели передают информацию в виде нулей и единиц (самый нижний уровень), а сетевое оборудование (3 уровень) использует эти данные, чтобы передать их в другую точку страны или мира, чтобы компьютер конечного пользователя мог их получить и преобразовать в понятный для человека вид.

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

⃣1 уровень OSI - физический (physical layer)

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

Самый известный протокол на физическом уровне это Ethernet. Он описывает, как сигналы кодируются и передаются по проводам. Кроме этого есть Bluetooth, WI-FI, давно забытые ИК-порты, которые также содержат инструкции для передачи данных.

⃣ 2 уровень OSI - канальный (data link layer)

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

Если немного упростить, то на канальном уровне происходит передача информации в рамках одной локальной подсети.

P.S. О следующих уровнях поговорим во второй части. А пока поделитесь - задавали ли вам вопросы на собеседованиях на эту тему или вас эта участь обходила стороной?)