Sazoks

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

Доступность
Здесь уже появляется неоднозначность.

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

По идее, здесь мы поддерживаем согласованность, жертвуя.. доступностью? Но ведь нет же! Мы все равно получим ответ.

Да, мы жертвуем доступностью, так как ответ мы не получим, если какой-то узел выпал из кластера => операция записи просто не будет выполнена.
Хотя в реальной жизни мы сразу получим ответ вида "запрос не может быть обработан. Почините кластер"
Пример такой системы - etcd, в которой ты заранее указываешь размер кластера и если кластер не может придти в состояние кворума (доступно N/2+1 узел, где N-количество узлов), то весь кластер переходит в аварийный режим без возможности чтения или записи.
Таким образом гарантируется консистентность даже на отвалившихся от кластера узлах.

Определение доступности из CAP вообще ничего не говорит про задержку (latency).

Потому что CAP не про это.

Резюмируя вопросы:

1. Просто читаем определение:

High availability (HA) is a system's capability to provide services to end users without going down for a specified period of time. High availability minimizes or (ideally) eliminates service downtime regardless of what incident the company runs into (a power outage, hardware failure, unresponsive apps, lost connection with the cloud provider, etc.).

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

Какая правильная и полная формулировка Availability из CAP?

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

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

Любой запрос - любой запрос чтения или записи к любому из работающих узлов системы.
Завершается откликом - значит тебе дают какой-то ответ, который не является ошибкой.
Пример доступной, но не консистентной системы управления кадрами:
Запрос: "Какая зарплата у Иванова?"
Узел 1: 1000 долларов
Узел 2: две тысячи долларов
Узел 3: Иванов у нас не работает

Пример такой же системы, но в которой действует принцип консистентность:
Запрос: Иванов уволен?
Узел 1,2,3: Ошибка: кластер в аварийном режиме.
Либо:
Узел 1,2,3: Иванов не уволен.
Либо:
Узел 1,2: Иванов не уволен
Узел 3: Ошибка: отсутствует кворум.

Запрос: Уволить Иванова.
Узел 1,2,3: Ошибка: кластер в аварийном режиме. Доступно только чтение.
Либо:
Как в третьем варианте, если возможна запись при наличии кворума.

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

CAP не про это.

Отказоустойчивая система не допускает потери функциональности вообще?

Пуленепробиваемое стекло не допускает пробития пулями вообще?)
В случае катастрофического отказа - возможно всё.

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

Два слова: нагрузочное тестирование.

Теперь все дополнения тут:

Конфиденциальность. Пользователь уверен, что данные из системы не утекут.

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

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

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

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

Я бы поспорил насчёт среднего арифметического )

Здесь вопрос в том, как мерить общую производительность сервиса?

Никак, ведь нет никакой "общей производительности".
Нагрузочное тестирование существует, но его проводят в профиле какой-то конкретной нагрузки/сценария.

Например в банковской системе могут проводить нагрузочную систему по нескольким сценариям:
1. "Чёрная пятница" - резко увеличивается количество карточных операций.
2. "Реклама у крупного блогера" - резко увеличилось количество запросов на выпуск новой карты. Нужно проверить, как вообще выдержит сервис, отвечающий за эмбоссинг.
3. "Экономике в стране «очень плохо»" - смотрим как выдержит клиринг при большом количестве межбанковских переводов.

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

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

Или добавив пакетную обработку.

На задержка напрямую зависит от пропускной способности (производительности) и канала связи. Чем ближе сервер к пользователю, тем меньше задержка.

А вот и нет.
У нас вполне может быть узкий канал с низкой задержкой или же широкий канал с большой задержкой.
А ещё задержка - это время обработки запроса твоей собственной системой.
Например твой сервис вполне может иметь большой latency, но и большой throughput и наоборот.

Допускает ли High Availability полный отказ системы или только отказ каких-то компонент с точки зрения функциональности, а не экземпляров?

