Войти
Проектирование надежности сайта ( SRE) - это набор принципов и практик, которые включают аспекты разработки программного обеспечения и применяют их к инфраструктуре и операционным проблемам. Основные цели - создание масштабируемых и высоконадежных программных систем. Разработка надежности сайта тесно связана с DevOps, набором практик, сочетающих разработку программного обеспечения и ИТ-операции, а SRE также описывается как конкретная реализация DevOps.
Сфера проектирования надежности сайтов зародилась в Google вместе с Беном Трейнором Слоссом, который основал группу по обеспечению надежности сайтов после прихода в компанию в 2003 году. В 2016 году в Google работало более 1000 инженеров по надежности сайтов. Эта концепция, зародившаяся в Google в 2003 году, распространилась на более широкую индустрию разработки программного обеспечения, и впоследствии другие компании начали нанимать инженеров по надежности сайтов. Такая позиция чаще встречается в крупных веб-компаниях, поскольку небольшие компании часто не работают в масштабах, требующих специальных SRE. Организации, принявшие эту концепцию, включают Airbnb, Dropbox, IBM, LinkedIn, Netflix и Wikimedia. Согласно отчету DevOps Institute за 2021 год, 22% организаций в опросе, в котором приняли участие 2000 респондентов, приняли модель SRE.
Инжиниринг надежности сайта, как рабочая роль, может выполняться индивидуальными специалистами или организовываться в группы, обычно отвечающие за сочетание следующего в рамках более широкой инженерной организации: доступность системы, задержка, производительность, эффективность, управление изменениями, мониторинг, аварийное реагирование, и планирование мощности. Инженеры по надежности сайта часто имеют опыт разработки программного обеспечения, системного проектирования или системного администрирования. Сферы проектирования надежности сайта включают автоматизацию, проектирование системы и улучшение устойчивости системы.
Инжиниринг надежности сайта, как набор принципов и практик, может выполнить каждый. SRE похож на проектирование безопасности в том смысле, что каждый должен внести свой вклад в передовые методы обеспечения безопасности, но компания может решить в конечном итоге нанять специалистов для этой работы. И наоборот, для защиты интернет-систем компании могут нанимать инженеров по безопасности, а для определения и обеспечения своих целей надежности компании могут вместо этого нанимать SRE.
Разработка надежности сайта также описывается как конкретная реализация DevOps, но она ориентирована конкретно на создание надежных систем, тогда как DevOps в более широком смысле ориентирована на инфраструктуру.
Стивен Госсетт написал в « Built In», что некоторые компании переименовали свои операционные группы в группы SRE с небольшими значительными изменениями. Это также считается верным для операционных групп, переименованных в команды DevOps.
Было предпринято несколько попыток определить канонический список принципов проектирования надежности площадки, но, хотя консенсус отсутствует, в большинство таких определений обычно включаются следующие характеристики:
Практика проектирования надежности сайта также сильно различается, но приведенный ниже список относительно часто встречается, по крайней мере, частично:
Команды инженеров по обеспечению надежности сайтов взаимодействуют с другими командами в своих компаниях и в различных формах используют принципы и методы SRE. Вот общий обзор распространенных командных реализаций SRE:
Объем предоставляемых услуг или рабочих процессов обычно неограничен.
Основное внимание уделяется надежности скрытых систем, которые помогают повысить эффективность работы других команд. Их часто путают с командами «Платформа» или «Операциями платформы». Команды SRE инфраструктуры могут объединяться с одной или несколькими группами разработчиков платформы, но они отличаются тем, что группы SRE инфраструктуры фокусируются на выполнении большей части, если не всей, работы, описанной в приведенном выше списке принципов и практик. Команды платформ, как правило, сосредоточены на создании платформы, и, хотя надежность желательна, это не их единственный приоритет.
Основное внимание уделяется инструментам для измерения, обслуживания и повышения надежности системы.
Команда SRE для продукта и / или приложения. Некоторые крупные компании обычно нанимают несколько таких сотрудников.
Обычно практикующие SRE работают в одиночку или в парах, состоящих из команды разработчиков программного обеспечения, чтобы применять большинство принципов и практик, описанных выше.
Проконсультируйтесь о том, как реализовать принципы и методы SRE. Обычно это опытные SRE, которые работали в командах над одной или несколькими из описанных выше реализаций. SRE по внешнему консультированию Команды SRE часто называют «инженерами по надежности клиентов». Они редко, если вообще когда-либо, меняют конфигурацию или код клиента.
Крупные компании, которые приняли SRE, как правило, имеют комбинацию описанных выше реализаций, в том числе несколько групп, выполняющих одну и ту же реализацию, например, несколько групп SRE продукта / приложения для удовлетворения конкретных требований нескольких продуктов и группу SRE инфраструктуры для объединения с платформой инженерная группа для достижения целей надежности общей платформы для обоих продуктов / приложений.
Организация USENIX с 2014 года проводит ежегодную конференцию SREcon для инженеров по надежности сайтов в отрасли, а также проводит региональные конференции с аналогичными темами.
