Системный Аналитик

Высоконагруженные приложения. Программирование, масштабирование, поддержка

✍️ Автор: Мартин Клеппман
🗓 Год издания: 2018
🔤 Язык: русский
📚 Объём: 640 стр.

Книга поможет расширить кругозор по проектированию систем. Рекомендуется системным аналитикам уровня middle и выше.

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

#архитектура #проектирование

Версионирование REST API

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

⚙️ Как это работает

1️⃣ Под номером версии фиксируется существующий контракт API, который используется потребителями

2️⃣ Если возникла необходимость внести изменения в существующий контракт, заводится отдельная ветка под дорабатываемый метод

3️⃣ Изменения публикуются в новой версии метода API, при этом старая версия остаётся рабочей до тех пор, пока у неё есть потребители

4️⃣ Потребители сами решают, в какой момент они будут готовы перейти на новую версию того или иного метода


✍️ Пример

Допустим, есть метод который позволяет опубликовать статью в блоге: POST /v1/articles
Метод принимает на вход в теле запроса следующие параметры, которые являются обязательными:

{
  "text": "string",
  "author": "string",
  "title": "string"
}

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

Поэтому создаём новую версию метода POST /v2/articles и все изменения реализуем там:

{
  "text": "string",
  "author": "string",
  "title": "string",
  "category": "string"
}

При этом старая версия метода (POST /v1/articles) продолжает работать.


Способы версионирования API

💫 Префикс URI
Пример: GET /v1/users
✔️ Способ простой в проектировании, реализации и документировании
✖️ Создает большое количество дубликатов URL и может снизить производительность приложения

💫 Параметр запроса
Пример: GET /users?version=v1
✔️ Способ рекомендуется, если важно HTTP-кеширование для повышения пропускной способности
✖️ Приводит к загрязнению URI, так как префиксы и суффиксы добавляются к основным строкам URI

💫 HTTP заголовок запроса
Пример: GET /users, а версию передаём в headers: version=v1
✔️ Не приводит к загрязнению URI, легко реализовать
✖️ Приводит к неправильному использованию заголовков, т.к они нужны для метаинформации

💫 Feature-версионирование
У клиента API есть набор фич. При отправке запроса, сервер проверяет его набор фич и на этой основе сам определяет нужную версию для каждого клиента
✔️ Можно использовать в качестве внутреннего API
✖️ Со временем фичи могут вступить в конфликт, если отвечают за одну и ту же часть бизнес-логики


⭐️ Подборка материалов доступна в базе знаний по системному анализу

#api

Принцип пирамиды Минто. Золотые правила мышления, делового письма и устных выступлений

✍️ Автор: Барбара Минто
🗓 Год издания: 2004
🔤 Язык: русский
📚 Объём: 189 стр.

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

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

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

#навыки

OAuth 2.0 и OpenID Connect

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

👤 OpenID Connect — протокол аутентификации, который позволяет безопасно узнать сведения о пользователе, от имени которого совершается вход. OpenID Connect позволяет реализовывать сценарии, когда единственный логин можно использовать во множестве приложений, — этот подход также известен как single sign-on (SSO).

В чём отличие между OAuth 2.0 и OpenID Connect

Вся разница сводится к различию процессов аутентификации и авторизации.

Простыми словами:

💩Аутентификация — это когда мы проверяем, кто именно запрашивает доступ и является ли он тем, кем он себя представляет.

💩Авторизация — это когда мы проверяем, имеет ли конкретный клиент доступ к запрашиваемой информации.

OAuth 2.0 используется для авторизации, а OpenID Connect для аутентификации. А ещё OpenID Connect делает возможным использование SSO.

Токены

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

💩id_token — содержит информацию о клиенте, он выдается провайдером идентификации (IdP) в ответ на успешную аутентификацию пользователя. Может содержать, например, id пользователя, фамилию, имя, телефон и т.д.
💩access_token — это токен доступа, который используется для совершения действий от имени пользователя. Может быть ограничен скоупом — перечислением прав, которые может делать приложение с этим токеном от имени клиента. access_token имеет короткий срок жизни в целях безопасности.
💩refresh_token — это токен, который используется для получения нового access_token, когда старый истекает или отзывается. Имеет более длительный срок.

Все эти токены можно генерировать по-разному, но самый популярный формат — это JSON Web Token (JWT).

Структура JWT
💫Заголовок (header) — состоит из типа токена и алгоритма хэширования подписи
💫Полезная нагрузка (payload) — любые данные, которые вы хотите передать в токене. Payload не шифруется при использовании токена, поэтому не стоит передавать в нем чувствительные данные. Например, паспортные данные.
💫Подпись (signature) — заголовок и нагрузка формируются отдельно в формате JSON, кодируются в base64, а затем на их основе вычисляется подпись, которая также становится частью токена.

