Назад | Перейти на главную страницу

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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