Uno sviluppatore dovrebbe rifiutarsi di accedere al server di produzione? [chiuso]

Dipende. Ecco il meta principio. Se sei in una piccola azienda e c'è un problema e ti stai rifiutando di risolverlo, allora il tuo comportamento tuo è diventato un problema.

Ora la domanda è quale problema hai.

1. Il problema è che le modifiche alla produzione devono essere apportate e tu sei quella disponibile?
2. Il problema è che non sai davvero come eseguire l'attività?
3. O il problema è che qualcuno stia cercando di usarti come porta di servizio per fare qualcosa che qualcun altro pensa che non dovrebbe accadere?

Decidi velocemente.

Se è il primo, allora quello che dovresti fare è eseguire il compito, documentare attentamente mentre vai a ciò che hai fatto, e poi inviarlo a chiunque, idealmente dovrebbe aver fatto quel lavoro, possibilmente lungo con il tuo commento che ti senti fuori dalla tua profondità e questo è rischioso. Sentiti libero di cedere a qualsiasi persona che pensi sia qualificata per avere un'opinione su quello che hai fatto. C'è la possibilità che tu riceva un feedback che ti aiuti a farlo meglio la prossima volta.

Se è il secondo, quindi misura due volte, taglia una volta. Questa è un'opportunità di apprendimento, trattala come una cosa. E invia un'email come quella sopra descritta cercando feedback e consigli su come farlo la prossima volta.

Se è l'ultimo, allora dovresti dire: "Così e così è responsabile per questo, e non voglio creare un problema perché non so su che altro starei calpestando". E poi rimani saldo sul fatto di passare il tempo.

Se hai dei dubbi, commetti un errore nel far eseguire immediatamente l'operazione dopo aver inviato gli avvisi di cui hai bisogno. Di solito non rovinerete (troppo male) e questo risolve un ovvio problema immediato. Se la tua azione si rivela sbagliata, la colpa tende ad essere facile da deviare. (A meno che tu non sia in un'organizzazione tossica, nel qual caso l'unica scelta che funzionerà a lungo termine è ottenere un lavoro migliore.)

Sei in qualche modo in forma o in forma Responsabile di qualsiasi azione che deve essere eseguita "come root" sul server di produzione?

Se è così, allora sei pesante.

