Должен ли dev быть администратором на своем компьютере? [закрыто]


35

Должны ли разработчики в корпоративной среде иметь права администратора на своем компьютере? Зачем?

Технологическая среда:

  • Windows 7
  • Visual Studio 2008 & 2010
  • SQL Server




3
Я голосую за то, чтобы вновь открыть этот вопрос, потому что, несмотря на несколько субъективный характер вопроса, с ним почти каждый администратор Windows (я не могу комментировать другие платформы) столкнется во время своей карьеры. Ответы, опубликованные до сих пор, предоставляют информацию, которая, как я полагаю, поможет другим, когда столкнется с этой проблемой.
Джон Гарденье

2
Если бы я мог проголосовать, чтобы открыть это, я бы.
jmort253

Ответы:


52

Должны ли они? Это зависит от корпорации. Лично я думаю, что это нормально, если есть некоторые понятные правила.

  1. Быть администратором на вашем ящике - это привилегия, а НЕ право.
    1. Ловля вирусов в нескольких случаях будет отменена
    2. Отключение корпоративных агентов приведет к отмене прав - AV / инвентаризация / развертывание программного обеспечения / и т. Д.
    3. В основном, если вы делаете что-то, что рискует, сеть будет отозвана
  2. Любые инструменты, которые вы устанавливаете, не должны становиться зависимыми от вашего проекта без их включения в официально утвержденный список. Будьте добры, не срывайтесь в день развертывания и требуйте установки $ random_library на все серверы без тестирования
  3. Для чего-либо за пределами обычных приложений, установленных везде, поддержка будет наилучшим усилием. Служба поддержки и / или системные администраторы не будут тратить 5 часов, пытаясь отладить причины конфликтов с DLL.

18
Хороший список. Также добавим, что если продукт в конечном итоге будет запускаться пользователями без прав администратора, то вам необходимо провести соответствующее тестирование (реальное тестирование юзабилити). Слишком много разработчиков проводят тестирование бедняков, где они тестируют на своей машине разработчика, на которой у них есть права бога. Продукт работает хорошо, и они получают одобрение только для того, чтобы узнать, что он задыхается в непривилегированной среде.
Шон Андерсон

4
@ Шон, есть причина, по которой вам нужны тестеры и разработчики.
Ян Рингроз

11
Это типичный ответ администратора сети, который не понимает, почему разработчикам требуются права администратора. Это должен решать человек уровня менеджера, который управлял или был разработчиком в прошлом. В противном случае вы не будете заражены вирусами, а офисы свободны от разработчиков.
Мухаммед Хасан Хан

11
@Hasan, и это типичный ответ разработчика, которому никогда не приходилось иметь дело с зараженной сетью, насыщающей DS3 трафиком, который захватывает весь офис. Я не прошу вас делать что-нибудь столь обременительное здесь.
Zypher

9
В доме разработчиков вы находитесь в бизнесе из-за программного обеспечения, которое выпускает команда разработчиков. Я работал в нескольких компаниях, где машины были заблокированы до такой степени, что это делало работу невозможной, и нам было трудно убедить людей, что нам нужны привилегии администратора для запуска инструментов разработки. Или там, где доступ в интернет был ограничен, чтобы мы не могли даже прочитать онлайн-документацию. Или антивирусный продукт, который сканировал каждую вставку записи базы данных и, следовательно, так сильно снижал производительность, что мы, разработчики, не могли заставить программное обеспечение работать правильно.
Мэтт

35

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


13
+1 - разработчики (обычно) довольно умные люди и поддерживают свои машины в чистоте
Марк Хендерсон

9
Не говори так. :)
mrdenny

4
@ Марк, мне еще предстоит увидеть доказательства, подтверждающие это утверждение.
Джон Гарденер

4
@ Марк Хендерсон, возможно, вам повезло работать с хорошей группой людей. Во- первых, если сайты, которые я читаю ежедневно , создают у меня впечатление, что не все разработчики созданы равными.
Зоредаче

8
Я считаю, что есть старая клингонская пословица, которая гласит: «Остерегайтесь программистов, несущих отвертки».
Барт Сильверстрим

23

В развитии есть и наука, и искусство; это не так просто, как «знать», что нам нужно. Если у нас уже был ответ половину наша работа будет спорно; Поиск правильного подхода часто повторяется и может включать в себя несколько инструментов непредсказуемым образом. Требовать посредника для установки каждого из них (часто с высокой задержкой) только для того, чтобы найти (около часа в), что для вашего сценария необходим «аддон сверхабонентского инструмента», глупо.

