Андрей

Приоритезация

2024-06-22T16:07:20.891Z

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

11 мин

9.3KУправление разработкой*Управление проектами*Управление продуктом*Технотекст 2022

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

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

Привет,

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

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

Когда не обойтись без фреймворка приоритизации

В стартапах ранней стадии чаще всего фреймворки приоритизации не используются. Команда занята проверкой гипотез, поиском целевого сегмента клиентов, изучает его потребности и тестирует базовое решение (продукт) — ищет product-market fit. Проверка гипотез в большинстве случаев не требует разработки — ручные продажи, лендинги, чаты, no code — любимые инструменты стартаперов. То есть разработчиков может не быть совсем или они могут разрабатывать ядро продукта из минимального набора необходимых компонентов.

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

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

Благодаря скорингу фичей получается:

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

Распаковываем RICE и ICE

Существует как минимум 15 фреймворков приоритизации задач — модель Кано, взвешенная оценка, MoSCoW и другие. Среди самых популярных методов скоринга фичей выделяют RICE и ICE. Первую популяризировал предприниматель Шон Эллис в книге «Взрывной рост» (Growth Hacking) в 2017 году, потом уже в 2018 ветеран Google и Microsoft Итамар Гилад разобрал работу фреймворка ICE.

RICE

Свое название методика получила по первым буквам входящих в расчет компонент:

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

ICE

ICE — это вариация RICE, где отдельно не выделяют R (Reach), считая его компонентом I (Impact). Это имеет смысл с точки зрения бизнеса. Например, если фича затрагивает небольшой процент наиболее лояльных пользователей, Reach (охват) будет низким, тогда как Impact (влияние) будет больши́м.

Дальше я буду говорить только про ICE.

Чаще всего используют одну из двух трактовок ICE — «классическую» или «финансовую».

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

Impact (влияние) включает в себя сразу и количество охваченных клиентов, и выгоду от фичи. Как правило, для быстрой оценки Impact оценивается в баллах по шкале от 1 до 10.
Confidence остается тем же, что и в RICE. Измеряется по шкале от 1 до 10 или в процентах.
Effort меняется на Ease — простоту реализации, по сути, обратное значение от усилий. Effort можно считать в человеко-днях, story points, T-shirts (S, M, L, XL) или аналогично Impact разбить на 10 интервалов.

Поясню, как работает «быстрый» ICE, на примере абстрактной фичи, отправляющей некоторые системные сообщения не по SMS, а через push в мобильное приложение:

это фича средняя по эффекту на бизнес — на 5 из 10;
выше среднего по сложности разработки — на 8 из 10;
уверенность почти 100%, но что-то может пойти не так, поэтому 80%.

Impact (5) × Confidence (80%) / Effort (7) = 0,57 условной единицы оценки.

Очень часто классического ICE недостаточно, например, если нужно не просто приоритизировать фичи внутри команды, но и выбрать между собственной разработкой, покупкой вендорского решения или «ручным бэкендом» операционной команды.

Для таких случаев подходит более точный вариант — финансовый ICE — подсчет выгоды от вложения денег в разработку фичи или, как говорят финансисты, profit & loss (PnL): дословно «прибыль и убытки». Финансовый вариант сложнее для расчета, но зато оперирует понятными для руководства измерениями — затратами и экономическим эффектом в деньгах.

В этом случае:

Impact считается в долларах или рублях;
Confidence, как и раньше, в процентах от никакой 0% до абсолютной уверенности 100% в успехе фичи;
Effort в стоимости разработки.

А оценка нашей фичи из примера будет такова:

охват 100 тыс. пользователей; считаем экономию для каждого: частота 10 сообщений в год, стоимость одного сообщения 2 рубля через SMS, push — 0.5 рублей с учетом поддержки этого канала;
Confidence — тот же, 80%;
20 дней разработки = 700 тыс. руб.

Impact (100 тыс. пользователей × 10 сообщений в год × (2 — 0.5) руб. экономии) × 80% — 700 тыс. руб. = 500 тыс. руб.

Достоинства и недостатки ICE скоринга

Подход ICE часто критикуют (например, здесь):

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

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

Impact

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

Чтобы не углубляться в юнит-экономику, тонкости расчета lifetime value, разберем простой пример: вы продакт внутреннего продукта службы поддержки клиентов. Ваша фича — внедрение чат-бота в личном кабинете клиента для снижения нагрузки на телефонную поддержку.

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

Какие данные могут пригодиться для расчета?

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

Допустим, эти данные есть — что дальше?

Нужно рассчитать бизнес-кейс — экономический эффект по максимально простой формуле.

Для нашего примера бизнес-кейс можно подсчитать так:

100 тыс. пользователей × 10% доля тех, кто обращается в саппорт × 5 обращений в год × 30% доля обращений в чат × 50% потенциал автоматизации × 50 рублей экономии на звонках — 50000 руб. за внедрение внешнего решения — 15000 чатов × 1 руб. выплаты вендору = 310 тыс. руб.

Если вы используете внешний API, его лучше учесть именно в экономическом эффекте вместе с платежами партнерам за внедрение. Затраты вашей команды на интеграцию нужно относить к Effort (усилиям).

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

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

Confidence

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

Я обычно применял метод Confidence-meter от Итамара Гилада, где мнение одного или нескольких коллег дает в лучшем случае 20% уверенности, а полноценная проверка гипотез через интервью, MVP и А/Б-тесты повышает Confidence до 60–95%. 100% по Гиладу не бывает никогда.

Мой совет на этапе оценки уверенности — максимально отключить самоуверенность и сфокусироваться на «накоплении» Confidence с помощью подходящих способов валидации того, что проблема существует, а ваша фича решает эту проблему достаточно эффективно.

Effort и его рост

Перейдем к оценке усилий и трудозатрат.

Здесь я вижу две проблемы.

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

Как правило, оценка сложности занижена.

Ниже пример из моего опыта, когда после предварительной оценки окончательная вырастала на 36–100%, в среднем на 63%. Причина простая: предварительная оценка хорошо описывала известную сложность, то есть была консервативной («не менее, чем...») и оптимистичной («вроде это несложно»).

Effort (high-level)

Effort (after grooming)

Effort difference

Group budgets

75%

3DS add card flow

47%

API credentials

92%

Invite statuses

53%

Reports columns customisation

36%

Booker assignment

80%

Automatic limit for Client X

100%

Subscriptions

40%

Total

189

309

63%

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

Вишенка на торте — калькулятор стоимости человеко-дня

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

Я не нашел годного расчета, поэтому запилил свой Калькулятор стоимости 1 дня разработки:

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

39 тыс. руб. для аккредитованной IT-компании;
45 тыс. руб. для обычной компании без налоговых льгот.

Средняя фича может стоить 1 млн руб. для компании, так что надо быть уверенным, стоит ее делать или нет. Здесь логично разместить рекламу аутсорс-разработки (становится понятно, почему даже компании с сильной in-house командой привлекают внешнюю помощь).

Трудозатраты: взгляд разработчика

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

Слово Стасу:

Откуда к нам приходят фичи? Компания ставит цели, договаривается с командами о приоритетных направлениях, формулирует OKR. Для выполнения OKR придумываются гипотезы, часть из них попадает в разработку.
Задачи приходят к нам в виде эпиков — улучшений продукта, которые можно сделать за один-максимум два спринта. Я слежу за тем, чтобы эпики не превышали 15–20 стори поинтов и предлагаю продакту фазировать улучшения. С помощью дробления повышается и точность оценки трудозатрат, и сокращаются сроки релизов.
Основной конфликт: продакт хочет фичи, разработчики не хотят продуктовый долг.
Продакт хочет, чтобы фичи делались дешево, потом стоимость владения не увеличивалась.
Чтобы разрешить этот конфликт, мы договорились, что 20% трудозатрат отдаем на погашение тех долга. Этот резерв распределяет команда разработки.
Сменятся поколения продактов и разработчиков, но нужно отдавать старые долги.

Что нужно, чтобы приоритизация заработала

Сначала стратегия, потом фичи.

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

займет много времени;
может расфокусировать команду.

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

Договоритесь в компании о единой методологии оценки.

Вторая преграда для внедрения ICE или другой методологии — приоритизация должна быть сквозной, то есть единой для всех команд, которые тесно работают друг с другом. Это одна из задач директора по продуктам (Chief Product Officer) — придумать одинаковые правила игры.

Приоритизируйте крупные фичи, затем всё остальное.

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

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

Используйте инструменты для фиксирования и автоматического обновления ICE.

В Jira и другом ПО для приоритизации есть возможность добавлять ICE-score к каждой задаче. По моему опыту еще лучше дополнительно разложить ICE на impact, confidence и effort и сделать один слайд (1-pager) для руководства, чтобы более широкому кругу, а не только команде разработки, было понятно, как компания тратит деньги и что получит взамен.

Заключение

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

Используйте ICE вместо RICE (Impact может включать в себя Reach).
Как расшифровывать E — решать вам. Это ease (сложность реализации) или величина обратно пропорциональная — effort (усилия).
Быстрый ICE в условных единицах подходит для скоринга 100 задач. Если надо выбирать из 20 — посчитайте ICE в деньгах.
Бизнес-кейс — фундамент для оценки эффекта (Impact). Постарайтесь, чтобы ваша формула для экономического эффекта была простой и проверяемой. Компоненты для формулы держите под рукой.
Уверенность (Confidence) не должна строиться только на харизме автора идеи, идеи нужно проверять, чтобы сделать Confidence ближе к 100% — интервью с клиентами хорошо, тестовый запуск еще лучше.
Трудозатраты (Effort) можно считать в человеко-днях или story points. Заложите рост оценки усилий на разработку по мере углубления в требования по фиче.
За человеко-день разработчик получит на руки 10 тыс. руб., а компании этот день обойдется в 39 тыс. руб. из-за налогов, бенефитов и накладных расходов. Не забывайте про деньги, когда загружайте in-house разработку, и нанимайте аутсорсеров для отдельных задач.
Effort генерит технический долг. Договоритесь с разработчиками о его размере и способах погашения.
Чтобы приоритизация прижилась в компании:

Приоритизируйте задачи, связанные со стратегическим выбором компании. Проверяйте цепочку от фичи к целям компании.
Договоритесь со всеми смежными командами о единой методологии приоритизации.
Приоритизируйте по Стивену Кови — сначала внутри списка крупных задач, потом переходите к средним и небольшим.
Упрощайте расчет ICE через трекеры задач.

Если хотите обсудить продакт-менеджмент, приоритизацию, добавляйтесь в LinkedIn или пишите в личку в Telegram.

Теги:

Хабы:

Источник: Приоритизация бэклога. Зачем нужны фреймворки и как работать по ICE — опыт менеджера с 5-летним стажем / Хабр (habr.com)

System design

2024-06-21T16:13:30.621Z

В шпаргалке на высоком уровне рассматриваются такие вещи, как протоколы коммуникации, DevOps, CI/CD, архитектурные паттерны, базы данных, кэширование, микросервисы (и монолиты), платежные системы, Git, облачные сервисы etc. Особую ценность представляют диаграммы — рекомендую уделить им пристальное внимание. Полагаю, шпаргалка будет интересна всем, кто хоть как-то связан с разработкой программного обеспечения и, прежде всего, веб-приложений. Буду признателен за помощь в уточнении/исправлении понятий, терминологии, логики/алгоритмов работы систем (в рамках того, что по этому поводу содержится в оригинале), а также в обнаружении очепяток.

Выражаю благодарность Анне Неустроевой за помощь в редактировании материала.

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

System Design (сборник на английском языке).

Протоколы

CI/CD

Архитектурные паттерны

База данных

Кэш

Микросервисная архитектура

Платежные системы

DevOps

Облачные сервисы

Инструменты, повышающие продуктивность разработки

Linux

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

Реальные системы

Протоколы

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

SOAP:

зрелый, всесторонний, основанный на XML
хорошо подходит для корпоративных приложений

REST:

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

GraphQL:

язык запросов (query language), позволяющий запрашивать данные избирательно (частично)
меньше нагрузка на сеть, более быстрые ответы от сервера

gRPC:

современный, высокопроизводительный, основанный на буферах протоколов (protocol buffers)
хорошо подходит для микросервисов

WebSocket:

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

Webhook:

основанный на событиях и коллбэках HTTP, асинхронный
хорошо подходит для систем уведомлений

REST и GraphQL

Сравнение REST и GraphQL:

GraphQL – это язык запросов для API, разработанный Meta. Он предоставляет полное описание данных в API и позволяет клиенту запрашивать только то, что ему нужно
сервер GraphQL является посредником между клиентом и сервером. GraphQL может агрегировать несколько запросов REST в один запрос (и request, и query в переводе на русский означают "запрос"). Сервер GraphQL организует ресурсы в граф (отсюда и название)
GraphQL поддерживает запросы, мутации (модификация ресурсов) и подписки (получение уведомлений о модификациях)

gRPC

RPC (Remote Procedure Call – удаленный вызов процедур) называется "удаленным", поскольку обеспечивает взаимодействие между удаленными сервисами, когда они находятся на разных серверах в микросервисной архитектуре. С точки зрения пользователя это выглядит, как вызов локальной функции.

На диаграмме представлен поток данных (flow) gRPC:

Клиент отправляет REST-запрос. Тело запроса (request body) содержит данные в формате JSON (как правило).
2-4. Сервис заказов (order service) (клиент gRPC) получает запрос, преобразует его и отправляет запрос RPC сервису оплаты (payment service) (сервер gRPC). gRPC кодирует данные клиента в двоичный формат и отправляет их в низкоуровневый транспортный слой (transport layer).
gRPC отправляет пакеты данных (data packages) по сети с помощью HTTP2. Благодаря двоичной кодировке и сетевым оптимизациям gRPC может быть до 5 раз быстрее JSON.
6-8. Сервис оплаты получает пакеты данных по сети, декодирует их и вызывает серверное приложение.
9-11. Результат, полученный от серверного приложения, кодируется и отправляется в транспортный слой.
12-14. Сервис заказов получает пакеты данных, декодирует их и отправляет результат клиентскому приложению.

Webhook

Сравнение Polling (опроса) и Webhook:

Предположим, что у нас есть электронный магазин. Клиенты отправляют заказы в сервис заказов через шлюз API (API Gateway), а сервис заказов обращается к сервису оплаты для выполнения денежных транзакций. Сервис оплаты, в свою очередь, обращается к внешнему провайдеру сервиса оплаты (Payment Service Provider, PSP) для завершения транзакции.

Существует 2 способа взаимодействия с внешним PSP.

1. Короткий опрос

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

Короткий опрос имеет следующие недостатки:

постоянные запросы статуса расходуют ресурсы сервиса оплаты
внешний сервис взаимодействует напрямую с сервисом оплаты, что создает уязвимости безопасности

2. Веб-хуки

Веб-хук регистрируется во внешнем сервисе. Мы как бы просим внешний сервис сообщить нам об изменениях по запросу по указанному URL. После выполнения операции, PSP отправляет запрос HTTP для обновления статуса платежа.

Ресурсы сервиса оплаты больше не расходуются на опрос.

Веб-хуки часто называют реверсивными (reverse) API или push-API, поскольку сервер отправляет запрос HTTP клиенту, а не наоборот.

При использовании веб-хуков следует уделять пристальное внимание следующим вещам:

API должно быть правильно спроектировано для взаимодействия с внешним сервисом
в шлюзе API должны быть установлены определенные правила безопасности
во внешнем сервисе следует регистрировать правильный URL

Производительность API

5 распространенных способов улучшения производительности API:

Пагинация

Эту оптимизацию применяют в случае большого объема данных. Результат отправляется клиенту по частям (чанкам — chunks) для улучшения отзывчивости сервиса.

Асинхронное логирование

Синхронное логирование работает с диском при каждом вызове и может замедлить систему. Асинхронное логирование отправляет логи в буфер без блокировки (lock-free buffer) и сразу возвращается. Логи записываются на диск с определенной периодичностью. Это существенно снижает нагрузку на ввод/вывод.

Кэширование

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

Сжатие полезной нагрузки

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

Пул подключений

При доступе к ресурсам нам часто приходится загружать данные из БД. Открытие нового подключения к БД – дорогая операция, с точки зрения производительности, поэтому для доступа к БД следует использовать пул открытых (набор существующих) подключений (connection pool). Пул подключений отвечает за управление жизненным циклом соединений.

HTTP 1.0 -> HTTP 1.1 -> HTTP 2.0 -> HTTP 3.0 (QUIC)

