Когда дело доходит до чего-то вроде производственного веб-сервера, как лучше всего распределять обязанности системного администратора и разработчика? Конкретно думаю об обновлении / установке софта. (Насколько я понимаю, разработчик не должен иметь root-доступ на рабочем сервере.)
Итак, на производственном веб-сервере работает Wordpress, и его необходимо обновить до последней версии. Кто отвечает за его обновление?
Что, если у разработчиков есть собственные взломанные плагины или пользовательские файлы ядра в приложении (в данном примере - WP)?
Я обнаружил, что в большинстве случаев, если ВЫ отвечаете за физический сервер, лучше НЕ давать разработчикам root-доступ.
Это что-то вроде споров о «священной войне», поскольку я уверен, что вы найдете разработчиков, которые не согласятся. Я лично был по обе стороны этих дебатов.
Мое ОСНОВНОЕ объяснение того, что я не предоставляю разработчикам (даже 100% доверенным разработчикам) root-доступ, заключается в том, что чаще всего им нужен какой-то пакет для правильной работы XYZ. Они устанавливают его ... или изменяют конфигурацию того, что уже установлено, чтобы оно работало ... или ... ну ... вы поняли.
Проходят месяцы ... сервер нужно переустановить или воссоздать ... и вдруг никто не знает, почему «он работает на старом сервере, а не на новом».
Ответ, конечно же, заключается в том, что документация, которую вы просматриваете, не включает все те небольшие пакеты и настройки, которые разработчики сделали, чтобы система заработала с первого раза.
Это может быть головной болью для обеих сторон ... но если системный администратор отвечает за сервер, пакеты и документацию ... а разработчик отвечает за разработку и программное обеспечение ... я думаю, вы '' Я найду, что в конце концов оно того стоило.
Если разработчику нужен собственный плагин, модуль, конфигурация, настройка ... нет проблем ... сделайте это за них ... но ДОКУМЕНТУТЕ ЭТО, чтобы вы могли воспроизвести это в следующий раз.
Золотое правило: Не позволяйте неадминистраторам прикасаться к тому, что вы не хотите сломать и за что будете нести ответственность.
Разработчики должны иметь доступ к тестовой среде. Как только их работа будет готова для размещения на производственной машине, ее следует передать системному администратору. Если разработчики выполнили свою работу и должным образом задокументировали процедуру, все будет хорошо. Если нет, им нужно пнуть их задницу за неадекватное тестирование.
Я тоже участвовал в этой битве. Мой ответ заключается в том, что тот, кто отвечает за безотказную работу сервера, должен нести ответственность за все обновления, изменения и т. Д. И т. Д. Nobodoy else должен иметь возможность выполнять эти типы функций на сервере. Если ваша задача - убедиться, что сервер запущен и работает, и если начальник возлагает на вас ответственность и ответственность за сервер, то вы обязаны поддерживать и защищать его.
Большинство разработчиков скажут вам, что им нужен доступ на уровне администратора к серверу, и большинство из них не согласятся со мной, но я тот, кто должен перезагружать его в 2 часа ночи, когда он зависает, и должен восстанавливать его после неудачное обновление, время простоя оплачивается моим отделом и т. д. и т. д. Я должен отвечать перед ИТ-директором за все, что влияет на наше соглашение об уровне обслуживания, поэтому я единственный, кто получает доступ на уровне администратора к серверу, и я ' m отвечает за все компоненты, обновления, изменения и т. д.
Согласен на 100%. Разработчики в большинстве случаев не знают, как работает syadmin. Если им что-то нужно, они вас просят, вот и все. Вы думаете о том, как и когда, и доставляете им полезный пакет. (например, им нужно отправлять электронные письма, ВЫ - тот, кто настраивает postfix). Более того, они будут склонны думать, что в большинстве случаев root-доступ заставит все работать, если они не могут сделать это с обычным доступом. Я согласен с другими здесь, их не будет с вами в 2 часа ночи, когда вы увидите проблему. Несколько недель назад у меня был случай, когда разработчик хотел обновить свой WordPress. Я сказал ему в журнале изменений RTF, для него это было бесполезно, процесс обновления осуществляется через красивый интерфейс. Ну, обновление не получилось, я сохранил его приложение, я сделал сценарий резервного копирования, а не он. Без меня он не смог бы восстановить сайт. Так что позаботьтесь об этих вещах, мы тратим время на настройку стратегий (chroot, резервное копирование, конфигурация), поэтому мы здесь (и нам это нравится :)), и разработчик НИКОГДА не должен вмешиваться в эти вещи (вернуть Цезарю то, что принадлежит Цезарю )
Существует тенденция к стиранию различий между разработкой и операциями. Сделайте своих разработчиков системными администраторами, а ваших системных администраторов разработчиками.
В этом смысле wordpress может выиграть от некоторой работы по автоматизированному (и программному) созданию блога. Многие пользователи WordPress поддерживают более нескольких экземпляров WP / WPMU, и их своевременное обновление как минимум обременительно.
Вы можете найти хороший (и забавный) обзор философии на Слайды Agile Infrastructure с Agile 2009
Разработчики не должны иметь root на производстве; с этим согласны все, кроме разработчиков. Но разработчики могут как бы съесть свой торт, так и съесть его. Я несколько удивлен, что об этом прямо не упомянули:
У одного из моих давних клиентов из малого бизнеса есть веб-сайт с установленным Drupal, несколько сайтов WordPress, форум SMF и несколько других случайных небольших веб-приложений. Я - системный администратор контракта (и по историческим причинам также обновляю / взламываю WordPress и SMF, когда это необходимо), и у моего клиента есть собственный контракт с разработчиками Drupal. Среда представляет собой несколько виртуальных машин VMware у поставщика общедоступного облака.
Разработчики действительно хотят иметь root-доступ и вроде как нуждаются в нем. В их обязанности входит написать правила перезаписи nginx, чтобы, например, все их пользовательские файлы Drupal работали. Но, черт возьми, я не даю им root-доступ на производственном сервере, и мой клиент согласен со мной в этом.
Итак, мы пошли на компромисс: они получают root-доступ на тестовом веб-сервере (который в целом идентичен производственному, за исключением его IP-адреса и находится в том же облаке). В котором, как и в производственной среде, есть etckeeper, поэтому я могу видеть, какие изменения они должны были внести, и какие пакеты они установили. Затем я могу либо запустить изменения в производство, либо сказать им, что не так с тем, что они хотят сделать. И если они действительно облажались (они еще не сделали этого, слава Богу), я могу легко отменить их изменения.
У них вообще нет доступа к производственному серверу базы данных; у них даже нет логинов пользователей. Только я и мой клиент.
(Само веб-приложение они развертывают напрямую с помощью git, и если они его сломают, они исправят его и объяснят моему клиенту, почему они должны продолжать быть его разработчиками. Хотя мой клиент отправлял мне копию на такое электронное письмо, чтобы я мог либо смейтесь над ними или фейспалм.)
Корень == Системный администратор.
Пользователи == Разработчики, администраторы баз данных или пользователи.
Root не знает сна, когда сервер не работает, root защищает пользователей от самих себя, root защищает данные пользователей из сети, root ставит здоровье сервера выше всех пользователей. Жопа рута на связи, когда сервер оффлайн. Сервер доволен, root доволен!
Распространенные причины незапланированного простоя: пользователи, недокументированные изменения в окружающей среде и экскаваторы. Серверы делают именно то, что им говорят, а не просто случайно ломаются. Вы спросите, хакеры, не «если», а «когда» ... следовательно, необходимость в «корне».
00:33 CDT вы знаете, где находятся ваши резервные копии и документы аварийного восстановления? :-п
Системные администраторы должны иметь доступ администратора (как указано в заголовке). Больше никому не нужен доступ к производственным серверам. Если разработчикам необходимо устранить проблему в производственной системе, эта проблема должна быть воспроизведена в среде разработки. Если это не так, они могут посидеть с системным администратором и просмотреть систему.
Разработчики не любят, когда у них нет возможности прикоснуться к продакшну, но это не работа. Задача состоит в том, чтобы написать программное обеспечение и передать его системным администраторам для выпуска производственной версии. Если они все задокументировали (и имейте в виду, что в большинстве магазинов документация - ругательное слово), то релизы должны пройти нормально.
В публичных компаниях в США приходится иметь дело с SOX, HIPPA и т. Д. Большинство этих забытых богом правил действительно помогают в этом аргументе. SOX диктует разделение обязанностей, которое требует, чтобы разработчики держали руки подальше от производственных систем.