Хотя виртуальная машина идеально подходит для этого, есть также много инструментов разработки, которые не могут работать (должным образом или даже вообще) в виртуальной машине, потому что они сами являются виртуальными машинами - и я не имею в виду такие вещи, как JVM; Я имею в виду полную машину emus / vms, например, наборы инструментов для устройства. Совместимость там улучшается.

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

Производительность огромна здесь; Как вы думаете, было ли нормально, чтобы пользователи ждали 3 секунды после каждого нажатия клавиши в Word для регистрации своего ключа? Я не шучу - инструменты разработки на виртуальных машинах и т. Д. Могут быть такими отстойными; для большинства целей разработки вам нужна отзывчивость. Прерывание потока сложной логики от мозга к клавиатуре может сделать практически невозможным выполнение работы. И я ненавижу это говорить, но да: время разработки стоит дорого.


18

В среде Windows, и особенно при использовании продуктов Microsoft для разработчиков, разработчику потребуются права администратора на их компьютере. Если вы лишите их этих прав, их способность выполнять свою работу будет ограничена, если не будет полностью запрещена.


1
Может быть. Но они должны быть обязаны тестировать свой код в непривилегированной среде, если они делают продукт для потребления пользователем.
Барт Сильверстрим

2
@ Барт, я полностью согласен, но разработчики все равно должны проводить тестирование на отдельной машине, потому что инструменты разработки создают совершенно иную среду, чем на «обычном» компьютере.
Джон Гарденье

@BartSilverstrim, который не всегда следует. То, что пользовательская часть приложения работает как обычный пользователь, не означает, что все компоненты работают (например, рассмотрим клиент-сервис, серверу, вероятно, потребуются более высокие привилегии). А потом подумайте об установщике ...
Ричард

1
@Richard, это тоже правда, но я считаю, что Барт считал, что тестирование должно проводиться в среде, максимально приближенной к тому, что будет использовать клиент.
Джон Гарденье

1
Правильный ответ на проблему программного обеспечения, не связанную с системными задачами, почти никогда не следует «запускать от имени администратора».
Барт Сильверстрим

9

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

Иногда мне может понадобиться установить дополнительную библиотеку для того, чтобы приложение, которое я разрабатываю, работало в производственной среде. При этом у меня есть строгое правило, которое я разработал: «Для любого приложения, для которого требуются сторонние библиотеки, библиотеки должны быть установлены в среде «песочницы» перед производственным развертыванием и, в некоторых случаях, перед разработкой приложения ».

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

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


9

Отказ от ответственности: я разработчик.

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

Итак, давайте представим, что мы спорим об этом перед директором по ИТ или операциям, или кем бы ни контролировал наш бюджет , и задаем эти вопросы.

  1. Какая минимальная привилегия требуется для выполнения функций отдела? Это наша базовая линия.
  2. Каковы риски предоставления им большего доступа? (реальные риски, а не только лучшие / худшие сценарии)
  3. Какова истинная ожидаемая стоимость предоставления им большего доступа? (расходы на поддержку, исправление непреднамеренных изменений, сделанных неопытным администратором и т. д.)
  4. Какова истинная ожидаемая стоимость не предоставляя им больше доступа? (потеря производительности, потребность в ИТ-поддержке для выполнения повседневных задач, текучесть кадров из-за морального состояния и т. д.)

Ответив на эти вопросы, вы можете принять обоснованное решение, а не страстное.

Для вашей конкретной среды есть некоторые вещи, которые требуют прав администратора (см. Права пользователя и Visual Studio ) - если они этого не делают, тогда вы можете ответить на вопросы 2 - 4.

Как консультант, я видел обе крайности этой политики, и, хотя я всегда хочу иметь административный доступ к машине, в некоторых случаях это не имело смысла. И я не уверен, что является причиной и что является следствием, но без исключения все места, где я видел разработку Windows, где разработчики имели доступ администратора, также имели НАМНОГО более высокую производительность от каждого разработчика, чем места, где они были заблокированы.


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

4

Я думаю, что вы задаете неправильный вопрос, вы должны спросить:

Будет ли хороший разработчик работать для работодателя, который не дает ему / ей права администратора на их ПК?

То, что кому-то «нужно» и чего они ожидают, часто не одно и то же, ведь вам не нужно позволять разработчику пить кофе в рабочее время, но если вы этого не сделаете…

(Убедитесь, что вы четко изложили свою политику на этапе собеседования, в противном случае вы можете получить людей, которые возьмут на себя работу, которая затем будет презирать вашу компанию из-за отсутствия прав администратора - не ожидайте, что программисты логично подумают о подобных вещах! )