HTTP 1.0 был завершен и полностью задокументирован в 1996. Каждый запрос к серверу требует отдельного соединения TCP
HTTP 1.1 был опубликован в 1997. TCP-соединение может оставаться открытым для повторного использования (постоянное подключение), но проблема блокировки HOL (head-of-line) остается. Блокировка HOL означает, что когда исчерпан лимит параллельных запросов, новые запросы ждут завершения предыдущих
HTTP 2.0 был опубликован в 2015. Он решает проблему HOL путем мультиплексирования запросов на уровне приложения (application layer), но HOL остается на транспортном уровне (transport layer, например, TCP). Как видно на диаграмме, HTTP 2.0 представил концепцию "потоков" (streams) HTTP — абстракция, позволяющая разным запросам HTTP использовать одно соединение TCP. Потоки могут отправляться в разном порядке
первый черновик HTTP 3.0 был опубликован в 2020. В качестве нижележащего транспортного протокола вместо TCP в нем используется QUIC, что решает проблему HOL в транспортном слое

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

SOAP, REST, GraphQL и RPC

Существуют разные архитектурные стили API, каждый со своими паттернами и стандартами обмена данными:

Сначала код и сначала API

Разница между подходами к разработке "Сначала код" и "Сначала API" (Code First, API First):

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

При написании кода следует помнить о сложности системы и аккуратно определять границы (зоны ответственности) сервисов.

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

Для валидации дизайна API перед написанием кода можно использовать фиктивные запросы и ответы.

В целом, микросервисная архитектура повышает качество ПО и продуктивность разработчиков. Грамотно спроектированное API позволяет быстрее запускать проект и делает процесс разработки более плавным.

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

Снижается вероятность возникновения неприятных сюрпризов на последних этапах жизненного цикла проекта.

Наличие спроектированного API позволяет писать тесты, не дожидаясь разработки. Отсюда один шаг к разработке на основе тестов (Test Driven Design, TDD).

Коды статусов HTTP

Коды ответов(статусов) HTTP делятся на 5 категорий:

Информационные (100-199).
Коды успеха (200-299).
Коды перенаправления (300-399).
Коды ошибок на стороне клиента (400-499).
Коды ошибок на стороне сервера (500-599).

Коды ответов HTTP на MDN.

Шлюз API

Клиент отправляет запрос HTTP в шлюз API (API Gateway).
Шлюз разбирает (парсит) и проверяет атрибуты запроса.
Шлюз выполняет проверки по белому/черному списку ресурсов.
Шлюз обращается к провайдеру идентификации (поставщику удостоверений – Identity Provider) для аутентификации и авторизации.
К запросу применяются правила ограничения частоты запросов (rate limit). При превышении лимита запрос отклоняется.
6 и 7. После выполнения проверок шлюз определяет сервис, совпадающий с путем роута (route path).
Шлюз преобразует запрос в подходящий протокол и передает его серверным микросервисам.
9-12. Шлюз отвечает за обработку ошибок, а также провалов, связанных с тем, что решение проблемы требует больше времени (разрыв цепочки — circuit break). Для логирования и мониторинга здесь также может использоваться стек ELK (Elastic-Logstash-Kibana). Здесь же можно реализовать кэширование данных.

Эффективное и безопасное API

Типичные проекты/схемы API на примере корзины товаров:

Обратите внимание, что дизайн API – это не только дизайн URL. Необходимо правильно выбирать названия ресурсов, идентификаторы и паттерны путей (path patterns). Также важно устанавливать правильные заголовки HTTP и эффективные правила ограничения частоты запросов (rate limit).

Инкапсуляция TCP/IP

Как данные передаются по сети? Почему в сетевой модели OSI (Open Systems Interconnection – взаимосвязь открытых систем) так много уровней?

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

Когда устройства А передает данные устройству Б по протоколу HTTP, сначала на уровне приложения (application layer) в запрос добавляется заголовок HTTP.
Затем к данным добавляются заголовки TCP или UDP. Они инкапсулируются в сегменты TCP на транспортном уровне (transport layer). Заголовок содержит порт источника (source port), порт назначения (destination port) и номер последовательности (sequential number).
Затем на сетевом уровне (network layer) добавляется заголовок IP. Он содержит адреса IP источника/назначения.
На уровне связи данных (data link layer) в датаграмму (datagram) IP добавляется заголовок MAC с MAC-адресами источника и получателя.
Инкапсулированные кадры (фреймы – frames) попадают на физический уровень (physical layer) и передаются по сети в двоичном виде.
6-10. При получении битов по сети устройство Б выполняет процесс распаковки, обратный процессу инкапсуляции. Заголовки удаляются слой за слоем, после чего устройство Б может читать данные.

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

Почему NGINX называют "обратным" прокси?

Разница между прямым (forward) и обратным (reverse) прокси:

Прямой прокси – это сервер, находящийся между пользователем и Интернетом.

Прямой прокси обычно используется для:

Защиты клиентов.
Преодоления ограничений браузера.
Блокировки доступа к определенным ресурсам.

Обратный прокси – это сервер, принимающий запросы от клиента, передающий их веб-серверу и возвращающий результат клиенту после обработки запроса сервером.

Обратный прокси хорошо подходит для:

Защиты сервера.
Балансировки нагрузки.
Кэширования статических ресурсов.
Кодирования и декодирования подключений SSL.

Алгоритмы балансировки нагрузки

6 наиболее распространенных алгоритмов балансировки нагрузки:

Статические алгоритмы

Циклический (round robin) – запросы клиента передаются разным экземплярам сервиса по порядку. Как правило, сервисы не владеют состоянием (stateless).
Липкий (sticky) циклический – улучшение циклического алгоритма. Если первый запрос Алисы передается сервису А, последующие запросы Алисы также передаются этому сервису.
Взвешенный (weighted) циклический – администратор присваивает веса каждому сервису. Чем больше вес, тем больше запросов может обработать сервис.
Хэш – данный алгоритм применяется функцию хэширования к IP или URL входящего запроса. Хэш определяет сервис, которому передается запрос.

Динамические алгоритмы

Наименьшее количество соединений (least connections) – новый запрос передается экземпляру с наименьшим количеством параллельных подключений.
Наименьшее время ответа (least response time) – новый запрос передается экземпляру с наименьшим временем ответа.

URL, URI и URN

Сравнение URL, URI и URN:

URI

URI расшифровывается как Uniform Resource Identifier (единый идентификатор ресурса). Он определяет логический или физический ресурс в вебе. URL и URN являются подтипами URI. URL определяет локацию (местонахождения) ресурса, а URN — название ресурса.

URI состоит из следующих частей:

URL

URL расшифровывается как Uniform Resource Locator (единый указатель ресурсов) и является ключевой концепцией HTTP. Он представляет собой уникальный адрес ресурса в вебе. URL может использоваться с другими протоколами, такими как FTP и JDBC.

URN

URN расшифровывается как Uniform Resource Name (единое имя ресурса). URN не могут использоваться для локализации ресурса. Простым примером является сочетание пространства имен (namespace) и специфичной для него строки.

URIs, URLs, and URNs: Clarifications and Recommendations 1.0.

CI/CD

CI/CD простыми словами

SDLC с CI/CD

SDLC (software development life cycle – процесс разработки ПО) состоит из нескольких основных этапов: разработка, тестирование, деплой и поддержка. CI/CD автоматизирует и интегрирует эти этапы для обеспечения более быстрых и надежных релизов.

Отправка ("пуш") кода в репозиторий запускает сборку и тесты. Запускаются тесты непрерывной цепочки (End-to-end, e2e) для валидации кода. Если тестирование проходит успешно, код автоматически разворачивается в стейдже/продакшне. В противном случае, код возвращается на доработку. Эта автоматизация обеспечивает получение быстрой обратной связи разработчиками и снижает риск попадания багов в продакшн.

Разница между CI и CD

Continuous Integration (CI) (непрерывная интеграция) автоматизирует процессы сборки, тестирования и объединения ("мержа"). Она запускает тесты при каждой фиксации ("коммите") кода для обнаружения проблем с интеграцией на ранних стадиях. Это способствует частой фиксации кода и быстрой обратной связи.

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

Конвейер CI/CD

Типичный конвейер (pipeline) CI/CD состоит из нескольких этапов:

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

Технический стек Netflix (конвейер CI/CD)

Планирование: инженеры Netflix используют JIRA для планирования и Confluence для документации.

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

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

Упаковка: пакет и зависимости помещаются в Amazon Machine Image (AMI) для релиза.

Тестирование: подчеркивает направленность культуры продакшна на создание инструментов хаоса.

Деплой: Netflix использует собственный Spinnaker для деплоя.

Мониторинг: метрики мониторинга аккумулируются в Atlas, а для обнаружения аномалий используется Kayenta.

Отчет об инциденте: инциденты сортируются по приоритету, для обработки инцидентов используется PagerDuty.

Архитектурные паттерны

MVC, MVP, MVVM, MVVM-C и VIPER

MVC, самый старый паттерн, появился почти 50 лет назад
каждый паттерн имеет "view" (V), отвечающий за отображение содержимого и обработку пользовательского ввода
большинство паттернов включает "model" (M) для управления данными
"controller", "presenter" и "view-model" являются посредниками между слоем отображения и моделью

18 основных архитектурных паттернов

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

Abstract Factory (абстрактная фабрика): создатель семьи – создает группы связанных элементов
Builder (строитель): мастер лего – создает объекты поэтапно, разделяет создание и отображение
Prototype (прототип): создатель клонов – создает копии полностью готовых объектов
Singleton (одиночка): единственный и неповторимый – специальный класс, который может иметь только один экземпляр
Adapter (адаптер): универсальный плагин – соединяет вещи с разными интерфейсами
Bridge (мост): подключатель функций – связывает объекты с функциями
Composite (композитор): строитель деревьев – формирует древовидные структуры из простых и сложных частей
Decorator (декоратор): настройщик – добавляет возможности в объекты без изменения их ядра
Facade (фасад): единый центр обслуживания – представляет целую систему с помощью одного простого интерфейса
Flyweight (легковес): хранитель пространства – эффективно распределяет небольшие повторно используемые элементы
Proxy (прокси): запасной актер – представляет другой объект, управляет доступом к нему или выполнение операций с ним
Chain of Responsibility (цепочка ответственности): эстафета запроса – запрос обрабатывается цепочкой объектов
Command (команда): обертка задачи – преобразует запрос в объект, готовый к выполнению операции
Iterator (итератор): исследователь коллекций – предоставляет доступ к коллекции элементов по одному
Mediator (посредник): коммуникационный хаб – упрощает взаимодействие между разными классами
Memento (запоминатель): капсула времени – сохраняет и восстанавливает состояние объекта
Observer (наблюдатель): издатель новостей – уведомляет классы об изменениях других объектов
Visitor (посетитель): умелый гость – добавляет новые операции в класс без его модификации

База данных

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

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

8 структур данных, улучшающих работу баз данных

Ответ на этот вопрос зависит от того, как БД используется. Индексы данных могут храниться в памяти или на диске. Форматы данных могут быть разными: числа, строки, географические координаты etc. Система может часто читаться или писаться (write-heavy, read-heavy). Все эти факторы влияют на выбор формата индексов БД.

Наиболее популярные структуры данных, использующиеся для индексации:

Skiplist: индексы хранятся в памяти. Используется в Redis
Hash index (хэшированный индекс): популярная реализация структуры данных "Карта" (или "Коллекция") (map)
SSTable: иммутабельная (неизменяемая) реализация "Карты", хранящаяся на диске
LSM дерево: Skiplist + SSTable. Хорошо подходит для частой записи
B-дерево: индексы хранятся на диске. Согласованная производительность чтения/записи
Inverted index (инвертированный индекс): хорошо подходит для индексации документов. Используется в Lucene
Suffix tree (суффиксное дерево): хорошо подходит для поиска строковых паттернов (string patterns)
R-дерево: разнонаправленный поиск, такой как поиск ближайшего соседа

Выполнение инструкции SQL в базе данных

Разные БД имеют разную архитектуру. Некоторые общие подходы:

Инструкция SQL отправляется в БД через транспортный протокол (например, TCP).
Инструкция передается парсеру команды (command parser), который выполняет ее синтаксический и семантический анализ и генерирует дерево запроса (query tree).
Дерево запроса передается оптимизатору (optimizer). Оптимизатор создает план выполнения (execution plan).
План выполнения передается исполнителю (executor). Исполнитель извлекает данные для выполнения.
Методы доступа (access methods) предоставляют логику получения данных, необходимых для выполнения, извлечения данных из движка хранилища (storage engine).
Методы доступа определяют, является ли инструкция доступной только для чтения. Если да (SELECT), инструкция передается менеджеру буфера (buffer manager) для дальнейшей обработки. Менеджер буфера ищет данные в кэше или файлах.
Если инструкцией является UPDATE или INSERT, она передается менеджеру транзакций (transaction manager) для дальнейшей обработки.
В ходе транзакции данные блокируются (lock mode). За это отвечает менеджер блокировки (lock manager). Блокировка обеспечивает соответствие транзакции принципам ACID.

Теорема CAP

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

Теорема CAP утверждает, что распределенная система не может одновременно соответствовать всем трем критериям.

Consistency (согласованность): все клиенты видят одни и те же данные, независимо от того, к какому узлу (node) они подключены.

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

Partition Tolerance (устойчивость к разделению): разделение означает нарушение коммуникации между двумя узлами. Устойчивость означает, что система продолжает работать, несмотря на разделения.

Формулировка "2 из 3" может быть полезной, но также может вводить в заблуждение.

Выбор базы данных – нелегкая задача. В данном случае нельзя опираться только на теорему CAP. Например, компании не выбирают Cassandra для приложений чата просто потому, что Cassandra является системой AP. Однако Cassandra имеет характеристики, которые делают ее неплохим выбором для хранения сообщений (см. историю Discord в конце).
CAP ограничивает лишь небольшую часть возможностей: идеальная доступность и согласованность при наличии разделения, которое встречается довольно редко.
Теорема утверждает, что возможна 100% доступность и согласованность. На самом деле, речь чаще всего идет о выборе между задержкой и согласованностью при отсутствии сетевого разделения. См. теорему PACELC.

Является ли теорема CAP полезной?

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

Типы памяти и хранилищ данных

Визуализация запроса SQL

Инструкции SQL выполняются БД следующим образом:

разбор инструкции и ее валидация
преобразование SQL во внутренний формат, такой как реляционная алгебра (relational algebra)
оптимизация внутреннего представления и создания плана выполнения (execution plan) на основе индексации
выполнение плана и возвращение результата

Выполнение инструкции SQL является сложным процессом, включающем множество соображений, таких как:

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

Язык SQL

SQL (Structured Query Language – язык структурированных запросов) был стандартизирован в 1986. В течение следующих 40 лет он стал доминирующим языком для систем управления реляционными базами данных. Последний стандарт называется ANSI SQL 2016.

SQL включает в себя 5 основных компонентов:

DDL: data definition language (язык определения данных) — CREATE, ALTER, DROP
DQL: data query language (язык запроса данных) — SELECT
DML: data manipulation language (язык манипуляции данными) — INSERT, UPDATE, DELETE
DCL: data control language (язык управления данными) — GRANT, INVOKE
TCL: transaction control language (язык управления транзакциями) — COMMIT, ROLLBACK

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

Кэш

Кэширование данных

Кэширование данных в типичной архитектуре:

Кэширование данных выполняется на нескольких уровнях:

Клиентские приложения: ответы HTTP могут кэшироваться браузером. Мы запрашиваем данные по HTTP в первый раз, данные возвращаются с политикой истечения срока действия (expiry policy) в заголовке HTTP. Мы запрашиваем данные повторно, клиентское приложение пытается извлечь данные из кэша браузера.
CDN (Content Delivery Network – сеть доставки контента): CDN кэшируют статические веб-ресурсы. Клиенты могут извлекать данные из ближайшего узла CDN.
Балансировщик нагрузки (Load Balancer): балансировщик нагрузки также может кэшировать данные.
Брокер сообщений (Message Broker): брокер сначала записывает сообщения на диск, потребители извлекают их по необходимости. Данные кэшируются в кластерах Kafka, например, в течение времени, определяемого политикой удержания (retention policy).
Сервисы: в сервисах существуют разные уровни кэша. Если данные не кэшированы в кэше CPU, сервис пытается извлечь данные из памяти. Иногда имеется второй слой кэша с хранением данных на диске.
Распределенный кэш (Distributed Cache): Redis, например, хранит в памяти пары ключ-значение для различных сервисов. Операции чтения/записи в Redis выполняются значительно быстрее по сравнению с базой данных.
Полнотекстовый поиск (Full-text Search): Elastic, например, хорошо подходит для поиска документов или отчетов (логов). Поисковый движок выполняет индексацию копии данных.
БД: в БД существуют разные уровни кэша:

WAL (Write-ahead Log – журнал упреждающей записи) – данные записываются в WAL перед построением B-дерева
Bufferpool – область памяти, выделяемая для кэширования результатов запросов
материализованное представление (Materialized View) – предварительное вычисление результатов запросов и их сохранение в таблицах БД для повышения производительности
журнал транзакций (Transaction Log) – фиксация всех транзакций и обновлений БД
журнал репликации (Replication Log) – фиксация состояния репликации кластера БД

Причины высокой производительности Redis

