Comments 23
И в чем противоречие с ITIL, по вашему мнению ?
Не столько противоречие, сколько то, что ITIL не поднимается выше уровня сервиса/услуги (если я правильно понимаю), а в данном случае построение адаптивных самостоятельно модифицируемых сценариев - одна из ключевых активностей. Примерно по такой же причине продуктовая разработка и UX-дизайн ортогональны ITIL.
На уровне сервисов же, которые используются в этих сценариях скорее всего никакого противоречия нет.
Написано лишь бы написать. Я видел такие "команды создания сценариев", они повторяют ровно то же от чего хотели уйти изобретением DevOps.
За счёт чего интеграция этих сценариев в рабочий процесс команд разработки был простым и быстрым в вашем случае?
За счёт чего интеграция этих сценариев в рабочий процесс команд разработки был простым и быстрым в вашем случае?
А кто сказал, что быстрым? Любая команда пытается в первую очередь оптимизировать и облегчить свою работу. Плюс у большей части инженеров там отсутствует понимание UX, без которого построить нормальную систему, которой реально будут пользоваться, можно только случайно. В итоге получается монстр, который загоняет команды разработки в жёсткие рамки, предоставляя им возможность работать не так, как удобно им, а так, как "удобно им" по мнению авторов монстра. То есть "легко и быстро и удобно", что было одной из основ практики, вырождается в "легко и быстро и удобно для авторов фреймворка".
Т.е. у тех, кто строил пользовательские сценарии для команд разработки не было квалификации строить такие сценарии? Кажется вы сами только что назвали причину неудачи в вашем случае.
Как вообще обеспечивались модифицируемость этих сценариев со стороны команд разработки? Почему при всех названных недостатках команды разработки все равно выбирали то неудобное, что им предоставляли, а не делали вместо этого свои неэффективные, но зато понятные и удобные велосипеды? Как оценивали удобство и простоту использования этих сценариев? Кто двигал всю эту деятельность и отвечал за нее?
не было квалификации строить такие сценарии
Ну она в принципе мало у кого есть. Я даже не могу сказать, что такой квалификацией в полной мере обладаю, например.
Как вообще обеспечивались модифицируемость этих сценариев со стороны команд разработки?
Задачами в бэклог команде разработки фреймворка
Почему при всех названных недостатках команды разработки все равно выбирали...
У них не было выбора, вариант деплоя был только один. Всё остальное было под запретом от команды фреймворка, которые, по какой-то причине, контролировали собственно весь процесс выкатки.
Как оценивали удобство и простоту использования этих сценариев?
По плотности "плача Ярославны" в чатах и FAQ-статьях в руку длинной
Кто двигал всю эту деятельность и отвечал за нее
А это имеет принципиальное значение?
Это всё говорит о том, что применялся не тот подход, который я описываю, а devops "второго поколения" (я привел три условных "поколения devops" в статье).
Перечитайте блок, который начинается "По сути современный DevOps (и DevOps ближайшего будущего) и заключается в" -- судя по ответам у вас кажется ничего озвученного не было представлено.
Здравствуйте. А может кто-то объяснит - а что делают devops?
12 лет занимался разработкой проектов в том числе в acronis, Яндексе, nvidia, huawei под разные платформы под разное кол-во кастомеров в проектах от 3000 строк под 5 млн строк кода. Где используется 0 научных статей до 20 на проекте.
Но я никогда не слышал про devops. По крайней мере за 2006 до 2020 я никогда не сталкивался с такими людьми вовсе. Не в старапах, не в больших компаниях, не в средних компаниях. Не в рф культуре не в культуре сша, не в культуре Китая.
Если цель девопсов получить связь с пользователями то вот такие инструменты используются повсеместно на практике
Трекеры багов (если проект открытый)
Форумы
Прямая связь с кастомерами с помощью почты (но для этого сбора используются менеджеры проектов - они должны бегать по клиентам и как-то систематизировать требования)
Внутренние тестеры проверяющиеся софт на баги
Снятие метрик или логов с пользователей если установлена обратная связь с пользователями с помощью автоматической обратной связи (если не нарушается приватность и как это организовать зависит от проекта)
Если же цель обновление версий программного обеспечения
Это делается для стендэлоун приложений схемами принятыми в конкретной операционной системе.
Если речь идет про большую распределённую систему с кучей веб-сервисов — то это решают программисты внутри компании как обновлять веб-сервисы или скрипты или программы. Но это договоренность по сути + скрипты которое это делают. Это важно - но это решается как обновлять (при понимании как работает компьютер и вычислительные сети) за неделю вроде как самими программистами по крайней мере на моей практике все заканчивалось скриптов до 2000 строк которое все раскладывает и проверяет. Это важно сделать один раз - но в моей практике это делают сами программисты.
если цель наладить сборки и проведение анализа кода
То это делают вроде как программисты сами опять таки. Владеющие или изучившие или создавшие инструменты для сборки или анализа кода.
может девонской - это администраторы развёрнутых систем которые следят что все веб-сервисы работают правильно в распределенной системе? Или настраивающие инструменты сборки программного обеспечения?
Буду благодарен если тот кто сталкивался с людьми девопс - расскажут про их роли.
Наверное просто в моей жизни - эти люди назывались по другому
Спасибо.
Цель - ускорение выпуска ПО, все аспекты этого (кроме, пожалуй, собственно разработки).
Подробнее обсуждать это здесь не будем. Лучше про это почитать в других местах, про это написано очень много. Даже Википедия и гугл будут достаточно подходящими источниками для общего знакомства с вопросом.
Назовите хоть один проект который этим пользуется? все сервисы Яндекса этим не пользуются, все известные мне проекты компании nvidia (штук 30) этим не пользуются, опенсорс проекты гугла этим не пользуются… что делают эти люди? Как я пока понял они собирают билды - но это в 2022 году автоматизировано.
В гугле я сам не работал - но у меня много друзей кто туда пошёл и у меня были совместные проекты с ними. Там часто программисты и site reliability engineers работают которые бдят что система работает.
Какие "эти люди"?
Команды разработки создают и поддерживают клиентские приложения.
SRE обеспечивают работу клиентских приложений (и как я уже сказал, это функция, а не роль).
Платформенные команды создают и поддерживают инфраструктурную платформу (которой пользуются другие команды в своей работе).
Интеграционные команды (хотя эта роль скорее индивидуальная, не командная) помогают командам разработки с быстрым стартом.
В качестве примера (на который я во многом ориентировался когда это писал) — Amazon Web Services.
Если вы намекаете на мифических "девопс-инженеров", про них здесь не было ни слова (и не будет с моей стороны), и мне непонятно какое они вообще отношение имеют к статье. Рекомендую еще раз внимательно ее прочитать.
Также обращаю внимание, что без целеполагания ни одна роль не решает ни одну проблему. Статья описывает именно особенности такого целеполагания и его составляющие.
Спасибо. Не на что я не намекаю - мне нужен был пример хоть одного реального проекта где используются такие люди. У меня есть знакомые кто делает Amazon Web Services в Амазоне - я у него спрошу что делают девопс в Амазоне с этой системой
(В Яндексе много распределённых систем - но там все делают программисты и системные администраторы)
В Амазоне есть команды, которые разрабатывают и поддерживают отдельные сервисы (команды разработки), они же как понимаю занимаются SRE.
Эти команды разрабатывают свои сервисы поверх других сервисов, предоставляемых Амазоном как платформой (эти сервисы разрабатываются в точно такой же модели).
Для быстрого старта новых команд (внутренних и клиентских) у них есть роль Cloud Solution Architect, и высокоуровневые сервисы типа Amplify, как и большое количество всегда актуальной документации, референсных архитектур, типовых решений для старта, опенсорс инструментов и много чего еще.
Это и есть один из вариантов "Devops ближайшего будущего", о котором я говорю.
Яндекс до "института" Cloud Solution Architect аля Амазон кажется еще не дошел — скорее всего придет к нему когда количество запросов от пользователей станет значительно выше чем "мощность" внутренней разработки.
Очередной вид "волшебников", обещающих решить все проблемы разработки разом. По факту-опыту взаимодействия с "девопсами" заказчиков - в лучшем случае бесполезный элемент.
Извините, я на эту реплику отвечать не буду, как и на возможный тред, с обсуждением одной и той же темы по кругу в сотый раз.
По теме статьи по прежнему готов пообщаться.
Мне тоже не понятно кто это такие хотя я вроде как опытный человек с образованием из Стенфорда https://burlachenkok.github.io/cv_kburlachenko_feb_2022.pdf
В своей практике я общался напрямую отвечая за маленькие и гигантские компоненты - но это было общение с заказчиками напрямую или иногда менеджеры проекта выполняют такую роль посредника - если роль девопс общение с заказчиком - то они дублируют прожект менеджера
Иногда под девопсами понимают наверное людей кто занимается конфигурацией билд системы. Но это тоже во всех проектах с 1 или 3 миллионами клиентов - автоматизировано.
Это термины - если откроется вам больше кто это - пожалуйста делитесь.
Возможно это системный администратор поддержки развёрнутой системы…
Я пока понять не могу
Про роли я ответил чуть выше: https://habr.com/ru/post/657593/#comment_24208167
Как-то я пропустил момент когда подобный кич стал приемлемым среди выпускников Стенфорда.
Спасибо большое за комментарий. Стенфорд про науку и инженерию. И в этих вещах немного другие классификационные коды для людей кто занимается информатикой https://dl.acm.org/ccs - здесь среди академической классификации нету DevOps.
Что входит в роль девопсов или проджект менеджера или вообще какие-то социальные роли на проекте - на курсах в Стенфорде не учат в явном виде.
Учат в том числе как делать системы типа Apache Spark (так как автор этой система является проф. там - Matei Zaharia). Учат создавать механические, электрические или информационные системы и зачастую это и является целью - создание устройства или системы некоторой которая делает полезное людям с гарантиями желательно.
Как-то так :)
Эволюция DevOps