Die Website \u201eScripped\u201c war ein Drehbuchdienst, der cloudbasierte Schreibwerkzeuge, Online-Speicher und eine Community zum Lesen und Kritisieren von Drehb\u00fcchern in Arbeit bot. \u201eWar\u201c ist das Schl\u00fcsselwort in diesem Satz. Letzten Fr\u00fchling meldeten sich registrierte Benutzer auf einer leeren Seite an, die die erschreckende Meldung enthielt, dass ihr Browser \u201efestgestellt hat, dass der Server die Anfrage f\u00fcr diese Adresse auf eine Weise umleitet, die niemals abgeschlossen wird.\u201c <\/p>\n
Kein Aprilscherz oder Trick-or-Treat; Bald zeigte eine Meldung auf der Startseite an, dass nach einem k\u00fcrzlichen Eigent\u00fcmerwechsel der Website der regul\u00e4re Sicherungsprozess fehlschlug \u2013 und dabei alle vorherigen Sicherungen gel\u00f6scht wurden<\/em>. Die fr\u00fcheren Eigent\u00fcmer hatten ihre Sicherungen zerst\u00f6rt, sodass von der gesamten gemeinsamen Arbeitsdatenbank der Community nur noch ein Server-Image aus dem Jahr 2010 \u00fcbrig blieb. <\/p>\n Laut der (inzwischen entfernten) Seite, wenn Autoren keine Sicherungskopie ihrer Arbeit aufbewahrten, \u201ebedauern wir, [ihnen] mitteilen zu m\u00fcssen, dass sie nicht mehr existiert.\u201c Man m\u00fcsste annehmen, dass die meisten Benutzer lokale Sicherungen ihrer Arbeit aufbewahrten und sich nicht vollst\u00e4ndig auf Cloud-Speicher f\u00fcr ihre Drehb\u00fccher verlassen w\u00fcrden; dennoch muss der Verlust ihrer kreativen Leistung verheerend sein. (Ich habe einen Freund, einen talentierten Fernsehautor, der bei einem \u00e4hnlichen Ereignis im Jahr 2011 jahrelange Materialien verlor; meines Wissens hat er seitdem nicht mehr geschrieben.) <\/p>\n Jedes Mal, wenn wir die Kontrolle \u00fcber unsere Daten aufgeben oder unser geistiges Eigentum auslagern, setzen wir uns und unsere Existenz aufs Spiel. Bei Kepner-Tregoe schulen wir unsere Kunden darin, ein Tool namens \u201ePotenzielle Problemanalyse\u201c zu verwenden, um solche Bedrohungen zu reduzieren. In sechs Schritten k\u00f6nnen Kunden Aktionspl\u00e4ne erstellen, die sowohl die Wahrscheinlichkeit eines katastrophalen Ereignisses verringern als auch schnell erkennen, wann es an der Zeit ist, einen (definierten) \u201ePlan B\u201c einzusetzen. <\/p>\n Die Analyse beginnt mit der spezifischen Formulierung der zu sch\u00fctzenden Aktion<\/strong>. Spezifisch zu sein ist wichtig: \u201eBetreiben eines webbasierten Dienstes\u201c ist weit gefasst und kann es schwierig machen, eine klare Liste von Risiken zu identifizieren; \u201eErstes vollst\u00e4ndiges Backup auf neuen Servern durchf\u00fchren\u201c ist besser, um die Art des kreativen Denkens anzuregen, die zu Ergebnissen f\u00fchrt. <\/p>\n Als N\u00e4chstes holen wir Experten (und Skeptiker) hinzu, um Ideen zu sammeln und \u201ePotenzielle Probleme zu identifizieren\u201c<\/strong>, indem wir fragen: \u201eWas kann schiefgehen, wenn wir dies tun?\u201c Auch hier ist Spezifit\u00e4t entscheidend. Wir sehen h\u00e4ufig Teams, die ein m\u00f6gliches Problem wie \u201eBackup schl\u00e4gt fehl\u201c angehen. Aber welche verschiedenen Fehlermodi gibt es? Sind sie alle gleicherma\u00dfen wahrscheinlich? Gleicherma\u00dfen katastrophal? Wird auf sie identisch reagiert? Wenn die Antwort auf eine dieser Fragen \u201eNein\u201c lautet, sollte das potenzielle Problem weiter pr\u00e4zisiert werden. <\/p>\n Im Allgemeinen erfordert das Auflisten von \u201ewas schiefgehen kann\u201c nicht viel Aufwand; die Zeit oder die Ressourcen, um alles auf dieser Liste zu bew\u00e4ltigen, schon. Viele Organisationen haben ihre eigenen FMEA-\u00e4hnlichen Matrizen zur Priorisierung von Risiken. Eine Alternative besteht darin, zwei verschiedene Dimensionen zu identifizieren \u2013 die Wahrscheinlichkeit eines Fehlers und separat dessen Auswirkungen \u2013, um sich auf die kritischsten Risiken zu konzentrieren. <\/p>\n Von dort aus ist es nur nat\u00fcrlich, sofort handeln zu wollen; wir ermutigen Kunden, innezuhalten und die \u201eWahrscheinlichen Ursachen\u201c<\/strong> der hochpriorit\u00e4ren potenziellen Probleme zu identifizieren. Wenn wir eine Ursache eliminieren oder zumindest ihre Wahrscheinlichkeit verringern, haben wir einen gro\u00dfen Schritt getan, um sicherzustellen, dass das potenzielle Problem nicht auftritt. Auf die Gefahr hin, redundant zu sein: Je spezifischer die wahrscheinliche Ursache, desto besser die Chance, sie zu verhindern \u2013 \u201eHardwarefehler\u201c ist offen f\u00fcr Interpretationen; \u201eSSE-Controller fallen aus\u201c ist etwas, das beherrschbar ist. Indem wir die Grundursache verstehen, gehen wir das potenzielle Problem direkter und gezielter an. <\/p>\n Wir erlauben uns dann, Ma\u00dfnahmen zu ergreifen \u2013 \u201eVorbeugende Ma\u00dfnahmen\u201c<\/strong>, was genau das bedeutet, was der Name impliziert. Die Absicht ist, die wahrscheinliche Ursache zu verhindern und so unseren Plan zu sch\u00fctzen. Vorbeugende Ma\u00dfnahmen k\u00f6nnen entweder die wahrscheinliche Ursache direkt angehen oder einfach verhindern, dass die Ursache das potenzielle Problem erzeugt. (Es mag beispielsweise unm\u00f6glich sein, einen Netzausfall zu verhindern, aber vorbeugende Ma\u00dfnahmen wie die Installation von unterbrechungsfreien Stromversorgungen k\u00f6nnen verhindern, dass dieser Ausfall Ger\u00e4te stilllegt). <\/p>\n Viele Organisationen, die des \u201eFeuerl\u00f6schens\u201c m\u00fcde sind, h\u00f6ren hier auf. Nach der Entwicklung einer perfekten L\u00f6sung und der Installation unz\u00e4hliger Ma\u00dfnahmen zur Problemvermeidung scheint es unvorstellbar, dass tats\u00e4chlich schlimme Dinge passieren k\u00f6nnten. Kluge Teams wissen, dass sie dieser Kombination aus Hochmut und mangelnder Vorstellungskraft nicht zum Opfer fallen d\u00fcrfen. <\/p>\n Der vorletzte Schritt einer guten PPA beginnt damit, sich vorzustellen, dass das Problem aufgetreten ist und es an der Zeit ist, seine Auswirkungen<\/em> zu minimieren \u2013 die Festlegung von \u201eNotfallma\u00dfnahmen\u201c<\/strong> ist das, was ben\u00f6tigt wird. Die Herausforderung besteht nicht darin, sich Gedanken dar\u00fcber zu machen, warum<\/em> das Problem aufgetreten ist, sondern zu fragen: \u201eWas werden wir tun, wenn<\/em> es passiert?\u201c H\u00e4ufig finden Teams keine tiefere Antwort als \u201er\u00fcckg\u00e4ngig machen\u201c (CABs wollen immer den \u201eRollback-Plan\u201c wissen); manchmal ist das nicht m\u00f6glich, und andere Male ist es kl\u00fcger, in den metaphorischen Schleudergang zu gehen, um zu entkommen. Die Ironie hierbei ist, dass Backup-L\u00f6sungen eine Notfallma\u00dfnahme sind \u2013 sie werden ausgel\u00f6st, wenn die prim\u00e4ren Daten entweder zerst\u00f6rt oder gel\u00f6scht werden. <\/p>\n (Es ist sicherlich eine Binney-Regel, wenn auch noch nicht zu einem Binney-Gesetz erhoben: Sie werden immer<\/u>, irgendwann, Notfallma\u00dfnahmen ergreifen; es ist besser, dies in einem Konferenzraum zu tun, gem\u00fctlich Kaffee vor einem Whiteboard schl\u00fcrfend, als wenn alles schiefgegangen ist, Kollegen in Panik geraten, Ger\u00e4te schmelzen und Auftragnehmer auf die Uhr schauen).<\/p>\n Ma\u00dfnahmen ohne Verantwortlichkeit n\u00fctzen niemandem. Das Festlegen klarer Ausl\u00f6ser<\/strong> liefert eine eindeutige Benachrichtigung, dass ein potenzielles Problem tats\u00e4chlich aufgetreten ist, und zeigt sowohl die zu ergreifende Notfallma\u00dfnahme als auch, wer sie ergreifen sollte. <\/p>\n \u00dcbersicht der potenziellen Problemanalyse:<\/strong><\/p>\n H\u00e4tten die neuen Eigent\u00fcmer von Scripped erkannt, \u201ewas schiefgehen k\u00f6nnte\u201c mit ihrem Backup, mit dem Verst\u00e4ndnis, dass sie keine fr\u00fcheren Backups besa\u00dfen, h\u00e4tten sie wahrscheinlich vorbeugende Ma\u00dfnahmen ergriffen, um das Debakel zu vermeiden. Andernfalls, wenn sie ein oder zwei klare Notfallma\u00dfnahmen identifiziert h\u00e4tten, h\u00e4tten sie kritische Daten retten k\u00f6nnen, bevor es zu sp\u00e4t war. Stattdessen sind sie zu einem von zu vielen warnenden Beispielen geworden. <\/p>\n","protected":false},"excerpt":{"rendered":" Die Website \u201eScripped\u201c war ein Drehbuchdienst, der cloudbasierte Schreibwerkzeuge, Online-Speicher und eine Community zum Lesen und Kritisieren von Drehb\u00fcchern in Arbeit bot. \u201eWar\u201c ist das Schl\u00fcsselwort in diesem Satz. Letzten Fr\u00fchling meldeten sich registrierte Benutzer auf einer leeren Seite an, die die erschreckende Meldung enthielt, dass ihr Browser \u201efestgestellt hat, dass der Server die Anfrage […]<\/p>\n","protected":false},"author":5,"featured_media":2918,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[35],"tags":[],"ppma_author":[163],"class_list":["post-65763","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-sonstige"],"acf":[],"yoast_head":"\n\n