Если бы нам довелось прочитать разговор в 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-канал с полезностями и уютный чат