Автору👍. Жду статью про путь с Interactive Brokers 🤗

«If DevOps is a sausage then SRE is a sizzle!»

В простонародье три буквы SRE могут относиться к:
Simple Restart Everything, или Sysadmin (Really Expensive), или Server Reboot Engineer или Sometimes Reliable Engineer...

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

Пока вы, как инженер, не столкнетесь с реальными задачами бизнеса нуждающегося в «Site Reliability Engineering», определить, что нужно конкретно от вас, DevOps, CloudOps, SecOps, SysOps, как от инженера — зачастую бывает довольно проблематично. И тут не важно сколько вы знаете про Гугл с их error budget...пока вы не потрудитесь в схожей компании с подобными проблемами и процессами.

Практики создания и поддержки надежной SaaS платформы «в масштабе» своего рода и есть Site Reliability.

Так как «классический» DevOps очень тяжело определить и померять, SRE как концепция более четко структурирована и определена для организации и команд.

На украинском рынке очень мало продуктовых компаний и еще меньше тех, кто дорос до уровня внедрения reliability в свой продукт. Для многих стремление к максимальной стабильности системы является бессмысленным и контрпродуктивным.

Очень тяжело научиться измерять и доносить важные для бизнеса показатели, если бизнес не понимает зачем это нужно — внедрение и обучение занимает много времени и ресурсов. В конце концов, как вы можете провести содержательную беседу с разработчиками о надежности сервисов компании, без должной оценки и измерения этой самой надежности?

Многие организации реагирует на инженерные проблемы эмоциями, вместо извлечения уроков из метрик или репортов. И кажется, что SRE устанавливает еще один набор ограничений. Но только так вы можете приступить к процессу повышения reliability.

При этом, бывает, что командам работающим с SRE стандартами, не хватает осознанности и согласованности в понимании и адаптация таких практик, как SLOs или, например blameless postmortems, что на самом деле способствует более ясному определению и «кодификации» четких ожиданий от них самих. Тут преодоление вами как специалистом различных организационных барьеров, может иногда отнимать не только веру, а и возможность разрабатывать программные системы для решения сложных проблем.

И наверное только в такие моменты, действительно начинаешь понимать

смысл SRE и чем они отличаются от DevOps

... ;)

Можно сказать, что это две стороны одной медали. Но уровень погружения в продукт у SRE все-таки больше. Главное понимать, где начинается этот продукт, а где outsource или outstaff. В противном случае ваша работа будет больше OPS, чем SRE.