Visitors have accessed this post 3145 times.

Если вы зайдете на hh и напишите в поисковой строке HighLoad или «высокие нагрузки», результаты поиска вас удивят. «Чистых» вакансий по высоким нагрузкам практически нет. Как правило, задачи HighLoad упоминаются в обязанностях DevOps-инженеров (правда, чаще это матерые спецы уровня Senior) или backend-разработчиков. Поэтому очень часто происходит смешение задач HighLoad и DevOps. Давайте разберемся, чем же HighLoad отличается от DevOps.

Возьмем DevOps-инженера Михаила. Он, со своей стороны, вроде бы обеспечивает необходимую часть для построения высоконагруженного приложения: автоматизирует процессы, настраивает мониторинг, следит за актуальностью версий и выкатками. Значит, он занимается еще и HighLoad? Нет, для HighLoad этого недостаточно. Высокие нагрузки требуют не только базовой автоматизации, но и отказоустойчивости, особенно в моменты пиковых наплывов пользователей.

Здесь самое время рассказать о концепции SRE (Site Reliability Engineering), которая была разработана Google еще в 2003 году. В ней Google осветил организацию рабочих процессов, которая позволяет обеспечить бесперебойную работу всех его грандиозных и очень высоконагруженных систем. Эти принципы и легли в основу HighLoad.

SRE идет бок о бок с DevOps и решает следующие задачи:

• стандартизация,
• достижение баланса между отказами и релизами,
• снижение стоимости отказов,
• автоматизация,
• безотказность работы.

Как видно из перечисленных задач, по сути SRE продолжает идею DevOps, добавляя к отказу от оргбарьеров, принятию фэйлов, постепенным изменениям, автоматизации свои ценности. Поэтому HighLoad и DevOps имеют очень много общего. Однако SRE содержит методы и рекомендации, которые необязательно входят в DevOps и которые необязательно знать нашему DevOps-инженеру Михаилу. Но без которых не обойтись инженеру по высоким нагрузкам. Тут важно отметить, что все эти принципы и практики работают не каждый сам по себе, а как единое согласованное целое.

SRE решает проблему доступности высоконагруженной системы, измеряя ее показателями инженеров, менеджеров и клиентов. Поэтому в SRE введены такие метрики, как SLA, SLI и SLO.

•  SLA (Service Level Agreement / Соглашение об уровне обслуживания) — те самые 99,99% (или 99,97%, или еще какие-либо). Показывает допустимое и вычислимое время простоя системы, а также оговаривает штрафы за несоблюдение уровня.
• SLI (Service Level Indicator / Показатель уровня обслуживания) — это измеряемые показатели времени выполнения, пропускной способности, количества сбоев в моменте, здесь и сейчас.
• SLO (Service Level Objective / Цель уровня обслуживания) — это целевое значение для разных SLI. Отличие от SLA в том, что SLO обозначает цель, а SLA говорит о том, что произойдет, если она не будет достигнута.

Говоря о Highload системах, мы обращаемся к SRE, чтобы иметь четкое понимание цифр и целей, с которыми ведется работа в нашей высоконагруженной системе.

Дак в чем же отличие?

Сегодня специалист по высоким нагрузкам – это человек, работающий с огромным стеком технологий и количественных показателей, умеющий формализованно оценить любую по масштабам систему. Он и архитектор, и инженер (в том числе — по DevOps), и местами разработчик. Но главное, объединяющее HighLoad и DevOps, – это стремление к постоянному развитию и улучшению. Это не конечная точка, а путь, требующий каждодневного изучения новых технологий и выбора лучших решений для вашей системы.

От редакции

Если вам интересно посещать бесплатные онлайн-мероприятия по DevOps, Kubernetes, Docker, GitlabCI и др. и задавать вопросы в режиме реального времени, подключайтесь к каналу DevOps by REBRAIN. 

*Анонсы мероприятий каждую неделю

Практикумы для специалистов по инфраструктуре и разработчиков — https://rebrainme.com.

Наш Youtube-канал — https://www.youtube.com/channel/UC6uIx64IFKMVmj12gKtSgBQ.

Агентство Fevlake, проектируем и поддерживаем IT-инфраструктуры с 2012 года — https://fevlake.com.