В одной из наших предыдущих статеймы обсуждали, что такое SRE, что они делают, и некоторые общие обязанности, которые может иметь типичный SRE, такие как поддержка операций, работа с билетами на неисправности и реагирование на инциденты, а также общий мониторинг и наблюдаемость системы. В этой статье мы углубимся в различные принципы и рекомендации SRE, которые инженер по надежности сайта практикует в своей роли. Как и DevOps, эти принципы SRE служат руководством для выравнивания, поскольку это относится к выравниванию, достижению и поддержке целей организации.
Google была первой компанией, которая создавала, охватывала и поддерживала роль инженерии надежности сайта. С тех пор роль SRE развивалась по мере того, как отрасль менялась и переходила от традиционных монолитных структур к большим, широко распределенным сетям и микросервисам. Однако одна вещь во многом осталась прежней – принципы, которых придерживаются SРЕ. Эти основные принципы SRE сосредоточены на одном: надежности системы управления и обслуживания. Давайте углубимся в эти основные принципы SRE.
Принципы SRE
Принятие и управление рисками
Принятие риска на самом деле является одним из основных принципов SRE, и легко понять, почему. Чтобы сделать систему более надежной, вы должны учитывать сценарии «что, если» и извлекать уроки из потенциальных сбоев. Ни одна система никогда не бывает на 100% надежной, и в какой-то момент что-то обязательно пойдет не так. К сожалению, большинство пользователей не знают (или особенно не заботятся) об этой реальности. Они просто хотят, чтобы все работало, и всегда есть цена достижения этой надежности, будь то деньги, время или даже поддержание доверия клиентов.
Для SRE учет рисков и извлечение уроков из неудач имеют важное значение для создания устойчивых систем. Но всегда есть компромиссы, которые нужно взвесить. Максимизация надежности может означать замедление темпа разработки новых функций или может привести к увеличению затрат без значительного увеличения доходов. Идея не в том, чтобы сделать систему более надежной, чем она на самом деле должна быть. В конце концов, если дополнительные усилия и ресурсы не приносят значимой ценности, их лучше потратить на что-то другое. В SRE все дело в поиске «правильного» уровня надежности, который уравновешивает стоимость, скорость и ценность.
Цели уровня обслуживания
Принцип учета риска тесно связан с целями уровня обслуживания (SLO). SLO — это конкретные цели производительности в рамках соглашения об уровне обслуживания (SLA), которые измеряются с помощью индикаторов уровня обслуживания (SLI) — фактических показателей, отслеживающих производительность вашего сервиса. Например, если в SLO указано, что время безотказной работы должно составлять 99,9%, SLI измеряет, достигли ли вы этой отметки. Эти SLI постоянно контролируются SRE, поэтому если производительность падает ниже согласованного порога, команда получает предупреждение и может быстро отреагировать. SLI в конечном итоге касаются того, что наиболее важно для пользователей, помогая командам расставлять приоритеты в аспектах обслуживания, которые напрямую влияют на пользовательский опыт.
Вот краткое описание этих терминов:
- SLA: Общие соглашения с клиентами или заказчиками об уровне предоставляемых услуг.
- SLO: конкретные цели производительности в SLA, такие как время безотказной работы, время отклика или стандарты безопасности.
- SLI: Фактические показатели эффективности, которые отслеживают соответствие SLO.
По сути, SLO позволяют командам измерять реальную производительность в соответствии с SLA, устанавливая четкие ожидания в отношении качества обслуживания. Эта структура подтверждает согласованную толерантность к риску, определяя, насколько вариативность или время простоя может выдержать сервис, сохраняя при этом потребности пользователей и бизнес-цели.
Читайте:Узнайте больше об управлении соответствием соглашениям об узле в вашей организации.
Устраните труд
Труд, как он определен в области роли 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 или запланируйте демонстрацию с одним из наших инженеров по производительности.
