Комментарии 12
Напомню, что SRE — это человек, который должен, владеть всем, чем владеет DevOps, и при этом иметь навыки разработки, больше заниматься надёжностью, доступностью и масштабируемостью систем.
То есть девопсам навыками разработки обладать не нужно?
Ну вообще странно видеть в статье которая позиционируется как анализ такой недочет. В полемику я вступать конечно не буду, достаточно прочитать две книги, про то как devops меняет мир и sre гугловскую и сразу понятно чем эти вещи отличаются.
Как я понял общаясь с коллегами, в банках вообще какое-то своё понимание кто такой devops инженер и причём в каждом банке это понимание своё.
Это не только в банках. В каждой компании своё понимание )
Я за свой опыт работы в СБЕР и ВТБ встречал коллег с таким же профилем должности как у меня, но совершено разными скилсетами и должностными обязаностями. Так что чаще вообще даже не организация определяет что делает DevOps, а конкретный трайб, стрим, либо кросс-функциональная команда.
Весело становится когда говорят: "У нас DevOps инженер простаивает" и тебя кидают на частичную занятость в другую команду где может даже оркестратор другой использоваться, или DevOps IaC занимается без микросервисов. Но ничего, менеджеры то знают что DevOps-инженер магическим образом решит все проблемы.
DevOps-теория не реализовалась на практике.
Видимо потому что не было никакой теории, а лишь чьи-то хотелки, которые не опирались на действительность. А в действительности все хотят сидеть за стенами и перекидывать ответственость за неё. В этом смысле девопс даже вреден.. ходит тут стены ломает, людям работать мешает))
Будущего у девопс-инженера примерно два:
Уйти в корпорцию и стать "набором инструментов" узкозаточеных на определённом куске "платформы".
Существовать в небольших стартапах оставаясь универсалом-многостаночником.
Непонятно что понимается под навыками разработки у SRE в данной статье.
Спасибо, статья интересная. Идея "Мы стремимся избавить продуктовые команды от DevOps-специалистов" звучит отлично, а как с этим на практике?
В своём опыте работал в разных командах и везде разный уровень людей в разработке. Кто-то постоянно в запаре и не может/не хочет вникать вообще во что-то из девопс задач: деплой в прод ночью, откат, добавить переменную окружения к микросервису и ещё кучу всего, что обычно просят нас делать :) Люди либо не хотят, либо не умеют вникать, потому что привыкли, что есть девопс к которому можно прийти и попросить сделать, потому что это всегда девопсы и делают.
Полагаю, что для достижения желаемого ( из моего первого абзаца) должен быть очень высокий уровень процессов и культуры в команде/проекте. Что вообще редкость. Я, например, нигде не видел настоящего CI, чтобы каждый день все правки шли в мастер и была постоянная интеграция. Что говорить про остальное)
Тут плюсую. На мой взгляд, это часто происходит в быстро растущих отделах/командах внутри крупных компаний. Допустим, DevOps-инженер с нуля создал автоматизацию, и предвкушает, что теперь сможет спокойно улучшать и развивать своё костыльное MVP решение с конвейером поставок. Однако вместо этого его верный коллега менеджер просит внедрить полумёртвое решение ещё на пару других систем, либо все решают, что "и так сойдёт", и ставят другие приоритетные задачи. В итоге накапливается технический долг, тормозится технологическое развитие функциональности поставки. Получается, что DevOps-инженер превращается в хомяка, бегущего по своему колесу, надеясь, что однажды появится возможность заняться рефакторингом и развитием текущих процессов. Но момент этот никогда не наступает, проект успешно сдают и закрывают, передают на сопровождение с техническим долгом, а DevOps-инженер переходит к разработке новой информационной системы. Это мой опыт, не вижу смысла с этого пригорать, мне понятно что бизнес хочет быстрее закрыть свои эпики, попасть во все KPI и всем безразницы что там под капотом крутится. tldr; Welcome to Agile.
P.S.
Не обязательно в моем примере привязываться к автоматизации и CI/CD, это может быть и канареечное развертывание, и организация нагрузочного тестирования, и возможность делать откаты схем без накатки бекапов и т.п.
DevOps - это практика, автор описывает именно ок ситуацию, которая возникла в крупных забюрократизированных компаниях типа банков - под DevOps подразумевается заповедник гоблинов из сисадминов на стероидах, а чтобы прийти и реализовать DevOps практику - необходимо менять процессы и способ мышления, тут этого до сих пор не произошло.
Название DevOps вообще получилось случайно. А цель у Патрика Дебуа была именно админов под заточить по Agile практики. А дальше натянули сову на глобус.
Будущее DevOps-инженера