Сертификация GCP (серия 12 деталей)
В предыдущем посте я поделился изучением, что SLI должен быть выражен как соотношение между двумя числами. Это Хорошие события над Действительные события
Работая таким образом, это позволяет нам гарантировать, что SLI падает в процентах от 0% до 100%.
- 0% ничего не работает
- 100% ничего не сломано
Это означает, что он интуитивно понятен и напрямую переводится на целевые показатели SLO и концепцию бюджетов ошибок.
Кроме того, из -за согласованного процентного формата это означает, что строительство инструментов для отслеживания ваших SLI стало проще. Оповещение, SLO Reporting и т. Д. Можно записано, чтобы ожидать той же структуры. Хорошие события, действительные события и ваш Slo -порог (ы).
Может быть заманчиво рассмотреть все события. Однако формулирование Действительно важно, поскольку это позволяет четко заявить о событиях, которые не будут рассмотрены.
НАПРИМЕР. Вы можете получить некоторый уровень ботов, получающих доступ к вашему сайту, влияя на выполнение их запросов. Когда вы узнаете о производительности SLI, вы можете исключить их из действительных событий. Другим примером может быть то, что у вас есть сотни возможных вызовов HTTPS API Но вы уменьшаете объем мониторинга SLI до определенных путей запроса. Итак, все Действительно Пути — это те, которые находятся в этой области.
Доступность
Чтобы использовать SLI для доступности, есть два варианта:
- Какие запросы должны отслеживать как Действительно
- Что делает ответ успешный
Используя уже покрытые термины, это может быть выражено как доля Действительно Запросы обслуживались успешно Анкет
Возможно, вам потребуется написать сложную логику, чтобы определить, насколько доступна система, такая как то, совершил ли пользователь полное путешествие пользователя, дисконтируя, где он мог бы добровольно выйти из процесса.
Например, приложение электронной коммерции может иметь путешествие:
Search => view => Добавить в корзину => Checkout => Покупка => Подтверждение
Однако люди могут «бросить» на любых этапах (независимо от того, насколько доступна система), поэтому измерение SLI должно учитывать только полные поездки пользователей.
Задержка
Для веб -приложения, как и доступность, мы можем определить его как долю Действительно Запросы обслуживались быстрее чем порог.
Итак, снова есть два варианта:
- Какие запросы должны отслеживать как Действительно
- Когда таймер должен запустить и остановиться для этих действительных запросов
Установка порога для достаточно быстро зависит от того, насколько точно измеренная задержка приводит к пользовательскому опыту и более тесно связана с целевым показателем SLO. Например, вы можете спроектировать систему, чтобы дать восприятие скорости с помощью таких методов, как предварительное извлечение или кэширование.
Обычно вы можете установить порог в 95% всех запросов, будет реагировать быстрее, чем порог. Однако вполне вероятно, что люди все еще будут счастливы, если присутствует более низкий процент, и, как правило, результаты будут длинным хвостом. НАПРИМЕР. Некоторые люди получат очень медленный опыт, но небольшой процент. Таким образом, возможно, стоит установить пороговые значения, которые нацелены на 75% до 90% запросов.
Задержка — это не просто запрос/ответ. Там могут быть сценарии, такие как обработка конвейера данных, где задержка приходит для игры.
НАПРИМЕР. Если у вас есть пакетный конвейер, который выполняется ежедневно, то для завершения необходимо не занять более 24 часов.
Примечание о задержке отслеживания заданий — это когда предупреждения запускаются. Если вы сообщаете только о том, что партийное задание завершилось, и пропустило цель задержки, то вы станете проблемой, вы станете проблемой.
Давайте предположим, что порог 60 минут для партийной работы, но работа занимает 90 минут и вызывает предупреждение SLO. Было 30 -минутное окно, где мы не знали о чем -то, что сломало SLO.
Качественный
Возвращаясь к нашему проценту, качество может быть выражено, понимая два значения. Доля Действительно Запросы, поданные без Уничтожение качества Анкет Это оставляет наш выбор как:
- Какие запросы должны отслеживать как Действительно
- Как определить, был ли ответ с унижение качества
Подобно задержке, можно было бы установить цели SLO через спектр из -за их взаимодействия с целевым SLO.
Программа, которую я изучаю, дает пример веб -приложения, которое вентиляет запросы на 10 серверов, каждый из которых имеет 99,9% доступность SLO, и каждый бэкэнд имеет возможность отклонять запросы при перегрузке.
Таким образом, вы можете сказать, что что -то вроде 99% ответов на обслуживание не имеют отсутствия ответов на бэкэнд. Кроме того, 99,9% имеют менее 1 отсутствующего ответа на бэкэнд. Иллюстрировано ниже:
Сертификация GCP (серия 12 деталей)
Оригинал: «https://dev.to/eggsy84/gcp-devops-certification-day-ten-5d0g»