Русский
Русский
English
Статистика
Реклама

Site reliability engineering

Цель SRE надёжная система. Обзор основных метрик SRE

27.10.2020 04:14:55 | Автор: admin

Site Reliability Engineering (SRE) это одна из форм реализации DevOps. SRE-подход возник в Google и стал популярен в среде продуктовых IT-компаний после выхода одноимённой книги в 2016 году.


В статье опишем, как SRE-подход соотносится с DevOps, какие задачи решает инженер по SRE и о каких показателях заботится.



От DevOps к SRE


Во многих IT-компаниях разработкой и эксплуатацией занимаются разные команды с разными целями. Цель команды разработки выкатывать новые фичи. Цель команды эксплуатации обеспечить работу старых и новых фич в продакшене. Разработчики стремятся поставить как можно больше кода, системные администраторы сохранить надёжность системы.


Цели команд противоречат друг другу. Чтобы разрешить эти противоречия, была создана методология DevOps. Она предполагает уменьшение разрозненности, принятие ошибок, опору на автоматизацию и другие принципы.


Проблема в том, что долгое время не было чёткого понимания, как воплощать принципы DevOps на практике. Редкая конференция по этой методологии обходилась без доклада Что такое DevOps?. Все соглашались с заложенными идеями, но мало кто понимал, как их реализовать.


Ситуация изменилась в 2016 году, когда Google выпустила книгу Site Reliability Engineering. В этой книге описывалась конкретная реализация DevOps. С неё и началось распространение SRE-подхода, который сейчас применяется во многих международных IT-компаниях.


DevOps это философия. SRE реализация этой философии. Если DevOps это интерфейс в языке программирования, то SRE конкретный класс, который реализует DevOps.


Цели и задачи SRE-инженера


Инженеры по SRE нужны, когда в компании пытаются внедрить DevOps и разработчики не справляются с возросшей нагрузкой.


В отличие от классического подхода, согласно которому эксплуатацией занимается обособленный отдел, инженер по SRE входит в команду разработки. Иногда его нанимают отдельно, иногда им становится кто-то из разработчиков. Есть подход, где роль SRE переходит от одного разработчика к другому.


Цель инженера по SRE обеспечить надёжную работу системы. Он занимается тем же, что раньше входило в задачи системного администратора, решает инфраструктурные проблемы.


Как правило, инженерами SRE становятся опытные разработчики или, реже, администраторы с сильным бэкграундом в разработке. Кто-то скажет: программист в роли инженера не лучшее решение. Возможно и так, если речь идёт о новичке. Но в случае SRE мы говорим об опытном разработчике. Это человек, который хорошо знает, что и когда может сломаться. У него есть опыт и внутри компании, и снаружи.


Предпочтение не просто так отдаётся разработчикам. Имея сильный бэкграунд в программировании и зная систему с точки зрения кода, они более склонны к автоматизации, чем к рутинной администраторской работе. Кроме того, они имеют больший багаж знаний и навыков для внедрения автоматизации.


В задачи инженера по SRE входит ревью кода. Нужно, чтобы на каждый деплой SRE сказал: OK, это не повлияет на надёжность, а если повлияет, то в допустимых пределах. Он следит, чтобы сложность, которая влияет на надёжность работы системы, была необходимой.


  • Необходимая сложность системы повышается в том объёме, которого требуют новые продуктовые фичи.
  • Случайная сложность системы повышается, но продуктовая фича и требования бизнеса напрямую на это не влияют. Тут либо разработчик ошибся, либо алгоритм не оптимален.

Хороший SRE блокирует любой коммит, деплой или пул-реквест, который повышает сложность системы без необходимости. В крайнем случае SRE может наложить вето на изменение кода (и тут неизбежны конфликты, если действовать неправильно).


Во время ревью SRE взаимодействует с оунерами изменений, от продакт-менеджеров до специалистов по безопасности.


Кроме того, инженер по SRE участвует в выборе архитектурных решений. Оценивает, как они повлияют на стабильность всей системы и как соотносятся с бизнес-потребностями. Отсюда уже делает вывод допустимы нововведения или нет.


Целевые показатели: SLA, SLI, SLO


Одно из главных противоречий между отделом эксплуатации и разработки происходит из разного отношения к надёжности системы. Если для отдела эксплуатации надёжность это всё, то для разработчиков её ценность не так очевидна.


SRE подход предполагает, что все в компании приходят к общему пониманию. Для этого определяют, что такое надёжность (стабильность, доступность и т. д.) системы, договариваются о показателях и вырабатывают стандарты действий в случае проблем.


Показатели доступности вырабатываются вместе с продакт-оунером и закрепляются в соглашении о целевом уровне обслуживания Service-Level Objective (SLO). Оно становится гарантом, что в будущем разногласий не возникнет.


Специалисты по SRE рекомендуют указывать настолько низкий показатель доступности, насколько это возможно. Чем надёжнее система, тем дороже она стоит. Поэтому определите самый низкий уровень надёжности, который может сойти вам с рук, и укажите его в качестве SLO, сказано в рекомендациях Google. Сойти с рук значит, что пользователи не заметят разницы или заметят, но это не повлияет на их удовлетворенность сервисом.


Чтобы понимание было ясным, соглашение должно содержать конкретные числовые показатели Service Level Indicator (SLI). Это может быть время ответа, количество ошибок в процентном соотношении, пропускная способность, корректность ответа что угодно в зависимости от продукта.


SLO и SLI это внутренние документы, нужные для взаимодействия команды. Обязанности компании перед клиентами закрепляются в в Service Level Agreement (SLA). Это соглашение описывает работоспособность всего сервиса и штрафы за превышение времени простоя или другие нарушения.


Примеры SLA: сервис доступен 99,95% времени в течение года; 99 критических тикетов техподдержки будет закрыто в течение трёх часов за квартал; 85% запросов получат ответы в течение 1,5 секунд каждый месяц.


Почему никто не стремится к 100% доступности


SRE исходит из предположения, что ошибки и сбои неизбежны. Более того, на них рассчитывают.


Оценивая доступность, говорят о девятках:


  • две девятки 99%,
  • три девятки 99,9%,
  • четыре девятки 99,99%,
  • пять девяток 99,999%.

Пять девяток это чуть больше 5 минут даунтайма в год, две девятки это 3,5 дня даунтайма.



Стремиться к повышению доступности нормально, однако чем ближе она к 100%, тем выше стоимость и техническая сложность сервиса. В какой-то момент происходит уменьшение ROI отдача инвестиций снижается.


Например, переход от двух девяток к трём уменьшает даунтайм на три с лишним дня в год. Заметный прогресс! А вот переход с четырёх девяток до пяти уменьшает даунтайм всего на 47 минут. Для бизнеса это может быть не критично. При этом затраты на повышение доступности могут превышать рост выручки.


При постановке целей учитывают также надёжность окружающих компонентов. Пользователь не заметит переход стабильности приложения от 99,99% к 99,999%, если стабильность его смартфона 99%. Грубо говоря, из 10 сбоев приложения 8 приходится на ОС. Пользователь к этому привык, поэтому на один лишний раз в год не обратит внимания.


Среднее время между сбоями и среднее время восстановления MTBF и MTTR


Для работы с надёжностью, ошибками и ожиданиями в SRE применяют ещё два показателя: MTBF и MTTR.


MTBF (Mean Time Between Failures) среднее время между сбоями.


Показатель MTBF зависит от качества кода. Инженер по SRE влияет на него через ревью и возможность сказать Нет!. Здесь важно понимание команды, что когда SRE блокирует какой-то коммит, он делает это не из вредности, а потому что иначе страдать будут все.


MTTR (Mean Time To Recovery) среднее время восстановления (сколько прошло от появления ошибки до отката к нормальной работе).


Показатель MTTR рассчитывается на основе SLO. Инженер по SRE влияет на него за счёт автоматизации. Например, в SLO прописан аптайм 99,99% на квартал, значит, у команды есть 13 минут даунтайма на 3 месяца. В таком случае время восстановления никак не может быть больше 13 минут, иначе за один инцидент весь бюджет на квартал будет исчерпан, SLO нарушено.


13 минут на реакцию это очень мало для человека, поэтому здесь нужна автоматизация. Что человек сделает за 7-8 минут, скрипт за несколько секунд. При автоматизации процессов MTTR очень часто достигает секунд, иногда миллисекунд.


В идеале инженер по SRE должен полностью автоматизировать свою работу, потому что это напрямую влияет на MTTR, на SLO всего сервиса и, как следствие, на прибыль бизнеса.


Обычно при внедрении автоматизации стараются оценивать время на подготовку скрипта и время, которое этот скрипт экономит. По интернету ходит табличка, которая показывает, как долго можно автоматизировать задачу:


Всё это справедливо, но не относится к работе SRE. По факту, практически любая автоматизация от SRE имеет смысл, потому что экономит не только время, но и деньги, и моральные силы сотрудников, уменьшает рутину. Всё это вместе положительно сказывается на работе и на бизнесе, даже если кажется, что с точки зрения временных затрат автоматизация не имеет смысла.


Бюджет на ошибки


Как мы выяснили, пытаться достичь 100% стабильности не самая лучшая идея, потому что это дорого, технически сложно, а часто и бесполезно скорее всего, пользователь не оценит старания из-за проблем в соседних системах.


Поэтому команды всегда принимают некоторую степень риска и прописывают её в SLO. На основе SLO рассчитывается бюджет на ошибки (Error budget).



Бюджет на ошибки помогает разработчикам договариваться с SRE.


Если бюджет на ошибки содержит 43 минуты даунтайма в месяц, и 40 минут из них сервис уже лежал, то очевидно: чтобы оставаться в рамках SLO, надо сократить риски. Как вариант, остановить выпуск фич и сосредоточиться на баг-фиксах.


Если бюджет на ошибки не исчерпан, то у команды остаётся пространство для экспериментов. В рамках SRE подхода Error budget можно тратить буквально на всё:


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

Чтобы не выйти за рамки, Error budget делят на несколько частей в зависимости от задач. Каждая команда должна оставаться в пределах своего бюджета на ошибки.



В ситуации профицитного бюджета на ошибки заинтересованы все: и SRE, и разработчики. Для разработчиков такой бюджет сулит возможность заниматься релизами, тестами, экспериментами. Для SRE является показателем хорошей работы.


Эксперименты в продакшене это важная часть SRE в больших командах. С подачи команды Netflix её называют Chaos Engineering.


В Netflix выпустили несколько утилит для Chaos Engineering: Chaos Monkey подключается к CI/CD пайплайну и роняет случайный сервер в продакшене; Chaos Gorilla полностью выключает одну из зон доступности в AWS. Звучит дико, но в рамках SRE считается, что упавший сервер это само по себе не плохо, это ожидаемо. И если это входит в бюджет на ошибки, то не вредит бизнесу.


Chaos Engineering помогает:


  1. Выявить скрытые зависимости, когда не совсем понятно, что на что влияет и от чего зависит (актуально при работе с микросервисами).
  2. Выловить ошибки в коде, которые нельзя поймать на стейджинге. Любой стейджинг это не точная симуляция: другой масштаб и паттерн нагрузок, другое оборудование.
  3. Отловить ошибки в инфраструктуре, которые стейджинг, автотесты, CI/CD-пайплайн никогда не выловят.

Post mortem вместо поиска виноватых


В SRE придерживаются культуры blameless postmortem, когда при возникновении ошибок не ищут виноватых, а разбирают причины и улучшают процессы.


