SysAdmin & Developer: Обов'язки [закрито]

Якщо мова йде про щось на зразок виробничого веб-сервера, яка найкраща практика для відповідальності перед системою та розробником? Зокрема, я думаю про оновлення / встановлення програмного забезпечення. (Наскільки я розумію, у розробника не повинно бути кореневого доступу на виробничому сервері.)

Отже, на виробничому веб-сервері працює Wordpress, і його потрібно оновити до останньої версії. Хто несе відповідальність за його оновлення?

Що робити, якщо у розробників є хакерські плагіни або спеціальні основні файли програми (у цьому прикладі WP)?

Я виявив, що в більшості випадків, якщо ви відповідаєте за фізичний сервер, найкраще НЕ надавати кореневому доступу розробників.

Це трохи дискусія про "святу війну", оскільки я впевнений, що ви знайдете розробників, які не згодні. Я особисто був на обох сторонах цієї дискусії.

Мої ОСНОВНІ міркування про те, щоб не надавати кореневому доступу дискам (навіть 100% довірених розробників) є те, що найчастіше є якийсь пакет, який їм потрібен для того, щоб XYZ працював правильно. Вони йдуть вперед і встановлюють його ... або переконфігурують щось, що вже є, щоб воно працювало ... або ... ну ... ви зрозуміли ідею.

Минають місяці ... сервер потрібно перевстановити або відтворити ... і раптом ніхто не знає, чому "Це працює на старому сервері, але не на новому".

Відповідь, звичайно, полягає в тому, що документація, яку ви переглядаєте, не включає всі ті маленькі пакунки та налаштування, які розробники зробили для того, щоб система працювала вперше.

Це може бути болем у $ $ для обох сторін ... але якщо sysadmin відповідає за сервер, пакети та документацію ... а розробник несе відповідальність за розробку та програмне забезпечення ... Я думаю, що ви ' Я знайду, що це було варте зрештою.

Якщо розробнику потрібен спеціальний плагін, модуль, конфігурація, налаштування ... немає проблем ... зробіть це для них ... але ДОКУМЕНТ ІТ, щоб ви могли його відтворити наступного разу.

Золоте правило : Не дозволяйте адміністраторам торкатися того, чого ви не хочете зламати, і за що будете нести відповідальність.

Розробники повинні мати доступ до тестового середовища. Після того, як їх робота буде готова поставитись на виробничу машину, її слід передати адміністратору sys. Якщо чорти зробили свою справу і правильно задокументували процедуру, все піде добре. Якщо ні, то вони потребують, щоб їхні боки вигнали задля недостатнього тестування.

Я також був у цій битві. Моя відповідь полягає в тому, що хто несе відповідальність за час роботи сервера, той, хто повинен відповідати за всі оновлення, зміни і т. Д. І т.д. Якщо ваша робота - переконатися, що сервер працює та працює, і якщо начальник несе за вас відповідальність і відповідальність за сервер, тоді це ваша відповідальність за його підтримку та безпеку.

Більшість розробників збирається сказати вам, що їм потрібен доступ адміністратора до сервера, і більшість з них зі мною не погоджуються, але я той, хто повинен перезавантажити його о 2 ранку, коли він зависне, повинен відновити його після невдале оновлення, час простою стягується з мого відділу, і т. д. і т. д. Я маю відповідати в керівництві директора по роботі за те, що впливає на нашу умову угоди, тому я єдиний, хто отримує доступ адміністратора до сервера, і я ' м відповідальний за всі компоненти, оновлення, зміни тощо.

Я на 100% згоден. Dev більшість часу не знають, як працюють сидмін. Якщо їм щось потрібно, вони просять вас, ось і все. Ви думаєте про те, як і коли, і доставляєте їм корисний пакет. (як, наприклад, їм потрібно надсилати електронні листи, ВИ - це той, хто налаштовує постфікс). Більше того, вони схильні думати, що в більшості випадків кореневий доступ призведе до того, що вони працюватимуть, якщо вони не зможуть зробити це за допомогою звичайного доступу. Я згоден з іншими тут, вони не будуть з вами о 2 ранку, коли у вас з’явиться проблема. У мене був випадок кілька тижнів тому, розробник хотів оновити свій wordpress. Я сказав йому в журнал змін RTF, для нього це було марно, процес оновлення здійснюється через прекрасний інтерфейс. Ну оновлення не спрацювало, я зберегла його програму, я створив резервний сценарій не він. Без мене він не міг би відновити сайт.

