Durch meinen Fehler sparte das Unternehmen 500.000 Dollar

• Nachdem ein Engineer die 10-Minuten-Idle-Einstellung nach Snowflake-Abfragen reduziert hatte, sanken die erwarteten jährlichen Datenbankkosten von rund 1 Mio. Dollar auf 500.000 Dollar
• Die jahrelang verzögerte Advanced Analytics Platform stützte sich auch nach dem Launch noch auf eine komplexe ETL-Kette aus Spreadsheets, S3, Lambda, MongoDB, Snowflake und JavaScript-Stored-Procedures
• Der Kern der Kostenverschwendung: Obwohl weniger als 1 TB Daten pro Tag verarbeitet wurden, blieb die Compute-Kapazität nach im Schnitt 2 Sekunden langen Abfragen lange eingeschaltet
• Die Änderung wurde zunächst nur auf einen Teil der Compute-Ressourcen angewendet; das Management erkannte die Einsparung an, wollte die vollständige Umsetzung aber verzögern, und in PowerPoint wurde sie als Optimierung durch Analyse von Nutzungsmustern dargestellt
• Auch nach der Einsparung von 500.000 Dollar blieb die Vergütung ungewiss, während Meetings und Reporting-Aufwand zunahmen – ein Beispiel dafür, wie organisatorische Ineffizienz größere politische Kosten erzeugt als eine kurze individuelle Umsetzung

---

Eine jahrelang verschobene Analyseplattform

• Das Unternehmen wollte stärker datengetrieben arbeiten und beschloss, eine Analyseplattform zu bauen und dafür Personal einzustellen
• Der Engineer, der als Data Scientist eingestellt wurde, konnte keine eigentliche Data-Science-Arbeit machen; auch Anfragen nach Compute für Machine Learning oder Datenpipelines wurden mit dem Hinweis beantwortet, man solle bis zur Bereitstellung der Advanced Analytics Platform, kurz AAP, warten
• AAP sollte ursprünglich im Januar starten, wurde dann auf März verschoben und anschließend mit Verweis auf Covid auf Eis gelegt
• Drei Jahre nachdem er das Unternehmen verlassen hatte, war AAP startbereit; dabei stellte sich heraus, dass die eigentlich benötigten Funktionen von Anfang an gar nicht geplant gewesen waren
• In derselben Woche verließen vier Engineers das Unternehmen, und er trat dem AAP-Team bei, nachdem er Bedingungen gestellt hatte

Technische Schulden direkt nach dem Launch

• Obwohl AAP gerade erst gestartet war, gab es viele technische Schulden und operative Risiken
• Ein neu eingestellter Kollege fand gleich am ersten Tag im Projekt-Repository eine Datei, mit der man über die CI/CD-Pipeline die Produktion löschen konnte, wenn man in den falschen Ordner wechselte
  • In dieser Datei befanden sich auch die Schlüssel und Passwörter, die für ein Administratorkonto nötig waren
• Änderungen an Datenbankzugriffsrechten waren lediglich das Hochladen einer etwa 2 KB großen CSV-Datei, liefen aber über einen übermäßig langen Pfad
  • Ein Spreadsheet wurde von Python geparst
  • Das Ergebnis wurde in S3 abgelegt
  • Lambda wandelte es erneut nach S3 um
  • MongoDB holte sich die S3-Datei
  • Eine andere Lambda-Funktion leitete MongoDB-Records an S3 weiter
  • Snowpipe importierte die S3-Daten nach Snowflake
  • Eine JavaScript-Stored-Procedure pivotierte die Snowflake-Daten in ein relationales Format
• Das Security-Team verlangte ein Format, das sich leicht auf schädliche Inhalte scannen ließ, weshalb alles in CSV umgewandelt wurde; ein tatsächliches Scan-Tool wurde jedoch nie ausgerollt
• Die Lambda-Funktionen begannen mit counter = 1, einem Überbleibsel einer früheren Implementierung, und diese Zeile wurde immer weiter kopiert
• Die CI/CD-Tests blieben monatelang im Fehlerzustand, weil beim Debugging die Nutzung des Befehls tee den Fehlercode überschrieben hatte
• Auch das Abrufen von API-Passwörtern war über zwei Schritte verknotet
  • Wenn man in einem AWS-Service nach einem Schlüssel wie service-password suchte, kam als Wert ebenfalls service-password zurück
  • Dieser Wert wurde dann in einem anderen Service verwendet, um das tatsächliche Passwort zu finden