Предположим, даунтайм в квартал был не 13 минут, а 15. Кто может быть виноват? SRE, потому что допустил плохой коммит или деплой; администратор дата-центра, потому что провел внеплановое обслуживание; технический директор, который подписал договор с ДЦ и не обратил внимания, что его SLA не поддерживает нужный даунтайм. Все понемногу виноваты, значит, нет смысла возлагать вину на кого-то одного. В таком случае организуют постмортемы и правят процессы.


Мониторинг и прозрачность


Без мониторинга нельзя понять, вписывается ли команда в бюджет и соблюдает ли критерии, описанные в SLO. Поэтому задача инженера по SRE настроить мониторинг. Причём настроить его так, чтобы уведомления приходили только тогда, когда требуются действия.


В стандартном случае есть три уровня событий:


  • алёрты требуют немедленного действия (чини прямо сейчас!);
  • тикеты требуют отложенного действия (нужно что-то делать, делать вручную, но не обязательно в течение следующих нескольких минут);
  • логи не требуют действия, и при хорошем развитии событий никто их не читает (о, на прошлой неделе у нас микросервис отвалился, пойди посмотри в логах, что случилось).

SRE определяет, какие события требуют действий, а затем описывает, какими эти действия должны быть, и в идеале приходит к автоматизации. Любая автоматизация начинается с реакции на событие.


С мониторингом связан критерий прозрачности (Observability). Это метрика, которая оценивает, как быстро вы можете определить, что именно пошло не так и каким было состояние системы в этот момент.


С точки зрения кода: в какой функции или сервисе произошла ошибка, каким было состояние внутренних переменных, конфигурации. С точки зрения инфраструктуры: в какой зоне доступности произошел сбой, а если у вас стоит какой-нибудь Kubernetes, то в каком поде, каким было его состояние при этом.


Observability напрямую связана с MTTR. Чем выше Observability сервиса, тем проще определить ошибку, исправить и автоматизировать, и тем ниже MTTR.


SRE для небольших компаний и компаний без разработки


SRE работает везде, где нужно выкатывать апдейты, менять инфраструктуру, расти и масштабироваться. Инженеры по SRE помогают предсказать и определить возможные проблемы, сопутствующие росту. Поэтому они нужны даже в тех компаниях, где основная деятельность не разработка ПО. Например, в энтерпрайзе.


При этом необязательно нанимать на роль SRE отдельного человека, можно сделать роль переходной, а можно вырастить человека внутри команды. Последний вариант подходит для стартапов. Исключение жёсткие требования по росту (например, со стороны инвесторов). Когда компания планирует расти в десятки раз, тогда нужен человек, ответственный за то, что при заданном росте ничего не сломается.


Внедрять принципы SRE можно с малого: определить SLO, SLI, SLA и настроить мониторинг. Если компания не занимается ПО, то это будут внутренние SLA и внутренние SLO. Обсуждение этих соглашений приводит к интересным открытиям. Нередко выясняется, что компания тратит на инфраструктуру или организацию идеальных процессов гораздо больше времени и сил, чем надо.


Кроме того, для любой компании полезно принять, что ошибки это нормально, и начать работать с ними. Определить Error budget, стараться тратить его на развитие, а возникающие проблемы разбирать и по результатам разбора внедрять автоматизацию.


Что почитать


В одной статье невозможно рассказать всё об SRE. Вот подборка материалов для тех, кому нужны детали.


Книги об SRE от Google:
Site Reliability Engineering
The Site Reliability Workbook
Building Secure & Reliable Systems


Статьи и списки статей:
SRE как жизненный выбор
SLA, SLI, SLO
Принципы Chaos Engineering от Chaos Community и от Netflix
Список из более чем 200 статей по SRE


Доклады по SRE в разных компаниях (видео):
Keys to SRE
SRE в Дропбоксе
SRE в Гугл
SRE в Нетфликсе


Где поучиться


Одно дело читать о новых практиках, а другое дело внедрять их. Если вы хотите глубоко погрузиться в тему, приходите на онлайн-интенсив по SRE от Слёрма. Он пройдет 1113 декабря 2020.


Научим формулировать показатели SLO, SLI, SLA, разрабатывать архитектуру и инфраструктуру, которая их обеспечит, настраивать мониторинг и алёртинг.


На практическом примере рассмотрим внутренние и внешние факторы ухудшения SLO: ошибки разработчиков, отказы инфраструктуры, наплыв посетителей, DoS-атаки. Разберёмся в устойчивости, Error budget, практике тестирования, управлении прерываниями и операционной нагрузкой.


Узнать больше и зарегистрироваться

Подробнее..

Митап по SRE вторник, 3 ноября, 1900 по Москве

28.10.2020 14:12:50 | Автор: admin


Слёрм приглашает на митап Профессия SRE: практика и мифы. Поговорим про SRE с экспертами, обсудим вопросы участников.
Повестка дня:


  • Что такое SRE и зачем все это нужно IT и бизнесу?
  • SRE хайп или проверенный подход?
  • Как с этим работать?
  • Практики SRE.
  • Как внедрить у себя?
  • Что нужно, чтобы стать SRE-инженером?

Начало митапа: 3 ноября, вторник, 19.00 МСК.


Эксперты


Артём Артемьев. Lead SRE в Inspectorio. Знает, как помочь команде встретиться с SLI и жить дружно. Имеет успешный опыт в инцидент-менеджменте и мониторинге сложных решений, perfomance-тестировании и борьбе за каждый RPS.


Павел Селиванов. Senior DevOps Engineer в Mail.ru Cloud Solutions. На счету десятки выстроенных инфраструктур и сотни написанных пайплайнов CI/CD. Сертифицированный администратор Kubernetes. Автор нескольких курсов по Kubernetes и DevOps. Регулярный докладчик на Российских и международных IT конференциях.


Ведущий митапа: Марсель Ибраев, СТО Слёрм.


Регистрация


Приходите, будем рады встрече и вашим вопросам!

Подробнее..

Как Лёха стал инженером по SRE выдуманная история про невыдуманные проблемы

06.11.2020 16:10:59 | Автор: admin

Направление Site Reliability Engineering становится всё более популярным. Хайп не на пустом месте: проблемы и задачи, которые решает SRE, действительно насущны для многих компаний.

Популярность SRE растёт, но знаний о нём всё ещё недостаточно. Я не буду повторять формальные определения, а вместо этого расскажу несколько историй из жизни системного инженера Лёхи. Путь выдуманного Лёхи во многом похож на путь, который прошли реальные крупные компании, где впервые и возникли SRE-инженеры (даже если назывались иначе).

Через историю Лёхи вы узнаете о задачах, которые решает SRE, и причинах, по которым для решения этих задач пришлось выделять отдельный класс инженеров.

Глава 1. Hope is not a strategy

Утро понедельника, инженеру эксплуатации Лёхе звонит разработчик Толя:

У нас проблема! Ошибки в сервисе Плутон.

Подробности будут?

Там какие-то проблемы при работе с внешними ресурсами. Надо срочно починить! У нас всё лежит в проде.

Хорошо, сейчас посмотрим.

За пару минут Лёха выясняет, что Плутон это третьестепенный сервис, который обращается во внешние ресурсы и получает от них не очень важные данные. Обработка ошибок в нём не предусмотрена, поэтому если Плутон недоступен, то всё ломается. Плюс выяснилось, что до одного из внешних сервисов есть потери пакетов у магистрального провайдера.

Там потери у магистрального провайдера, часть запросов теряются.

Ну и? Когда починишь?

Эм, что? Это не у нас проблема, это у магистрального провайдера!

Ну значит, звони магистральному провайдеру, пусть срочно чинят!

Серьезно? Да им пофиг на нас. Могу позвонить в администрацию президента, толку и то больше будет

Ну тогда звони нашему провайдеру, пусть с магистральным разберётся, мы платим за сетевое соединение, всё должно быть доступно на 100%!

Станция пожаротушения в ЦОД SelectelСтанция пожаротушения в ЦОД Selectel

До перехода в эксплуатацию Лёха 3,5 года работал программистом. Он решил вспомнить прошлое и написал маленький патч для Плутона с возможностью автоматически выполнять retry в течение заданного времени.

А диалога про 100% доступность могло бы не состояться, если бы Толик понимал: рассчитывать, что хоть один сервис в мире (да что там в мире, в галактике!) имеет 100% доступность, глупо. Сколько бы ты ни платил денег, это недостижимо. В погоне за 100% доступностью можно растратить весь бюджет, но так и не достигнуть её. Куда лучше быть готовым к нестабильности и уметь с ней работать.

Леха понимает, что 100% доступность чего угодно невозможна, но он не разработчик, хоть у него и есть опыт работы разработчиком, это не его зона ответственности. Толик разрабатывает приложения и мог бы научить приложение работать стабильно в нестабильных условиях. Если приложение попадет в зону ответственности Лехи, то мы получим первого SRE.

Сложность систем и взаимодействия между ними, а также требование стабильной работы в нестабильных условиях привели к тому, что знаний одного только разработчика или инженера эксплуатации стало недостаточно. Требовались люди, которые сочетают в себе умения двух специальностей.

Почему никто не стремится к 100% доступности? спросил Толя

100% доступность невозможна и бессмысленна. Надо исходить из предположения, что ошибки и сбои неизбежны, и также учитывать стабильность работы внешних компонентов, таких как браузер, мобильная ОС, сеть клиента, так как их надежность зачастую ниже даже 99%, и наши усилия будут незаметны для пользователя . Более того, предстоящие сбои надо учитывать при разработке и эксплуатации.

Оценивая доступность, говорят о девятках:

  • две девятки 99%,

  • три девятки 99,9%,

  • четыре девятки 99,99%,

  • пять девяток 99,999%.

Пять девяток это чуть больше 5 минут даунтайма в год, две девятки это 3,5 дня даунтайма.

Стремиться к повышению доступности нормально, однако чем ближе она к 100%, тем выше стоимость и техническая сложность сервиса. В какой-то момент происходит уменьшение ROI отдача инвестиций снижается.

Например, переход от двух девяток к трём уменьшает даунтайм на три с лишним дня в год. Заметный прогресс! А вот переход с четырёх девяток до пяти уменьшает даунтайм всего на 47 минут. Для бизнеса это может быть не критично. При этом затраты на повышение доступности могут превышать рост выручки.

При постановке целей учитывают также надёжность окружающих компонентов. Пользователь не заметит переход стабильности приложения от 99,99% к 99,999%, если стабильность его смартфона 99%. Грубо говоря, из 10 сбоев 8 будет приходится на сбои, связанные с работой смартфона, а не самого сервиса. Пользователь к этому привык, поэтому на один лишний раз в год не обратит внимания.

Глава 2. Нестабильность сохраняется

Прошло несколько недель. Лёха расслабился и спокойно занимался привычной работой.

Но однажды вечером пятницы, за 20 минут до конца рабочего дня, в кабинет ворвался технический директор Иван Эрнестович.

Сударь, а вы осведомлены, что у вас приложение работает из рук вон плохо? Я бы даже сказал, отвратительно.

Произносит он это без мата и криков, спокойным тихим голосом, отчего становится еще страшнее. Мониторинг не сообщал ни о каких инцидентах, поэтому придётся выяснять подробности.

Добрый вечер, Иван Эрнестович. А не могли бы вы рассказать, почему сделали такой вывод? Давайте начнём по порядку: о каком приложении речь?

