Офер за 1 день в команду BetterMe (Frontend Hiring, JavaScript/React/Redux)
×Закрыть
Lead SRE в SPSCommerce
  • Карьера в IT: Site Reliability Engineer

    «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.