Рубрика «sre» - 2

Эксплуатация большой распределённой системы: чему я научился - 1

Читая различные каналы и рассылки, я часто встречаю статьи о конкретных «болях» и проблемах, возникающих при росте компании, когда надежность и масштабируемость выходят на первый план. Эта статья — иная. Здесь нет подробного разбора конкретных архитектурных решений или пошагового руководства по изменению инженерной культуры. Скорее, это взгляд сверху на те вызовы, которые возникают при эксплуатации распределенных систем, и отправная точка, которая поможет сориентироваться в потоке терминов, аббревиатур и технологий.

Предлагаю вашему вниманию перевод статьи, написанной инженером из Uber.

* * *

В последние несколько лет я создавал и обслуживал большую распределённую систему платежей в Uber. За это время я многое узнал о концепциях распределённых архитектур и на своём опыте выяснил, насколько трудно создавать и обслуживать высоконагруженные системы с высокой доступностью. Построение такой системы — работа интересная. Мне нравится планировать, как система будет обрабатывать рост трафика в 10-100 раз, обеспечивать надёжность данных вне зависимости от аппаратных сбоев. Однако эксплуатация большой распределённой системы дала мне неожиданный опыт.
Читать полностью »

Когда Facebook «лежит», люди думают, что это из-за хакеров или DDoS-атак, но это не так. Все «падения» за последние несколько лет были вызваны внутренними изменениями или поломками. Чтобы учить новых сотрудников не ломать Facebook на примерах, всем большим инцидентам дают имена, например, «Call the Cops» или «CAPSLOCK». Первый так назвали из-за того, что когда однажды соцсеть упала, в полицию Лос-Анджелеса звонили пользователи и просили его починить, а шериф в отчаянии в Твиттере просил не беспокоить их по этому поводу. Во время второго инцидента на кэш-машинах опустился и не поднялся сетевой интерфейс, и все машины перезапускали руками.

Элина Лобанова работает в Facebook последние 4 года в команде Web Foundation. Участники команды зовутся продакшн-инженерами и следят за надежностью и производительностью всего бэкенда, тушат Facebook, когда он горит, пишут мониторинг и автоматизацию, чтобы облегчить жизнь себе и другим.

Взгляд изнутри на надежность сервисов Facebook - 1

В статье, основанной на докладе Элины на HighLoad++ 2019, расскажем, как продакшн-инженеры следят за бэкендом Facebook, какие инструменты используют, из-за чего возникают крупные сбои и как с ними справиться.
Читать полностью »

19 марта запустится практический курс для системных администраторов Linux от Mail.ru Group - 1

Мы запускаем практический учебный курс для будущих системных администраторов Linux, инженеров доступности сервисов (SRE). Это будет квест, во время которого вы получите хорошую базовую подготовку, а также сможете проверить себя в условиях, максимально приближенных к реальным.

Читать полностью »

Можно ли описать Goggle в нескольких словах? Компанию, в которой сотни подразделений, порой настолько экспериментальных, что вплотную приближаются к научной фантастике. Компанию, в которой работают сотни тысяч человек по всему миру.

Наверное, Google — для каждого своей. Для каждого наблюдателя — сотрудника, независимого разработчика и админа, конкурента, просто человека интересующегося IT-тематикой, пользователя в сети, вбивающего в адресную строку браузера google.com.

Я познакомился c Евгением Вараввой, разработчиком широкого профиля в Google (Сан-Франциско), на Слёрме SRE — он там вовсю с удовольствием запутывал участников задачками, неожиданными багами и проблемами учебного проекта.

А после, когда начали расставлять столы, усталые участники прощаться друг с другом, сотрудники Слёрма убирали провода, роутеры и сетевые удлинители, я пригласил Евгения поговорить — каким он видит Google. Изнутри. И изменилась ли его ощущение и точка зрения за десяток лет работы в компании.

Что получилось — читайте…

Евгений Варавва, разработчик в Google. Как описать Google в 5 словах - 1

Читать полностью »

Наша команда любит эксперименты. Каждый Слёрм — это не статичное повторение предыдущих, а осмысление опыта и переход от хорошего к лучшему. Но со Слёрмом SRE мы решили применить абсолютно новый формат — дать участникам условия, максимально приближённые к «боевым».

Если кратко обрисовать, чем мы занимались на интенсиве: «Строим, ломаем, чиним,
изучаем». SRE мало чего стоит в голой теории — только практика, реальные решения, реальные проблемы.