Я сожалею, что вы не осведомлены о проблемах, но коль уж так, извольте слушать. Во время обеда с партнёром решил я рассказать ему про наш новый продукт Русь. А он в ответ: Да слышал я, и даже заходил поглядеть, но так и не дождался загрузки главной страницы. Я ринулся проверять и тут же сам убедился в его словах (лицо Ивана Эрнестовича изобразило отчаяние).

Мониторинг молчит, но я сейчас все проверю. Изволите ожидать, или отправить результаты расследования почтой?

Я подожду.

Быстрый обзор системы мониторинга показал, что все показатели в рамках нормы. В частности, за последние 3 часа было всего ~ 1000 неуспешных запросов (неуспешными по мнению Лехи считаются только те запросы, на которые был получен 50x код ответа).

Проверил данные системы мониторинга, за последние часы было всего 1000 неуспешных запросов, новый сервис работает.

Сколько? И вы смеете называть это работает? Это недопустимый показатель!

Вы, как всегда, правы, Иван Эрнестович. 1000 неуспешных запросов звучит грустно. Но это всего 1.5% от общего количества запросов. А это, согласитесь, не так уж и плохо.

Действительно, 1.5% не так страшно, но все ж почему мы не смогли открыть приложение?

А вы, говорите, обедали? В таком случае, проблема может быть не с нашим приложением, а с мобильным интернетом или Wi-Fi в ресторане.

Не исключено. Но 1000 запросов это много, будьте любезны с этим разобраться.

Конечно, я уже завёл задачу, мы проведём диагностику и пришлём отчёт.

И прекратите пугать людей большими цифрами! Жду предложение по изменению системы мониторинга. Твоя идея с соотношением мне понравилась, надобно ее проработать.

С этими словами Иван Эрнестович удалился, а наш герой Лёха выдохнул, дооформил задачу по инциденту, передал данные ночному дежурному и тоже удалился.

К причинам инцидента и отчету мы вернёмся чуть позже, а вот историю про метрики вынесем как вывод к этой главе. После этого диалога Лёха придумал систему оценки качества работы продукта и за выходные её прописал.

Фактически Лёха создал то, что сейчас обязательно используется в рамках SRE подхода:

Целевые показатели: SLA, SLI, SLO

Чтобы в следующий раз Иван Эрнестович не был удивлён, узнав о 1,5% проваленных запросов, Лёха выбрал ключевые метрики, по которым можно отслеживать, насколько стабильно работает наш сервис. Также предложил сразу установить для данных метрик границы, при пересечении которых команда, отвечающая за сервис, понимает, что все стало плохо и пора сфокусироваться над стабильностью. И даже придумал название для таких метрик: соглашение о целевом уровне обслуживания Service-Level Objective (SLO).

Это соглашение позволяет всем в компании прийти к общему пониманию, что такое надежность (стабильность, доступность) системы. Потому что без него надёжность заботит только отдел эксплуатации. Разработчики ей пренебрегают, а для бизнеса это вообще абстракция, и цифры только путают.

В SLO закрепляют целевые показатели доступности, которые вырабатывают вместе с продакт-оунером. То есть Лёха может их предложить, но утвердить не может. Здесь нужно согласие всех лиц, принимающих решение.

Чтобы понимание было ясным, соглашение должно содержать конкретные числовые показатели Service Level Indicator (SLI). Это может быть время ответа, количество ошибок в процентном соотношении, пропускная способность, корректность ответа что угодно в зависимости от продукта.

SLO и SLI это внутренние соглашения, нужные для взаимодействия команды. Обязанности компании перед клиентами закрепляются в Service Level Agreement (SLA). Это соглашение описывает работоспособность всего сервиса и штрафы за превышение времени простоя или другие нарушения.

Примеры SLA: сервис доступен 99,95% времени в течение года; 99 критических тикетов техподдержки будет закрыто в течение трёх часов за квартал; 85% запросов получат ответы в течение 1,5 секунд каждый месяц.

Среднее время между сбоями и среднее время восстановления MTBF и MTTR

Чтобы избежать претензий, Лёха пошёл дальше сформулировал ещё два показателя: MTBF и MTTR.

MTBF (Mean Time Between Failures) среднее время между сбоями.

Показатель MTBF зависит от качества кода. То есть чем меньше будет косячить разработчик Толя, тем лучше будет показатель MTBF. Но поскольку каждый косяк Толи влияет на Лёху, у Лёхи должна быть возможность делать ревью кода и, в случае совсем уж очевидных проблем, говорить Нет!.

По крайней мере, это предполагает подход SRE. Он же предполагает понимание со стороны команды: когда SRE блокирует какой-то коммит, он делает это не из вредности, а потому, что иначе страдать будут все.

MTTR (Mean Time To Recovery) среднее время восстановления (сколько прошло от появления ошибки до отката к нормальной работе).

Показатель MTTR рассчитывается на основе SLO. Инженер по SRE влияет на него за счёт автоматизации. Например, в SLO прописан аптайм 99,99% на квартал, значит, у команды есть 13 минут даунтайма на 3 месяца. В таком случае время восстановления никак не может быть больше 13 минут, иначе за один инцидент весь бюджет на квартал будет исчерпан, SLO нарушено.

13 минут на реакцию это очень мало для человека, поэтому здесь нужна автоматизация. Что человек сделает за 7-8 минут, с тем скрипт справится за несколько секунд. При автоматизации процессов MTTR очень часто достигает секунд, иногда миллисекунд.

Бюджет на ошибки

Как мы выяснили, пытаться достичь 100% стабильности не самая лучшая идея, потому что это дорого, технически сложно, а часто и бесполезно скорее всего, пользователь не оценит старания из-за проблем в соседних системах.

Поэтому Лёха предложил ввести еще одно понятие бюджет ошибок. Это степень риска, которая допустима для данного сервиса, и ее можно прописать в SLO.

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

Если бюджет на ошибки содержит 43 минуты даунтайма в месяц, и 40 минут из них сервис уже лежал, то очевидно: чтобы оставаться в рамках SLO, надо сократить риски. Как вариант, остановить выпуск фич и сосредоточиться на баг-фиксах.

Если бюджет на ошибки не исчерпан, то у команды остаётся пространство для экспериментов.

Чтобы не выйти за рамки, Error budget делят на несколько частей в зависимости от задач. Каждая команда должна оставаться в пределах своего бюджета на ошибки.

Если это все будет внедрено, можно будет получить объективную картину, насколько стабильно работает наш сервис. Но остается одна серая зона: что делать, если бюджет на ошибки был исчерпан.

Лёха посчитал, что очень важно договориться об этом заранее и оформить в виде документа Error budget policy. Для примера он решил зафиксировать, что при исчерпании бюджета на ошибки останавливается вся разработка бизнес-функционала и вся команда работает над повышением стабильности. Лёха уверен: этот документ позволит избежать конфликтных ситуаций в и без того напряженной ситуации.

Леха закончил подготовку предложений и обнаружил, что уже вечер воскресенья, и уже совсем скоро опять на работу.

Глава 3. Post mortem

Придя в понедельник в офис, первым делом Лёха открыл результаты расследования инцидента. Увиденное не радовало. Небольшая цитата:

В период с 14-00 до 18-00 наблюдались проблемы с сервисом Русь. Они были связаны с тем, что сервис Плутон, от которого зависит наш сервис, переезжал в другой ДЦ и были потери пакетов. Написали служебку на запрет проведения работ в рабочее время для команды разработки и эксплуатации сервиса Плутон!

Лёха грустно вздохнул: от такого расследования проку мало, и принялся писать свой отчет для Ивана Эрнестовича.

Иван Эрнестович, наши отчеты об инцидентах, как и система мониторинга, деструктивны. Я подготовил собственный отчет, предлагаю данный вид документа сделать стандартным и назвать его, допустим, post-mortem. Цель этого документа не найти виноватых, а понять, в каких процессах есть проблемы и как можно их улучшить!

Что и когда произошло

16.10. 2015 19.45 поступила жалоба от Генерального директора о недоступности сервиса Русь, примерно в 16 часов.

16.10. 2015 19.55 Инженер по эксплуатации Анатолий по данным системы мониторинга зафиксировал 1000 неудачных запросов в период с 14 до 17 часов. В момент поступления жалобы инцидент уже был разрешен.

Причины и факторы

Нетехническая причина:

Переезд одного из микросервисов, от которого зависит сервис Русь во время повышенной нагрузки, без предупреждения команды сервиса Русь.

Техническая причина:

Отсутствие механизма повтора запросов у сервиса Русь.

Обнаружение

Жалоба генерального директора.

Решение

Инцидент был обнаружен уже после завершения, вмешательства со стороны службы эксплуатации не потребовалось.

Что прошло хорошо

В системе мониторинга присутствовали все необходимые графики.

В системе логирования был достаточный объем логов, чтобы установить причину появления неуспешных запросов.

Что можно улучшить

Разработать единую библиотеку, которая реализует функционал повтора запросов в случае кратковременной недоступности внешних сервисов. Данное решение было опробовано в рамках сервиса Русь и показало хорошие результаты.

Доработать систему алертов, чтобы получать уведомления о проблемах не от пользователей.

Внедрить метрики на основе соотношения успешных и неуспешных запросов.

Где нам повезло

Количество неуспешных запросов было 1.5%, и большинство пользователей не заметили проблему.

Задачи

RUS-347 доработка системы мониторинга. Добавление метрик соотношения неуспешных запросов к общему числу запросов.

RUS-354 разработка библиотеки для реализации механизма повтора неуспешных запросов.

Лёха сложил два документа в одно письмо и отправил их курьером Ивану Эрнестовичу, так как тот больше любил бумажные письма.

Прошло несколько недель, наш инженер Леха уже отчаялся получить хоть какую-то обратную связь, и уже даже почти перестал расстраиваться из-за зря потраченного времени. И тут раздается звонок от Ивана Эрнестовича:

Алексей, я рассмотрел твои предложения и сделал вывод, что на текущем месте работы ты работаешь неэффективно. Ты мог бы принести больше пользы моей компании, поэтому я перевожу тебя на новую работу. Ты будешь инженером по стабильности SRE. Даю тебе полгода, чтобы реализовать твои подходы и показать их эффективность.

P. S. история может показаться утрированной, таковой она и является. Примерно такой путь прошли компании, которые придумали SRE.

Так чем же будет заниматься инженер по SRE Лёха

  1. Формировать целевые показатели надёжности системы и поддерживать их.

  2. Проверять и оптимизировать код, опираясь на знания о надёжности системы.

  3. Анализировать возникающие ошибки. Делать выводы, писать скрипты автоматизации для разрешения проблем.

И это только малая часть обязанностей SRE-инженера. Если вам интересны подробности, то прочтите обзорную статью по SRE от Слёрма (выдержки из неё вошли в этот текст). В конце обзорной статьи вы найдёте ещё массу полезных ссылок.

А если есть желание попробовать свои силы на практике, то приходите на интенсив. Там будет много практических кейсов и практикующие SRE-инженеры из крупнейших ИТ-компаний мира.

Узнать подробности и записаться

Автор статьи: Владимир Гурьянов архитекторрешений Southbridge, Certified Kubernetes Administrator.

Подробнее..

Можно бить разработчиков за баги, а можно внедрить SRE о чём говорили на митапе Слёрма

17.11.2020 06:15:37 | Автор: admin


Зачем нужно SRE, когда есть DevOps, что такое SLO и бюджет на ошибки, каким компаниям точно не надо внедрять новую методологию, существуют ли джуниор-инженеры по SRE и сколько платят опытным. Об этом и не только говорили на митапе Слёрма Профессия SRE: практика и мифы.


