Fehler in der IT Datenverlust ?

[TooMuchCoffeeMan]

vor 6 Minuten schrieb OkiDoki:

Meiner Kenntnis nach ist das auch außerhalb der EU, nur für bestimmte Länder, mit den von dir beschriebenen Punkten möglich. Nur gibt es statt der AVV eine SCC (Standard Contractual Clauses). 

Jain. Die DSGVO ist so konstruiert, dass prinzipiell erst einmal jedes Land außerhalb der EU so eingestuft wird als gäbe es dort kein angemessenes Datenschutzniveau. Man muss sich als Unternehmen also versichern, dass das Niveau des Datenschutzes bei dem Dienstleister im EU-Ausland dem identifizierten Risiko gemäß als ausreichend anzusehen ist. Das muss man der Aufsichtsbehörde im Zweifel auch schriftlich nachweisen können. Artikel 44-50 der DSGVO sind hier interessant. Einen AVV oder in dem Fall DPA (Data Protection Agreement) muss man natürlich trotzdem abschließen.

[OkiDoki]

vor 29 Minuten schrieb TooMuchCoffeeMan:

Jain. Die DSGVO ist so konstruiert, dass prinzipiell erst einmal jedes Land außerhalb der EU so eingestuft wird als gäbe es dort kein angemessenes Datenschutzniveau.

Es gibt für einige Länder Beschlüsse der EU-Kommission d.h. das trifft so nicht auf jedes Land zu, sondern eben nur für die Länder bei denen es keine eigenen Regelungen.

Ich glaube aber, dass es hier viel zu OffTopic wird. Schreibe aber gerne weiter per PN darüber, da ich die Diskussion sehr interessant finde.

 

Edit: Sorry hab was durcheinandergebracht ... mit den DPA hast du natürlich recht.

Bearbeitet 28. September 2020 von OkiDoki

[Kellerbräune]

Am 28.9.2020 um 08:34 schrieb TooMuchCoffeeMan:

Letztendlich ist es allerdings auch eine Haftungsfrage. Du bist nämlich als Auszubildender kein vollwertiger Mitarbeiter. Die Verantwortung für dein (nicht grob fahrlässiges) Tun und auch deine Fehler trägt dein Ausbilder / Vorgesetzter. Natürlich gibt es trotzdem einen ordentlich Anschiss wenn du einen großen Fehler gemacht hast, aber du bist eben der Auszubildende und weißt es im Zweifel vielleicht gar nicht besser. Durch Fehler lernt man manchmal mehr als durch stures Lernen.

 

 

  Moin, ich glaube ich habe mich da falsch ausgedrückt. Mir ist klar, dass ich während meiner Ausbildungszeit keine "Verantwortung" zu tragen habe. Egal, ob ich einen kompletten Betrieb lahmlege, in dem ich z.B. den Server zwecks Unwissenheit außer Gefecht setze oder ich versehentlich beim Tausch der Platte, das Backup oder die Datenbank "zerschieße", da meine Vorgesetzten / Ausbilder während meiner Ausbildungszeit, meine Arbeit "kontrollieren" müssten. However, mir ging es eher darum, dass wenn ich einen Fehler gemacht habe, diesen lieber einmal zu viel melde, egal ob Folgeschäden oder gar keine Folgeschäden entstehen werden. Lieber einmal zu viel, als zu wenig. 

Selbst die minimalen Kleinigkeiten sollten bei Unsicherheit gemeldet werden, egal wie die Geschichte ausgeht. Im besten Fall war es falscher Alarm und man bekommt eine kurze Erklärung dazu. Selbst wenn etwas passiert, gibt es Anschiss, aber auch hier eine Erklärung für die Zukunft. 

Bei meinem ersten Vorfall habe ich das nicht gemeldet, ging "nur" um eine defekte Tür. Als mein Chef es bemerkte, war er eher zornig darüber, dass ich es nicht meldete. Ich sagte ihm, dass ich bissel Panik davor hatte, aber als er mir die Hintergründe erklärte, was alles passieren kann, war mir klar, ich hätte mal... 

Als ich versehentlich einen "Datenschutzvorfall" ausgelöst habe, habe ich das sofort gemeldet. Anfangs hatte ich deutlich mehr bammel gehabt. Sind schließlich keine Peanuts. Nach einer ausführlichen Schilderung an meinen Chef / Vorgesetzten, wie das ganze passiert war und ich es nicht wusste, dass das so nicht in Ordnung ist, obwohl wir geschäftliche Partner sind, habe ich eine ausführliche Erklärung und tieferes Know-How erhalten und eine mündliche "Rüge" mit der Bitte, besser aufzupassen. 

