В течение своей карьеры мне приходилось работать в командах и компаниях, где в качестве разработчика я помещал код в репозиторий и просто надеялся, что все будет хорошо, когда какой-нибудь мифический сисадмин в конце концов не запустит его в продакшн. Случалось и то, что мне нужно было подготовить «голые» сервера в понедельник, разработать стратегию развертывания во вторник, написать некоторую бизнес-логику в среду, развернуть ее в четверг и разобраться с неполадками в пятницу. И все это, даже не подозревая о существовании таких модных терминов, как DevOps или SRE-инженер.
Но затем люди вокруг меня начали говорить о DevOps и SRE, сравнивать их друг с другом и составлять списки с потрясающими материалами по теме. Открылись новые возможности трудоустройства, и я быстро подсуетился. Итак, далее мой опыт работы в SRE и Platform Engineering с точки зрения бывшего разработчика ПО. И да, я думаю, что эта информация применима в первую очередь для компаний, продукт которых представляет собой некоторый веб-сервис. Именно в такой компании я проработал десять лет. Люди, занимающиеся встраиваемыми системами или разработкой баз данных, вероятно, живут в совершенно других реалиях.
Здесь все просто. Разработка — это прикладное программирование, т.е. написание бизнес-логики вашего основного продукта. Это единственная деятельность из трех, обсуждаемых здесь, которая напрямую приносит деньги компании.
![]()
Единственное, для чего создана компания, это, конечно же, продажи, все остальное — расходы :)
— ⊥nɹqöSןɐʌıʞ (@slavadotcom)July 31, 2021
ИМХО, разработка — это супер круто! Как разработчик, вы быстро начинаете думать, что вы — самый важный человек на свете. Без вашего кода ничего нет. Но, очевидно, недостаточно просто писать код. Код должен быть загружен в продакшн и выполнен там.
Я носил гордое звание Software Developer (или Software Engineer) с самого начала моей карьеры в 2011 году. И до сих пор помню ту боль — я всегда хотел иметь контроль над развертыванием своего кода. Такое случалось редко. Вместо этого — какая-то непонятная процедура, когда кто-то, обычно даже не ваш старший коллега, имеет доступ к рабочим серверам и развертывает там код. Таким образом, если после внесений изменений в репозиторий вам не повезло заметить баг только в live-версии сервиса, вам нужно просить о дополнительном развертывании. Полный отстой.
Даже не буду пытаться цитировать здесь официальное определение. Вместо этого я поделюсь личным опытом. Для меня DevOps был культурным сдвигом, дающим командам разработчиков больше контроля над загрузкой кода в продакшн. Реализация может быть разной. Я работал в командах, где разработчики просто имели
В идеальном мире GitOps-разработчики по-прежнему будут просто помещать код в репозитории. Тем не менее где-то в распоряжении команды появится волшебная кнопка, которая запустит новую версию или, возможно, даже выделит часть инфраструктуры для удовлетворения новых требований.
Первоначальная идея DevOps, вероятно, была намного шире. Но исходя из того, что я вижу в описаниях вакансий и что я слышу от рекрутеров и коллег, DevOps-инженеров, в большинстве случаев речь идет о создании эффективного способа развертывания материалов, созданных в процессе разработки. В более продвинутых кейсах DevOps также может быть связан с другими вещами, повышающими скорость разработки. Но сам DevOps при всем этом никогда не касается самой бизнес-логики приложения.
У Google есть отличная серия книг,объясняющая идею Site Reliability Engineering, и что еще более важно для меня, рассказывающая о некоторых реальных технических практиках, используемых SRE-инженерами в Google. В частности, там говорится, что SRE является лишь одним из способов реализации культуры DevOps —
Такое объяснение мне особо не помогло. Но что было еще более странным, подсознательно я всегда чувствовал восхищение при чтении, чем занимаются SRE-инженеры, и ощущал скуку, когда вспоминал о DevOps… Так что разница явно была, но я долго не мог ее уловить.
Конечно, это просто мои личные предпочтения, но всякий раз, когда кто-то упоминает о настройке CI/CD-конвейера, я впадаю в депрессию. И в настоящее время в DevOps полным-полно подобных задач. Не поймите неправильно, CI/CD-конвейеры восхитительны! Я счастлив, когда у меня есть возможность использовать их. Но я не получаю удовольствия от их настройки. С другой стороны, я всегда рад помочь, когда кто-то просит меня вскочить и взглянуть на «кровоточащую рану» в продакшене, будь то баг, утечка памяти или ухудшение производительности.
Разработка кода и загрузка его в продакшн по-прежнему не составляют полной картины. Кто-то должен поддерживать продакшн живым и здоровым! И именно это место занимает SRE в моей модели мира.
Книга Google SRE рассматривает следующие темы: мониторинг и оповещения, определение SLO ваших сервисов и контроль за бюджетами на ошибки (error budgets), реагирование на инциденты и последующий анализ. Все это помогает сделать продакшн надежней. В Facebook существует знаменитая роль Production Engineer, но ее довольно трудно отличить от типичной роли SRE, если судить только по описанию обязанностей.
Вот также отличный твит, который подтверждает мое мнение, что основной задачей SRE является продакшн.
Мой очень упрощенный ответ, когда кто-то спрашивает в чем разница между SRE и DevOps.
* SRE = ориентирован в первую очередь на продакшн
* DevOps = ориентирован в первую очередь на CI/CD и скорость разработки
— Tammy Bryant Butow ⚓ (@tambryantbutow)June 16, 2021
И еще один:
Мне нравится! Мой типичный ответ:
SRE работает от прода назад. DevOps работает от разработки вперед. Где-то посередине они встречаются.
– Гэри Похрон (@garypochron)16 июня 2021 г.
Таким образом, DevOps поддерживает актуальность прода. SRE обеспечивает стабильность прода.
UPD: Брюс Домингес недавно опубликовал статью с некоторыми мыслями, что отличает SRE-команды от команд Ops или Platform Engineering, и они перекликается с моим опытом. ROAD to SRE описывает ключевые направления деятельности SRE-команды (и ИМХО, порядок имеет значение):
Когда я был единственным инженером в стартапе, приличная часть моей работы заключалась в том, чтобы превратить некоторые типовые ресурсы, которые я арендовал у провайдера инфраструктуры, во что-то более адаптированное к потребностям компании. Итак, у меня была куча скриптов для подготовки нового сервера, некоторое понимание того, как обеспечить сетевое подключение между нашими серверами в разных дата-центрах, некоторые навыки репликации production на staging и, возможно, написания одного или двух демонов, чтобы помочь мне со сбором логов. Я не совсем понимал, что к чему, но всё это составляло нашу Платформу.
Присоединившись к гораздо более крупной компании и начав изучение тем, связанных с инфраструктурой, я понял, что существует третья область, которая может быть довольно близка к DevOps и SRE. Она называется Platform Engineering.
Насколько я понимаю, Platform Engineering фокусируется на разработке экосистемы, которая может быть эффективно использована с точки зрения Dev, Ops и SRE.
Platform Engineering может включать в себя написание кода. Или акцентировать внимание на конфигурации. Но опять же, речь идет не о первичной бизнес-логике вашего продукта, а о том, чтобы сделать некоторую базовую инфраструктуру более подходящей для повседневных потребностей.
Platform Engineering — это не разработка инфраструктуры.
Platform Engineering заключается в том, чтобы позволить другим делать все, что они хотят делать.
На своей заре Twitter был великолепной платформой, не имеющей ничего общего с инфраструктурой: t.co/6hKdaIxYOt
— Ivan Pedrazas (@ipedrazas)July 31, 2021
Честно говоря, я не вижу противоречия между моим взглядом на Platform Engineering и объяснением из этого твита. Разработка требует инфраструктуры для выполнения кода. Таким образом, если Platform Engineering заключается в том, чтобы позволить другим делать все, что они хотят делать, по крайней мере, частично, то PE должно быть связано с разработкой инфраструктуры.
У меня есть ощущение, что в ситуации, когда компания имеет тысячи «голых» серверов в своих собственных дата-центрах, Platform Engineering начнется с управления этим парком машин. Таким образом, может потребоваться установка или даже разработка какого-то ПО для инвентаризации. Установка операционных систем и базовых пакетов на подготавливаемых серверах, вероятно, также входит в обязанности разработчика платформы.
К счастью, облачные технологии позволили Platform Engineering работать на гораздо более высоких уровнях. Все основные задачи по управлению парком машин уже решены за вас. И даже оркестровка рабочих нагрузок решается такими проектами, как Kubernetes или AWS ECS. Однако решение довольно универсальное, а ваши команды, скорее всего, будут развертывать очень похожие микросервисы. Таким образом, предоставление им шаблона проекта по умолчанию, который будет интегрирован с подсистемами сбора метрик и журналов компании, значительно ускорит работу.
До сих пор я намеренно избегал разговоров о ролях и должностях. Development, Operations, SRE, и Platform Engineering для меня — это вопрос о расстановки акцентов. И в гораздо меньшей степени вопрос о названии должности. Один человек может быть Dev на этой неделе, затем Ops на следующей неделе и SRE через неделю.
По моему опыту, разделение между Dev, Ops, SRE и PE становится более очевидным, когда размер компании становится больше. Больший размер компании обычно означает больше специалистов и меньше универсалов. Вот так вы получаете выделенные SRE-команды и отдел по Platform Engineering. Но, конечно, это не строгое правило. Например, в должности SRE я потратил около года, занимаясь всеми вещами истинного SRE (SLO, мониторинг, оповещение, реагирование на инциденты), а затем перешел в Platform Engineering, где больше занимался разработкой инфраструктуры, чем традиционным SRE.
Замечательно, но куда вовлечена команда безопасности с точки зрения DevOps и SRE?
— Saliou Fall (@S4L1OU)July 31, 2021
Это очень хороший вопрос! Но у меня нет простого ответа. Разумный подход заключается в том, чтобы сделать безопасность сквозной темой в Dev, Ops, SRE и PE. Различные проблемы безопасности могут быть решены на разных уровнях с использованием разных инструментов. Например, разработка может быть связана с предотвращением SQL-инъекций, в то время как разработчики платформы могут укрепить сеть, настроив некоторые причудливые cilium policies.
Не забывайте, все вышеперечисленное — ИМХО ;)
Но затем люди вокруг меня начали говорить о DevOps и SRE, сравнивать их друг с другом и составлять списки с потрясающими материалами по теме. Открылись новые возможности трудоустройства, и я быстро подсуетился. Итак, далее мой опыт работы в SRE и Platform Engineering с точки зрения бывшего разработчика ПО. И да, я думаю, что эта информация применима в первую очередь для компаний, продукт которых представляет собой некоторый веб-сервис. Именно в такой компании я проработал десять лет. Люди, занимающиеся встраиваемыми системами или разработкой баз данных, вероятно, живут в совершенно других реалиях.
Что такое Development?
Здесь все просто. Разработка — это прикладное программирование, т.е. написание бизнес-логики вашего основного продукта. Это единственная деятельность из трех, обсуждаемых здесь, которая напрямую приносит деньги компании.
Единственное, для чего создана компания, это, конечно же, продажи, все остальное — расходы :)
— ⊥nɹqöSןɐʌıʞ (@slavadotcom)July 31, 2021
ИМХО, разработка — это супер круто! Как разработчик, вы быстро начинаете думать, что вы — самый важный человек на свете. Без вашего кода ничего нет. Но, очевидно, недостаточно просто писать код. Код должен быть загружен в продакшн и выполнен там.
Я носил гордое звание Software Developer (или Software Engineer) с самого начала моей карьеры в 2011 году. И до сих пор помню ту боль — я всегда хотел иметь контроль над развертыванием своего кода. Такое случалось редко. Вместо этого — какая-то непонятная процедура, когда кто-то, обычно даже не ваш старший коллега, имеет доступ к рабочим серверам и развертывает там код. Таким образом, если после внесений изменений в репозиторий вам не повезло заметить баг только в live-версии сервиса, вам нужно просить о дополнительном развертывании. Полный отстой.
Что такое DevOps
Даже не буду пытаться цитировать здесь официальное определение. Вместо этого я поделюсь личным опытом. Для меня DevOps был культурным сдвигом, дающим командам разработчиков больше контроля над загрузкой кода в продакшн. Реализация может быть разной. Я работал в командах, где разработчики просто имели
sudo на рабочих серверах. Но, вероятно, наиболее распространенным подходом является предоставление командам разработчиков какого-нибудь CI/CD-конвейера. В идеальном мире GitOps-разработчики по-прежнему будут просто помещать код в репозитории. Тем не менее где-то в распоряжении команды появится волшебная кнопка, которая запустит новую версию или, возможно, даже выделит часть инфраструктуры для удовлетворения новых требований.
Первоначальная идея DevOps, вероятно, была намного шире. Но исходя из того, что я вижу в описаниях вакансий и что я слышу от рекрутеров и коллег, DevOps-инженеров, в большинстве случаев речь идет о создании эффективного способа развертывания материалов, созданных в процессе разработки. В более продвинутых кейсах DevOps также может быть связан с другими вещами, повышающими скорость разработки. Но сам DevOps при всем этом никогда не касается самой бизнес-логики приложения.
Что такое SRE
У Google есть отличная серия книг,объясняющая идею Site Reliability Engineering, и что еще более важно для меня, рассказывающая о некоторых реальных технических практиках, используемых SRE-инженерами в Google. В частности, там говорится, что SRE является лишь одним из способов реализации культуры DevOps —
class SRE implements DevOps {}.Такое объяснение мне особо не помогло. Но что было еще более странным, подсознательно я всегда чувствовал восхищение при чтении, чем занимаются SRE-инженеры, и ощущал скуку, когда вспоминал о DevOps… Так что разница явно была, но я долго не мог ее уловить.
Конечно, это просто мои личные предпочтения, но всякий раз, когда кто-то упоминает о настройке CI/CD-конвейера, я впадаю в депрессию. И в настоящее время в DevOps полным-полно подобных задач. Не поймите неправильно, CI/CD-конвейеры восхитительны! Я счастлив, когда у меня есть возможность использовать их. Но я не получаю удовольствия от их настройки. С другой стороны, я всегда рад помочь, когда кто-то просит меня вскочить и взглянуть на «кровоточащую рану» в продакшене, будь то баг, утечка памяти или ухудшение производительности.
Разработка кода и загрузка его в продакшн по-прежнему не составляют полной картины. Кто-то должен поддерживать продакшн живым и здоровым! И именно это место занимает SRE в моей модели мира.
Книга Google SRE рассматривает следующие темы: мониторинг и оповещения, определение SLO ваших сервисов и контроль за бюджетами на ошибки (error budgets), реагирование на инциденты и последующий анализ. Все это помогает сделать продакшн надежней. В Facebook существует знаменитая роль Production Engineer, но ее довольно трудно отличить от типичной роли SRE, если судить только по описанию обязанностей.
Вот также отличный твит, который подтверждает мое мнение, что основной задачей SRE является продакшн.
Мой очень упрощенный ответ, когда кто-то спрашивает в чем разница между SRE и DevOps.
* SRE = ориентирован в первую очередь на продакшн
* DevOps = ориентирован в первую очередь на CI/CD и скорость разработки
— Tammy Bryant Butow ⚓ (@tambryantbutow)June 16, 2021
И еще один:
Мне нравится! Мой типичный ответ:
SRE работает от прода назад. DevOps работает от разработки вперед. Где-то посередине они встречаются.
– Гэри Похрон (@garypochron)16 июня 2021 г.
Таким образом, DevOps поддерживает актуальность прода. SRE обеспечивает стабильность прода.
UPD: Брюс Домингес недавно опубликовал статью с некоторыми мыслями, что отличает SRE-команды от команд Ops или Platform Engineering, и они перекликается с моим опытом. ROAD to SRE описывает ключевые направления деятельности SRE-команды (и ИМХО, порядок имеет значение):
- Response (Реагирование) — создание эффективной культуры реагирования на инциденты
- Observability (Наблюдаемость) — инструментирование, мониторинг и оповещение
- Availability & Reliability (Доступность и надежность) — SLI/SLO и управление сбоями
- Delivery (Доставка) — эффективное построение, инициализация и развертывание (IaC, CI/CD и т.д.)
Что такое Platform Engineering
Когда я был единственным инженером в стартапе, приличная часть моей работы заключалась в том, чтобы превратить некоторые типовые ресурсы, которые я арендовал у провайдера инфраструктуры, во что-то более адаптированное к потребностям компании. Итак, у меня была куча скриптов для подготовки нового сервера, некоторое понимание того, как обеспечить сетевое подключение между нашими серверами в разных дата-центрах, некоторые навыки репликации production на staging и, возможно, написания одного или двух демонов, чтобы помочь мне со сбором логов. Я не совсем понимал, что к чему, но всё это составляло нашу Платформу.
Присоединившись к гораздо более крупной компании и начав изучение тем, связанных с инфраструктурой, я понял, что существует третья область, которая может быть довольно близка к DevOps и SRE. Она называется Platform Engineering.
Насколько я понимаю, Platform Engineering фокусируется на разработке экосистемы, которая может быть эффективно использована с точки зрения Dev, Ops и SRE.
Platform Engineering может включать в себя написание кода. Или акцентировать внимание на конфигурации. Но опять же, речь идет не о первичной бизнес-логике вашего продукта, а о том, чтобы сделать некоторую базовую инфраструктуру более подходящей для повседневных потребностей.
Platform Engineering — это не разработка инфраструктуры.
Platform Engineering заключается в том, чтобы позволить другим делать все, что они хотят делать.
На своей заре Twitter был великолепной платформой, не имеющей ничего общего с инфраструктурой: t.co/6hKdaIxYOt
— Ivan Pedrazas (@ipedrazas)July 31, 2021
Честно говоря, я не вижу противоречия между моим взглядом на Platform Engineering и объяснением из этого твита. Разработка требует инфраструктуры для выполнения кода. Таким образом, если Platform Engineering заключается в том, чтобы позволить другим делать все, что они хотят делать, по крайней мере, частично, то PE должно быть связано с разработкой инфраструктуры.
У меня есть ощущение, что в ситуации, когда компания имеет тысячи «голых» серверов в своих собственных дата-центрах, Platform Engineering начнется с управления этим парком машин. Таким образом, может потребоваться установка или даже разработка какого-то ПО для инвентаризации. Установка операционных систем и базовых пакетов на подготавливаемых серверах, вероятно, также входит в обязанности разработчика платформы.
К счастью, облачные технологии позволили Platform Engineering работать на гораздо более высоких уровнях. Все основные задачи по управлению парком машин уже решены за вас. И даже оркестровка рабочих нагрузок решается такими проектами, как Kubernetes или AWS ECS. Однако решение довольно универсальное, а ваши команды, скорее всего, будут развертывать очень похожие микросервисы. Таким образом, предоставление им шаблона проекта по умолчанию, который будет интегрирован с подсистемами сбора метрик и журналов компании, значительно ускорит работу.
Что насчет должностей?
До сих пор я намеренно избегал разговоров о ролях и должностях. Development, Operations, SRE, и Platform Engineering для меня — это вопрос о расстановки акцентов. И в гораздо меньшей степени вопрос о названии должности. Один человек может быть Dev на этой неделе, затем Ops на следующей неделе и SRE через неделю.
По моему опыту, разделение между Dev, Ops, SRE и PE становится более очевидным, когда размер компании становится больше. Больший размер компании обычно означает больше специалистов и меньше универсалов. Вот так вы получаете выделенные SRE-команды и отдел по Platform Engineering. Но, конечно, это не строгое правило. Например, в должности SRE я потратил около года, занимаясь всеми вещами истинного SRE (SLO, мониторинг, оповещение, реагирование на инциденты), а затем перешел в Platform Engineering, где больше занимался разработкой инфраструктуры, чем традиционным SRE.
А что с Security?
Замечательно, но куда вовлечена команда безопасности с точки зрения DevOps и SRE?
— Saliou Fall (@S4L1OU)July 31, 2021
Это очень хороший вопрос! Но у меня нет простого ответа. Разумный подход заключается в том, чтобы сделать безопасность сквозной темой в Dev, Ops, SRE и PE. Различные проблемы безопасности могут быть решены на разных уровнях с использованием разных инструментов. Например, разработка может быть связана с предотвращением SQL-инъекций, в то время как разработчики платформы могут укрепить сеть, настроив некоторые причудливые cilium policies.
Вместо заключения
Не забывайте, все вышеперечисленное — ИМХО ;)