Я только что наткнулся Что-то горит в серверной; как я могу быстро определить, что это?. В комментариях я нашла такую цитату:
you don't let a developer anywhere near your root passwords
Как разработчик, но также как человек, очень интересующийся вещами сисадмина, мне интересно, есть ли в этой фразе что-то большее, чем просто стандарт для всех - то есть не выдавать пароли? Комментатор заявляет, что это довольно хорошо известно сообществу системных администраторов. Это?
Поскольку операционная ответственность производственной системы обычно принадлежит системному администратору, только системный администратор должен иметь полный административный доступ к системе - это очень просто.
Теперь вы можете сказать «Ну, иногда мы вносим изменения в код, требующие перенастройки системы, разве у нас не должно быть доступа для соответствующей перенастройки систем?»
Если изменения вашего кода требуют перенастройки системы, вы сможете объяснить системному администратору, какие у вас требования. Таким образом, системный администратор может проверить ваши требования к изменениям и остановить их, если они могут иметь операционные последствия, которые вы, как разработчик, могли не предвидеть.
Отвечая на @NathanLong, я понимаю, что в небольших компаниях иногда бывает так. В таких ситуациях, когда администраторы и разработчики являются одними и теми же пользователями, альтернативой является разделение владения системой между несколькими людьми и обеспечение того, чтобы никто - я имею в виду НИКТО - не вносит свои собственные изменения конфигурации. Попросите другого разработчика просмотреть ваши изменения, а третий выполнит реконфигурацию.
При возникновении сомнений начните с планирования и анализа изменений - все остальное будет составлять ужасное управление изменениями
Я не говорю, что системные администраторы идеальны, но существует огромное количество примеры разработчиков это даже не должны быть разработчики. Не говоря уже о том, чтобы иметь root-доступ к системам с критически важными данными.
Но в любом случае в основном речь идет об ответственности за внесенные изменения. Многим системным администраторам кажется, что разработчики будут делать что-то на серверах, а затем не берут на себя ответственность за то, что они сделали. Разработчики часто сосредоточены только на выполнении единственной программы / задачи, над которой они работают, и не тратят время на то, чтобы обдумывать общую картину или долгосрочное состояние системы, с которой они работают. Они не усвоили привычек, как безопасно вносить изменения.
Это не относится ко всем разработчикам, безусловно, есть отличные разработчики, которые могут отлично поддерживать системы. Просто часто кажется, что это правда в 95% случаев.
Такие привычки, как:
Я попытаюсь объяснить с помощью метафоры (я разработчик, кстати, иногда занимаюсь системным администратором).
Художник и декоратор интерьеров
Допустим, разработчик - художник и создает много фантастических картин. Хорошо, может, они и не фантастические, но он сделал то, что просил его работодатель. У него это хорошо получается, поэтому все картины получаются хорошими.
Теперь картины нужно разместить внутри соответствующих зданий. Художник знает все о краске, но не знает, как правильно что-то закрепить на стене. Если художник все же решит попробовать это (потому что он может), декоратор интерьера (системный администратор) может прийти через несколько недель и ответить так: «Что, черт возьми, здесь произошло ...?» "Все криво, это .. это должно было идти по потолку! Как, черт возьми, это прикреплено к ва .. ЭТО ЭТО КЛЕЙ !?"
Излишне говорить, что декоратор интерьера мог бы справиться лучше. Он знал, где что ставить и как это монтировать. Он постоянно использовал одни и те же винты и случайные провода. Он делал это тысячу раз и мог, в значительной степени, делать это с закрытыми глазами.
Короче говоря: Системный администратор знает, как обращаться со своей установкой лучше, чем разработчик (по крайней мере, он должен). Он будет поддерживать свою систему в чистоте и организованности и знать, как все это работает. Кроме того, многие разработчики привыкли делать вещи сисадминами (например, дома) и они БУДУТ пытаться сделать это сами, если смогут, потому что это экономит их время.
Конечно, бывают ситуации, когда один человек делает и то, и другое, но, скорее всего, они будут в относительно простых средах или местах, где менеджер не смог увидеть, что ему действительно нужны два человека.
Я советую перевернуть его и поставить себя в положение другой стороны.
Итак, в том же духе:
Почему у системных администраторов не должно быть полного доступа для изменения исходного кода?
Короче говоря, для меня это то, что разработчики не должны иметь root-доступ, потому что они не обязательно знают, что делают с точки зрения системного администрирования, и не нуждаются (или не должны) в этом. , поэтому предоставление root существенно увеличивает риск возникновения проблем без всякой пользы. Администрирование систем - чужая работа.
Точно так же, как системные администраторы не должны вносить изменения в код по тем же причинам.
Этот совет кажется немного устаревшим; Это происходит из эпохи, когда непослушные разработчики, у которых был пароль root, приходили и вносили изменения в действующую систему.
Эти дни ни один. Никто должны вносить изменения в действующую систему, ни разработчик ни сисадмин. Внесение изменений на сервере - это работа такой системы, как Chef или Puppet. Наша отрасль вышла за рамки концепции единственный сервер это можно было настроить вручную много лет назад. Теперь нам либо нужна способность иметь множество идентично настроенных серверов развертывание сразу или, по крайней мере, возможность надежно восстановить любой отдельный сервер в любой момент. Это исключает внесение изменений на сервер кем-либо с паролем root, независимо от того, в какой шляпе он находится.
Итак, вернемся к вопросу: должны ли разработчики иметь пароль root? Да! Должны ли системные администраторы иметь пароль root? Да! Зачем? Так как сложные системы не могут быть эффективно диагностированы без умных универсалов, которые понимают их от начала до конца - или, по крайней мере, команда, состоящая из разработчиков и системных администраторов. И часть диагностики не может быть выполнена без входа на сервер и наличия прав на проверку того, что происходит (например, разработчику может потребоваться запустить strace или dtrace, чтобы понять, что на самом деле веб-сервер все время использует). Только помни - смотри, не трогай!
Я работал с большим количеством разработчиков, которые (справедливо) не заинтересованы в том, чтобы быть системными администраторами - они просто хотят, чтобы их программное обеспечение работало. Они выберут самый быстрый путь к этому концу, что часто может повлечь за собой, например, исправление ошибок разрешений с помощью chmod 777 -R .
Само собой разумеется, что это плохо.
Я не могу говорить от имени сообщества системных администраторов, но могу по опыту.
Хотя они, кажется, знают свое дело, они, похоже, не обращают внимания на необходимые детали, и случайные вещи устанавливаются / меняются, например, в другой месяц я узнал, что на одном из наших производственных веб-серверов был установлен KVM / QEMU!
Еще меня раздражает то, что они склонны смешивать роли серверов, поэтому хост гипервизора внезапно также становится сервером мониторинга и веб-сервером. Также, похоже, отсутствует согласованность, например, 3 сервера, выполняющие одну и ту же роль, которые должны быть настроены одинаково, будут настроены 3 совершенно разными способами.
Конечно, комментатор мог просто иметь в виду, что они должны использовать SSH-ключи вместо паролей :)
Обычно это делается для разделения интересов. Введение такого лимита требуется в некоторых средах в целях безопасности. Он может принести пользу для бизнеса, отображая информацию о приложениях, которая иначе была бы недоступна.
Разделение обязанностей и контроль изменений.
Разделение обязанностей означает, что у вас никогда не бывает одного человека, отвечающего за одну задачу. Лучший способ реализовать это - убедиться, что ни один человек не МОЖЕТ выполнить одну задачу в одиночку.
Что касается управления изменениями, для его правильной реализации вы должны убедиться, что все изменения в производственных системах полностью задокументированы. Лучший способ добиться этого - попросить разработчика предоставить системным администраторам раздаточный материал, предоставить им код и документацию и позволить им выполнить развертывание.
Это чрезмерное упрощение общей проблемы ИТ-индустрии. Для одного человека просто слишком много, чтобы знать все, поэтому люди специализируются на своих знаниях. В идеале это должны делать только те, кто обладает специальными знаниями для выполнения задачи.
В реальном мире нас часто просят «носить разные шляпы» со стороны управленческих структур, которые до сих пор не знают всех сложностей работы ИТ и справляются со сложностями работы и финансов компании, которые им известны (и часто ИТ-персонал - нет).
Это часто приводит к таким установкам, о которых спрашивает ОП, когда две из этих ИТ-областей пересекаются. Подобно этому отношению, как сетевой человек, я знаю, насколько легко иметь подобные мысли о сисадминах, ведь часто сисадминов также просят управлять сетью.
В относительно небольшом количестве случаев они делают отличную работу, а в других относительно небольшом количестве случаев они делают ужасную работу. В большинстве случаев они делают достойную работу где-то посередине. Однако запоминаются не великие работы, а ужасающие и в меньшей степени достойные работы.
Когда к участию привлекается сетевой человек (консультант по определенной причине / проекту или потому, что ИТ-персонал расширился и теперь включает одного), они часто обнаруживают, что рекомендуемые передовые методы игнорируются, неправильные конфигурации, дыры в безопасности и т. Д. много времени они проводят, пытаясь выяснить, как пустые вещи стали такими, какими они были, устраняют проблемы, которые не должны возникать, и исправляют неправильные конфигурации и проблемы.
Но это работает в обоих направлениях и включает ряд пересекающихся дисциплин. Что касается моего примера, я как сетевой человек знаю, что я не могу настроить сервер так быстро, как знающий системный администратор, и / или что, вероятно, будет ряд вещей, которые я бы пропустил или сделал неправильно (или, по крайней мере, не в лучшем путь). Дайте мне достаточно времени, и я смогу выполнить, по крайней мере, довольно приличную работу, но часто работа / работа не дают этого времени. Если у меня есть выбор, я легко предпочитаю передать его хорошему системному администратору.