Я признаю, что я работаю в высшем образовании и являюсь «системным администратором / программистом», как и все в моей группе, поэтому я полагаю, что мой опыт не совсем актуален. Но я не могу представить себе работу в качестве разработчика в магазине, который не дал бы мне полный контроль над моей рабочей станцией (выбор и установка ОС, выбор программного обеспечения и т. Д.), Не говоря уже о привилегиях пользователя root.
Джейсон Антман

4

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

ИМХО, лучшая рабочая среда, которую я видел по сей день, - это то, где две группы держатся отдельно. Разработчики имеют свой собственный домен в лесу (посредством которого ИТ контролирует, что этот домен и его пользователи могут делать в остальной части компании), и все они являются локальными администраторами с опытными парнями с MCSE, выступающими в роли администраторов локальных доменов, у них есть собственная тестовая среда и может делать практически все, что им нужно и в их локальной сети, с помощью единой политики ИТ (без пиратского программного обеспечения). Корпоративные ИТ не несут ответственности и не оказывают поддержку разработчиков и только усиливают некоторые корпоративные правила высокого уровня (не facebook, порно или подобное через брандмауэр, УБСА не позволяют связываться с корпоративной локальной сетью), и все они имеют виртуальные частные сети на основе RSA для работы из дома который помещает их прямо в их локальной сети. Аккуратно, не правда ли?


2

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


2

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

Все идет не так, и вы можете стереть и восстановить в считанные минуты.


2
Есть одна очень веская причина не привязывать их к виртуальной машине - производительность. Разработчик, работающий над основным приложением, может легко использовать каждый бит машины с высокими техническими характеристиками с огромным объемом оперативной памяти, быстрым жестким диском и т. Д. Установка их на виртуальную машину - это почти то же самое, что возвращение их компьютеров несколько лет назад. Отлично подходит для безопасности, но не так хорош для производительности.
Джон Гарденье

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

4
Речь идет не о написании для нижнего уровня требований, а об использовании инструментов, которые требуют более высокой производительности, чем позволяют виртуальные машины. Использование Visual Studio 2010 внутри виртуальной машины заметно менее адаптивно, чем на голом железе. Продукт, который вы пишете, может нормально работать на ВМ, но это не значит, что инструменты разработчика всегда работают.
Майкл Шимминс

2

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

Как разработчик, разочаровывает, когда что-то не работает, потому что у нас нет доступа.


2

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

Как Java-разработчик, у меня почти не было необходимости иметь права администратора на моей машине на постоянной основе . Тем не менее, существуют законные случаи, когда вам нужен доступ по требованию администратора (.ie. Вам нужно переместить свой ноутбук через физически отдельные домены, и вам нужно соответственно изменить свой сетевой адаптер.) Это был единственный раз, когда мне действительно нужно было постоянный постоянный доступ администратора к моей машине.

