15 лет назад DevOps начинался в попытке “подружить” разработку и эксплутацию — через культуру, обмен знаниями и совместную работу. Затем быстро развернулся в сторону ускорения поставки изменений из разработки в продакшн (активность Lean Value Stream Mapping), продолжился в понимание того, что программисты создают не просто код в репозитории (и даже не протестированный код в репозитории), а работающее приложение в продакшне (практики Observability и SRE). И последние несколько лет DevOps перешел к рассмотрению взаимодействия команд на масштабе (фреймворк Team Topologies).
Что при этом менее заметно, так это происходящая одновременно с этим эволюция корпоративной архитектуры:
Сперва одно подразделение (Ops) предоставляло сервис пользователям при помощи инструментов, которые разрабатывает другое подразделение (Dev)
Затем взгляд сместился на построение цепочки добавленной стоимости (Value Stream), которое включает как оба этих подразделения, так и новые роли (например Product)
Сегодня же говорят о построении инфраструктурных платформ и выделение особых интеграционных команд (enabling teams) для создания гибкости на продуктовом ландшафте
По сути современный DevOps (и DevOps ближайшего будущего) и заключается в:
предоставлении сервисов при помощи которых команды разработки сами могут строить свой рабочий процесс, при этом сами эти сервисы должны соответствовать стандартам качества заданным в организации (по ИБ, SLA и т.д.)
создании на базе этих сервисов типовых решений для быстрого старта, которые каждая команда разработки может адаптировать под себя
активностях по интеграции, обучению и передаче экспертизы для еще более быстрого старта команд разработки
практиках SRE, которые по факту уходят от инфраструктурных команд в команды разработки
Важный вопрос, который встает в такой картине если хотя бы чуть-чуть отойти в сторону от разработки: зачем командам строить свои уникальные рабочие процессы? Зачем делать свои велосипеды? Почему не взять один стандартный процесс разработки, сделать его частично кастомизируемым и работать по нему?
Ответ на это достаточно простой: у разных продуктов и компонентов разная частота внесения изменений, разные “нефункциональные” требования (например, критичность для бизнеса, требования к доступности и нагрузке, или требования compliance), а часто и разный технологический стек (бэк, фронт, два вида мобилки). Один универсальный набор инструментов и процессов не подойдет для этих таких разных компонентов — для каких-то продуктов он может начать тормозить разработку, а для каких-то не будет обеспечивать необходимый уровень качества. С другой стороны слишком широкие возможности кастомизации затрудняют использование инструментов, и польза от точечной кастомизации “стандартного пайплайна” для маленьких низкокритичных компонентов с быстрым циклом разработки будет невелика.
Выход здесь лежит в построении типовых сценариев работы команд, и их самостоятельной адаптации под конкретные потребности команд по месту. Фокус при этом должен быть на простоту и скорость интеграции такого сценария (и его обновлений!) в повседневную жизнь команды. Другой важный момент для команд должны быть видны явные преимущества использования этого сценария и предоставляемых сервисов по сравнению с созданием собственных велосипедов. Это осуществимо при помощи списка составляющих перечисленных в середине статьи.
В случае старой парадигмы (ITIL/ITSM подход) это сделать невозможно, т.к. реинжиниринг процессов дорог и ограничивает скорость изменений самих рабочих процессов.
Комментарии (23)
Cib0rg
27.03.2022 11:18Написано лишь бы написать. Я видел такие "команды создания сценариев", они повторяют ровно то же от чего хотели уйти изобретением DevOps.
erthad Автор
27.03.2022 11:26За счёт чего интеграция этих сценариев в рабочий процесс команд разработки был простым и быстрым в вашем случае?
erthad Автор
27.03.2022 11:27За счёт чего интеграция этих сценариев в рабочий процесс команд разработки был простым и быстрым в вашем случае?
Cib0rg
27.03.2022 12:18+1А кто сказал, что быстрым? Любая команда пытается в первую очередь оптимизировать и облегчить свою работу. Плюс у большей части инженеров там отсутствует понимание UX, без которого построить нормальную систему, которой реально будут пользоваться, можно только случайно. В итоге получается монстр, который загоняет команды разработки в жёсткие рамки, предоставляя им возможность работать не так, как удобно им, а так, как "удобно им" по мнению авторов монстра. То есть "легко и быстро и удобно", что было одной из основ практики, вырождается в "легко и быстро и удобно для авторов фреймворка".
erthad Автор
27.03.2022 14:33Т.е. у тех, кто строил пользовательские сценарии для команд разработки не было квалификации строить такие сценарии? Кажется вы сами только что назвали причину неудачи в вашем случае.
Как вообще обеспечивались модифицируемость этих сценариев со стороны команд разработки? Почему при всех названных недостатках команды разработки все равно выбирали то неудобное, что им предоставляли, а не делали вместо этого свои неэффективные, но зато понятные и удобные велосипеды? Как оценивали удобство и простоту использования этих сценариев? Кто двигал всю эту деятельность и отвечал за нее?
Cib0rg
27.03.2022 15:15не было квалификации строить такие сценарии
Ну она в принципе мало у кого есть. Я даже не могу сказать, что такой квалификацией в полной мере обладаю, например.
Как вообще обеспечивались модифицируемость этих сценариев со стороны команд разработки?
Задачами в бэклог команде разработки фреймворка
Почему при всех названных недостатках команды разработки все равно выбирали...
У них не было выбора, вариант деплоя был только один. Всё остальное было под запретом от команды фреймворка, которые, по какой-то причине, контролировали собственно весь процесс выкатки.
Как оценивали удобство и простоту использования этих сценариев?
По плотности "плача Ярославны" в чатах и FAQ-статьях в руку длинной
Кто двигал всю эту деятельность и отвечал за нее
А это имеет принципиальное значение?
erthad Автор
27.03.2022 17:03Это всё говорит о том, что применялся не тот подход, который я описываю, а devops "второго поколения" (я привел три условных "поколения devops" в статье).
Перечитайте блок, который начинается "По сути современный DevOps (и DevOps ближайшего будущего) и заключается в" -- судя по ответам у вас кажется ничего озвученного не было представлено.
burzzo
28.03.2022 02:56-2Здравствуйте. А может кто-то объяснит - а что делают devops?
12 лет занимался разработкой проектов в том числе в acronis, Яндексе, nvidia, huawei под разные платформы под разное кол-во кастомеров в проектах от 3000 строк под 5 млн строк кода. Где используется 0 научных статей до 20 на проекте.
Но я никогда не слышал про devops. По крайней мере за 2006 до 2020 я никогда не сталкивался с такими людьми вовсе. Не в старапах, не в больших компаниях, не в средних компаниях. Не в рф культуре не в культуре сша, не в культуре Китая.
Если цель девопсов получить связь с пользователями то вот такие инструменты используются повсеместно на практике
Трекеры багов (если проект открытый)
Форумы
Прямая связь с кастомерами с помощью почты (но для этого сбора используются менеджеры проектов - они должны бегать по клиентам и как-то систематизировать требования)
Внутренние тестеры проверяющиеся софт на баги
-
Снятие метрик или логов с пользователей если установлена обратная связь с пользователями с помощью автоматической обратной связи (если не нарушается приватность и как это организовать зависит от проекта)
Если же цель обновление версий программного обеспечения
Это делается для стендэлоун приложений схемами принятыми в конкретной операционной системе.
-
Если речь идет про большую распределённую систему с кучей веб-сервисов — то это решают программисты внутри компании как обновлять веб-сервисы или скрипты или программы. Но это договоренность по сути + скрипты которое это делают. Это важно - но это решается как обновлять (при понимании как работает компьютер и вычислительные сети) за неделю вроде как самими программистами по крайней мере на моей практике все заканчивалось скриптов до 2000 строк которое все раскладывает и проверяет. Это важно сделать один раз - но в моей практике это делают сами программисты.
если цель наладить сборки и проведение анализа кода
То это делают вроде как программисты сами опять таки. Владеющие или изучившие или создавшие инструменты для сборки или анализа кода.
может девонской - это администраторы развёрнутых систем которые следят что все веб-сервисы работают правильно в распределенной системе? Или настраивающие инструменты сборки программного обеспечения?
Буду благодарен если тот кто сталкивался с людьми девопс - расскажут про их роли.
Наверное просто в моей жизни - эти люди назывались по другому
Спасибо.
erthad Автор
28.03.2022 08:09Цель - ускорение выпуска ПО, все аспекты этого (кроме, пожалуй, собственно разработки).
Подробнее обсуждать это здесь не будем. Лучше про это почитать в других местах, про это написано очень много. Даже Википедия и гугл будут достаточно подходящими источниками для общего знакомства с вопросом.
burzzo
28.03.2022 10:08Назовите хоть один проект который этим пользуется? все сервисы Яндекса этим не пользуются, все известные мне проекты компании nvidia (штук 30) этим не пользуются, опенсорс проекты гугла этим не пользуются… что делают эти люди? Как я пока понял они собирают билды - но это в 2022 году автоматизировано.
В гугле я сам не работал - но у меня много друзей кто туда пошёл и у меня были совместные проекты с ними. Там часто программисты и site reliability engineers работают которые бдят что система работает.
erthad Автор
28.03.2022 10:54Какие "эти люди"?
Команды разработки создают и поддерживают клиентские приложения.
SRE обеспечивают работу клиентских приложений (и как я уже сказал, это функция, а не роль).
Платформенные команды создают и поддерживают инфраструктурную платформу (которой пользуются другие команды в своей работе).
Интеграционные команды (хотя эта роль скорее индивидуальная, не командная) помогают командам разработки с быстрым стартом.
В качестве примера (на который я во многом ориентировался когда это писал) — Amazon Web Services.
Если вы намекаете на мифических "девопс-инженеров", про них здесь не было ни слова (и не будет с моей стороны), и мне непонятно какое они вообще отношение имеют к статье. Рекомендую еще раз внимательно ее прочитать.
Также обращаю внимание, что без целеполагания ни одна роль не решает ни одну проблему. Статья описывает именно особенности такого целеполагания и его составляющие.
burzzo
28.03.2022 10:57Спасибо. Не на что я не намекаю - мне нужен был пример хоть одного реального проекта где используются такие люди. У меня есть знакомые кто делает Amazon Web Services в Амазоне - я у него спрошу что делают девопс в Амазоне с этой системой
(В Яндексе много распределённых систем - но там все делают программисты и системные администраторы)
erthad Автор
28.03.2022 12:23В Амазоне есть команды, которые разрабатывают и поддерживают отдельные сервисы (команды разработки), они же как понимаю занимаются SRE.
Эти команды разрабатывают свои сервисы поверх других сервисов, предоставляемых Амазоном как платформой (эти сервисы разрабатываются в точно такой же модели).
Для быстрого старта новых команд (внутренних и клиентских) у них есть роль Cloud Solution Architect, и высокоуровневые сервисы типа Amplify, как и большое количество всегда актуальной документации, референсных архитектур, типовых решений для старта, опенсорс инструментов и много чего еще.
Это и есть один из вариантов "Devops ближайшего будущего", о котором я говорю.
dimas062
28.03.2022 09:38Очередной вид "волшебников", обещающих решить все проблемы разработки разом. По факту-опыту взаимодействия с "девопсами" заказчиков - в лучшем случае бесполезный элемент.
erthad Автор
28.03.2022 09:52Извините, я на эту реплику отвечать не буду, как и на возможный тред, с обсуждением одной и той же темы по кругу в сотый раз.
По теме статьи по прежнему готов пообщаться.
burzzo
28.03.2022 10:26Мне тоже не понятно кто это такие хотя я вроде как опытный человек с образованием из Стенфорда https://burlachenkok.github.io/cv_kburlachenko_feb_2022.pdf
В своей практике я общался напрямую отвечая за маленькие и гигантские компоненты - но это было общение с заказчиками напрямую или иногда менеджеры проекта выполняют такую роль посредника - если роль девопс общение с заказчиком - то они дублируют прожект менеджера
Иногда под девопсами понимают наверное людей кто занимается конфигурацией билд системы. Но это тоже во всех проектах с 1 или 3 миллионами клиентов - автоматизировано.
Это термины - если откроется вам больше кто это - пожалуйста делитесь.
Возможно это системный администратор поддержки развёрнутой системы…
Я пока понять не могу
erthad Автор
28.03.2022 10:55Про роли я ответил чуть выше: https://habr.com/ru/post/657593/#comment_24208167
Akiyamka
28.03.2022 15:53-1Как-то я пропустил момент когда подобный кич стал приемлемым среди выпускников Стенфорда.
burzzo
28.03.2022 16:27Спасибо большое за комментарий. Стенфорд про науку и инженерию. И в этих вещах немного другие классификационные коды для людей кто занимается информатикой https://dl.acm.org/ccs - здесь среди академической классификации нету DevOps.
Что входит в роль девопсов или проджект менеджера или вообще какие-то социальные роли на проекте - на курсах в Стенфорде не учат в явном виде.
Учат в том числе как делать системы типа Apache Spark (так как автор этой система является проф. там - Matei Zaharia). Учат создавать механические, электрические или информационные системы и зачастую это и является целью - создание устройства или системы некоторой которая делает полезное людям с гарантиями желательно.
Как-то так :)
it2manager
И в чем противоречие с ITIL, по вашему мнению ?
erthad Автор
Не столько противоречие, сколько то, что ITIL не поднимается выше уровня сервиса/услуги (если я правильно понимаю), а в данном случае построение адаптивных самостоятельно модифицируемых сценариев - одна из ключевых активностей. Примерно по такой же причине продуктовая разработка и UX-дизайн ортогональны ITIL.
На уровне сервисов же, которые используются в этих сценариях скорее всего никакого противоречия нет.