На YouTube можно посмотреть видеозапись встречи, а здесь мы приводим текстовую версию разговора с некоторыми сокращениями.


Участники митапа:


  • Павел Селиванов DevOps Engineer в Mail.ru Cloud Solutions. Строит DevOps, CI/CD-процессы.
  • Артём Артемьев Lead SRE в компании Inspectorio. Помогает девопсам жить хорошо.
  • Марсель Ибраев CTO Слёрм.

Заметка на полях: Site Reliability Engineering (SRE) произносится на русском как эс-эр-и.


Что такое SRE и чем отличается от DevOps



Марсель Ибраев (МИ): Что такое SRE: это технология, методология или профессия? Что такое SRE простыми словами?


Поисковик мне выдал прекрасные статьи, где объясняется, что это набор методов, показателей и предписывающих способов обеспечения надёжности систем. На вики-словаре есть не менее интересное определение: это обеспечение надежной работы систем, обеспечение бесперебойной доступности сервисов. После такого объяснения я, разумеется, всё понял и проникся, но всё-таки, что такое SRE простыми словами?


Артём Артемьев (АА): Ты давно читал про DevOps? Забей в поиске, прочтёшь почти то же самое. На самом деле SRE это то, как в Google в своё время увидели DevOps. Получилось немного по-другому, но нечто очень похожее на DevOps.


Павел Селиванов (ПС): Тут я соглашусь. Google пишет, что SRE это практическая имплементация методологии DevOps. И мне правда кажется, что это так.


АА: Проблема только в том, что у нас нет нормального определения DevOps. У каждого DevOps сильно свой. SRE одна из разновидностей DevOps.


МИ: В Google, получается, взяли на себя смелость опубликовать своё видение.


АА: Кстати, интересно, что у Facebook тоже есть своё видение DevOps, просто Facebook об этом не написал книжку. Не рассказал, как у них это получилось. Но у них DevOps нет. У них operations отдается всем инженерам, все инженеры так или иначе занимаются operations. Но есть люди, которые занимаются инфраструктурой, и они называются продакшн-инженерами.


П: У меня даже есть идея, почему Google написал такую книжку, а Facebook нет. Потому что Facebook делает сервисы для себя по большей части, а Google для других. И когда Google надоело, что пользователи их хают, когда сервисы работают нормально, они попытались объясниться.


М: Получается, Google переварил DevOps, в итоге у них родился Site Reliability Engineering. Но почему тогда концепция стала такой популярной? Просто бренд сыграл, или эта штука действительно хорошо показывает себя на практике?


АА: Многие конторы ищут Святой Грааль: вот у нас всё плохо, но сейчас мы наймём DevOps и всё полетит. С DevOps не получилось, давай теперь переименуем его в SRE.


МИ: Звучит логично.


АА: Насколько популярно, не знаю. Думаю, если собрать статистику, в скольких компаниях есть SRE У вас в Mail.ru есть SRE?


ПС: Да.


АА: Больше, чем DevOps?


ПС: Скорее всего, да. Больше ли, чем админов я не уверен. Mail.ru придумала, как работать хорошо, задолго до появления Docker, SRE, DevOps и всего прочего. А так как компания большая, смысла менять своё на новое и хайповое нет. Это огромные усилия. Поэтому мы по многим, особенно глобальным вещам живём на наших внутренних регламентах и инструментах. А ими занимаются сисадмины.


МИ: Непопулярно.


ПС: Зато работает.


АА: Я ещё вижу в реалиях русскоговорящего рынка, что у нас есть проблема никто не понимает (по крайней мере, мало кто понимает), что есть проблема с DevOps. Что мы должны получить от внедрения DevOps? Как правило, все говорят про Continuous delivery, сбор метрик.


МИ: Ну да, построили пайплайны, и у нас как будто построен DevOps.


АА: Но по факту выходит, что метрики все зеленые, а пользователи жалуются. Инженеры говорят: всё хорошо, всё работает.


В Google придумали, что нужно подойти к пользователю как можно ближе, и важны не показатели, а SLO, которое получает пользователь. В итоге в компаниях возникает необходимость нанять еще девопсов, которые будут делать похожую работу, но по-другому. И как их назвать? О, давай назовём SRE.

МИ: Получается, SRE это реинкарнация, нечто, что получило физическую оболочку в рамках Google. Был некий DevOps, который все понимали по-своему, и Google не исключение, они тоже поняли это по-своему, набили кучу шишек и пришли к подходу, который назвали Site Reliability Engineering.


АА: Когда Google начал выдумывать SRE, ещё DevOps не был объявлен (хотя о нём впервые заговорили в 2000 году где-то во Франции, но это было ещё не широко). Ребята из Google не знали о DevOps, просто придумали то же колесо сами.


ПC: Мне тоже кажется, что DevOps был придуман в рамках каких-то встреч и конференций (как и Agile манифест в своё время), когда люди собрались и начали думать, как сделать так, чтобы всем стало хорошо. Собрались, придумали, и кто-то дальше эту идею развивал. А Google к этому подходил иначе, с точки зрения своих внутренних проблем. Они решали конкретную задачу, да, возможно, ту же самую задачу, что и комьюнити, и очень похожими средствами, но задача была полностью практическая. Нужно было решать конкретные вещи в конкретные сроки и конкретными действиями.


МИ: Означает ли это, что концепция SRE и весь его инструментарий подойдут далеко не всем? Если заработало у Google, не факт, что заработает у других?


АА: Аналогично и для DevOps. Но смотря про что говорить. Если про то, что надо мерить SLO со стороны пользователя, наверное, это почти всем подойдет. Если про подход катись как можно чаще, а ты запускаешь космические корабли, то катиться как можно чаще дорого и непонятно, надо тестировать больше.


МИ: Да, ко всему нужно подходить с головой и с пониманием, что ты делаешь, а не просто гнаться за хайпом.


Кто такой SRE-инженер? Почему это больше разработчик, чем админ



МИ: SRE называют концепцией или методологией, а это, я бы сказал, слова-паразиты, потому что сейчас так называют что ни попадя. Если мы говорим, что SRE это ряд конкретных практик и решений, придуманных в Google, было бы интересно послушать, чем конкретно должен заниматься SRE-инженер. Можно описать типовой день или неделю. Что он должен делать, какие у него обязанности?


АА: Google приводит сравнение SRE и DevOps. Там перечисляются все эти пункты и оказывается, что всё матчится друг в друга. Но самая большая разница, о которой говорит Google, они не нанимают operations или админов.
Они решили везде нанимать software engineer, которые умеют программировать которые очень ленивые, ничего не любят делать руками и чуть что пишут код. Но Google может себе позволить найти software-инженера, который очень хорошо разбирается в сети, системе, производительности и т. д.


В масштабах Google очень важно автоматизировать всё, что можно автоматизировать. Когда у тебя десять серверов можно сделать всё руками, а когда миллион тут уже не выйдет. Плюс человек умеет ошибаться, а робот нет. Так что принципиальная разница заключается в том, что мы нанимаем инженеров, которые пишут программы, чтобы те менеджирили operation-задачи.


МИ: То есть глобально SRE-инженер занимается автоматизацией?


АА: Старается заниматься. Ну и DevOps тоже. Большая задача SRE уметь падать и быстро чиниться. Та самая концепция Error budget.


Когда у тебя маленький стартап и не так много клиентов, ты быстро деплоишься, быстро бежишь, что-то сломал, но тебе не очень больно. Тебе важно донести ценности до пользователей и не страшно сломаться. Но на уровне Google все замедляется, все боятся что-то сломать. Темп доставки новых фич сильно уменьшается, все работают не спеша.


Концепция Error budget, когда сказано, что твой сервис 5% в месяц может быть сломанным, позволяет убедиться, что команда этого сервиса не замедлилась и бежит быстро. Move fast and break things не бояться немного сломать, но в то же время экспериментировать и доносить нужные ценности. Это второй аспект. Возможно, он важен только компаниям размера Google. Когда у тебя небольшая компания, вы и так все мотивированы и бежите вперёд. Error budget вас сильно не спасёт.


ПС: Прикол именно в том, что SRE это по большому счёту разработчик. Да, разрабатывать, естественно, это не единственная его функция, но именно майндсет разработчика, способность к разработке и реальный опыт программирования одна из ключевых вещей в этой профессии.


Марсель, ты говоришь, что SRE-engineer это человек, который должен заниматься автоматизацией. Мне кажется, это может вводить в заблуждение, потому что под словом автоматизация мы часто понимаем набор скриптов, который сделает grep в логи, положит в такой-то файлик, а дальше этот файлик по TCP отправит туда-то вот это автоматизация. Однострочник на Bash, скриптик на Python и так далее. Просто с этой точки зрения любой разработчик тоже занимается автоматизацией, но почему-то его работу мы автоматизацией не называем.


SRE все-таки такой автоматизатор, который не скриптики пишет (не только их, потому что для любого админа тоже никогда не было проблемой написать скриптик), но имеет майндсет разработчика и рассматривает проблемы инфраструктуры как софтварные проблемы, которые можно и нужно решать с помощью кода.

Все эти инфраструктурные инструменты, которых за последние лет пять появилось огромное количество, начиная от Kubernetes, системы мониторинга, кучи экспортеров того же Prometheus они гораздо сложнее, чем просто скрипт автоматизации. И вот эти все системы, мне кажется, появляются в том числе благодаря развитию SRE как направления и тому, что инфраструктурными задачами начинает заниматься разработчик.


Странно было бы заопенсорсить свой набор из миллиона bash-скриптов, zabbix-шаблонов и прочего. Вывалить это всё на гитхаб и сказать: вот, ребят, мы за десять лет существования компании накопили вот такую кучу нате. Понятно, что это ни у кого бы не взлетело. А вот инструменты, которые делают разработчики для поддержки инфраструктуры, они действительно новые и полезные.


Поэтому мне кажется, важно обращать внимание, что SRE это такой человек. Не факт, что это человек прямо из разработки, из админов тоже бывают SRE. Просто админ тогда должен быть такой, который имеет достаточный опыт разработки, в том числе и продакшн, промышленной. И прям хорошо и плотно в это погружён.


МИ: То есть SRE-инженер, как правило, из разработки. Появляется проблема, и он смотрит не на то, как это закостылить, а на то, как автоматизировать, и может написать программу или приложение, которое всё это будет обрабатывать. Ещё я слышал, что с SRE связаны системы мониторинга доступности, чтобы у нас приложение было доступно и соответствовало неким метрикам. Это тоже задача SRE-инженера? Его задача эти метрики настрААвать, отслеживать как он с ними работает?


АА: Метрики отслеживать не задача инженера SRE. Моя задача как инженера SRE сделать инструменты для команд, чтобы они понимали, сколько у них осталось SLO, почему он уменьшается и как выглядит работа их приложения, конкретного сервиса этой команды для конечного пользователя: какой был latency, сколько было ошибок и как это всё выглядело.


Они ко мне обращаются за помощью, когда видят, что тает их SLO и они не понимают почему. На авторизации логины стали длиннее на пару секунд, и они считают это нормальным, но это выпало из SLO, начинает выпадать из допустимого latency. Ко мне прям прибегали ребята из сервиса авторизации и спрашивали: почему у нас SLO тает, вчера было 3 секунды, а сегодня 3,5 секунды ничего страшного же. Но если вы договорились, что должно быть 3 секунды, то, ребят, извините.


Что такое SLO, SLA и Error Budget