Иногда вам нужен доступ администратора, потому что ИТ недоукомплектованы (или некомпетентны, или погрязли в волоките). Но если вы работаете с компетентным ИТ-отделом, они могут установить его для вас даже удаленно (или предоставив пользовательских установщиков, которые будут «запускаться как» "Администратор и установить материал для вас, просто нажав на них.)

Так что ответ (опять же) - это зависит. Есть ли у вас отзывчивый ИТ-персонал, который может устанавливать вещи по требованию (или в разумные сроки)? Нужно ли это разработчикам для тех задач, за которые им платят ?

Если разработчики действительно и законно нуждаются в этом (как в «Я буквально не смогу ничего сделать без него» ), в отличие от удобства (как в «Я хочу установить все, что я хочу» ), и если ИТ-поддержка недостаточно отзывчив (по каким-либо причинам), тогда да, у них должен быть доступ администратора к своим машинам.

В противном случае нет. Помните принцип наименьших привилегий , люди.


2

Есть разработчики и есть разработчики. Если «разработчик» - это какой-то Java-парень JBoss за $ 40 / час, пишущий правила для механизма правил, то, конечно, нет. Если «разработчик» - это C / Assembly за $ 350 / час, который заставляет ваше программное обеспечение для редактирования видео работать на GPU с максимальной скоростью, то да, конечно.


1

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

Это не обязательно правда...

Вы можете создать собственную политику и заставить все программы и функции работать с пользователями разработки в системе. Вам просто придётся разбираться в грязи и в мелочах с пользовательскими разрешениями на программные / системные каталоги с группами или пользовательскими группами в зависимости от желаемого дизайна.

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


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

Я бы предпочел тогда полный доступ в сети dev, а затем подключаться к корпоративной сети через Интернет только через VPN, если это реальная проблема. Я также много корпоративных отделов ИТ, которые я видел, предоставил мне меньше, чем то, что делает хороший провайдер !! Разработчику не нужно быть в той же нефильтрованной сети, что и бухгалтерия и т. Д.
Ян Рингроз

1

Разработчики должны (в идеале) иметь два доменных имени пользователя.

Тот, который имеет права локального администратора (для разработки) и тот, который имеет те же права, что и все остальные в компании. Затем они могут проверить свою работу на репрезентативном наборе разрешений.

Это должно уменьшить вероятность того, что ItWorksOnMyMachine-itis иногда появляется .....


0

Я должен (явно) предоставить несогласный голос и сказать не только нет, но и черт возьми. У меня нет проблем с предоставлением прав администраторам на изолированную виртуальную машину, которая не имеет доступа к сети. У Зайфера это было почти правильно (исправление выделено жирным шрифтом):

«Быть ​​администратором на моем ящике - это привилегия, а НЕ право». Эти системы являются корпоративными активами, за которые я несу полную ответственность. Когда Джо Разработчик устанавливает свою пиратскую копию Microsoft Боба («потому что мне это было нужно »), ему не придется объяснять, как ее не нашли до аудита. Разработчики обычно думают, что корпоративные правила так или иначе не применяются к ним. Предоставляя им изолированную виртуальную машину, они могут следовать всем правилам, которым должны следовать все остальные (поскольку теперь только ИТ-специалисты могут копировать файлы в систему и из нее). Волшебным образом система запросов снова используется разработчиками, небо больше не падает, когда Джо Разработчик портит свой ящик для разработки - он просто просит новый (или восстановление, если его просят сделать резервные копии)

Г-н Денни упомянул, что разработчики стоят денег, когда им приходится ждать установки приложений, А. привет ... мое время, как правило, столь же ценно, как и Joe Developer (как правило, тем более, поскольку я поддерживаю работающее программное обеспечение - и действительно ли я Я должен упомянуть все время, потраченное на то, чтобы помочь разработчику Джо отладить его последний шедевр), и Б., когда dev перебирает бюджет, потому что они ждали приложения и пытались обвинить в этом ИТ, я бы сказал:

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

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

РЕДАКТИРОВАТЬ: Конечно, вполне возможно, что разработчики, с которыми я сталкивался, необычайно скучны (опрос текущего урожая только 1 слышал о переполнении стека, чтобы дать некоторый уровень эталона). Исходная точка зрения, с которой я начинаю, - «что вам нужно делать, что компания платит за вас». Если вам нужны права администратора, вы их получаете, но не стоит с ними бороться, и если я могу дать вам коробку, которая, честно говоря, мне все равно, что вы с ней делаете, и это работает, тогда мы оба готовы идти вперед.


14
Ух ты, БОФ живет среди нас! Вы потерпели неудачу по основному принципу, согласно которому наша работа - это прежде всего предоставление всем остальным возможности выполнять свою работу наилучшим образом в рамках ограничений, наложенных на нас политикой, правовыми требованиями и т. Д. Это НЕ является одним из произвольно диктовать другим, как они должны работать просто потому, что это нам подходит.
Джон Гарденье

+1 за последний абзац. Вы можете исключить все остальные параграфы, если просто нанять достойных разработчиков.
Роберт Харви

6
Ух - люби нас и им менталитет. Считаете ли вы, что «его» крайний срок на самом деле является «вашим» крайним сроком, так как вы все в нем вместе (предположительно) на благо компании. Я не знаю вас по кусочку мыла, но вы напоминаете мне о мерзком, высокомерном, типичном администраторе sys, пытающемся найти способ сказать-нет-скорее-чем-да-да. Для каждого 1 хорошего системного администратора есть еще 10, которые ваша компания нанимает, которые увековечивают стереотип, который вы только что изложили, и делают все остальное в жизни компании намного сложнее. Вы должны заботиться о предоставлении услуг, а не об ограничениях.
Майкл Шимминс

Я специально рассмотрел большинство из этих пунктов в ответе: serverfault.com/questions/232416/…
Марк

1
Возможно, ВЫ - причина того, что «разработчики, с которыми вы работали, необычайно скучны»… Компания должна решить, хочет ли она вольнодумских или скучных разработчиков, и не может действовать так, как ненавидят вольнодумые разработчики, а затем рассчитывает отделить кого-либо от скучных разработчиков. Однако унылые разработчики могут быть лучшими из большой корпоративной работы.
Ян Рингроз
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.