Глава 1 Надежные, масштабируемые и удобные в сопровождении приложения

Удобство сопровождения

Книга

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

Designing Data-Intensive Applications: The Big Ideas Behind Reliable, Scalable, and Maintainable Systems

Главная книга для тех, кто хочет научиться создавать крупные, быстрые и надежные ИТ-системы вроде Telegram, Netflix или крупных интернет-магазинов.

Автор

Мартин Клеппман

martin.kleppmann.com ↗

Спикер

Артём Никифоров

t.me/Frich22 ↗

Раздел 1.4 · Зачем это

Сопровождение дороже разработки

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

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

01 · OPERABILITY

Удобство эксплуатации

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

02 · SIMPLICITY

Простота

Новым инженерам легко понять систему — за счёт максимально возможного её упрощения. Это не то же самое, что простота пользовательского интерфейса.

03 · EVOLVABILITY

Возможность развития

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

Простых решений нет — как и с надёжностью и масштабируемостью. Эти три принципа нужно просто держать в голове при проектировании.

Принцип 1 · Удобство эксплуатации

Хороший софт не компенсирует плохую эксплуатацию

«Хороший обслуживающий персонал часто может обойти ограничения плохого ПО, но хорошее ПО не способно надёжно работать под управлением плохих операторов» — Джей Крепс, один из создателей Kafka. Операторы здесь — те, кто держит систему в проде: ops, SRE, дежурный инженер. Автоматизировать можно и нужно, но настроить автоматизацию и проверить, что она работает правильно, — всё равно задача людей.

За что отвечают операторы

Следят за состоянием системы и восстанавливают сервис после сбоев.
Ищут причины отказов и просадок производительности.
Обновляют ПО и платформы, включая исправления безопасности; внедряют практики деплоя и управления конфигурацией.
Отслеживают, как системы влияют друг на друга, и останавливают проблемное изменение до ущерба.
Планируют мощности (capacity planning) заранее и сохраняют знания о системе при смене людей.

Что система может сделать для операторов

Наблюдаемость: хороший мониторинг и видимость того, что происходит внутри во время работы.
Поддержка автоматизации и интеграция со стандартными утилитами.
Независимость от отдельных машин: одну можно вывести на обслуживание, система продолжает работать.
Качественная документация и понятная операционная модель: «сделаю X — произойдёт Y», минимум неожиданностей.
Разумные настройки по умолчанию и самовосстановление где возможно — но с возможностью оператору вмешаться и переопределить.

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

Принцип 2 · Простота

Простота: регулируем сложность

Код маленького проекта бывает восхитительно простым и выразительным, а по мере роста превращается в «большой ком грязи» (Big Ball of Mud). Сложность замедляет всех, кто работает над системой, и увеличивает стоимость сопровождения. Симптомы узнаваемы:

взрывной рост числа состояний тесная связанность модулей (tight coupling) запутанные зависимости несогласованные наименования и терминология «костыли» ради производительности частные случаи для обхода проблем

Цена сложности

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

Побочная сложность vs неотъемлемая

Упростить систему — не обязательно урезать функциональность. Мозли и Маркс («Out of the Tar Pit», 2006) делят сложность на неотъемлемую (essential) — она в самой задаче пользователя — и побочную (accidental) — она от нашей конкретной реализации. Убирать нужно именно побочную.

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

Принцип 3 · Возможность развития

Требования не останутся неизменными. Никогда.

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

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

Agile — но на каком масштабе?

На уровне процессов адаптацию к изменениям даёт Agile; на уровне кода — разработка через тестирование (TDD) и рефакторинг. Но обсуждают их обычно в маленьком масштабе: пара файлов исходного кода в одном приложении.

Развитие на уровне информационной системы

Книга ищет способы ускорить адаптацию на уровне больших систем из нескольких приложений и сервисов. Пример из доклада Антона про раздел 1.3: как перевести живой Twitter с подхода 1, где лента собирается при чтении, на подход 2, где твиты раскладываются по лентам подписчиков при записи?

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

Не из книги · Примеряем на фронтенд

Три принципа — в нашем репозитории

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

Принцип	Как звучит в нашем проекте	Что помогает
Удобство эксплуатации	Релиз и откат, конфиги и флаги, ошибки в проде; «сделаю X — произойдёт Y» про пайплайн и окружения	Наблюдаемость: мониторинг ошибок, RUM (мониторинг реальных пользователей), Web Vitals; воспроизводимые сборки; документация «как выкатить и как откатить»; разумные дефолты
Простота	Разросшееся состояние UI, тесно сцепленные компоненты, «костыли» на useEffect, три способа сделать одно и то же	Дизайн-система и переиспользуемые компоненты как абстракции; убирать побочную сложность, а не функциональность
Возможность развития	Внутри приложения: классы → хуки, CRA → Vite, Next.js Pages → App Router. На уровне системы: смена контракта API (REST → GraphQL или BFF), выделение микрофронтенда, новое требование закона, которое трогает фронт, бэк и аналитику сразу	Явные границы модулей и контрактов, тесты как страховка рефакторинга, постепенная миграция вместо переписывания с нуля

Вопрос к своему репозиторию: сколько стоит изменение, которое пользователю кажется маленьким? Это и есть измеримая возможность развития.

Что забрать с собой

Удобство сопровождения — в четырёх строках

Сопровождение дороже разработки. Проектируем так, чтобы не создавать унаследованные системы своими руками.
Удобство эксплуатации = наблюдаемость + управляемость. Хороший мониторинг состояния системы и эффективные способы управлять этим состоянием; стандартные задачи делаются легко.
Простота — основная цель. Убираем побочную сложность, а не функциональность; инструмент — хорошие абстракции.
Возможность развития — отдельный принцип, опирающийся на простоту. Требования изменятся обязательно; простую систему адаптировать легче, а книга ищет, как ускорять изменения на уровне целой системы, а не пары файлов.

Резюме главы: лёгкого пути к надёжности, масштабируемости и удобству сопровождения нет. Но есть паттерны и методики, которые встречаются снова и снова — им и посвящена остальная книга.

Что далее

Подходы к работе над информационными системами Пройдено

Антон Помазков

Надежность Пройдено

Артём Никифоров

Масштабируемость Пройдено

Антон Помазков

Удобство сопровождения Пройдено

Артём Никифоров