SysAdmin & Developer: responsabilità [chiuso]

Quando si tratta di qualcosa come un server web di produzione, qual è la migliore pratica per le responsabilità per l'amministratore di sistema e lo sviluppatore? In particolare, sto pensando di aggiornare / installare il software. (A mio avviso, lo sviluppatore non dovrebbe avere accesso root sul server di produzione.)

Quindi un server Web di produzione esegue Wordpress e deve essere aggiornato all'ultima versione. Chi è responsabile di mantenerlo aggiornato?

Cosa succede se gli sviluppatori hanno plug-in personalizzati o file core personalizzati sull'app (in questo esempio, WP)?

Ho scoperto che nella maggior parte dei casi, se TU sei il responsabile del server fisico, è meglio NON dare l'accesso root agli sviluppatori.

Questo è un po 'un dibattito sulla "guerra santa" poiché sono sicuro che troverai sviluppatori che non sono d'accordo. Sono stato personalmente su entrambi i lati del dibattito.

Il mio ragionamento PRINCIPALE per non dare agli sviluppatori (anche sviluppatori fidati al 100%) l'accesso è perché più spesso c'è qualche pacchetto di cui hanno bisogno per far funzionare correttamente XYZ. Vanno avanti e lo installano ... o riconfigurano qualcosa che è già in atto in modo che funzioni ... o ... beh ... hai capito.

Passano i mesi ... il server deve essere reinstallato o ricreato ... e all'improvviso nessuno sa perché "Funziona sul vecchio server ma non su quello nuovo".

La risposta ovviamente è che la documentazione che stai guardando non include tutti quei piccoli pacchetti e modifiche che gli sviluppatori hanno fatto per far funzionare il sistema la prima volta.

Può essere una seccatura in un $$ per entrambi i lati ... ma se l'amministratore di sistema è responsabile per il server, i pacchetti e la documentazione ... e lo sviluppatore è responsabile dello sviluppo e del software ... Penso che tu " Scoprirò che ne è valsa la pena alla fine.

Se lo sviluppatore ha bisogno di un plug-in, un modulo, una configurazione, un tweak personalizzati ... nessun problema ... fallo per loro ... ma DOCUMENTI IT in modo da poterlo riprodurre la prossima volta.

Regola d'oro : non lasciare che i non amministratori tocchino qualcosa che non desideri venga infranto e per il quale sarai ritenuto responsabile.

Gli sviluppatori dovrebbero avere accesso a un ambiente di test. Una volta che il loro lavoro è pronto per essere inserito nella macchina di produzione, dovrebbe essere consegnato all'amministratore di sistema. Se gli sviluppatori hanno fatto il loro lavoro e documentato correttamente la procedura, tutto andrà bene. In caso contrario, hanno bisogno che i loro lati posteriori vengano calciati per non eseguire adeguatamente i test.

Sono stato anche in questa battaglia. La mia risposta è che chiunque sia responsabile del tempo di attività del server è colui che dovrebbe essere responsabile di tutti gli aggiornamenti, modifiche, ecc. Ecc. Nessun altro utente dovrebbe essere in grado di eseguire questi tipi di funzioni sul server. Se il tuo compito è assicurarti che il server sia attivo e funzionante e se il capo ti ritiene responsabile e responsabile del server, è tua responsabilità mantenerlo e proteggerlo.

La maggior parte degli sviluppatori ti dirà che hanno bisogno dell'accesso a livello di amministratore al server e la maggior parte di loro non sarà d'accordo con me, ma sono io quello che deve riavviarlo alle 2 del mattino quando si blocca, deve ricostruirlo dopo un aggiornamento non riuscito, i tempi di inattività sono addebitati al mio dipartimento, ecc. ecc. Devo rispondere al CIO per tutto ciò che influisce sul nostro SLA, quindi sono l'unico a ottenere l'accesso a livello di amministratore al server e Sono responsabile di tutti i componenti, aggiornamenti, modifiche, ecc.

Sono d'accordo al 100%. Gli sviluppatori non sono per lo più consapevoli di come funzionano le cose di Syadmin. Se hanno bisogno di qualcosa, ti chiedono, tutto qui. Pensi a come e quando e consegni loro un pacchetto utilizzabile. (come se avessero bisogno di inviare e-mail, TU sei tu a configurare postfix). Inoltre, tenderanno a pensare che nella maggior parte dei casi, l'accesso alla radice farà funzionare le cose se non sono in grado di farlo con un accesso normale. Sono d'accordo con gli altri qui, non saranno con te alle 2 del mattino quando vedrai un problema. Ho avuto il caso poche settimane fa, uno sviluppatore voleva aggiornare il suo wordpress. Gli ho detto al log delle modifiche di RTF, per lui, che era inutile, il processo di aggiornamento è realizzato attraverso una bellissima interfaccia. Bene l'aggiornamento non ha funzionato, ho salvato la sua applicazione, non ho creato lo script di backup. Senza di me non avrebbe potuto ripristinare il sito.