🔀 Процесс на примере использования VK API

1. Приложение генерирует параметры запроса и отправляет пользователя на сервер авторизации oauth.vk.com, добавив к ссылке параметры, включая запрашиваемый scope, например, friends
2. Пользователю открывается окно, где он проходит аутентификацию — вводит логин и пароль
3. После входа открывается окно с запросом прав доступа. Пользователь нажимает на кнопку "Разрешить". Тем самым он авторизует приложение на выполнение действий от его имени с запрашиваемым scope.
4. Сервер авторизации генерирует access_token и refresh_token и возвращает их приложению
5. Теперь приложение может управлять списком друзей пользователя

⭐️ Подборка материалов доступна в базе знаний по системному анализу

#архитектура #проектирование

Системный Аналитик pinned «Больше подборок в закрытом канале Ещё больше полезных материалов по системному анализу можно получать в закрытом канале, который доступен по подписке. Что входит в подписку: ➖2-3 подборки материалов каждую неделю в закрытом канале ➖навигация по всем материалам…»

Основы технологий баз данных: учебное пособие

✍️ Автор: Новиков Б. А. / Б. А. Новиков, Е. А. Горшкова, Н. Г. Графеева; под ред. Е. В. Рогова.
🗓 Год издания: 2020
🔤 Язык: русский
📚 Объём: 583 стр.

Материал первой части учебного пособия составляет основу для базового курса и содержит краткий обзор требований и критериев оценки СУБД и баз данных, теоретическую реляционную модель данных, основные конструкции языка запросов SQL, организацию доступа к базе данных PostgreSQL, вопросы проектирования приложений и основные расширения, доступные в системе PostgreSQL.

Вторая часть, добавленная в настоящем издании, содержит материал, который будет полезен разработчикам баз данных и СУБД. В ней подробно рассматриваются структуры хранения, методы выполнения и оптимизации запросов, дополнительные возможности языка SQL, средства поддержки согласованности и надежности. Рассмотрены средства программирования серверов баз данных, средства расширения функциональности PostgreSQL, вопросы создания систем с репликацией, параллельных и распределенных систем баз данных.

#бд

Больше подборок в закрытом канале

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

Что входит в подписку:
➖2-3 подборки материалов каждую неделю в закрытом канале
➖навигация по всем материалам
➖коммьюнити подписчиков — обмен опытом и общение
➖доступ к каналу с тестовыми заданиями из собеседований
➖тесты для самопроверки
➖(скоро) обновляемая база знаний по ключевым темам системного анализа
➖(скоро) исчерпывающая интерактивная карта навыков системного аналитика со ссылками на материалы из базы знаний

Тарифы:
💩350 ₽ — месяц
💩3400 ₽ — год (283 р/мес, экономия 20%)

Оформить подписку можно через кнопки ниже.

Шпаргалка по SQL

А для тех, кто готов изучать базы данных глубже — напоминаем о наших подборках:

▪️Основные понятия баз данных
▪️Подборка полезных материалов по основам баз данных
▪️SQL vs NoSQL: отличие реляционных и нереляционных БД
▪️Типы связей в БД. Нормализация
▪️Виды нереляционных БД. Какие бывают NoSQL базы данных
▪️Шпаргалка по выбору правильной СУБД
▪️Памятка по SQL

Kanban vs Scrum: сравнение методологий

Kanban и Scrum — методологии гибкого управления проектами, используемые для реализации принципов Agile и DevOps при разработке.

Kanban — подход к управлению процессом разработки, который включает следующие практики:

💩Визуализация задач и прогресса с помощью канбан-доски, установление приоритетов задачам
💩Ограничение количества задач со статусом "В работе", или WIP (work in progress). Если лимит превышен, то команда не может взять новую задачу в работу, пока не будет завершена одна из текущих
💩Управление потоком: отслеживание метрик, таких как скорость движения задач между статусами, для устранения «бутылочных горлышек», где процесс замедляется
💩Проведение каденций — встреч членов команды по процессу разработки. Всего выделяют 7 видов встреч. Главная цель — объяснение правил для всех участников команды и сбор обратной связи
💩Непрерывное улучшение процесса на основе обратной связи и анализа метрик

Что общего между Kanban и Scrum

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


✅ Когда лучше применять

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

Scrum:
💩 важен строгий контроль сроков и структура
💩 требуется четкое определение целей и результатов
💩 команда является кросс-функциональной
Пример: Разработка новой версии продукта с фиксированным релизным циклом, например, каждые 3 месяца.


