Лучшие практики проектирования надежности сайта (SRE)

Автор: Раян Дас, InfraCloud (платиновый спонсор, KCD Chennai 2022)

Что такое проектирование надежности сайта (SRE)?

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

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

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

Зачем нам нужен SRE? Важно ли это? И что делает хорошую команду SRE?

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

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

Основной целью SRE является повышение производительности и операционной эффективности.

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

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

SRE против DevOps и как SRE работает с DevOps?

По своей сути, проектирование надежности сайта — это реализация парадигмы DevOps. Точно так же, как непрерывная интеграция и непрерывная доставка (CI/CD) являются применением принципов DevOps к выпуску программного обеспечения, SRE — это применение тех же принципов к надежности программного обеспечения.

Существует большое разнообразие способов определения DevOps. Тем не менее, традиционная модель заключается в разделении команд разработки («devs») и эксплуатации («ops»), что приводит к тому, что команда, которая пишет код, не отвечает за то, как он работает, когда клиенты начинают его использовать. Команда разработчиков «перебрасывает код через стену» команде операторов для установки и поддержки.

Согласно подходу Google, вы можете использовать SRE для лучшего внедрения принципов DevOps в организации и измерения успеха внедрения.

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

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

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

Лучшие практики SRE

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

Бюджеты ошибок

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

SLI = [Good events / Valid events] x 100

Теперь процент выражается как SLI, и как только вы определите цель для каждого из этих SLI, это и будет ваша цель уровня обслуживания (SLO), а бюджет ошибок — это остаток, до 100.

Например, представьте, что вы измеряете доступность вашей домашней страницы. Доступность измеряется количеством запросов, на которые были получены ответы с ошибкой, деленное на все действительные запросы, которые получает домашняя страница, выраженное в процентах. Если вы решили, что цель доступности — 99,9%, то бюджет ошибок составляет 0,1%. Вы можете обслуживать до 0,1% ошибок (желательно чуть меньше 0,1%), и пользователи будут с удовольствием продолжать пользоваться сервисом.

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

На первый взгляд, бюджеты ошибок не так важны. Это просто еще одна метрика, которую ИТ и DevOps должны отслеживать, чтобы убедиться, что все работает гладко, верно? К счастью, ответ — нет. Бюджеты ошибок — это не просто удобный способ убедиться, что вы выполняете договорные обещания. Новые обновления обычно замораживаются, если команда исчерпала свой бюджет ошибок на определенный квартал. Они также дают возможность командам разработчиков внедрять инновации и идти на риск.

Определяйте SLO как пользователь

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

Индикаторы уровня обслуживания (SLI): Тщательно определенная количественная мера какого-либо аспекта уровня предоставляемых услуг, например, пропускной способности, задержки. А также:

• Непосредственно измеряемый & наблюдаемый пользователями.
• Это может представлять опыт пользователя.
• Простыми словами, здесь говорится о том, что именно вы собираетесь измерять.

Цели уровня обслуживания (SLO): Целевое значение или диапазон значений для уровня обслуживания, измеряемого SLI. Также это:

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

Соглашения об уровне обслуживания (SLA): SLA — это:

• Бизнес-контракт, предусматривающий предоставление клиенту определенной формы компенсации, если услуга не соответствует ожиданиям.
• Простыми словами, SLO + последствия.

Мониторинг ошибок и доступности

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

Эффективное планирование мощностей

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

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

Уделяя внимание управлению изменениями

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

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

Безупречное вскрытие

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

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

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

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

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

Заключение

В этой статье мы попытались охватить фундаментальные концепции и практики, необходимые для создания успешной команды SRE. Если вы планируете внедрить культуру SRE в своем проекте/организации, обучите свою команду, следуйте лучшим практикам и доверяйте процессу. Вы не достигнете 100% совершенства. Это миф. Но вы значительно упростите процесс и максимально приблизитесь к совершенству.

Надеюсь, эта статья была полезной для вас. Сообщите мне о своих мыслях. Начните разговор в Twitter и LinkedIn. Для получения регулярных обновлений от InfraCloud, посвященных облачным технологиям, следите за нами в Twitter и LinkedIn.

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

Ссылки

• Сборник лучших практик для производственных служб
• Что такое SRE и как он связан с DevOps?
• SRE Site Reliability Engineering
• ЧТО ТАКОЕ SRE И КАК ОН СВЯЗАН С DEVOPS?
• SRE vs DevOps: в чем разница
• Как окна технического обслуживания влияют на бюджет ошибок — советы SRE
• Что такое бюджет ошибок и почему он имеет значение?
• Выбор правильных показателей уровня обслуживания
• Метрики SRE: Четыре золотых сигнала мониторинга
• Топ-10 лучших практик по проектированию надежности сайта
• 5 лучших практик для проведения ретроспектив инцидентов