Існує тенденція до розмивання різниці між розробниками та операціями. Створіть своїх розробників sysadmins та своїх sysadmins.

У цьому сенсі wordpress може отримати користь від роботи над автоматизованим (і програмним) створенням блогу. Багато користувачів Wordpress підтримують більше декількох екземплярів WP / WPMU, і своєчасне їх оновлення є принаймні громіздким.

Ви можете знайти хороший (і цікавий) огляд філософії на слайдах Agile Infrastructure від Agile 2009

Розробники не повинні мати корінь у виробництві; з цим погоджуються всі, крім розробників. Але розробники можуть сортувати свій торт і їсти його теж. Я дещо здивований, що ніхто цього прямо не згадував:

Один з моїх дуже давно малих бізнес-клієнтів має веб-сайт із установкою Drupal, кілька сайтів WordPress, форум SMF та кілька інших випадкових невеликих веб-додатків. Я є системним адміністратором за контрактом (і з історичних причин також оновлюю / злом WordPress та SMF, коли це потрібно) і мій клієнт має власний контракт розробників Drupal. Навколишнім середовищем є кілька віртуальних машин VMware на загальнодоступному постачальнику хмарних технологій.

Розробники дуже хочуть мати доступ до кореня та потребувати цього. Це їхня відповідальність писати правила перезапису nginx, щоб, наприклад, працювати всі їх власні друкарські речі. Але я ні в якому разі не даю їм root доступу на виробничому сервері, і мій клієнт погоджується зі мною в цьому.

Тож ми йшли на компроміс: вони отримують кореневий доступ на тестовому веб-сервері (який, як правило, ідентичний виробництву, за винятком його IP-адреси та знаходиться в одній хмарі). Котрий, як і виробництво, має etckeeper, тому я можу побачити будь-які зміни, необхідні для внесення, та будь-які встановлені пакети. Тоді я можу або втягнути зміни у виробництво, або сказати їм, що не так у тому, що вони хочуть робити. І якщо вони насправді накрутили (ще не, дякую gawd), я можу легко відновити їх зміни.

Вони взагалі не мають доступу до сервера виробничої бази даних; вони навіть не мають користувачів. Тільки мій клієнт і я.

(У самому веб-додатку вони розгортаються безпосередньо за допомогою git, і якщо вони порушують його, вони отримують виправити це і пояснити моєму клієнту, чому вони повинні продовжувати бути його розробниками. Хоча мій клієнт буде мені на такій електронній пошті, щоб я міг або сміятися над ними або з фарбою.)

Root == Системний адміністратор.

Користувачі == Розробники, DBA або Користувачі.

Root не знає сну, коли сервер не працює, root захищає користувачів від самих себе, root захищає дані користувачів від мережі, root ставить здоров'я сервера вище всіх користувачів. Коренева дупа знаходиться на лінії, коли сервер перебуває в автономному режимі. Сервер щасливий, root задоволений!

Загальні причини непланового часу роботи: користувачі, незадокументовані зміни в навколишньому середовищі та навантажувачі. Сервери роблять саме те, що їм кажуть, що вони не просто випадково ламаються. Хакерів, яких ви запитуєте, це не так, це коли, то ... таким чином, необхідність у "корені".

00:33 CDT Ви знаєте, де знаходяться ваші резервні копії та документи на відновлення після аварій? :-p

У системних адміністраторів повинен бути доступ адміністратора (як і в назві). Ніхто більше не потребує доступу до виробничих серверів. Якщо розробникам потрібно усунути проблему у виробничій системі, ця проблема має бути відтвореною в середовищі розробки. Якщо це не так, вони можуть сидіти з sysadmin і переглядати систему.

Розробникам не подобається, що вони не можуть торкнутися виробництва, але це не там робота. Завдання полягає в тому, щоб написати програмне забезпечення та здати його на системні адміністратори для випуску продукції. Якщо вони все задокументували (і майте на увазі, що в більшості магазинів документація - це брудне слово), то випуски повинні бути нормальними.

У публічних компаніях тут, у США, ви маєте справу з SOX, HIPPA тощо. Більшість цих законів, що були забуті, насправді допомагають у цьому аргументі. SOX диктує розділення обов'язків, що вимагає від розробників тримати руки поза виробничими системами.