Domanda:
Masticato per aver fatto un backup
KirynDawn
2017-10-04 20:17:25 UTC
view on stackexchange narkive permalink

Sono un programmatore di tutti i tipi e, in parole povere, ho creato un modulo che gli utenti utilizzano per rivedere determinate informazioni e quindi approvarle o rifiutarle.

Oggi è stato il primo modulo rifiutato che abbiamo ricevuto . Il mio capo mi ha chiesto perché e ho rigurgitato i motivi che erano elencati nel modulo.

Poi ha voluto cancellare l'inserimento dei dati perché non forniva alcun valore (la sua opinione).

Ho espresso la mia opinione e ha sottolineato che letteralmente voleva solo ora sapere perché il modulo è stato rifiutato e l'unico modo per ottenere tale informazione era dai dati del modulo stesso.

Più tardi nel corso della giornata ho notato i dati del modulo è ancora nel DB, quindi ho fatto rapidamente un backup per questo, ho fatto sapere al mio capo che ho fatto il backup con il motivo che gli ho detto all'inizio della giornata. Circa un'ora dopo vengo chiamato nel suo ufficio e vengo masticato. Ha detto che fare il backup lo ha fatto incazzare e che ero solo un programmatore e, anche se le opinioni sono benvenute, azioni del genere non lo sono e che sono stato fortunato a farlo con lui e non con nessuno degli altri superiori.

Cosa diavolo è appena successo? I dati di backup si trovano sulla mia macchina locale nel file csv. Non su server che occupano spazio o altro (sono solo tre righe comunque)!

Non mi ha mai trattato così prima e sono trasparente su tutto ciò che tocco.

L'ho fatto hai davvero oltrepassato i miei limiti?

Posso fidarmi del mio manager?

È questo un primo segnale che vogliono che me ne vada e stanno per fare il pelo nell'uovo?

AGGIORNAMENTO: ho inviato una lettera di scuse colpendo tutte le possibili ragioni per cui mi sbagliavo. Le scuse sono state accettate ed è stato suggerito di andare avanti dalla situazione. Grazie a tutti per le vostre intuizioni, mi avete davvero aiutato qui.

AGGIORNAMENTO 2: un collega che conosceva la situazione ha ricevuto lo scoop interno dal capo. Ciò che li ha fatti incazzare è stata la connotazione delle mie parole nel mio ragionamento ... Il che è davvero fuori dal personaggio perché non ho mai avuto problemi prima con loro o con nessun altro. Dopo aver rivalutato tutte le risposte oggi, sono stato convinto di essere stato impostato per fallire.

Se fossi obbligato alla cancellazione dei dati chissà quali problemi sarebbero accaduti durante l'auditing (non so come vengono controllati i dati però). Molto probabilmente sarei stato io a incolpare dei problemi (l'ho visto accadere al programmatore prima di me).

Se avessi fatto il backup nel modo "corretto" invece di archiviarlo sarebbe comunque caduto sotto insubordinazione.

Voterò per chiudere questa domanda ora.

AGGIORNAMENTO 3: Poiché mi sono dimenticato di questo e rileggendo ci sono molte domande e speculazioni. Il manager è stato licenziato 1 anno fa. Non so perché, ma potrei sicuramente indovinare. Spera che questa affermazione porti una chiusura.