Redis – это хранилище данных, основанное на RAM. Доступ к оперативной памяти как минимум в 1000 раз быстрее доступа к диску.
Для повышения эффективности выполнения запросов в Redis используется мультиплексирование ввода/вывода и однопоточный цикл выполнения.
В Redis используется несколько эффективных низкоуровневых структур данных.

Другим популярным решением для хранения данных в памяти является Memcached.

Случаи использования Redis

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

Сессии – распределение сессии пользователя между разными сервисами
кэш — кэширование объектов или страниц
распределенная блокировка (Distributed Lock) – строка Redis может использоваться для блокировки распределенных сервисов
счетчик – подсчет количества лайков или чтений статьи
ограничение частоты запросов (Rate Limit) – ограничение частоты запросов на основе IP пользователя
генератор глобальных идентификаторов
корзина товаров – хэш Redis может использоваться для представления пар ключ-значение в корзине товаров
вычисление вовлеченности пользователя (User Retention) – Bitmap может использоваться для представления ежедневного входа пользователя в систему и его вовлеченности
очередь сообщений (Message Queue)
ранжирование–- для сортировки статей может использоваться ZSet

Стратегии кэширования

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

Микросервисная архитектура

Типичная микросервисная архитектура

Типичная микросервисная архитектура состоит из следующих частей:

балансировщик нагрузки (Load Balancer) – распределяет входящий трафик между сервисами
CDN (Content Delivery Network — сеть доставки контента) – группа географически распределенных серверов, содержащих статический контент для быстрой доставки. Клиенты сначала запрашивают данные из CDN и только после этого обращаются непосредственно к сервису
шлюз API (API Gateway) – обрабатывает входящие запросы и передает их соответствующим сервисам. Он общается с провайдером идентификации (Identity Provider – поставщик удостоверений) и другими службами
провайдер идентификации – обработка аутентификации и авторизации пользователей
реестр служб (Service Registry) – отвечает за регистрацию микросервисов для использования другими компонентами системы, такими как шлюз API
управление — мониторинг сервисов
микросервисы – проектируются и разворачиваются в разных доменах (domains). У каждого домена своя база данных. Шлюз API общается с микросервисами через REST или другие протоколы, микросервисы одного домена общаются между собой через RPC

Преимущества микросервисов

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

Лучшие практики микросервисов

9 лучших практик разработки микросервисов:

У каждого микросервиса должно быть свое хранилище данных.
Код каждого сервиса должен быть примерно на одном уровне завершенности.
Каждый сервис должен собираться независимо от других.
У каждого сервиса должно быть своя зона ответственности.
Сервисы должны разворачиваться с помощью контейнеров.
Сервисы не должны хранить состояние (должны быть stateless).
Должен применяться доменно-ориентированный дизайн.
Микрофронтенды.
Окрестрация сервисов.

Типичный технический стек микросервисов

Препродакшн

Определение API – определение коммуникации между фронтендом и бэкендом. Для этого может использоваться Postman или OpenAPI.
разработка – для разработки фронтенда чаще всего используется React, для разработки бэкенда — Python/PHP/Java/GO etc. Шлюз API (API Gateway) конфигурируется в соответствии с определением API.
непрерывная интеграция (Continuous Integration, CI) – для автоматизированного тестирования часто используется JUnit и Jenkins. Код упаковывается в образ Docker и разворачивается в виде микросервисов.

Продакшн

Для балансировки нагрузки часто используется Nginx. Cloudflare предоставляет CDN (Content Delivery Network — сеть доставки контента)
шлюз API
облачная инфраструктура — микросервисы разворачиваются в облаке: AWS, Microsoft Azure, Google GCP etc. Для кэширования данных чаще всего используется Redis, для полнотекстового поиска – Elastic Search
взаимодействие между сервисами -–для этого используются брокеры сообщений (Message Broker) вроде Kafka или RPC
хранение данных – реляционные, нереляционные базы данных, облачные хранилища etc.
управление и мониторинг — для управления микросервисами используются такие инструменты, как Prometheus, Elastic Stack, Kubernetes etc.

Причины высокой производительности Kafka

На производительность Kafka влияет множество архитектурных решений. 2 основных:

Последовательный ввод/вывод (Sequential IO).
Принцип нулевого копирования (Zero Copy Principle).

Диаграмма иллюстрирует, как данные передаются между производителем (producer) и потребителем (consumer), а также что означает принцип нулевого копирования.

1.1-1.3. Производитель записывает данные на диск.

Потребитель читает данные без нулевого копирования.
2.1. Данные загружаются с диска в кэш операционной системы.
2.2. Данные копируются из кэша ОС в приложение Kafka.
2.3. Приложение Kafka копирует данные в буфер сокета (socket buffer).
2.4. Данные копируются из буфера сокета на сетевую карту.
2.5. Сетевая карта отправляет данные потребителю.
Потребитель читает данные с нулевым копированием.
3.1. Данные загружаются с диска в кэш ОС.
3.2. Кэш ОС копируется сразу на сетевую карту с помощью команды sendfile().
3.3. Сетевая карта отправляет данные потребителю.

Нулевое копирование — это сохранение нескольких копий данных в контекстах приложения и ядра (kernel).

Платежные системы

Почему кредитную карту называют "самым выгодным продуктом банка"? Как VISA/Mastercard делают деньги?

Экономическая составляющая оплаты товара с помощью кредитной карты:

Держатель карты платит 100$ за товар.
Продавец получает более высокие продажи и должен компенсировать банку-эмитенту (банку, выпустившему карту) и карточной сети (card network) расходы на обеспечение сервиса оплаты. Банк-эквайер (банк, которому принадлежит платежный терминал) устанавливает продавцу комиссию, которая называется "комиссией за скидку продавца" (merchant discount fee).
3-4. Эквайер удерживает 0,25$ в качестве эквайринговой наценки (acquiring markup) и 1,75$ выплачиваются эмитенту в качестве комиссии за обмен (interchange fee). Комиссия за скидку продавца должна покрывать комиссию за обмен. Комиссия за обмен устанавливается карточной сетью, поскольку согласование эквайером комиссии с каждым продавцом было бы неэффективным.
Карточная сеть согласовывает сетевые оценки и комиссии с каждым банком, который оплачивает расходы сети каждый месяц. Например, VISA взимает оценку 0,11% плюс 0,0195$ за каждую операцию.
Держатель карты платит банку-эмитенту за его услуги.

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

Принцип работы VISA

VISA, Mastercard и American Express выступают в роли карточных сетей (card networks) для клиринга и расчета средств. Банк-эквайер и банк-эмитент могут быть (и часто являются) разными банками. Если бы банки выполняли транзакции одну за другой без посредника, каждый банк должен был бы устанавливать транзакцию с другими банками. Это неэффективно.

На диаграмме показана роль VISA в процессе оплаты с помощью кредитной карты. Этот процесс на самом деле состоит из двух процессов. Когда пользователь использует карту, запускается процесс авторизации. Когда продавец хочет получить деньги в конце дня происходит процесс захвата и расчетов (capture and settlement).

Авторизация

Эмитент предоставляет карту потребителю.
Держатель карты хочет совершить покупку и прикладывает карту к торговому (Point of Sale, POS) терминалу в магазине.
POS отправляет транзакцию эквайеру, которому принадлежит терминал.
3 и 4. Эквайер отправляет транзакцию в карточную сеть, которая также называется карточной схемой (card scheme). Сеть отправляет транзакцию эмитенту для подтверждения.
4.1, 4.2 и 4.3. Эмитент замораживает деньги при подтверждении транзакции. Подтверждение или отказ отправляются эквайеру, а также – в терминал.

Захват и расчеты

1 и 2. Продавец хочет получить деньги в конце дня, он нажимает "захват" (capture) на терминале. Транзакции отправляются эквайеру группой (batch). Эквайер отправляет группу в карточную сеть.

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

DevOps

DevOps, SRE и Platform Engineering

Концепция DevOps была представлена в 2009 Patrick Debois и Andrew Shafer на конференции "Agile". Они стремились сократить разрыв между разработкой ПО и его эксплуатацией, продвигая культуру сотрудничества и общую ответственность за весь жизненный цикл разработки ПО.

Концепция SRE, или Site Reliability Engineering (проектирование надежности объекта), была впервые разработана компанией Google в начале 2000-х для решения операционных задач управления крупномасштабными и сложными системами. Google разработала методы и инструменты SRE, такие как система управления кластерами Borg и система мониторинга Monarch, чтобы повысить надежность и эффективность своих сервисов.

Platform Engineering (разработка платформ) — это более новая концепция, основанная на SRE. Считается, что это расширение практик DevOps и SRE с упором на предоставление комплексной платформы для разработки продуктов, которая поддерживает всю бизнес-логику.

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

Что такое Kubernetes?

Kubernetes (K8s) – это система оркестрации контейнеров. Она используется для деплоя и управления контейнерами. Ее дизайн во многом вдохновлен Borg – внутренней системой Google.

Кластер (cluster) K8s состоит из набора рабочих машин (worker machines), называющихся узлами (nodes), которые запускают контейнеризованные приложения. Каждый кластер имеет хотя бы один рабочий узел.

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

Компоненты уровня управления

Сервер API – общается со всеми компонентами кластера. Все операции над модулями выполняются через него.
Планировщик (Scheduler) — следит за полезной нагрузкой модулей и загружает создаваемые модули.
Менеджер контроллеров (Controller Manager) – запускает контроллеры, включая Node Controller, Job Controller, EndpointSlice Controller и ServiceAccount Controller.
Etcd – хранилище ключ-значение, используемое в качестве резервного хранилища данных всех кластеров.

Узлы

Модули. Модуль – это группа контейнеров и наименьшая единица, которой оперирует K8s. Модули имеют один IP-адрес, применяемый ко всем контейнерам модуля.
Kubelet – агент, запускающийся на каждом узле кластера. Он обеспечивает запуск контейнеров в модуле.
Kube Proxy – сетевой прокси, запускающийся в каждом узле кластера. Он перенаправляет трафик, приходящий в узел из сервиса. Он перенаправляет запросы для обработки в нужные контейнеры.

Docker и Kubernetes

Что такое Docker?

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

Что такое Kubernetes?

Kubernetes, часто именуемый K8s, – это опенсорсная платформа для оркестрации контейнеров. Она предоставляет фреймворк для автоматизации деплоя, масштабирования и управления контейнеризованными приложениями посредством кластера узлов.

Отличия

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

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

Если быть кратким, то Docker фокусируется на контейнеризации и запуске контейнеров на отдельных хостах, а Kubernetes специализируется на управлении и оркестрации контейнеров в масштабе посредством кластера хостов.

Принцип работы Docker

На следующей диаграмме представлена архитектура Docker и то, что происходит при выполнении команд docker build, docker pull и docker run:

Архитектура Docker включает в себя 3 основных компонента:

клиент (client) – клиент общается с демоном (daemon)
хост (host) – демон регистрирует запросы API и управляет объектами, такими как образы (images), контейнеры, сети и тома (volumes)
реестр (registry) – место хранения образов. DockerHub — публичный/открытый реестр образов

В качестве примера рассмотрим процесс выполнения команды docker run:

Из реестра извлекается соответствующий образ.
Создается контейнер.
Контейнеру выделяется область файловой системы для чтения/записи.
Создается сетевой интерфейс, контейнер подключается к дефолтной сети.
Контейнер запускается.

Git

Принцип работы команд Git

Важно, где хранится наш код. Обычно предполагается, что он хранится либо на удаленном сервере, таком как Github, либо на нашей локальной машине. Но это не совсем так. Git поддерживает 3 локальных хранилища на нашей машине, так что наш код может быть обнаружен в 4 местах:

Рабочая директория (working directory) – место редактирования файлов
промежуточная область (staging area) – временная локация для хранения файлов до следующей фиксации (commit)
локальный репозиторий – содержит зафиксированный код
удаленный репозиторий – удаленный сервер, на котором хранится код

Большинство команд Git осуществляет перемещение кода из одной локации в другую.

Принцип работы Git

Git – это распределенная система контроля версий.

Каждый разработчик поддерживает локальную копию основного репозитория, редактирует и фиксирует (commit) локальную копию.

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

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

Git merge и git rebase

Разница между командами git merge и git rebase:

Когда мы вливаем (merge) изменения из одной ветки (branch) в другую, мы можем использовать git merge или git rebase.

Merge

Данная команда создает новый коммит G в основной (main) ветке. G содержит историю как основной, так и функциональной (feature) ветки.

Merge является недеструктивным (non-destructive) – ни основная, ни функциональная ветка не модифицируются.

Rebase

Rebase перемещает историю функциональной ветки в начало (head) основной ветки. Это приводит к созданию новых коммитов E, F и G для каждого коммита функциональной ветки.

Преимуществом rebase является линейная история фиксации изменений (коммитов).

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

Облачные сервисы

Облачная нативность

Диаграмма показывает эволюцию архитектуры и процессов с 1980-х:

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

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

Облачная нативность включает 4 аспекта:

Процесс разработки – эволюционировал от водопада (waterfall) до Agile и DevOps.
Архитектура приложения – архитектура эволюционировала от монолитов к микросервисам. Каждый сервис является небольшим, адаптируемым к ограниченным ресурсам облачных контейнеров.
Деплой – сначала приложения разворачивались на физических серверах. В 2000-х приложения нечувствительные к задержке стали разворачиваться на виртуальных серверах. Облачная нативность позволяет упаковывать приложения в образы Docker и разворачивать их в контейнерах.
Инфраструктура приложения – приложения массово разворачиваются в облачной инфраструктуре вместо локальных серверов.

Инструменты, повышающие продуктивность разработки

Визуализация файлов JSON

Файлы JSON, содержащие вложенные структуры, сложно читать.

JsonCrack генерирует граф данных на основе файла JSON, что сильно облегчает изучение его структуры.

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

Автоматические преобразование кода в архитектурные диаграммы

Возможности Diagrams:

визуализация архитектуры облачной системы с помощью Python
рендеринг диаграмм в Jupiter Notebook
инструменты проектирования не требуются
поддерживаются следующие провайдеры: AWS, Azure, GCP, Kubernetes, Alibaba Cloud, Oracle Cloud etc.

Linux

Файловая система Linux

Файловая система Linux раньше напоминала неорганизованный город, где люди строили свои дома там, где им заблагорассудится. Однако в 1994 был введен стандарт иерархии файловой системы (Filesystem Hierarchy Standard, FHS) Linux.

Внедряя такой стандарт, как FHS, ПО может обеспечить единообразную структуру в разных дистрибутивах Linux. Тем не менее, не все дистрибутивы Linux строго придерживаются этого стандарта. Они часто включают уникальные элементы или рассчитаны на удовлетворение конкретных потребностей. Начните с изучения названного стандарта. Используйте такие команды, как cd для навигации и ls для просмотра содержимого каталога. Представьте файловую систему в виде дерева, которое начинается с корня (root, /). Со временем это станет для вас второй натурой, превратив вас в опытного администратора Linux.

18 основных команд Linux

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

Популярные команды Linux:

ls – показывает список файлов и директорий
cd – меняет текущую директорию
mkdir – создаёт директорию
rm – удаляет файлы или директории
cp – копирует файлы или директории
mv – перемещает или переименовывает файлы или директории
chmod – меняет разрешения файла или директории
grep – ищет паттерн в файлах
find – ищет файлы или директории
tar – управляет архивными файлами Tarball
vi – редактирует файлы с помощью текстовых редакторов
cat – показывает содержимое файлов
top – показывает процессы и используемые ресурсы
ps – показывают информацию о процессе
kill – завершает процесс с помощью сигнала
du – вычисляет используемое пространство файла
ifconfig – настраивает сетевые интерфейсы
ping – тестирует соединение между хостами

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

Принцип работы HTTPS

Hypertext Transfer Protocol Secure (безопасный протокол передачи гипертекста, HTTPS) – это расширение Hypertext Transfer Protocol (протокола передачи гипертекста, HTTP). HTTPS передает зашифрованные данные с помощью Transport Layer Security (безопасность транспортного уровня, TLS). Если данные будут перехвачены, все, что получит злоумышленник, — это двоичный код.

Как шифруются и расшифровываются данные?

Клиент и сервер устанавливают соединение TCP.
Клиент отправляет серверу приветствие (client hello). Сообщение содержит необходимые алгоритмы шифрования (наборы шифров – cipher suites) и последнюю поддерживаемую версию TLS. Сервер отвечает приветствием (server hello), сообщающим, поддерживает ли он данные алгоритмы и версию TLS. Затем сервер отправляет клиенту сертификат SSL. Сертификат содержит открытый ключ, название хоста, дату истечения срока действия etc. Клиент валидирует сертификат.
После проверки сертификата SSL клиент генерирует ключ сессии (session key) и шифрует его с помощью открытого ключа. Сервер получает зашифрованный ключ и расшифровывает его с помощью закрытого ключа.
Теперь, когда клиент и сервер имеют один и тот же ключ сессии (симметричное шифрование), данные могут передаются по защищенному двунаправленному каналу.

