В одной из наших предыдущих статей мы обсудили, кто такой инженер SRE, чем он занимается, а также некоторые общие обязанности, которые может иметь типичный SRE. Например, поддержка операций, обработка заявок на неисправности и реагирование на инциденты, а также общий мониторинг и наблюдаемость системы.
В этой статье мы более подробно рассмотрим различные принципы и рекомендации SRE, которые инженер по надежности объекта применяет в своей роли. Как и DevOps, эти принципы SRE служат руководством для согласования, достижения и поддержки целей организации.
Google была первой компанией, которая создала, приняла и поддержала роль инженеров по обеспечению надежности сайтов. С тех пор роль SRE менялась по мере того, как отрасль менялась и переходила от традиционных монолитных структур к крупным, широко распределенным сетям и микросервисам.
Однако одно во многом осталось прежним – принципы, которых придерживаются SRE. Эти основные принципы SRE сосредоточены на одном: надежности системы управления и обслуживания. Давайте углубимся в эти основные принципы SRE.
Принципы SRE
Принятие и управление рисками
Принятие риска является первым из принципов SRE, и на это есть веская причина. Чтобы повысить надежность системы, важно оценить влияние сбоев типа «что, если». Само собой разумеется, что ни одна система не является надежной на 100 процентов. В какой-то момент что-то пойдет не так.
К сожалению, обычный пользователь или клиент не знает об этом и не хочет проявлять такое понимание. И существуют неизбежные затраты, связанные с обеспечением надежности. Будь то финансовые затраты, временные затраты или просто доверие клиента к вашим услугам.
Одна из обязанностей SRE — полагаться на сбои и риски, чтобы научиться в конечном итоге делать свои услуги и системы более устойчивыми. Однако есть компромиссы, которые необходимо принимать во внимание. Например, обеспечение максимальной надежности может быть достигнуто за счет более быстрого предоставления будущих услуг.
Порой дальнейшие улучшения не обязательно означают значительный рост продаж. Цель состоит в том, чтобы создать надежную систему, но не более того, чем это необходимо, поскольку затраты и время перевешивают потенциальные выгоды.
Определение целей уровня обслуживания
Принцип принятия риска тесно связан с объектами уровня обслуживания или SLO. Если копнуть немного глубже, SLO — это формализованные цели в Соглашении об уровне обслуживания (SLA), которые измеряются с помощью индикаторов уровня обслуживания или SLI. SLI — это фактические показатели производительности ваших сервисов.
Например, если в вашем SLO указано, что время безотказной работы должно составлять 99,9%, фактический SLI должен соответствовать этому показателю производительности или превышать его, чтобы соответствовать этому конкретному SLO. SLI — это индикаторы, которые SRE будет постоянно отслеживать, чтобы в случае превышения этого порога команды были предупреждены и проблема могла быть быстро решена. SLI действительно привязаны к пользователю, чтобы определить, что наиболее важно для его опыта использования услуги.
SLA, SLO и SLI
- Соглашение об уровне обслуживания: соглашение с вашими клиентами или заказчиками, определяющие уровень предоставляемого обслуживания.
- SLO: соглашение в рамках SLA, определяющее конкретные показатели, такие как время безотказной работы, время ответа, безопасность, разрешение проблем и т. д.
- SLI: фактическая производительность или показатели ваших SLO, определяющие уровень соответствия.
SLO используются для измерения фактической производительности в соответствии с SLA, которые представляют собой соглашения между поставщиком услуг и клиентом. Опять же, все это восходит к идее о том, что должно быть соглашение или понимание того, какой уровень риска или терпимости можно допустить для конкретной услуги.
Автоматизация работы
Работа, согласно определению роли SRE, — это объем ручной работы, необходимой для обеспечения работы служб. Одна из основных целей SRE — автоматизировать как можно больше работы. Это позволяет SRE освободить больше времени для более важных задач. И если задуматься, сокращение работы действительно должно быть частью работы каждого.
Чем меньше времени тратится на повторяющиеся задачи, тем выше производительность в долгосрочной перспективе. Каждый раз, когда инженеру по надежности объекта приходится выполнять повторяющиеся действия вручную, связанные с управлением производственными услугами, это можно охарактеризовать как хлопоты.
Во многих ситуациях могут быть случаи, когда SRE должен выполнять трудоемкие действия вручную, но не все из них следует определять как работу. Однако важно определить, какие действия внутри команды SRE занимают больше всего времени. После этого определите, где можно внести улучшения, чтобы уменьшить объем работы и улучшить ее баланс.
Когда Google впервые представила роль SRE, они поставили перед собой цель: половина времени SRE должна быть сосредоточена на сокращении будущей операционной работы или добавлении сервисных возможностей. Разработка новых функций коррелирует с улучшением таких показателей, как надежность и производительность, что в конечном итоге снижает потенциальную работу в будущем.
Мониторинг
BAILRY — это решение для мониторинга для отслеживания времени безотказной работы, доступности, функциональности и общей производительности серверов, веб-сайтов, сервисов и приложений. Мониторинг является одним из наиболее важных принципов SRE в рамках этой роли. Непрерывный мониторинг гарантирует, что сервисы функционируют должным образом, и может помочь определить момент возникновения проблем и их немедленное решение.
Как упоминалось в предыдущем разделе, соблюдение этих SLO является ключом к определенным бизнес-SLA и, в конечном итоге, к пользователям. Мониторинг может предоставить SRE и командам исторические тенденции производительности и дать представление о разовой проблеме по сравнению с более широкой системной проблемой. Согласно определению инициативы Google SRE, четыре золотых сигнала мониторинга включают следующие показатели:
- Задержка. Задержка — это время или задержка, необходимая службе для ответа на запрос. Понятно, что медленное время отклика влияет на восприятие пользовательского опыта. Мониторинг может предоставить возможность контролировать это время.
- Трафик. Трафик относится к объему пользовательского спроса или нагрузки на систему. Это можно измерить количеством HTTP-запросов в секунду или в зависимости от фактического сервиса.
- Ошибка. Под сбоями понимается частота сбоев запросов к службе. Однако командам SRE важно различать серьезные сбои, такие как ошибки сервера 500, и мягкие сбои, такие как ответ 200 OK, время ожидания которого истекает из-за того, что был установлен определенный порог производительности. Важно подумать о том, как правильно отслеживать различные подобные сценарии.
- Насыщенность. Насыщенность — это измерение количества системных ресурсов, имеющихся у конкретной службы. До определенного момента производительность большинства сервисов будет снижаться. Понимание того, где это происходит, может помочь правильно определить цели и задачи мониторинга, чтобы можно было предпринять корректирующие действия.
Автоматизация
Автоматизируйте, автоматизируйте, автоматизируйте. Мы уже касались этого принципа ранее, когда обсуждали сокращение работы, но его нельзя недооценивать. Природа роли SRE настолько разнообразна, насколько это возможно. Чтобы уменьшить вероятность ручного вмешательства во всех аспектах их обязанностей, автоматизация задач является ключом к успешному бизнесу. По мере того как услуги масштабируются и становятся более распределенными, ими становится гораздо сложнее управлять.
Автоматизируя повторяющиеся задачи по всем направлениям, будь то тестирование, доставка программного обеспечения, инциденты или просто общение между командами, автоматизация обеспечивает немедленные преимущества, эффективность и, что наиболее важно, последовательность. С момента создания роли SRE изменились способы совместной работы команд разработки, контроля качества и эксплуатации. Для поддержки этой новой среды и практик DevOps были разработаны различные платформы и инструменты.
Разработка релиза
Релизная инженерия. Звучит как сложная тема, но на самом деле это всего лишь простой способ определить, как создается и доставляется программное обеспечение. Хотя разработка релизов сама по себе является отдельным названием и ролью, в рамках концепции SRE это означает предоставление стабильных, последовательных и, конечно же, повторяемых услуг.
Это возвращает нас к предыдущему разделу об автоматизации. Когда вы что-то делаете, делайте это правильно. И будьте готовы повторять это последовательно, если это необходимо. Создание серии разовых услуг отнимает много времени и требует ненужных усилий.
Если мы вернемся к истории должности SRE в Google, у них были специальные инженеры по выпуску, работавшие напрямую с SRE. Инженерам по выпуску обычно поручают определение лучших практик разработки программных сервисов, развертывание обновлений, постоянное тестирование и решение проблем с программным обеспечением, а также многие другие обязанности.
Эта роль становится все более важной, когда вы думаете о том, как быстро масштабировать и предоставлять услуги. Набор лучших практик и инструментов (и их соблюдение) необходим для удовлетворения этих требований и обеспечит спокойствие командам SRE, как только эта сборка будет запущена в производство.
Простота
Учитывая должность, которая, казалось бы, не имеет конца по количеству обязанностей и ожиданий, как, например, должность SRE, конечным принципом является, как это ни парадоксально, простота. Возможно, на практике легче сказать, чем сделать, но этот принцип фокусируется на идее разработки системы или услуги, которая настолько сложна, насколько это необходимо.
Хотя на первый взгляд это может показаться нелогичным, на самом деле все сводится к желанию иметь надежную, последовательную и предсказуемую систему. Это может показаться скучным, но для SRE это одна из конечных целей.
SRE стремятся создать систему или услугу, которая не сложна и не трудна в управлении. SRE хотят, чтобы информационная система просто выполняла ту работу, для которой была разработана. Однако с точки зрения пользователя сервис, предлагающий множество функций, может также предложить много преимуществ, но для SRE это означает лишь больше потенциальных проблем.
Однако изменения всегда неизбежны, и если вы хотите добавить в веб-сервис новые функции, делайте это осторожно. Небольшими постепенными изменениями легче управлять, чем создавать и выпускать множество функций одновременно. SRE также должны учитывать потребности и цели компании.
Эпилог
Роль SRE сосредоточена на создании, развертывании и обслуживании надежных систем и сервисов в любом масштабе. Эти семь основных принципов помогают определить методы работы SRE, которые способствуют согласованию практик DevOps и поддерживают цели организации. Это сложная роль, которая пытается сбалансировать надежность с выпуском функций, сохраняя при этом исключительный уровень качества.
Платформа BAILRY предоставляет SRE возможности мониторинга, необходимые для обеспечения непрерывности их услуг. Оповещения в реальном времени — платформа предоставляет основные инструменты, необходимые для управления производительностью всех ваших сервисов в долгосрочной перспективе.
Простой, надежный и недорогой сервис BAILRY поможет контролировать доступность сайта. Важно чтобы сайт открывался в браузере посетителя!
Компания Mainton - разработка и тестирование программного обеспечения под заказ, DevOps и SRE, SEO и реклама в интернете с 2004 года.