Доступность исчисляется относительно внешнего клиента - может или нет получить доступ к сервису. Здесь без разницы, что для этого используется кластеризация, бэкапы, стендбаи и т.д.
Главное - это то, как систему видит пользователь. Собственно, все SLA на так и рассчитываются.

Какая правильная и полная формулировка Availability из CAP?

На сколько я помню, эту теорему в свое время критиковали и продолжают за неясность определения. Но если в кратце, доступность здесь означает, что ты получишь ответ, даже если связь с другими узлами кластера пропадет. Если в кратце, доступность = можешь получить ответ хоть когда-нибудь.
Пример:
1. Есть кластер из 2 Postgres мастеров. Связь между ними пропадает и запросы они принимать не могут. Это НЕ Availability, т.к. нам важна консистентность
2. Если кластер из 2 Postgres узлов - мастер и слейв. Даже если связь между ними пропадет, то запросы они принимать смогут, но данные могут быть в не согласованном состоянии (мастер принял несколько UPDATE/INSERT/DELETE, а слейв о них не знает). Это Availability, но Consistency мы потеряли
3. Если кластер из 2 Mongo узлов. Там используется свой протокол, который позволяет системе быть доступной, даже если связь между мастерами потеряется. Это Availability, но согласованность может потеряться
P.S. в последнем используются специальные распределенные структуры данных (чтобы каждый узел мог модифицировать свою версию, а потом смержить с другими узлами)

Отказоустойчивая система не допускает потери функциональности вообще?

Отказоустойчивость - это не дискретная (0 или 1), а непрерывная характеристика. Здесь лучше думать в ключе SLA (99, 99.9, 99.999 т.д.), т.к. никакая система не может быть полностью отказоустойчивой. Но в целом да - отказоустойчивость значит, что функциональность должна работать и клиент может ее использовать.

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

1+ слово - тестирование (нагрузочное, объемное и т.д.)
Здесь нельзя вычислить формулами, сколько и что сможем обслужить. Только экспериментом числа получать.

UPD: если хочешь призму, чтобы смотреть на распределенные системы, то вот тут скачай "Распределенные системы" от Таненбаума - https://www.distributed-systems.net/index.php/book...

Описание проблемы проще чем кажется: чем больше трафика - тем больше работы.
Это влечет за собой:
- Больший нагрев процессора и других комплектующих + повышение их износа -> могут отвалиться
- В каждом софте (даже стабильной ОС) есть ошибки, которые точно возникнут согласно ЗБЧ
- Появляется слишком много прерываний, которые тормозят систему -> большие операционные издержки (переключение контекста, переход в режим ядра и т.д.)
- Рано или поздно доступные ресурсы закончатся (ОЗУ, Диск, буфер сетевой карты), а не многие приложения могут такое обработать и упадут

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

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

UPD: + конечно же когда много трафика, то какие-то пакеты отбрасываются/теряются и необходимо слать их повторно, что увеличивает нагрузку на сеть + задержку запроса

Из всего изученного стало понятно, что процессы - это некие "контейнеры", содержащие id, статус, instruction pointer, значение регистров, открытые файлы и другие данные контекста.

Вот уже по этому предложению видно, что понятно не стало. instruction pointer и значения регистров -- свои у каждого потока.

какую роль в планировании играют процессы?

Никакой.

Для чего они нужны?

Для учёта ресурсов и создания изолированных адресных пространств.

Как планировщик ОС работает с процессами?

Никак.

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

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

Вопрос 1. Два конвейера позволяют только сократить накладные расходы на context switch. Параллелизм это не увеличивает, так как вычислительное ядро по-прежнему одно.

Вопрос 2. Верно. Разделите понятия процесс и поток. Думайте о процессе как о контейнере для потоков, а не как об активной сущности, которая исполняет код. В каждом процессе есть как минимум 1 поток. Все без исключения программы стартуют как однопоточный процесс, который имеет возможность превратиться в многопоточный, заспавнив ещё потоков. Ну и, соответственно, ОС шедулит потоки, а не процессы.

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

