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

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

Доступность

В чем разница между надежностью и доступностью?

• Надежность - способность системы выполнять требуемые действия, не допуская ошибок.
• Доступность - готовность системы к работе при необходимости выполнить требуемые действия.

Как улучшить доступность?

1. Учитывайте возможные отказы
2. Всегда помните о масштабировании (прим. от меня и ограничениях)
3. Смягчайте последствия рисков (понравился пример что если не работает поиск на сайте футболок, выдавайте временно топ предложения)
4. Контролируйте доступность (== мониторинг)
5. Disaster recovery policy (прим. от меня старайтесь строить self-recovering processes в системах)

Какая доступность является нормальная?

Определите сами на основе таблицы: 99% - 432 минуты даунтайма в месяц 99,9% - 43 минуты 99,99% - 4 минуты 99,999% - 26 секунд

Управление рисками

Принцип управления рисками

1. Составить матрицу рисков (шаблон)
   • Важно понимать, что у риска есть вероятность и критичность, для этого примеры:
     • Список топ-10 футболок: низкая вероятность и низкая критичность.
     • База данных с заказами: низкая вероятность и высокая критичность.
     • Загрузка сторонних шрифтов: высокая вероятность и низкая критичность.
     • Фотографии футболок: высокая вероятность и высокая критичность.
2. Ликвидация самых опасных рисков.
3. Смягчение последствий рисков, которые нельзя исключить.
4. Итерируй матрицу рисков или см п.1

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

Сервисы

Что такое сервис

1. Собственная кодовая база
2. Управлять собственными данными
3. Предоставлять возможности другим сервисам
4. Пользоваться возможностями других сервисов
5. Иметь единственного владельца-команду.
   • В книге уточняется что одна команда может владеть несколькими сервисами, но не наоборот. (P.s. не согласен полностью)

Как делить

1. Разделение по бизнес-требованиям (legal, security)
2. Разделение по зонам ответственности (management)
3. Разделение по роду данных (domain)
4. Разделение возможностей или информации (reusable apps)

Сложности

1. Нет общей картины
2. Благоприятная среда для сбоев и ошибок
3. Сложно внести изменения
4. Возрастает количество зависимостей

Была отдельная большая глава про обработку ошибок от сервисов и постепенной деградации.

Масштабирование сервисов

Запас на две ошибки

Правило лётчиков в том, что если ты не можешь сделать манёвр, то у тебя должен быть запас высоты на две ошибки. Очень клёвое правило и дальше были простые вычисления для примера: Есть сервис на 300 rps, сколько нужно узлов для 1000 rps? Очевидный ответ - 4 (1000/300 ~ 3.33, ближайшее целое 4), но в этой ситуации при выходе из строя ноды каждая получает 333 rps и это вызовет каскадный отказ. При 5 узлах мы начинаем работать когда вышибает одну ноду, но если идёт деплой и вышибло одну ноду, то снова скатываемся в предыдущую ситуацию, поэтому идеально иметь запас на две ошибки.

Домашка

Сколько нужно узлов для обработки 10000 rps, если одна нода обрабатывает 300 rps? Если у нас два датацентра и нам необходимо обеспечить отказ на уровне датацентра? А если у нас 6 дата центров? :)

Владение сервисами

• Все сервисы закреплены за командами разработки
• Ни один сервис не закреплен за несколькими командами
• Команда может отвечать за несколько сервисов
• На командах полный цикл: от архитектуры до мониторинга и решения проблем
• Между сервисами есть четкие границы и документированное API
• Между сервисами установлено SLA, о нарушениях которых оповещается команда-владелец

Классы сервисов

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

• Класс 1 - тяжелые последствия, пример: сервис обработки заказов
• Класс 2 - неприятное взаимодействие с сервисом для клиента, пример: сервис поиска
• Класс 3 - незаметное или почти незаметное взаимодействие, пример: сервис рекомендаций
• Класс 4 - никакого негативного влияния на клиентов, пример: сервис генерации отчётов

Использование классов сервисов

• Ожидания - какая у сервиса должна быть надёжность и доступность?
• Реагирование - насколько быстро надо реагировать на проблему в сервисе?
• Зависимости - какие классы у сервисов от которых зависите? Как мы должны обрабатывать отказы: деградировать или умирать?

SLA

Почему SLA важны и особенно внутренние?

• Создание доверия
• Упрощение диагностики проблем
• Измерение производительности

Как ставить SLA?

• SLA должны быть релевантны потребителям иначе они не SLA
• Желательно, иметь как можно меньше метрик
• Желательно, иметь одни SLA на всех потребителей

Примеры SLA про магазин высокоуровнего:

• Доступность - “наш магазин доступен не менее чем 99,4% времени”
• Время загрузки - “страницы открываются менее чем за 4 с в 99% случаях”
• Продукты - “как минимум 80% наших товаров в каталоге находится на складе”

Облачные сервисы

Там было про AWS, Lambda и прочее. Похоже на маркетинговый булшит, ничего полезного.

Вопросы к сервисам на основе предложенной книги

1. Есть ли у вас матрица рисков?
2. Есть ли SLA для сервисов?
3. Есть ли несколько команд, которые владеют одним сервисом?