Почему HTTPS переключается на симметричное шифрование при передаче данных?

На это существует 2 основные причины:

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

OAuth 2.0 простыми словами

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

Сущностями, участвующими в OAuth, являются пользователь, сервер и поставщик удостоверений/провайдер идентификации (Identity Provider, IDP).

Токен OAuth

При использовании OAuth мы получаем токен OAuth, который представляет нашу личность и разрешения (permissions). Этот токен может делать несколько важных вещей:

Single Sign-On (единый вход, SSO) – токен OAuth позволяет войти в несколько служб или приложений, используя всего один логин, что делает жизнь проще и безопаснее
авторизация в разных системах – токен OAuth позволяет распределять права авторизации или доступа в разных системах, поэтому нам не нужно выполнять вход в каждую систему по-отдельности
доступ к профилю пользователя – приложения с токеном OAuth могут получить доступ к определенным частям профиля пользователя согласно предоставленным разрешениям.

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

4 наиболее распространенных механизмов аутентификации

Ключи SSH – криптографические ключи, которые используются для безопасного доступа к удаленным системам и серверам.
Токены OAuth – токены, предоставляющие ограниченный доступ к пользовательским данным сторонним приложениям.
Сертификаты SSL – цифровые сертификаты, которые обеспечивают безопасную и зашифрованную связь между серверами и клиентами.
Реквизиты для входа (credentials) – информация, предоставленная пользователем, которая используется для проверки и предоставления доступа к различным системам и сервисам.

Сессия, куки, JWT, SSO и OAuth

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

WWW-аутентификация – самый простой метод. Браузер запрашивает имя пользователя и пароль. Из-за невозможности контролировать жизненный цикл авторизации сегодня этот способ используется редко
контроль жизненного цикла авторизации выполняется с помощью файлов куки (cookie), содержащих данные сессии. Сервер поддерживает хранилище сессий, а браузер сохраняет идентификатор сессии. Файлы куки обычно не подходят для мобильных приложений
для решения проблемы совместимости можно использовать токены. Клиент отправляет токен на сервер, а сервер проверяет его. Недостатком является то, что токен необходимо шифровать и расшифровывать, что может занимать много времени
JWT (JSON Web Token) – это стандартный способ представления токенов. Такие токены можно проверить и им можно доверять, поскольку они содержат цифровую подпись. Поскольку JWT содержит подпись, нет необходимости сохранять информацию о сессии на стороне сервера
SSO (Single Sign-On – единый вход) позволяет войти в систему один раз для авторизации на нескольких сайтах. Для хранения межсайтовой информации в нем используется CAS (Central Authentication Service — центральная служба аутентификации)
OAuth позволяет предоставлять доступ к определенной части наших учетных данных сторонним приложениям

Безопасное хранение паролей в базе данных и их валидация

Плохие практики

хранение паролей в виде обычного текста – плохая идея, поскольку любой, у кого есть внутренний доступ, может их увидеть
непосредственное хранения хэшей паролей является недостаточным с точки зрения безопасности, поскольку оно подвержено атакам с предварительными вычислениями (precomputation attacks), таким как радужные таблицы (rainbow tables)
для смягчения атаки с предварительным вычислением при хэшировании паролей используется соль (salt)

Соль

Согласно рекомендациям OWASP, "соль – это уникальная, случайно сгенерированная строка, которая добавляется к каждому паролю в процессе хэширования".

Хранение пароля и соли

Результат хэширования должен быть уникальным для каждого пароля.
В БД записывается результат выполнения функции hash(password + salt).

Валидация пароля

Клиент вводит пароль.
Система извлекает соль из БД.
Система добавляет соль к паролю и хэширует его. Получаем хэшированное значение H1.
Система сравнивает H1 и H2, где H2 — это хэш, хранящийся в БД. Если H1 и H2 совпадают, введенный пользователем пароль является валидным.

JWT (JSON Web Token) простыми словами

Представьте, что у нас есть специальная коробка под названием JWT. Внутри этой коробки лежит три вещи: заголовок (header), полезная нагрузка (payload) и подпись (signature).

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

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

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

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

Принцип работы Google Authenticator и других типов двухфакторной аутентификации

Google Authenticator используется для входа в учетную запись, когда включена двухфакторная аутентификация.

Google Authenticator – это программный аутентификатор, реализующий службу двухэтапной проверки.

Данный процесс состоит из 2 этапов:

Пользователь включает двухэтапную аутентификацию Google.
Пользователь использует аутентификатор для входа в систему etc.

Стадия 1

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

Служба аутентификации возвращает URI клиенту. URI состоит из эмитента ключа (key issuer), имени пользователя и секретного ключа. URI отображается в виде QR-кода на странице.
Боб использует Google Authenticator для сканирования сгенерированного QR-кода. Секретный ключ записывается в аутентификатор.

Стадия 2

1 и 2. Боб хочет войти на сайт с двухэтапной проверкой Google. Для этого ему нужен пароль. Каждые 30 секунд Google Authenticator генерирует шестизначный пароль, используя алгоритм TOTP (Time-based One Time Password – одноразовый пароль на основе времени). Боб использует пароль для входа на сайт.
3 и 4. Клиент отправляет пароль, введенный Бобом, на сервер для аутентификации. Служба аутентификации считывает секретный ключ из базы данных и генерирует шестизначный пароль, используя тот же алгоритм TOTP, что и клиент.

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

Может ли другое лицо получить секретный ключ?

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

Может ли хакер угадать шестизначный пароль?

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

Реальные системы

Технический стек Netflix

Диаграмма основана на исследованиях многих инженерных блогов Netflix и проектов с открытым исходным кодом.

Для разработки нативных мобильных приложений используется Swift и Kotlin, для разработки веб-приложений – React.

Для взаимодействия клиента и сервера используется GraphQL.

Для разработки сервисов бэкенда используется ZUUL, Eureka, фреймворк Spring Boot и другие технологии.

В качестве БД используются EV Cache, Cassandra, CockroachDB и другие.

Для сообщений и потоковой передачи данных используются Apache Kafka и Fink.

В качестве хранилища видео используются S3 и Open Connect.

Для обработки данных используются Flink и Spark. Данные визуализируются с помощью Tableau. Для обработки структурированной информации хранилища данных используется Redshift.

Для процессов, связанных с CI/CD, используются такие инструменты, как JIRA, Confluence, PagerDuty, Jenkins, Gradle, Chaos Monkey, Spinnaker, Atlas и другие.

Архитектура Twitter по состоянию на 2022 год

Это настоящая архитектура Твиттера. Она опубликована Илоном Маском и перерисована нами для лучшей читабельности.

Эволюция архитектуры Airbnb в течение последних 15 лет

Архитектура Airbnb прошла через 3 основных стадии:

Монолит (2008-2017)

Airbnb начинался как простая торговая площадка для гостиниц и гостей. Она была разработана с помощью Ruby on Rails в виде монолита.

Недостатки:

отсутствие постоянной команды разработчиков + бесхозный код
медленный деплой

Микросервисы (2017-2020)

Ключевые сервисы:

сервис получения данных
сервис бизнес-логики
сервис рабочих процессов
сервис агрегации UI (User Interface — пользовательский интерфейс)

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

Недостатки:

сотнями сервисов и зависимостей сложно управлять

Микро- и макросервисы (2020-настоящее время)

Гибридная модель микро- и макросервисов фокусируется на унификации API.

Монорепозиторий и микрорепозитории

Что лучше? Почему разные компании выбирают разные варианты?

Концепция монорепозитория не нова; Linux и Windows были разработаны с использованием этой концепции. Чтобы улучшить масштабируемость и скорость сборки, Google разработал специальную внутреннюю цепочку инструментов и строгие стандарты качества кодирования, чтобы обеспечить единообразие разработки и деплоя.

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

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

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

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

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

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

Микрорепозиторий может либо использовать собственный стандарт, либо принять общий стандарт, включив в него лучшие практики. Для сервиса он может масштабироваться быстрее, но качество кода может быть немного другим. Для управления микросервисами инженеры Google разработали Bazel, а Meta – Buck. Среди инструментов с открытым исходным кодом можно называть Nix, Lerna и другие.

С годами у микросервисов появилось больше поддерживаемых инструментов, включая Maven и Gradle для Java, NPM для NodeJS, CMake для C/C++ и другие.

Архитектура Stack Overflow

Какая архитектура реализована в Stack Overflow?

Если ваш ответ – локальные серверы и монолит, вы, скорее всего, провалите собеседование, но именно так оно и устроено!

Ожидание

Для разделения системы на небольшие компоненты используются микросервисы
у каждого сервиса своя база данных, активно используется кэш
сервисы сегментированы (sharded)
сервисы взаимодействуют друг с другом асинхронно через очереди сообщений
сервисы реализованы с использованием источников событий (Event Sourcing) с CQRS
широко используются распределенные системы, такие как итоговая согласованность (eventual consistency), теорема CAP etc.

Реальность

Stack Overflow обрабатывает весь трафик с помощью всего 9 локальных веб-серверов, и это монолит! Никакие облачные решения в нём не используются.

Почему Amazon Prime Video Monitoring перешел с бессерверной архитектуры на монолит? Как это может сэкономить 90% стоимости?

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

Что такое служба видеомониторинга Amazon Prime?

Сервису Prime Video необходимо следить за качеством тысяч прямых трансляций. Инструмент мониторинга автоматически анализирует потоки данных в режиме реального времени и выявляет проблемы с качеством, такие как повреждение блоков (block corruption), зависание видео и проблемы с синхронизацией. Это важный процесс для удовлетворения клиентов.

Мониторинг состоит из 3 компонентов: медиаконвертер, детектор дефектов и сервис уведомлений в реальном времени.

Недостатки старой архитектуры

Старая архитектура была основана на Amazon Lambda, который позволял быстро создавать сервисы. Однако использование архитектуры в больших масштабах было нерентабельным. Две самые дорогостоящие операции:

Рабочий процесс оркестрации – пошаговые функции (step functions) AWS взимают с пользователей плату за переходы состояний, а оркестрация выполняет несколько переходов состояний каждую секунду.
Передача данных между распределенными компонентами — промежуточные данные хранятся в Amazon S3, чтобы их можно было загрузить на следующем этапе. Чем больше объем данных, тем дороже загрузка.

Монолит экономит 90% стоимости

Монолитная архитектура предназначена для решения проблем стоимости. Компонентов по-прежнему 3, но медиаконвертер и детектор дефектов развертываются в одном процессе, что экономит затраты на передачу данных по сети. Удивительно, но изменение архитектуры привело к экономии средств на 90%!

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

Технический директор Amazon Вернер Фогельс сказал следующее: "Создание эволюционирующих программных систем – это стратегия, а не религия. Поэтому необходимо периодически непредвзято пересматривать архитектуру системы".

Бывший вице-президент Amazon по устойчивому развитию Адриан Кокрофт: "Команда Prime Video следовала по пути, который я называю "Сначала бессерверные"… Я не сторонник только бессерверных технологий".

Как Disney Hotstar удалось собрать 5 миллиардов смайлов во время турнира?

Клиенты отправляют смайлы через стандартные HTTP-запросы. Вы можете думать о Golang Service как о типичном веб-сервере. Golang выбран потому, что он хорошо поддерживает параллелизм. Потоки в Golang легкие.
Поскольку объем данных очень велик, в качестве буфера используется Kafka (брокер сообщений).
Смайлы агрегируются службой потоковой обработки под названием Spark. Он собирает данные каждые 2 секунды (интервал настраивается). В зависимости от интервала приходится идти на некоторые компромиссы. Более короткий интервал означает, что смайлы доставляются другим клиентам быстрее, но это также означает, что требуется больше вычислительных ресурсов.
Агрегированные данные записываются в другой Kafka.
Потребители PubSub (издатель/подписчик) извлекают агрегированные смайлы из Kafka.
Смайлы доставляются клиентам в режиме реального времени через инфраструктуру PubSub. Инфраструктура PubSub интересна. Hotstar рассмотрела следующие протоколы: Socketio, NATS, MQTT и gRPC и остановилась на MQTT.

Похожий подход к архитектуре применяется LinkedIn, который обрабатывает миллион лайков в секунду.

Как Discord хранит триллионы сообщений?

Эволюция хранения сообщений в Discord:

MongoDB ➡️ Cassandra ➡️ ScyllaDB.

В 2015 первая версия Discord была построена на основе одной реплики MongoDB. Примерно в ноябре 2015 MongoDB хранила 100 миллионов сообщений, и оперативная память больше не вмещала данные и индексы. Задержка стала непредсказуемой. Возникла необходимость переместить хранение сообщений в другую базу данных. Была выбрана Cassandra.

В 2017 у Discord было 12 узлов (nodes) Cassandra, на которых хранились миллиарды сообщений.

На начало 2022 было 177 узлов с триллионами сообщений. На этом этапе задержка стала непредсказуемой, а выполнение операций по техническому обслуживанию стало слишком дорогим.

Причин возникновения такой ситуации несколько:

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

ScyllaDB – это база данных, совместимая с Cassandra, написанная на C++. Discord изменил свою архитектуру, включив в нее монолитный API, сервис данных, написанный на Rust, и ScyllaDB в качестве основного хранилища данных.

Задержка чтения p99 в ScyllaDB составляет 15 мс по сравнению с 40-125 мс в Cassandra. Задержка записи p99 составляет 5 мс по сравнению с 5-70 мс в Cassandra.

Как работают прямые видеотрансляции на YouTube, TikTok Live или Twitch?

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

Вот что делает это возможным:

Необработанные (raw) видеоданные захватываются микрофоном и камерой. Данные передаются на сервер.
Видеоданные сжимаются и кодируются. Например, алгоритм сжатия разделяет фон и другие элементы видео. После сжатия видео кодируется в соответствии со стандартами, такими как H.264. Это сильно уменьшает размер видеоданных.
Закодированные данные делятся на мелкие части (чанки — chunks), обычно длиной в несколько секунд, поэтому для их загрузки или потоковой передачи требуется гораздо меньше времени.
Сегментированные данные отправляются на сервер потоковой передачи (streaming server). Сервер потоковой передачи должен поддерживать различные устройства и условия сети. Это называется "адаптивной потоковой передачей битрейта" (Adaptive Bitrate Streaming). Это означает, что на шагах 2 и 3 необходимо создать несколько файлов с разным битрейтом.
Данные потоковой передачи в реальном времени передаются на пограничные серверы (edge servers), поддерживаемые CDN (Content Delivery Network – сеть доставки контента). Миллионы зрителей могут смотреть видео с ближайшего пограничного сервера. CDN значительно снижает задержку времени передачи данных.
Устройства зрителей декодируют и распаковывают видеоданные и воспроизводят видео в плеере.
7 и 8. Если видео необходимо сохранить для повторного воспроизведения, закодированные данные отправляются в хранилище, откуда впоследствии извлекаются без обращения к CDN.

Стандартные протоколы для прямой трансляции:

RTMP (Real-Time Messaging Protocol – протокол обмена сообщениями в реальном времени) – изначально был разработан Macromedia для передачи данных между Flash-плеером и сервером. Теперь он используется для потоковой передачи видеоданных через Интернет. Обратите внимание, что приложения для видеоконференций, такие как Skype, используют протокол RTC (Real-Time Communication – связь в реальном времени) для снижения задержки.
HLS (HTTP Live Streaming — прямая трансляция по HTTP) — этот протокол требует кодировки данных в H.264 или H.265. Устройства Apple поддерживают только это протокол
DASH (Dynamic Adaptive Streaming over HTTP – динамическая адаптивная потоковая передача данных через HTTP)

И HLS, и DASH поддерживают потоковую передачу с адаптивным битрейтом.

Теги:

Хабы:

Оригинальная ссылка: System Design 101 / Хабр (habr.com)

SQL

2024-06-13T12:59:19.344Z

Оглавление

DDL (Data Definition Language)

CREATE: Создаёт новые таблицы, базы данных, индексы и другие объекты базы данных

ALTER: Изменяет структуру существующих таблиц, например, добавляет новые столбцы, изменяет тип данных столбца, удаляет столбцы и т.д.

DROP: Удаляет существующие объекты базы данных

TRUNCATE: Удаляет все записи из таблицы, не удаляя саму таблицу

DML (Data Manipulation Language)

SELECT
INSERT
UPDATE
JOIN

DCL (Data Control Language)

TCL (Transaction Control Language)

Объектно-ориентированное программирование

2024-04-21T16:13:23.378Z

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

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

Эта статья — попытка рассказать о объектно-ориентированном программировании доступно, для тех, кто не имеет специализированного образования.

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

Абстракция
Инкапсуляция
Полиморфизм
Наследование

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

Классы в ООП

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

Что такое класс?

Класс — это как чертеж или шаблон, который описывает, как объекты должны быть созданы.

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

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