Selbiges war, als nach meinem vor Ort Einsatz schlagartige Netzwerkprobleme im 24x7 Produktivbetrieb aufgetreten sind, die kurz vor Feierabend gemeldet wurden. Habe den Fall direkt gemeldet, mein Einsatz geschildert, mein Vorgesetzter war am späten Abend vor Ort, da der Kunde ziemlich sauer war und was war es? Nicht mein Fehler. Netzwerkkarte war defekt. 

Fazit und worauf ich hinaus wollte;

-> Ich finde es wichtig, dass man zu seinem Fehler steht und falls man unsicher ist, lieber einmal mehr bescheid sagen, als zu warten

-> Das zeigt deutlich charakterliche Stärke.

-> Die Folgen sind meistens schlimmer, wenn man es nicht meldet. 

 

[Velicity]

Am 26.9.2020 um 16:29 schrieb Max112:

Ist euch als IT Mitarbeiter schonmal ein "großer" Fehler passiert und Daten sind entweder verloren gegangen oder irgendwelche Server sind kaputt gegangen wo wichtige Daten drauf waren ?

Jap, ein TRUNCATE auf eine wichtige Tabelle in der Produktion. Auf zu viele Baustellen gleichzeitig getanzt, mal davon ab, dass unser Rechtekonzept zu wünschen übrig lässt und jeder überall DBA ist. Durfte quasi im anderen Fenster alle paar Sekunden auf Zuruf ein paar unterschiedliche TRUNCATEs ausführen, während ich zwischen zwei aktiven Supportfällen hin- und her getanzt bin und hatte da eben das falsche Fenster offen und den Dritten erzeugt..

Am 26.9.2020 um 16:29 schrieb Max112:

Ich weiß kein Backup kein Mitleid aber mich würde Mal interessieren wie ihr damit umgegangen seit und euer Vorgesetzter oder Chef ^^ 

Nun ein geradeaus Backup gab es da auch nicht, womit man das auf die Schnelle hinkriegen würde, zumal neben dieser Tabelle noch Unmengen an Änderungen am System stattfinden und ein TRUNCATE zerschießt leider auch die Tabellendefinition, womit sowas ala ein Fixer INSERT eines SELECT .. AS TIMESTAMP OF, sprich ein Flashback Query ebenfalls flach fällt. Glücklicherweise war es Freitag Abend und der Kunde wollte quasi eh in 10-15 Minuten Feierabend machen.

Wie ich damit umgegangen bin? Chef telefonisch gesagt was passiert ist, noch am gleichen Abend, nicht dass ihn jemand kundenseitig anruft und er keine Ahnung hat worum es geht. Und dann eben zwei All-Nighter am Wochenende und den Stand wieder per Hand repariert. Sprich ein Mix aus AUDIT Tabellen, der Sicherung des Vorabends, Schlussfolgerungen bzgl. der Daten, aufgrund von Daten die gleichzeitig in andere Tabellen geschrieben werden usw. Und dann eben ein paar Euro in unser dafür vorgesehenes Sparschwein, womit dann bei genug Inhalt mal zu Mittag gegrillt wird.

Man lernt dazu, nicht dass sich was an unseren Rechtekonzept oder Backupkonzept geändert hätte, was eigentlich der richtige Weg wäre, neben dem ganzen Multitasking aber das hat sich schon eingebrannt, so dass ich persönlich sehr viel vorsichtiger bin. Die Auswirkungen waren wie gesagt, vor allem aufgrund des Zeitpunkts sehr gering, hätte auch anders laufen können. So waren die Auswirkungen weit unter dem, was quasi bei größeren Updates oder durch Bedienerfehler regelmäßig auftritt, von daher hat da kein Hahn nach gekräht. In Summe hat es mich wohl am meisten gestört, weil es echt ein verdammt blöder Fehler war.

Und ja, natürlich waren in dem Fall nicht Daten wirklich komplett verloren, weil sie sich eben wieder herstellen lassen konnten. Ändert aber denke ich nix am Ablauf. Schauen was man machen kann, kommunizieren, dass man verkackt hat. Ggf. hat jemand anders eine Lösung, die man nicht auf dem Schirm hatte. Ansonsten sind Fehler aber wohl menschlich, häufig hängen sie mit falschen Abläufen zusammen, die man dann noch mal angehen kann und solange wir nicht von Personenschaden reden, ist das denke ich auch nicht der Weltuntergang.