I commenti non sono per discussioni estese;questa conversazione è stata [spostata in chat] (http://chat.stackexchange.com/rooms/66685/discussion-on-question-by-kiryndawn-chewed-out-for-making-a-backup).
Avrai sicuramente sentito parlare del prossimo [Regolamento generale sulla protezione dei dati] dell'UE (https://en.wikipedia.org/wiki/General_Data_Protection_Regulation).Il GDPR non è qualcosa di nuovo, è solo lo snellimento e l'omogeneizzazione di direttive sui dati simili di molte nazioni.Considerando che i dati del modulo come quello possono essere considerati ** informazioni personali ** e che tali dati sono soggetti a una regolamentazione pesante, hai messo l'azienda a rischio di non conformità a tali normative.E se il modulo conteneva informazioni personali ** sensibili **, hai commesso un enorme no-no.
Solo per vedere se c'è un grande angolo di protezione dei dati qui: queste tre righe di dati che hai copiato in un file .csv di backup - sono state fatte copie degli stessi dati durante la discussione che hai avuto con il tuo capo a riguardo?Ad esempio, i dati di identificazione personale vengono visualizzati nelle e-mail o nei registri delle chat o altro?Se è così, e se il tuo capo non è preoccupato per quelli, allora * probabilmente * non è un problema di protezione dei dati, dal momento che sarebbe piuttosto brutto farlo con i dati soggetti alle normative sulla protezione.
Avrei fatto la stessa cosa perché questo manager si sta solo coprendo il culo con l'opinione onesta di qualcuno.Ti auguro il meglio nella ricerca di lavoro perché ovviamente sei migliore del tuo capo.Succede spesso.
Considerando che il tuo capo non ha fornito alcuna ragione tecnica, legale o logica per cui i dati non dovrebbero essere salvati, dubito che tu abbia fatto qualcosa di "sbagliato".Sembra che stia nascondendo qualcosa o stia cercando di mostrare i suoi muscoli politici.Probabilmente si sente come se stessi pestando le dita dei piedi.
Sarebbe utile sapere, e non hai menzionato, se i dati di questo modulo specifico possono essere considerati qualcosa come "feedback negativo".E non hai menzionato se contenesse informazioni "personali" o "riservate" o "protette".Se non fosse roba "segreta", avrei (forse / forse) inviato al capo un'e-mail del tipo: Su tua richiesta, ho cancellato il record # 12345 Data aaaa / mm / gg hh: mm: ss contenente i datiblah-blah-blah.Quindi lascia che le regole (e i regolamenti) di gestione della posta elettronica gestiscano quando è stato effettivamente eliminato.Probabilmente ti avrebbe comunque causato qualche problema.
@KevinFegan Non so se le persone che utilizzano le informazioni le considerano negative o meno.Le informazioni rientrano in una sorta di contratto di servizio condiviso
Sono contento che tu abbia concluso.Per quanto riguarda il backup dei dati nel database, se la tua azienda si preoccupasse di recuperare i dati, sarebbe stato eseguito il backup in un registro delle transazioni recuperabile da un amministratore di database.Ciò protegge non solo le righe di dati copiate, ma tutti i dati nel database.Il tuo ex supervisore avrebbe dovuto essere in grado di dirtelo.
Otto risposte:
HLGEM
2017-10-04 20:43:54 UTC
view on stackexchange narkive permalink

Non dovresti mai fare una copia personale dei dati di un database aziendale sul tuo computer.

Questo è un reato di licenziamento dove lavoro perché abbiamo dati considerati privati ​​o riservati.

È importante disporre di controlli interni per proteggere le informazioni del database. Hai dimostrato in questo caso che non puoi fidarti dei dati dell'azienda. Personalmente non ti permetterei mai più di accedere ai dati di produzione.

Certamente non dovresti fare tali copie dopo che il tuo capo ti ha detto di cancellare i dati perché questa è insubordinazione, anche un reato di licenziamento. Hai completamente torto e sei fortunato a essere ancora impiegato. Scusati e dì che non succederà più e significa che.

Per inciso, se hai un processo di rifiuto, dovrebbe essere definito nei tuoi requisiti su cosa succede quando i dati vengono rifiutati e ciò dovrebbe accadere automaticamente nel sistema senza alcun intervento manuale. Il fatto che tu non l'abbia fatto mi sembra molto strano. Devi scoprire qual è il requisito e implementarlo anche se non sei d'accordo. Non è tuo compito determinare i requisiti, è tuo compito implementarli.

Non avevo idea che fosse così serio. Per quanto riguarda quando un modulo viene rifiutato, questo è tutto, questa è la fine del processo del modulo ...
Risposta perfetta.Lavorando nel settore della sicurezza, una ragionevole quantità del mio tempo è dedicata alla disinfezione dei database per le PII in modo che gli sviluppatori possano lavorare con loro senza avere accesso a dati sensibili.
@PeteCon i nostri database non sono disinfettati.È come questa azienda ampia.Anche le PII sono esposte, ma da oggi penso che sarebbe una buona idea per me tenermi per me su cose del genere ...
@KirynDawn: Ci sono certamente aziende in cui è così grave.Ci sono aziende in cui la sicurezza è ancora più seria: ho lavorato per un'azienda della difesa.Ecco perché questo non dovrebbe preoccuparti: quando la sicurezza è così importante, non è una sorpresa.Per prendere la compagnia di difesa come esempio: ho avuto un briefing sulla sicurezza di due giorni prima che mi venisse assegnato un computer.E questo è stato disconnesso sia da Internet che dai dati reali (double air gap).E sono sicuro che nel caso di esempio di HLGEM, ci sarebbero stati anche sufficienti avvertimenti in anticipo.
In quanto programmatore, sono d'accordo soprattutto con l'ultima frase.Il mio non è ragionare sul perché, il mio è solo per fare ... e possibilmente suggerire un modo migliore.Lo hai fatto e ti è stato detto senza mezzi termini di non preoccupartene.Va bene, non hai mano se diventa a forma di pera a meno che tu non lavori per un boss *******, nel qual caso non dovresti essere lì.Fare copie personali è quasi sempre un'idea terribile.
Rispettosamente non sono d'accordo con questa risposta, in gran parte per il motivo addotto da @MSalters.Ma anche l'OP sta chiaramente e costantemente cercando di dare al capo ciò che vuole, non di ignorare il capo.Il capo ha detto: "non ha fornito alcun valore" (implicando una mancanza di importanza), poi si è arrabbiato (implica l'importanza).Lo definirei un fallimento nella comunicazione da parte del capo.
Una copia su una macchina da lavoro non è certo una copia "personale".
@EdmundReed: Se la sua esistenza non è documentata ufficialmente e se la sua creazione non è stata approvata dalla sicurezza (con una traccia cartacea appropriata), allora è abbastanza personale da essere considerata una violazione della politica di sicurezza.Lo scopo di tali politiche è garantire che le persone responsabili della protezione dei dati sappiano dove si trovano * tutte * le copie in un dato momento.E no, "forse alcuni sviluppatori lo hanno anche sulle loro workstation" non conta davvero come sapere dove si trovano i dati.
Questa risposta estrapola troppo da un altro posto di lavoro.Le regole sul posto di lavoro del PO non sono note.
@IlmariKaronen Se qualcosa non è "approvato" dalla sicurezza, ma non hanno intrapreso alcuna azione concreta per richiedere l'approvazione esplicita prima che il tentativo di un utente abbia successo, allora non sono molto competenti nell'implementazione dei controlli di sicurezza.Se il database è così importante, devono controllare l'accesso ad esso e, anche in questo caso, definire solo viste basate sui ruoli per gli sviluppatori e avere un database separato con dati di esempio su un ambiente di sviluppo, ecc. Formazione esplicita sulle implicazioni di sicurezza edovrebbe essere richiesto anche il trattamento dei dati.
Se questa risposta è vera (e potrebbe esserlo), allora anche il manager ha commesso un reato di licenziamento, poiché l'interrogante non avrebbe dovuto comunque essere autorizzato ad avvicinarsi ai dati sensibili senza adeguata formazione / briefing.Questo potrebbe in qualche modo spiegare perché il capo è così eccitato al riguardo, ma anche perché non lo licenzierà, dal momento che ammettere l'incidente gli costerebbe anche il lavoro.Personalmente penso che sia più probabile che i dati non siano (trattati come) così sensibili, e le risposte di Kozaky e Bill hanno maggiori probabilità di essere corrette, ma è una possibilità.
@ray: Concordo sul fatto che il PO avrebbe dovuto essere effettivamente informato sulle politiche di sicurezza pertinenti se avesse accesso a dati sensibili.Detto questo, ci sono situazioni in cui può essere ragionevole fidarsi degli sviluppatori con accesso diretto ai dati di produzione (dopotutto, * qualcuno * deve avere quell'accesso), ma comunque richiedere loro di non eliminare i backup non documentati sulle loro workstation.Ricorda che "sensibile" non significa sempre "classificato top secret";potrebbe semplicemente significare "sarebbe imbarazzante se i nostri concorrenti se ne impossessassero" o "dobbiamo eliminarlo dopo 1 anno per rispettare le leggi sulla privacy".
I dati aziendali di @Dominik sono sempre dati aziendali, mai tuoi.Lo chiami "backup", l'altro può chiamarlo "pirateria" e hai ragione entrambi.Alcune aziende non si preoccupano del valore dei dati in loro possesso, ma ciò non significa che sia un approccio ragionevole o prevedibile.Dico che sei tu che estrapoli troppo dal lavorare in luoghi di lavoro disattenti.Le regole "non prendere ciò che non è tuo da prendere" e "obbedisci al capo" non sono molto sorprendenti da aspettarsi senza un addestramento speciale, vero?
@Agent_L L'OP non ha mai piratato alcun dato.Per la pirateria dei dati, devono essere coinvolti malizia e profitto personale.Voleva solo usare il cervello per fare un buon lavoro, ma il suo manager gli nasconde alcune informazioni cruciali o cerca di essere fuori dai guai dai predatori di rango superiore.Sono d'accordo con te in generale, ma per favore smettila di mettermi le parole in bocca e di fare inferenze ingiustificate sul mio ambiente di lavoro.
Ho dovuto downvote."Non fare mai copie personali dei dati da un database" è semplicemente sbagliato.Non prendere dati privati o riservati, certo, ma hai fatto una dichiarazione generale "non copiare mai i dati" su tutti i dati del database.Questo è solo un cattivo consiglio, soprattutto perché OP ha affermato di essere un programmatore.Essendo dal punto di vista tecnico, ci sono molte cose che facciamo con i database che altri dipendenti potrebbero non fare.Copiare un sondaggio, che probabilmente era anonimo, non è un reato contro il fuoco in nessuna azienda ragionevole.
@IlmariKaronen Hai ragione, ma non è ragionevole ritenere lo sviluppatore responsabile di quello che sembra essere un chiaro fallimento del mgmt nell'addestrare adeguatamente lo sviluppatore su ciò che è (non) autorizzato a fare in un ambiente di produzione.Sarebbe come un agente di polizia che ferma le persone e distribuisce biglietti per eccesso di velocità / citazioni in un'area dove non c'erano mai segnali di limite di velocità per cominciare.
@Dominik - Sono d'accordo che OP non ha "piratato" i dati, ma la tua descrizione che "Per la pirateria dei dati, ci deve essere malizia e profitto personale coinvolti".è sbagliato / fuorviante.Se copi dati (CD di musica / software, libro, ...) e li dai via gratuitamente ad alcuni dei tuoi amici, non c'è "malizia e profitto personale" ma è ancora "pirateria" (violazione del copyright).
user34587
2017-10-04 20:36:58 UTC
view on stackexchange narkive permalink

A quanto pare, il tuo capo ti ha chiesto di fare qualcosa e non è stato fatto. Hai quindi deliberatamente fatto un passo per assicurarti che i dati esistessero ancora, anche se cancellati dal database (un passaggio di backup che sarebbe comunque avvenuto).

Come hai detto con i backup orari che hanno luogo in ogni caso, questi dati possono ancora essere recuperati in seguito, ma nel prendere il tuo backup personale dei dati "offensivi", il tuo capo potrebbe averlo interpretato come una consapevole sfida alle sue istruzioni. Hai oltrepassato i tuoi limiti? Forse, anche se sembra davvero che il tuo capo abbia reagito in modo eccessivo. A seconda di come hai svolto l'attività, ad alcune aziende potrebbe non piacere l'idea che i programmatori eseguano backup locali in quanto consente a un dipendente scontento un'altra strada per il contrabbando di dati fuori dall'ufficio. Un esempio estremo, ma di solito è la forza trainante di una tale politica. Prima di andare oltre, vorrei indagare in quali circostanze i programmatori sono autorizzati a eseguire backup al di fuori di quelli automatizzati (ad esempio, per testarli). Se hai violato inconsapevolmente una regola qui, potrebbe spiegare la reazione del tuo capo.

Puoi fidarti del tuo manager? Hai detto che non ti ha mai trattato così prima e presumo che anche l'osservazione "solo un programmatore" sia stata una tantum. Suggerirei di lasciare passare questo incidente poiché il tuo manager potrebbe essere ancora arrabbiato per qualche altro incidente quel giorno. Il suo masticare potrebbe essere stato perché se questo fosse davvero stato portato ai superiori, anche il suo lavoro sarebbe stato a rischio. Se il problema persiste per un certo periodo di tempo su altre questioni banali, potrebbe non essere un segno diretto che "vogliono che te ne vada", ma che le tue capacità saranno apprezzate meglio altrove.

"_con i backup orari che avvengono comunque, questi dati possono ancora essere recuperati successivamente_" Ma sicuramente il primo backup dopo che il record è stato cancellato sarà un backup del DB _senza record_.Anche se sono presenti nomi ciclici per i backup, probabilmente non passerà molto tempo prima che non ci sia ancora alcun backup contenente il record.
In Europa, OP potrebbe affrontare il carcere a seconda di ciò che è nei dati del modulo.O peggio, essere licenziato.
@Mindwin Sembra terribile.Da quel poco che sappiamo, sembra che il capo non stia tramando niente di buono, e posso facilmente vedere il dipendente fare il carcere per aver fatto ciò che il capo ha ordinato per coprire qualcosa.Così triste che qualcuno potrebbe rischiare il carcere per aver fatto la cosa morale, etica e onorevole non cancellando un record negativo.Sembra così al contrario.
[Lucida il tuo curriculum e corri alla porta] (https://workplace.stackexchange.com/questions/100086/chewed-out-for-making-a-backup/100089?noredirect=1#comment306638_100086) è il consiglio più validoin questi casi.
@Mindwin Per favore, espandi la tua affermazione che si può affrontare il carcere per aver tenuto una registrazione dei dati aziendali su un computer di lavoro - con che tipo di dati potrebbero verificarsi in quale giurisdizione?Anche il GDPR, che entrerà in vigore il prossimo anno, ed è molto più severo delle normative vigenti per quanto riguarda l'archiviazione e il trattamento dei dati, prevede solo sanzioni pecuniarie come punizione e avvertenze per i primi trasgressori.
@Mindwin E a seconda di ciò che è nel modulo dati OP potrebbe anche affrontare la prigione per * cancellarlo *.Le persone non si arrabbiano per cose così banali senza motivo.C'è una ragione per cui il manager voleva che tutte le tracce di questo record andassero via ...
@pilsetnieks Negli Stati Uniti, conservare qualsiasi PHI (informazioni sanitarie protette) su un personal computer può essere una violazione HIPAA.Tali violazioni, se riscontrate, possono effettivamente portare a posti di lavoro persi e multe piuttosto salate.Inoltre potrebbe esserci una politica aziendale contro il mantenimento dei dati di backup su una macchina senza backup.Immagino molti settori in cui le informazioni aziendali proprietarie vengono trattate in questo modo.(Si noti che non ci sono specifiche su quali utenti si riferisca)
Questa risposta fornisce una buona discussione del punto di vista generale della politica aziendale.Tuttavia dovrebbe davvero menzionare anche i problemi di devops / privacy.Secondo l'OP, hanno preso un'esportazione di dati di informazioni _customer_ da un database aziendale (presumibilmente sicuro) e l'hanno archiviato sul loro desktop come file .csv_ (presumibilmente molto, molto meno sicuro).È dubbio che il processo di backup automatizzato invii i suoi dati alla macchina dello sviluppatore, quindi non è davvero paragonabile.In breve, il PO ha gravemente violato le migliori pratiche di sicurezza / privacy, e anche questo _probabilmente_ ha contribuito a masticare.
Immagino che @Mindwin stia pensando a dettagli bancari, informazioni su persone vulnerabili, cartelle cliniche, codici di lancio nucleare ... quel genere di cose.Nota le specifiche, ma ho visto persone allontanarsi dai locali dalla polizia per aver memorizzato i dettagli della carta di credito.
Sì, in retrospettiva, se i dati erano di natura sensibile, posso capire che la reazione del manager potrebbe non essere stata esagerata.
Non ci sono scuse per chiunque ti tratti nel modo in cui ha detto né le cose che ha detto, capo o meno e indipendentemente dalle ragioni (entro i limiti ovviamente).Permetteresti a qualcuno di trattarti come ha fatto lui o di minacciarti?Non la penso così e il fatto che sia il tuo capo rende più imperativo che rimanga entro i suoi limiti e trovi il modo di comunicare con le persone con cui lavora / sotto in un modo che non includa "masticarti" o minacciaretu.Non hai 5 anni.Lo porterei alle risorse umane se non si ricevono scuse.
Bill Leeper
2017-10-05 01:29:23 UTC
view on stackexchange narkive permalink

Penso che le persone si stiano concentrando troppo sui dettagli di backup.

Ecco cosa penso sia successo e perché sei entrato in contatto con il tuo capo.

Lui / lei voleva per coprire questo feedback negativo. Ti è stato chiesto di distruggere queste prove, ma invece ne hai fatto una copia d'archivio.

Si tratta di qualunque impatto negativo questo modulo abbia sul tuo capo, non sui dettagli se un backup esisteva già, o se pensavi che il feedback fosse relativo.

Bingo.In casi come questo è meglio eliminare i dati e se in seguito si verifica un problema assicurati di avere un'e-mail o qualcosa per dimostrare che hai formalmente raccomandato di non intraprendere tale azione.
Forse c'era qualcosa nella forma che OP non ha notato, ma il capo l'ha fatto.Il capo può anche presumere che OP capisca perché il modulo non dovrebbe essere salvato, il che significa che fare un backup sembra uno sforzo consapevole per minare il capo.
Esattamente il mio primo pensiero e avrei risposto così se non l'avessi fatto.+1 Questa situazione è semplicemente bizzarra in circostanze normali e porta a una cattiva gestione da parte del capo.
Questo può essere vero, ma è principalmente speculazione.
@jpmc26 Quindi è la risposta attualmente più votata da HLGEM
Non c'è nulla nella domanda dei PO, o, per quanto posso dire, in ulteriori commenti di OP, che indichi che i dati del modulo in questione potrebbero essere classificati come "feedback negativo", o in qualche modo "negativi".Ma, se i dati fossero "feedback negativi", questo fatto sembrerebbe abbastanza importante da essere menzionato dal PO.Certo, avrebbe potuto essere negativo, ma non ci sono indicazioni che lo fosse.
Sto solo deducendo in base alla risposta ostile ricevuta.Le altre risposte qui indicavano che l'OP era probabilmente ragionevole, e lo era, a meno che non ci fosse qualche motivo per cui il capo non voleva queste informazioni.Quindi è logico che il capo non lo volesse.Solo il capo lo sa, ma in generale se ti viene data una direttiva specifica, purché non sia legale, dovresti seguirla
rath
2017-10-04 20:36:02 UTC
view on stackexchange narkive permalink

il backup dei database dei nostri dipartimenti viene eseguito automaticamente ogni ora

e

Nel corso della giornata [...] I fatto rapidamente un backup per questo [...] con il motivo per cui gli ho detto all'inizio della giornata

e

I dati di backup sono sulla mia macchina locale nel file csv. Non su server che occupano spazio o altro (sono solo tre righe comunque)!

Vediamo.

  1. Manager ti chiede di eliminare i dati che ritiene irrilevanti
  2. I dati esistono nei backup automatici e sono recuperabili
  3. Estrai manualmente le righe eliminate dal database nonostante (2)

Tu hanno oltrepassato i tuoi limiti . Penso che tu sappia (in fondo) non si tratta delle tre righe di spazio che il tuo backup sta occupando. Hai insistito per conservare i dati. Il tuo manager ha visto che mentre vai contro qualcosa su cui ha l'ultima parola.

Le scuse sarebbero in ordine.

Rispondere alle tue ulteriori domande:


  • Posso fidarmi del mio manager
  • È un primo segnale che vogliono che me ne vada e stanno per fare il pelo nell'uovo

Noi (beh, io ) non posso estrapolare da ciò che hai presentato qui per rispondere a nessuna di queste domande.

"I dati esistono nel backup automatico": se è presente un backup automatico e il capo elimina quel modulo prima che venga eseguito il backup, non viene eseguito il backup.
Invierò delle scuse con la nuova prospettiva che ho acquisito da tutte le risposte.Grazie.
@gnasher729 In questo caso sembra che [sia stato effettuato un backup] (https://workplace.stackexchange.com/questions/100086/chewed-out-for-making-a-backup/100088?noredirect=1#comment306460_100086), masì, generalmente è meglio assumere la legge di Sod.
Ma il tuo capo ha l'autorità per cancellare i dati?
@Neuromancer questo va oltre lo scopo della domanda.Dovremmo presumere in buona fede che tutto ciò che OP ha scritto nella Q è veritiero, a meno che non ci sia qualche errore logico o contraddizione nel testo Q.
@rath Penso che questo sia un cattivo consiglio, anche se non ho intenzione di -1.Questo è il tipo di comportamento che spesso degrada in grandi scandali se non viene risolto.OP non dovrebbe crollare.Andare agli uffici delle risorse umane e / o legali o di etica sarebbe più appropriato, se ti preoccupi di fare qualcosa.Per un problema così minore, non mi preoccuperei, ma se è abbastanza importante da fare qualcosa, prendi la testa del manager.Il manager _non dovrebbe richiedere al dipendente di cancellare questi dati_;in effetti potrebbe essere criminale.
@midwin il capo potrebbe essere un cattivo attore che copre i fallimenti per una serie di motivi
Per quanto riguarda la sicurezza dell'intero sistema, il fatto che tu abbia deciso unilateralmente di "fare il tuo backup" è la punta di un iceberg.Cosa succede quando in futuro crei * più * backup e poi inizi unilateralmente a * ripristinarli * perché hai deciso unilateralmente che potrebbe risolvere qualche problema appena sorto!Rispondi, caos incontrollato.IMHO il modo più semplice per risolvere questo problema è sbarazzarsi di persone con quel tipo di mentalità.Puoi supplicare "è stato un incidente, onesto" se vuoi, ma se fossi il capo non starei ascoltando !!
... E se affermi di non * mai * ripristinare il backup, allora la domanda "allora perché ti sei preso la briga di farlo?"non ha una buona risposta a cui riesco a pensare.Quindi, nella migliore delle ipotesi, prendi decisioni sbagliate o fai cose senza motivo, nessuno dei quali è comportamenti che probabilmente l'azienda vorrà nei suoi dipendenti!
La quantità di congetture nei commenti mi supera.Non sappiamo se i dati fossero riservati, se il gestore fosse autorizzato a chiedere la cancellazione, se l'OP volesse ripristinare successivamente i dati, o qualcosa del genere!Il manager potrebbe aver reagito in modo eccessivo, ma semplicemente non lo sappiamo.Concentrati sui dati che abbiamo, possiamo giocare a what-if tutto il giorno, ma non aiuta nessuno.
Eppure si tralascia completamente la reazione del manager che era fuori dai limiti e includeva la minaccia dell'OP e in realtà consigliava di scusarsi?Il manager verrebbe invece "masticato" dalle risorse umane in qualsiasi azienda che rispetti i propri dipendenti.
@Frisbetarian Per quanto possa essere vero, non rispondo al manager ma all'OP.
gnasher729
2017-10-04 21:00:18 UTC
view on stackexchange narkive permalink

Impossibile dire cosa sia successo senza molte informazioni sulla tua azienda. Le possibilità sono ovunque tra un capo incompetente in un viaggio di potere che fa del suo meglio per impedirti di svolgere correttamente il tuo lavoro e tu sei fortunato a non essere licenziato per aver duplicato informazioni top secret sui clienti. Chiamarti "solo un programmatore" mi farebbe supporre il 60% contro il 40% per il primo, che non significa molto.

BradC
2017-10-05 01:04:08 UTC
view on stackexchange narkive permalink

In qualità di amministratore di database, potrei sostenere che il record dovrebbe rimanere nella tabella del database, ma essere adeguatamente contrassegnato con uno stato di "rifiutato" o altro.

Ma questo è un progetto di applicazione decisione e potrebbe influire sul modo in cui vengono eseguite altre query e rapporti o richiedere un po 'di lavoro aggiuntivo per assicurarsi che nient'altro venga influenzato.

La chiave qui, tuttavia, è che hai già provato a spiegare il tuo punto di vista e il tuo capo ti ha annullato su questo. Non è una buona idea.

Come hanno indicato altre risposte, salvare i dati "di lato" come CSV sulla macchina locale potrebbe avere altre considerazioni sulla sicurezza.

Se ti avvicini correttamente, il tuo capo potrebbe essere disposto a considerare una soluzione intermedia, come scrivere il rifiuto nel log degli errori dell'applicazione (hai un log degli errori dell'applicazione, giusto?). Non tutti i campi, forse solo il nome, la data / ora e il codice di rifiuto / il messaggio di rifiuto o qualsiasi altra cosa.

rifiutati o approvati sono solo i campi della tabella.i moduli approvati salgono ulteriormente in un processo che non ho alcun coinvolgimento mentre i moduli rifiutati vengono completati
Infatti, in 25 anni di sviluppo di database e applicazioni, non mi sono mai imbattuto in una situazione in cui l'eliminazione fisica casuale fosse accettabile: l'eliminazione logica è quasi sempre preferita da una prospettiva di tracciabilità e responsabilità.Ovviamente, la pulizia e l'archiviazione dei dati avvengono, ma è tutt'altro che casuale.Tuttavia, l'archiviazione dei dati sulle workstation anziché sui server è spesso disapprovata.
user44108
2017-10-04 20:29:32 UTC
view on stackexchange narkive permalink

Qui presumo che siano stati eliminati i dati del modulo, non il modulo stesso.

Non sappiamo quali siano stati i motivi dell'eliminazione, ma sembra che sia un problema di qualità.

Sembra ragionevole che i dati di bassa qualità possano essere eliminati in quanto potrebbero influire negativamente sui rapporti statistici per le approvazioni / i rifiuti.

Se elimini la spazzatura, sei lasciati con dati di buona qualità da confrontare.

Se è così, allora l'eliminazione dei dati va bene.

Se la situazione è diversa dalla mia ipotesi, dovrai correggere me.

Sebbene come nota la risposta di Bill Leeper, in questo caso il criterio sembra essere che "dati di alta qualità" sia "feedback positivo che dice che stiamo facendo un buon lavoro fornendo ai nostri utenti ciò che vogliono" e "dati di bassa qualità" lo sono "feedback negativo dove i dati da noi forniti sono stati rifiutati ".Anche se è stato l'errore dell'utente, e in realtà i dati rifiutati andavano bene, è un po 'strano voler masterizzare una segnalazione di bug difettosa con il fuoco.Quindi, se l'obiettivo è che il rapporto statistico dica "100% di accettazione", l'interlocutore potrebbe avere ragione (anche se politicamente imprudente) a mettere in dubbio tale obiettivo ...
@SnarkShark ha scritto "potrebbe influire negativamente sui rapporti statistici ..." e "Se elimini la spazzatura, ti rimangono dati di buona qualità da segnalare". Mi sembra una menzogna.Trattenere dati che influiscono negativamente sui rapporti statistici è generalmente considerato molto, molto negativo e, a seconda di ciò che viene utilizzato, anche illegale.
@Aaron - non conosci il contesto qui o il motivo per cui il manager ha deciso di scartare questi dati.Potrebbe trattarsi di dati di test in cui vengono utilizzati valori di spazzatura.In tal caso, non vuoi che i dati dei test inquinino i tuoi rapporti.A questo punto, non abbiamo idea del motivo per cui il manager abbia scartato i dati, quindi non possiamo fare supposizioni.
@SnarkShark OP ha detto che proveniva da un modulo e sembra che l'input provenga da una persona;ciò non è garantito dalla formulazione di OP ma suona probabilmente in base alla formulazione.Potrebbero esserci alcuni casi specifici in cui il comportamento del manager era appropriato, ma sarebbero l'eccezione, non la regola.Quindi sono d'accordo con te - non lo sappiamo;ma in assenza di ulteriori informazioni, penso che "potrebbero essere dati di test spazzatura" è il presupposto non sicuro.Dovremmo presumere la buona fede da parte di OP, e se la tua ipotesi è corretta (cosa che potrebbe essere), allora OP omettere tali dettagli non è in buona fede
@Aaron Erano i dati di produzione.So che questi dati vengono controllati alla fine dell'anno.Tuttavia, non so come venga verificato.
ochhii
2017-10-05 14:22:22 UTC
view on stackexchange narkive permalink

Pur essendo d'accordo con @Kozaky, ha accettato la risposta. Penso che se avessi descritto meglio l'importanza di conservare questi dati, avresti potuto facilmente convincere il tuo capo in primo luogo. In qualità di programmatore, è tuo dovere fornire informazioni tecniche che descrivono l'importanza dei dati che ricevi.

Non vai troppo nei dettagli su ciò che avevi detto e il tuo commento sul fatto che stavi letteralmente per dirgli perché la domanda è stata rifiutata è completamente vero. Tuttavia, consiglierei ulteriormente l'importanza di conservare questi dati "rifiutati":

  • Supponiamo che la tua azienda veda un calo delle domande approvate. Avere una buona fonte di dati per le domande rifiutate può aiutare la tua azienda ad adattarsi ai problemi dei suoi clienti e forse ad espandersi in un'area che altrimenti non conoscerebbero (offrendo un nuovo servizio a questi candidati rifiutati).
  • Oppure, forse i candidati vengono rifiutati a causa di un punteggio di credito basso (non conosco il tuo modello di business, ma sto tentando di fare un esempio reale), la tua azienda potrebbe essere in grado di vendere i dati dei clienti ad altre aziende che vendono credito servizi di costruzione.

Senza sapere quale servizio stai fornendo è difficile da consigliare, ma spero che questi esempi ti aiutino in futuro.

È responsabilità del programmatore assicurarsi che gli utenti possano utilizzare i programmi (in questo caso, rivedere i moduli) correttamente.Non sono troppo sicuro che l'eliminazione dei dati sia affare del programmatore.
Mi dispiace, sono confuso sul punto che stai facendo.Sono d'accordo che l'eliminazione dei dati non è affare del programmatore, spero che questo non sia ciò che hai letto dalla mia risposta perché non potrebbe essere più lontano da ciò che intendevo fare con la mia risposta.
Il punto è che la conservazione / eliminazione dei dati è una decisione del manager.Il programmatore non dovrebbe interferire.I tuoi due proiettili non hanno significato.
Gli sviluppatori di @scaaahu di solito hanno la capacità e persino la necessità di prendere decisioni sulla conservazione dei dati, quindi è prima responsabilità del programmatore.Quanto al fatto che il gestore abbia l'autorità di ordinare a uno sviluppatore di cancellare i dati per i motivi forniti in questione, dipende dalla situazione;non puoi semplicemente dire "è una decisione del manager".Anche se il manager decide, * È * compito del programmatore discuterne con il manager.Non discutere con il tuo manager quando pensi che stia commettendo un grosso errore è segno di un posto di lavoro terribile e disfunzionale.
Ho dovuto fare +1 su questa risposta e non capisco il punteggio negativo.A meno che non abbia saltato qualcosa, questa è stata una delle risposte migliori con il suo "Dovresti provare a convincere il tuo manager".Questo _ ** è davvero qualcosa che il dipendente DOVREBBE fare ** _."Sì-uomini" sono cattivi dipendenti.Un dipendente che non cerca mai di convincere il proprio capo di nulla e non ci ha mai nemmeno provato almeno una volta è un dipendente che potrebbe non valere tanto.


Questa domanda e risposta è stata tradotta automaticamente dalla lingua inglese. Il contenuto originale è disponibile su stackexchange, che ringraziamo per la licenza cc by-sa 3.0 con cui è distribuito.
Loading...