Системный администратор и разработчик: Обязанности [закрыто]

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

Devs должен иметь доступ к тестовой среде. После того как их работа готова быть помещенной на производственную машину, она должна быть передана sys администратору. Если devs сделали свое задание и правильно зарегистрировали процедуру, все будут подходить. В противном случае им нужны их задние стороны, для которых ударяют для того, чтобы не соответственно протестировать.

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

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

Я 100% соглашаюсь. Dev большую часть времени не знают, как работают syadmin вещи. Если им нужно что-нибудь, они спрашивают Вас, это - все. Вы думаете о том, как и когда и Вы обеспечиваете им применимый пакет. (как они должны послать электронные письма, ВЫ - тот, который собирается настраивать постфикс). Кроме того, они будут склонны думать, что в большинство времен, корневой доступ заставит вещи работать, если они не смогут сделать это с нормальным доступом. Я соглашаюсь с другими здесь, они не будут с Вами в 2:00, когда u'll будут видеть проблему. У меня был случай несколько недель назад, разработчик хотел обновить свой Wordpress. Я сказал ему журналу изменений RTF для него, который был бесполезен, процесс обновления сделан через красивый интерфейс. Хорошо обновление не работало, мне сохранили его приложение, я сделал резервный сценарий не им. Без меня он, возможно, не смог восстановить сайт. Поэтому заботьтесь об этих вещах, мы проводим время для установки стратегий (chrooting, резервное копирование, конфигурация) вот почему, мы здесь (и мы любим его :)), и dev никогда не должен interfer с этими вещами (отдайте Caesar, что, принадлежит Caesar),

Существует тенденция для размывания различия между dev и операциями. Сделайте своих системных администраторов разработчиков и своих разработчиков системных администраторов.

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

Можно найти хорошее (и забава) обзором философии при слайдах Гибкой инфраструктуры с Гибкого 2009

Корень == системный администратор.

Пользователи == разработчики, DBAs или пользователи.

Root не знает сна, когда сервер снижается, корень защищает пользователей от себя, корень защищает данные пользователей из сети, корень помещает здоровье сервера, прежде всего, пользователи. Задница Root находится на строке, когда сервер в режиме офлайн. Сервер, счастливый, корневой счастливый!

Общие причины в течение незапланированного времени простоя: Пользователи, Недокументированные изменения в среде и экскаваторы типа обратная лопата. Серверы делают точно, что им говорят, что они не просто случайным образом повреждаются. Хакеры Вы спрашиваете, не если, когда... таким образом потребность в "корне".

0:33 CDT Вы знаете, где Ваши резервные копии и документы аварийного восстановления?:-p

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

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

В публичных компаниях здесь в США, у Вас есть SOX, HIPPA, и т.д. для контакта с. Большинство этих заброшенных инструкций на самом деле помогает с этим аргументом. SOX диктует разделение обязанностей, которое требует, чтобы разработчики сохранили там руки прочь от производственных систем.

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

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

Разработчики действительно хотят иметь root-доступ и в некотором роде нуждаются в нем. В их обязанности входит написать правила перезаписи nginx, чтобы, например, все их пользовательские файлы Drupal работали. Но, черт возьми, я не даю им root-доступ на производственном сервере, и мой клиент соглашается со мной в этом.

Мы пошли на компромисс: они получают root-доступ на тестовом веб-сервере (который в целом идентичен производственному, за исключением его IP-адрес и находится в том же облаке). В котором, как и в производственной среде, есть etckeeper, поэтому я могу видеть, какие изменения они должны были внести, и какие пакеты они установили. Затем я могу либо запустить изменения в производство, либо сказать им, что не так с тем, что они хотят сделать. И если они действительно облажались (они еще не сделали этого, слава gawd), я могу легко отменить их изменения.

У них вообще нет доступа к производственному серверу базы данных; у них даже нет логинов пользователей. Только мой клиент и я.

(Само веб-приложение, они развертываются напрямую с помощью git, и если они его сломают, они должны исправить это и объяснить моему клиенту, почему они должны продолжать быть его разработчиками. Хотя мой клиент отправлял мне копию на такое письмо, чтобы я мог либо посмеяться над ним, либо фейспалм.)