Думаю, текст выше может быть немного непонятным, поэтому давайте рассмотрим это на очень простом примере:

Представим, что класс — это как кулинарный рецепт для блюда. Рецепт описывает, какие ингредиенты вам понадобятся и что вам нужно делать, чтобы приготовить блюдо. Однако сам рецепт не содержит ингредиентов — это просто инструкции. То есть, рецепт сам по себе не имеет никакого вкуса и не может быть съеден.

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

По другому объект в ООП часто называют "Экземпляр класса"

И снова пример, чтобы было понятно:

Если у вас есть класс Car, который определяет, что у автомобиля должны быть такие свойства, как марка, модель и цвет, и методы, например, start() и stop(), то когда вы создаёте конкретный автомобиль из этого класса, например, красный Ford Mustang, вы создаёте объект или экземпляр класса Car.

Этот объект (Car) будет иметь конкретные значения для своих свойств
марка: Ford,
модель: Mustang,
цвет: красный
и сможет выполнять действия, определённые методами класса (запускаться и останавливаться. Ну, или что вы еще определите при создании класса Car ).

Тем, кому интересно, как создание класса выглядит в коде Python, пример ниже:

class Car: # создаем класс Автомобиль
    def __init__(self, color, brand):
        self.color = color  # цвет автомобиля
        self.brand = brand  # марка автомобиля

    def drive(self):
        print(f"The {self.color} {self.brand} is driving.")

А вот код на Python для создания экземпляра класса на основе определенного выше класса Car:

# Создание объекта класса Car
my_mustang = Car("red", "Ford Mustang")

# Теперь можно вызвать метод drive, чтобы "поездить" на машине
my_mustang.drive()

my_mustang это переменная, которая хранит ссылку на новый объект класса Car.
Car("red", "Ford Mustang") создает новый экземпляр класса Car с цветом "red" и маркой "Ford Mustang".
Вызов my_mustang.drive() запустит выполнение метода drive, который определен в классе Car, и выведет сообщение "The red Ford Mustang is driving."

В диаграмме классов UML это будет выглядет вот так:

Класс Car и созданный от него объек. Связь - ассоциация.

Существует еще одно понятие класса - Абстрактный класс, которое я сейчас разберу и мы вернемся к принципам ООП.

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

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

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

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

Ниже диаграмма классов, которая показывает абстрактный класс Vehicle, наследуемые подклассы Car и Motorcycle, и объет класса Car - Toyota, и объект класса Motorcycle - HarleyDavidson.

Диаграмма классов.

Кстати, в этом примере образования подклассов от абстракного класса мы познакомились с одним из принципов ООП - наследованием.
А теперь подробнее.

Наследование

Наследование в программировании — это когда один класс берет свойства и функциональность от другого класса, и может добавлять или изменять их.
Снова примеры:
Автомобили:
Представь, что у нас есть базовый класс "Автомобиль", который имеет свойства как "скорость", "цвет" и "количество колес". Теперь, если мы хотим создать спортивный автомобиль, мы просто "наследуем" все эти свойства от базового автомобиля и добавляем новые характеристики, например, "спойлер" или "турбонаддув".

Животные:
Если у нас есть базовый класс "Животное" с свойствами "еда", "способы передвижения", и "окрас", мы можем создать подкласс "Птица", который наследует все эти свойства и добавляет новые, как "летает" или "имеет перья".

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

Сладости:
У нас есть базовый класс "Сладость" с характеристиками "вкус", "цвет" и "форма". Мы можем создать подкласс "Конфета", который наследует эти характеристики и добавляет новые, например, "жевательная" или "с начинкой".

Абстракция

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

Тут можно вспомнить создание абстрактного класса, про который говорилось выше, а можно посмотреть на примеры ниже:

В системе оплаты, например в интернет-магазине, абстракция может использоваться для упрощения процесса оплаты.
Вместо того чтобы каждый раз подробно описывать процесс взаимодействия с различными платежными системами (кредитные карты, электронные деньги, банковские переводы и т.д.), вы можете создать абстрактный класс "Оплата", который будет иметь общий метод "произвести оплату".
Конкретные классы (подклассы от абстрактного класса "Оплата"), такие как "ОплатаКартой" или "ЭлектронныеДеньги", будут реализовывать этот метод по-разному, но пользователь интерфейса системы будет работать с этими методами через общий интерфейс, не вдаваясь в детали каждой платежной системы.

Полиморфизм

Полиморфизм в программировании — это принцип объектно-ориентированного программирования, который позволяет объектам разных типов обрабатываться как объекты одного типа.
Другими словами, это способность одного и того же метода работать по-разному в зависимости от того, к какому объекту он применяется.
Например, если мы определим метод "говорить" для класса "animal", то при реализации этого методами экземпляром класса "тигр", мы получим рычание, а в случае класса "кот" - мяукание.

Это наверное самый простой принцип для понимания.
Однако еще одна ремарка, чтобы не перепутать абстракцию и полиморфизм:

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

Инкапсуляция

Еще один простой принцип ООП.

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

Другой пример:

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

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

Пример инкапсуляции в банковском проекте:

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

Банковский счет (класс): Это класс в нашей программе, который хранит все детали счета клиента. Атрибуты (свойства) класса, такие как баланс счета и номер счета, делаются приватными. Это означает, что они не могут быть изменены напрямую извне класса; они могут быть доступны только через методы (функции) этого класса.
Публичные методы: Чтобы взаимодействовать с данными счета, мы предоставляем публичные методы, такие как получитьБаланс(), внестиДеньги(сумма) и снятьДеньги(сумма). Эти методы управляют данными безопасно, обеспечивая, например, что не будет снято больше денег, чем есть на счету.
Приватные методы: Могут быть и приватные методы, например, для внутренних расчетов или для проверки условий перед выполнением транзакции. Эти методы не доступны извне класса, что повышает безопасность.

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

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

На этом все. Надеюсь, у меня получилось.

Personas

2024-03-03T16:39:07.172Z

Оглавление

A user persona is a semi-fictional character based on your current (or ideal) customer.

CJM

CJM 2

Stakeholders

2024-03-03T16:03:18.131Z

Customers: The direct user of a product or service, often both internal and external to the company executing the project
Project manager: The project's leader
Project team members: The group executing the project under the project manager's leadership
Project sponsor: The project's financier
Steering committee: An advisory group providing guidance on key decisions, which includes the sponsor, executives, and key stakeholders from the organization
Executives: The top management in the company executing the project; those who direct the organization's strategy
Resource managers: Other managers who control resources needed for executing the project

There are many more examples of project stakeholders, including: sellers/suppliers, contractors, owners, government agencies, media outlets, and even society at large.

What is a Stakeholder Engagement Plan?

A stakeholder engagement plan is a formal document which outlines the plan to communicate with stakeholders who hold interest or potential interest in a project. A stakeholder engagement plan identifies potential stakeholders, their interest levels, power and influence and is continuingly updated to meet stakeholder needs.

What is covered in a stakeholder management plan?

The primary components of a stakeholder management plan are:

Prioritization of stakeholders: Rank stakeholders based on their ability to influence your project and how much they care about its outcome.
Stakeholder expectations: You cannot manage expectations if you don’t know what they are. You must document everything, including how they prefer to communicate and what they want to be involved with.
Communication rules: The plan should outline the level, frequency, and type of communication with each stakeholder as well as who on the team is their point of contact.
Action plans: This is the meat of your plan — It’s where you outline how you will manage stakeholder involvement and what steps to take to ensure expectations are met.

Top tips for how creating a stakeholder management plan

Here are eight tips for how to create the perfect stakeholder management plan:

Use a template: A stakeholder management template guide or a pre-built RACI template will save you time creating your plan, ensure no information fields are overlooked, and create consistency, as every stakeholder plan in your company will look the same.
Start early: Key stakeholders can influence your project before it’s even off the ground. Identifying and involving stakeholders early can make all the difference to their level of engagement and your success.
Update regularly: Stakeholders change throughout your project. Some may leave positions while others may join. Plus, their level of engagement and expectations may evolve as time goes on. Review your plan at least monthly to ensure it’s up-to-date.
Ensure transparency: Transparency builds trust, and when you have your stakeholders’ trust, you’re much more likely to have their cooperation and support. When creating your communication guidelines in your plan, keep in mind that open, frequent, two-way communication creates project transparency.
Make priority clear: Including a grid or matrix of stakeholders based on interest and influence can help you quickly see and understand where to focus your efforts.
Be concise: For your plan to be successful, you need to get to the root of what people care about and document it in concise, easy-to-understand terms that anyone who reads it can grasp.
Plan for conflict: You will inevitably have stakeholders with conflicting needs. Be proactive about how you will resolve issues and document this approach in your plan so that everyone is aware of it beforehand.
Publish it: Your stakeholder management plan shouldn’t be a secret. Store it somewhere accessible and share it with stakeholders. Not only does this increase transparency, but it also helps ensure no stakeholders or key factors were overlooked.

5 Levels of Stakeholder Engagement

Unaware – Not aware of the project and the impacts of the project
Resistant – Aware of the project and resistant to change
Neutral – Aware of the project and neither supports or resists
Supportive – Aware of the project and supportive of change
Leading – Aware of the project and impact and actively engaged in ensuring the project is a success

Класификация стейкхолдеров:

http://requirements.ru/lections_16#162

Customer Journey Map - главный инструмент проектировщика услуг

2024-02-25T17:37:32.566Z

Введение

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

Приведу пример популярной услуги — прослушивание музыки. Я слушаю музыку на персональном компьютере под управлением OS X, на смартфоне (iOS), и на Apple TV. Компания Apple довольно хорошо продумала процесс потребления музыки: я могу купить альбом на своем iPhone, а затем могу этот альбом прослушать на Apple TV, к которому у меня подключены большие колонки. Однако, я не могу начать слушать некую композицию на iPhone, а затем продолжить прослушивание на Apple TV — для этого мне приходится искать нужный альбом в меню Apple TV, эту процедуру простой не назовешь. То есть, в компании Apple никто не озаботился такой возможностью и не реализовал её. При этом, как дизайнер iPhone, так и дизайнер Apple TV хорошо сделали свою работу. Функционал, который мне нужен находится на границе двух устройств и, непонятно, кто должен отвечать за проектирование таких связок.

Данный пример показывает, что в наше время недостаточно продумывать в деталях пользовательский интерфейс одного цифрового продукта в отрыве от взаимодействия с другими продуктами, с которыми они находятся в единой инфраструктуре. Нужен такой инструмент, который позволяет выявлять проблемы на стыках, а также позволяет проектировать связки между продуктами. Как обычно потребность спровоцировала создание новой чудесной методики, которая называется «Customer Journey Map».

Customer Journey Map это, пожалуй, лучший инструмент User Experience, за последние 10 лет (после персонажей).

Что такое услуга?

Что такое услуга? Для любителей строгих определений приведу цитату из ГОСТ-9000-2008:

Услуга — результат, по меньшей мере, одного действия, обязательно осуществленного при взаимодействии поставщика и потребителя, и, как правило, нематериальна.

Давайте запомним слово «результат» — это то, что наиболее важно для любого потребителя.

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

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

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

Что такое Customer Journey Map?

Итак, что такое Customer Journey Map (для сокращения далее просто CJM)?

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

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

Вот примеры типичных CJM (пока обращайте внимание только на внешнюю сторону диаграммы):

customerexperienceplanning.com

thebridge.nl

Давайте посмотрим на упрощенный пример CJM:

Mel Edwards, 2011

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

Mel Edwards, 2011 & Alexey Kopylov, 2013

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

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

Mel Edwards, 2011 & Alexey Kopylov, 2013

Давайте проиллюстрирую это простым примером: многие интернет магазины требуют пройти процедуру регистрации и, зачастую, имеется такой шаг, как подтверждение регистрации специальной по ссылке, которая приходит на ваш почтовый ящик (это нужно, чтобы доказать, что регистрируется живой человек, а не робот). В этом случае повышается вероятность, что пользователь не сможет пройти этот шаг: возможно письмо со ссылкой попало в спам, возможно пользователь ошибся и вместо gmail.com ввел gmail.ru или другой несуществующий адрес, возможно он вообще забыл, что нужно было подтвердить регистрацию. В известных мне примерах потери пользователей на этом шаге достигали 70%!

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

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

Вспомним пример с прослушиванием музыки. На самом деле у Apple есть способ обеспечивающий переход от прослушивания на iPhone к прослушиванию на Apple TV, а именно технология AirPlay. Однако не все потребители знают о волшебной технологии и поэтому не могут ею воспользоваться. Есть правило, что функционал который пользователи не могут найти для них как бы не существует. Можно было бы так реализовать принцип «тяни-толкай»: как только пользователь оказывается в зоне, где доступен Apple TV, то сразу получает сообщение (не прерывающее прослушивание), что он может включить аудиосистему (подключенную к Apple TV) и продолжить прослушивание уже на ней. И наоборот, как только пользователь включает ТВ, он видит сообщение, какая композиция проигрывается на iPhone и что нужно сделать, чтобы перенаправить звук на аудиосистему (нажатием на одну кнопку).

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

Задачи, решаемые CJM

Перечислю все задачи, которые решает CJM:

Создание непрерывного UX на протяжении всего потребления услуги.
Вспомните вышеупомянутый «тяни-толкай».
Увеличение конверсии потребителей.
За счет снижения барьеров, а также за счет уменьшения потерь при переходе от точки контакта к точке контакта, до цели доходит больше потребителей.
Повышение лояльности потребителей.
Retention rate — количество возвращающихся потребителей растет, если мы спроектировали и реализовали услугу без барьеров.
Повышение ответственности специалистов компании.
У каждой точки взаимодействия есть свои ответственные работники со стороны компании. После того, как мы нанесли все точки взаимодействия на карту, все работники в компании могут видеть, кто и за что отвечает и как справляется со своими обязанностями (если настроим KPI для каждой точки). Это само по себе повышает уровень ответственности.
Ускорение разработки многоканальных услуг и продуктов и повышение качества разработки.
За счет того, что все стороны, участвующие в разработке, более полно видят как осуществляется услуга, а также видят все потенциальные слабые места услуги и могут вовремя вмешаться в их разработку.
Создание новых захватывающих взаимодействий.
Появляется возможность придумать и реализовывать новые инновационные возможности (вспомните пример про продолжение прослушивания аудиозаписи при переходе от одного устройства к другому).

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

Создаем CJM, пошаговая инструкция

Шаг №1. Идентифицируем все точки контакта и каналы взаимодействия

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

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

Запомните, что для одной целевой группы (или для одного персонажа, если вы используете методику персонажей) рисуется одна CJM диаграмма!

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

Графически CJM может иметь различный вид — диаграмм может быть линейной, если характер взаимодействия с потребителями также является линейным:

desonance.wordpress.com

Может быть разветвленный, если у потребителей имеются множественные альтернативные сценарии взаимодействия:

Alexey Kopylov, 2013

Может иметь временной вид — годится для отображения взаимодействия с услугой в течение суток:

customerexperienceplanning.com

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

Шаг №2. Описываем точки контакта

Теперь каждую точку контакта и каждый канал необходимо описать.

Вот типичная информация, которую мы должны зафиксировать:

Канал взаимодействия
У точек может быть несколько каналов, перечисляем все каналы.
Целевое действие, сценарий, критерии успеха
Описываем, чего потребитель хочет добиться при данном взаимодействии. Также описываем как проистекает идеальный сценарий взаимодействия, а также, что нужно делать, если у потребителя возникли проблемы. Описываем конкретные критерии успеха прохождения сценария — это нам необходимо для сбора статистики качества прохождения каждой точки контакта.
Степень критичности точки/канала
Помогает концентрироваться на самых критичных точках.
Барьеры
Перечисляем все проблемы, с которыми могут столкнуться потребители внутри данной точки взаимодействия.
Способы снижения барьеров
Для каждого барьера определяем контрмеры, которые мы должны реализовать при оптимизации услуги. Например, как в моем примере подтверждения регистрации, мы можем контролировать, какие email’ы вводит потребитель и предлагать исправлять ошибки в написании адреса.
Конверсия и ROI оптимизации
Считаем количество пришедших в данную точку потребителей к количеству успешно достигших следующей точки взаимодействия. Идеально, если все потребители пришли к следующей точке (коэффициент = 1.0). Это главный KPI точки взаимодействия и работника компании, который это взаимодействие реализует. Конверсия позволит вам посчитать экономический эффект от снижения того или иного барьера. Например, вы можете рассчитать, что снижение барьера внутри некоторой точки контакта приведет повышению конверсии на 20%. Прослеживая эти 20% далее по цепочке CJM и дойдя до момента, когда потребитель приносит деньги, вы сможете довольно точно определить, сколько денег принесет оптимизация данной точки. Если при этом вы еще оцените затраты на снижение барьера, то у вас появляется значение коэффициента ROI (возврат от инвестиций). Имея значение ROI вам будет довольно легко доказать топ-менеджерам выгоду такой оптимизации.
Другие KPI (например retention rate, время на контакт и так далее)
Мы можем придумать большое количество KPI, которые более полно характеризуют качество услуги в данной точке.
Психоэмоционально состояние, степень фрустрации и стресса
Эти данные мы можем получить просматривая жалобы потребителей или же с помощью качественных методов исследования (интервью, полевые наблюдения). Как и степень критичности точки контакта данная информация помогает сконцентрироваться на самых важных точках осуществления услуги.

