Первоначально опубликовано на Неудача неизбежна Анкет
Это вторая статья серии из двух частей. Нажмите Здесь Для первой части интервью с Брайаном, Кэрри, JP и ZAC, чтобы узнать больше о Twitter SRE.
Ранее мы видели, как SRE в Twitter трансформировал свою инженерную практику, чтобы повысить готовность к производству в масштабе. Концепция целей уровня обслуживания (SLO) и бюджеты ошибок были ключом к этому преобразованию, поскольку SLO формируют способность организации принимать ориентированные на данные решения в отношении надежности. (Читайте здесь для определения SLO и как они преобразовали Evernote.). Сегодня команда Twitter инвестировала в централизованный инструмент для измерения, отслеживания и визуализации SLO и их соответствующих бюджетов ошибок.
Тем не менее, успешно внедрение SLO гораздо легче сказать, чем сделать. Многие организации боролись с усыновлением по ряду причин. Обычные препятствия включают в себя заинтересованность в бай-ин, не зная, что (и как) измерить, и путаницу в том, как сделать SLO действующими.
В то время как команда инженеров в Твиттере заложила очень прочную основу вокруг наблюдаемости и надежности, потребовалось несколько важных прорывов, прежде чем SLO начали достичь более широкого принятия в организации, и путешествие продолжается.
До SLOS инженеры использовали индикаторы уровня обслуживания (SLIS) в течение многих лет. SLIS вытащил из обширных инструментов Twitter инфраструктуры и инвестиций в их стек наблюдений. Их стек наблюдений обеспечил основу для измерения здоровья обслуживания с такими показателями, как показатель успеха, задержка и пропускная способность в их экосистеме распределенного обслуживания. Например, команда будет следить за уровнем успеха для пользовательских услуг HTTP, которые они вычисляют, изучая ошибки HTTP 500 в сравнении с общими запросами.
Интеграция SLIS с оповещениями и ротациями по вызову была основной практикой в их инженерных командах в течение многих лет. Кроме того, их внимание к управлению инцидентами и посмертными средствами позволило им постоянно учиться на своей всегда развивающейся производственной экосистеме.
Значительная точка перегиба была связана с внедрением концепции SLO в Finagle, библиотеке RPC Twitter, которая поддерживается командой библиотеки Core Systems (CSL). Как упоминалось в предыдущем посте, Finagle обеспечивает функции надежности, такие как балансировка нагрузки, выключатели цепи, детекторы сбоев и многое другое, заполняя их внутри каждой отдельной части программного обеспечения, которое работает. В 2018 году команда CSL сделала SLOS первоклассной сущностью во внутренней версии Finagle в Твиттере, создав основополагающий строительный блок API, который привязан к границе обслуживания, который они называют целью. Это было преобразующе в том смысле, что это позволило команде начать определение взаимодействия с обслуживанием к услугам и моделировать за пределами предупреждения, создавая программное определение, которое команда теперь могла бы использовать для информирования решений времени выполнения.
Команда Twitter поддержала реализацию с предложениями для проектов и вариантов использования, которые могли бы использовать функцию SLO, и первоначально предоставила конфигурацию, а также измерение SLO в реальном времени в реальном времени.
На своих начальных этапах принятие этой функции было ограничено. Владельцы услуг могут настроить SLOS, но из -за отсутствия инструментов и преимуществ, автоматически связанных с включением SLO, было мало стимулов для этого в контексте других приоритетов.
Видя это, команда инвестировала в последующую работу. Они начали создавать интеграцию и решения для владельцев услуг на вершине SLO, таких как нагрузка на основе SLO, поскольку они обеспечивали более полезный контекст, чем связанная метрика, такая как дросселя процессора. Благодаря пилотированию таких улучшений, аппетит к усыновлению начал расти.
Размышляя о том, как определить SLOS, команда Twitter обычно начинается с учета того, какие функции являются ключевыми, и гарантируя, что они хорошо оснащены и поняты.
Важно определить сигналы, которые наилучшим образом отражают критический пользовательский опыт. Некоторые сигналы для успеха обслуживания могут обеспечить цвет, но не так просты для интерпретации. Например, при анализе частоты ошибок услуг внутри центра обработки данных клиент может повторно повторить эти запросы, что делает его неисправным данным, чтобы рассуждать о том, что такое истинный показатель успеха пользователя.
Как только команда установит разумный SLO на верхнем уровне, это будет проходить через сервисы, от которых зависит граница. Каждая услуга имеет множество зависимостей обслуживания, и, следовательно, задержка и успешные SLO для всех всплывающих и нижних услуг должны работать вместе в контексте определенной границы. SLOS обеспечивает более целостный способ измерения всего пути вызова.
Внедрение бюджетов по ошибкам ознаменовало еще одну критическую точку перегиба в принятии SLO в Твиттере. Бюджеты по ошибкам делают SLOS действенными и предоставляют другой объектив для понимания услуги с течением времени, поэтому они были важной последующей функцией после первоначальной доставки SLO.
Бюджеты ошибок со временем смотрят на SLO и, следовательно, позволили команде начать отслеживание производительности, предоставляя историческое представление о том, как сервис достигает целей в разные сроки. Традиционный метрический вид имеет тенденцию быть недальновидным и может похоронить сигналы вокруг ценных тенденций и возможностей. Вместо приборной панели, которая намещает сотни метрик, бюджеты ошибок становятся поднужденной функцией, чтобы выбрать несколько наиболее важных показателей, и углубиться в то, как и почему они меняются со временем.
Важным примечанием является то, что команда не предписывает фиксированный набор действий после истощения бюджета ошибок. В то время как бюджеты ошибок могут быть мощным инструментом, истинное значение должно резонировать с инженерными командами и командами продуктов.
Например, одна команда предположила, что бюджет ошибок поможет информировать, когда могут пройти автоматические развертывания, и, в частности, сделать то, чтобы сделать развертывание, если бюджет ошибок был исчерпан. Но они обнаружили, что иногда развертывание приостановлено или заблокированное, может содержать исправление для увеличения ошибок. Таким образом, это простое правило «развертывания блоков, если ни один бюджет ошибок» быстро начал разваливаться. Самое развертывание, которое заблокировало, может уменьшить объем или скорость ошибок и, возможно, даже защитить SLO и позволить его встретить в течение оставшегося продолжительности времени.
Имея в виду, что они не обязательно должны быть предписывающими, бюджеты ошибок дают очень полезные предложения для владельцев услуг, думая о том, как расставить приоритеты в работе. Они создают важную «взлетно -посадочную полосу» для масштабирования темпов инноваций вверх или вниз. Например, чрезмерно быстрый бюджет ошибок может стать признаком приоритетов в смягчении работы для текущего вызовов или предстоящего спринта. В качестве альтернативы, недостаточное использование бюджета по ошибкам может быстрее подталкивать команду на работу по функциям или экспериментировать больше.
В то время как команда все еще в начале принятия SLO, они уже видели огромный потенциал и ценность SLO несколькими способами.
От «распределенного зоопарка» до общего языка
В Twitter есть сотни, если не тысячи услуг, что делает свою инфраструктуру сложным зверями. Текущие участники командного центра Twitter (TCC) были достаточно долго, где они обычно знают, что такое большинство услуг и как услуги «объединяются». Тем не менее, они знают, что в конечном итоге они достигнут точки, когда это станет невозможным, где ни один человек не сможет Грока, как все это работает. Инвестируя в SLOS сейчас, чтобы помочь провести обсуждения, цель состоит в том, что к тому времени, когда они достигнут этой точки не известной сложности, они будут настроены для программного управления метриками обслуживания.
Правильное количество контекста
Контекст является ключом. Монитоны могут легко иметь сотни графиков, которые переводят в тысячи метрик. Команды могут иметь десятки или сотни оповещений в своих услугах в нескольких центрах обработки данных. Эти информационные панели, метрики и оповещения полезны для тех, кто управляет этими услугами, но они очень высокий контекст и информационная перегрузка для кого -либо еще.
SLO создают возможность иметь более направленные разговоры с общим контекстом. Вместо того, чтобы смотреть на сотню фотографий приборной панели, команда может выровнять четыре или пять вещей, которые имеют значение. Любой из них не зеленый, другие могут понять, что что -то не так, не зная ничего другого в службе.
Динамическая балансировка нагрузки и выброс нагрузки
Сделав SLOS первым классовым объектом, услуги могут говорить на уровне программирования, помимо простого измерения. Это позволяет команде вносить систематические улучшения, используя SLOS в качестве строительного блока. Например, команда изучает, может ли вместо этого быть на основе SLO на основе Finagle.
С помощью Finagle службы могут программно обнаружить, когда они находятся под нагрузкой (обычно с сигналами второго класса, такими как процессор), а затем сигнализировать о перенаправлении трафика в другой экземпляр. Вместо того, чтобы полагаться на сигналы второго класса для реализации обратного давления, служба может непосредственно знать, является ли она тенденцией к нарушению SLO, чтобы сигнализировать о обратном давлении и уменьшить нагрузку на себя.
Изящная деградация
Одна из целей команды Twitter для SLO заключается в изящном ухудшении услуг во время крупномасштабных мероприятий, чтобы гарантировать, что основная функциональность всегда доступна. Вместо того, чтобы режим неудачи «все или ничего», команда стремится изящно ухудшать услуги, отбрасывая периферийные функции, сохраняя при этом основную функциональность.
Команда Twitter заинтересована в использовании SLO для реализации селективного шаблона выключателя схемы для повышения общей надежности системы. Владельцы услуг могут решить, какие вышестоящие услуги необходимы для основной функциональности, а какие необходимы только для надстройки или наворотов. Служба вверх по течению, которая не очень важна для одной услуги, может иметь решающее значение для других. Потребляемая служба может реализовать автоматический выключатель для обнаружения и прекращения отправки трафика в услуги, испытывающие высокую частоту ошибок.
В Твиттере ответственность ориентирована на товарищей по команде, несущих ответственность за то, что они планируют сделать продвижение вперед. Поскольку одним из наиболее важных аспектов эффективных операций является безупречная культура, SLO никогда не связаны с индивидуальными показателями эффективности. Скорее, цель состоит в том, чтобы определить или реализовать больше SLO, чтобы получить большую видимость и понимание, а не обвинять команды в том, что они не встречаются с ними.
Оригинал: «https://dev.to/blameless/slo-adoption-at-twitter-25n4»