Ребят, всем привет!

Я не забыл про книгу, скоро будет конспект по второй главе (был перерыв). А пока я пишу конспект, то предлагаю вам насладиться подкастом с автором книги Designing Data-Intensive Applications Martin Kleppmann у Gergely Orosz — Designing Data-intensive Applications with Martin Kleppmann

Designing Data-Intensive Applications

Глава 2. Defining Nonfunctional Requirements

Вторая глава книги посвящена нефункциональным требованиям к разрабатываемым нами системам. Под нефункциональными требованиями автор подразумевает:

- Производительность (Performance)
- Надёжность (Reliability) и отказоустойчивость (Fault Tolerance)
- Масштабирование (Scalability)
- Поддержка (Maintainability)

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

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

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

1. Время ответа
2. Пропускная способность

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

Пропускная способность (throughput) — максимальное количество запросов или единиц (МБ, ГБ, ТБ) данных в секунду, которое система способна обработать. Чем выше показатель тем производительность системы лучше.

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

Есть ещё одна метрика, которую часто путают с временем ответа это задержка (latency). Автор пишет, что эти два термина зачастую используют как взаимозаменяющие, но на практике задержка означает время, необходимое для доставки сетевых пакетов до пункта назначения и обратно (после обработки запроса). То есть, время ответа уже включает в себя время задержки, т.е. response time > latency практически всегда.

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

- Арифметическое среднее (Mean)
- Медиана (Median)
- Процентиль (Percentile)

Использовать арифметическое среднее для измерения времени ответа некорректно (но применимо для измерения пропускной способности). Оно не даёт объективной картины, т.к. сильно подвержено влиянию выбросов (outliers). Лучше всего подходит процентиль. Медиана, например, является 50-м процентилем (p50). Если, например, медиана времени ответа 200мс, то это значит что 50% пользователей получили ответа до 200мс, а остальные 50% от 200мс и выше. Лучше всего использовать p90, p95, p99.

Надежность
Надёжная система подразумевает что:

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

Отказоустойчивая система подразумевает, что в случае выхода из строя части системы она продолжает свою работу. Например, отказ работы одного из жестких дисков или физической машины не должен повлиять на работоспособность приложения. Для проектирования отказоустойчивых систем практикуют т.н. Chaos Engineering. Это инженерная дисциплина, направленная на проверку надёжности распределенных систем через регулярное внедрение преднамеренных сбоев (увеличение сетевых задержек, отключение серверов и т.д.)

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

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

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

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

Улучшить масштабируемость можно несколькими способами:
- Добавлением новых ресурсов (улучшение памяти, дисков, CPU), вертикальное масштабирование (vertical scaling)
- Добавлением новых машин, горизонтальное масштабирование (horizontal scaling)

Автор подход с горизонтальным масштабированием разбивает на два:

1. Shared-Disk Architecture
2. Shared-Nothing Architecture

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

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

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

Чтобы снизить тяжесть бремени поддержки стоит придерживаться нескольких принципов:

- Работоспособность (Operability)
- Простота или управляемая сложность (Simplicity)
- Расширяемость или жизнестойкость (Evolvability)

Работоспособность
- Автоматизация рутинных задач (например, CI/CD, внедрение DevOps практик)
- Автоматический сбор и анализ состояния работы систем и подсистем (Observability & Monitoring)
- Актуальная документация и база знаний
- Внедрение практики дежурства и postmortems, SRE-практик

Простота или управляемая сложность
Авторы книги сложность системы делят на два типа:

1. Необходимая (Essential), она появляется из сложности самой доменной области приложения при проектировании
2. Случайная (Accidental), такой тип сложности уже возникает из-за ошибок в проектировании, организации кода, компромиссов при выборе технологий

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

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

На канале Елизаветы Осетинской вышло интересное интервью с создателем ClickHouse Алексеем Миловидовым: https://www.youtube.com/watch?v=FSGhaMmqWTA

PostgreSQL 18 изнутри

Postgres Pro выпустили новую версию книги про устройство PostgreSQL: PostgreSQL 18 изнутри

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

Скачать по ссылке.

Официальная документация по Python теперь доступна на русском языке: https://blog.python.org/2026/08/the-python-documentation-is-now-available-in-russian/