❌ Когда не подойдет

Kanban
💩в проектах, где необходимо строго соблюдать сроки
💩в кросс-функциональных командах
💩когда требуется постоянная обратная связь от клиентов

Scrum
💩 продукт нужен целиком, итерации невозможны
💩 когда нет сплочённой, самоорганизованной и кросс-функциональной команды
💩 для слишком маленьких групп из 1–2 человек, или, наоборот, больших лучше заменить другими методами — SAFe, LeSS.


☯️ Гибрид ScrumBan

Используется в средах, где необходимо управление проектом в условиях неопределенности и частых изменений. ScrumBan легче внедрить, чем Scrum
💩от Scrum: сохраняет ключевые элементы Scrum: спринты, роли (Product Owner, Scrum Master, и команда разработки) и основные события (планирование, ревью, ретроспектива).
💩от Kanban: заимствует концепцию визуализации процесса на доске, ограничения рабочего объема, адаптацию к изменениям в реальном времени и фокус на поток задач.

⭐️ Подборка материалов доступна в базе знаний по системному анализу

#управление_проектами

📚 Ловите огромную подборку книг по гибким методологиям 🔥

Все книги можно бесплатно скачать в .pdf. Все ссылки ведут на наш второй канал "Библиотека Системного Аналитика"

1. Подборка книг по Agile
2. Подборка книг по Scrum
3. Подборка книг по Kanban

Одна из частых ошибок при проектировании API - это отождествление модели объектов API со схемой БД. Особенно ярко проявляется при работе с REST API, когда аналитик убежден, что каждый HTTP-ресурс - это таблица в БД.

Почему модель данных API может отличаться от модели БД?

1️⃣ Первичная задача при проектировании сущностей и связей в БД - это эффективное хранение данных, обеспечение производительности и стабильности сервис. Такая модель может быть неудобна для потребителей сервиса. Например, БД может иметь ненормализованную форму.

2️⃣ Сервис может использовать нереляционное хранилище. Например, MongoDB для хранения объектов в виде документов.

3️⃣ Сервис может использовать несколько БД для хранения данных. Возможно, из-за легаси. Или мы используем разные хранилища для разных типов данных

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

5️⃣ Жесткая связка модели API и схемы БД, потребует большего времени на доработки, если одна из них меняется.

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

Подписывайтесь на продолжение: @nextway_news

Тест-кейсы: как и зачем писать📝

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

Виды тест-кейсов:

✅ Позитивные (положительные). Проверяют, что система правильно реагирует на корректные данные
Пример: пользователь существует в системе и он может пройти авторизацию

❌ Негативные (отрицательные). Показывают, что система умеет работать с некорректными данными
Пример: пользователь при регистрации ввёл простой пароль 12345, а кнопка “Установить пароль” активной не стала, т.к ждёт более сложный

🚫 Деструктивные. Служат для проверки прочности системы
Пример: метод для получения заказов пользователя нельзя выполнить без авторизации


Особенности:
💩Идеально подходят для описания сложных проверок в системе и регрессионного тестирования
💩Помогают автоматизировать ручные проверки, если тестирование занимает много времени
💩Используются для проверки системы не тестировщиками, для онбординга новых людей на проект
💩Помогают определить необходимое время на тестирование
💩Избыточны для небольших задач
💩Требуют много времени на написание и актуализацию
💩Может возникнуть "Эффект пестицида" — когда из-за постоянного повторения одинаковых шагов не получается найти ошибки


Содержание тест-кейса

💫Уникальный номер. Позволит ссылаться на тесты по номеру
💫Заголовок. Отражает цель - что именно нужно проверить
💫Предусловия. Что нужно сделать перед началом тест-кейса
💫Постусловия (редко). Что нужно сделать после проведения проверки. Например, удалить изменения из базы данных
💫Шаги. Что нужно сделать для проверки
💩Не описывать шаги слишком подробно. Например, следует писать «Введите email» вместо «Введите email, нажимая клавиши на клавиатуре».
💩Шаги должны быть конкретными. Написать: “Нажмите на иконку пользователя → Личный кабинет” вместо “Зайдите в личный кабинет”
💩Скриншоты можно использовать только как дополнение к текстовому описанию
💫Ожидаемый результат. Что должно получиться после или во время прохождения шагов
💫Статус. Passed/Failed, то есть Успех/Провал или другой. Отмечается при прохождении кейса тестировщиком


Use Case 🆚 Test Case

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

🔸 Test Case — детальное описание того, как должно проходить тестирование конкретной функции в системе. Основываются на юскейсах и используются для проверки соответствия реализации требованиям.


