Почему разработчики не работают лучше и как они могут улучшиться?

139
10
1
Лучший ответ
144

Исторически (в модели развития водопада) разработчики отвечали только за предоставление функций и исправление ошибок. От них не ожидали, что они поймут, как их приложения развертываются или поддерживаются в производстве, поскольку это была «операционная» работа. Эта чрезмерная специализация вызвала несколько неприятных проблем для разработчиков и разработчиков:

игра с постоянным обвинением, вина которой в том, что приложение не работает (как и ожидалось), вместо того, чтобы просто работать вместе, чтобы заставить его работать снова - разработчики имели мнение о написании дерьмового не поддерживаемого кода, и было известно, что операциям требуются целые годы, чтобы делать даже самые простые вещи несет ответственность только за часть процесса разработки (так называемый завершенный код), не зная, что происходит позже - что привело к сбою сборок и развертываний; Более того, поскольку разработчики не контролировали свои приложения в производстве, такого программного обеспечения обычно не хватало с точки зрения ведения журналов, мониторинга и общей телеметрии - разработчики просто не знали, какая команда инструментария нуждалась в операциях, оперативники не делились знаниями о том, что происходило на производстве. запретить разработчикам делать что-либо со своими приложениями; Кроме того - разработчикам среды обычно давали среды, совершенно отличные от prod, что усложняло процесс исправления ошибок.

Как упомянул Эд Гюнтер, немногие умные парни (Джин Ким и Джез Хамбл) согласились с тем, что определенно так не должно работать, и описали так называемое движение DevOps в нескольких превосходных книгах:

Проект Феникс Руководство DevOps Непрерывная доставка

Недавно они опубликовали книгу «Ускорение», но я еще не читал ее, поэтому пока не рекомендую.

Объединяя знания из этих и нескольких других книг с опытом работы с огромным количеством проектов, мы внедрили практики Neops в Neoteric, которые помогают нам преодолеть проблему с отвращением к операциям. Мои любимые:

команды состоят как из разработчиков, так и из администраторов, и несут ответственность за их приложения от самой первой строки кода, посредством сборок и развертываний, вплоть до бесперебойной его работы на производстве. Мы реализовали непрерывную доставку с множеством средств автоматизации, что не только дает нам быструю обратную связь любых проблем - это также форма исполняемой общей документации, которая позволяет создавать и развертывать наши приложения, которая доступна, используется и активно поддерживается каждым членом команды. Откат также автоматизирован, что облегчает эксперименты и обучение (гораздо проще попробовать что-то, если вы знаете, что в случае возникновения проблем вы просто нажимаете кнопку и возвращаетесь к предыдущей версии) инфраструктура обеспечивается с помощью инструментов самообслуживания, которые не дают разработчикам ждать ops guys / gals, в то время как ops имеют время, чтобы поделиться лучшим практикует, как обращаться с конкретными (наиболее сложными) сценариями

Таким образом, разработчик знает, «как выполнять операции», просто формирует повседневную практику и делится этой практикой с операциями. Я считаю, что мы достигли точки, когда различие между dev и ops на самом деле больше не применимо к нам. Я настоятельно рекомендую вам взглянуть на нашу статью о культуре DevOps в блоге Neoteric.

ответил(а) 2019-12-11T17:33:39+03:00 11 месяцев, 3 недели назад
108

Я занимаюсь разработкой программного обеспечения более десяти лет и профессионально занимаюсь разработкой DevOps последние пару лет.

Я нахожу их обоих интересными и сложными, но я бы никогда не переключился на работу только над инфраструктурой.

Это не удар по инженерам инфраструктуры. Я твердо уважаю их навыки, упорство и интеллект. Но DevOps напоминает мне о ремонте автомобилей, а разработка напоминает мне о доставке пиццы.

Раньше я доставлял пиццу, и мне это нравилось. Сама пиццерия представляла собой систему с параллельными и последовательными процессами, и она принимает заказы и ингредиенты в качестве входных данных, а также выпускает горячую пиццу и крылышки в качестве выходных данных.

И доставка, ну ... есть причина, по которой коммивояжер по-прежнему остается одной из самых интересных задач для оптимизации по сей день.

Но когда машина сломалась, это был мой худший день. И, похоже, это был лучший день моих братьев. Ему приходилось проводить часы под солнцем или под дождем, в темное или раннее утро, получая жир и следы ожогов на руках и одежде, а также совершая многочисленные поездки в автозону.

