Фитнес фукнции могут быть следующих видов:
- атомарные/целостные
- непрерываные/прерывающиеся
- статические/динамисеские
- автоматизированные/ручные
- временные
- атомарные/целостные
- непрерываные/прерывающиеся
- статические/динамисеские
- автоматизированные/ручные
- временные
Инкрементальные изменения
Это основной механизм эволюционной архитектуры. Идея в том, чтобы двигаться вперед небольшими шагами, заменяя устаревшие компоненты более новыми аналогами. При этом в какой-то момент времени могут быть доступны и старые и новые компоненты.
Это основной механизм эволюционной архитектуры. Идея в том, чтобы двигаться вперед небольшими шагами, заменяя устаревшие компоненты более новыми аналогами. При этом в какой-то момент времени могут быть доступны и старые и новые компоненты.
Модульность
В основе модульности лежит идея слабого зацепления и автономность модулей.
Иерархия стандартная: модуль - компонент - код
В основе модульности лежит идея слабого зацепления и автономность модулей.
Иерархия стандартная: модуль - компонент - код
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: согласованность, доступность, устойчивость к разделению)
Оценка книги: книга обзорно рассматривает основные понятия связанные с разработкой надежных баз данных. Сюда входит и подготовка инфраструктуры, и обзор средств и способов мониторинга, и вопросы связанные с построением и проектированием БД. Рекомендую к прочтению.
Я осознанно опустил из конспекта вопросы касающиеся процесса управления конфигуациями, изменениями и проблемами. Эти процессы очень похожи на то, что описывает ITIL и так как я планирую конспектировать ITIL здесь не рассматриваю эти вопросы.
Конспект The Site Reliability Workbook
Ключевые концепции DevOps:
- уменьшение преград и разрозненности
- проблемы – это нормально
- изменения должны внедряться поэтапно
- инструменты и корпоративная культура взаимосвязаны
- измерения важны (что нельзя измерить, нельзя улучшить)
SRE – Site Reliability Engineering
Ключевые концепции SRE:
- Все операции по сопровождению выполняются программным обеспечением
- Управленческие решения принимаются на базе SLO (Service level objectives)
- Минимизация человеческого труда
- Автоматизация прежде всего
- Уменьшение стоимости ошибки
- Уменьшение границ между разработкой и сопровождением
- Унификация используемых инструментов
Вывод: SRE и DevOps очень похожи друг на друга.
Организация работы построена на идеях персональной ответственности (делай сам, а не перекладывай на других), взаимозаменяемости (каждый можем кого угодно), взаимоуважения.
SLO – документ определяющий требования к продукту (список целей и критерии их достижения)
Организация работы начинается с определения SLO
SLO включает в себя требования надежности
Для оценки надежности и качества используют показатели уровня обслуживания SLI (Service Level Indicator) – числовые метрики, которые можно измерить и агрегировать по времени.
Сбор данных SLI должен осуществляться автоматизировано средствами системы мониторинга.
Для мониторинга предлагается использовать стандартные принципы и системы. Идея состоит в сборе числовых метрик и событий. Использовании распределенных, слабозацепленных систем мониторинга. Для оповещения использовать стандартные схемы с всплывающими окнами, смс и почтой. Для уменьшения потока оповещений использовать механизмы агрегации.
Человеческий труд – основное препятствие для повышение эффективности работы.
Уменьшение труда делается за счет автоматизации и отказа от лишнего труда. Основные «пожиратели» времени сотрудников – бизнес процессы, консультации и контроль правильности выполнения работ, миграции на новые технологии, проблемы с инструментами (вынужденные простои). При этом SRE не ставит перед собой задачу полностью устранить труд, но сделать это там где возможно.
Основное решение – автоматизация. Но перед выполнением автоматизации должна быть выполнена оценка целесообразности изменений, возможно от можно просто отказаться от лишних действий.
Важный момент автоматизации – системы восстановления работоспособности.
Советы по оптимизации систем восстановления работоспособности:
- графический интерфейс не должен быть сложным или перегруженным
- не полагаться на человеческую экспертизу/опыт (имеется в виду анализ потока событий одним или несколькими людьми, анализ должен быть автоматизирован)
- проектируйте переиспользуемые компоненты
- не переоценивайте проблему и не усложняйте решение
- не стремитесь делать идеальную автоматику
- автоматизация – не разовое мероприятие
- подходите к проблему целостно
Одна из важных целей SRE – оставлять систему максимально простой. Оценка сложности программной системы имеет множество нюансов. Недостаточно оценить цикломатическую сложность исходного кода софта, входящего в систему. В число параметров для оценки входят: время обучения нового члена команды для работы с системой, время объяснения устройства системы, разнообразие административных возможностей, разнообразие конфигурационных моментов, возраст системы.
Упрощение системы – непрерывный процесс поиска решений, которые позволяют уменьшать время на освоение системы новыми членами команды, переиспользовать системы повторно и т.д.
SRE инженеры должны быть задействованы и в оперативной работе, и в проектировании.
Один из основных механизмов устранения проблема – инцидент менеджмент. Средство автоматизации – ICS (Incident Command System).
Ролевая модель:
- Incident Commander – управляет устранением инцидента (обычно человек обнаруживший инцидент)
- Communication Lead – обеспечивает внешние коммуникации
- Ops Lead - устраняет инцидент
Инцидент – событие требующее немедленной реакции и устраняющееся в короткие сроки. Важно как можно быстрее восстановить работоспособность системы.
Ключевые концепции DevOps:
- уменьшение преград и разрозненности
- проблемы – это нормально
- изменения должны внедряться поэтапно
- инструменты и корпоративная культура взаимосвязаны
- измерения важны (что нельзя измерить, нельзя улучшить)
SRE – Site Reliability Engineering
Ключевые концепции SRE:
- Все операции по сопровождению выполняются программным обеспечением
- Управленческие решения принимаются на базе SLO (Service level objectives)
- Минимизация человеческого труда
- Автоматизация прежде всего
- Уменьшение стоимости ошибки
- Уменьшение границ между разработкой и сопровождением
- Унификация используемых инструментов
Вывод: SRE и DevOps очень похожи друг на друга.
Организация работы построена на идеях персональной ответственности (делай сам, а не перекладывай на других), взаимозаменяемости (каждый можем кого угодно), взаимоуважения.
SLO – документ определяющий требования к продукту (список целей и критерии их достижения)
Организация работы начинается с определения SLO
SLO включает в себя требования надежности
Для оценки надежности и качества используют показатели уровня обслуживания SLI (Service Level Indicator) – числовые метрики, которые можно измерить и агрегировать по времени.
Сбор данных SLI должен осуществляться автоматизировано средствами системы мониторинга.
Для мониторинга предлагается использовать стандартные принципы и системы. Идея состоит в сборе числовых метрик и событий. Использовании распределенных, слабозацепленных систем мониторинга. Для оповещения использовать стандартные схемы с всплывающими окнами, смс и почтой. Для уменьшения потока оповещений использовать механизмы агрегации.
Человеческий труд – основное препятствие для повышение эффективности работы.
Уменьшение труда делается за счет автоматизации и отказа от лишнего труда. Основные «пожиратели» времени сотрудников – бизнес процессы, консультации и контроль правильности выполнения работ, миграции на новые технологии, проблемы с инструментами (вынужденные простои). При этом SRE не ставит перед собой задачу полностью устранить труд, но сделать это там где возможно.
Основное решение – автоматизация. Но перед выполнением автоматизации должна быть выполнена оценка целесообразности изменений, возможно от можно просто отказаться от лишних действий.
Важный момент автоматизации – системы восстановления работоспособности.
Советы по оптимизации систем восстановления работоспособности:
- графический интерфейс не должен быть сложным или перегруженным
- не полагаться на человеческую экспертизу/опыт (имеется в виду анализ потока событий одним или несколькими людьми, анализ должен быть автоматизирован)
- проектируйте переиспользуемые компоненты
- не переоценивайте проблему и не усложняйте решение
- не стремитесь делать идеальную автоматику
- автоматизация – не разовое мероприятие
- подходите к проблему целостно
Одна из важных целей SRE – оставлять систему максимально простой. Оценка сложности программной системы имеет множество нюансов. Недостаточно оценить цикломатическую сложность исходного кода софта, входящего в систему. В число параметров для оценки входят: время обучения нового члена команды для работы с системой, время объяснения устройства системы, разнообразие административных возможностей, разнообразие конфигурационных моментов, возраст системы.
Упрощение системы – непрерывный процесс поиска решений, которые позволяют уменьшать время на освоение системы новыми членами команды, переиспользовать системы повторно и т.д.
SRE инженеры должны быть задействованы и в оперативной работе, и в проектировании.
Один из основных механизмов устранения проблема – инцидент менеджмент. Средство автоматизации – ICS (Incident Command System).
Ролевая модель:
- Incident Commander – управляет устранением инцидента (обычно человек обнаруживший инцидент)
- Communication Lead – обеспечивает внешние коммуникации
- Ops Lead - устраняет инцидент
Инцидент – событие требующее немедленной реакции и устраняющееся в короткие сроки. Важно как можно быстрее восстановить работоспособность системы.
Non-Abstract Large System Design (NALSD)
Процесс проектирования:
1 стадия включает принципиальную возможность построения решения:
- Возможно ли это?
- Можем ли мы сделать лучше?
2 стадия вписывает принципиальное решение в рамки проекта:
- возможно ли реализовать в заданных границах (деньги, время и т.д.)
- устойчиво ли полученное решение?
- можно ли сделать лучше?
Далее итеративно делается следующее:
- формируются требования
- выполняется дизайн системы
- выполняется калькуляция ресурсов
- определяются варианты развития системы
- процесс повторяется со второй позиции, до получения удовлетворяющего требованиям решения.
Конвейеры обработки данных используются в следующих приложениях:
1. ETL (Extract Transform Load)
ETL служат для:
- изменения состава данных
- выполнения промежуточных расчетов
- назначение индексов
- обогащение данных
2. Анализ данных (например на базе BI системы). Используются для оперативного мониторинга, построения отчетов, анализа данных.
3. Машинное обучение используется для поиска корреляций и «умного» анализа данных.
Процесс проектирования:
1 стадия включает принципиальную возможность построения решения:
- Возможно ли это?
- Можем ли мы сделать лучше?
2 стадия вписывает принципиальное решение в рамки проекта:
- возможно ли реализовать в заданных границах (деньги, время и т.д.)
- устойчиво ли полученное решение?
- можно ли сделать лучше?
Далее итеративно делается следующее:
- формируются требования
- выполняется дизайн системы
- выполняется калькуляция ресурсов
- определяются варианты развития системы
- процесс повторяется со второй позиции, до получения удовлетворяющего требованиям решения.
Конвейеры обработки данных используются в следующих приложениях:
1. ETL (Extract Transform Load)
ETL служат для:
- изменения состава данных
- выполнения промежуточных расчетов
- назначение индексов
- обогащение данных
2. Анализ данных (например на базе BI системы). Используются для оперативного мониторинга, построения отчетов, анализа данных.
3. Машинное обучение используется для поиска корреляций и «умного» анализа данных.