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