Ich verstehe, dass man in dieser Katastrophe Humor findet, aber ich frage mich, wie es mit der Verantwortlichkeit aussieht.
Auf HN habe ich schon ein paar Mal gelesen, dass durch diesen Vorfall Schäden in Milliardenhöhe entstanden seien, aber von Klagen war bisher noch nicht viel zu hören.
Ist die Lizenz so wasserdicht, dass Kunden keine Möglichkeit auf Abhilfe haben? Bei Verbrauchern, deren privater PC ein paar Stunden oder Tage stillsteht, könnte ich das noch verstehen, aber dass die Industrie ein solches Risikoniveau akzeptiert, ergibt für mich keinen Sinn.
Genau das ist auch ein wichtiger Grund, warum Bauingenieurwesen als ernstzunehmende Disziplin gilt. Wenn eine Brücke einstürzt, droht nicht nur finanzielle Haftung, sondern möglicherweise auch strafrechtliche Verantwortung, und Studierende des Bauingenieurwesens lernen immer wieder, dass sie ins Gefängnis kommen können, wenn sie unethisch handeln oder als Ingenieure inakzeptable Risiken eingehen.
Gibt es für Softwareingenieure einen Weg, ein solches Niveau an Verantwortlichkeit und Berufspraxis zu erreichen?
Bauingenieurwesen ist anders, weil es physische Produkte entwirft. Nichts wird exakt bis an die Grenze ausgelegt; bei allem wird eine ausreichende Sicherheitsmarge eingeplant.
Man berechnet etwa eine Brücke, über die dicht an dicht Lastwagen fahren, während während eines Hurrikans auch noch ein Erdbeben auftritt, und schlägt dann noch 20 % drauf. Wenn man nicht sicher ist, ob ein Träger hält, macht man ihn größer; selbst wenn die Berechnung um 0,5 % danebenliegt, ist das kein großes Problem.
Wenn in den Konstruktionsunterlagen ein Tippfehler steht und ein 150-Fuß-Träger in eine 15,0-Fuß-Lücke eingesetzt werden soll, wird der Bauunternehmer nachfragen. Deshalb ist ein Brückeneinsturz fast sicher das Ergebnis grober Fahrlässigkeit.
Beim Programmieren dagegen kann schon ein einziges < statt <= den Unterschied zwischen einem völlig intakten Zustand und Schäden in Milliardenhöhe ausmachen. Kein Programmierer auf der Welt kann eine Anwendung von nichttrivialer Komplexität zu 100 % fehlerfrei schreiben.
Selbst der seL4-Mikrokernel, der mit formalen Korrektheitsbeweisen wirbt, hat Bugs. Compiler und Proof-Checker sind technisch möglich, beschweren sich aber nicht, wenn man sie etwas offensichtlich Falsches tun lässt.
Für den kleinsten Fehler praktisch unbegrenzt zu haften, ist nichts, was ein vernünftiger Mensch akzeptieren kann.
Wenn man Softwareingenieure haftbar machen will, muss man zuerst einen Weg finden, alltägliche gutgläubige Fehler von grober Fahrlässigkeit zu unterscheiden, und das dürfte sehr schwer zu formalisieren sein.
Als Delta wegen 500 Millionen Dollar Schaden eine Klage ankündigte, antwortete CrowdStrike öffentlich, dass die vertragliche Haftungsgrenze von CrowdStrike bei einem einstelligen Millionenbetrag liege.
Anschließend schickten sie eine Liste mit Dingen, die sie im Discovery-Verfahren anfordern würden, sobald die Klage beginnt: Backup-Pläne, Failover-Pläne, Testpläne und -ergebnisse, den Zeitpunkt der letzten Wiederherstellungsübung aus Backups usw.
Im Grunde heißt das: „Wenn ihr klagt, durchleuchten wir eure IT-Praktiken so gründlich, dass sie peinlicher aussehen als unsere, und zeigen, dass der Fehler bei euch lag.“
Es gibt Rechtsmittel, aber wie gesagt nicht für normale Leute. Unternehmen verklagen CrowdStrike bereits und werden das auch weiterhin tun; nach den von CrowdStrike veröffentlichten Dokumenten zu urteilen, scheinen die geschädigten Unternehmen sehr gute Gewinnchancen zu haben.
Es wirkt sehr wahrscheinlich, dass sie Richter, Jury oder Schiedsrichter davon überzeugen können, dass CrowdStrike grob fahrlässig gehandelt und den Unternehmen eindeutig direkte Verluste sowie indirekte Reputationsschäden verursacht hat.
Ehrlich gesagt bin ich mir nicht sicher, ob CrowdStrike das bis zum Ende durchfechten wird. Das meiste dürfte außergerichtlich beigelegt werden, und in den nächsten Jahren könnten wir erleben, wie CrowdStrike zugrunde geht.
Viele Unternehmen haben Versicherungen für Vorfälle, bei denen Einnahmequellen ausfallen. So wie Landwirte Ernteversicherungen oder große Einzelhändler Katastrophenschadenversicherungen haben, dürfte es auch etwas für Situationen geben, in denen durch einen Infrastrukturausfall der Umsatz für eine gewisse Zeit auf null fällt.
Selbst wenn alle Betroffenen 100 % ihrer Verluste bei ClownStrike geltend machen, reichen die Umsätze von ClownStrike nicht aus, um diese Verluste zu decken. Selbst wenn man das Unternehmen in die Schließung treiben wollte, könnte man keinen Betrag eintreiben, der dem tatsächlichen Schaden nahekommt.
Deshalb frage ich mich, was konkret vorgeschlagen wird. Bugfreier Code ist nahezu unmöglich, und einen Teil des Risikos akzeptieren die Nutzer.
Glaubt man wirklich, dass Software zwingend zu 100 % bugfrei sein muss, bevor sie eingesetzt wird? Wie will man das beweisen? Und die Anschlussfrage wäre dann, wie sauber der eigene Code sein müsste, damit man das für möglich hält.
Möglich ist es schon, aber die Antwort lautet Zeit. Bauingenieurwesen hat eine Geschichte von Tausenden von Jahren, Software Engineering ist viel jünger, und selbst die Grundlagen des Fachs verändern sich noch.
Zumindest in meinem Land gab es seit Ende der 1970er-Jahre Gesetzesentwürfe für Lizenzpflichten für Systemanalysten, Programmierer elektronischer Computer, Bediener von Datenverarbeitungsmaschinen und Schreibkräfte (!).
Wenn solche Gesetze verabschiedet worden wären, wäre die Entwicklung der Softwarebranche in unserem Land um Jahrzehnte zurückgeworfen worden. Ein Entwurf wollte zum Beispiel die „Bedienung und den Betrieb elektronischer Verarbeitungsgeräte oder Maschinen einschließlich Terminals (digitaler oder visueller Geräte)“ nur Inhabern einer Lizenz als „Bediener von Datenverarbeitungsmaschinen“ erlauben.
Dieses Problem geht über CrowdStrike hinaus und zeigt einen Sicherheitsansatz insgesamt, bei dem man Security-Produkte von der Stange kauft, um Regulierer und Versicherer zufriedenzustellen, ohne sich wirklich darum zu kümmern, was diese tatsächlich tun und wie sie funktionieren.
Das heißt nicht, dass man Technologie nicht regulieren sollte, aber das heutige Modell „Wir kaufen das und lagern die Verantwortung aus“ funktioniert nicht.
Noch schlimmer ist, dass die Leute, die so etwas vorausgesehen haben – also die IT-Abteilungen –, vermutlich nichts dagegen tun konnten. Sehr wahrscheinlich wurde es von der Unternehmensspitze wegen Anforderungen der „Cyberversicherung“ oder anderer Vorschriften verpflichtend gemacht. Wahnsinn.
Ich habe viele gute IT-Leute gesehen, die so empfanden, aber meiner Erfahrung nach waren die meisten IT-Abteilungen wenig daran interessiert, ob etwas tatsächlich Probleme löst, solange es die Punkte erfüllt, die im Vertrag verlangt werden.
Bei einem früheren Arbeitgeber wurde über ein Wochenende Software ähnlich wie CrowdStrike auf meiner Workstation installiert, und als ich zurückkam, waren die Kompilierzeiten um 20 % langsamer.
Ich hatte das damals gemessen und Dutzende Messwerte dazu; per ETL-Tracing konnte ich zeigen, dass diese Software die Ursache war, aber die IT erkannte das nicht an. Im Vertrag des Anbieters stand nämlich, dass es bei unserer Workload keine Performance-Auswirkungen geben werde.
Die meisten IT-Abteilungen hätten das nicht vorhergesehen, und es ist auch naheliegend, dass sie ihre gesamte Sicherheitsstrategie nicht auf diese Möglichkeit ausgerichtet haben. Ich weiß nicht, woher dieses Narrativ kommt.
Falcon bot und bietet Kunden reale, echte Sicherheitsvorteile. Das heißt nicht, dass es alle Risiken beseitigt, und auch nicht, dass es keine eigenen Risiken schafft.
Wie bei jedem Engineering-Problem ist es buchstäblich ein Spiel der Trade-offs. Das sollte den Leuten hier nicht fremd sein.
Plötzlich ist HN voller Sicherheitsexperten mit Rückschaufehler und Recency Bias, die erklären, wie Unternehmen dieser Kugel hätten ausweichen können, ohne die echten Kugeln zu berücksichtigen, denen sie durch den Einsatz von Falcon überhaupt erst ausgewichen sind.
Das könnte als Beweisvideo vor Gericht oder in einem Prozess verwendet werden und ist keine lustige Angelegenheit.
Ursprünglich war das wohl ein geschlossener Moment unter Security-Nerds, aber jetzt wurde er öffentlich, sodass die breite Öffentlichkeit, die großen Schaden erlitten hat, sich nach Herzenslust darüber lustig machen kann.
Ich hatte überhaupt nicht den Eindruck, dass der CrowdStrike-Manager die Lage auf die leichte Schulter genommen hat. Im Gegenteil: Die Rede wirkte so, als nehme er die Situation ernst, erkenne sie als gewaltigen Fehler an und nehme die Trophäe als Zeichen der Schande und als warnendes Beispiel für künftige CrowdStrike-Mitarbeiter an.
Ich finde, es war ein wirklich würdevoller Schritt, dass der Manager diesen Preis angenommen hat. Natürlich bedeutet das keineswegs, dass CrowdStrike dadurch von Verantwortung oder Haftung für den Vorfall befreit wäre.
Als T-Shirt könnte es lustig sein.
When I use
REGEXP
I use it in my
KERNEL CODE
Tragödie und Komödie sind zwei Seiten derselben Medaille.
Probleme der Computersicherheit traten schon während des Vietnamkriegs auf, und die USA arbeiteten tatsächlich daran, wirksame Modelle für Computersicherheit zu finden. Aber wir leben in einer Gesellschaft, die das praktisch aus dem Gedächtnis gelöscht hat.
Warum muss ein Scanner rund um die Uhr über allem laufen, was ein Computer ausführen will?
Warum muss sich ein Betriebssystem auf periphere Berechtigungen verlassen?
CrowdStrike die Schuld zu geben, lenkt nur von den grundlegenden Designfehlern in Betriebssystemen wie Linux, MacOS und Windows ab, die wir jeden Tag ignorieren.
Ich mache immer noch Microsoft verantwortlich, denn es ist nicht unmöglich, aktualisierten Code außerhalb des Kernels auszuführen und Kernel-Mode-Code nur für Beobachtung und Aktionen zu verwenden, nicht aber für Logik.
Ich arbeite in der IT und war der arme Mensch, der ausgerechnet dann On-Call hatte, als Clown Strike den Großteil der Infrastruktur weggefegt hat.
Dass ich mich persönlich dagegen gesträubt hatte, cloudbasierten Unsinn zu verwenden, hat wahrscheinlich dazu geführt, dass wir in Stunden statt in Tagen wiederherstellen konnten.
Ich bin ziemlich besorgt, dass wir demnächst einen weiteren großen cloudbasierten Ausfall bewältigen müssen, weil Leute wie IT-Direktoren das nicht als Problem ansehen und keinerlei Maßnahmen ergreifen, um solchen Unsinn zu verhindern.
Ich wiederhole bis zum Überdruss: „Nur Idioten verlassen sich auf die Computer anderer Leute“, und dem stimme ich zu 100 % zu.
Es ist seltsam, dass Manager oder Führungskräfte zwar verstehen, warum ein Single Point of Failure in der internen Infrastruktur schlecht ist, es aber offenbar in Ordnung finden, wenn Produkte oder Dienste externer Anbieter zu einem Single Point of Failure werden.
Sobald sie einen Vertrag abschließen und Geld bezahlen, scheinen sie zu glauben, dass das von Übermenschen gebaut und gewartet wird, die im Gegensatz zu internen Engineers keine Fehler machen. Dieses fehlgeleitete Vertrauen verstehe ich nicht.
Stimme zu 100 % zu. Außerdem ist es erstaunlich zu sehen, wie absurd viel Geld für Cloud-Dienste wie Azure VD ausgegeben wird.
Mit nur einem Teil des jährlichen Cloud-Budgets könnte ein Unternehmen selbst eine sehr stabile auch offline nutzbare Infrastruktur aufbauen.
Dein Ton klingt sehr aggressiv. Selbst wenn du recht hast, würde ich wohl nicht mit dir zusammenarbeiten wollen.
Vielleicht könntest du deine Aussage besser vermitteln, wenn du nicht so aggressiv formulierst.
Wenn dumme CTOs Ratschläge von CTO-Summits, Beratern mit verzerrten Eigenanreizen und allen möglichen zufälligen Konferenzen annehmen, kann man nicht viel machen.
Die früheren Gewinner von „Most Epic Fail“ wurden natürlich überwiegend von Microsoft dominiert.
Man kann die Schande weiter herumreichen, aber wenn man glaubt, dass solche Produktionsausfälle durch schlechte Prozesse entstehen, dann hat Microsoft hier eindeutig ebenfalls eine große Rolle gespielt.
Ich frage mich wirklich, wie CEO und CTO nach diesem Chaos noch ihre Posten behalten können.
In mehreren Städten funktionierte 911 nicht, und die Abläufe in Krankenhäusern wurden bis zum Stillstand verlangsamt, aber für einen Auftritt bei Defcon und Witze ist Zeit?
Gibt es noch Krankenhäuser, deren Computer nicht repariert sind? Natürlich hat CS es vermasselt, aber außer Schadenersatz zu leisten und Prozesse zu ändern, weiß ich nicht, was man jetzt noch tun könnte.
Andere davor zu warnen, denselben Fehler zu wiederholen, wirkt nicht wie eine schlechte Nutzung der Zeit.
CS muss hier zu Recht kritisiert werden, aber CS in kritische Systeme wie 911 einzubauen, war meiner Meinung nach selbst ein großer Fehler.
Allerdings wusste die Person, die das getan hat, wahrscheinlich, dass sie sich der Verantwortung entziehen kann, also gab es wohl auch keinen Grund, sich darum zu kümmern.
1 Kommentare
Meinungen auf Hacker News
Ich verstehe, dass man in dieser Katastrophe Humor findet, aber ich frage mich, wie es mit der Verantwortlichkeit aussieht.
Auf HN habe ich schon ein paar Mal gelesen, dass durch diesen Vorfall Schäden in Milliardenhöhe entstanden seien, aber von Klagen war bisher noch nicht viel zu hören.
Ist die Lizenz so wasserdicht, dass Kunden keine Möglichkeit auf Abhilfe haben? Bei Verbrauchern, deren privater PC ein paar Stunden oder Tage stillsteht, könnte ich das noch verstehen, aber dass die Industrie ein solches Risikoniveau akzeptiert, ergibt für mich keinen Sinn.
Genau das ist auch ein wichtiger Grund, warum Bauingenieurwesen als ernstzunehmende Disziplin gilt. Wenn eine Brücke einstürzt, droht nicht nur finanzielle Haftung, sondern möglicherweise auch strafrechtliche Verantwortung, und Studierende des Bauingenieurwesens lernen immer wieder, dass sie ins Gefängnis kommen können, wenn sie unethisch handeln oder als Ingenieure inakzeptable Risiken eingehen.
Gibt es für Softwareingenieure einen Weg, ein solches Niveau an Verantwortlichkeit und Berufspraxis zu erreichen?
Man berechnet etwa eine Brücke, über die dicht an dicht Lastwagen fahren, während während eines Hurrikans auch noch ein Erdbeben auftritt, und schlägt dann noch 20 % drauf. Wenn man nicht sicher ist, ob ein Träger hält, macht man ihn größer; selbst wenn die Berechnung um 0,5 % danebenliegt, ist das kein großes Problem.
Wenn in den Konstruktionsunterlagen ein Tippfehler steht und ein 150-Fuß-Träger in eine 15,0-Fuß-Lücke eingesetzt werden soll, wird der Bauunternehmer nachfragen. Deshalb ist ein Brückeneinsturz fast sicher das Ergebnis grober Fahrlässigkeit.
Beim Programmieren dagegen kann schon ein einziges
<statt<=den Unterschied zwischen einem völlig intakten Zustand und Schäden in Milliardenhöhe ausmachen. Kein Programmierer auf der Welt kann eine Anwendung von nichttrivialer Komplexität zu 100 % fehlerfrei schreiben.Selbst der seL4-Mikrokernel, der mit formalen Korrektheitsbeweisen wirbt, hat Bugs. Compiler und Proof-Checker sind technisch möglich, beschweren sich aber nicht, wenn man sie etwas offensichtlich Falsches tun lässt.
Für den kleinsten Fehler praktisch unbegrenzt zu haften, ist nichts, was ein vernünftiger Mensch akzeptieren kann.
Wenn man Softwareingenieure haftbar machen will, muss man zuerst einen Weg finden, alltägliche gutgläubige Fehler von grober Fahrlässigkeit zu unterscheiden, und das dürfte sehr schwer zu formalisieren sein.
Anschließend schickten sie eine Liste mit Dingen, die sie im Discovery-Verfahren anfordern würden, sobald die Klage beginnt: Backup-Pläne, Failover-Pläne, Testpläne und -ergebnisse, den Zeitpunkt der letzten Wiederherstellungsübung aus Backups usw.
Im Grunde heißt das: „Wenn ihr klagt, durchleuchten wir eure IT-Praktiken so gründlich, dass sie peinlicher aussehen als unsere, und zeigen, dass der Fehler bei euch lag.“
Es wirkt sehr wahrscheinlich, dass sie Richter, Jury oder Schiedsrichter davon überzeugen können, dass CrowdStrike grob fahrlässig gehandelt und den Unternehmen eindeutig direkte Verluste sowie indirekte Reputationsschäden verursacht hat.
Ehrlich gesagt bin ich mir nicht sicher, ob CrowdStrike das bis zum Ende durchfechten wird. Das meiste dürfte außergerichtlich beigelegt werden, und in den nächsten Jahren könnten wir erleben, wie CrowdStrike zugrunde geht.
Selbst wenn alle Betroffenen 100 % ihrer Verluste bei ClownStrike geltend machen, reichen die Umsätze von ClownStrike nicht aus, um diese Verluste zu decken. Selbst wenn man das Unternehmen in die Schließung treiben wollte, könnte man keinen Betrag eintreiben, der dem tatsächlichen Schaden nahekommt.
Deshalb frage ich mich, was konkret vorgeschlagen wird. Bugfreier Code ist nahezu unmöglich, und einen Teil des Risikos akzeptieren die Nutzer.
Glaubt man wirklich, dass Software zwingend zu 100 % bugfrei sein muss, bevor sie eingesetzt wird? Wie will man das beweisen? Und die Anschlussfrage wäre dann, wie sauber der eigene Code sein müsste, damit man das für möglich hält.
Zumindest in meinem Land gab es seit Ende der 1970er-Jahre Gesetzesentwürfe für Lizenzpflichten für Systemanalysten, Programmierer elektronischer Computer, Bediener von Datenverarbeitungsmaschinen und Schreibkräfte (!).
Wenn solche Gesetze verabschiedet worden wären, wäre die Entwicklung der Softwarebranche in unserem Land um Jahrzehnte zurückgeworfen worden. Ein Entwurf wollte zum Beispiel die „Bedienung und den Betrieb elektronischer Verarbeitungsgeräte oder Maschinen einschließlich Terminals (digitaler oder visueller Geräte)“ nur Inhabern einer Lizenz als „Bediener von Datenverarbeitungsmaschinen“ erlauben.
Dieses Problem geht über CrowdStrike hinaus und zeigt einen Sicherheitsansatz insgesamt, bei dem man Security-Produkte von der Stange kauft, um Regulierer und Versicherer zufriedenzustellen, ohne sich wirklich darum zu kümmern, was diese tatsächlich tun und wie sie funktionieren.
Das heißt nicht, dass man Technologie nicht regulieren sollte, aber das heutige Modell „Wir kaufen das und lagern die Verantwortung aus“ funktioniert nicht.
Noch schlimmer ist, dass die Leute, die so etwas vorausgesehen haben – also die IT-Abteilungen –, vermutlich nichts dagegen tun konnten. Sehr wahrscheinlich wurde es von der Unternehmensspitze wegen Anforderungen der „Cyberversicherung“ oder anderer Vorschriften verpflichtend gemacht. Wahnsinn.
Bei einem früheren Arbeitgeber wurde über ein Wochenende Software ähnlich wie CrowdStrike auf meiner Workstation installiert, und als ich zurückkam, waren die Kompilierzeiten um 20 % langsamer.
Ich hatte das damals gemessen und Dutzende Messwerte dazu; per ETL-Tracing konnte ich zeigen, dass diese Software die Ursache war, aber die IT erkannte das nicht an. Im Vertrag des Anbieters stand nämlich, dass es bei unserer Workload keine Performance-Auswirkungen geben werde.
Falcon bot und bietet Kunden reale, echte Sicherheitsvorteile. Das heißt nicht, dass es alle Risiken beseitigt, und auch nicht, dass es keine eigenen Risiken schafft.
Wie bei jedem Engineering-Problem ist es buchstäblich ein Spiel der Trade-offs. Das sollte den Leuten hier nicht fremd sein.
Plötzlich ist HN voller Sicherheitsexperten mit Rückschaufehler und Recency Bias, die erklären, wie Unternehmen dieser Kugel hätten ausweichen können, ohne die echten Kugeln zu berücksichtigen, denen sie durch den Einsatz von Falcon überhaupt erst ausgewichen sind.
Das könnte als Beweisvideo vor Gericht oder in einem Prozess verwendet werden und ist keine lustige Angelegenheit.
Ursprünglich war das wohl ein geschlossener Moment unter Security-Nerds, aber jetzt wurde er öffentlich, sodass die breite Öffentlichkeit, die großen Schaden erlitten hat, sich nach Herzenslust darüber lustig machen kann.
Ich finde, es war ein wirklich würdevoller Schritt, dass der Manager diesen Preis angenommen hat. Natürlich bedeutet das keineswegs, dass CrowdStrike dadurch von Verantwortung oder Haftung für den Vorfall befreit wäre.
When I use
REGEXP
I use it in my
KERNEL CODE
Tragödie und Komödie sind zwei Seiten derselben Medaille.
Über xcancel: https://xcancel.com/singe/status/1822324795645575263
Probleme der Computersicherheit traten schon während des Vietnamkriegs auf, und die USA arbeiteten tatsächlich daran, wirksame Modelle für Computersicherheit zu finden. Aber wir leben in einer Gesellschaft, die das praktisch aus dem Gedächtnis gelöscht hat.
Warum muss ein Scanner rund um die Uhr über allem laufen, was ein Computer ausführen will?
Warum muss sich ein Betriebssystem auf periphere Berechtigungen verlassen?
CrowdStrike die Schuld zu geben, lenkt nur von den grundlegenden Designfehlern in Betriebssystemen wie Linux, MacOS und Windows ab, die wir jeden Tag ignorieren.
Ich mache immer noch Microsoft verantwortlich, denn es ist nicht unmöglich, aktualisierten Code außerhalb des Kernels auszuführen und Kernel-Mode-Code nur für Beobachtung und Aktionen zu verwenden, nicht aber für Logik.
Ich arbeite in der IT und war der arme Mensch, der ausgerechnet dann On-Call hatte, als Clown Strike den Großteil der Infrastruktur weggefegt hat.
Dass ich mich persönlich dagegen gesträubt hatte, cloudbasierten Unsinn zu verwenden, hat wahrscheinlich dazu geführt, dass wir in Stunden statt in Tagen wiederherstellen konnten.
Ich bin ziemlich besorgt, dass wir demnächst einen weiteren großen cloudbasierten Ausfall bewältigen müssen, weil Leute wie IT-Direktoren das nicht als Problem ansehen und keinerlei Maßnahmen ergreifen, um solchen Unsinn zu verhindern.
Ich wiederhole bis zum Überdruss: „Nur Idioten verlassen sich auf die Computer anderer Leute“, und dem stimme ich zu 100 % zu.
Sobald sie einen Vertrag abschließen und Geld bezahlen, scheinen sie zu glauben, dass das von Übermenschen gebaut und gewartet wird, die im Gegensatz zu internen Engineers keine Fehler machen. Dieses fehlgeleitete Vertrauen verstehe ich nicht.
Mit nur einem Teil des jährlichen Cloud-Budgets könnte ein Unternehmen selbst eine sehr stabile auch offline nutzbare Infrastruktur aufbauen.
Vielleicht könntest du deine Aussage besser vermitteln, wenn du nicht so aggressiv formulierst.
Zum Vergleich eine Liste früherer Pwnie-Award-Gewinner: https://en.wikipedia.org/wiki/Pwnie_Awards
Man kann die Schande weiter herumreichen, aber wenn man glaubt, dass solche Produktionsausfälle durch schlechte Prozesse entstehen, dann hat Microsoft hier eindeutig ebenfalls eine große Rolle gespielt.
Ich frage mich wirklich, wie CEO und CTO nach diesem Chaos noch ihre Posten behalten können.
In mehreren Städten funktionierte 911 nicht, und die Abläufe in Krankenhäusern wurden bis zum Stillstand verlangsamt, aber für einen Auftritt bei Defcon und Witze ist Zeit?
Andere davor zu warnen, denselben Fehler zu wiederholen, wirkt nicht wie eine schlechte Nutzung der Zeit.
Allerdings wusste die Person, die das getan hat, wahrscheinlich, dass sie sich der Verantwortung entziehen kann, also gab es wohl auch keinen Grund, sich darum zu kümmern.