Первоначально опубликовано на Бесплатный блог Отказ
Традиционно разработанные инженеры были связаны своими руками, когда они просят инвестиции в сокращение технического долга. Изменения архитектуры, рефакторист кода и замедление разработки функций для наличия продукта — в основном желаемое мышление, даже если эти усилия неизбежно становятся критическими важными для каждой компании. Если фиксация по техническому долгу не обрабатывается или не разобрано, продукт компании и здоровье бизнеса будут страдать. Когда вы должны иметь дело с вашим техническим долгом? Как вы можете принести команду лидерства на борту? Что связано с этими вопросами?
Цветеный болтался с лидером Sre Garrett Plasky, чтобы получить ответы. Команда Garrett Sre из 15-20 инженеров 15-20 отвечает за сохранение света, A.K.a. Управляя производственной инфраструктурой для Evernotes более 220 млн. Пользователей на 5 миллиардов ресурсов. Их продукт представляет собой кроссплатформенную заявку SaaS, предназначенное для того, чтобы люди могли организовать, персонализировать, потреблять и делиться мыслями из любого устройства в любое время.
В любое время вы идете к лидерам с «вот мою проблему. Мы должны инвестировать в нашу архитектуру. «Они говорят:« Что данные? » Вы идете, «вот мой slo диаграмма».
В любое время вы идете к лидерам с «вот мою проблему. Мы должны инвестировать в нашу архитектуру. «Они говорят:« Что данные? » Вы идете, «вот мой slo диаграмма».
С этой целью SLOS является критической частью доставки кода до вашей производственной среды. Наличие SLOS на месте для ваших производственных услуг позволяет удалить эмоцию и двусмысленность, когда речь идет о том, чтобы выяснить влияние незапланированного отключения или ошибки, выпущенной до производства.
SLOS, SLIS и SLA используются исключительно для метрик, которые захватывают опыт ваших пользователей, такие как наличие, задержка запроса, пропускной способности и частота ошибок и т. Д.
SLO , Объектив уровня обслуживания, является внутренней целью для метрики, которую вы измеряете.
SLI , Индикатор уровня обслуживания, это имя для метрики. Например, если SLI вы измерили, это доступность, то соответствующая SLO, которую вы можете установить, будет 99,95%, будет 99,95%. Комплексное SLO — это арт в себе, но в конечном итоге вы должны стремиться установить цель, которая находится выше точки При котором ваши пользователи чувствуют боль, а также то, что вы можете реально встречаться (то есть SLOS не должны быть аспирационными).
SLA , Соглашение о уровне обслуживания, является внешней метрикой, которую вы юридически обязаны встречаться, такие как 99% для наличия. Когда вы не встретите свою SLA, вы компенсируете клиентов долларами. Вот почему вы хотите установить свои SLOS быть более строгими, чем ваши SLA.
Как ваши DevOps, так и команды разработки продукта несут ответственность за удовлетворение SLO. Это оказывает давление на обе направления. Мы встречаемся в SLO? Если это так, инжиниринг продукта может работать быстрее. Мы не? Теперь нам нужно вернуть давление от операций — как мы исправм причину, по которой мы не встречаем наш SLO.
Бюджет ошибок 1 минус SLO. Продолжая примеру, ежемесячный бюджет на 0,05% на доступность (на основе целевой доступности 99,95%) означает, что ваш сервис может быть недоступным в течение 22 минут в этом месяце. Ошибка мин/месяц x 0,05% = ~ 22 мин/месяца практика побуждает вас стратегически сжечь бюджет до нуля каждый месяц, будь то его для функций запуска или архитектурные изменения. Таким образом, вы знаете, что вы работаете так быстро, как можете без ущерба для доступности.
Каждый месяц я представляю, насколько хорошо мы встречались с нашими SLOS. Один барный график, который я использую, показывает нашу производительность для доступности на нашем SLO для каждого месяца в течение последних 6 месяцев. График SLO помогает нам привести к решению дорожной карты продукта. Когда предмет архитектуры склонна к неудаче и заставить нас не соответствовать нашему слову, мы можем сделать сознательное решение для инвестирования времени (или нет), чтобы сделать его лучше. Без SLO отслеживания у нас не было бы данных о оправдывании времени инвестиций в архитектуру.
Это было очень полезно для руководства, чтобы получить видимость нашего SLO. Недавно наш новый SVP инжиниринга пришел на встречу обзора службы, где я представлял наш производительность против наших SLOS. У нас был не так великий месяц. Он прыгнул прямо и спросил: «Так что мы делаем с этим?» Он задавал все соответствующие вопросы, не требуя никакого контекста. Он только что получил это!
Граф SLO вызвал большой разговор, который привел к нему, говоря: «Давайте удвоиться на некоторые из этих инвестиционных усилий архитектуры, о которых мы говорили!»
Граф SLO вызвал большой разговор, который привел к нему, говоря: «Давайте удвоиться на некоторые из этих инвестиционных усилий архитектуры, о которых мы говорили!»
В конечном итоге, это возвращается к доступности. Люди ожидают, что когда они делают вещи на телефоне, он сразу доступен по всему миру для кого-то другого, чтобы увидеть. Если это ожидание ваших пользователей, то вы должны служить этому. Для того, чтобы служить этому, вы должны быть доступны. Вот почему важно установить и встретить SLO для наличия.
В Evernote мы в настоящее время мы измеряем доступность на уровне Shard, а также в общем ведре обслуживания. Мы используем внешние зонды, которые удалили конечную точку Health Check на нашем обслуживании и возвращают успех или не удалите. Этот зонд делается каждую минуту на каждом хосте. Мы измеряем количество успехов по всем точкам данных о здоровье в течение определенного периода времени для определения доступности.
Точно нет. Я увлечен непринужденными постмерками, начиная до того, как я даже знал о SRE. Речь идет не о том, кто споткнулся через шнур питания? », Но« Как мы можем помешать людям отключить через шнур питания в следующий раз? ».
Это не о том, кто споткнулся через шнур питания? », Но« Как мы можем помешать людям отключить через шнур питания в следующий раз? ».
Я также создал шаговую функциональную графику для ожога бюджета ошибок. Линия на графике начинается сверху слева и провавает, как лестница для каждого экземпляра ожога бюджета ошибок. Отслеживая и агрегируя ключевые причины этих инцидентов, и анализируя, какие из них сжигают больше бюджета, чем другие, мы можем предпринять активные меры, чтобы предотвратить или управлять рискованными причинами в будущем.
Авансовые инвестиции на создание приборов, визуализации и сбора данных потребовали 2-3 инженерам около месяца для завершения. Каждый месяц я провожу день, чтобы собрать презентацию с помощью SQL-запросов и графиками.
Я благодарен, что мой VP в то время был одинаково увлечен реализовать бюджеты SLOS и ошибок. Он помог усилить идеи внутри компании. Наши SLOS кодифицируются во внутреннем докторе Evernote, к которому все в компании есть доступ. Первый раз, когда я представлял SLO Graph и Budget Budget Burn, был в команде SRE, и несколько сверстников в области инженерии. Со временем присоединились больше людей, включая вращающуюся экипаж людей, подобных нашим клиенту, другие инженерные менеджеры, и даже наш финансовый директор.
Как компания SaaS, наши пользователи доверяют нам, чтобы не потерять свои данные и хранить их навсегда. Они доверяют, чтобы они могли использовать Evernote, когда они хотят, где бы они ни были. Мы стремимся поддерживать этот доверие.
Как компания SaaS, наши пользователи доверяют нам, чтобы не потерять свои данные и хранить их навсегда. Мы стремимся поддерживать этот доверие.
Написано Чарли Тейлор
Оригинал: «https://dev.to/blameless/garrett-plasky-shares-how-slos-transformed-evernote-429g»