Bearbeitet 1. Oktober 2020 von Velicity

[Rabber]

Ich bin so frei und behaupte, dass so etwas schon jedem passiert ist, der länger in der IT arbeitet und das nicht nur in der Backoffice-Entwicklung, sondern auch direkt beim Kunden oder auf dem Live-System. Das bleibt einfach nicht aus, gerade in den ersten Jahren.

[treffnix]

Fehler sind menschlich, alles ganz normal. Wichtig ist eher die Kommunikation drumherum, als das der Fehler passiert ist.

Unsere Firma bietet ein ERP als Standardbranchenlösung an. Ich betreue Kunden, die nicht den Standard bekommen, sondern besonders viele Eigenentwicklungen. Wäre nicht das erste Mal, das da etwa schief geht in der Live-Umgebung, eventuell habe ich da auch schon den ein oder anderen Stillstand verursacht.. 👀

[allesweg]

Stillstand, Systemauslastung, Ausgabeloops (auch auf Durcker), ... passiert immer mal wieder. Ganz verhindern kann man das nie. Nur die Eintrittswahrscheinlichkeit sowie mögliche Folgen reduzieren.

Und das Geschehene so schnell wie möglich an die Zuständigen kommunizieren, zur Schadenseingrenzung und schnellstmöglichen Behebung.

[Han_Trio]

Ich hab mal ein paar hundert Postfächer unbeabsichtigt geleert, also die gesamte Korrespondenz ins Nirvana gepustet.

Hintergrund: Es war eine (geplante) Löschaktion, die auch tatsächlich mehrere zig Postfächer treffen sollte.

Dazu habe ich per Skript eine .txt mit den zu löschenden Postfächern eingelesen, wodurch für jeden Eintrag ein gewisses flag in einer DB auf einen "Lösch"-Wert gesetzt wurde. Ein separates Lösch-Skript schaut dann alle 10 Minuten, ob es etwas zu löschen gibt (alle Einträge, die entsprechend geflagt sind).

Doof: in der DB waren die Postfächer teilweise mit einem beginnenden Leerzeichen hinterlegt (was zum Zeitpunkt der damaligen Erstellung nicht verhindert worden war).
Aus dem Command "rm -rf /mail/kunde/ordner/postfach" des Lösch-Skripts wurde somit ein "rm -rf /mail/kunde/ordner/ postfach" - oder auch, wie die bash unter Linux es dann interpretiert, ein "rm -rf /mail/kunde/ordner/"

Joah.. kompletter Ordner gelöscht, inkl. aller darin befindlichen Postfächer. Mehrfach, da per Skript ausgeführt.

Es hat nicht lange gedauert, bis das aufgefallen ist.. geändert hat es natürlich nichts mehr, weg ist weg unter Linux. Backup (gewolltermaßen) nicht vorhanden.
So blieb - naben der Ursachenforschung, die zum Glück recht schnell erledigt war - die Informierung des Kunden sowie die Sicherstellung, dass das nicht erneut auftritt.
Tatsächlich haben wir noch weitere derartige Einträge gefunden, die also (theoretisch) auch noch weitere Kunden hätten betreffen können.

Nachdem der akute Sturm sich dann gelegt hatte, ging es an die Aufarbeitung. Ich habe hier sogar Lob erhalten, für die sofortige Eskalation und auch für die zielorientierte Verhinderung zukünftiger Vorfälle.

Ich fand es gut zu wissen, dass nicht erstmal nach dem Schuldigen gesucht und rumgemault wird, sondern sachliche Kommunikation, Analyse und Lösungsfindung im Vordergrund standen. Somit kann ich mich dem Rest hier anschließen, die bereits für einen offenen und ehrlichen Umgang plädiert haben.

PS: Die Kommunikation mit dem betroffenen Kunden hat dann jemand anders übernommen

[treffnix]

vor 1 Minute schrieb Han_Trio:

Die Kommunikation mit dem betroffenen Kunden hat dann jemand anders übernommen

Dann hattest du ja wirklich Glück  

vor einer Stunde schrieb allesweg:

Und das Geschehene so schnell wie möglich an die Zuständigen kommunizieren,

Doof nur, wenn man selber verantwortlich ist.. 😛 

[Maniska]

vor 10 Stunden schrieb treffnix:

Fehler sind menschlich, alles ganz normal.

Zeig mir einen Admin der noch nie aus versehen etwas gelöscht, das falsche System neugestartet oder sonst etwas verbockt hat, und ich zeige dir einen Admin der nichts arbeitet.