Важный советПри описании точек контакта используйте лексику потребителей, а не вашу профессиональную.

Ниже на рисунке примеры описания точек взаимодействия. Я картировал программу лояльности одной нефтяной компании.

Alexey Kopylov, 2013

Шаг №3. Находим кто и за что отвечает внутри компании

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

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

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

Шаг №4. Оптимизируем самые критические точки/каналы

Берем самые критические точки взаимодействия и снижаем барьеры внутри этих точек.

Возьмем пример с нефтяной компанией — барьер №2 шага №3:

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

Также продумайте, смогли ли вы реализовать принцип «тяни-толкай» для мотивации потребителей при продвижении по CJM?

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

Alexey Kopylov, 2013

При оптимизации также можно использовать методику теории ограничений Э. Голдратта.

Шаг №5. Берем под контроль процесс оптимизации

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

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

Инструменты для создания CJM

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

Post-It листочки

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

Красивые схемы

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

Excel + схемы

Сейчас я работаю, используя два инструмента: Flying Logic для прорисовки диаграммы и Excel (или Google Docs) для ввода информации по каждой точке контакта. Flying Logic довольно хорошо подходит для таких диаграмм, так как изначально был сделан для построения схем теории ограничений, которая довольно хорошо сопрягается с CJM. Недостаток этого способа — приходится постоянно синхронизировать диаграмму и таблицу для того, чтобы информация была актуальной.

Alexey Kopylov, 2013

Веб сервис Touchpoint Dashboard

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

touchpointdashboard.com

Выглядит все это весьма симпатично, однако, стоимость сервиса выглядит так (в месяц):

touchpointdashboard.com

То есть:

$175 за 1 пользователя
$625 за 5
$950 за 10

На мой взгляд это пока еще слишком дорого для большинства команд — ждем появления конкурента, уверен, после этого стоимость снизится.

Итоги

Напоследок кратко перечислю выгоды от применения CJM при перепроектировании услуги:

CJM позволяет распространить знания о реальном положении дел с потребителями в вашей компании.
Помогает обратить внимание топ-менеджеров на вопиющие факты или потенциальные возможности для роста.
Помогает рассчитать ROI оптимизации CJM.
Способствует разработатке стратегию развития услуги и продуктов, которые в нее входят.
Улучшает коммуникации внутри компании.
Повышает уровень подготовки персонала (выходим за рамки чистого UX).
Улучшает организационную культуру вашей компании.
Самое главное: повышает качество услуги, что способствует лояльности ваших потребителей!

Оригинал статьи: https://copylove.medium.com/customer-journey-map-8a5ac61d6b5e

System Analysis

2024-01-17T09:47:17.973Z

Содержание основное
Оглавление подготовка к экзамену

Based on Andersenlab matrix

Application types

Need to know:

Knows types of software Knows the differences between each type of software Knows when and where each type of software is used.
Provides thick and thin client examples Knows all the advantages of each type of software.
Knows the peculiarities of the implementation of each type of software.

Resources:

1. Types guide https://www.coderus.com/software-101-a-complete-guide-to-the-different-types-of-software/

2. Types https://clevertap.com/blog/types-of-mobile-apps/

Main types: webapps, mobile apps, desktop apps.
Далее можно дробить на:

Application Software (Прикладное: Word, субд, медиа, почта и т.д.)
System Software (Windows, iOS, Linux, Android, Windows phone, Apple's iOS и т.д.)
Firmware (Firmware is software that’s stored on a computer’s motherboard or chipset.)
Programming Software (IDEs, Gitlab, Github, Visual Studio etc)
Driver Software (Driver software communicates with hardware and control devices and peripherals attached to a computer. Examples: graphic, network card, mouse, keyborad)
Freeware
Freeware sounds like free software or open-source software but there’s a difference. Freeware software does not expose or share its source code. Yet the software owner does not charge others to use it.
Freeware licences vary as to what the software can be used for and who can share it.
Some developers only allow their freeware for private or personal use. Businesses need a paid licence or get written permission.
Shareware
Like freeware, shareware is free to use and share with others, but only for a short time. It acts as an evaluation. You can try some or all of the features before committing to a purchase.
Open Source Software
Open source means you can explore the actual code that the app was written in. (Linux)
Closed Source Software
Most applications are closed source in that they do not expose the original code. Licences are stringent. No unauthorised copying or cracking is allowed. The app can be commercial or private but it requires payment of some kind to use.
Utility Software
Utility software is designed to analyse and optimise a device.

Мобильные приложение

Native apps are created for one specific platform or operating system.
Web apps are responsive versions of websites that can work on any mobile device or OS because they’re delivered using a mobile browser.
Hybrid apps are combinations of both native and web apps, but wrapped within a native app, giving it the ability to have its own icon or be downloaded from an app store.

Native:

Pros: Because of their singular focus, native apps have the advantage of being faster and more reliable in terms of performance. They’re generally more efficient with the device’s resources than other types of mobile apps. Native apps utilize the native device UI, giving users a more optimized customer experience.

And because native apps connect with the device’s hardware directly, they have access to a broad choice of device features like Bluetooth, phonebook contacts, camera roll, NFC, and more.

Cons: However, the problem with native apps lies in the fact that if you start developing them, you have to duplicate efforts for each of the different platforms. The code you create for one platform cannot be reused on another. This drives up costs. Not to mention the effort needed to maintain and update the codebase for each version.

And then, every time there’s an update to the app, the user has to download the new file and reinstall it. This also means that native apps do take up precious space in the device’s storage.

Web apps:

They’re actually responsive websites that adapt its user interface to the device the user is on. In fact, when you come across the option to “install” a web app, it often simply bookmarks the website URL on your device.

Pros: Because it’s web-based, there is no need to customize to a platform or OS. This cuts down on development costs.
Plus, there’s nothing to download. They won’t take up space on your device memory like a native app, making maintenance easier – just push the update live over the web. Users don’t need to download the update at the app store.

Cons: But this is also pertinent: web apps are entirely dependent on the browser used on the device. There will be functionalities available within one browser and not available on another, possibly giving users varying experiences.
And because they’re shells for websites, they won’t completely work offline. Even if they have an offline mode, the device will still need an internet connection to back up the data on your device, offer up any new data, or refresh what’s on screen.
(google maps, Twitter lite, etc)

Hybrid

These are web apps that look and feel like native apps. They might have a home screen app icon, responsive design, fast performance, even be able to function offline, but they’re really web apps made to look native.

Pros: Building a hybrid app is much quicker and more economical than a native app. As such, a hybrid app can be the minimum viable product – a way to prove the viability of building a native app. They also load rapidly, are ideal for usage in countries with slower internet connections, and give users a consistent user experience. Finally, because they use a single code base, there is much less code to maintain.

Cons: Hybrid apps might lack in power and speed, which are hallmarks of native apps.

Гибридное приложение – это вид мобильного приложения, которое сочетает в себе элементы нативных и веб-приложений. Оно разработано с использованием веб-технологий (например, HTML, CSS, JavaScript), но упаковано таким образом, чтобы работать как нативное приложение на мобильном устройстве. Это позволяет ему взаимодействовать с нативными функциями устройства, такими как камера, датчики, сохраненные данные и т.д.
Вот несколько примеров гибридных приложений:
Instagram: Одно из самых популярных гибридных приложений, использующее веб-технологии для обеспечения плавного пользовательского опыта.
Uber: Приложение Uber для пользователей является гибридным, что обеспечивает быструю и эффективную работу на разных платформах.
Twitter: Это еще один пример гибридного приложения, которое обеспечивает высокую производительность и плавность интерфейса.
Gmail: Gmail также использует гибридный подход, чтобы предоставить пользователям удобный и функциональный интерфейс.

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

Types of Mobile Apps: How to Choose Just One

How to find flaws in the selected type of software:

Тестирование Производительности: Это включает в себя нагрузочное тестирование и стресс-тестирование для проверки, как приложение справляется с большими объемами трафика и давлением.
Тестирование Уязвимостей: Особенно важно для веб-приложений и гибридных приложений, которые могут быть подвержены веб-специфическим угрозам, таким как XSS (Cross-Site Scripting), CSRF (Cross-Site Request Forgery) и SQL-инъекции.
Юзабилити Тестирование (Тестирование Удобства Использования): Проверка на интуитивно понятный и удобный пользовательский интерфейс, особенно важно для мобильных приложений, где ограничен размер экрана.
Тестирование Совместимости: Особенно важно для гибридных и веб-приложений, чтобы убедиться, что они работают корректно на различных устройствах, браузерах и операционных системах.
Тестирование Безопасности: Включает в себя проверку на утечки данных, неправильное управление доступом, и другие потенциальные уязвимости безопасности.
Код Ревью: Анализ исходного кода на предмет потенциальных уязвимостей, плохих практик программирования и неэффективного использования ресурсов.
Автоматизированное Тестирование: Использование инструментов для автоматического тестирования кода и интерфейса может помочь в обнаружении ошибок, которые могли быть упущены в ручном тестировании.
Пользовательское Тестирование: Получение обратной связи от реальных пользователей может выявить проблемы, которые не были замечены разработчиками и тестировщиками.

Вверх

Operating systems

Knows types of OS Knows the general characteristics of each type of OS
Knowledge of virtualization tools Knowledge of mobile application emulators
Able to run a virtual machine Able to run a mobile application on a work computer

Resources:

1. Operation systems https://www.geeksforgeeks.org/types-of-operating-systems/
2. File system https://en.wikipedia.org/wiki/File_system
3. Virtual machine https://www.vmware.com/topics/glossary/content/virtual-machine.html

Operating System is a type of software that works as an interface between the system program and the hardware.

1. Десктопные операционные системы:

Windows: Одна из самых популярных ОС в мире, разработанная Microsoft. Используется на персональных компьютерах, ноутбуках.
macOS: Разработана Apple Inc. и используется на компьютерах Mac. Известна своей удобной и интуитивно понятной интерфейсной системой.
Linux: Это семейство открытых и бесплатных операционных систем на базе ядра Linux. Существует множество дистрибутивов Linux, таких как Ubuntu, Fedora, Debian, которые подходят для разных типов пользователей.

2. Мобильные операционные системы:

Android: Разработана Google и является самой популярной мобильной ОС в мире. Используется на множестве устройств от различных производителей.
iOS: Операционная система от Apple, используемая на iPhone, iPad и iPod Touch.
HarmonyOS: Разработана китайской компанией Huawei для использования на различных устройствах, включая смартфоны, планшеты и умные домашние устройства.

3. Операционные системы для серверов:

Windows Server: Версия Windows, оптимизированная для серверов.
Ubuntu Server, CentOS, Red Hat Enterprise Linux (RHEL): Популярные дистрибутивы Linux, используемые на серверах.

4. Встроенные операционные системы:

RTOS (Real-Time Operating System): Операционные системы реального времени, используемые во встроенных системах, где требуются быстрые и предсказуемые времена реакции. Примеры включают FreeRTOS и VxWorks.
Embedded Linux: Версия Linux, оптимизированная для встроенных систем.

5. Специализированные и нишевые ОС:

Chrome OS: Разработана Google и используется в ноутбуках Chromebook. Основана на веб-приложениях и интеграции с сервисами Google.
Tizen: ОС, разработанная Linux Foundation и поддерживаемая Samsung, для использования во всем, от смарт-часов и телевизоров до смартфонов.

Types of Operating Systems

Batch Operating System: A Batch Operating System is a type of operating system that does not interact with the computer directly. There is an operator who takes similar jobs having the same requirements and groups them into batches.
Time-sharing Operating System: Time-sharing Operating System is a type of operating system that allows many users to share computer resources (maximum utilization of the resources).
Distributed Operating System: Distributed Operating System is a type of operating system that manages a group of different computers and makes appear to be a single computer. These operating systems are designed to operate on a network of computers. They allow multiple users to access shared resources and communicate with each other over the network. Examples include Microsoft Windows Server and various distributions of Linux designed for servers.
Network Operating System: Network Operating System is a type of operating system that runs on a server and provides the capability to manage data, users, groups, security, applications, and other networking functions.
Real-time Operating System: Real-time Operating System is a type of operating system that serves a real-time system and the time interval required to process and respond to inputs is very small. These operating systems are designed to respond to events in real time. They are used in applications that require quick and deterministic responses, such as embedded systems, industrial control systems, and robotics.
Multiprocessing Operating System: Multiprocessor Operating Systems are used in operating systems to boost the performance of multiple CPUs within a single computer system. Multiple CPUs are linked together so that a job can be divided and executed more quickly.
Single-User Operating Systems: Single-User Operating Systems are designed to support a single user at a time. Examples include Microsoft Windows for personal computers and Apple macOS.
Multi-User Operating Systems: Multi-User Operating Systems are designed to support multiple users simultaneously. Examples include Linux and Unix.
Embedded Operating Systems: Embedded Operating Systemsare designed to run on devices with limited resources, such as smartphones, wearable devices, and household appliances. Examples include Google’s Android and Apple’s iOS.
Cluster Operating Systems: Cluster Operating Systems are designed to run on a group of computers, or a cluster, to work together as a single system. They are used for high-performance computing and for applications that require high availability and reliability. Examples include Rocks Cluster Distribution and OpenMPI.

SQL

2023-12-26T18:05:37.217Z

Оглавление

Основные понятия реляционных баз данных
Отношение, реляционная модель
Создание таблицы
Вставка записи в таблицу
Выборка данных, вычисляемые столбцы, математические функции IF
Выборка данных, операторы BETWEEN, IN
Выборка данных с сортировкой ORDER BY
Выборка данных, оператор LIKE
Выбор уникальных элементов столбца DISTINCT и GROUP BY
Выборка данных, групповые функции SUM и COUNT
Выборка данных, групповые функции MIN, MAX и AVG
Вычисления по таблице целиком
Выборка данных по условию, групповые функции
Выборка данных по условию, групповые функции, WHERE и HAVING

Основные понятия реляционных баз данных

Реляционная модель была разработана в конце 1960-х годов Е.Ф.Коддом . Она определяет способ представления данных (структуру данных), методы защиты данных (целостность данных), и операции, которые можно выполнять с данными (манипулирование данными). Эта модель лежит в основе всех реляционных баз данных до настоящего времени.

Основные принципы реляционных баз данных:

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

Пример отношения:

На примере таблицы Сотрудник рассмотрим терминологию реляционных баз данных:

отношение – это структура данных целиком, набор записей (в обычном понимании – таблица) , в примере –это Сотрудник;
кортеж – это каждая строка , содержащая данные (более распространенный термин – запись ), например, <001, Борин С.А, 234-01-23, программист>, все кортежи в отношении должны быть различны;
мощность – число кортежей в таблице (проще говоря, число записей), в данном случае 3, мощность отношения может быть любой (от 0 до бесконечности), порядок следования кортежей - неважен;
атрибут – это столбец в таблице (более распространенный термин – поле ), в примере – Табельный номер, Фамилия И.О., Телефон, Должность)
размерность – это число атрибутов в таблице, в данном случае – 4;
размерность отношения должна быть больше 0, порядок следования атрибутов существенен;
домен атрибута – это допустимые значения (неповторяющиеся), которые можно занести в поле , например для атрибута Должность домен – {инженер, программист}.

Отношение, реляционная модель

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

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

Пример.

Рассмотрим некоторый склад, на котором хранятся книги. Известно название книги, ее автор, количество экземпляров на складе и ее цена.

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

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

1. Дать таблице имя, пусть она будет называться book, вот некоторые правила для выбора имен таблиц:

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

Также рекомендуется:

чтобы имя было существительным в единственном числе;
имя должно быть понятным и соответствовать тому объекту, который оно описывает;
имя должно быть как можно короче, максимум до 10 символов.

Важно. Имена таблиц являются регистрозависимыми из-за операционной системы на которой работает stepik, то есть имя book и Book – разные имена. Рекомендуется для записи имен таблиц использовать только строчные (маленькие) буквы.

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

title – поле для хранения названия книги;
author – поле с фамилией автора книги ;
priсe – цена книги;
amount – количество книг.

Правила по выбору имени поля информационного объекта:

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

Рекомендации по выбору имени поля информационного объекта:

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

3. Включить ключевое поле book_id, которое является ОБЯЗАТЕЛЬНЫМ ЭЛЕМЕНТОМ каждой реляционной таблицы. Ключевое поле является уникальным для каждой записи, однозначно определяет запись и в дальнейшем будет использоваться для связей с другими таблицами.

Рекомендации по именованию ключевых полей:

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

