GK
Да, потому что разработчики не учли их интересов. Потому у каждого свой огород
Size: a a a
2019 October 25
KG
да да именно так. говно на поддержку не примем. нет документации - идите пишите
AK
Цитата:
В модели DevOps границы между группами разработки и эксплуатации стираются. Иногда две эти группы объединяются в одну общую, где инженеры работают над всем жизненным циклом приложения – от разработки и тестирования до развертывания и эксплуатации – и развивают целый ряд навыков, не ограничиваясь узкой специализацией.
В модели DevOps границы между группами разработки и эксплуатации стираются. Иногда две эти группы объединяются в одну общую, где инженеры работают над всем жизненным циклом приложения – от разработки и тестирования до развертывания и эксплуатации – и развивают целый ряд навыков, не ограничиваясь узкой специализацией.
ну это в начале так было. имхо, это примерно как с xerox - изначально это компания, но для большинства людей это та штука в угулу которая доки копирует - ксерокс. так и девопс, культура, модель взаимодействия... нет, теперь это сисадмин
KG
QA гейт вобще должна поддержка проходить
AS
Да, потому что разработчики не учли их интересов. Потому у каждого свой огород
Нет никаких интересов суппорта. Есть общие интересы. Если разработчики сами не заботятся о мониторинге и обсервебилити, то это не менее стремно, чем "не примем на поддержку потому что вы со мной не согласовали".
GK
Нет никаких интересов суппорта. Есть общие интересы. Если разработчики сами не заботятся о мониторинге и обсервебилити, то это не менее стремно, чем "не примем на поддержку потому что вы со мной не согласовали".
Интересы разные, их можно сделать общими. В этом и суть "внедрения" DevOps
AS
Интересы разные, их можно сделать общими. В этом и суть "внедрения" DevOps
Разные интересы это локальная оптимизация. В целом система в этом случае находится в субоптимальном состоянии.
GK
ну это в начале так было. имхо, это примерно как с xerox - изначально это компания, но для большинства людей это та штука в угулу которая доки копирует - ксерокс. так и девопс, культура, модель взаимодействия... нет, теперь это сисадмин
Не совсем так. Можно иметь десяток сисадминов, которые могут на питоне, могут CI/CD, куб и цеф, но при этом в матричной структуре в подразделении саппорта. Без встраивания их продуктовые команды толку будет мало.
GK
Почему это говорю. Лично выстраивал продуктовые команды, с поддержкой менеджмента разумеется, в матричной структуре.
RT
Цитата:
В модели DevOps границы между группами разработки и эксплуатации стираются. Иногда две эти группы объединяются в одну общую, где инженеры работают над всем жизненным циклом приложения – от разработки и тестирования до развертывания и эксплуатации – и развивают целый ряд навыков, не ограничиваясь узкой специализацией.
В модели DevOps границы между группами разработки и эксплуатации стираются. Иногда две эти группы объединяются в одну общую, где инженеры работают над всем жизненным циклом приложения – от разработки и тестирования до развертывания и эксплуатации – и развивают целый ряд навыков, не ограничиваясь узкой специализацией.
На практике я вижу что нужна группа разработки DevOps инфраструктуры (инструментов, платформы) и практика DevOps в командах проудуктов по самостоятельному обслуживанию своей инфраструктуре на базе платформы, которая постороена разработчикой DevOps платформы
AS
Разные интересы именно потому, что разработчики не получают обратной связи от своего продукта, а поддержка не понимает как на самом деле работает система. И пока они не начнут работать, как единое целое ничего принципиально не изменится. Каждый прикроет свою жопу, а проблемы останутся.
GK
На практике я вижу что нужна группа разработки DevOps инфраструктуры (инструментов, платформы) и практика DevOps в командах проудуктов по самостоятельному обслуживанию своей инфраструктуре на базе платформы, которая постороена разработчикой DevOps платформы
Это упрощённый кейс, если строить с нуля.
GK
Разные интересы именно потому, что разработчики не получают обратной связи от своего продукта, а поддержка не понимает как на самом деле работает система. И пока они не начнут работать, как единое целое ничего принципиально не изменится. Каждый прикроет свою жопу, а проблемы останутся.
Да, поэтому нужно выстраивать продуктовые команды и прививать общие интересы. А когда KPI разные, это непросто. Но это возможно, если есть поддержка сверху.
RT
Разные интересы именно потому, что разработчики не получают обратной связи от своего продукта, а поддержка не понимает как на самом деле работает система. И пока они не начнут работать, как единое целое ничего принципиально не изменится. Каждый прикроет свою жопу, а проблемы останутся.
С точки зрения достижения результата это верно.
С точки зрения оптимизации расходов - нет, команду нужно укомплектовать полным набом специалистов разных компетенций, рабочая загрузку у них будет неравномерной.
Это кошмар для ресурс-менеджера, что кто-то будет “недозагружен”.
С точки зрения оптимизации расходов - нет, команду нужно укомплектовать полным набом специалистов разных компетенций, рабочая загрузку у них будет неравномерной.
Это кошмар для ресурс-менеджера, что кто-то будет “недозагружен”.
AS
На практике я вижу что нужна группа разработки DevOps инфраструктуры (инструментов, платформы) и практика DevOps в командах проудуктов по самостоятельному обслуживанию своей инфраструктуре на базе платформы, которая постороена разработчикой DevOps платформы
Почитайте статью от Netflix. Они сделали платформенные команды, только для того, чтобы упростить жизнь продуктовым. При этом продуктовые команды не обязаны (ключевое слово!) использовать продукты платформенной команды. Главное, чтобы конечное решение соответствовало нефункциональным требованиям. То есть в общем платформенных команд стоит избегать как можно дольше. По крайней мере до тех пор пока создание своего продукта станет выгоднее, чем силами продуктовой команды внедрить что-то существующее на рынке.
GK
С точки зрения достижения результата это верно.
С точки зрения оптимизации расходов - нет, команду нужно укомплектовать полным набом специалистов разных компетенций, рабочая загрузку у них будет неравномерной.
Это кошмар для ресурс-менеджера, что кто-то будет “недозагружен”.
С точки зрения оптимизации расходов - нет, команду нужно укомплектовать полным набом специалистов разных компетенций, рабочая загрузку у них будет неравномерной.
Это кошмар для ресурс-менеджера, что кто-то будет “недозагружен”.
Всё усложняется тем, что команда может состоять из людей которые работают в разных подразделениях и у них разные ресур-менеджеры
RT
Почитайте статью от Netflix. Они сделали платформенные команды, только для того, чтобы упростить жизнь продуктовым. При этом продуктовые команды не обязаны (ключевое слово!) использовать продукты платформенной команды. Главное, чтобы конечное решение соответствовало нефункциональным требованиям. То есть в общем платформенных команд стоит избегать как можно дольше. По крайней мере до тех пор пока создание своего продукта станет выгоднее, чем силами продуктовой команды внедрить что-то существующее на рынке.
Мы в целом идем по этому же пути)
AS
Платформенные команды чаще всего делают жалкое подобие реальных инструментов, которые сильно осложняют жить продуктовым.
GK
Мы в целом идем по этому же пути)
Видимо, это есть некий новый виток эволюции.
AS
И делают проприетарный продукт, который существует ровно до тех пор пока менеджмент его навязывает продуктовым