C'è una tendenza a confondere la distinzione tra sviluppo e operazioni. Rendi i tuoi sviluppatori amministratori di sistema e i tuoi sviluppatori amministratori di sistema.

In questo senso, wordpress potrebbe trarre vantaggio da alcuni lavori sulla creazione automatica (e programmatica) di blog. Molti utenti di wordpress mantengono più di qualche istanza di WP / WPMU e aggiornarli tempestivamente è almeno ingombrante.

Puoi trovare una bella (e divertente) panoramica della filosofia nelle diapositive Agile Infrastructure di Agile 2009

Gli sviluppatori non dovrebbero avere radici nella produzione; tutti tranne gli sviluppatori sono d'accordo su questo. Ma gli sviluppatori possono in qualche modo avere la loro torta e mangiarla anche loro. Sono un po 'sorpreso che nessuno abbia menzionato esplicitamente questo:

Uno dei miei lunghissimi clienti di piccole imprese ha un sito Web con un'installazione Drupal, diversi siti WordPress, un forum SMF e poche altre app Web casuali. Sono l'amministratore delegato del contratto (e per motivi storici aggiorno / hackero WordPress e SMF quando necessario) e il mio cliente ha il suo contratto Drupal sviluppatori. L'ambiente è costituito da diverse macchine virtuali VMware su un provider di cloud pubblico.

Gli sviluppatori vogliono davvero avere l'accesso come root e ne hanno bisogno. È loro responsabilità scrivere le regole di riscrittura di nginx per far funzionare tutte le loro cose Drupal personalizzate, per esempio. Ma al diavolo non sto dando loro l'accesso root sul server di produzione, e il mio cliente è d'accordo con me su questo.

Quindi abbiamo compromesso: ottengono l'accesso come root sul server Web di prova (che è generalmente identico alla produzione tranne che per il suo indirizzo IP e si trova sullo stesso cloud). Che, come la produzione, ha etckeeper in modo che io possa vedere tutte le modifiche necessarie per apportare e tutti i pacchetti che hanno installato. Posso quindi portare i cambiamenti in produzione o dire loro cosa c'è che non va in quello che vogliono fare. E se hanno fatto un casino (non l'hanno ancora fatto, grazie a Dio) posso facilmente ripristinare le loro modifiche.

Non hanno alcun accesso al server del database di produzione; non hanno nemmeno accessi utente. Solo io e il mio cliente.

(La stessa app Web, si distribuiscono direttamente con Git, e se la rompono, riescono a risolverlo e spiegano al mio cliente perché dovrebbero continuare a essere i suoi sviluppatori. Anche se il mio client mi avrebbe CC su tale e-mail in modo che potessi ridere di loro o facepalm.)

Root == Amministratore di sistema.

Utenti == Sviluppatori, DBA o Utenti.

La radice non conosce sospensione quando un server è inattivo, root protegge gli utenti da se stessi, root protegge i dati degli utenti dalla rete, root mette la salute del server al di sopra di tutti gli utenti. Il culo di Root è in linea quando il server è offline. Server felice, root felice!

Motivi comuni per i tempi di fermo non programmati: utenti, modifiche non documentate nell'ambiente e backhoes. I server fanno esattamente ciò che viene loro detto che non si rompono casualmente. Gli hacker che chiedi, non è se, è quando ... quindi la necessità di una "radice".

00:33 CDT sai dove sono i tuoi backup e documenti di disaster recovery? :-p

Gli amministratori di sistema dovrebbero avere accesso come amministratore (proprio come dice il titolo). Nessun altro ha bisogno di accedere ai server di produzione. Se gli sviluppatori devono risolvere un problema su un sistema di produzione, tale problema dovrebbe essere riproducibile nell'ambiente di sviluppo. In caso contrario, possono sedersi con l'amministratore di sistema e guardare attraverso il sistema.

Agli sviluppatori non piace non poter toccare la produzione, ma non c'è lavoro. Il compito è scrivere il software e consegnarlo ai amministratori di sistema per una versione di produzione. Se hanno documentato tutto (e tenere presente che nella maggior parte dei negozi la documentazione è una parolaccia), le versioni dovrebbero andare bene.

Nelle aziende pubbliche qui negli Stati Uniti, hai a che fare con SOX, HIPPA, ecc. La maggior parte di questi regolamenti dimenticati aiuta in realtà con questo argomento. SOX impone la separazione dei compiti che richiede agli sviluppatori di tenere le mani lontane dai sistemi di produzione.