• Das Skript zur Erstellung von Pipeline-Konfigurationsdateien begann mit 600 auskommentierten Zeilen, weil sie später noch gebraucht werden könnten

Die Snowflake-Einstellung, die die Kosten explodieren ließ

• Die Plattform war um ein Vielfaches teurer als das vorherige Betriebsmodell und überschritt das Budget für Datenbankkosten deutlich
• Die ursprünglich beabsichtigten jährlichen Betriebskosten schienen bei etwa 200.000 Dollar zu liegen, doch die tatsächlichen erwarteten Kosten näherten sich fast 1 Mio. Dollar
• Die Datenbank war Snowflake, und Snowflake rechnet nach der Größe der Computer ab, die Abfragen ausführen
• Compute verursacht nur Kosten, solange es eingeschaltet ist
• Das Team führte pro Woche einige Tausend Abfragen aus; die meisten davon waren Experimentierabfragen von Entwicklern, die ungelesene PowerBI-Berichte geringfügig anpassten
• Die durchschnittliche Laufzeit einer Abfrage lag bei etwa 2 Sekunden, doch die Compute-Ressourcen waren so konfiguriert, dass sie nach einer Abfrage 10 Minuten im Idle-Zustand blieben
• Etwa einen Monat nach seinem Einstieg entdeckte er diese Einstellung und schlug vor, sie anzupassen, doch es folgten nur prozedurale Diskussionen über notwendige Discovery-Arbeit, ohne dass etwas umgesetzt wurde

Eine Änderung in 5 Minuten und ihre Überprüfung

• Einige Monate später erhielt er die Karte „Discovery: Optimise Costs“ und brauchte für das nächste Stand-up ein Ergebnis, also beschloss er, seine bestehende Hypothese selbst zu überprüfen
• Er bat darum, einem kompetent wirkenden neuen Engineer aus einem anderen Team Administratorrechte zu geben, doch das Management erlaubte es nicht
• Stattdessen teilte er Datenbankzugangsdaten mit niedrigerem Berechtigungsniveau, keine Admin-Rechte, und der Engineer unterzog die mögliche Kostensenkung einem Plausibilitätscheck
• Am letzten Tag der Woche um 16 Uhr änderte er die Einstellung, nachdem er in einem Engineer-Chatraum ohne Manager geprüft hatte, ob es Einwände gab
• Zur Sicherheit wandte er die Änderung zunächst nicht auf alle Compute-Ressourcen an, sondern nur auf einen Teil der Compute-Ressourcen

Einsparung und Reaktion der Organisation

• Am folgenden Montag sank die erwartete Rechnung von rund 1 Mio. Dollar auf 500.000 Dollar
• Das Team stellte dies als großen Erfolg bei der Kostensenkung dar, doch aus seiner Sicht hatte man im Wesentlichen nur aufgehört, bereits verschwendetes Geld weiter zu verschwenden
• Andere Teams stellten infrage, dass der neu hinzugekommene Engineer zeitgleich mit dieser Einsparung gekommen war, und fragten, warum man diese Einsparung vorher nicht erkannt hatte
• Das Management freute sich, war aber der Ansicht, dass eine sofortige Anwendung der Änderung auf alle Compute-Ressourcen der Abteilung zu viel Aufmerksamkeit einbringen und unerwünschte Fragen auslösen könnte
• Es gab den impliziten Vorschlag, die Umsetzung langsam vorzunehmen, damit die Änderung wie eine länger dauernde Arbeit wirkte
• Er musste eine PowerPoint erstellen, und die Formulierung wurde sinngemäß auf „eine sorgfältige statistische Analyse der Nutzungsmuster hat Möglichkeiten für eine effektivere Ressourcenverteilung aufgezeigt“ gebracht
• Tatsächlich bestand die Änderung darin, eine Einstellung anzupassen, damit teure Compute-Ressourcen nicht den ganzen Tag im Idle-Zustand bleiben

