Инженер по надежности сайта, или SRE, — это роль, которая охватывает аспекты как разработки программного обеспечения, так и операций / инфраструктуры. Он также включает в себя стратегию и набор практик и принципов для всех предложений услуг и тесно связан с DevOps и операциями. Термин «проектирование надежности сайта» впервые появился в Google в 2003 году, когда была создана команда по надежности сайта. В то время команда состояла из инженеров-программистов. С тех пор концепция проектирования надежности сайта эволюционировала и проникла в более широкую индустрию разработки программного обеспечения и теперь является ее собственной ролью в организациях.
Инженеры по надежности сайта преодолевая разрыв между операционными и разработчиками программного обеспечения. Хотя не существует единого подхода, подходящего для всех подходов к тому, что инженер по надежности сайта делает от организации к организации, в широком смысле, ответственность инженера по надежности сайта может охватывать широкий спектр целей, таких как управление и мониторинг доступности системы, задержки, производительности, эффективности, реагирования на инциденты, а также планирование емкости служб организации. Давайте углубимся в это, чтобы лучше понять эту роль и то, как она функционирует в организациях.
Что такое проектирование надежности сайта?
Если подумать об этом по-другому, то проектирование надежности сайта — это то, где встречаются традиционная ИТ-роль, или роль системного администрирования, и DevOps. В традиционной ИТ-среде организации, возможно, имели команду системных администраторов, управляющих сложными системами. Основное внимание и ответственность заключается в обеспечении правильного развертывания программного обеспечения и предоставлении надежного обслуживания конечным пользователям. Кроме того, их роль включает в себя управление любыми проблемами или проблемами, которые возникают после развертывания программного обеспечения.
Однако системные администраторы не сосредоточены на фактической разработке программного обеспечения, где роли разработчика и системного администратора могут противоречить друг другу. Разработчики сосредоточены на создании программного обеспечения и получении его в руки пользователей, не обязательно заботясь об аспектах или последствиях развертывания программного обеспечения. Именно на этом стыке вступает роль инженера по надежности сайта. Инженеры по надежности сайта сосредоточены на создании масштабируемых и надежных программных систем, поэтому это также включает в себя обеспечение того, чтобы работы по разработке были эффективными и надежными, поэтому, когда готовый продукт готов к производству, нет никаких сюрпризов.
Что делает инженер по надежности сайта?
Проектирование надежности сайта включает в себя разделение времени между операциями и разработкой. Например, инженер по надежности сайта может быть вовлечен в запросы в службу поддержки, инциденты по вызову, ручные задачи и т. Д. В дополнение к этому, инженер по надежности сайта может также тратить свое время на проактивные проекты, такие как автоматизация, повышение надежности системы и т. Д., Пытаясь уменьшить объем ручной работы и обеспечивая эффективную работу всех компонентов (инфраструктура / оборудование, промежуточное ПО, программное обеспечение и т. Д.), Которые необходимы для поддержания развертывания программного обеспечения в рабочем состоянии.
Каковы некоторые общие обязанности SRE?
Фактические обязанности SRE варьируются от компании к компании, но по большей части команда SRE или SRE несет ответственность за все аспекты своих предложений услуг и может потребовать одну, все или несколько обязанностей, перечисленных ниже:
- Планирование емкости
- Наличие
- Производительности
- Мониторинга
- Реагирование на инциденты
- Поддержка по вызову
- Вскрытие
Итак, как вы можете видеть, роль SRE имеет тенденцию быть мастером на все руки. В одну минуту SRE может выделять хранилище в AWS, а в следующую минуту SRE может потребоваться поговорить с клиентами или написать код Python для нового проекта. Это действительно зависит от дня.
Какие инструменты используют S SREs?
Инструменты и программные решения, которые инженеры по надежности сайта могут сильно различаться от организации к организации. Одна из основных причин заключается в том, что в более крупных организациях, как правило, в группе SRE будет больше персонала, поэтому обязанности и сфера охвата для каждого SRE будут разделены между командой, что приведет к более целенаправленной роли. В свою очередь, это также сократит спектр инструментов и платформ, которые они будут использовать. Так, например, в более крупной корпоративной организации SRE может просто работать в Jenkins весь день, каждый день.
С другой стороны, команде инженеров по надежности сайта или отдельному лицу в небольшой организации, возможно, придется носить гораздо больше шляп, поскольку персонал, вероятно, будет ограничен, поэтому их набор инструментов должен будет включать в себя все, от платформ управления конфигурацией и автоматизированных систем реагирования на инциденты до инструментов мониторинга и аналитики. Возможно, вы уже знакомы с некоторыми инструментами, которые использует SRE, такими как Docker, Terraform, Prometheus и Kibana.
Читайте: Top 13 Site Reliability Engineer (SRE) Tools, чтобы узнать больше о самых популярных инструментах, которые инженеры по надежности сайтов используют сегодня.
Где я могу узнать больше о проектировании надежности сайта?
Термин «инженер по надежности сайта» приписывается Бену Трейнору Слоссу, в настоящее время вице-президенту по инженерным разработкам в Google. В 2003 году его попросили создать и управлять командой из семи инженеров, что в конечном итоге привело его к созданию новой роли / названия. Есть несколько отличных онлайн-ресурсов, написанных Беном и несколькими другими членами инженерной команды Google, которые охватывают все: от принципов и принципов SRE, ролей и обязанностей SRE до эволюции роли инженера по надежности сайта и того, где она находится в современных средах DevOps. Нет лучшего способа узнать больше о проектировании надежности сайта, чем от человека и организации, которые создали роль в первую очередь, верно?
Существует также большой список ресурсов Site Reliability Engineering, расположенных на GitHub.
Вывод: Что такое инженер по надежности сайта (SRE)?
Как мы уже говорили, SRE — это больше, чем просто ваши традиционные операции или роль системного администратора. SRE использует свой обширный опыт и знания, чтобы помочь автоматизировать и повысить эффективность своих программных услуг и организации. Хороший SRE — это тот, кто, по большому счету, является отличным решателем проблем. Они не обязательно должны быть экспертами во всем, что они делают, но они должны иметь представление о многих различных дисциплинах и знать, какие шаги и методы выполнять, когда возникают проблемы. Они также должны понимать, как различные роли в их организации работают вместе, чтобы эффективно выполнять задачи и проекты. Это похоже на постоянное составление большой, сложной головоломки. Иногда это может быть очень разочаровывающим и требовательным, и иногда части могут пропасть, но как только вы закончите это, есть много гордости и достижений.
В рамках ответственности SRE мониторинг и наблюдаемость являются ключевым компонентом их обязанностей. Синтетические решения для мониторинга от Dotcom-Monitor позволяют S SRE и DevOps командам моделировать и контролировать пользователей через систему или службу. Платформа Dotcom-Monitor позволяет SРЕ настраивать настраиваемые оповещения мониторинга и интегрируется с платформами инцидентов и оповещений, такими как PagerDuty, VictorOps, AlertOps, а также многими другими. Кроме того, SРЕМ могут просматривать панели мониторинга в режиме реального времени, получать доступ к отчетам и просматривать аналитику для быстрого выявления проблем с производительностью. Для SРЕ и команд жизненно важно постоянно контролировать работоспособность приложений и инфраструктуры, чтобы обеспечить понимание надежности, доступности и общей производительности их инфраструктуры.
Узнайте больше о Dotcom-Monitor и о том, как вы можете использовать платформу, чтобы углубиться в мониторинг и наблюдаемость, чтобы получить лучшее представление о ваших приложениях и инфраструктуре.
