Comments 23
Виртуальный помощник выполняет его запрос.
Ок, программисты сделали свой ход - написали робота, заменяющего девопса. Ждём ответный удар со стороны девопсов, скрипт, заменяющий программиста.
Продвигаемый в статье подход больше похож на запоздалую маркетинговую чушь про AI. Индустрия идет в декларативный IaC, а не императив. О проблеме общего языка Дмитрий Столяров из Флант делал доклады еще года 4 назад, актуально до сих пор.
Update: не удивлюсь, если kubiya.ai повторяет бизнес-модель engineer.ai/builder.ai - чат на аутсорсе.
Не, не, не, какой AI. Надо уволить девопса и его обязанности переложить на разработчика.
//сарказм
Как по мне война между разработчиками и девопсами возникает из-за низкой квалификации последних. Хорошие девопсы, это программисты, которые постигли SDLC, CI/CD, Cloud, IaaC практики. Плохие девопсы, это неучи после курсов, либо сисадмины не имеющие никакого представления о разработке ПО.
Виртуальные окружения, инфраструктура как код (императивный код высокого уровня, а не yml или скрипты на баше), удобные и стандартизированные на всю компанию инструменты для логгирования, конфигурирования и отладки -- вот секрет успеха и быстрой разработки.
А когда девопсы вставляют палки в колеса, мол это сложно задеплоить, пишите код криво, что бы легко деплоилось, да и еще забирают себе все права, что нужно на каждый чих им писать, тогда и начинается война.
О чем речь если никто не может сказать, что же входит в обязанности девопса? Зачастую, особенно на out-stuff проектах, наличие девопсов только создает проблемы, так как опытные разработчики сами могут все настроить, но у них нет доступов.
Для меня девопс, это эксперт не только по развертыванию ПО, но и по автоматизации развертывания. Это автоматизация должна быть гибкой и простой настолько, что любой разработчик в команде, будет способен легко из шаблонов создать новый микросервис и задеплоить его в дев-окружение. Но как показывает практика, хороших спецов можно встретить крайне редко.
Как по мне война между разработчиками и девопсами возникает из-за низкой квалификации последних
или первых. Или упрямства последних, или упрямства первых, или лени последних, или лени первых, или излишней педантичности... в общем, стопицот их, причин.
Как по мне война между разработчиками и девопсами возникает из-за того, что обе стороны мнят себя великими творцами-архитекторами. По факту первые беспробудно кодят в жестких рамках, придуманных другими, вторые вынуждены вечно что-то автоматизироват.
2013 год. Джин Ким, Джордж Спаффорд, Кевин Бер пишут книгу "Проект «Феникс». Роман о том, как DevOps меняет бизнес к лучшему". Книга о том, как новая парадигма DevOps рушит границы между разработкой, тестированием, сопровождением/эксплуатацией и все вместе делают бизнесу хорошо.
2022 год. @ru_vds пишут статью на Хабре "Пора закончить холодную войну между DevOps и разработчиками ПО"
И - ирония.
PS: Отнеситесь к комментарию иронично. Да, я прекрасно понял, что написано в статье и нахожу её скорее полезной. Да, я понимаю, что под DevOps в статье подразумеваются администраторы, сопровождающие процесс разработки, а не полумифическая (но всё равно полезная) парадигма из книги. Просто обратил внимание на некоторую эволюцию терминов и понятий.
Прочел статью, но не увидел в ней ответа на вопрос: зачем так сложно - чат-бот, NLP, NLU и прочие достижения AI? Почему нельзя использовать опубликованный на веб-сервере каталог услуг, а задачу формализации запросов возложить на самих разработчиков - наверняка ведь они это умеют?
Особенно непонятности добавдяет то, что эта статья размещена в блоге компании, которая сама предоставляет довольно широкий спектр услуг широкому кругу лиц и, наверняка, с каталогом услуг знакома не по наслышке.
Тоже подумалось об этом.
1. В идеале всё решается пивной посиделкой с участием девопсов и разработчиков, после чего в представителях другого отдела перестаёшь видеть гоблинов и лентяев и выстраивается вполне себе нормальный неофициальный канал связи.
2. Если первый пункт не получается или по каким-то пунктам неприемлем, формализуется процесс - разрабатывается форма заявки, в которой описываются все необходимые поля, а также время реакции DevOps-ов. Сформированная заявка отправляется любым каналом связи.
3. Если и это не решает проблем, ставится и настраивается обычная тикетная система.
Может мне просто такие коллективы попадались, но среди программистов почти никто не пил. Особенно если было много молодых. Так что идея с "посиделками" так себе. А еще она может сработать с точностью до наоборот и алкоголь кому-то развяжет язык.
Всякие тимбилдинги, если они по указке сверху тоже не приветствую. Наверное единственный способ улучшить коммуникацию это посадить работать рядом, но это не всегда возможно. Как правило работники сбиваются в группки "по кабинетам" вне зависимости от размера кабинета и рода занятий. Ну и кроме конфликтов профессий еще конфликт возрастов существует.
А иногда менеджеры даже культивируют такого рода конфликты, так как тесная команда может начать диктовать свои условия и шантажировать уходом.
В таком случае можно переходить к пункту 2: создавать форму и ставить нормативы, в течение какого времени DevOps должен вернуться с результатом: инстанс поднят, инстанс не поднят по такой-то причине и дальнейшие шаги..., в заявке не понятны пункты...
Лезть программистам "в кухню Devops-ов", не зная как там всё распланировано и настроено (читай отправлять конфиг через чат-бот) - верный способ поссориться с коллегами.
Devops - это не про ansible, gitlab, terraform, helm, etc. Технологии вообще не причем.
Devops - про взаимодействие условных девелоперов с условными админами для достижения общих целей. Если идет такой диалог, как в прологе статьи, это не devops. Это яркий пример той проблемы, которая присутствовала в прошлом, и присутствует в настоящем - отсутствие тесного взаимопонимания. И devops как раз вариант решения этой проблемы. Опять же решение не в технологиях, а в том, чтобы условный девелопер и условный админ стали одной командой с единой целью и начали друг с другом конструктивно обсуждать имеющиеся проблемы и возможные решения. И после принятия решения - имплементация может быть в использовании конкретной технологии.
Аналогичная история с Agile. Agile не про спринты, дейлики, ретро и прочее. Agile про тесное взаимопонимание бизнеса и технарей.
Автоматизированный бардак останется бардаком. А бот вносит в бардак дополнительную боль. Жать кнопки и заполнять формы проще и понятнее, чем объяснять боту что ж ты хотел-то.
Если у вас войны между разработчиками и админам (ну ладно-ладно DevOps-ами), то это может говорить о недостаточной квалификации как минимум части этих людей. И попутно руководителей, которые проморгали ситуацию и не исправляют.
Вот взять ваш же пример из статьи. Разработчику нужно запустить приложение в определенных условиях - почему из него надо эту информацию клещами тянуть? А с другой стороны - зачем разработчику знать все наименования теплейтов инстансов и групп безопасности? Админ/DevOps на основе требований сам выберет все что надо, если это не эникей с ЗП в 200 тыщ =).
З.Ы. Немножко завидую людям из примера, которые могут бесконечно воевать на работе со всеми и не переживать о будущем.
Дикие люди придумали Сервисдески и другие тикетные системы. В которых создаются шаблоны заявок в которых прописаны какие данные должны быть указаны в заявке. Но передовое сообщество разработчиков и девопс в данном примере игнорирует эти архаичные инструменты?
таск трекеры не панацея, а перекладывание ответственности на заявителя.
даже в шаблонами.
допустим я не шарю с сетевых делах. если при заполнении заявки у меня будут спрашивать про гейтвеи, транки, косы, квоты и т.д. я ничего вразумительного не заполню, даже если начну читать про все эти гейтвеи, транки, косы, квоты и т.д.
В статье нет примера про инициативность DevOps. Разраб выходит на тестовый сервер, а тот не работает. Разраб паникует, пишет девопсу в чатик. Дня через два девопс отвечает, что поменял что-то там в настройках, теперь выкладывать код надо не так, а так. Решил так сделать, поскольку "так всем будет удобнее".
Возможно, у них есть какие-то KPI про то, что вообще они делают. Если ты месяц формально не делаешь ничего, то за что тебе платят? Надо что-то хоть иногда менять. Других трактовок у меня нету.
В целом, мне кажется, многое бы решалось мессаджами не про потребности, а про "когда мы можем переговорить голосом". Договорились о времени, поговорили 10 минут, потом уже можно детали в чате дописывать.
Пора закончить холодную войну между DevOps и разработчиками ПО