Комментарии

Есть две хорошие практики, которые может взять на вооружение любая команда.

Бюджет ошибки. SRE-команды считают так называемый бюджет ошибки — допустимый период, в течение которого сервис может работать ниже целевых уровней. С помощью бюджета можно измерять серьёзность инцидентов. Если, например, инцидент истратил 30% бюджета, его можно считать серьёзным. Это помогает SRE-инженерам не отвлекаться на минорные проблемы, которые регулярно возникают даже в самых оттестированных проектах.

Постмортемы. Это грустное слово означает отчёт или небольшую статью, которую пишут по результатам решения проблемы. С помощью постмортемов SRE-инженер делится важным знанием с командами разработки, помогая избежать ошибок в будущих проектах.

Хорошо. А чему разработчики и команды могут научиться у парадигмы SRE, даже если таких специалистов в штате нет?

Вроде того, он настоящий Бэтмен. Чтобы задержать преступника быстрее полиции, важно действовать не хуже настоящего полицейского. SRE должен разбираться в инфраструктуре, конфигурации серверов, быстро читать логи. Он умеет писать код не хуже программистов — ведь часто для исправления бага нужно быстро переписать что-то руками.

Чтобы работать очень быстро, в SRE используют парадигму «инфраструктура как код». Инженеры могут управлять инфраструктурой и настраивать её через процедуры в коде — так они работают со всеми компонентами в одной среде и не отвлекаются на ручное «накликивание» настроек серверов.

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

Получается, SRE-специалист — это такой сисадмин-девопс-программист

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

Но обычного письма или пуша для SRE-инженера мало. Алерт в его случае работает многоступенчато. Например, сперва разработчик получает уведомление через телеграм-бота. После этого он должен быстро отметить в мониторинговой админке, что увидел проблему. Если этого не сделать, мониторинг начнёт звонить SRE-специалисту по телефону, вызывая на бой с багами. Многоступенчатость важна, ведь сервис может упасть и ночью, а во сне можно случайно пропустить вызов или машинально отменить его, как будильник.

В небольших и средних компаниях обычно дежурит один SRE-инженер. Если он пропустит алерт, то решение ситуации придётся откладывать. В больших компаниях инженеров сразу несколько — они могут подстраховать друг друга.

А как SRE узнает, что что-то случилось?

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

В компаниях с командой из 10–15 человек можно обойтись без SRE: обычно разработчики дежурят по очереди. А вот большому высоконагруженному сервису, например банку, без такого специалиста не обойтись: в случае проблем счёт идёт на минуты.

А что в такой ситуации сделает SRE-инженер?

Была — но её обеспечивали иначе. Представим большой и популярный онлайн-кинотеатр. Это сложный сервис, который должен показывать сериалы и фильмы 24/7 с минимальной задержкой.

Предположим, что в пятницу у сервиса два важных события: вечером выходит финальный эпизод сериала «Игры у стола» и тем же вечером разработчики апдейтят бэк. Тесты проходят, всё работает, «Игры» летят — разработчики уходят в бар отмечать долгожданный релиз. А в субботу утром десятки тысяч людей не могут нормально посмотреть сериал: вместо 20 мс сайт работает с задержкой 100500 мс.

При традиционном подходе к надёжности первыми о ситуации узнают сотрудники поддержки, ведь расстроенные зрители заполнят все чаты. Специалист поддержки не может восстановить работу сервиса — он эскалирует проблему, передав её в технический хелп. Там увидят, что случилась большая беда, и начнут вызванивать разработчиков. Не факт, что все они на связи в субботу, ведь у всех нас есть свои дела по выходным. В итоге через несколько часов соберётся консилиум программистов и будет решать, что делать: откатывать апдейт или попытаться пофиксить текущий билд. На восстановление нормальной работоспособности уйдут часы или даже дни — а такой простой очень дорого обходится бизнесу.

А что, до SRE безотказности сервисов не было?

