В Амазоне есть команды, которые разрабатывают и поддерживают отдельные сервисы (команды разработки), они же как понимаю занимаются SRE.
Эти команды разрабатывают свои сервисы поверх других сервисов, предоставляемых Амазоном как платформой (эти сервисы разрабатываются в точно такой же модели).
Для быстрого старта новых команд (внутренних и клиентских) у них есть роль Cloud Solution Architect, и высокоуровневые сервисы типа Amplify, как и большое количество всегда актуальной документации, референсных архитектур, типовых решений для старта, опенсорс инструментов и много чего еще.
Это и есть один из вариантов "Devops ближайшего будущего", о котором я говорю.
Команды разработки создают и поддерживают клиентские приложения.
SRE обеспечивают работу клиентских приложений (и как я уже сказал, это функция, а не роль).
Платформенные команды создают и поддерживают инфраструктурную платформу (которой пользуются другие команды в своей работе).
Интеграционные команды (хотя эта роль скорее индивидуальная, не командная) помогают командам разработки с быстрым стартом.
В качестве примера (на который я во многом ориентировался когда это писал) — Amazon Web Services.
Если вы намекаете на мифических "девопс-инженеров", про них здесь не было ни слова (и не будет с моей стороны), и мне непонятно какое они вообще отношение имеют к статье. Рекомендую еще раз внимательно ее прочитать.
Также обращаю внимание, что без целеполагания ни одна роль не решает ни одну проблему. Статья описывает именно особенности такого целеполагания и его составляющие.
Цель - ускорение выпуска ПО, все аспекты этого (кроме, пожалуй, собственно разработки).
Подробнее обсуждать это здесь не будем. Лучше про это почитать в других местах, про это написано очень много. Даже Википедия и гугл будут достаточно подходящими источниками для общего знакомства с вопросом.
Это всё говорит о том, что применялся не тот подход, который я описываю, а devops "второго поколения" (я привел три условных "поколения devops" в статье).
Перечитайте блок, который начинается "По сути современный DevOps (и DevOps ближайшего будущего) и заключается в" -- судя по ответам у вас кажется ничего озвученного не было представлено.
Т.е. у тех, кто строил пользовательские сценарии для команд разработки не было квалификации строить такие сценарии? Кажется вы сами только что назвали причину неудачи в вашем случае.
Как вообще обеспечивались модифицируемость этих сценариев со стороны команд разработки? Почему при всех названных недостатках команды разработки все равно выбирали то неудобное, что им предоставляли, а не делали вместо этого свои неэффективные, но зато понятные и удобные велосипеды? Как оценивали удобство и простоту использования этих сценариев? Кто двигал всю эту деятельность и отвечал за нее?
Не столько противоречие, сколько то, что ITIL не поднимается выше уровня сервиса/услуги (если я правильно понимаю), а в данном случае построение адаптивных самостоятельно модифицируемых сценариев - одна из ключевых активностей. Примерно по такой же причине продуктовая разработка и UX-дизайн ортогональны ITIL.
На уровне сервисов же, которые используются в этих сценариях скорее всего никакого противоречия нет.
До определенного возраста дети учатся поведению у окружающего.
Не «учатся взаимодействовать», а именно учатся поведению — примеряют на себя ролевые модели с окружающего. Поэтому социализация в том смысле, который в это слово вкладываете вы, лет до 10-12 лучше происходит со взрослыми.
Это естественно не значит, что нужно ограждать от детей — напротив, общение со сверстниками тоже очень важно и нужно — ролевые модели, полученные от взрослых тоже где-то нужно проверять. Я хочу сказать, что это общение переоценено. Несколько друзей, дети родственников или дети друзей семьи, детский коллектив на кружках — этого вполне достаточно. Годам к 10-12 дети уже начинают активно интересоваться и незнакомым окружением — тогда уже нужно давать возможность им этот интерес реализовать (и это тоже не значит «бросить в толпу, а дальше пусть попытается выплыть сам»).
В защиту «школьной социализации» возможно скажу лишь, что это пожалуй единственное место кроме семьи, в котором у детей есть возможность как-то строить отношения со сверстниками на всю жизнь (несколько лет для них это воспринимается как вся жизнь).
Я здесь не знаю насколько это важно, и у всех ли это получается, я здесь указываю на момент, который я упускаю, но который может оказаться важен (а может и не оказаться).
Если перевести на язык программистов, к примеру: у тебя в форме входа нет валидации на поле е-мейл, нет защиты от SQL-инъекций, пароли хранятся в базе в открытом тексте, при проверке логина вычитывается из базы запись о пользователе целиком несмотря на то, что нам нужен только логин, плюс наверняка есть еще несколько багов про которые мы не знаем.
У тебя угнали пароли пользователей через форму входа, в чем корневая и единственная причина этого инцидента?
Чаще всего у инцидента не одна «корневая» причина, а целая серия обстоятельств, которые произошли одновременно.
Если бы какой-то части обстоятельств не было (даже одного) — инцидента могло бы вообще не быть.
Похожая тема — в разборах причин автокатастроф, см википедию, там тоже так же, например: не сделали что-то здесь во время обслуживания, сломалось что-то там, совпали погодные условия, ошибка в документации на самолет (и как следствие конкретная ошибка пилота) — в результате авария. Не было бы хотя бы чего-то одного из этого — самолет нормально долетел бы резервных мощностях.
PureData это не модульный синт, а скорее язык программирования.
Суть похожа, конечно, но сравнивать модуляры и пюредату это как сравнивать scratch и python.
Почему это может быть полезно? Потому что, наблюдая за пассажирами, можно придумать киллер-фичу. Ну или просто понять, как сделать людям удобнее, и сказать продуктологу. А дальше поменять мир. Немного. И не сразу
Рассказ очень интересный, но конкретно здесь — почему бы сразу продуктолога не отправить на электричках? :-)
В Амазоне есть команды, которые разрабатывают и поддерживают отдельные сервисы (команды разработки), они же как понимаю занимаются SRE.
Эти команды разрабатывают свои сервисы поверх других сервисов, предоставляемых Амазоном как платформой (эти сервисы разрабатываются в точно такой же модели).
Для быстрого старта новых команд (внутренних и клиентских) у них есть роль Cloud Solution Architect, и высокоуровневые сервисы типа Amplify, как и большое количество всегда актуальной документации, референсных архитектур, типовых решений для старта, опенсорс инструментов и много чего еще.
Это и есть один из вариантов "Devops ближайшего будущего", о котором я говорю.
Про роли я ответил чуть выше: https://habr.com/ru/post/657593/#comment_24208167
Какие "эти люди"?
Команды разработки создают и поддерживают клиентские приложения.
SRE обеспечивают работу клиентских приложений (и как я уже сказал, это функция, а не роль).
Платформенные команды создают и поддерживают инфраструктурную платформу (которой пользуются другие команды в своей работе).
Интеграционные команды (хотя эта роль скорее индивидуальная, не командная) помогают командам разработки с быстрым стартом.
В качестве примера (на который я во многом ориентировался когда это писал) — Amazon Web Services.
Если вы намекаете на мифических "девопс-инженеров", про них здесь не было ни слова (и не будет с моей стороны), и мне непонятно какое они вообще отношение имеют к статье. Рекомендую еще раз внимательно ее прочитать.
Также обращаю внимание, что без целеполагания ни одна роль не решает ни одну проблему. Статья описывает именно особенности такого целеполагания и его составляющие.
Извините, я на эту реплику отвечать не буду, как и на возможный тред, с обсуждением одной и той же темы по кругу в сотый раз.
По теме статьи по прежнему готов пообщаться.
Цель - ускорение выпуска ПО, все аспекты этого (кроме, пожалуй, собственно разработки).
Подробнее обсуждать это здесь не будем. Лучше про это почитать в других местах, про это написано очень много. Даже Википедия и гугл будут достаточно подходящими источниками для общего знакомства с вопросом.
Это всё говорит о том, что применялся не тот подход, который я описываю, а devops "второго поколения" (я привел три условных "поколения devops" в статье).
Перечитайте блок, который начинается "По сути современный DevOps (и DevOps ближайшего будущего) и заключается в" -- судя по ответам у вас кажется ничего озвученного не было представлено.
Т.е. у тех, кто строил пользовательские сценарии для команд разработки не было квалификации строить такие сценарии? Кажется вы сами только что назвали причину неудачи в вашем случае.
Как вообще обеспечивались модифицируемость этих сценариев со стороны команд разработки? Почему при всех названных недостатках команды разработки все равно выбирали то неудобное, что им предоставляли, а не делали вместо этого свои неэффективные, но зато понятные и удобные велосипеды? Как оценивали удобство и простоту использования этих сценариев? Кто двигал всю эту деятельность и отвечал за нее?
Не столько противоречие, сколько то, что ITIL не поднимается выше уровня сервиса/услуги (если я правильно понимаю), а в данном случае построение адаптивных самостоятельно модифицируемых сценариев - одна из ключевых активностей. Примерно по такой же причине продуктовая разработка и UX-дизайн ортогональны ITIL.
На уровне сервисов же, которые используются в этих сценариях скорее всего никакого противоречия нет.
За счёт чего интеграция этих сценариев в рабочий процесс команд разработки был простым и быстрым в вашем случае?
За счёт чего интеграция этих сценариев в рабочий процесс команд разработки был простым и быстрым в вашем случае?
Пара комментариев:
модели в формате
*.archimateкажется сейчас не поддерживаются — можно для себя чуть переписатьentrypoint.shи тогда все заработаетимена файлов на русском не поддерживаются
В остальном все супер, спасибо!
Небольшая поправка: "Snapshot" — это не скриншоты, это HTML со всеми включенными в него картинками, этакий "снимок" страницы.
Спасибо за статью, очень полезно!
Польза от участия в конфликтах есть только если ты научился выходить из них без проигрыша, разве нет?
Не «учатся взаимодействовать», а именно учатся поведению — примеряют на себя ролевые модели с окружающего. Поэтому социализация в том смысле, который в это слово вкладываете вы, лет до 10-12 лучше происходит со взрослыми.
Это естественно не значит, что нужно ограждать от детей — напротив, общение со сверстниками тоже очень важно и нужно — ролевые модели, полученные от взрослых тоже где-то нужно проверять. Я хочу сказать, что это общение переоценено. Несколько друзей, дети родственников или дети друзей семьи, детский коллектив на кружках — этого вполне достаточно. Годам к 10-12 дети уже начинают активно интересоваться и незнакомым окружением — тогда уже нужно давать возможность им этот интерес реализовать (и это тоже не значит «бросить в толпу, а дальше пусть попытается выплыть сам»).
В защиту «школьной социализации» возможно скажу лишь, что это пожалуй единственное место кроме семьи, в котором у детей есть возможность как-то строить отношения со сверстниками на всю жизнь (несколько лет для них это воспринимается как вся жизнь).
Я здесь не знаю насколько это важно, и у всех ли это получается, я здесь указываю на момент, который я упускаю, но который может оказаться важен (а может и не оказаться).
У тебя угнали пароли пользователей через форму входа, в чем корневая и единственная причина этого инцидента?
Если бы какой-то части обстоятельств не было (даже одного) — инцидента могло бы вообще не быть.
Похожая тема — в разборах причин автокатастроф, см википедию, там тоже так же, например: не сделали что-то здесь во время обслуживания, сломалось что-то там, совпали погодные условия, ошибка в документации на самолет (и как следствие конкретная ошибка пилота) — в результате авария. Не было бы хотя бы чего-то одного из этого — самолет нормально долетел бы резервных мощностях.
Суть похожа, конечно, но сравнивать модуляры и пюредату это как сравнивать scratch и python.
Рассказ очень интересный, но конкретно здесь — почему бы сразу продуктолога не отправить на электричках? :-)