Очередное занятие курса “Otus PHP professional“ посвящено понятию надежности работы сайта. После этого занятия вы сможете использовать лучшие практики обеспечения производительности и отказоустойчивости. Мы рассмотрим базовые принципы построения отказоустойчивых систем; термины SLAs, SlIs, SLOs; лучшие практики обеспечения надежности работы сайтов и организации SRE-взаимодействия.

  • Преподаватель: Михаил Каморин

  • Дата и время: 14 июня, вторник в 20:00

  • Длительность занятия: 90 минут

/**/

Карта курса

Цели вебинара


1. SRE ~ Инжинерия недежности сайтов

Термин SRE

Site Reliability Engineering ~ Проектирование надежности сайта

Зона ответственности SRE

Метрики SRE

Примеры:

  • SLI ~ допустимое число ошибок

(звезда) Пример хорошего SLO = 99,99% — это 8.6 сек в сутки или 13 мин в квартал

Пример: если downtime при деплое =10 сек, то в месяц можно сделать не более 80 деплойментов при указанном SLO (можно посчитать).

Вопросы SRE

Ответы: (…)


2. Автоматизация рутинных задач

Источники рутинных задач

Управление рутинными задачами

(звезда) пример “человека за ширмой“: взаимодействие админа с юзером через чаи-бота

(звезда) способы самообслуживания: например, это система тикетов в саппорт

(звезда) единообразие: объединяем схожие задачи в одну (пример: разные, но похожие отчеты для разных отделов)

(звезда) риски автоматизации: безработица среди людей ) например, если после автоматизации прибыль не растет , то зачем орна нужна (и зачем увольнять людей?)

Вопросы атоматизации рутинных задач

Ответы:

  1. д.б. оценена частота возникновения задачи, сколько времени требуется на ее выполненри, время на ее автоматизацию и сколько задача проживет; (звезда) м.б. ошибка проектирования, если возникает часто? тогда нужен рефакторинг

  2. да, если атоматизация ускорит выполнение задачи

  3. нет, если задача легко автоматизируется; да, если нужно срочно решать задачу, то можно завести “человека за ширмой“, затем уже плавно заменить его на робота; возможно, если человек делает что-то сложно формализумое/автоматизируемое (ручная работа и т.п.)


3. Лучшие практики ~ Best code practices

Глубокая защита (Defense in depth)

Постепенная деградация

(звезда) пример: уменьшение качества видео на ютубе при уменьшении скорости соединения

(звезда) пример: поддержка всех бразуеров, с исключениями по ходу уже

Вопросы по Best code practices

Ответы:

  • разные каналы оповещений, либо мониторинг для мониторинга )

  • ?

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


4. Конфигурирование лучших парктик

Философия конфигурирования

Механика конфигугрирования

(звезда) пример с авто-откатом: изменение разрешения экрана (возврат назад, если не подтвердил измегнения разрешения нажатием “Ок”); хорошо иметь такую систему авто-отката и в веб-системах (например, в конструкторах сайтов — когда можно “напортачить“ и все сломается, иметь возможность сбросить правки).


5. Исправление ошибок лучших практик

Организация мониторинга

  • Алерты

  • Тикеты

  • Протоколы

Учения по оперативной готовности

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

Аварийное устранение ошибок

На что следует обращать внимание SRE :

Планирование масштабирования

Планирование масшитабирования: задача

Ответы:

  • 37 копий нужно для пиковой нагрузки (с запасом), с учетом того что 1 деплоится, в то время как ост работают; +1 копия для случая что кто-то ляжет

  • для геогр. разделения: 14+2 для Сев Америки, 3+2 для Юж Америки, и т.п.Ю, итого +7 лишних копий; но можно сократить до +2 , если катить последовательно по странам (а не одновременно);


Дополнительные вопросы


Tags

Нет комментариев

Добавить комментарий

Ваш адрес email не будет опубликован.

Этот сайт использует Akismet для борьбы со спамом. Узнайте, как обрабатываются ваши данные комментариев.