• Prendi possesso di un componente aggiuntivo della shell che registra tutto ciò che digiti in un file - in questo modo, almeno avrai una registrazione di come hai rotto,
• Chiedi a qualcun altro di guardarti alle spalle prima di premere qualcosa di circolare e vagamente rosso ( specialmente se lampeggia in qualsiasi modo),
• Notifica a chiunque si occupi delle disposizioni sulla sicurezza aziendale di avere questo livello di accesso (e permetti a loro di chiederne il motivo) - potrebbe creare un nido di vespe per il tuo capo,
• Analizza i modi per ridurre al minimo il rischio che tu possa causare alcun danno: cosa devi fare in qualsiasi altro modo (o da qualcuno / qualcos'altro)?
  Automazione: fare le cose in modo affidabile, allo stesso modo, ogni volta, è una cosa meravigliosa.
• Preparati per il peggiore quando succede.

Se in realtà non hai bisogno di questo livello di accesso, qualcuno deve portarlo via da te.

Il principio del minimo privilegio non si applica solo al codice dell'applicazione; si applica ugualmente bene alle persone. Sei veramente ti vuole in grado di vedere il loro stipendio? Lasciando che "scivolare" nella conversazione potrebbe molto bene ottenere le cose rotolando.

Evita l'interazione solo se ...

Evitare completamente il server di produzione è solo pratico se:

1. Fornisci al cliente un modo indolore per aggiornare il software e sei disposto a fornire una formazione per mostrare loro come procedere.
2. Gli aggiornamenti sono tali che il client può eseguirli a loro piacimento. Se si richiede loro di eseguire un aggiornamento per scappatoie di sicurezza nel software, potrebbero non volere / essere in grado di farlo e devi renderne conto.
3. respingi la possibilità di avere accesso in qualsiasi modo. Una delle implicazioni legali dell'essere in grado di accedere al server di produzione è che si può essere accusati letteralmente di qualsiasi tipo di problema a cui si ha accesso. Rimuovere questa possibilità è fondamentale per rimuovere la responsabilità legale.

Tuttavia, i vantaggi di evitare completamente il server di produzione si applicano solo se l'intera azienda è d'accordo. Se tu, il programmatore, decidi che questo è l'approccio migliore e Bob, il programmatore interno non è d'accordo e ignora la tua attenzione, alla fine non hai ottenuto nulla, tranne potenzialmente alcune ceneri di sigarette nel tuo caffè mattutino in ufficio. In altre parole, se questa non è una politica aziendale, questo è ciò che deve cambiare, non tu personalmente. Puoi menzionare questi punti al tuo capo, tuttavia, se la tua azienda non è a bordo, devi in definitiva interagire con il server di produzione.

Alcuni consigli utili se è necessario

Se devi interagire con il server di produzione, ho abbastanza esperienza per citare alcuni suggerimenti:

• FARE il backup prima di fare qualsiasi cosa che possa manipolare il database. Più recente, meglio è. Se dovesse succedere qualcosa e tu avessi un backup di un giorno, starai ancora nella sh * t, ma almeno non verrai licenziato. Prendi una copia da mezz'ora fa e potresti persino uscirne incolume.
• FARE avviso prima di eseguire qualsiasi attività sul server di produzione. Se questo dovesse essere un problema legale, mentre questo non è una prova evidente che non si tocca il server senza un avviso, è una buona argomentazione a tuo favore. Se invii un'e-mail, assicurati di recuperare un indicatore che il cliente ha letto.
• contattare il proprio cliente quando sarebbe opportuno eseguire aggiornamenti / verifiche. Hai solo bisogno di farlo una volta sola, per avere un'idea generale delle ore (ora di pranzo o quant'altro). Assicurati di inviare una conferma degli orari comunicati per telefono per iscritto in una e-mail, e assicurati che il tuo cliente abbia ricevuto e-mail (a volte le e-mail falliscono ancora).
• NON eseguire modifiche sul database che non è possibile invertire. Sì, hai un backup, è vero, ma come reagirebbe il tuo cliente se fossi costretto a dirgli che l'unico modo per tornare a uno stato precedente era quello di cancellare tutti i dati per quel giorno? Ancora più importante, come reagirebbe il tuo capo a te dicendogli che dovresti cancellare i dati di produzione del cliente per quel giorno? Se non c'è altro modo, puoi sempre scegliere NON per farlo. È sempre possibile trasferire i dati nei database locali per replicare i problemi (presupponendo ovviamente che si abbia l'approvazione). Non ci dovrebbero essere scuse qui.
• NON lasciare dati indesiderati sul database. Questo è un corollario alla dichiarazione di cui sopra. Se hai creato un nuovo record per testare qualcosa, anche se questo potrebbe non avere alcun impatto sul funzionamento del programma, il client può ancora vederlo. È completamente poco professionale come programmatore e fa sembrare alla tua azienda che vendi cioccolato e anche software sul lato.

Probabilmente già conosci questi punti o non ti chiederei se è una buona idea modificare il server di produzione, anche se forse questa risposta potrebbe aiutarti a formulare una sorta di politica aziendale per ciò che riguarda l'interazione con il server di produzione .

Spero che ti aiuti!

La domanda di "dovrebbe" trova la sua strada in una serie di altre situazioni. Nel mondo di devops dove i programmatori prendono ciò che viene visto come tradizionalmente ruoli IT, la linea ottiene molto sfocato. In altri mondi come banche o qualsiasi cosa che gestisca denaro (o assistenza sanitaria e hipaa), la domanda è un clamoroso "no" senza ulteriori elaborazioni necessarie.

Vediamo come una di quelle aree di gestione del denaro lo gestisce. Il PCI DSS (settore della carta di pagamento (ad esempio: Visa, Mastercard e simili) Data Security Standard) ha alcuni punti specifici su questo argomento.

Ci sono requisiti specifici nel DSS come 3.5.1:

Restrict access to cryptographic keys to the fewest number of custodians necessary.

o 6.4.2:

Separation of duties between development/test and production environments

Quest'ultimo in particolare parla di ciò che stai chiedendo e nella sezione di orientamento si legge:

Reducing the number of personnel with access to the production environment and cardholder data minimizes risk and helps ensure that access is limited to those individuals with a business need to know.

The intent of this requirement is to separate development and test functions from production functions. For example, a developer may use an administrator-level account with elevated privileges in the development environment, and have a separate account with user-level access to the production environment.

Questo significa che se stai indossando un cappello per sviluppatori, non dovresti avere accesso amministrativo nell'ambiente di produzione. Un può sostenere che è possibile cambiare cappelli (e tutti gli ambienti associati - ecco "sei in chiamata e avere un computer con accesso amministratore su cui non si fa sviluppo - e non fare cose amministrative da la tua macchina di sviluppo. "), ma questo entra nel modo in cui la direzione vuole affermare di soddisfare i requisiti.

Quindi, gli sviluppatori dovrebbero avere accesso alla produzione? Sicuramente, la lettura di registri e simili è molto utile e una sofferenza dover passare attraverso le organizzazioni IT e / o operative per ottenere l'accesso. Gli sviluppatori dovrebbero avere admin l'accesso alla produzione? Dipende da cosa stanno facendo e da cosa dicono i vari regolamenti.

Se sei in un piccolo negozio che non ha il personale, o l'infrastruttura, o il requisito che non hai accesso, è probabile che tu ti trovi con l'accesso di amministratore no mater se piaccia o no e si chieda di fare cose di admin su di esso di volta in volta.

Dipende veramente da dove ti trovi e da quanta burocrazia c'è per proteggere la produzione dagli sviluppatori (perché ci sono poche cose divertenti come spingere accidentalmente il codice o modificare il codice live in produzione).

La vita di qualcuno che ha accesso alla produzione è sempre "interessante".