Если бы нам довелось прочитать разговор в Slack между разработчиком ПО и инженерами DevOps, то он мог бы выглядеть примерно так:
Разработчик ПО: Это займёт кучу времени. «Мне нужно новое окружение для моего приложения».
Два часа спустя…
DevOps: Почему разработчики ПО думают, что я умею читать мысли!? «Ладно, а какие типы инстансов вам нужны?»
Час спустя (после обсуждения с командой…)
Разработчик ПО: «Мне нужен g3.8xlarge для тестирования новой функции визуализации».
На следующий день…
DevOps: «Хорошо, а в какой AZ он должен находиться? И ещё с какой группой безопасности он должен быть связан?»
Разработчик ПО: Они что, не знают всего этого сразу? «Любая AZ в us-west-1, группа sg-3164z279».
48 часов спустя, после нескольких серий обсуждений дополнительных параметров, разрешений и прочих милых подробностей, DevOps получает одобрение на создание окружения, выходит на улицу, чтобы купить себе шоколадку в качестве награды за все эти мучения, и забывает сообщить разработчику ПО, что запрос был одобрен, пока до конца рабочего дня не остаётся пять минут.
Звучит знакомо? Если да, то глубоко в отделах разработки ПО и DevOps вашей компании, возможно идёт крайне непродуктивная холодная война.
Причина войны
Что стало причиной этой войны? Чтобы понять это, нам нужно проанализировать две основные проблемы, возникающие из-за описанного выше сценария. Во-первых, не имея общего языка и чётких каналов коммуникации, никакие две стороны не смогут совместно работать даже над простыми задачами, не говоря уже о сложных. Во-вторых, даже при наличии общего языка вся излишняя работа, переключение между контекстами, задержки и неизбежные разногласия приводят к накоплению в организации напряжённости уровня холодной войны.
Усугубляет эти проблемы размытие границ ответственности, возникшее из-за модели DevOps и у команд разработчиков ПО и у DevOps. Однако реальность такова:
- Разработчики ПО хотят писать код, реализовывать фичи и запускать их в инфраструктуре (чтобы с ними могли работать пользователи) без проблем и не закапываясь в подробности эксплуатации.
- DevOps хотят заниматься упрощением и поддержанием стабильности продакшена, оптимизацией инфраструктуры, улучшением мониторинга и внедрением инноваций, не касаясь сервисов конечного пользователя (например, разработчиков ПО) и запросов доступа.
Когда обе стороны тратят множество циклов на узкие места эксплуатации (в промежутках между бросанием невидимых ножей ненависти друг в друга), организация теряет продуктивность разработки ПО, а также потенциальные инновации со стороны DevOps, потому что никто не получает того, что им нужно.
Эту огромную утерю продуктивности невозможно измерить одними только метриками DORA. Она уходит глубоко, в самое сердце культуры организации. Но теперь, наконец, видна возможность завершения десятилетиями длившейся холодной войны между разработчиками ПО и DevOps.
Эволюция обладателя премии мира с DevOps
Никто не думает, что ситуация, в которую мы попали — радикальный конфликт между разработчиками ПО и DevOps — это что-то хорошее. Ни один бизнес не может работать эффективно при таком уровне впустую растрачиваемых времени и усилий. Именно поэтому несколько лет назад инсайдеры начали сообщать о зарождении самообслуживающихся (self-service) DevOps.
Когда слышишь о self-service DevOps, то в голову приходят маленькие роботы, предоставляющие всю инфраструктуру, которая может понадобиться разработчикам. К сожалению, это не так.
Сегодня self-service DevOps всё ещё находятся на стадии юности: неудобные внутренние порталы разработчиков, каталоги сервисов, инструменты автоматизации рабочих процессов и другие новые игрушки.
Однако эта сфера быстро взрослеет благодаря уже происходящему эволюционному процессу.
▍ Вчера: всё началось с чат-ботов
Попытки создания симуляции разговоров начались практически после изобретения компьютеров. Современные чат-боты определённо умнее, однако им не удалось выполнить свою исходную цель: они не могут понять любой запрос, легко интегрироваться с инструментами DevOps и автоматизировать рабочие процессы.
В реальности чат-боты в чём-то полезны, однако сталкиваются со множеством фундаментальных проблем. По сути, они полагаются на простые, заранее созданные потоки и стандартные линейные взаимодействия на основе правил. Однако все мы знаем, что в реальном мире вопросы и запросы могут быть разнообразными и уникальными… а с подобным чат-боты справляться не обучены.
Кроме того, стоит признать, что чат-бот, не выполняющий свою задачу, хуже, чем ничего: разработчики ПО пытаются угадать волшебные команды, которые заставят чат-бот выполнить свою задачу, и если им не удаётся найти такие команды, то всё равно приходится обращаться к команде DevOps, однако теперь на 24, 48 или 72 часа позже, когда уже накопилось сильное раздражение.
Чтобы создать интерфейс, который бы действительно экономил время разработчиков и эксплуатационщиков, нужно больше интеллекта, чем имеющийся у простого чат-бота.
▍ Сегодня и завтра: всё продолжается с разговорным AI
Чат-боты ограничены, поскольку они не понимают языков, используемых разработчиками. Но что, если мы сможем использовать AI для обеспечения более тонкого понимания? Чтобы достигнуть этого уровня понимания, нужно реализовать две стратегии:
- Обработка естественного языка (Natural language processing, NLP) использует AI для систематического парсинга слов и благодаря тщательно обученным AI-решений пытается определить значение.
- Ещё одним уровнем выше идёт понимание естественного языка (natural language understanding, NLU), обучающееся распознавать вариации в языке, отражающие неточность, с которой люди общаются в реальном мире. NLU учитывает такие факторы, как эмоциональный настрой, семантику, контекст и намерения.
По сути, NLP нацелена на создание алгоритмов для распознавания и понимания естественного языка, а NLU — на значение предложения. Соединив их вместе, мы получим истинный разговорный AI.
NLP и NLU — лишь один из множества необходимых строительных блоков, входящих в разговорный AI, чтобы он мог обеспечить истинное понимание и интеллект, которые в конечном итоге заменят чат-ботов. Давайте взглянем и на некоторые другие строительные блоки:
- Движок обработки естественного языка (с использованием NLP/NLU) для оценки пользовательского ввода и понимания запроса
- Интеграция с identity-провайдером (IDP) наподобие Okta, и с другими источниками, например, с базой знаний или с поставщиками облачных сервисов, для обеспечения тщательного контроля разрешений и безопасности
- Итеративное машинное обучение для выявления новых массивов данных и тестирования прогнозов пользовательского поведения с целью непрерывного совершенствования ответов
- Система управления диалогами для сохранения контекста разговора и обеспечения возможности соответствующих ответов разговорного AI
- Управление контекстом («хранение состояния») для отслеживания того, на чём завершился разговор и последнего достигнутого этапа
- Интерфейс для взаимодействия с пользователем, обычно текстом или голосом; в идеале — через его любимый инструмент рабочего процесса
В качестве примера управления контекстом в представленном выше разговоре разработчика и DevOps, можно сказать, что даже спустя 24 или больше часов AI должен помнить, какой этап был достигнут в разговоре, чтобы он мог продолжить его после получения авторизации.
Кроме того, критически важен последний пункт — пользовательский интерфейс. Чтобы достичь истинного разговорного интеллекта, действительно упрощающего DevOps, необходим интерфейс, объединяющий уже работающие команды. Благодаря этому, вы не добавите лишнего стресса, вызываемого переключением контекста, который сам по себе сильно снижает продуктивность и сосредоточенность.
И премию мира получает… виртуальный помощник DevOps
Помните, выше мы обсуждали непонимание между разработчиком и DevOps? Виртуальный помощник способен закрыть этот пробел, давая обеим сторонам именно того, чего они хотят. Разработчики хотят писать код и без проблем получать нужную им инфраструктуру. Инженерам DevOps нужна безопасность и эффективность, чтобы избежать излишних разрешений и затрат на облачные сервисы; кроме того, они не хотят тратить время на повторяющиеся, монотонные задачи с постоянным переключением контекста.
При наличии виртуального помощника взаимодействие может происходить следующим образом:
- Разработчик ПО использует удобную ему рабочую среду: Slack, Microsoft Teams и так далее.
- Он сообщает все подробности на разговорном языке.
- Виртуальный помощник выполняет его запрос. Например:
- Предоставляет новые облачные ресурсы
- Запускает сложный процесс
- Предоставляет данные, которые сложно найти
- В конце виртуальный помощник отправляет подтверждение в рабочую среду разработчика ПО, чтобы он сразу же мог приступать к работе.
Благодаря разговорному AI, обе стороны остаются продуктивными и сосредоточенными на работе. Разработчики ПО могут заниматься разработкой, а DevOps не придётся тратить время на переключение контекста или бесконечные повторяющиеся запросы.
Так что мы должны вручить Нобелевскую премию мира разговорному AI; спустя десятилетия конфликта наконец-то наступит мир. А кто выиграет от этого больше всего? Ваша организация, долго и счастливо живущая в гармонии с DevOps.
Telegram-канал с полезностями и уютный чат
Комментарии (23)
olku
30.11.2022 16:58+8Продвигаемый в статье подход больше похож на запоздалую маркетинговую чушь про AI. Индустрия идет в декларативный IaC, а не императив. О проблеме общего языка Дмитрий Столяров из Флант делал доклады еще года 4 назад, актуально до сих пор.
olku
30.11.2022 19:16Update: не удивлюсь, если kubiya.ai повторяет бизнес-модель engineer.ai/builder.ai - чат на аутсорсе.
aaabramenko
30.11.2022 17:04+2Не, не, не, какой AI. Надо уволить девопса и его обязанности переложить на разработчика.
//сарказм
LuggerFormas
30.11.2022 17:25+3а Вы точно ruvds, а не dzone.com? Не уверен, ссылок нашпиговано ой-ой. Может, при копировании их все же чистить?
SWATOPLUS
30.11.2022 19:31+1Как по мне война между разработчиками и девопсами возникает из-за низкой квалификации последних. Хорошие девопсы, это программисты, которые постигли SDLC, CI/CD, Cloud, IaaC практики. Плохие девопсы, это неучи после курсов, либо сисадмины не имеющие никакого представления о разработке ПО.
Виртуальные окружения, инфраструктура как код (императивный код высокого уровня, а не yml или скрипты на баше), удобные и стандартизированные на всю компанию инструменты для логгирования, конфигурирования и отладки -- вот секрет успеха и быстрой разработки.
А когда девопсы вставляют палки в колеса, мол это сложно задеплоить, пишите код криво, что бы легко деплоилось, да и еще забирают себе все права, что нужно на каждый чих им писать, тогда и начинается война.
О чем речь если никто не может сказать, что же входит в обязанности девопса? Зачастую, особенно на out-stuff проектах, наличие девопсов только создает проблемы, так как опытные разработчики сами могут все настроить, но у них нет доступов.
Для меня девопс, это эксперт не только по развертыванию ПО, но и по автоматизации развертывания. Это автоматизация должна быть гибкой и простой настолько, что любой разработчик в команде, будет способен легко из шаблонов создать новый микросервис и задеплоить его в дев-окружение. Но как показывает практика, хороших спецов можно встретить крайне редко.
PuerteMuerte
30.11.2022 22:55+2Как по мне война между разработчиками и девопсами возникает из-за низкой квалификации последних
или первых. Или упрямства последних, или упрямства первых, или лени последних, или лени первых, или излишней педантичности... в общем, стопицот их, причин.
myc
02.12.2022 02:24Как по мне война между разработчиками и девопсами возникает из-за того, что обе стороны мнят себя великими творцами-архитекторами. По факту первые беспробудно кодят в жестких рамках, придуманных другими, вторые вынуждены вечно что-то автоматизироват.
speshuric
30.11.2022 23:102013 год. Джин Ким, Джордж Спаффорд, Кевин Бер пишут книгу "Проект «Феникс». Роман о том, как DevOps меняет бизнес к лучшему". Книга о том, как новая парадигма DevOps рушит границы между разработкой, тестированием, сопровождением/эксплуатацией и все вместе делают бизнесу хорошо.
2022 год. @ru_vds пишут статью на Хабре "Пора закончить холодную войну между DevOps и разработчиками ПО"И - ирония.
PS: Отнеситесь к комментарию иронично. Да, я прекрасно понял, что написано в статье и нахожу её скорее полезной. Да, я понимаю, что под DevOps в статье подразумеваются администраторы, сопровождающие процесс разработки, а не полумифическая (но всё равно полезная) парадигма из книги. Просто обратил внимание на некоторую эволюцию терминов и понятий.
mvv-rus
01.12.2022 03:41+4Прочел статью, но не увидел в ней ответа на вопрос: зачем так сложно - чат-бот, NLP, NLU и прочие достижения AI? Почему нельзя использовать опубликованный на веб-сервере каталог услуг, а задачу формализации запросов возложить на самих разработчиков - наверняка ведь они это умеют?
Особенно непонятности добавдяет то, что эта статья размещена в блоге компании, которая сама предоставляет довольно широкий спектр услуг широкому кругу лиц и, наверняка, с каталогом услуг знакома не по наслышке.
Germanjon
01.12.2022 07:36+1Тоже подумалось об этом.
1. В идеале всё решается пивной посиделкой с участием девопсов и разработчиков, после чего в представителях другого отдела перестаёшь видеть гоблинов и лентяев и выстраивается вполне себе нормальный неофициальный канал связи.
2. Если первый пункт не получается или по каким-то пунктам неприемлем, формализуется процесс - разрабатывается форма заявки, в которой описываются все необходимые поля, а также время реакции DevOps-ов. Сформированная заявка отправляется любым каналом связи.
3. Если и это не решает проблем, ставится и настраивается обычная тикетная система.maledog
01.12.2022 12:51Может мне просто такие коллективы попадались, но среди программистов почти никто не пил. Особенно если было много молодых. Так что идея с "посиделками" так себе. А еще она может сработать с точностью до наоборот и алкоголь кому-то развяжет язык.
Всякие тимбилдинги, если они по указке сверху тоже не приветствую. Наверное единственный способ улучшить коммуникацию это посадить работать рядом, но это не всегда возможно. Как правило работники сбиваются в группки "по кабинетам" вне зависимости от размера кабинета и рода занятий. Ну и кроме конфликтов профессий еще конфликт возрастов существует.
А иногда менеджеры даже культивируют такого рода конфликты, так как тесная команда может начать диктовать свои условия и шантажировать уходом.Germanjon
01.12.2022 13:34В таком случае можно переходить к пункту 2: создавать форму и ставить нормативы, в течение какого времени DevOps должен вернуться с результатом: инстанс поднят, инстанс не поднят по такой-то причине и дальнейшие шаги..., в заявке не понятны пункты...
Лезть программистам "в кухню Devops-ов", не зная как там всё распланировано и настроено (читай отправлять конфиг через чат-бот) - верный способ поссориться с коллегами.
ggo
01.12.2022 10:27+5Devops - это не про ansible, gitlab, terraform, helm, etc. Технологии вообще не причем.
Devops - про взаимодействие условных девелоперов с условными админами для достижения общих целей. Если идет такой диалог, как в прологе статьи, это не devops. Это яркий пример той проблемы, которая присутствовала в прошлом, и присутствует в настоящем - отсутствие тесного взаимопонимания. И devops как раз вариант решения этой проблемы. Опять же решение не в технологиях, а в том, чтобы условный девелопер и условный админ стали одной командой с единой целью и начали друг с другом конструктивно обсуждать имеющиеся проблемы и возможные решения. И после принятия решения - имплементация может быть в использовании конкретной технологии.
Аналогичная история с Agile. Agile не про спринты, дейлики, ретро и прочее. Agile про тесное взаимопонимание бизнеса и технарей.
elve
01.12.2022 11:44Автоматизированный бардак останется бардаком. А бот вносит в бардак дополнительную боль. Жать кнопки и заполнять формы проще и понятнее, чем объяснять боту что ж ты хотел-то.
Если у вас войны между разработчиками и админам (ну ладно-ладно DevOps-ами), то это может говорить о недостаточной квалификации как минимум части этих людей. И попутно руководителей, которые проморгали ситуацию и не исправляют.
Вот взять ваш же пример из статьи. Разработчику нужно запустить приложение в определенных условиях - почему из него надо эту информацию клещами тянуть? А с другой стороны - зачем разработчику знать все наименования теплейтов инстансов и групп безопасности? Админ/DevOps на основе требований сам выберет все что надо, если это не эникей с ЗП в 200 тыщ =).
З.Ы. Немножко завидую людям из примера, которые могут бесконечно воевать на работе со всеми и не переживать о будущем.
vya
01.12.2022 13:04Потому и воюют, что переживают. Если бы все вместе работали, а не воевали - давно бы при коммунизме жили.;)
Skimz
01.12.2022 13:15+1Дикие люди придумали Сервисдески и другие тикетные системы. В которых создаются шаблоны заявок в которых прописаны какие данные должны быть указаны в заявке. Но передовое сообщество разработчиков и девопс в данном примере игнорирует эти архаичные инструменты?
ggo
02.12.2022 10:30+1таск трекеры не панацея, а перекладывание ответственности на заявителя.
даже в шаблонами.
допустим я не шарю с сетевых делах. если при заполнении заявки у меня будут спрашивать про гейтвеи, транки, косы, квоты и т.д. я ничего вразумительного не заполню, даже если начну читать про все эти гейтвеи, транки, косы, квоты и т.д.
beeptec
02.12.2022 11:46Мне очень понравился подробный разбор темы конфликтов и противоречий в подаче этих парней.
MaryRabinovich
02.12.2022 13:09В статье нет примера про инициативность DevOps. Разраб выходит на тестовый сервер, а тот не работает. Разраб паникует, пишет девопсу в чатик. Дня через два девопс отвечает, что поменял что-то там в настройках, теперь выкладывать код надо не так, а так. Решил так сделать, поскольку "так всем будет удобнее".
Возможно, у них есть какие-то KPI про то, что вообще они делают. Если ты месяц формально не делаешь ничего, то за что тебе платят? Надо что-то хоть иногда менять. Других трактовок у меня нету.
В целом, мне кажется, многое бы решалось мессаджами не про потребности, а про "когда мы можем переговорить голосом". Договорились о времени, поговорили 10 минут, потом уже можно детали в чате дописывать.
MaryRabinovich
02.12.2022 13:11И кстати да, вопрос: какие KPI у девопсов? Формальные и неформальные? В моём (возможно, кривом) представлении потребителя девопс-контекста лучший девопс - это тот, чьё имя никто не знает. Как лучший китайский правитель. Но если так, то как решают вопрос зарплаты девопса?
PuerteMuerte
Ок, программисты сделали свой ход - написали робота, заменяющего девопса. Ждём ответный удар со стороны девопсов, скрипт, заменяющий программиста.
beeptec
Ok, DevOps организовал проект и построил платформу не требующую услуг со стороны скрипт программистов. Таким образом он освободил свое время для ускоренного продвижения к конечным задачам.
Автор статьи выставляет девопсов полными идиотами и пятым колесом в телеге, при том что девопсы, как и кодеры бывают разными, тупыми или способными.