Вопрос 4. Kernelspace и userspace потоки отличаются только тем, в каких кольцах они исполняются. Kernel потоки исполняются в привилегированных кольцах, а user потоки в непривилегированных. Во всём остальном эти потоки ничем друг от друга не отличаются. Кольца ограничивают набор процессорных инструкций и системных вызовов, которые поток может использовать. Например, чтение файла с диска - это привилегированная операция (так как требует прямого доступа к девайсу), поэтому когда обычный userspace поток хочет прочитать файл, ОС приостанавливает userspace поток и передаёт управление kernelspace потоку, у которого достаточно привилегий на выполнение данной операции.

Кооперативную многозадачность можно сделать и самому. Концепция называется green threads. В языках программирования встречается уже готовая реализация грин тредов, только называется иначе: корутины (python), горутины (go), виртуальные потоки (java). Все они делают одно и то же - реализуют кооперативную многозадачность в userspace. При большом желании можно написать и свою реализацию грин тредов без использования уже готовых языковых инструментов. Хотя практического смысла в этом мало (кроме нарабатывания опыта).

Вопрос 5. Думаю, ответ на этот вопрос очевиден из ответа на предыдущий.

И всё же под "kernel" обычно подразумевают ядро ОС, а не ядро процессора (которое называют core, а не kernel). Единственный способ запустить поток в kernelspace - написать модуль/драйвер ядра. Обычные программы так не могут.

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

Хм тут вам помогут книги
Эндрю Таненбаум
Торвальдса
Русиновича
Helen Custer , David N Cutler
David A. Solomon
https://slideplayer.com/slide/6865915/

Гляньте вот на эту презентацию https://www.hse.ru/data/2010/12/24/1223886397/%D0%...

А вот тут прикладная часть
https://basis.gnulinux.pro/ru/latest/basis/15/15._...

В общем тема большая и гуглить вам много, но основных авторов я дал

Ну, книги Вам уже посоветовал @firedragon
Я же хочу вкратце ответить на этот замечательный вопрос.
Давайте разберемся с одним CPU без потоков...
Когда процессоры были большими, а люди... В общем, на заре компухтеров был только один поток, и чтобы получить многозадачность, придумали ОС с вытеснением задач.
Смысл в том, что когда завершается "программа", то запускается следующая в очереди (очередь с приоритетом). Задача работает до тех пор, пока не завершится.

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

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

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

Ах, да, молодость процессоров - одно прерывание на все сразу :) И крутись, как хочешь :)

Ответ простой - обновляют docker-compose.
Варианта два:
1) если прод. сервер один, то просят время на downtime, обновляют, проверяют, возвращают в продакшен
2) если серверов несколько, то исключают один сервер из сервиса, обновляют, проверяют, подключают заново, и т.д. со следующими

UX
Любой проект начинается с проектирования. Для крутых проектов, когда у проектировщика нет возможности въехать, может потребоваться помощь бизнес-аналитика. Увы, в России таких людей крайне мало, так что это — редкость. Впрочем, и проекты такого рода — тоже редкость.

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

Однако, если проектировщика нет, а дизайнер пока не в состоянии делать это сам, то вся надежда на:
Фронтенд
Человек, который будет реализовывать сложные взаимодействия, разработанные проектировщиком (или дизайнером, или им же самим). Без знания JS и ряда библиотек никому не интересен. Просто HTML и CSS уже редко кому требуются, только если работать на подхвате у фронтенда.

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

Ну и совсем невероятно, что проектирование сможет провести:
Менеджер
Его функции могут сильно варьироваться, от организации команды, до отбивания от клиентов (например, когда всё упало). Даже если не умеет проектировать (а кто в здравом уме от него это ожидает?), в стартапе он нужен. Практика показывает, что технические специалисты часто увлекаются деревьями, а лес идёт лесом.

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