МИ: А можешь расшифровать, что значат SLO, SLA, SLI?


АА: Думаю, все слышали про SLA (Service Level Agreement) это договор с любой компанией об уровне предоставления услуг, где компания обязуется, что 99% времени некий сервис будет работать.


МИ: Например, сервер на хостинге? То, что мы берём в аренду.


АА: Например, строка поиска в Google. Забиваешь, что нужно найти, а он тебе ищет. SLA там 99%. То есть Google сам говорит: зуб даю, что 99% будет.


При этом инженеры боятся, что они могут ошибиться и не попасть в эти 99%, и будет совсем больно. Поэтому внутри, у себя в команде, они договариваются: вот мы хотим, чтобы было 99.9%, тогда у нас есть в запасе 0,9%, и мы точно попадём. И вот этот их внутренний договор называется SLO.


МИ: Значит, SLA для внешних, а SLO внутри.


АА: И считается SLO по запросам от пользователя, как правило. Чем ближе к пользователю подошел, тем лучше. Идеально, если в java-скрипте тусуются отдельные элементы в браузере, и этот скрипт репортит куда-то о том, что не удалось аджаксом скачать какой-то кусочек элемента. Потому что часто, если у нас упал самый главный nginx, то это у нас в nginx логов нет, значит запросов нет, latency хорошие, всё хорошо. А тут java-скрипт начнет говорить, что есть ошибка. Либо, если это мобильный клиент, он прямо с мобилки сыплет свои ошибки, это просто идеально: мы всё знаем и считаем.


И есть ещё SLI (Service Level Indicator) это те параметры, о которых мы говорим. Например, задержка для клиента, как быстро он скачал страницу это один SLI. Либо количество ошибок, сколько клиентов у нас получили пятисотый статус ответа вместо двухсотого это второй SLI. Вот два очень распространенных SLI: latency и количество ошибок.


М: Ну и про Error budget расскажи. Я так понимаю, это некий бюджет, который закладывается на ошибки, на простой. Если команда разработки и в целом проект его превышает, то что-то происходит. Правильно ли я понимаю?


АА: Когда мы зафиксировали SLO и сказали, что обязуемся, чтобы 99.9% запросов валидно ответили пользователю, то у нас остались 0.01% запросов к сервису, которые могут пофейлиться. Если у нас там миллион запросов, то 0.01 от миллиона считаем. Это и есть наш Error budget или бюджет на ошибки.


Когда у нас есть в запасе эта цифра, мы в некоторых ситуациях можем не думать, что написали код, который не очень протестирован. Если у нас полно Error budget, мы можем не тратить ещё неделю на тестирование кода, а прямо сейчас выкатить его, потому что нам очень надо посмотреть, как он работает (понятно, что при этом мы должны уметь быстро откатываться и выкатывать код не на всех пользователей, а на 5%). Если код начал валиться, мы его откатили, перестали вести на него трафик и немного потратили своего Error budget. Но это позволило нам очень быстро проверить гипотезы и доставить ценности.


С другой стороны, если мы полностью потратили свой Error budget, нам нужно очень хорошо тестировать код и смотреть, на что мы его потратили: если у нас часто отваливалась база данных, то самое время отложить бэклог и заняться автоматическим переключением баз данных на slave.


ПС: Мне кажется, Error budget ещё очень полезен для оценки, какие решения сейчас нужно внедрять, в каких решениях назрела необходимость. Предположим, у нас есть сервис, который в теории доступен 100% времени. Он работает без ошибок, мы его не разрабатываем или нечасто деплоим, новые ошибки туда не приезжают. А когда мы его деплоим, у нас нет никакого rolling updates и вот этих всех модных штук, мы просто выключаем и включаем заново. И смотрим, что, например, генерируем таким образом энное количество ошибок.


При этом мы понимаем, что если деплоим раз в какое-то количество времени, то, даже несмотря на то, что никакой системы rolling updates нет, такие деплои за рамки Error budget не выходят. И это такой прекрасный показатель сказать, когда команде нужно задумываться о технических вещах. Вот сейчас назрел момент, мы начали выходить за Error budget, давайте его пофиксим хотя быть тем, что начнём выкатываться без простоя. Или мы действительно можем выкатываться с простоем.


SRE-инженер это клей, а SRE это хайп?



МИ: Если всё сложить, то получается, что SRE-инженер это некий человек, который мыслит одновременно и в плоскости инфраструктуры, доступности приложений и в плоскости разработки. Некий клей, который связывает эти два дела и думает больше о конечном клиенте и доступности, чем о написании кода или настройке Terraform и подобных вещах. Он вне рутины и визионирует эти процессы.


ПС: С точки зрения DevOps мы стремимся сделать некую инфраструктуру и создать такую ситуацию, в которой за свои приложения, в том числе и в продакшене, отвечает команда разработки. Команда сопровождения в таком случае поддерживает инфраструктуру и какие-то общие вещи, типа кластеров баз данных, кластеров очередей. Отдельная команда в виде девопсов или сама команда сопровождения реализует способы максимально автоматической работы для разработчика: доставлять свой код до продакшена, тестировать и так далее.


То есть, в DevOps команда разработки уже отвечает не только за то, чтобы код написать, кинуть админам и сказать, нате, деплойте, админы там подеплоят, поймут, что ничего не деплоится, вернут разработчикам; разработчик скажет: у меня работает, у вас не работает, идите разбирайтесь классический конфликт. В рамках философии DevOps разработчик отвечает за свой код: и написание, и его работу в продакшене.


В таком случае SRE-инженер никакой не клей, а админ, который теперь отвечает не только за работу в продакшене, но в том числе и разбирается в коде. И нет никаких разных целей у отдела сопровождения и отдела разработки. Есть одна цель рабочий продукт, который нужно сделать. Это не тот продукт, который никогда не падает (сервер, отключённый от питания, тоже никогда не падает) рабочий продукт это штука, которая приносит деньги компании. А для этого он: а) должен работать, б) должен обновляться. Так что отделы разработки и SRE реализуют одну цель.


МИ: Окей, с задачами SRE разобрались. Теперь другой вопрос: шумиха вокруг SRE это хайп, или все-таки у подхода есть реальное будущее? Второй Kubernetes или временное явление?


АА: Сложно сказать, DevOps это хайп или уже не хайп? Наверное, уже не хайп. Но если SRE это случай DevOps, то кто-то будет его использовать, а кто-то нет.


МИ: Мне кажется, хайп спадет, но останутся те, кто нашёл в этом пользу. На первый план выйдет что-то другое.


ПС: Как называть это в будущем SRE или DevOps это уже проблема будущих людей, а вот что инфраструктурой начнут заниматься люди, которые с руками, с головой и умеют код писать думаю, это весьма вероятно.


МИ: Меня пугает, что компании ищут людей, которые на все руки мастера. Могут и код написать, и инфраструктуру поднять, и винду настроить, и принтер починить. Просто сисадмины уже теряют актуальность. Возможно, в будущем просто разработчики тоже будут терять актуальность? Или нет?


АА: Тут сложно говорить, потому что компаниям нужна стабильная работа, а как называются те, кто умеет делать твой сервис стабильным, неважно. Просто в какой-то момент сисадмины поссорились с разработчиками, зависели друг от друга, но не договаривались. Тогда придумали DevOps, чтобы подружить их, и для бизнеса DevOps стал очень выгоден: со всех сторон бенефиты.


В какой-то момент DevOps чуть-чуть изменил свой курс от того, что ребята придумывали, и теперь он больше про деливери и измерения, инженерный аспект разработки. Он ушёл далеко от ощущений самих пользователей.


По сути, DevOps может делать и работу SRE измерять значения максимально близко к пользователю и знать, как часто сервис падает. Но в текущих реалиях DevOps немного не про это. Случилось культурное изменение. И тут на сцену выходит SRE, и компании понимают, что им нужен ещё один DevOps, но он будет не DevOps, а SRE. Очень часто люди, работающие над DevOps и SRE могут быть взААмозаменяемыми.

ПС: Вот ты Марсель говоришь, человек, который умеет всё. Но я не согласен. Артём, как ты думаешь, бывают ли джуниор SRE-инженеры?


АА: Думаю, даже бывают SRE-интерны.


ПС: Наверное, бывают разных способностей люди. Если есть какая-то система обучения SRE, то интерна можно себе представить. Но по моему опыту, SRE-инженер это такой человек, который видел разработку (если он со стороны разработчика, то минимум стал мидлом), который занимался многими вещами в компании, в том числе видел администрирование и сопровождение представляет, что там ребята делают.


Поэтому прийти и в первый год работы всего этого набраться, будучи джуниором SRE, мне кажется, вряд ли возможно. Нужно специальное место, где учат только SRE. Поэтому, это, скорее, не человек, который всё умеет, а человек, который достаточно опытен и при этом по своим софт-скиллам сложен таким образом, что разбирается в проблемах, в том, в чем он работает, и способен с этим работать комплексно.


Как внедрить SRE в компании



МИ: Внедрение SRE, как и DevOps, это революция или эволюция? Стоит ли пушить решение о том, что нам нужен SRE или DevOps в компании?


ПC: SRE это всё-таки конкретная, понятная методология, и в ней должна быть потребность. Поэтому путь внедрения SRE эволюционный. Cделать SRE из состояния мы классическая компания, у нас половина на железных серверах, половина на ноутбуке под столом я боюсь, что не выйдет. Потому что будут люди, которые скажут, что это абсолютная фигня от смузи-админов, разработчиков в узких джинсах и т. д.


Мне понравился доклад на одной из конференций. Там был тезис, что DevOps нельзя внедрить насильственно. Единственный вариант разогнать всю команду и набрать другую из людей, которые с DevOps знакомы. А чтобы никого не разгонять, надо взять несколько админов и послать на DevOps-конференцию. Пусть они послушают, поплюются, расскажут всем, что это фигня. Взять потом других админов или разработчиков, отправить туда. И постепенно за годик-два компания начнёт гореть идеями DevOps и со стороны разработки, и со стороны администрирования. Тогда команды сами придут к бизнесу и скажут: Чуваки, мы тут такую штуку знаем, давайте мы её внедрим. Из такого состояния SRE можно, пожалуй, считать революционным. Но когда нет никакого движения, никакой основы, то ничего не получится.


АА: Я вполне согласен с Павлом. Ещё часто SRE, как и DevOps, могут заносить сами владельцы бизнеса, которые хотят стабильности. Но насильно в инженера не занесёшь, надо продать, а продать тяжело, если кто-то упирается.


ММ: Мы сейчас по большей части поговорили про инженеров-разработчиков. Есть ли у вас представления, на какие аспекты работы проекта стоит обратить внимание с бизнесовой части? Как бизнес может понять, что им нужен SRE или какой-то другой подход в управлении проектами?


АА: Тут всегда простой вопрос как чувствуют себя пользователи? Например, если пользователи жалуются, а графики все зеленые.


ПС: В целом да.


SRE это же одно из возможных решений. Если есть проблема с доступностью сервиса, стабильностью, можно задуматься об SRE. Или в то же время задуматься о введении каких-нибудь KPI, кнутов на входе, и начать разработчиков бить за баги. Тоже как вариант, наверное, тоже может работать. SRE точно не будет серебряной пулей, которая спасёт от всего. Но вот проблему стабильности, проблемы в организации IT-команды, когда есть классический конфликт между администрированием и разработкой, решить поможет.

Что должен знать SRE-инженер и сколько может зарабатывать