Die Belastung nach dem Erfolg

• Er war der Ansicht, dass er durch informelles Vorgehen mit einigen guten Engineers leichter ein größeres Ergebnis erzielt hatte als die gesamte Abteilung
• Er kam zu dem Schluss, dass kompetente Menschen zwar in der Organisation vorhanden sind, aber durch die Organisationsstruktur daran gehindert werden, wirksam zu werden
• Nachdem er 500.000 Dollar eingespart hatte, bat er um eine Gehaltserhöhung von 30.000 Dollar, doch die Nachricht wurde zwar gelesen, blieb aber unbeantwortet; er rechnete damit, entweder gar nichts oder vielleicht etwa 5.000 Dollar zu bekommen
• Es kamen mehr Meetings hinzu, in denen über die Kostensenkung gesprochen werden sollte, ebenso zusätzlicher Aufwand für PowerPoint-Folien
• Er schließt damit, dass es für ihn besser gewesen wäre, nichts zu tun: In 5 Minuten habe er den größten Erfolg seiner Karriere erzielt, sich aber sofort zusätzliche Belastung eingehandelt

[GN⁺]

Meinungen auf Hacker News

• Dieser ganze Beitrag spricht mir sehr aus der Seele.
  In meiner Laufbahn bei der US Navy standen in meiner Personalakte Kosteneinsparungen von über 50 Millionen Dollar. Jedes Mal, wenn ich etwas tat, musste ich eine PowerPoint erstellen und es Generälen bzw. Admirälen präsentieren, und einmal wäre ich beinahe hart bestraft worden, weil ich meinen Vorgesetzten nicht die Lorbeeren hatte einheimsen lassen. Dabei wusste dieser Vorgesetzte überhaupt nicht, was ich getan hatte, und hatte gar nicht vor, sich die Lorbeeren zu holen.
  Ein Teil davon war während meiner Zeit als Lean-Six-Sigma-Black-Belt in unternehmensweiten Projekten, und schon dieser ganze Ausdruck ist mir verhasst. Meine Aufgabe bestand buchstäblich darin, die Kosten des DOD so weit wie möglich zu senken, und es war die schlimmste Phase meiner Karriere. Das war die Belohnung dafür, dass ich eigenmächtig Probleme gelöst hatte, mit denen Millionen Dollar gespart wurden.
  Dem letzten Teil des Beitrags stimme ich zu. Man muss vorsichtig sein, wenn man bei der Arbeit gute Dinge tut. Die Belohnung besteht fast nie aus Geld, sondern aus mehr Arbeit bei gleichem Gehalt.

  • So läuft es, wenn man am falschen Arbeitsplatz und mit dem falschen Chef landet. Ich habe gerade das Pech, an so einem schlechten Ort zu sein.
    Früher war ich an einem viel besseren Ort, und wenn ich von mir aus losgelegt und Millionen Dollar gespart habe, wurde das tatsächlich gefeiert, und mein Chef hat mir die Anerkennung auch zugestanden.
    In einem Arbeitsplatz mit toxischer Kultur sollte man niemals bleiben. Auch dann nicht, wenn das Geld besser ist. Es gibt kaum etwas Seelenzerfressenderes, als von inkompetenten, kleinlichen Karrieristen und Kontrollfreaks niedergedrückt zu werden.
  • Ich hatte einen Professor für Wirtschaftsingenieurwesen, der seine Karriere beim Militär im Bereich Energieeffizienz verbracht hatte.
    Seine Quintessenz war: „Das Gute an der US-Regierung ist, dass sie so groß ist, dass selbst wenn die optimale Lösung 30 % einspart und man mit der zweitbesten nur 29 % spart, man immer noch zig Millionen bis Hunderte Millionen Dollar spart und es niemandem auffällt.“
    Eines der großen Projekte war die Energieeffizienz abgelegener Militärlager. Wenn man Treibstoff in bestimmte Gegenden Afghanistans liefern ließ, kostete er etwa 100 Dollar pro Gallone, und die mobilen Generatoren liefen massenhaft nur bei 20–40 % ihrer Kapazität. Wenn ich mich richtig erinnere, waren etwa 70 % am effizientesten; indem man kleine Gebäude errichtete oder mehrere Zelte an einen Generator anschloss, konnte man den Treibstoffverbrauch stark senken und zugleich die Servicequalität verbessern.
  • Manchmal denke ich darüber nach, bei einer dieser Drei-Buchstaben-Regierungsbehörden einzusteigen, um Stellen zu finden, an denen man die Kosteneffizienz verbessern kann, oder um den USA, die mich als Einwanderer aufgenommen haben, direkt etwas zurückzugeben.
    Als FAANG-Ingenieur habe ich an Dingen gearbeitet, die direkt mit Geldflüssen zu tun hatten, und ich habe Erfahrung in verschiedenen Bereichen, die nützlich sein könnten.
    Dann komme ich zu dem Schluss, dass es vermutlich 95 % der Arbeit wäre, die richtigen Leute und das richtige Einsatzfeld zu finden, und lasse es wieder bleiben.
  • Schon der Ausdruck Six-Sigma Black Belt löst bei mir eine Reaktion aus. Das schlimmste Unternehmen, bei dem ich je war, stellte SSBBs wie verrückt ein; tatsächlich taten sie nichts und lieferten keine Ergebnisse.
    Aber wenn man den Kurs machte, wurde man bei Beförderungen schnell durchgereicht.
  • Das ist für mich eine große Quelle der Verzweiflung, und ich habe es in zwei Jobs selbst erlebt.
    Ich will einen stabilen Angestelltenjob, weiß aber: Wenn ich gute Arbeit leiste, sehen Manager das als freie Kapazität und laden mir bis an die Grenze noch mehr Arbeit auf. Gierige Leute werden niemals einer Umsatzbeteiligung oder Gewinnbeteiligung zustimmen; sie sagen einfach: Wir geben dir 5 % mehr pro Jahr, also halt den Mund und arbeite.
    Vor ein paar Jobs bat mich die Firma, die Namen der Projekte aufzuschreiben, die ich aktiv wartete; in Excel mit Standardschriftgröße füllte die Liste zwei ganze Bildschirme. Ich war so ausgebrannt, dass ich in eine schwere Depression rutschte.
    Noch schlimmer ist, dass ich auch diesen Unsinn namens Jobsuche hasse, dieses Unterwerfungsritual.