Таким образом, наша таблицаbookбудет выглядеть следующим образом:

Создание таблицы

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

ключевые слова : CREATE TABLE
имя создаваемой таблицы;
открывающая круглая скобка «(»;
название поля и его описание, которое включает тип поля и другие необязательные характеристики;
запятая;
название поля и его описание;
...
закрывающая скобка «)».

Пример. Создадим таблицу genre следующей структуры:

Созданная таблица - пустая.

Рекомендации по записи SQL запроса

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

Вставка записи в таблицу

Для занесения новой записи в таблицу используется SQL запрос, в котором указывается в какую таблицу, в какие поля заносить новые значения. Структура запроса:

ключевые слова INSERT INTO (ключевое слово INTO можно пропустить);
имя таблицы, в которую добавляется запись;
открывающая круглая скобка «(»;
список полей через запятую, в которые следует занести новые данные;
закрывающая скобка «)»;
ключевое слово VALUES;
открывающая круглая скобка «(»;
список значений через запятую, которые заносятся в соответствующие поля, при этом текстовые значения заключаются в кавычки, числовые значения записываются без кавычек, в качестве разделителя целой и дробной части используется точка;
закрывающая скобка «)».

Пример. В таблицу, состоящую из двух столбцов добавим новую строку, при этом в поле1 заносится значение1, в поле2 - значение2.

INSERT INTO таблица(поле1, поле2) 
VALUES (значение1, значение2);

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

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

количество полей и количество значений в списках должны совпадать;
должно существовать прямое соответствие между позицией одного и того же элемента в обоих списках, поэтому первый элемент списка значений должен относиться к первому столбцу в списке столбцов, второй – ко второму столбцу и т.д.;
типы данных элементов в списке значений должны быть совместимы с типами данных соответствующих столбцов таблицы ( целое число можно занести в поле типа DECIMAL, обратная операция - недопустима);
новые значения нельзя добавлять в поля, описанные как PRIMARY KEY AUTO_INCREMENT;
рекомендуется заполнять все поля записи, если же поле пропущено, значение этого поля зависит от установленных по умолчанию значений, если значения не установлены - на данной платформе вставляется пустое значение (NULL).

Пример

Вставим новую запись в таблицу genre, созданную на предыдущем шаге ( в первых двух строках показана структура таблицы, далее - ее содержимое):

Запрос:

INSERT INTO genre (name_genre) VALUES ('Роман');

Задание

Занесите новую строку в таблицу book (текстовые значения (тип VARCHAR) заключать либо в двойные, либо в одинарные кавычки):

Решение:

INSERT book (title,author,price,amount)
VALUES ('Мастер и Маргарита', 'Булгаков М.А.', 670.99,3);
SELECT * from book

Решение для нескольких строк:

INSERT book (title, author, price, amount)
VALUES ('Белая гвардия', 'Булгаков М.А.',540.50,5);
INSERT book (title, author, price, amount)
VALUES ('Идиот', 'Достоевский Ф.М.', 460.00,10);
INSERT book (title, author, price, amount)
VALUES('Братья Карамазовы', 'Достоевский Ф.М.',799.01,2);

Выборка данных, вычисляемые столбцы, математические функции IF

В SQL реализована возможность заносить в поле значение в зависимости от условия. Для этого используется функция IF():

IF(логическое_выражение, выражение_1, выражение_2)

Функция вычисляет логическое_выражение, если оно истина – в поле заносится значение выражения_1, в противном случае – значение выражения_2. Все три параметра IF() являются обязательными.

Допускается использование вложенных функций, вместо выражения_1 или выражения_2 может стоять новая функция IF.

Пример

Для каждой книги из таблицы book установим скидку следующим образом: если количество книг меньше 4, то скидка будет составлять 50% от цены, в противном случае 30%.

Запрос:

SELECT title, amount, price, 
    IF(amount<4, price*0.5, price*0.7) AS sale
FROM book;

Результат:

+-----------------------+--------+--------+---------+
| title                 | amount | price  | sale    |
+-----------------------+--------+--------+---------+
| Мастер и Маргарита    | 3      | 670.99 | 335.495 |
| Белая гвардия         | 5      | 540.50 | 378.350 |
| Идиот                 | 10     | 460.00 | 322.000 |
| Братья Карамазовы     | 2      | 799.01 | 399.505 |
| Стихотворения и поэмы | 15     | 650.00 | 455.000 |
+-----------------------+--------+--------+---------+

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

SELECT title, amount, price, 
    ROUND(IF(amount<4, price*0.5, price*0.7),2) AS sale
FROM book;

Результат:

+-----------------------+--------+--------+--------+
| title                 | amount | price  | sale   |
+-----------------------+--------+--------+--------+
| Мастер и Маргарита    | 3      | 670.99 | 335.50 |
| Белая гвардия         | 5      | 540.50 | 378.35 |
| Идиот                 | 10     | 460.00 | 322.00 |
| Братья Карамазовы     | 2      | 799.01 | 399.51 |
| Стихотворения и поэмы | 15     | 650.00 | 455.00 |
+-----------------------+--------+--------+--------+

Пример

Усложним вычисление скидки в зависимости от количества книг. Если количество книг меньше 4 – то скидка 50%, меньше 11 – 30%, в остальных случаях – 10%. И еще укажем какая именно скидка на каждую книгу.

Запрос:

SELECT title, amount, price,
    ROUND(IF(amount < 4, price * 0.5, IF(amount < 11, price * 0.7, price * 0.9)), 2) AS sale,
    IF(amount < 4, 'скидка 50%', IF(amount < 11, 'скидка 30%', 'скидка 10%')) AS Ваша_скидка
FROM book;

Результат:

+-----------------------+--------+--------+--------+-------------+
| title                 | amount | price  | sale   | Ваша_скидка |
+-----------------------+--------+--------+--------+-------------+
| Мастер и Маргарита    | 3      | 670.99 | 335.50 | скидка 50%  |
| Белая гвардия         | 5      | 540.50 | 378.35 | скидка 30%  |
| Идиот                 | 10     | 460.00 | 322.00 | скидка 30%  |
| Братья Карамазовы     | 2      | 799.01 | 399.51 | скидка 50%  |
| Стихотворения и поэмы | 15     | 650.00 | 585.00 | скидка 10%  |
+-----------------------+--------+--------+--------+-------------+

Задание

При анализе продаж книг выяснилось, что наибольшей популярностью пользуются книги Михаила Булгакова, на втором месте книги Сергея Есенина. Исходя из этого решили поднять цену книг Булгакова на 10%, а цену книг Есенина - на 5%. Написать запрос, куда включить автора, название книги и новую цену, последний столбец назвать new_price. Значение округлить до двух знаков после запятой.

Исходная таблица:

Решение:
SELECT
    author,
    title,
    CASE
        WHEN author = 'Булгаков М.А.' THEN ROUND(price * 1.10, 2)
        WHEN author = 'Есенин С.А.' THEN ROUND(price * 1.05, 2)
        ELSE price
    END AS new_price
FROM
    book;

Результат:

Выборка данных, операторы BETWEEN, IN

Логическое выражение после ключевого слова WHERE может включать операторы BETWEEN и IN. Приоритет у этих операторов такой же как у операторов сравнения, то есть они выполняются раньше, чем NOT, AND, OR.

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

Пример

Выбрать названия и количества тех книг, количество которых от 5 до 14 включительно.

Запрос:

SELECT title, amount 
FROM book
WHERE amount BETWEEN 5 AND 14;

Результат:

+---------------+--------+
| title         | amount |
+---------------+--------+
| Белая гвардия | 5      |
| Идиот         | 10     |
+---------------+--------+

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

SELECT title, amount 
FROM book
WHERE amount >= 5 AND amount <=14;

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

Пример

Выбрать названия и цены книг, написанных Булгаковым или Достоевским.

Запрос:

SELECT title, price 
FROM book
WHERE author IN ('Булгаков М.А.', 'Достоевский Ф.М.');

Результат:

+--------------------+--------+
| title              | price  |
+--------------------+--------+
| Мастер и Маргарита | 670.99 |
| Белая гвардия      | 540.50 |
| Идиот              | 460.00 |
| Братья Карамазовы  | 799.01 |
+--------------------+--------+

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

SELECT title, price 
FROM book
WHERE author = 'Булгаков М.А.' OR author = 'Достоевский Ф.М.';

Выборка данных с сортировкой ORDER BY

При выборке можно указывать столбец или несколько столбцов, по которым необходимо отсортировать отобранные строки. Для этого используются ключевые слова ORDER BY, после которых задаются имена столбцов. При этом строки сортируются по первому столбцу, если указан второй столбец, сортировка осуществляется только для тех строк, у которых значения первого столбца одинаковы. По умолчанию ORDER BY выполняет сортировку по возрастанию. Чтобы управлять направлением сортировки вручную, после имени столбца указывается ключевое слово ASC (по возрастанию) или DESC (по убыванию).

Столбцы после ключевого слова ORDER BY можно задавать:

названием столбца;
номером столбца;
именем столбца (указанным после AS).

Пример

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

Запрос:

SELECT title, author, price
FROM book
ORDER BY title;

Результат:

+-----------------------+------------------+--------+
| title                 | author           | price  |
+-----------------------+------------------+--------+
| Белая гвардия         | Булгаков М.А.    | 540.50 |
| Братья Карамазовы     | Достоевский Ф.М. | 799.01 |
| Идиот                 | Достоевский Ф.М. | 460.00 |
| Мастер и Маргарита    | Булгаков М.А.    | 670.99 |
| Стихотворения и поэмы | Есенин С.А.      | 650.00 |
+-----------------------+------------------+--------+

Аналогичный результат получится при использовании запроса:

SELECT title, author, price
FROM book
ORDER BY 1;

Пример

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

Запрос:

SELECT author, title, amount AS Количество
FROM book
WHERE price < 750
ORDER BY author, amount DESC;

Результат:

+------------------+-----------------------+------------+
| author           | title                 | Количество |
+------------------+-----------------------+------------+
| Булгаков М.А.    | Белая гвардия         | 5          |
| Булгаков М.А.    | Мастер и Маргарита    | 3          |
| Достоевский Ф.М. | Идиот                 | 10         |
| Есенин С.А.      | Стихотворения и поэмы | 15         |
+------------------+-----------------------+------------+

Можно использовать другие варианты записи запроса:

SELECT author, title, amount AS Количество
FROM book
WHERE price < 750
ORDER BY author, Количество DESC;

SELECT author, title, amount AS Количество
FROM book
WHERE price < 750
ORDER BY 1, 3 DESC;

Важно! Если названия столбцов заключены в кавычки, то при использовании их в сортировке, необходимо записывать их БЕЗ КАВЫЧЕК.

Задание

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

Результат:

+------------------+--------------------+
| author           | title              |
+------------------+--------------------+
| Достоевский Ф.М. | Братья Карамазовы  |
| Достоевский Ф.М. | Идиот              |
| Булгаков М.А.    | Белая гвардия      |
| Булгаков М.А.    | Мастер и Маргарита |
+------------------+--------------------+

Выборка данных, оператор LIKE

Оператор LIKE используется для сравнения строк. В отличие от операторов отношения равно (=) и не равно (<>), LIKE позволяет сравнивать строки не на полное совпадение (не совпадение), а в соответствии с шаблоном. Шаблон может включать обычные символы и символы-шаблоны. При сравнении с шаблоном, его обычные символы должны в точности совпадать с символами, указанными в строке. Символы-шаблоны могут совпадать с произвольными элементами символьной строки.

Пример 1

Вывести названия книг, начинающихся с буквы «Б».

Запрос:

SELECT title 
FROM book
WHERE title LIKE 'Б%';
/* эквивалентное условие 
title LIKE 'б%'
*/

Результат:

+-------------------+
| title             |
+-------------------+
| Белая гвардия     |
| Братья Карамазовы |
+-------------------+

Пояснение

Пример 2

Вывести название книг, состоящих ровно из 5 букв.

Запрос:

SELECT title FROM book 
WHERE title LIKE "_____"

Результат:

+-------+
| title |
+-------+
| Идиот |
| Поэмы |
+-------+

Пояснение

Пример 3

Вывести книги, название которых длиннее 5 символов:

Запрос:

SELECT title FROM book 
WHERE title LIKE "______%";
/* эквивалентные условия 
title LIKE "%______"
title LIKE "%______%"
*/

Результат:

+-----------------------+
| title                 |
+-----------------------+
| Мастер и Маргарита    |
| Белая гвардия         |
| Братья Карамазовы     |
| Стихотворения и поэмы |
| Дети полуночи         |
| Лирика                |
| Капитанская дочка     |
+-----------------------+

Пояснение

Пример 4

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

Запрос:

SELECT title FROM book 
WHERE   title LIKE "_% и _%" /*отбирает слово И внутри названия */
    OR title LIKE "и _%" /*отбирает слово И в начале названия */
    OR title LIKE "_% и" /*отбирает слово И в конце названия */
    OR title LIKE "и" /* отбирает название, состоящее из одного слова И */

Результат:

+-----------------------+
| title                 |
+-----------------------+
| Мастер и Маргарита    |
| Стихотворения и поэмы |
+-----------------------+

Пример 5

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

Запрос:

SELECT title FROM book 
WHERE title NOT LIKE "% %";

Результат:

+--------+
| title  |
+--------+
| Идиот  |
| Лирика |
| Поэмы  |
+--------+

Задание

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

Результат:

+-----------------------+-------------+
| title                 | author      |
+-----------------------+-------------+
| Капитанская дочка     | Пушкин А.С. |
| Стихотворения и поэмы | Есенин С.А. |
+-----------------------+-------------+

Решение:

SELECT title, author
FROM book
WHERE title LIKE '_% %'
    AND (author LIKE '% С.%' OR author LIKE "%С.%") 
ORDER BY title ASC;

Выбор уникальных элементов столбца DISTINCT и GROUP BY

Чтобы отобрать уникальные элементы некоторого столбца используется ключевое слово DISTINCT, которое размещается сразу после SELECT.

Пример

Выбрать различных авторов, книги которых хранятся в таблице book.

Запрос:

SELECT DISTINCT author
FROM book;

Результат:

+------------------+
| author           |
+------------------+
| Булгаков М.А.    |
| Достоевский Ф.М. |
| Есенин С.А.      |
+------------------+

Другой способ – использование оператора GROUP BY, который группирует данные при выборке, имеющие одинаковые значения в некотором столбце. Столбец, по которому осуществляется группировка, указывается после GROUP BY .

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

Запрос:

SELECT  author
FROM book
GROUP BY author;

Т.е. запрос

select title,Count(title)
 from book
 group by author

Запрос SELECT COUNT(title) FROM book GROUP BY author будет подсчитывать количество записей в столбце title для каждого уникального автора в таблице book.

Выборка данных, групповые функции SUM и COUNT

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

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

SELECT author, sum(amount), count(amount)
FROM book
GROUP BY author;

1. В таблице book определяются строки, в которых в столбце author одинаковые значения:

Получили 3 различные группы:

группа I объединяет две записи, у которых в столбце author значение Булгаков М.А.;
группа II объединяет три записи, у которых в столбце author значение Достоевский Ф.М.;
группа III объединяет одну запись, у которой в столбце author значение Есенин С.А.

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

3. Дальше можно выполнить вычисления над элементами КАЖДОЙ группы в отдельности, например, посчитать общее количество экземпляров книг каждого автора. Для этого используется групповая функция SUM(), а в скобках указывается столбец, по которому нужно выполнить суммирование ( в нашем случае amount):

4. Также можно посчитать, сколько записей относится к группе. Для этого используется функция COUNT(), в скобках можно указать ЛЮБОЙ столбец из группы, если группа не содержит пустых значений (ниже приведен пример, в котором показано, как работает COUNT(), если в группе есть пустые значения):

Пример

Посчитать, сколько экземпляров книг каждого автора хранится на складе.

Запрос:

SELECT author, SUM(amount)
FROM book
GROUP BY author;

Результат:

+------------------+-------------+
| author           | SUM(amount) |
+------------------+-------------+
| Булгаков М.А.    | 8           |
| Достоевский Ф.М. | 23          |
| Есенин С.А.      | 15          |
+------------------+-------------+

Пример

Посчитать, сколько различных книг каждого автора хранится на складе.

Только для этого примера в таблицу book добавлена запись с пустыми значениями в столбцах amount и price:

+---------+-----------------------+------------------+--------+--------+
| book_id | title                 | author           | price  | amount |
+---------+-----------------------+------------------+--------+--------+
| 1       | Мастер и Маргарита    | Булгаков М.А.    | 670.99 | 3      |
| 2       | Белая гвардия         | Булгаков М.А.    | 540.50 | 5      |
| 3       | Идиот                 | Достоевский Ф.М. | 460.00 | 10     |
| 4       | Братья Карамазовы     | Достоевский Ф.М. | 799.01 | 3      |
| 5       | Игрок                 | Достоевский Ф.М. | 480.50 | 10     |
| 6       | Стихотворения и поэмы | Есенин С.А.      | 650.00 | 15     |
| 7       | Черный человек        | Есенин С.А.      | Null   | Null   |
+---------+-----------------------+------------------+--------+--------+