МИ: Как вообще вот этим мифическим SRE-инженером стать? Что нужно сделать? Какими скиллами обладать, чтобы претендовать на такую позицию?


ПС: Я недавно размышлял над этим вопросом. Думаю, особенно у нас, в России, есть проблема. Вот если бы конкретный живой человек спросил у меня, я бы ему рассказал об определённых вещах, на которые нужно посмотреть. Он бы пришёл в первую попавшуюся компанию, где нужен SRE, а ему бы начали задавать вопросы о рейдах, например, или еще каких-то странных вещах. И тут вопрос: когда вы в современной компании последний раз видели живой рейд и зачем? Наверное, это полезно знать, но честно мне это сейчас не нужно в моей работе, и я на эти вопросы не отвечу. В большинстве случаев это не задача SRE. Есть, конечно, системщики, которые этим занимаются. Но у большинства компаний не железные сервера, а есть какое-то облако, купленное или свое, и приложение нужно эксплуатировать в рамках этого облака.


Программирование нужно при собеседовании точно. Я вот недавно общался с коллегами из Тинькова, и они сказали, что админы приходит на позицию SRE, их начинают спрашивать про какие-нибудь бинарные деревья, и они прям обижаются я же админ, зачем меня по программированию гонять?


Современные DevOps-инструменты типа infrastructure as code, инструменты оркестрации, как Kubernetes, инструменты мониторинга Prometheus, Grafana, возможно, и Zabbix всё еще бывает полезен. Docker. Это основной технологический список. Но очень важно то, в какую компанию вы придёте. Если ей нужны настоящие SRE, то с этим списком, скорее всего, получится пройти. Если нужны переименованные админы, то у вас начнут спрашивать про рейды и так далее.


АА: Я бы добавил, что Network тоже важен для SRE, потому что твои сервисы включаются по сети. И она, возможно, не ARP.


МИ: Да, есть такое. Я про это даже как-то рассказывал, что ездил в EPAM в гости, и мне жаловались, что сейчас растёт поколение девопсов, которые делают банальные ошибки, связанные с сетью.


МИ: Требуется ли делать упор на умение программировать как таковое или всё-таки надо знать какой-то конкретный язык?


ПС: Программирование как таковое это когда вам объяснили на Паскале в институте общие принципы программирования, циклы, операторы, ветвления? Нет, этого будет недостаточно. Но я знаю, что нормальный программист довольно легко переходит с одного языка на другой. Особых требований к языкам нет. Есть более популярные и менее популярные.


МИ: Стоит ли учиться программированию по книгам?


АА: Мне кажется, более ценно учиться в сервисах, которые тебе предоставляют задачку и окошко, куда нужно писать код, а потом можно в соседнем окошке посмотреть решение и обсуждение, как люди до тебя пришли к этому коду.


ПС: Я думаю, про языки проще найти готовые курсы, туториалы и документацию, если язык не первый. Книжки это скорее основы, которые в институте проходят. Но они довольно медленно устаревают. Тот же Чистый код читать это хорошо.


МИ: Что конкретно должен уметь кодить SRE? В какую сторону смотреть?


ПС: Я могу дать конкретный пример. Prometheus работает по следующему принципу: у него есть экспортеры (штуки, которые собирают данные систем и предоставляют их в формате, понятном для Prometheus), он приходит к экспортерам и собирает данные. Такая нормальная задача SRE была бы взять какую-нибудь часть системы, у которой всё еще нет опенсорсного решения, и сделать для неё один из экспортеров в Prometheus, к примеру. Или сказать разработчикам: Ребята, у нас там система сбора логов такая-то, а давайте вы все будете собирать логи и писать их вот в опредёленном виде, и вот вам для этого библиотека. Встройте её во все свои приложения. Библиотека для таких системных вещей типа логи, трейсинг и так далее. Тоже вполне нормальная задача для SRE-инженера.


МИ: Сколько зарабатывает SRE в России? У меня под рукой нет данных, но думаю, зависит от компании и требуемых скиллов.


ПС: Я тоже без понятия, но в целом про зарплату могу сказать так: когда я только начинал заниматься сопровождением, админы чаще всего получали меньше, чем разработчики на одинаковой позиции. Сейчас DevOps, SRE получают или так же, как разработчики, или больше, потому что и скилла нужно больше. Так что посмотрите на Хедхантере, сколько в среднем получают разработчики, и делайте выводы. Мне кажется, от 120-150 тысяч. Разумная верхняя граница, думаю, 250-300. Но границ, в принципе, нет.


Вакансии SRE на Headhunter


Что будет на интенсиве по SRE?



МИ: SRE это про практику. И как раз об этом мы будем говорить на нашем интенсиве, который пройдет 11-13 декабря. Будет много кейсов, с которыми сталкивается SRE-инженер.
Там же мы рассмотрим на практике построение метрик, проблемы с доступностью и прочее, прямо своими руками, реальными инструментами. Павел уже упомянул экспортеры, Prometheus, графики. Будем всё это щупать, со всем этим разбираться.


ПС: Я еще про интенсив добавлю чуть-чуть. Мы пытаемся за три дня дать людям понять, что такое быть SRE-инженером, пропустить это через себя. Показать три дня такой работы. Практику.


Мы дадим вам систему и будем её ломать и заставлять вас её чинить в коде, в инфраструктуре, смотреть на метрики, на логи, объясняться с пользователями и так далее. Мы показываем то, что написано в книгах Google об SRE через призму реальной работы.


МИ: Именно так. Там будут и Павел, и Артём. Еще к нам присоединится Иван Круглов. И мы все вместе будем во всем этом разбираться.


Блиц по вопросам из чата


SRE должен быть свой у каждой команды?


АА: Зависит от размера команды и важности сервиса, с которым она работает. Как правило, SRE обеспечивает платформу, инструменты и сервисы для того, чтобы команды могли скидывать свои метрики и видеть, как работает их сервис. В этом случае SRE просто обеспечивает некоторую прослойку между инфраструктурой и вашим сервисом, и в каждую команду свой SRE не нужен. Но допускаю, что может быть очень важный, либо достаточно большой сервис, куда неплохо бы выделить отдельного SRE.


Что, если сервис зависит от другого сервиса? Например, авторизации. Сервис авторизации падает сильно и надолго, это приводит к исчерпанию Error budget.


АА: Если ты зависишь от другого сервиса, ты не можешь написать сервис надежнее того, от которого зависишь. Но тут есть нюансы, потому что ты можешь ретрААть некоторые запросы в рамках таймаута. Посылать сразу несколько запросов. То есть, если у тебя есть сервис, от которого ты зависишь, можно в него послать одновременно три запроса. И, возможно, один из них с большей вероятностью выполнится, чем просто один отправленный запрос. Либо ты можешь договориться с бизнесом и своими пользователями, 500-я ошибка это точно ошибка. А 403-405 могут считаться не полноценной ошибкой, а в рамках предоставления сервиса. И когда недоступен сервис, от которого ты зависишь, ты своему клиенту отдаешь код ошибки, чтобы он знал, что нужно зайти позже. И это может считаться в рамках SLO, если договориться об этом.


ПС: Мне есть что добавить. Мы тут много раз говорили, что SRE-подход это снимать все эти метрики доступности как можно ближе к клиенту. Но тут важно понимать, что у нас не просто есть тут какой-то большой сайт, который состоит из сотни микросервисов, и мы на стороне клиентов смотрим, что открывается главная страница.


Когда сервисы общаются между собой, они же все клиенты друг друга. Поэтому все эти вещи про SLO и Error budget распространяются не только на конечного пользователя. По сути, мы для каждого сервиса компании можем объявить свои SLO и Error budget, и каждый сервис обязуется для всех своих клиентов предоставлять этот определенный уровень доступности. Причем, можно говорить не только про сами приложения и про их метрики. Мы можем говорить и про другие системы компании с теми же уровнями. Если есть команда, которая занимается сопровождением баз данных, то она может объявить свои уровни и поддерживать их. Мы внутри компании постоянно этим всем пользуемся.


Более того, тут какой важный принцип в SRE вместо поиска виноватых мы понимаем, что везде бывают ошибки и ориентируемся на то, чтобы жить в инфраструктуре, которая достаточно хорошо наполнена ошибками. И учим свои сервисы работать в таких условиях.


Имеет ли место SRE в компании с редкими релизами (раз в пару лет, например)?


А: Всё-таки это сделано в Google, и тут больше вопрос про надежность, а не про релизы как таковые. С редкими релизами имеет смысл собирать статистику, знать, насколько ты надежен, где что ломается и как это чинить. Можно просто два года подставлять костыли, чтобы через три года зарелизиться. Вопрос зачем это надо, если мы все равно не можем починить быстро? Ну, можно чинить не быстро тоже вариант, какие-то прослоечки делать.


Какие знания нужны, чтобы принять участие в интенсиве с пользой? Для начинающих или опытных?


МИ: Отличный вопрос. Крайне желательно иметь бэкграунд разработки. У нас приложение будет на Python и, если вы админ и кодили, и делали скрипты, наверное, вы тоже разберётесь. Но, как мы уже выяснили, все-таки SRE-инженеру нужен бэкграунд разработчика. Наши приложения будут работать в Kubernetes и крайне желательно с ним тоже уметь работать. Будем использовать Grafana, Prometheus.

Подробнее..

Сказка об Иване-Царевиче, Бабе-Яге и канонiчном SRE (комикс)

09.12.2020 12:08:12 | Автор: admin



























Комикс придумали и нарисовали дизайнеры Слёрма Екатерина Заволокина и Юлия Самохвалова вместе со спикером интенсива по SRE Артёмом Артемьевым.


Благодарим за помощь в создании Павла Селиванова и Марселя Ибраева.


Ставьте плюсы, делитесь с друзьями, тогда мы нарисуем еще что-нибудь!

Подробнее..

1113 декабря онлайн-интенсив SRE Одна из самых востребованных IT-профессий в мире

24.09.2020 14:19:46 | Автор: admin

Как совсем недавно была мода и высокий спрос на DevOps-инженеров, так сейчас рекрутеры крупнейших компаний ищут Site Reliability Engineer. Достаточно зайти на сайты крупнейших компаний, лидеров IT-рынка, чтобы в этом убедиться. Apple, Google, Booking, Amazon.


Site Reliability Engineering это билет в открытый мир IT. Любая страна, любая IT-компания.


От Apple до Google






На три дня вы погрузитесь в теорию и практику SRE: разработаете и будете поддерживать сайт, состоящий из нескольких микросервисов.


Научитесь правильно распределять ограниченные ресурсы для обеспечения быстродействия, отказоустойчивости и доступности сайта для максимальной надежности, достаточной, чтобы были довольны пользователи.



Что будет на курсе:


Строить


Сформулируете показатели SLO, SLI, SLA для сайта, состоящего из нескольких
микросервисов, разработаете архитектуру и инфраструктуру, которая их обеспечит,
соберете, протестируете и задеплоите сайт, настроите мониторинг и алертинг.


Ломать


Рассмотрите внутренние и внешние факторы ухудшения SLO: ошибки разработчиков, отказы инфраструктуры, наплыв посетителей, DoS-атаки. Разберетесь в устойчивости, error budget, практике тестирования, управлении прерываниями и операционной
нагрузкой.


Чинить


Организуете работу группы по ликвидации аварии в минимальные сроки: подключение коллег, оповещение интересантов (stakeholders), выстраивание приоритетов. Имитация реальных условий: восстановление работоспособности сервиса в условиях предельно ограниченного времени.