• Das erinnert mich an Texte von Dan Luu: https://danluu.com/nothing-works/
  Bei Chip-Softwaretools war es ähnlich. Standard war, Tools an große EDA-Anbieter auszulagern, aber wir erzielten große Wirkung mit selbstgebauten Spezialtools, die meist von einer einzigen Person erstellt oder gepflegt wurden.
  Während meiner Zeit liefen die meisten Simulatorzyklen auf einem von einer einzelnen Person gepflegten Spezial-Simulator, und dadurch sparten wir jedes Jahr mehrere Millionen Dollar an Simulatorkosten. Damals lag der Standardpreis bei ein paar Tausend Dollar pro Simulatorlizenz und Jahr, und die Simulations-Maschinenfarm hatte etwa tausend Maschinen.
  Man würde erwarten, dass Wettbewerber selbstverständlich dasselbe tun, wenn eine einzelne Person ein Tool bauen oder pflegen kann, das dem Unternehmen jedes Jahr mehrere Millionen Dollar wert ist; tatsächlich taten es die meisten aber nicht. Genauso, wie Wettbewerber niemanden einstellten, der Wafer öffnen konnte, obwohl sie dadurch schneller und billiger hätten ausliefern können.

  • Ich habe in EDA gearbeitet, und ja, die Software ist schlecht, aber die Käufer sind konservativ. Es ist eben ein riskantes und teures Geschäft.
    Dan Luu spricht von der „Cocktailparty-Version der Effizienzmarkthypothese“; die ökonomische Version von „nichts funktioniert“ liegt näher bei https://en.wikipedia.org/wiki/The_Market_for_Lemons. Dabei geht es um die Rolle von Information und Informationsasymmetrie in Märkten.
    Die Effizienzmarkthypothese scheitert daran, dass vollständiges Wissen unmöglich ist und adverse Selektion tatsächlich existiert.
  • Ich denke oft an diesen Text und an den über Kultur (https://danluu.com/culture/).
    Es gibt auch Unternehmen, die das genaue Gegenteil von dem sind, was der Originalbeitrag beschreibt. Wenn man einmal in so einem Unternehmen gearbeitet hat, kann man sich an einem schlechten Ort nicht mehr gemütlich einrichten.

• Der ganze Beitrag ist Gold wert
  Die Manager fragten, wie sie ohne ihre Hilfe so viel einsparen konnten, verlangten Folien, fragten mehrfach, was passiert sei, und die Änderung musste langsam ausgerollt werden, damit es so aussah, als sei sie im Laufe der Zeit schrittweise erfolgt und nicht durch einen kleinen Toggle. Angesichts der Wirkung wurde um eine Gehaltserhöhung gebeten, aber daraus wurde nichts.
  Schon im eigenen Interesse wäre es wohl besser, sich bei einem Unternehmen wie FAANG zu bewerben. Zumindest ist die Chance größer, dort besser behandelt zu werden.
  Und wenn der Blog Twitter-Card-Metadaten hätte, würde er auf Twitter vermutlich besser aussehen.

  • Wenn ich keine Gehaltserhöhung bekommen hätte, hätte ich wahrscheinlich allem zugestimmt und dann zu Beginn der Präsentation gesagt:
    „Hallo, ich erkläre Ihnen, wie die Einsparung von 500.000 Dollar möglich war. Im Grunde habe ich mir einen Tag lang angesehen, wie katastrophal die ursprüngliche Infrastruktur ausgerollt worden war, und die Code-Testfunktion entfernt, die die Probleme verursachte. In Entwicklung, Management, Test – in jeder Hinsicht war das ein vollständiges Oversight. Insgesamt ist dieser Code so nah am schlechtestmöglichen Zustand, wie es nur geht, und wurde einfach veröffentlicht. Außerdem wurde mir gesagt, ich solle das nicht sagen, weil dann alle schlecht aussehen, und ich solle es schrittweise ausrollen, damit es so aussieht, als hätten die Manager etwas getan.“
    Dann hätte ich das Mikrofon fallen lassen und die Bühne verlassen.
    Ehrlich gesagt hätte ich vermutlich extrem viel weniger Motivation gehabt, mich noch dafür zu interessieren. Und das sage ich als jemand, der das seit fast 20 Jahren macht und sich um die Arbeit kümmert, weil Rechnungen bezahlt und Kinder ernährt werden müssen.
  • Ich habe früher in einem steuerfinanzierten Projekt eine Möglichkeit gefunden, jährlich etwa 250.000 Dollar einzusparen.
    Ich erstellte ein Spreadsheet zum Kostenmodell, dokumentierte es und gab es meinem Chef, der sagte: „Ich schaue es mir an.“ Zwei Wochen später fragte ich, ob er es gesehen habe, und er sagte: „Sieht richtig aus. Gute Arbeit.“ Als ich fragte, ob wir es testweise anwenden würden, war seine Antwort ein Meisterstück:
    „Nein, wir werden nicht dafür bezahlt, Geld zu sparen, sondern dafür, Geld auszugeben.“
    Damals habe ich Cost+Award-Fee-Verträge der Regierung wirklich verstanden.
  • Ich weiß nicht, ob alle meine Freunde schlechte Entwickler sind, aber ich höre heutzutage nicht, dass man bei FAANG gut behandelt wird. Über Netflix habe ich in letzter Zeit nichts gehört.
  • Zumindest kann man bei FAANG statt PowerPoint meist fast normale Textdokumente verwenden.
    Der Nachteil ist wahrscheinlich, dass man dieses Dokument vor der Änderung schreiben, es vom ganzen Team reviewen lassen und für „Alignment“ sorgen muss.
  • Hat Xitter nicht kürzlich die Anzeige von Metadaten externer Websites bis auf Bilder komplett entfernt?

• Es war nicht so, dass er zufällig 500.000 Dollar gespart hat; er hat absichtlich 500.000 Dollar gespart und bereut es jetzt. Das ist nicht dasselbe.
  Große Organisationen sind so ineffizient, dass man sich fragt, wie sie überhaupt konkurrieren können, aber sie haben viel Geld, Skaleneffekte und solche Dinge. Dabei können sie Millionen für dummen Verschwendung und Ineffizienz verbrennen, ohne dass es jemanden besonders kümmert.

  • Das ist leicht zu verstehen. Große Organisationen konkurrieren mit anderen großen Organisationen, die ähnlich ineffizient sind. Effizienz in großen Organisationen ist ein wirklich, wirklich, wirklich schwieriges menschliches Problem, das wir noch nicht gelöst haben.
    Trotzdem liefern sie weiterhin wertvolle Services oder Produkte. Egal wie ineffizient sie sind: Sie sind effizienter, als gar nicht zu existieren. Deshalb entstehen solche Organisationen auch ohne Konkurrenz.
    Man könnte fragen, wie es mit Konkurrenz durch kleine Organisationen aussieht. Kleine Organisationen haben weniger Größeneffizienz, können aber, wenn sie in anderer Hinsicht effizient sind, manchmal effektiv mit Großunternehmen konkurrieren. Wenn sie jedoch wachsen und selbst zu großen Organisationen werden, übernehmen sie am Ende die Ineffizienzen großer Organisationen.
    So läuft es einfach. Es ist nicht so, dass es niemanden kümmert – im Gegenteil, den Eigentümern der Unternehmen ist es enorm wichtig. Das Problem ist, dass buchstäblich niemand weiß, wie man es löst.
  • Konkurrenz wird normalerweise durch einen oder mehrere Burggräben ausgeschaltet: enorme Anfangsinvestitionen, Patente, Markt-Lock-in-Verträge (z. B. wie Windows an OEMs verkauft wird), vertikale Integration (z. B. Apple), regulatorische Compliance (eine Bank oder ein Krankenhaus neu zu gründen ist tatsächlich schwierig), Übernahmen von Wettbewerbern, Übernahmen von Personal der Konkurrenz (der Grund, warum es bei FAANG so viele hochbezahlte Leute gibt, die an Dingen arbeiten, die dann gestrichen werden), oder weniger legitime Mittel.
    Großunternehmen neigen dazu, in ähnlichen Fehlermustern zu enden wie autoritär kontrollierte Staatsunternehmen. Interessant ist auch, wie gut China hier den Balanceakt zwischen Kontrolle und Wachstum geschafft hat.
  • In der Regel konkurrieren sie gar nicht. Wenn der Staat seine eigenen Regeln nicht durchsetzt, kaufen solche Unternehmen ihre Konkurrenten einfach auf.
    Sie würgen den Markt ab und werden gleichzeitig ineffizienter.
  • Der einzige Grund, warum 99 % der Großunternehmen existieren, ist, dass sie früher als andere groß geworden sind und ihre Größe ihnen die Macht gibt, alle anderen kleinzuhalten.
    Wettbewerb ist ein Märchen, das man MBAs erzählt, damit sie neue Geschäfte starten und es so aussieht, als gäbe es Konkurrenz. Sie hatten von Anfang an keine Chance.
  • Ich glaube wirklich, dass Inflation genau daher kommt. Jedes Mal, wenn nutzlose Löhne gezahlt werden, werden die Ergebnisse teurer oder weniger profitabel.
    Wenn man alle Verschwendung durch Optimierung beseitigen könnte, hätten wir vermutlich eher Deflation, während Computer und Geschäftsprozesse immer effizienter werden.

• Früher habe ich einmal einen Bug gefunden und dadurch 4 Millionen Dollar Jahresumsatz wiederhergestellt.
  Die Sache wurde unter den Teppich gekehrt, um das Team und die Führungskräfte zu schützen, die zugelassen hatten, dass dieser Fehler so lange bestehen blieb. Eine Gehaltserhöhung bekam ich nicht, aber ich gewann ein paar Verbündete und konnte es eine Weile etwas ruhiger angehen lassen.

  • Ganz am Anfang meiner Karriere, als ich bei einem Hedgefonds arbeitete, entdeckte ich geschäftskritische Netzwerkausrüstung, die bei einem Neustart eine Netzwerkschleife ausgelöst hätte.
    Zwei Server hatten mit bestimmten Feed-Daten zu tun, und ich merkte, dass die Kabel entgegen der Funktionsbeschreibung, die ich gehört hatte, seltsam angeschlossen waren.
    Die geschätzten Kosten eines Ausfalls dieses Systems lagen bei etwa 7 Millionen Dollar pro Minute. Ich sprach ein paar zuständige Mitarbeiter und das Netzwerkteam darauf an, wurde aber komplett ignoriert – mit der Begründung, „so hätten wir das unmöglich angeschlossen“, und weil ich neu war.
    Weil es wichtig wirkte, sprach ich das Problem im wöchentlichen Gruppenmeeting erneut an. Jemand ging nachsehen und kam mit der Rückmeldung zurück, dass es genau so war, wie ich gesagt hatte. Das war eine große Sache, und das Netzwerkteam musste etwa zwei Wochen lang im Notfallmodus arbeiten, um das Problem sauber zu beheben.
    Alle waren wütend auf mich. Obwohl ich eine Katastrophe für die Firma verhindert hatte, hatte ich mit der Sache alle schlecht aussehen lassen, zumal ich im Team einen niedrigen Status hatte. Das war eine wichtige Lektion.
  • Früh in meiner Karriere habe ich etwas Ähnliches gemacht, und das bekam ziemlich viel Aufmerksamkeit.
    Das System, das ich zur Behebung eines Bugs gebaut hatte, war faktisch ein Man-in-the-Middle-Angriff auf die Übermittlung von Apothekenrezepten. Weil die Apotheken Preisupdates nie einspielten, wurde der Preis unmittelbar vor der Weiterleitung des Rezepts an das System der Versicherung neu berechnet. Ich arbeitete bei einer kleinen unabhängigen Apothekenkette ohne zentrales Abrechnungssystem.
    In meiner damals grenzenlosen Genialität benannte ich das System nach der Person, in die ich verknallt war. Die Zentrale fand es so gut, dass sie einen jährlichen Preis nach meinem System benannte – was letztlich zu einem Preis wurde, der nach meinem damaligen Schwarm benannt war. Aber ich war viel zu verlegen, um die wahre Herkunft zu erzählen.
    Das ist 25 Jahre her, und bis heute wird jedes Jahr eine Trophäe mit dem Namen meines früheren Schwarms angefertigt und verliehen. Ich glaube, diese Person wäre entsetzt, wenn sie davon wüsste.

• So etwas hat es schon immer gegeben.
  Vor langer Zeit kam ich in einen Raum voller VT100-Terminals; es war ein Wochenende am Semesterende, und gelangweilte CS-Studenten warteten darauf, dass ihre Kompilierungen fertig wurden. Als ich mir das System ansah, stellte ich fest, dass alle Kompilierungen in eine Batch-Queue gestellt worden waren, deren Standardpriorität niedriger war als die interaktiver Jobs. Damit hatte jeder einzelne Tastendruck von irgendwoher eine höhere Priorität, und je öfter die Leute nachsahen, wo ihr Compile-Job stand, desto langsamer wurde alles.
  In den nächsten 15 Minuten erhöhte ich immer wieder die Priorität des Jobs ganz oben in der Queue, und eine Stunde später waren alle fertig und gingen nach Hause. Der Raum gehörte mir. Ein Sieg des unautorisierten Systemadministrators ;-)