vor 8 Stunden schrieb Han_Trio:

Ich fand es gut zu wissen, dass nicht erstmal nach dem Schuldigen gesucht und rumgemault wird, sondern sachliche Kommunikation, Analyse und Lösungsfindung im Vordergrund standen.

Welchen Zweck hat es, einen Schuldignen zu finden und den in Senkel zu stellen? Klar, wenn es absoluter Dummfug war, dann ist ein Anschiss gerechtfertigt, aber... Mir ist es lieber ich kann sofort wenn ich merke "ups... 💩" zum Kollegen, wir lösen das Problem asap und sagen dann dem Chef "XY ist aufgrund von ABC passiert, wir haben das Gröbste gerade gezogen und machen jetzt noch 123 damit das nicht mehr passieren kann <optional> das kostet dann aber €€€ an Software/DL" als dass jeder erst mal versucht ein Problem so lange wie möglich zu vertuschen und hofft dass es jemand anderem auf die Füße knallt.

Die Ursache ist wichtig, nicht der Verursacher (außer bei Absicht). Wenn man die Ursache abstellt, hat man das Problem und viele andere die ähnlich ablaufen könnten für die Zukunft gelöst.

[Kellerbräune]

vor 21 Stunden schrieb Maniska:

Mir ist es lieber ich kann sofort wenn ich merke "ups... 💩" zum Kollegen, wir lösen das Problem asap und sagen dann dem Chef "XY ist aufgrund von ABC passiert, wir haben das Gröbste gerade gezogen und machen jetzt noch 123 damit das nicht mehr passieren kann <optional> das kostet dann aber €€€ an Software/DL"

 

Passt perfekt. Klar, es fallen paar Kosten, aber dadurch zahlt der Betrieb "Lehrgeld" im Sinne von; "Was können wir besser machen".

vor 21 Stunden schrieb Maniska:

Die Ursache ist wichtig, nicht der Verursacher

Siehe ersten Kommentar. Zumal, um den Gedanken mal fortzuführen, was ist, wenn die Ursache durch einen neuen Kollegen fabriziert wurde? Angenommen ein neuer IT-Kollege (egal ob "Azubi" oder gelernter Techniker), soll ein System XY erweitern, neu aufsetzen, Daten sichern usw. (Viele andere Beispiele). 

Der neue Kollege erhält eine Anleitung, die Tätigkeit beschreibt und genau während der Tätigkeit passiert es. Die Sicherung klappt nicht, das System wird instabil oder oder. Da wäre die Ursache wiederum die Anleitung / Leitpfaden. WIederum kann der Betrieb dann, daran arbeiten, dass besser zu beschreiben. 

 

 

[sharpy35]

Mir ist in der Ausbildung auch mal dummes passiert. 
Hab n neues Remindersystem in unsere Application eingebaut und wollte das E-Mail senden testen. Also 500 Kunden ausgewählt und E-Mails gesendet. 
Da ich am Abend vorher Shaun of the Dead gesehn hatte lautete der E-mail Text. " Fuck a Doodle Doo"
Blöd war nur, dass ich meine ENV nicht auf DEV gestellt hatte sondern noch in der PROD war, weil ich vorher nen Caching Feature getestet hatte. 
Also ging an 500 reale Kunden die E-Mail mit "Fuck a doodle doo" raus. Es dauerte keine 2 Minuten bis bei uns die Telefone läuteten und die Kunden sich wütend beschwert haben  

Mein Chef hat mich daraufhin nach Hause geschickt und meinte er will mich die restliche Woche nicht mehr sehen...
Man ging es mir da dreckig. Aber man lernt draus  

[_n4p_]

vor 25 Minuten schrieb sharpy35:

Also 500 Kunden ausgewählt und E-Mails gesendet. 

sowas hab ich die Tage auch gemacht. In unserer Jira Test Instanz ein Ticket mit einer Organisation geteilt. Die gute Nachricht: der Emailversand funktioniert einwandfrei. Die schlechte Nachricht: der Kunde weiß jetzt das "Dings nicht geht"  Waren aber auch keine 500 Leute.

[papierstau]

Da gibt´s einiges

Neue USV abends beim Kunden vor Ort eingebaut, morgens eben die Konfiguration durchgeführt, Konfiguration gespeichert, plötzlich ist der Server nicht mehr erreichbar und das Telefon klingelt.

"Test shutdown sequence at save" 

Naja, dank IPMI-Zugriff und SSDs war das nach wenigen Minuten wieder in Ordnung.