Для продвинутых
Администраторы серверов (а то напридумывают всякое, а оно вызывает то самое падение)
Писатели (контент становится очень важен)
Тестировщики (чтобы косяки не всплыли после выхода продукта)
Контент-менеджеры (кто будет лопатить тонны текста и графики)
Возможно, технические дизайнеры с перспективой роста
Ну и далее, вплоть до милых фей в баре, которые всегда нальют горячее кофе

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

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

Первое, что бросается в глаза - настройки. Да, Вы следуете идеологии Django, которая неявно шепчет всем нам как их компоновать: но это небезопасно. Почему в настройках у вас модули, два из которых отражает какое-то окружение (разработка, боевое и что-то общее между тем и тем)? Исходя из Вашей структуры сразу витает в воздухе вопрос: "А почему настройки боевого окружения вдруг должны быть в репозитории? А как быть с секретным ключом? А безопасно ли это?". Следующий логичный вопрос удобства: почему я, как разработчик, вдруг должен заставлять своих DevOps'ов компоновать и поддерживать за меня настройки в виде файлов (модулей)? Это ведь исполняемый файл и там бесчисленное количество возможностей; более того, это не безопасно. Сейчас бОльшая часть проектов поднимается средствами docker-compose, куберов и прочих прелестей: дико неудобно собирать и поддерживать настройки в виде файлов для каждого запускаемого контейнера (у нас ведь есть переменные окружения). Надеюсь, здесь понятен основной посыл: безопасность и удобство использования.

(здесь я не сразу понял, что это именно проект, а не приложение; подробности в комментариях)
Едем дальше - core. Почему именно такое название? Понятное дело, ядро, Django в своих исходниках делает и всё такое... Но зайдя в такой проект, сразу ли будет понятно за что отвечает это приложение? Нет. В общем-то даже в документации к Django в quick start название приложения опирается на её главную бизнес-потребность.

Переходим к следующему: папка apps с приложениями. Для начала вроде всё удобно и логично: есть ядро проекта, а есть дополнения к нему а значит их нужно как-то отделить от этого ядра. А что делать если ядро будет всегда одно в проекте? А что делать если дополнительных приложений будет всего одно? А зачем тогда ему целая папка (приложению) если само приложение - и есть папка (или модуль в нашем случае)? Так оставлять или менять уровень вложенности? На самом деле что core, что appN - являются такими же Django приложениями (одинаковыми), а значит и уровень абстракции у них - один; один уровень абстракции говорит нам о том, что и appN нужно класть где-то рядом с core (здесь должно быть другое название как и писал). Часто я вижу в проектах, что core так и остаётся одой единственной core папкой без дальнейшей расширяемости. Вывод - преждевременная оптимизация - вещь нелогичная по сути своей.

Папка template. Здесь я всегда доверяюсь Django и кладу шаблоны в папку приложения (делая ещё две папки - templates, а в ней - папку с названием приложения). Здесь, думаю, подойдёт правило класть то, что используется, ближе к тому месту, где это используется (но с поправкой на рекоммендации оф. документации Django).

Папка static. В среде отладки её быть в принципе быть не должно; обычно вся статика всегда в первую очередь связана с приложением, куда мы её и стараемся класть (как с папкой templates), что является и советом из Django документации.

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

venv. Актуально только на компьютере каждого разработчика; по-моему это неудачное решение класть платформо-зависимые файлы под контроль версий.

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

Всё верно. Лучше зависимости передавать через конструктор

На Си будет практически то же самое. Только вместо new надо делать malloc, а вместо delete - free.

Если состояние такое:

$ git status

On branch master
Changes not staged for commit:
  (use "git add/rm <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

	deleted:    myfile

То файл можно восстановить вот так:

git checkout myfile

Чтобы восстановить файл из конкретного коммита или ветки, можно сделать вот так:

git checkout abcde myfile # abcde — хеш коммита
# или
git checkout feature3 myfile # feature3 — имя ветки