Участники были поделены на команды, чтобы бодрый соревновательный дух не дал никому заснуть или запустить «Angry Birds» на iPhone по примеру Дмитрия Анатольевича.

Проблемы, глюки, баги и задачи обеспечивали участникам четыре ментора. Иван Круглов, Principal Developer в Booking.com (Нидерланды). Бен Тайлер, Principal Developer в Booking.com (США). Эдуард Медведев, CTO в Tungsten Labs (Германия). Евгений Варавва, разработчик широкого профиля в Google (Сан-Франциско).

Да ещё и участники поделены на команды — и соревнуются друг с другом. Интересно?

Слёрм SRE. Сплошной эксперимент c экспертами из Booking.com и Google.com - 1
Иван, Бен, Эдуард и Евгений с добрым ленинским прищуром смотрят на бедных участников Слёрм SRE перед началом соревнования.

Читать полностью »

По мотивам дискуссии в чате AWS Minsk Community

В последнее время разгораются настоящие битвы на предмет определения понятия DevOps и SRE.
Несмотря на то, что уже во многом дискуссии на эту тему уже набили оскомину, в том числе и мне, решил вынести на суд хабра-сообщества и свой взгляд на эту тему. Тем, кому интересно, добро пожаловать под кат. И да начнется все по новой!
Читать полностью »

Слёрм SRE — учимся обеспечивать счастье пользователей - 1

3 февраля в Москве стартует Слёрм SRE.

Это первый интенсив, где мы ушли от схемы «Повторяй за преподавателем». Вас ждет работа в SRE-проекте, максимально приближенная к боевым условиям.

Вы получите в руки полновесный работающий проект и будете работать с ним в реальном времени. Вас ждет типичная задача SRE: работа с незнакомым кодом, проблемы синхронизации распределенных систем, сложности коммуникации с коллегами.

Вас ждут нетривиальные отказы систем, взятые из реальной жизни. (Я время от времени слышу от спикеров: «Коллеги, извините, в ближайшие два дня не смогу подключиться к встречам, зато появился отличный кейс для нашей программы»).

Читать полностью »

image

SRE (Site Reliability Engineering) — подход к обеспечению доступности веб-проектов. Считается фреймворком для DevOps и говорит как добиться успеха в применение DevOps-практик. В этой статье перевод Главы 4 Service Level Objectives книги Site Reliability Engineering от Google. Этот перевод я готовил самостоятельно и полагался на собственный опыт понимания процессов мониторинга. В телеграм-канале monitorim_it и прошлом посте на Хабре я публиковал также перевод 6 главы этой же книги о целях уровня обслуживания.

Перевод по катом. Приятного чтения!
Читать полностью »

Мониторинг распределённых систем — опыт Google (перевод главы книги Google SRE) - 1

SRE (Site Reliability Engineering) — подход к обеспечению доступности веб-проектов. Считается фреймворком для DevOps и говорит как добиться успеха в применение DevOps-практик. В этой статье перевод Главы 6 Monitoring Distributed Systems книги Site Reliability Engineering от Google. Этот перевод я готовил самостоятельно и полагался на собственный опыт понимания процессов мониторинга. В телеграм-канале @monitorim_it и блоге на Медиуме я публиковал также ссылку на перевод 4 главы этой же книги о целях уровня обслуживания.

Перевод по катом. Приятного чтения!
Читать полностью »

Как оценить ёмкость сервиса и не упасть под нагрузкой - 1

Рано или поздно любому растущему сервису приходится оценивать свои технические возможности. Сколько посетителей мы в силах обслужить? Какова ёмкость (она же capacity) системы? Не добрались ли мы до предела и не упадём ли, если привлечём ещё несколько тысяч пользователей? Сколько дополнительных вычислительных ресурсов заложить в бюджет на следующий год, чтобы соответствовать планам роста?

Ответы можно получить аналитическим путём, адресовав вопросы опытному разработчику/DevOps/SRE/админу. Достоверность оценки зависит от огромного числа факторов: начиная с темпов наполнения системы функциональностью и графа взаимосвязей между компонентами и заканчивая временем, которое эксперт с утра провёл в пробке. Чем сложнее система — тем больше сомнений в адекватности аналитической оценки.

Меня зовут Максим Куприянов, вот уже пять лет я работаю в Яндекс.Маркете. Сегодня я расскажу читателям Хабра, как мы учились оценивать ёмкость наших сервисов и что из этого вышло.
Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js