Изучать


Разберете подход к сайту с точки зрения SRE. Проанализируете инциденты (причины возникновения, ход устранения). Примете решение по их дальнейшему предотвращению: улучшить мониторинг, изменить архитектуру, подход к разработке и эксплуатации, регламенты. Автоматизируете процессы.


Преподавать вам будут спикеры-практики:



Интенсив пройдёт в декабре 2020, а именно 1113 декабря. Каждый день начинаем в 10:00, проверка связи в 9:45. По расписанию занятия идут до 19:00 с перерывом на обед.


Детальную программу курса и условия вы можете увидеть на сайте курса по SRE.


Пока ещё действует акционное предложение. Осталось 28 мест из 30.


Никогда не поздно всё поменять!

Подробнее..

После DevOps как стать SRE и устроиться на работу в Google

22.12.2020 16:08:30 | Автор: admin

SRE это Site Reliability Engineer


В IT отрасли это инженер, который отвечает за надежность очень сложных сервисов. Появилась профессия в Google и придумали методологию именно там. Оно и понятно, Гугл это сервис, который использует весь мир. Это огромные мощности и большая сложность.

14 декабря в работе гугла был сбой, весь мир был в недоумении. Вот в таких случаях и нужен SRE-инженер. Он не должен допустить подобных промахов.

Методологию DevOps российский IT-рынок освоил раньше и теперь ведутся жаркие споры об SRE vs DevOps. Кто-то говорит, что это одно и тоже, кто-то, что SRE это нечто, что логично продолжает DevOps. В России профессия только появилась. Крупные банки, которые содержат большие мощности, стали серьезно задумываться о таких ребятах.
В общем, Пока все спорят, мы решили пообщаться об SRE и DevOps, а также о работе в Гугл и Тинькофф.
Одного SRE я нашла в Tinkoff, до этого он работал в Google у первоисточника, так сказать. Зовут его Дима Масленников. Google мы уделили отдельное внимание, так как есть стереотип, что работать там весело. Мы выяснили, что не всем.


Что такое DevOps
DevOps это Development and Operation, методология при которой функции администратора (специалиста, который решает задачи со стороны серверов) распределяют между командой разработки, тестирования и т.д.

В статье приведен краткий и творчески переработанный текст интервью. Если хочется подробностей или лень читать, смотрите полную версию на моем youtube-канале
Фаря:
Как ты попал в Google?
Дмитрий Масленников:
Они меня очень долго хантили. Писали мне в LinkedIn, просили мое резюме, а я всё забывал им его прислать
Почему их футболил? Это же, блин, Google!
Не знаю, мне в России было хорошо.
А чем ты занимался в этот момент?
Был программистом, архитектором ПО. Занимался разработкой бэкенда.
А почему именно на тебя обратили внимание, как ты думаешь?
Понятия не имею. У меня были всякие громкие слова вписаны в профиле, потому что я работал на всякие Еbay, Samsung. И видимо, обилие этих громких имен и технологий, с которыми я работал, и сыграли роль.
Они тебя SRE обучали? Ведь в России такого не было и нет до сих пор.
Да, и нигде в мире такого нет. Поэтому обучение проходит в Google примерно полгода.
Вокруг SRE идут дикие дискуссии. Что это, является ли SRE противопоставлением DevOps, является ли оно его дополнением?
Я когда работал в eBay, я хорошо прочувствовал, что было до DevOps. Есть разработка (программисты) и есть администраторы. И они друг друга никогда не видят. Ты передал код руководителю, и он где-то лежит. Он, в свою очередь, тоже кому-то там передал. И кто-то этот код как-то эксплуатирует. DevOps же сказал, что их надо посадить вместе.
В какой момент здесь появляется SRE?
SRE появляется, когда софт становится чрезмерно сложным и чрезмерно нагруженным. Во-первых, сам функционал растет очень сильно. И это, порой, незаметно. Ну что поменялось в Google-поиске за последний год или за последние 5 лет? А там релизы идут каждую неделю с новым функционалом! Причем, именно с функционалом.
Когда появились гики, которые собирали машины у себя в гаражах, они были невероятно популярны и все хотели быть такими же умными как они. Но мир поменялся. Сейчас это навык, который могут иметь все и оценивается он не сильно высоко. Также будет и с программистами.

Я вообще даже не представляю, что там можно обновлять?
Например, ты кофе ищешь. Во-первых, геолокация. Если ты кофе ищешь в поле, то наверно ты ищешь, как его выращивают или историю. Если кофе ищешь в центре мегаполиса, то, наверное, попить. Или Хилтон. Это фамилия или отель?
Так, а SRE тут где?
Во-первых, растет функционал, растет сложность, растет нагрузка. То есть, мы охватываем всё больше и больше людей, интернет становится доступнее и доступнее. Например, присоединяется Индия и другие, ранее недоступные страны и местности. Всё становится географически очень широким. И соответственно люди начинают потреблять, у сервиса растет нагрузка. И это дает чрезмерную сложность.
Одно дело открыть сервис только на Москву, другое на всю Россию. Нагрузка колоссальная. И что происходит? Чтобы обслужить такое количество людей быстро, нужно очень много серверов. Сервисы должны быть доступны 24x7. Представь, если сейчас у тебя платеж будет идти не 5 минут, а три дня?
И вопрос, что администратору с этим всем делать?
Я предположу, что есть много администраторов. И они существуют в сложной иерархии, чтобы всё это дело поддерживать.
Администраторами, как пишет Google, расти невыгодно. Нанимать столько людей уже невозможно. Вот поэтому и появилось SRE.
В какой момент DevOps становится SRE?
Очень философский вопрос. Есть задачи и есть проблемы. Их нужно решать. Например, если в банке не выполнились переводы, то что делать? Решать проблему. Называть ли это SRE или не называть непонятно.
Ну, и это вообще просто такой спор ни о чём. Есть ли жизнь на Марсе, нет ли жизни на Марсе? Является ли SRE DevOpsом, не является ли SRE DevOpsом? И SRE, и DevOps это про то, как делать хорошо. Значит, берём лучшее отовсюду, применяем, чтобы пользователи были довольны.
То есть две методологии работают в связке?
В связке, но SRE всё-таки не администраторы, у них больше упор на программирование и автоматизацию. Плюс, я постоянно топлю за то, что мы административными методами редко должны работать. А если это происходит, то значит у нас что-то не так.
Но это не ответ на вопрос.
Они могут быть братья, они могут перекликаться, может быть одно и тоже как хотите. А действия-то как поменяются? Всё равно всё сводится к одному: есть софт, его надо эксплуатировать, нужны какие-то люди, которые будут решать проблемы по нагрузке. И как их назвать дело десятое.
SRE может стать DevOps или программист? Вообще, что нужно изучать, чтобы стать востребованным SRE?
Мне кажется, что надо учить не программирование, не SRE и DevOps, а думать про процесс, как про инженерное дело, которое присутствует в разработке программного обеспечения и оно многофакторное.
Недавно мы митап проводили про SRE, мы много спорили, но в одном мы сошлись: программисты уже не нужны так, как раньше. Нужны всем инженеры, которые могут решать проблемы. Когда появились гики, которые собирали машины у себя в гаражах, они были невероятно популярны и все хотели быть такими же умными как они. Но мир поменялся. Сейчас это навык, который могут иметь все и оценивается он не сильно высоко. Также будет и с программистами.
______________________________________________________________________________

Про работу SRE в Google


image
Давай про Гугл. Есть легенды про плюшки в Гугл при трудоустройстве. Расскажи поподробнее.
Во-первых, когда уходишь с прошлого места работы, они спрашивают: Сколько премий ты потеряешь, увольняясь?. Они компенсируют эти деньги, чтобы ты не раздумывал. Потом мне сняли на 3 месяца квартиру, дали отдельного риелтора от Google, который подбирает жилье. Либо они могут компенсировать тебе все расходы по переезду.
Первую неделю работы они тебе рассказывают вообще не про работу, а про то, как жизнь в Гугле и Ирландии устроена. В компании всё очень спокойно. Там везде микрокухни фруктики, и прочее. Общение в микрокухнях отдельная культура. Ещё есть трехразовое питание, массажи и раз в неделю можно прийти на работу с питомцем.
И такая мантра есть от менеджера главное, не перегори, не переработай.
Ещё у нас история интересная была. Парень устроился сразу после вуза, и решил сэкономить на жилье. Он купил самый дешёвый фургон, поставил туда кровать. В Google есть прачечные, аккумуляторы он заряжал в офисе, душ и полотенца тоже имеются. Фургон поставил на парковку у офиса и ходил с нее на работу.
Он хотел быстро выплатить кредит за обучение. Но потом ему так делать запретили.
Почему?
В СМИ пошла новость, стали обсуждать, а Google не нравится большая активность. Репутация брэнда, все дела
А почему ты уехал в Россию и трудоустроился в Тинькофф? Это так нетипично. Все стараются свалить, а ты вернулся.
Не знаю, бренд интересный и я клиент очень давно. Где ещё работать в России? Ну, Яндекс, ну Тинькофф. А уехал, потому что в Дублине скучно стало.
Почему в Дублине скучно?
Это маленький город. Это не Шенген, чтобы поехать в Европу надо получать визу.
По-нашему менталитету Дублин это деревня. Когда местные говорят, что они устали от Дублина, потому что там вайб большого города, для жителей Москвы это звучит смешно.
Но плюсы там были, например, очень спокойные люди. Там вообще никто не повышает голос. В России то, что не считается повышением голоса, после Дублина выглядит контрастно.
А почему в Google скучно? Что у Тинькофф есть такого, что нет у Google?
В Тинькофф есть драйв и хорошая агрессивность.
Мы хотим там расти, мы хотим захватывать рынки, мы хотим быть лучшими.
А в Google: Мы уже лучшие. Мы уже всё захватили. Ну, что-то мы ещё хотим дозахватить в Китае, но там политические проблемы

Если вам понравилось, ищите подробности в полной версии интервью.
Подробнее..

MySQL в финансах реакция или созидание?

04.03.2021 10:11:49 | Автор: admin

Высоконагруженные приложения финансовой сферы предъявляют жесткие требования ко всем компонентам, особенно к системе хранения данных.

Нужно постоянно и стабильно держать нагрузку, несмотря, а иногда и вопреки отказам, поломкам и внезапным миграциям. О том, как приходится жить DBA в мире стремительного повышения нагрузок и высоких требованиях стабильности, в своем докладе на конференции Saint HighLoad++ Online 2020 рассказал эксперт по базам данных ECOMMPAY IT Владимир Федорков.

Работа DBA очень похожа на работу уборщицы: пока везде вымыто, все довольны. Но как только появляется проблема с чистотой, возникают вопросы, и все сразу вспоминают о том, что есть DBA недобрым, иногда матерным, словом. Почему так происходит? Дело в том, что системы хранения и поиска данных на сегодняшний день являются фундаментом приложений. Нет быстрого доступа к данным нечего обрабатывать приложению нечего показать пользователю. И весь код с архитектурой становятся бесполезными.

Поэтому работа современного DBA обеспечить стабильный фундамент активно строящемуся зданию приложения. Часто здание не просто строится, но активно эксплуатируется, местами ремонтируется, кое-где перестраивается, где-то расширяется, а иногда разрезается и вывозится вместе с жильцами, без их выселения, в другое место. И все это нужно сделать так, чтобы не создать населяющим его людям неудобств. А в идеале провести все работы так, чтобы жильцы их просто не заметили. Конечно, с обычным здание выполнить эти действия не получится. А вот в IT, особенно в случае разработки по принципу гибких методологий, такое вполне возможно. Конечно, если уделять должное внимание деталям.

