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