Вот что DevOps заставляет меня чувствовать. Несмотря на то, что я ненавидел сломавшуюся машину и сломавшуюся, когда мне это было нужно, я не возражал против ремонта и определенно наслаждался достижениями и знанием того, как машина работает.

Ремонт автомобилей и работы с инфраструктурой аналогичны тем, что приходится много пытаться подобрать правильные детали, чтобы они поместились в нужное отверстие. А чтобы добраться до дыры, нужно понять, как попасть туда.

«Как вы приступаете к этому болту для стартера?» Это синоним слова «как мне установить таймаут там, в Nginx ??»

Разработчики тоже сталкиваются с этим, когда интегрируют библиотеки и API, а некоторые ненавидят эту часть. Некоторые не против. Может, кому-то даже понравится (фу)?

Если вы не против, то DevOps может быть для вас! Хотите удвоить свою ценность ($$$) в отрасли? Пройдите несколько курсов Udemy и разместите несколько собственных приложений и API.

Это то, как вы совершенствуетесь, вы стимулируете результат и позволяете людям практиковаться и играть.

ответил(а) 2019-12-11T17:33:39+03:00 11 месяцев, 3 недели назад
64

Корень проблемы - борьба со сложностью и нехваткой времени.

В старые времена, когда программист заканчивал свою работу, он нажимал кнопку «компилировать», копировал выходной файл на целевой компьютер и все. Со временем инфраструктура, конфигурация, развертывание, интеграция и т. Д. Становились все более и более сложными. Некоторые разработчики больше внимания уделяли инфраструктуре, а другие больше внимания уделяли разработке. Сегодня как разработка, так и эксплуатация являются настолько большими и сложными темами, что каждая из них требует постоянной работы. Стало невозможно знать все, потому что даже в вашей собственной специализации вы постоянно должны изучать новые вещи, чтобы не отставать. Специализация является необходимостью.

Конечно, такое разделение неизбежно приводит к «несоответствию импеданса» и создает много проблем и неоптимальных решений. Разработка и эксплуатация - две стороны одной медали, поэтому систему всегда следует рассматривать целостно. Такие технологии, как контейнеры, виртуализация, платформы облачных приложений и т. Д., Являются попыткой решения этих проблем, но они все еще не могут решить фундаментальную проблему.

ответил(а) 2019-12-11T17:33:39+03:00 11 месяцев, 3 недели назад
63

Разработчики должны принять передовые методологии, DevOps уже меняет мир в этом аспекте. Однако разработчики никогда не будут иметь пропускную способность для обработки операций. Что, если быть честным, это не то, куда мир собирается в любом случае ... ..

Вот почему искусственный интеллект начинает проникать в ИТ-операции и изменять методы работы разработчиков. Недавно мы выпустили информационный документ об этом, AIOps Adoption: Как успешно внедрить искусственный интеллект в ИТ-операциях, который предоставляет реальные инструменты для включения AI.

ответил(а) 2019-12-11T17:33:39+03:00 11 месяцев, 3 недели назад
52

Компании пытались снизить затраты, чтобы объединить системное администрирование с разработкой и создать странную позицию под названием Dev Ops.

Он не может быть хорошим в долгосрочной перспективе, может работать для небольших компаний и стартапов, но когда он вырастет, вам придется делегировать это более специализированным парням.

ответил(а) 2019-12-11T17:33:39+03:00 11 месяцев, 3 недели назад
53

Этот твит резюмирует это довольно хорошо. По моему опыту, среды, управляемые разработчиками, склонны воспринимать операционную среду как должное, и из-за давления на них разработчики считают, что операционная среда принадлежит исключительно им. Роль devops / sysadmin - защищать целостность среды для всех. Это не означает, что это глобальная проблема, и можно найти команды, которые разбираются в обеих сторонах. Например, политика Google в этом отношении совпадает. Docker, kubernetes и другие легкие системы виртуализации и развертывания дают некоторые ответы на эту проблему, но также могут создать больше проблем. Идеальным является управление ресурсами, которое назначает ресурсы по мере необходимости в среде, которая может их поддерживать. Пока несу большой клуб.

ответил(а) 2019-12-11T17:33:39+03:00 11 месяцев, 3 недели назад
Ваш ответ
Введите минимум 50 символов
Чтобы , пожалуйста,
Выберите тему жалобы:

Другая проблема