👨‍💻 Аналитик и тест-кейсы
➖На старте проекта кейсы может написать и согласовать аналитик - именно он лучше всех знает требования к системе. Это упростит сдачу проекта в будущем
➖Аналитик подсвечивает тестировщику какую часть функционала нужно оформить в виде кейсов для регрессионного тестирования - что было самым важным в релизе
➖Ревью тест-кейсов — аналитик проверяет, что тестировщик правильно понял задачу и ожидаемый результат соответствует требованиям


Инструменты ведения для тест-кейсов:
➖Zephyr for Jira
➖TestRail
➖Qase
➖Test IT


⭐️ Подборка материалов доступна в базе знаний по системному анализу

#тестирование

Все видеозвонки, которые вы когда-либо видели

Две книги по DevOps от Джена Кима. Первая написана в формате романа, вторая является технически более детальным продолжением.

1️⃣Проект «Феникс». Роман о том, как DevOps меняет бизнес к лучшему

✍️ Автор: Джин Ким, Бер К., Спаффорд Д.
🔤 Язык: русский
📚 Объём: 228 стр.

В этой художественной книге рассматриваются реалистичные сценарии работы в IT-компании. Проект «Феникс» предлагает читателям ряд эффективных инструментов и подходов в рамках практик DevOps.
- Подходит для ознакомления с профессией
- Описано, как происходит становление DevOps-специалиста в компании.
В книге есть конкретные практики вывода IT в компаниях на новый уровень эффективности и взаимодействия с бизнесом.
Легкий и доступный для новичка язык повествования.
Книга не содержит конкретных технических решений.

User Story vs Job Story

📄User Story – это краткое описание функции с точки зрения пользователя и наименьшая единица работы в Agile. В среднем, команда может выполнить 2-3 user story за двухнедельный спринт

Цель: декомпозировать требования на понятные и выполнимые элементы
Формула: Я, как [тип пользователя], хочу [желание], чтобы [ценность или результат]
Пример: Я, как пользователь сайта, хочу получить трек-номер, чтобы следить за посылкой. Я, как пользователь, могу запросить напоминание пароля, чтобы восстановить пароль

Как составить user story:
➖Определите пользователя, для которого создается функция
➖Сформулируйте результат, который получит пользователь после использования функции
➖Опишите ситуацию, в которой пользователь может использовать функцию
➖Укажите ограничения или условия, при которых функция должна работать

Способ проверки “INVEST”:
➖«I» Independent — независима от других историй
➖«N» Negotiable — обсуждаема, по ней можно спланировать дальнейшие действия
➖«V» Valuable — ценная, отвечает на вопрос «зачем»
➖«E» Estimable — оцениваемая, можно установить критерии успеха
➖«S» Small — маленькая или короткая, описывает одну задачу
➖«Т» Testable — тестируемая - можно получить обратную связь от пользователей и сделать выводы


🎯Job Story (инструмент из концепции Jobs To Be Done (JBTD)) - это описание возможных ситуаций, при которых пользователь хочет воспользоваться нашим продуктом

Цель: определить ситуации, в которых у пользователя возникает потребность в продукте
Формула: Когда [ситуация], я хочу [мотивация], чтобы [ожидаемый результат]
Пример: когда пользователь оплатил заказ на сайте, он беспокоится, доставят ли ему товар и хочет получить трек-номер, чтобы следить за посылкой

Способ проверки:
➖Описывает результат, который получит пользователь
➖Не содержит готовое решение
➖Описывает контекст, в котором человек находится при возникновении проблемы, а не саму проблему
➖Отвечает на вопрос «Почему/для чего?» мы должны это сделать

Отличия:
💩User Story описывает конкретный сценарий с точки зрения пользователя, Job Story - общую задачу, которую он выполняет в системе
💩User Story фокусируется на описании одной задачи, Job Story может включать в себя несколько User Story
💩User Story помогать лучше узнать пользователей, Job Story отвечают на вопрос почему они продолжают пользоваться продуктом и почему приходят новые


Совмещение инструментов:
1. Изучить потребности пользователей
2. Описать потребности по шаблону Job Story, это позволит видеть картину пользователя целиком: его чувства, эмоции, привычные реакции
3. Придумать как удовлетворить потребности, описанные в Job Story
4. Выбрать решение и описать его по шаблону User Story
5. Передать User Story в разработку

Итог:
💩Job Story подходит, если нужны идеи для доработки текущего продукта или создания нового
💩User Story подходит, если нужно декомпозировать и описать уже выбранное решение

⭐️ Подборка материалов доступна в базе знаний по системному анализу

#требоваия

Большая подборка материалов по 8 нотациям доступна в базе знаний по системному анализу