Закон Мелвина Конвея: "Организации, которые проектируют системы, склонны воспроизводить архитектуру которая воспроизводит организационную структуру самой организации"
Фитнес функции
Название немного вводит в заблуждение. На самом деле фитнес функция - это не обязательно функция реализованная на ЯП. Это любая оценка, которая позволяет сделать вывод о достижении или приближении к цели проектирования.
Название немного вводит в заблуждение. На самом деле фитнес функция - это не обязательно функция реализованная на ЯП. Это любая оценка, которая позволяет сделать вывод о достижении или приближении к цели проектирования.
Целью проектирования могут выступать любые требования, которые были получены как от заказчика, так и те которые являются следствием проектирования.
Мы можем сделать финтес функцию в виде автоматизированного теста, а можем в виде инструкции для человека, который будет вручную проверять наличие необходимых свойств у системы.
Например, если мы определим требование производительности для выполнения набора операций, скажем 100мс на операцию, то мы можем написать небольшую функцию или программу, которая будет контролировать данный показатель. Это и будет фитнес функция.
Фитнес фукнции могут быть следующих видов:
- атомарные/целостные
- непрерываные/прерывающиеся
- статические/динамисеские
- автоматизированные/ручные
- временные
- атомарные/целостные
- непрерываные/прерывающиеся
- статические/динамисеские
- автоматизированные/ручные
- временные
Инкрементальные изменения
Это основной механизм эволюционной архитектуры. Идея в том, чтобы двигаться вперед небольшими шагами, заменяя устаревшие компоненты более новыми аналогами. При этом в какой-то момент времени могут быть доступны и старые и новые компоненты.
Это основной механизм эволюционной архитектуры. Идея в том, чтобы двигаться вперед небольшими шагами, заменяя устаревшие компоненты более новыми аналогами. При этом в какой-то момент времени могут быть доступны и старые и новые компоненты.
Модульность
В основе модульности лежит идея слабого зацепления и автономность модулей.
Иерархия стандартная: модуль - компонент - код
В основе модульности лежит идея слабого зацепления и автономность модулей.
Иерархия стандартная: модуль - компонент - код
Workflow
- инкрементальные изменения
- построение и поддержание фитнес функций
- поддержание модульности
- инкрементальные изменения
- построение и поддержание фитнес функций
- поддержание модульности
Все остальные архитектуры могут развиваться эволюционнно. В книге есть пояснения относительно следующих архитектур:
Монолитные
- цельный монолит
- многослойный монолит
- модульный монолит
- микроядерный монолит
Event Driven
- брокеры
- медиаторы
Сервис ориентированные архитектуры
- ESB driven SOA
- микросервисы
Серверлес архитектура
Монолитные
- цельный монолит
- многослойный монолит
- модульный монолит
- микроядерный монолит
Event Driven
- брокеры
- медиаторы
Сервис ориентированные архитектуры
- ESB driven SOA
- микросервисы
Серверлес архитектура
Алгоритм построения эволюционной архитектуры
- определить требования, которые защищены эволюцией
- определить фитнес функции (оценки качества)
- настроить непрерывное развертывание с учетом автоматизации фитнес функций (конвейр развертывания)
- движение вперед по workflow описанному выше
- определить требования, которые защищены эволюцией
- определить фитнес функции (оценки качества)
- настроить непрерывное развертывание с учетом автоматизации фитнес функций (конвейр развертывания)
- движение вперед по workflow описанному выше
Конспект книги «Database Reliability Engineering» (DBRE)
Оценка
Основные индикаторы работоспособности сервиса:
- Latency (время ответа)
- Availability (доступность)
- Throughput (пропускная способность) обычно измеряется в операциях за единицу времени
- Durability (прочность или целостность данных)
- Cost or Efficiency (цена или эффективность) похожа на оценку «стоимость владения» - затраты на выполнение действий и поддержание СУБД
Для оценки сервиса для каждого из этих параметров нужно определить нижнюю и верхнюю границы, исходя из здравого смысла и требований заказчика.
Далее нужно автоматизировать процесс мониторинга, чтобы контроль за БД осуществлялся непрерывно.
Риск менеджмент
Основные действия:
- определить возможные проблемы/опасности которые создают операционные риски для сервиса
- оценить каждый риск и его влияние
- определить вероятности и последствия рисков
- определить способы контроля и уменьшения рисков
- расставить приоритеты рисков
- настроить системы мониторинга
- итеративно повторять данный список действий
Основные категории рисков:
- неучтенные факторы и сложность
- доступность ресурсов
- человеческий фактор
- безынициативность
- игнорирование простых проблем
- страх перед принятием решения
- излишний оптимизм
- групповые факторы
- перекладывание ответственности/принятия решения
- перекладывание рисков
Для избегания рисков – не позволяйте себе «стагнировать» и полагаться на случай.
Операционная прозрачность
Идея в том, чтобы сосредоточиться на анализе параметров работы сервиса и планировать его развитие.
Особенность современных БД – распределенность. Это дополнительная сложность для качественной оценки. Для анализа следует использовать специализированные системы, например BI
Советы при организации систем мониторинга:
- высокая скважность для сбора ключевых метрик
- простая архитектура сервисов
- использование фреймворков OpViz (операционная прозрачность)
- использование реальных данных для тестирования, а не синтезированных данных (тестирование как черный ящик)
- использование граничных случаев (тестирование как белый ящик)
- использование метрик и событий для анализа
- использовать продуманную политику для отображения данных и нотификации
Необходимо мониторить не только доступность сервиса, но и удовлетворенность клиентов качеством предоставляемой услуги.
Точки контроля
- контроль аппаратных средств (диск, процессор, память)
- контроль подключений
- контроль внутреннего состояния
Бэкап
Основные концепции
- логический – сохранение в формате подразумевающим возможность экспорта в другие системы
- физический – копирования файлов данных на систему резервного копирования
- онлайн – при одновременной работе СУБД
- офлайн – при выключенной СУБД
- полный – полное копирование
- инкрементальный – только изменения с прошлого бэкапа
- дифференциальный – только изменения с проглого полного бэкапа
В зависимости от выбранных опций резервного хранения можно делать различные схемы восстановления, которые продумываются на этапе проектирования.
Миграции
Шаблоны, которые используются для миграций БД:
- locking operations
- high resource utilization operations
- rolling migrations
Теория БД
- ACID (атомарность, согласованность, изолированность, долговечность)
- BASE (базовая доступность, неустойчивое состояние, согласованность в конечном счете)
- CAP теорема (только 2 из 3: согласованность, доступность, устойчивость к разделению)
Оценка книги: книга обзорно рассматривает основные понятия связанные с разработкой надежных баз данных. Сюда входит и подготовка инфраструктуры, и обзор средств и способов мониторинга, и вопросы связанные с построением и проектированием БД. Рекомендую к прочтению.
Оценка
Основные индикаторы работоспособности сервиса:
- Latency (время ответа)
- Availability (доступность)
- Throughput (пропускная способность) обычно измеряется в операциях за единицу времени
- Durability (прочность или целостность данных)
- Cost or Efficiency (цена или эффективность) похожа на оценку «стоимость владения» - затраты на выполнение действий и поддержание СУБД
Для оценки сервиса для каждого из этих параметров нужно определить нижнюю и верхнюю границы, исходя из здравого смысла и требований заказчика.
Далее нужно автоматизировать процесс мониторинга, чтобы контроль за БД осуществлялся непрерывно.
Риск менеджмент
Основные действия:
- определить возможные проблемы/опасности которые создают операционные риски для сервиса
- оценить каждый риск и его влияние
- определить вероятности и последствия рисков
- определить способы контроля и уменьшения рисков
- расставить приоритеты рисков
- настроить системы мониторинга
- итеративно повторять данный список действий
Основные категории рисков:
- неучтенные факторы и сложность
- доступность ресурсов
- человеческий фактор
- безынициативность
- игнорирование простых проблем
- страх перед принятием решения
- излишний оптимизм
- групповые факторы
- перекладывание ответственности/принятия решения
- перекладывание рисков
Для избегания рисков – не позволяйте себе «стагнировать» и полагаться на случай.
Операционная прозрачность
Идея в том, чтобы сосредоточиться на анализе параметров работы сервиса и планировать его развитие.
Особенность современных БД – распределенность. Это дополнительная сложность для качественной оценки. Для анализа следует использовать специализированные системы, например BI
Советы при организации систем мониторинга:
- высокая скважность для сбора ключевых метрик
- простая архитектура сервисов
- использование фреймворков OpViz (операционная прозрачность)
- использование реальных данных для тестирования, а не синтезированных данных (тестирование как черный ящик)
- использование граничных случаев (тестирование как белый ящик)
- использование метрик и событий для анализа
- использовать продуманную политику для отображения данных и нотификации
Необходимо мониторить не только доступность сервиса, но и удовлетворенность клиентов качеством предоставляемой услуги.
Точки контроля
- контроль аппаратных средств (диск, процессор, память)
- контроль подключений
- контроль внутреннего состояния
Бэкап
Основные концепции
- логический – сохранение в формате подразумевающим возможность экспорта в другие системы
- физический – копирования файлов данных на систему резервного копирования
- онлайн – при одновременной работе СУБД
- офлайн – при выключенной СУБД
- полный – полное копирование
- инкрементальный – только изменения с прошлого бэкапа
- дифференциальный – только изменения с проглого полного бэкапа
В зависимости от выбранных опций резервного хранения можно делать различные схемы восстановления, которые продумываются на этапе проектирования.
Миграции
Шаблоны, которые используются для миграций БД:
- locking operations
- high resource utilization operations
- rolling migrations
Теория БД
- ACID (атомарность, согласованность, изолированность, долговечность)
- BASE (базовая доступность, неустойчивое состояние, согласованность в конечном счете)
- CAP теорема (только 2 из 3: согласованность, доступность, устойчивость к разделению)
Оценка книги: книга обзорно рассматривает основные понятия связанные с разработкой надежных баз данных. Сюда входит и подготовка инфраструктуры, и обзор средств и способов мониторинга, и вопросы связанные с построением и проектированием БД. Рекомендую к прочтению.