• Vor ein paar Monaten habe ich einen S3-Bucket entdeckt, der immer weiter wuchs und 80.000 Dollar pro Monat verschlang, und dem Unternehmen damit 1 Million Dollar pro Jahr gespart.
  Beim Nachsehen stellte sich heraus, dass ein nicht mehr genutztes System Dateien in diesen Bucket kopierte. Ich kontaktierte die Stakeholder; sie schalteten es ab und löschten die Dateien.
  Das obere Management schien sich nicht groß dafür zu interessieren. Der Chef meines Chefs meinte, ich solle mich an ein anderes Team wenden, das so etwas eigentlich hätte bemerken müssen, und damit war die Sache erledigt.

  • Bei einem SaaS-Anbieter, den wir nutzen, passiert gerade genau so etwas. Ich habe es ihnen gesagt, aber sie haben es abgetan. Wahrscheinlich VC-Geld :D

• „Zum Beispiel wurden 234.745 INSERTs in [table name deleted]_HOURLY ausgeführt, und alle hatten weniger als 1000 Zeilen.“
  Das stand tatsächlich im Snowflake-Support-Slack unserer Organisation, und es war praktisch dasselbe Problem: kleine Transaktionen, über die Zeit verteilt, die den Cluster ständig wieder aufwecken. Dieses Produkt ist nicht für einen so gängigen Anwendungsfall wie kontinuierliches Laden kleiner Datenmengen gebaut.
  Ich bin ein Data-Warehouse-Administrator mit echter Praxiserfahrung und sehe gerade dabei zu, wie Leute durch Kostenüberschreitungen nach und nach meine Stellenbeschreibung neu entdecken. Sie sagen ernsthaft Dinge wie: „Es ist selbstverwaltet, aber man muss die Kosten überwachen und Loads und Queries effizienter neu schreiben.“ Ich habe Angst zu fragen, was sie glauben, was ich den ganzen Tag mache.