Есть две хорошие практики, которые может взять на вооружение любая команда.

Бюджет ошибки. SRE-команды считают так называемый бюджет ошибки — допустимый период, в течение которого сервис может работать ниже целевых уровней. С помощью бюджета можно измерять серьёзность инцидентов. Если, например, инцидент истратил 30% бюджета, его можно считать серьёзным. Это помогает SRE-инженерам не отвлекаться на минорные проблемы, которые регулярно возникают даже в самых оттестированных проектах.

Постмортемы. Это грустное слово означает отчёт или небольшую статью, которую пишут по результатам решения проблемы. С помощью постмортемов SRE-инженер делится важным знанием с командами разработки, помогая избежать ошибок в будущих проектах.

Хорошо. А чему разработчики и команды могут научиться у парадигмы SRE, даже если таких специалистов в штате нет?

Вроде того, он настоящий Бэтмен. Чтобы задержать преступника быстрее полиции, важно действовать не хуже настоящего полицейского. SRE должен разбираться в инфраструктуре, конфигурации серверов, быстро читать логи. Он умеет писать код не хуже программистов — ведь часто для исправления бага нужно быстро переписать что-то руками.

Чтобы работать очень быстро, в SRE используют парадигму «инфраструктура как код». Инженеры могут управлять инфраструктурой и настраивать её через процедуры в коде — так они работают со всеми компонентами в одной среде и не отвлекаются на ручное «накликивание» настроек серверов.

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

Получается, SRE-специалист — это такой сисадмин-девопс-программист

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

Но обычного письма или пуша для SRE-инженера мало. Алерт в его случае работает многоступенчато. Например, сперва разработчик получает уведомление через телеграм-бота. После этого он должен быстро отметить в мониторинговой админке, что увидел проблему. Если этого не сделать, мониторинг начнёт звонить SRE-специалисту по телефону, вызывая на бой с багами. Многоступенчатость важна, ведь сервис может упасть и ночью, а во сне можно случайно пропустить вызов или машинально отменить его, как будильник.

В небольших и средних компаниях обычно дежурит один SRE-инженер. Если он пропустит алерт, то решение ситуации придётся откладывать. В больших компаниях инженеров сразу несколько — они могут подстраховать друг друга.

А как SRE узнает, что что-то случилось?

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

В компаниях с командой из 10–15 человек можно обойтись без SRE: обычно разработчики дежурят по очереди. А вот большому высоконагруженному сервису, например банку, без такого специалиста не обойтись: в случае проблем счёт идёт на минуты.

А что в такой ситуации сделает SRE-инженер?

Была — но её обеспечивали иначе. Представим большой и популярный онлайн-кинотеатр. Это сложный сервис, который должен показывать сериалы и фильмы 24/7 с минимальной задержкой.

Предположим, что в пятницу у сервиса два важных события: вечером выходит финальный эпизод сериала «Игры у стола» и тем же вечером разработчики апдейтят бэк. Тесты проходят, всё работает, «Игры» летят — разработчики уходят в бар отмечать долгожданный релиз. А в субботу утром десятки тысяч людей не могут нормально посмотреть сериал: вместо 20 мс сайт работает с задержкой 100500 мс.

При традиционном подходе к надёжности первыми о ситуации узнают сотрудники поддержки, ведь расстроенные зрители заполнят все чаты. Специалист поддержки не может восстановить работу сервиса — он эскалирует проблему, передав её в технический хелп. Там увидят, что случилась большая беда, и начнут вызванивать разработчиков. Не факт, что все они на связи в субботу, ведь у всех нас есть свои дела по выходным. В итоге через несколько часов соберётся консилиум программистов и будет решать, что делать: откатывать апдейт или попытаться пофиксить текущий билд. На восстановление нормальной работоспособности уйдут часы или даже дни — а такой простой очень дорого обходится бизнесу.

А что, до SRE безотказности сервисов не было?