Как же построить надежный фундамент для приложения? Компонентов успешной работы два: реактивный и проактивный. По их соотношению в ежедневной работе можно судить и о стабильности приложения, в целом, и об эффективности работы DBA.

Реактивность это реакция на происходящие в данный момент проде события, которые каким-либо образом влияют на работу БД, а значит и приложения ( в основном, речь идет об алертах от системы мониторинга). Если вы получаете информацию об отказах от своего руководства или, тем более, от клиентов система для вас полностью непрозрачна. А это значит, что вы не в состоянии ей управлять без риска что-то сломать на уровне базовых операций.

Задача реактивной работы: отработать событие как можно быстрее в соответствии с его приоритетом. Согласно методологии работы департамента эксплуатации ECOMMPAY IT, в случае аффекта клиентов сотрудники обязаны за минимально возможное время снять этот аффект. А дальше, в рабочем порядке, ликвидировать последствия инцидента. В этом случае бизнес несет минимальные потери как в финансовом, так и в репутационном выражении.

У реактивной работы есть множество методологий, которые несмотря на свою увлекательность, не входят в описательные цели этой статьи. Но однозначно нужно помнить одно утверждение: если критические отказы не начинают обрабатываться в течении трех минут с момента появления, деньги бизнеса не отрабатываются должным образом.

При всей своей важности, видимости и понятности для начальства и бизнеса, реактивная работа сама по себе не является залогом стабильности работы системы. За это ответственна менее заметная, но гораздо более важная часть работы DBA: проактивная или созидательная работа.

Она заключается в анализе текущей ситуации, поиске узких мест и нахождении потенциальных проблем, которые могут выстрелить завтра, на следующей неделе, через месяц или даже через год. Чем большую проблему удается обнаружить заранее, тем больше денег сэкономит бизнес на прямых потерях, и тем больше времени персонал будет занят производительным трудом, а не разгребанием последствий инцидентов.

В чем заключается проактивная работа в случае баз данных? Как и в любых других случаях, она делится на поиски ответов к двум вопросам: Где мы сейчас находимся? и Куда нам нужно двигаться?. Оба вопроса одинаково важны, но без ответа на первый мы не сможем ответить на второй, поэтому с него и начнем.

Метрики

Для того, чтобы производить анализ работы БД нужны метрики: они делают работу системы прозрачной, визуализируют состояние системы и дают возможность понимания того, что происходит здесь и сейчас.

Метрики обеспечивают крайне важную составляющую работы системного администратора ситуационную осведомленность. Ситуационная осведомленность это набор параметров, знание которых позволяет оценить работу основных компонентов системы и определить состояние системы? в целом. Без визуализации этих параметров? система не может считаться прозрачной и будет невозможна не только проактивная, но и реактивная работа.

Для систем на основе MySQL абсолютно критичными параметрами являются:

  • Метрики базы: Threads_running и Threads_connected;

  • Загрузка CPU (Load Average), context switches;

  • Загрузка дисковой подсистемы (read/s, writes/s, avg write time, avg read time);

  • Количество запросов в статусе блокировки.

Threads_running показывает, сколько запросов в настоящее время находятся в активной фазе. Это может быть фаза исполнения запроса или ожидание блокировки: речь идет о результате исполнения, который прямо сейчас ожидает приложение. Эта метрика важна еще и потому, что внутри MySQL каждый запрос (точнее, подключение) обрабатывается одним потоком, а значит, одним ядром CPU. Поэтому приближение количества активных потоков к количеству ядер на машине можно считать тревожным сигналом. В ситуации, когда количество активных запросов в разы превышает количество ядер, операционная система вынуждена делить время процессора между запросами, что приводит к менее эффективному их выполнению, увеличению Load Average, росту context switches, метрики Threads_connected и последовательной деградации производительности системы. Такое состояние системы характеризуется экспоненциальным ростом времени отклика, падением пропускной способности севера и, с точки зрения приложения и пользователей, это равнозначно отказу.

Загрузка дисковой подсистемы показывает, как быстро записываются изменения и насколько эффективно читаются незакешированные в памяти MySQL данные. Приближение метрик read/s, writes/s (они же Read IOPS и Write IOPS) к предельным значением для текущего сервера (они определяются бенчмарками) означает рост очереди активных запросов, и далее нас ждет рост Threads_running.

Отдельно можно выделить количество запросов в статусе блокировки. Блокировки бывают разными, и несмотря на то, что каждый конкретный запрос в состоянии блокировки практически не отъедает ресурс у системы, заблокированный запрос может влиять на время ответа клиенту, тормозить синхронные операции, удерживать ценные ресурсы, как на стороне базы данных, так и на стороне приложения. И, в конечном итоге, это может привести к тем же последствиям, что и большое количество активных запросов. Радости от блокировок тоже никакой. Поэтому если SELECT FOR UPDATE кажется Вам отличной идеей, у меня для вас плохие новости.

Запросы

Одними метриками сыт не будешь. Недостаточно знать, что нагрузка на базу приемлема и перегруза нет. Если в базу данных кто-то пишет, то объемы данных будут расти. Это значит, что в какой-то момент плавный и часто незаметный глазу рост времени выполнения запросов, повинуясь правилу материалистической диалектики, перейдет из количественного в качественный, и резким скачком времени ответа сообщит о том, что мирные времена закончились.

Поэтому DBA каждый день готовится к войне. А для этого нужно смотреть сами запросы, даже если прямо сейчас все хорошо.

Какие запросы смотрим:

  • Те, которые нагружают CPU;

  • Те, которые нагружают диск;

  • Все запросы, длиннее ста миллисекунд.

Как узнать, что нагружает CPU? Процессор нагружают все запросы, но смотреть в первую очередь нужно те, у которых большое суммарное время выполнения. Причем отдельный запрос может быть очень быстрым, но большое количество очень быстрых запросов может отъедать значительное количество ресурсов системы. И это может внезапно и очень неприятно аукнуться в момент легкой перегрузки. Идентифицировать такие запросы можно по большим значениям Exec time в выводе pt-query-digest, в PMM, через Performance_schema или по значению sum_time в ProxySQL.

Какие запросы нагружают диск? Этот вопрос чуть более сложный. Запись нагружает диск всегда, а вот запросы на чтение могут выполнятся только в памяти, если ее (в случае InnoDB за кэширование данных отвечает настройка innodb_buffer_pool_size) достаточно для хранения всех горячих данных. Интересно, что чтения с диска требуют не только SELECTы, но и команды записи данных. INSERTу, чтобы записать данные, нужна страничка с тем местом таблицы, в которую эти данные пишутся. UPDATE и DELETE также будут запрашивать с диска данные, которые нужно поменять (удалить), а ALTERу вообще может потребоваться вся таблица.

Запись почти всегда медленнее чтения. Исключение составляет запись в RAM-кэш дискового контроллера и в кэш-память сетевого диска. За этим и некоторыми другими редкими исключениями мы можем смело считать, что нагрузку на запись нужно смотреть в первую очередь. Особенно это касается систем виртуализации, где настройки драйвера могут сильно сказаться на производительности базы.

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

Исторические данные

Моментальный снапшот метрик и запросов позволяет увидеть текущее состояние системы, однако современные системы не просто работают 24/7. В каждый момент нагрузка на них может плавать, и моментальный снапшот эти изменения не покажет. Поэтому основную информацию о производительности нужно собирать на постоянной основе. Эту информацию крайне удобно визуализировать в виде графиков.

Такую возможность предоставляют сейчас многие системы мониторинга: OkMeter, Prometheus + Grafana, графики в Zabbix и многое другое. Напишите, пожалуйста, в комментариях, какую систему визуализации метрик вы можете порекомендовать. Моей персональной любовью является PMM крайне удобная штука, которая показывает все необходимые метрики от уровня операционной системы до внутренних метрик MySQL и ProxySQL.

Какую гранулярность выбрать для графиков? Короткие интервалы опроса (до 5 секунд) позволяют увидеть единичные моментальные всплески, но серьезно увеличивают количество хранимых исторических данных и создают видимую нагрузку на исследуемую систему. Длинные периоды опроса (больше минуты) комфортны для хранения, но появляется риск пропустить существенные всплески нагрузки.

Мы остановились на гранулярности в 20-30 секунд. Такой интервал сбора данных позволяет увидеть все более-менее серьезные всплески, при этом не нагружая клиентские системы и базы мониторингом.

Графики нагрузки позволяют решить несколько ключевых проблем:

  • Посмотреть сезонность;

  • Увидеть всплески от единичных запусков скриптов и запросов;

  • Увидеть работу кронов;

  • Оценить влияние деплоя;

  • Оценить общий рост нагрузки.

Сезонность позволяет как минимум планировать работы. Для высоконагруженных систем попытка выполнения отдельных миграций БД в момент суточного пика равнозначна отказу систем. Бизнесу это точно не понравится. Такую же службу могут сослужить и некоторые крон задачи, запущенные в момент экстремальной нагрузки.

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

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

Важность коммуникаций и открытости

Если посмотреть на список вариантов, можно увидеть, что немногие из них могут быть реализованы силами только DBA. Большая и самая эффективная часть решений может быть реализована только на уровне кода и логики приложения. Здесь мы подходим к самой важной идее всего нашего повествования: парадигме один в поле не воин.

В современном мире, особенно с увеличением количества людей в компании, наблюдается тенденция к изоляции разработки от эксплуатации и наоборот. Такая ситуация может привести к потере осведомленности разработки о нюансах функционирования приложения в проде. В то же время эксплуатация может недополучать знания о функциональных взаимодействиях внутри приложения.

Проблемы в коммуникации могут сказываться как на скорости решения отказов функционального и нагрузочного характера, так и в решениях по архитектуре, что приводит к долговременным негативным последствиям как для эксплуатации, так и для разработки.

Частично с такими проблемами борется продуктовая трансформация, создавая центры компетенций и делая кросс-командные связи более выраженными. В этом смысле администраторы баз данных и SRE являются точкой, где концентрируется информация о производительности приложений. Это делает необходимым их совместную работу с командами разработки по выявлению проблем производительности на как можно более ранней стадии, в идеале еще на этапе концепта. Такой подход помимо удешевления стоимости эксплуатации ПО, за счет оптимизации, на ранней стадии позволяет избежать архитектурных проблем и существенно ускорить разработку.

Говоря простым языком прозрачность коммуникаций между разработкой и эксплуатацией позволяет на ранней стадии решить значительное количество проблем и относительно спокойно жить с ростом нагрузки и количества данных.

Заключение

Производительность, устойчивость и стабильность не единичные задачи. Это целый комплекс ежедневных рутин и аналитики, направленный на выявление как текущих, так и потенциальных узких мест, которые могут появиться через месяц, два, шесть и даже через год.

Основа этих мер прозрачность приложений для всех команд, коммуникация и налаженное взаимодействие между всеми заинтересованными лицами. Разработка знает, как система должна работать, эксплуатация знает как она работает по факту. Обмен знаниями и взаимная осведомленность ключи к успеху в работе любой IT компании.

Конференция HighLoad++ 2020 пройдет 20 и 21 мая 2021 года.Приобрести билетыможно уже сейчас.

Хотите бесплатно получить материалы конференции мини-конференции Saint HighLoad++ 2020?Подписывайтесьна нашу рассылку.

Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru