Size: a a a

SPb Reliability Meetup

2019 April 18

C

Constantine in SPb Reliability Meetup
ты )
источник

p

pragus in SPb Reliability Meetup
я просто периодически смотрю в каких чатиках давно не было активности и выпиливаюсь из таких )))
источник

PR

Paul Rudnitskiy in SPb Reliability Meetup
так у нас тут мало народу... И митапов давно не было)
источник

W

Womchik in SPb Reliability Meetup
Можно бота с анекдотами привести
источник

⚓️Damir in SPb Reliability Meetup
А я как раз хотел вчера спросить.
У меня нет хорошего понимания кто такие SRE вне гугла. В статье - https://blog.alicegoldfuss.com/how-to-get-into-sre/#definition  в том числе пытаются описать SRE:
I’ve seen SRE refer to:
The team that owns incident response
The team that owns internal deployment tooling
The team that owns the data center
The team that owns reliability processes for all of engineering
The team that owns the container platform
The team that owns the databases
The team that owns the network
The team that owns monitoring
The team that is embedded onto dev teams to own all the things devs don’t want to own

Насколько это совпадает с вашим представлением, кто такие SRE?
источник

ST

Sergey Trapeznikov in SPb Reliability Meetup
за исключением последнего
типичное описание девупса в рф
источник

SM

Serg Martynov in SPb Reliability Meetup
Вообще тут отпущен пункт про автоматизацию, почти полностью.
источник

SM

Serg Martynov in SPb Reliability Meetup
Это и отличает от понимания гугловского SRE
источник

ST

Sergey Trapeznikov in SPb Reliability Meetup
Serg Martynov
Это и отличает от понимания гугловского SRE
то есть SRE вне гугла не должен заниматься автоматизацией?)
источник

SM

Serg Martynov in SPb Reliability Meetup
Наоборот должен, вообще без опыта разработки сложно отвечать за доступность серьёзной системы. Надо иметь понимание архитектуры проекта и уметь зафиксить багу.
источник

AM

Aleks Mayer in SPb Reliability Meetup
Serg Martynov
Наоборот должен, вообще без опыта разработки сложно отвечать за доступность серьёзной системы. Надо иметь понимание архитектуры проекта и уметь зафиксить багу.
Какая связь между понимаем архитектуры и умением пофисить багу?
источник

AM

Aleks Mayer in SPb Reliability Meetup
Или умением пофиксить багу и опытом разработки?
Что такое вообще - опыт разработки?
источник

SM

Serg Martynov in SPb Reliability Meetup
Aleks Mayer
Какая связь между понимаем архитектуры и умением пофисить багу?
Самая прямая. Ты можешь увеличением таймаута на ответ спровоцировать каскадный сбой🤷‍♂
источник

ST

Sergey Trapeznikov in SPb Reliability Meetup
Serg Martynov
Наоборот должен, вообще без опыта разработки сложно отвечать за доступность серьёзной системы. Надо иметь понимание архитектуры проекта и уметь зафиксить багу.
А как же шареная ответственность? Разрабы не должны заботиться о доступности своего кода?
источник

ST

Sergey Trapeznikov in SPb Reliability Meetup
Может sre решается тупо доучиванием разрабов мониторингу и отказоустойчивости приложений?
источник

SM

Serg Martynov in SPb Reliability Meetup
Sergey Trapeznikov
А как же шареная ответственность? Разрабы не должны заботиться о доступности своего кода?
Все должны, в классическом трактате гугла SRE как раз и консультируют команды по архитектурным вопросам, чтобы сервис соответствовал минимальным требованиям доступности. Или максимальным.
источник

ST

Sergey Trapeznikov in SPb Reliability Meetup
Aleks Mayer
Или умением пофиксить багу и опытом разработки?
Что такое вообще - опыт разработки?
Интересно, засчитывается ли ямл разработка
источник

DN

Dmitry Nagovitsin in SPb Reliability Meetup
Sergey Trapeznikov
за исключением последнего
типичное описание девупса в рф
А уже сложилось чем занимается типичный девупс? Чёт с этим проблемы были. И да, сре это имплементация девопс
источник

AM

Aleks Mayer in SPb Reliability Meetup
Sergey Trapeznikov
Интересно, засчитывается ли ямл разработка
Вот и я пытаюсь это понять.
источник

AS

Alexander Salimonov in SPb Reliability Meetup
Vasiliy Romaneev
на деле - можно сделать достаточно просто:
1. Есть инфраструктурная команда на компанию.
Она пилит инфраструктуру и выдаёт рекомендации и шаблоны.
2. Есть команда (или SRE в команде) - применяют эти шаблоны на себя.
Таким образом, от разработчика по OPS-части почти ничего не нужно, да и нужно на старте проекта.
Практики от инфраструктурной команды у них есть.
Остаётся только оптимизировать проект под нагрузки. Ну нужен опытный инженер, да, который будет ревьюить, менторить и что там еще нужно от лида.
Это довольно плохо масштабируется. «Инфраструктура», а на деле это пачка темплейтов, спек, либ, пайплайнов и все обмазанное клеем будет только сдерживать развитие.
источник