• Vor langer Zeit in einer weit, weit entfernten Galaxis habe ich etwas, das N × (Oracle-Lizenzen + Sun-Server) erfordert hätte, durch ein Perl-Skript mit weniger als 100 Zeilen und einen einzigen Sun-Server ersetzt und damit über 300 Millionen Dollar pro Jahr gespart.
  Dabei habe ich auch MapReduce erfunden. Das war vor Google.
  Das Problem bestand darin, verschiedene Statistiken aus Webserver-Logs zu berechnen, zum Beispiel die 10 beliebtesten Seiten. Die ursprüngliche Lösung war, weil die Logs riesig waren, alles in eine Oracle-Datenbank auf mehreren Servern zu laden, dann mehrere SQL-Queries auszuführen und das jeden Tag zu wiederholen.

• Die Sammlung beeindruckender HN-Kommentare zum Beitrag des Autors ist großartig: https://ludic.mataroa.blog/compliments/

  • Einige davon sind berechtigt. Der Autor wirkt bisweilen etwas selbstbezogen. Er scheint von der Prämisse auszugehen: „Alle anderen sind unfähig, und ich bin der Retter.“
    Es ist gut möglich, dass viele Leute in der Organisation dem Autor weit voraus waren. Noch wahrscheinlicher ist, dass ein Engineer oder Manager in derselben Gruppe diese Ineffizienz auf Vorrat gehalten hatte, um sie in einer Phase der Kostensenkungen einzusetzen, und dass der Autor diese Gelegenheit verdorben hat. Wenn es dann nichts mehr zu streichen gibt, können enorme Schmerzen und schlechte Leistungsbeurteilungen unvermeidlich sein.
  • Das erinnert mich leider an den inzwischen inaktiven Account @shit_hn_says [1].
    Vermutlich ist er inaktiv, weil das Diskursniveau auf HN so weit gesunken ist, dass inzwischen fast jeder Kommentar dafür infrage käme.
    [1] https://twitter.com/shit_hn_says