Запрос:

/* чтобы проверить запрос, добавьте в таблицу строку */
INSERT INTO book (title, author, price, amount) VALUES ('Черный человек','Есенин С.А.', Null, Null);

SELECT author, COUNT(author), COUNT(amount), COUNT(*)
FROM book
GROUP BY author;

Результат:

+------------------+---------------+---------------+----------+
| author           | COUNT(author) | COUNT(amount) | COUNT(*) |
+------------------+---------------+---------------+----------+
| Булгаков М.А.    | 2             | 2             | 2        |
| Достоевский Ф.М. | 3             | 3             | 3        |
| Есенин С.А.      | 2             | 1             | 2        |
+------------------+---------------+---------------+----------+

Из таблицы с результатами запроса видно, что функцию COUNT() можно применять к любому столбцу, в том числе можно использовать и *, если таблица не содержит пустых значений. Если же в столбцах есть значения Null, (для группы по автору Есенин в нашем примере), то

COUNT(*) — подсчитывает все записи, относящиеся к группе, в том числе и со значением NULL;
COUNT(имя_столбца) — возвращает количество записей конкретного столбца (только NOT NULL), относящихся к группе.

Задание

Посчитать, количество различных книг и количество экземпляров книг каждого автора , хранящихся на складе. Столбцы назвать Автор, Различных_книг и Количество_экземпляров соответственно.

Исходная таблица:

Решение:

SELECT 
    author AS Автор, 
    COUNT(title) AS Различных_книг, 
    SUM(amount) AS Количество_экземпляров
FROM 
    book
GROUP BY 
    author;

Результат:

Выборка данных, групповые функции MIN, MAX и AVG

К групповым функциям SQL относятся: MIN(), MAX() и AVG(), которые вычисляют минимальное, максимальное и среднее значение элементов столбца, относящихся к группе.

Пример

Вывести минимальную цену книги каждого автора

Запрос:

SELECT author, MIN(price) AS min_price
FROM book
GROUP BY author;

Результат:

+------------------+-----------+
| author           | min_price |
+------------------+-----------+
| Булгаков М.А.    | 540.50    |
| Достоевский Ф.М. | 460.00    |
| Есенин С.А.      | 650.00    |
+------------------+-----------+

Задание

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

SELECT author, 
    MIN(price) AS Минимальная_цена,
    MAX(price) AS Максимальная_цена,
    AVG(price) AS Средняя_цена
FROM book
GROUP BY author

Вычисления по таблице целиком

Групповые функции позволяют вычислять итоговые значения по всей таблице. Например, можно посчитать общее количество книг на складе, вычислить суммарную стоимость и пр. Для этого после ключевого слова SELECT указывается групповая функция для выражения или имени столбца, а ключевые слова GROUP BY опускаются.

Пример

Посчитать количество экземпляров книг на складе.

Запрос:

SELECT SUM(amount) AS Количество
FROM book;

Результат:

+------------+
| Количество |
+------------+
| 46         |
+------------+

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

Пример

Посчитать общее количество экземпляров книг на складе и их стоимость .

Запрос:

SELECT SUM(amount) AS Количество, 
    SUM(price * amount) AS Стоимость
FROM book;

Результат:

+------------+-----------+
| Количество | Стоимость |
+------------+-----------+
| 46         | 26267.50  |
+------------+-----------+

Задание

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

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

Решение:

select 
MIN(price) as Минимальная_цена,
MAX(price) as Максимальная_цена,
ROUND(AVG(price),2) as Средняя_цена
from book

Выборка данных по условию, групповые функции

В запросы с групповыми функциями можно включать условие отбора строк, которое в обычных запросах записывается после WHERE. В запросах с групповыми функциями вместо WHERE используется ключевое слово HAVING , которое размещается после оператора GROUP BY.

Пример

Найти минимальную и максимальную цену книг всех авторов, общая стоимость книг которых больше 5000.

Запрос:

SELECT author,
    MIN(price) AS Минимальная_цена, 
    MAX(price) AS Максимальная_цена
FROM book
GROUP BY author
HAVING SUM(price * amount) > 5000;

Результат:

+------------------+------------------+-------------------+
| author           | Минимальная_цена | Максимальная_цена |
+------------------+------------------+-------------------+
| Достоевский Ф.М. | 460.00           | 799.01            |
| Есенин С.А.      | 650.00           | 650.00            |
+------------------+------------------+-------------------+

Также в запросах с группировкой можно сортировать данные.

Пример

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

Запрос:

SELECT author,
    MIN(price) AS Минимальная_цена, 
    MAX(price) AS Максимальная_цена
FROM book
GROUP BY author
HAVING SUM(price * amount) > 5000 
ORDER BY Минимальная_цена DESC;

Результат:

+------------------+------------------+-------------------+
| author           | Минимальная_цена | Максимальная_цена |
+------------------+------------------+-------------------+
| Есенин С.А.      | 650.00           | 650.00            |
| Достоевский Ф.М. | 460.00           | 799.01            |
+------------------+------------------+-------------------+

Задание

Вычислить среднюю цену и суммарную стоимость тех книг, количество экземпляров которых принадлежит интервалу от 5 до 14, включительно. Столбцы назвать Средняя_цена и Стоимость, значения округлить до 2-х знаков после запятой.

Решение:
SELECT 
    ROUND(AVG(price),2) as Средняя_цена,
    ROUND(SUM(price*amount),2) as Стоимость
from book
where amount between 5 and 14

Основа таблицы:

Выборка данных по условию, групповые функции, WHERE и HAVING

WHERE и HAVING могут использоваться в одном запросе. При этом необходимо учитывать порядок выполнения SQL запроса на выборку на СЕРВЕРЕ:

FROM
WHERE
GROUP BY
HAVING
SELECT
ORDER BY

Сначала определяется таблица, из которой выбираются данные (FROM), затем из этой таблицы отбираются записи в соответствии с условием WHERE, выбранные данные агрегируются (GROUP BY), из агрегированных записей выбираются те, которые удовлетворяют условию после HAVING. Потом формируются данные результирующей выборки, как это указано после SELECT ( вычисляются выражения, присваиваются имена и пр. ). Результирующая выборка сортируется, как указано после ORDER BY.

Важно! Порядок ВЫПОЛНЕНИЯ запросов - это не порядок ЗАПИСИ ключевых слов в запросе на выборку. Порядок записи (синтаксис запроса) остается таким же, как рассматривался ранее в курсе. Порядок ВЫПОЛНЕНИЯ нужен для того, чтобы понять, почему, например, в WHERE нельзя использовать имена выражений из SELECT. Просто SELECT выполняется компилятором позже, чем WHERE, поэтому ему неизвестно, какое там выражение написано.

Пример

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

SELECT author,
    MIN(price) AS Минимальная_цена,
    MAX(price) AS Максимальная_цена
FROM book
WHERE author <> 'Есенин С.А.'
GROUP BY author
HAVING SUM(amount) > 10;

Результат:

+------------------+------------------+-------------------+
| author           | Минимальная_цена | Максимальная_цена |
+------------------+------------------+-------------------+
| Достоевский Ф.М. | 460.00           | 799.01            |
+------------------+------------------+-------------------+

Другим способом решения примера является запрос:

SELECT author,
    MIN(price) AS Минимальная_цена,
    MAX(price) AS Максимальная_цена
FROM book
GROUP BY author
HAVING SUM(amount) > 10 AND author <> 'Есенин С.А.';

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

Задание

Посчитать стоимость всех экземпляров каждого автора без учета книг «Идиот» и «Белая гвардия». В результат включить только тех авторов, у которых суммарная стоимость книг (без учета книг «Идиот» и «Белая гвардия») более 5000 руб. Вычисляемый столбец назвать Стоимость. Результат отсортировать по убыванию стоимости.

select 
    author,
    SUM(price*amount) as Стоимость
from book
where title<>"Идиот" and title<>"Белая гвардия"
group by author
having Стоимость > 5000
order by author desc

Роль и задачи QA. Основные артефакты QA

2023-12-12T12:22:16.845Z

Оглавление

Основные задачи QA
Артефакты
Виды тестирования
Типы багов
Техники тестов

QA (Quality Assurance, Обеспечение Качества) является неотъемлемой частью процесса разработки программного обеспечения и других продуктов. QA необходим по следующим причинам:

1. Гарантия Качества Продукта:

Предотвращение Дефектов: QA помогает выявлять и устранять ошибки на ранних этапах разработки, что снижает стоимость их исправления в будущем.
Соответствие Стандартам: Обеспечивает, что продукт соответствует заранее определенным стандартам качества и требованиям пользователя.

2. Удовлетворенность Клиента:

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

3. Надежность и Безопасность:

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

Основные Задачи QA:

Разработка и Поддержка Тестовых Сценариев:

Создание детальных тестовых планов и сценариев для проверки функциональности продукта.

Тестирование Продукта:

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

Анализ и Документирование Результатов:

Анализ результатов тестов для выявления ошибок и документирование их для команды разработчиков.

Сотрудничество с Разработчиками:

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

Управление Рисками:

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

Поддержка Процесса Непрерывного Улучшения:

Участие в анализе процессов разработки и предложения улучшений для повышения качества продукта.

Обеспечение Соблюдения Норм и Стандартов:

Гарантия того, что продукт соответствует всем необходимым стандартам и нормативным требованиям.

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

Основные артефакты QA (Quality Assurance, Обеспечения Качества) включают в себя следующие документы и материалы:

1. Тестовый План (Test Plan)

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

2. Тестовые Сценарии (Test Cases)

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

3. Тестовые Сценарии (Test Scripts)

Автоматизированные или ручные сценарии, используемые для выполнения тестов.

4. Тестовые Данные (Test Data)

Данные, используемые в тестировании для проверки функциональности и производительности продукта.

5. Чек-листы (Checklists)

Списки для быстрой проверки основных функций и характеристик продукта.

6. Отчеты о Дефектах (Defect Reports)

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

7. Отчеты о Тестировании (Test Reports)

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

8. Матрица Трассируемости Требований (Requirements Traceability Matrix)

Таблица, связывающая требования с соответствующими тестовыми сценариями, что обеспечивает полное покрытие требований тестированием.

9. Документы Стратегии и Методологии Тестирования

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

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

Виды тестирования

1. Функциональное Тестирование (Functional Testing)

Цель: Проверка функциональности продукта, чтобы убедиться, что он работает в соответствии с требованиями.
Примеры: Тестирование пользовательских интерфейсов, API, баз данных, безопасности, клиент-серверных приложений.

2. Регрессионное Тестирование (Regression Testing)

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

3. Нагрузочное Тестирование (Load Testing)

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

4. Тестирование Безопасности (Security Testing)

Цель: Выявление уязвимостей в программе, которые могут привести к потере данных, несанкционированному доступу и другим угрозам.
Примеры: Проверка на SQL-инъекции, тестирование на проникновение, проверка шифрования.

5. Юзабилити Тестирование (Usability Testing)

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

6. Тестирование Совместимости (Compatibility Testing)

Цель: Проверка работы продукта в различных окружениях, на разных устройствах, браузерах и операционных системах.
Примеры: Тестирование на различных версиях ОС, в разных браузерах.

7. Интеграционное Тестирование (Integration Testing)

Цель: Проверка взаимодействия между различными модулями или сервисами в системе.
Примеры: Тестирование API, клиент-серверных взаимодействий.

8. Юнит-Тестирование (Unit Testing)

Цель: Проверка отдельных модулей или компонентов программы для убеждения в их корректной работе.
Примеры: Тестирование отдельных функций, классов, методов.

9. Тестирование Производительности (Performance Testing)

Цель: Оценка скорости, масштабируемости и стабильности системы под нагрузкой.
Примеры: Тестирование отклика при высокой нагрузке, стресс-тестирование.

10. Эксплораторное Тестирование (Exploratory Testing)

Цель: Исследование системы, обнаружение неочевидных ошибок.
Примеры: Неструктурированное тестирование, при котором тестировщик одновременно изучает систему и проектирует тесты.

Типы Дефектов (Багов):

Функциональные Дефекты:

Проблемы, связанные с функциональностью продукта. Пример: неверно работающая кнопка в интерфейсе.

Логические Дефекты:

Ошибки в бизнес-логике или алгоритмах. Пример: неправильный расчет в финансовой системе.

Ошибки Интерфейса:

Проблемы в визуальном отображении и взаимодействии пользователя с системой. Пример: неправильное расположение элементов на странице.

Ошибки Совместимости:

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

Производительности:

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

Безопасности:

Уязвимости, которые могут привести к несанкционированному доступу или утечке данных. Пример: SQL-инъекция.

Ошибки Установки:

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

Ошибки Конфигурации:

Неправильная настройка параметров системы. Пример: неправильные настройки сервера.

Ошибки Интеграции:

Проблемы во взаимодействии между разными компонентами или системами. Пример: сбой в API-взаимодействии.

Ошибки Пользовательского Опыта:

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

Техники тестов

Эквивалентные классы: Эта техника разбивает входные данные на группы, где каждая группа представляет эквивалентный класс входных данных. Затем для каждого класса выполняются тесты.
Граничные значения: Эта техника фокусируется на граничных значениях входных данных, таких как минимальные и максимальные значения, а также значения, близкие к ним. Тестирование на граничных значениях может выявить ошибки, связанные с обработкой крайних ситуаций.
Парные комбинации (Pairwise Testing): Это методика, которая помогает снизить количество тестов, путем тестирования всех возможных комбинаций пар входных данных, таким образом экономя время и ресурсы.
Таблицы принятия решений (Decision Tables): Этот метод используется для моделирования различных вариантов поведения системы на основе разных комбинаций входных условий.
Тестирование состояний (State Transition Testing): Эта техника подходит для систем, имеющих разные состояния, и она направлена на проверку переходов между этими состояниями.
Тестирование методом "Черного ящика" (Black Box Testing): При этом методе тестировщик сосредотачивается на функциональности системы без знания внутренней реализации. Это позволяет тестировать систему с точки зрения пользователя.
Тестирование методом "Белого ящика" (White Box Testing): Здесь тестировщик имеет доступ к внутренней структуре кода и тестирует его на основе логики и структуры программы.
Тестирование с использованием техники "Пути выполнения" (Path Testing): Этот метод фокусируется на проверке всех возможных путей выполнения программы.
По убыванию степени важности тестируемых функций (по уровню функционального тестирования):

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

Андрей

Приоритезация

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

Когда не обойтись без фреймворка приоритизации

Распаковываем RICE и ICE

RICE

ICE

Достоинства и недостатки ICE скоринга

Impact

Confidence

Effort и его рост

Вишенка на торте — калькулятор стоимости человеко-дня

Трудозатраты: взгляд разработчика

Что нужно, чтобы приоритизация заработала

Заключение

System design

Протоколы

REST и GraphQL

gRPC

Webhook

1. Короткий опрос

2. Веб-хуки

Производительность API

HTTP 1.0 -> HTTP 1.1 -> HTTP 2.0 -> HTTP 3.0 (QUIC)

SOAP, REST, GraphQL и RPC

Сначала код и сначала API

Коды статусов HTTP

Шлюз API

Эффективное и безопасное API

Инкапсуляция TCP/IP

Почему NGINX называют "обратным" прокси?

Алгоритмы балансировки нагрузки

URL, URI и URN

CI/CD

CI/CD простыми словами

Технический стек Netflix (конвейер CI/CD)

Архитектурные паттерны

MVC, MVP, MVVM, MVVM-C и VIPER

18 основных архитектурных паттернов

База данных

8 структур данных, улучшающих работу баз данных

Выполнение инструкции SQL в базе данных

Теорема CAP

Типы памяти и хранилищ данных

Визуализация запроса SQL

Язык SQL

Кэш

Кэширование данных

Причины высокой производительности Redis

Случаи использования Redis

Стратегии кэширования

Микросервисная архитектура

Типичная микросервисная архитектура

Лучшие практики микросервисов

Типичный технический стек микросервисов

Причины высокой производительности Kafka

Платежные системы

Почему кредитную карту называют "самым выгодным продуктом банка"? Как VISA/Mastercard делают деньги?

Принцип работы VISA

DevOps

DevOps, SRE и Platform Engineering

Что такое Kubernetes?

Docker и Kubernetes

Принцип работы Docker

Git

Принцип работы команд Git

Принцип работы Git

Git merge и git rebase

Облачные сервисы

Популярные облачные сервисы по состоянию на 2023 год

Облачная нативность

Инструменты, повышающие продуктивность разработки

Визуализация файлов JSON

Автоматические преобразование кода в архитектурные диаграммы

Linux

Файловая система Linux

18 основных команд Linux

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

Принцип работы HTTPS

OAuth 2.0 простыми словами