Книга мне понравилась своей лаконичностью так, что советую прочитать чеклист на основе её и сделать вывод хотите ли вы читать её полностью. Весь чек лист разбит на основе оглавления из книги, поэтому можете читать выборочно.
Здесь и далее следует понимать, что все примеры старались проводиться либо из опыта, либо на основе типичного магазина по продаже футболок
Доступность
В чем разница между надежностью и доступностью?
- Надежность - способность системы выполнять требуемые действия, не допуская ошибок.
- Доступность - готовность системы к работе при необходимости выполнить требуемые действия.
Как улучшить доступность?
- Учитывайте возможные отказы
- Всегда помните о масштабировании (прим. от меня и ограничениях)
- Смягчайте последствия рисков (понравился пример что если не работает поиск на сайте футболок, выдавайте временно топ предложения)
- Контролируйте доступность (== мониторинг)
- Disaster recovery policy (прим. от меня старайтесь строить self-recovering processes в системах)
Какая доступность является нормальная?
Определите сами на основе таблицы: 99% - 432 минуты даунтайма в месяц 99,9% - 43 минуты 99,99% - 4 минуты 99,999% - 26 секунд
Управление рисками
Принцип управления рисками
- Составить матрицу рисков (шаблон)
- Важно понимать, что у риска есть вероятность и критичность, для этого примеры:
- Список топ-10 футболок: низкая вероятность и низкая критичность.
- База данных с заказами: низкая вероятность и высокая критичность.
- Загрузка сторонних шрифтов: высокая вероятность и низкая критичность.
- Фотографии футболок: высокая вероятность и высокая критичность.
- Важно понимать, что у риска есть вероятность и критичность, для этого примеры:
- Ликвидация самых опасных рисков.
- Смягчение последствий рисков, которые нельзя исключить.
- Итерируй матрицу рисков или см п.1
Дальше в главе написано примеры конкретных действий по каждому из пунктов. Из интересного забавным показалось, что можем сделать запас на 6 серверов приложения, но они все в одной стойке/питании и на самом деле это не резервирование. (Привет, Selectel)
Сервисы
Что такое сервис
- Собственная кодовая база
- Управлять собственными данными
- Предоставлять возможности другим сервисам
- Пользоваться возможностями других сервисов
- Иметь единственного владельца-команду.
- В книге уточняется что одна команда может владеть несколькими сервисами, но не наоборот. (P.s. не согласен полностью)
Как делить
- Разделение по бизнес-требованиям (legal, security)
- Разделение по зонам ответственности (management)
- Разделение по роду данных (domain)
- Разделение возможностей или информации (reusable apps)
Сложности
- Нет общей картины
- Благоприятная среда для сбоев и ошибок
- Сложно внести изменения
- Возрастает количество зависимостей
Была отдельная большая глава про обработку ошибок от сервисов и постепенной деградации.
Масштабирование сервисов
Запас на две ошибки
Правило лётчиков в том, что если ты не можешь сделать манёвр, то у тебя должен быть запас высоты на две ошибки. Очень клёвое правило и дальше были простые вычисления для примера: Есть сервис на 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 и прочее. Похоже на маркетинговый булшит, ничего полезного.
Вопросы к сервисам на основе предложенной книги
- Есть ли у вас матрица рисков?
- Есть ли SLA для сервисов?
- Есть ли несколько команд, которые владеют одним сервисом?