Plsfix — Issue Brain für Platform Engineering

 (plsfix.co)
1 Punkte von GN⁺ 2024-05-22 | 1 Kommentare | Auf WhatsApp teilen
  • plsfix sammelt bereits gelöste Incident-Aufzeichnungen, wandelt sie in verifizierte Runbooks und ausführbare Skills um und bietet bei erneut auftretenden gleichen Störungen direkt im Thread einen Ausführen-Button an
  • Der Ablauf führt über schreibgeschützte Erfassung, Clustering wiederkehrender Incidents, Verifizierung durch Engineers und Ausführung; jeder Schritt basiert auf früheren Lösungsfällen des Teams
  • Im Pilotbeispiel wurden unter 14.802 Events 7 wiederkehrende Cluster gefunden, 22 % der neuen Events automatisch gelöst, und im Slack-Beispiel wurde 4 Sekunden nach der Warnung mit 94 % Konfidenz ein Runbook zugeordnet
  • Runbooks werden zu YAML-Skills kompiliert; sichere Schritte werden automatisch ausgeführt, Korrekturen mit blast radius stoppen jedoch bei den festgelegten Freigebenden
  • Der 6-wöchige Pilot für Fintech- und Platform-Teams wird nicht berechnet, wenn bis Woche 4 das Volumen wiederkehrender Incidents nicht um 30 % sinkt; die Einrichtung der schreibgeschützten Erfassung dauert etwa 30 Minuten

Ein Produkt, das wiederkehrende Störungen in ausführbares Wissen verwandelt

  • plsfix holt bereits gelöste Incidents eines Teams aus Slack, PagerDuty, GitHub, Claude usw. und wandelt sie in verifizierte Runbooks und ausführbare Skills um
  • Tritt dieselbe Art von Störung erneut auf, antwortet der Bot im selben Thread, und der Nutzer kann sie mit einem Klick auf Run playbook ausführen
  • Die Pilotmetriken auf dem Startbildschirm zeigen Daten aus Woche 1 des acme-Piloten
    • 14.802 Events erfasst
    • 7 wiederkehrende Cluster identifiziert
    • 22 % der neuen Events automatisch gelöst

Das Problem: verstreutes Lösungswissen lässt wiederkehrende Störungen anwachsen

  • Viele Störungen sind keine völlig neuen Probleme, sondern eher wiederkehrende Störungen, die früher schon gelöst wurden, an die sich aber niemand mehr erinnert
  • Das Beispiel zeigt einen Staff Engineer, der um 3 Uhr morgens erneut die exakte Lösung in einem Slack-Thread finden muss
  • Der Lösungsprozess bleibt über mehrere Tools verteilt zurück
    • In PagerDuty gibt es das Acknowledge
    • Im Claude-Thread steht die Diagnose
    • In den Kommentaren eines geschlossenen PR steht die eigentliche Korrektur
  • Anstatt Runbooks nur aus Prompts zu erzeugen, verfolgt plsfix jeden Schritt aus Incidents, die das Team in der Vergangenheit tatsächlich gelöst hat

Vier Schritte von der Erfassung bis zur Ausführung

  • Ingest

    • Schreibgeschützte Konnektoren holen gelöste Vorgänge aus den Orten, an denen das Team Probleme tatsächlich behebt
    • Vor dem Clustering werden PII entfernt
    • Verbunden werden Slack, PagerDuty, GitHub, Jira, Linear, ServiceNow, Notion, Claude / ChatGPT

  • Cluster

    • Die Signatur wiederkehrender Incidents wird gelernt
    • Die Signatur besteht aus Regexen für Alert-Payloads, Service-Mengen, Nähe zu Deployments sowie Kanal- und Reporter-Mustern
    • Gleichartige Störungen werden demselben Cluster zugeordnet

  • Verify

    • Auf Basis früherer Lösungsfälle wird ein Entwurf des Runbooks erstellt
    • Ein Engineer prüft ihn einmal, passt ihn bei Bedarf an und klickt dann auf Verify
    • Jeder Schritt erhält eine Quelle

  • Execute

    • Runbooks werden in ausführbare Skills kompiliert
    • Schritte mit geringem Risiko werden automatisch ausgeführt
    • Aktionen mit blast radius stoppen beim festgelegten Freigebenden
    • Dasselbe Runbook kann in Slack, CLI, PagerDuty, Linear, Jira und im Web-Posteingang ausgeführt werden

Runbooks, die direkt im Slack-Thread ausgeführt werden

  • Es gibt ein Beispiel, in dem der Bot 4 Sekunden nach der Warnung im selben Thread ein Runbook postet, das mit 94 % Konfidenz einem bestehenden Cluster zugeordnet wurde
  • Das Beispiel-Cluster ist FX rate cache TTL fallback; das verifizierte Runbook v3 wurde 6-mal verwendet und hat eine Erfolgsquote von 83 %
  • Die Match-Signale sind wie folgt
    • Signature regex 94 %
    • Recent deploy proximity 87 %
    • Service overlap 100 %
    • Channel + reporter history 71 %
  • Das Beispiel-Runbook behandelt das Problem, dass veraltete FX-Rates für die Preisberechnung von Live-Trades verwendet werden
    • Während einer Redis-Eviction fällt der Cache-Miss-Pfad auf eine aus dem Load-Test 2025 verbliebene TTL-Konstante von 1 Stunde zurück
    • Das letzte Auftreten wird mit vor 11 Tagen angezeigt
    • Die Schritte check und verify werden automatisch ausgeführt, der Schritt fix erfordert eine Freigabe

Tatsächliche Fehler, die im Pilot geclustert wurden

  • Vom Pilot werden 3 von aktuell 7 geclusterten Beispielen offengelegt

  • FX rate cache TTL fallback set to 1 hour, not 1 minute

    • Die Bedingungen sind fx.rate.age_ms > 60000 und order.execution.status = filled
    • Der Cache-Miss-Pfad gibt die aus dem Load-Test verbliebene Konstante TTL_FALLBACK_MS = 3_600_000 zurück
    • Während Redis-Evictions zur Spitzenzeit wurden etwa 14k Symbole mit Raten bepreist, die älter als 60 Sekunden waren
    • In einem früheren Incident entstanden vor der manuellen Entdeckung 18 Minuten lang fehlbewertete Trades im Umfang von 340.000 $

  • Idempotency keys regenerated on retry → duplicate ACH debits

    • Die Bedingungen sind ach.duplicate_debit und idempotency_key.reused = false
    • Die Retry-Middleware erzeugt bei jedem 5xx einen neuen X-Idempotency-Key, anstatt den ursprünglichen Schlüssel wiederzuverwenden
    • Wenn von der Bank nach einer 504-Antwort noch eine 200-Antwort kommt, bucht der zweite Retry einen zweiten Debit
    • Im vergangenen Monat gab es 12 doppelte Debits; alle erforderten manuelle Rückabwicklung und eine Entschuldigung beim Kunden

  • Decimal precision drift between risk-svc and ledger-svc

    • Die Bedingungen sind pnl.reconcile.diff > 0.01 und services.disagree = [risk, ledger]
    • risk-svc deserialisiert Beträge als float64, während ledger-svc Decimal128 verwendet
    • Beim JSON-Round-Trip geht Sub-Cent-Präzision verloren, und die Differenz summiert sich über Tausende von Trades hinweg bis zur Auslösung einer Reconciliation am Nachmittag
    • Über 4 Wochen akkumulierten sich kleine Differenzen zu einer Recon-Differenz von 9,2k $, bevor sie entdeckt wurde
    • Als weitere Pilot-Cluster werden stripe webhook drops post-deploy, postgres pool exhaustion on report-gen, kafka rebalance storm und market-data WS subscription leak aufgeführt

Runbooks sind keine Wikis, sondern Ausführungsspezifikationen

  • Alle verifizierten Runbooks werden in YAML-Skills kompiliert
  • Der Skill enthält Trigger-Signatur, Schritte, erwartete Ausgaben und die festgelegten Freigebenden für riskante Aktionen
  • Bei jedem Speichern wird zusammen mit dem Runbook ein Drift-Check ausgeführt, damit Dokumentation und Ausführungsartefakt nicht auseinanderlaufen
  • Die Eigenschaften der Runbooks sind wie folgt
    • Schritte sind keine Pseudocode-Beschreibungen, sondern echte Shell-Befehle
    • Jeder fix-Schritt hat festgelegte Freigebende und einen expliziten blast radius
    • Jede Ausführung wird zu einem neuen Trainingsbeispiel für das nächste Matching
  • Das YAML-Beispiel zeigt das Runbook rb-fx-01
    • confidence_threshold ist 0,85
    • confirm_cache_age prüft Cache-Alter und Eviction-Rate in Redis
    • force_cache_refresh erfordert eine Freigabe; der blast radius beträgt etwa 14k Symbole und rund 2 Sekunden Preis-Pause
    • confirm_fresh_rates prüft, ob das maximale Alter unter 60 Sekunden liegt
    • Nach der Ausführung wird in #payments-platform, #platform-oncall benachrichtigt und ein Log unter einem S3-Pfad hinterlegt

Vertrauen und Governance

  • Die Grundhaltung ist read-only; Ausführung ist so ausgelegt, dass sie Freigabe-Gates durchläuft
  • Das Produkt wurde für Fintech entwickelt und bietet eine Haltung, mit der Security-Teams den Pilot freigeben und Auditoren Runs abzeichnen können
  • Datenhaltung und Deployment sind wie folgt
    • Rohdaten werden 90 Tage aufbewahrt
    • Redigierte Daten werden 18 Monate aufbewahrt
    • Im Pilot wurde die Freigabe durch Legal eingeholt
    • Single-Tenant-Deployment ist verfügbar
    • Trainingsdaten verlassen den Tenant nicht
  • PII-Redaktion erfolgt vor Embeddings oder LLM-Calls
    • E-Mail, IP, customer-id und ein konfigurierbares Secrets-Dictionary werden entfernt
    • Das ursprüngliche Artefakt bleibt am Ursprungsort
  • Alle Konnektoren starten schreibgeschützt
    • Ausführungsscopes werden pro Runbook vergeben
    • Festgelegte Freigebende sind erforderlich
    • Ein Entzug ist mit einem Klick möglich
  • Für alle Runbook-Schritte reicht die Provenienz bis zu den Lösungs-Incidents zurück, die als Lernquelle dienten
    • Audit-Logs pro Run werden signiert bereitgestellt
    • Export in ein SIEM ist möglich

Ausführungsoberflächen und Pilotbedingungen

  • Derselbe Skill funktioniert auf mehreren Oberflächen, die Teams bereits nutzen
    • Slack thread auto-suggest: Wenn eine bekannte Signatur auftritt, wird im selben Thread das passende Runbook gepostet
    • /pls fix CLI: Verwendet im Terminal dasselbe Runbook und dieselben Freigabe-Gates
    • PagerDuty incident page: Noch bevor der On-Call seine Eingabe abschließt, zeigt die Incident-Karte das passende Runbook mit One-Click-Run
    • Linear / Jira issue: Wird ein Issue mit bekannter Signatur geöffnet, wird das Runbook als Kommentar angehängt und die Ausführung vorgeschlagen
    • Web inbox: Platform Leads sehen Events, Cluster, Runs und Post-Mortems an einem Ort
  • Der Pilot ist ein Closed pilot und wird mit 4 Design-Partnern sowie Q2 2026 angegeben
  • Der 6-wöchige Pilot richtet sich an kleine Gruppen aus Fintech- und Platform-Teams
  • Der Ablauf ist schreibgeschütztes Ingest, gemeinsame Verifizierung eines Clusters und danach die Aktivierung von Auto-Suggest
  • Wenn bis Woche 4 das Volumen wiederkehrender Incidents nicht um 30 % sinkt, wird nichts berechnet
  • Das Setup für schreibgeschütztes Ingest dauert etwa 30 Minuten, in Woche 1 findet ein gemeinsames Cluster-Review statt, und bis Woche 4 gibt es keine Verpflichtung

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-05-22
Meinungen auf Hacker News

  • In den meisten Regionen würde das als kommerzielle Bestechung gelten.
    Nach California Penal Code § 641.3 macht sich ein Mitarbeiter der kommerziellen Bestechung schuldig, wenn er ohne Wissen oder Zustimmung seines Arbeitgebers Geld oder etwas von Wert dafür annimmt, seine Position zugunsten einer anderen Person einzusetzen.
    Diese Bestimmung gilt jedoch nicht, wenn der Betrag oder Wert 250 US-Dollar oder weniger beträgt.

    • Es wirkt, als liefere das Gesetz bereits eine praktische Lösung. Man müsste im Gebotsfeld nur eine <=250-Beschränkung setzen.
    • Wenn es gar keine anderen Mittel gibt, ist die Kernfrage, ob Bestechung zwingend schlecht ist. Wenn Big Tech sich darum gekümmert hätte, gäbe es Kundensupport; da das nicht der Fall ist, entwickelt der Markt gerade seine eigene Lösung.
    • Klingt so, als wäre es okay, solange es unter 250 US-Dollar pro Fall bleibt.
    • Seltsam. Werden dann auch Wahlkampfspenden auf 250 US-Dollar begrenzt?
    • Wenn man irgendwo in Social Media „Mein Konto wurde gesperrt“ postet, stürzen sich Bots darauf, die einem sagen, wen man zur Wiederherstellung kontaktieren soll.
      Aus meiner Sicht wirken Kontosperren wie eine unkontrollierte Erpressungsstruktur, betrieben von Social-Media-Mitarbeitern oder auf der Plattform selbst. Social Media war an sich schon in gewissem Maße fast ein Betrug und hat anonymen Betrügern immer wieder Gelegenheiten geschaffen, Menschen organisiert in die Irre zu führen.
      Social Media hat NFT, Crypto, Influencer-Kultur und alle möglichen „Fake it till you make it“-Strukturen vorangetrieben; es wäre besser, zu unabhängigen Web-Communitys zurückzukehren. Kurzfristig wäre das schmerzhaft, aber immer noch viel besser, als wenn Beiträge zur Bewerbung des eigenen Geschäfts nur 30 Aufrufe bekommen, weil man nicht bezahlt hat.

  • Das wirkt völlig verrückt. Jedes Unternehmen würde jemanden dafür selbstverständlich entlassen. Der genaue Name dafür ist Korruption, und die rechtlichen Folgen sollte man sich definitiv ebenfalls Sorgen machen.

    • Das ist eindeutig ein enormes Ethikproblem, aber gerade das macht es am interessantesten. Wegen der Themen Ethik, Compliance und Korruption könnte es intern in Unternehmen enorme Aufmerksamkeit erzeugen und sie dazu bringen, das Grundproblem tatsächlich auf dauerhaft wirksame Weise zu verbessern.
    • Wie andere schon gesagt haben, wird das künftig ein großes Problem werden.
      Jemand, der tatsächlich gesperrt werden sollte, etwa weil er illegale Inhalte hochgeladen hat, könnte diesen Dienst nutzen. Wenn das Unternehmen einem von einem internen Mitarbeiter eingereichten Formular vertraut und die Sperre aufhebt, wird diese Person weiter illegale Inhalte posten und erneut gesperrt werden.
      Wenn sich genug solcher True-Positive-Fälle ansammeln, wird das Unternehmen irgendwann feststellen, dass Mitarbeiter ihre Befugnisse nutzen, um beliebige Leute hereinzulassen. Ein kluges Unternehmen markiert von internen Mitarbeitern entsperrte Konten, sodass es das vielleicht schon beim ersten Fall erkennt.
      Das wahrscheinlichste Ende ist die Entlassung des betreffenden Mitarbeiters. Im schlimmsten Fall könnte das Unternehmen allen internen Mitarbeitern verbieten, Formulare für externe Personen einzureichen.
      Wenn diese Website ein Scherz ist, sollte sie das zumindest klar kennzeichnen. Ein bloßer Haftungsausschluss, man solle unbekannte Personen verifizieren, reicht nicht aus. Es ist auch fraglich, ob interne Mitarbeiter besser verifizieren können als der Kundensupport; Funktionen wie E-Mail-Versand oder Veröffentlichung sollten entfernt werden, damit tatsächliche Kontaktaufnahme und Geldüberweisung verhindert werden.
    • Stimme zu. Das ist eine Konstruktion, bei der jemand privat Geld annimmt und dann Arbeitszeit und Ressourcen des Unternehmens nutzt, um etwas zu tun, das der Arbeitgeber nicht will. Klingt nach einer schwachen Form von Bestechung.
      In der FAQ heißt es, die Anonymität der Mitarbeiter werde gewährleistet, gleichzeitig aber werde zur Verifizierung als Google-Mitarbeiter eine Bestätigungs-E-Mail an eine google.com-Adresse geschickt. Natürlich kann Google diese E-Mail sehen.
    • Zumindest bei Meta/Facebook war es seit Langem ein offenes Geheimnis, dass der schnellste Weg, etwas auf der Plattform schnell erledigt zu bekommen, darin besteht, jemanden bei Meta zu kennen.
    • Das würde ich gern glauben, aber als ich einige nur intern bei FAANG ausgeschriebene Stellen bearbeitete, schrieben externe Personen E-Mails, um sich nach diesen Positionen zu erkundigen. Später stellte sich heraus, dass es rund um bezahlte Empfehlungen eine eigene kleine Vermittlungsindustrie gab.

  • Professor Robert Klitgaard sagte: Korruption = Monopol + Ermessensspielraum - Transparenz. Ursprünglich schrieb er das über politische Systeme und Bestechung, aber es trifft auch hier zu.
    https://globalanticorruptionblog.com/2014/05/27/klitgaards-m...
    Viele Tech-Unternehmen haben in ihrem Markt ein Monopol, unbegrenzten Ermessensspielraum und nahezu keine Transparenz. Es ist eher überraschend, dass niemand früher auf die Idee für ein Schmiergeld-für-schnellere-Bearbeitung-Startup gekommen ist.
    https://en.wikipedia.org/wiki/Facilitating_payment
    Die meisten Kommentare sehen darin ein schlechtes Geschäft für den Mitarbeiter, und bei 500 US-Dollar für das Aufheben einer Kontosperre mag das stimmen. Aber wenn jemand mit einem Jahresgehalt von 300.000 US-Dollar in einer Struktur festhängt, in der die 2FA-Codes aller Konten per E-Mail kommen, oder ein Social-Media-basiertes Geschäft betreibt, zahlt er möglicherweise weit mehr als 500 US-Dollar, um sein Konto zurückzubekommen.
    Big-Tech-Mitarbeiter sitzen auch nicht alle in San Francisco. In Regionen mit niedrigeren Lebenshaltungskosten wie Europa verdienen viele ungefähr die Hälfte von Amerikanern, und je niedriger das Einkommen, desto anfälliger ist man für solche Versuchungen.
    Ich verteidige Bestechung nicht, aber ich finde es überraschend, wie nahezu einhellig die Reaktion ist, dass es unrealistisch sei, Mitarbeiter von Social-Media-Unternehmen zu bezahlen. Historisch sind Systeme ohne Transparenz, in denen Mitarbeiter über in Geld umwandelbaren Ermessensspielraum verfügen, korrupt geworden.
    Tech-Unternehmen sollten das ernster nehmen. Wenn Menschen sich daran gewöhnen, Geld zu bezahlen, um von Entscheidungsträgern fair behandelt zu werden, ist es sehr schwer, dieses Verhalten wieder zu ändern.

    • Die einzige Gewinnstrategie ist, nicht mitzuspielen. Social Media ist eine Plage der Menschheit.

  • Auf der einen Seite steht ein Verhalten, das praktisch garantiert zur Kündigung führt, auf der anderen Seite stehen 150 $.
    Ich habe früher bei FB gearbeitet, und es gab dort ein Team, das Mitarbeiter aufspürte, die auf diese Weise Zugriffsrechte verkauften. Für einen Betrag, der für die meisten technischen Rollen dort praktisch etwa einem Stundenlohn entspricht, ein solches Risiko einzugehen, ist schwer vorstellbar.

    • Plot Twist: Das könnte ein Honeypot-Marktplatz sein, um Mitarbeiter zu erwischen, die auf diese Weise Zugriffsrechte verkaufen.
    • Stimmt, für so etwas Rückvergütungen anzunehmen, wirkt skrupellos. Andererseits kann ich mir vorstellen, dass man in der Lage, von so einem Problem betroffen zu sein, sogar einen Insider bezahlen würde, um es lösen zu lassen.
      Es geht nicht nur um ein simples technisches Problem, also etwa eine Kontosperrung, sondern vor allem um das Gefühl, von Anfang an ungerecht behandelt worden zu sein, und die Wut, in einer endlosen Höllenschleife festzustecken.
    • Für alle, die FB nicht gut kennen: maxrmk hat recht. Um etwas Kontext zu ergänzen: Wenn eines der Privacy-Teams so einen Verstoß entdeckt, wird der Mitarbeiter normalerweise zu einem HR-Meeting gebeten und direkt am nächsten Tag entlassen.
      Ein Freund von mir hat so etwas unbeabsichtigt getan, als er einem persönlich bekannten Freund bei einem Kontoproblem helfen wollte. Er wusste nicht, dass es ein Privacy-Verstoß war, und griff auf das System zu. Monate später wurde bei der Untersuchung von Projektdaten ein Audit ausgelöst; als der Eintrag gefunden wurde, wurde er schon am nächsten Tag aus dem Unternehmen entfernt.
      Deshalb ist das keine gute Geschäftsidee.
    • Was man wirklich braucht, ist, bei diesem Ermittlungsteam anzuheuern und die Fähigkeit zu verkaufen, dass dieses Team Fälle übersieht. Der Name wäre dann ungefähr plsfixmyfix.com.
    • Aus Sicht von jemandem, der bei einem dieser Unternehmen arbeitet: Dieses Risiko ist es absolut nicht wert.

  • Vielleicht bin nur ich es, aber viele scheinen das große Ganze zu übersehen. Solche Services entstehen nur, wenn die normalen Lösungswege das Problem nicht beheben.
    Für mich ist das eher ein Signal, dass Big Tech es nicht geschafft hat, ein wirksames Einspruchsverfahren zu schaffen, das der Nachfrage der Nutzer entspricht. Viel Geld wird damit wohl nicht zu verdienen sein, aber es wäre interessant zu sehen, wie Big Tech diesen Bereich verbessert.

    • Ich glaube nicht. Ineffizienz ist der Kern. Dieser Service ist ein Witz und ziemlich sicher illegal. Alle wissen, dass dieses System „kaputt“ ist, aber kostenlosen Kundensupport kann man nicht unbegrenzt skalieren.
      Die legitime Nachfrage nach solchen Services beweist den Wert dieser Konten. Ich denke, dass Tech-Unternehmen in ein paar Jahren selbst in diesen Bereich einsteigen und bezahlten Kundensupport anbieten werden, wie ihn Unternehmenskunden bekommen. Für „verifizierte“ Konten kann man bereits zahlen, also ist das der nächste Schritt. Wenn die Unternehmen es nicht monetarisieren, wird der Staat es regulieren.
    • Bevor es das gab, kamen die meisten internen Anfragen vermutlich von Mitarbeitern, die tatsächlich jemandem helfen wollten. Natürlich kann es auch schon Mitarbeiter gegeben haben, die gegen Bezahlung interne Formulare eingereicht haben, aber wahrscheinlich war das nicht weit verbreitet.
      Wenn man den Ablauf wie auf dieser Website formalisiert, wird es deutlich wahrscheinlicher, dass interne Formulare zur Aufhebung von Kontosperren gegen Geld eingereicht werden. Denn man schafft einen Marktplatz, der Antragsteller mit skrupellosen Mitarbeitern zusammenbringt, senkt die Reibung bei der Durchführung der Transaktion und zieht mit offen in Aussicht gestelltem Geld Mitarbeiter an, die eher auf Geld aus sind, statt zu helfen, weil jemand zu Unrecht gesperrt wurde.
      Deshalb wirkt das wie eine deutlich ethisch abstoßendere Struktur als der bisherige Prozess.
    • Die Mehrheit auf HN dürfte wissen, dass Big Tech kein wirksames Einspruchsverfahren geschaffen hat. Das ist überhaupt kein Geheimnis. Trotzdem ist dieser Service offene Korruption.

  • Ich habe früher schon einen unternehmerischeren Ansatz gesehen: Ein OnlyFans-Model habe Mitarbeiter auf LinkedIn gesucht und Sex gegen die Aufhebung einer Kontosperre getauscht, um ihr Instagram-Konto zurückzubekommen.
    https://www.newsweek.com/onlyfans-star-slept-meta-employees-...

  • Wie prüft man, ob der Antragsteller wirklich eine normale Person ist, die völlig grundlos gesperrt wurde, oder jemand, der aus rechtlichen Gründen wie CSAM oder wegen eines Verstoßes gegen die Nutzungsbedingungen zu Recht gesperrt wurde?
    Wenn Mike Meta entlassen wird, weil er versucht hat, ein echtes Terroristenkonto wieder freizuschalten — zumal offensichtlich interne Erwähnungen überwacht werden —, übernimmt dieser Service dann die Verantwortung dafür?

    • Ein „verifizierter Mitarbeiter“ des Unternehmens könnte selbst nachforschen, bevor er die passenden Unterlagen einreicht. Aber dann entsteht normalerweise eine eigene Dokumentationsspur, die am Ende sehr wahrscheinlich auf ihn zurückfällt.
      Ehrlich gesagt überwiegt hier das Risiko den Nutzen bei weitem. Ich verstehe gar nicht, warum das überhaupt jemand machen sollte.
      „Stabiler Job mit sechsstelligem Jahreseinkommen“ versus „einmalig 100 $ von einem Fremden aus dem Internet“ — die Antwort ist offensichtlich.
      Ehrlich gesagt riecht das nach einer Falle.
    • Es dürfte ähnlich laufen wie bei Fällen, in denen die traurige Geschichte einer Person viral geht und das Problem dann gelöst wird. Ein Mitarbeiter sieht das und erstellt ein Ticket nach dem Motto: „Diese unbekannte Person hat Problem XYZ“, und der Support untersucht es und ergreift die passende Maßnahme.
      Wie der tatsächliche Prozess bei Meta aussieht, weiß ich nicht.
    • Soweit ich weiß, ist eine häufige Ursache für eingefrorene Konten, dass das Konto als von jemand anderem übernommen erkannt wird. Wenn man einen beschleunigten Umgehungskanal schaffen will, um den Zugriff auf solche Konten wiederherzustellen, muss das sehr sorgfältig implementiert werden.

  • Ich musste nachsehen, ob heute der erste April ist. Das ist eines der schockierendsten Dinge, die ich in letzter Zeit gesehen habe. Ich hoffe aufrichtig, dass die Leute, die davon profitieren, zumindest entlassen werden.

    • Das Konzept selbst wirkt wie eine Art Performance-Art-Protest.
      Eine Plattform zu bauen, um die undurchsichtigen Nicht-Kundensupport-Systeme dieser Unternehmen mit Bestechung zu durchqueren, ist entweder Korruption auf niedrigem Niveau oder Kunst auf hohem Niveau.
    • Mitarbeiter, die sich bei diesem Service anmelden, sollten vorsichtig sein. Facebook wird diese Person mit Sicherheit verklagen, und Zahlungsaufzeichnungen werden bei der Beweisaufnahme zu den ersten Unterlagen gehören, die herausgegeben werden müssen.
      Ich sehe keine Möglichkeit, wie Anonymität lange gewährleistet bleiben soll.
    • Eher scheint es einen Teil der Rechte gewöhnlicher Menschen zurückzugeben, die große Tech-Konzerne offenbar nicht zu respektieren meinen.

  • Ich verstehe vollkommen, warum das als unethisch angesehen wird. Ich verstehe auch, dass Mitarbeiter, die solche Prämien annehmen, entlassen werden
    Aber gegen welches Gesetz verstößt das eigentlich? Rechtlich wirkt es zwar wie Bestechung, weil es eine ungewöhnliche Maßnahme fördert. Gemeint ist aber genau dieser Teil „ungewöhnlich“. Könnte ein Unternehmen vor Gericht gehen und das strafrechtlich verfolgen, während es einräumt, dass sein Verfahren zur Anfechtung einer Sperrung ungewöhnlich ist?
    Und gegen welche Klausel eines Standard-Arbeitsvertrags verstößt es? Geld dafür zu nehmen, eine Dienstleistung zu erbringen, die der Arbeitgeber nicht anbietet? Interessanterweise wäre es, wenn der Arbeitgeber diese Dienstleistung anböte, keine Bestechung mehr, sondern eine legale Expressgebühr; um das zu verhindern, müsste man also eine gesonderte Klausel in den Arbeitsvertrag aufnehmen
    Das ist keine rhetorische Frage, ich suche wirklich nach einer Antwort
    In vielerlei Hinsicht passiert dieser Prozess bereits, und die Beteiligten erwarten ihn in gewissem Maße auch. Ich habe schon mehrfach Fälle gesehen, in denen eine Entscheidung offenbar gekippt wurde, weil eine Twitter-Berühmtheit genug Lärm machen konnte; solche Fälle landeten auch hier auf der Frontpage. Der Unterschied liegt nur in der Art der Währung, die verwendet wird, um das System zu umgehen

    • Es gibt eine einfache Lösung. Man macht den Betrag zu einer Spende an eine Wohltätigkeitsorganisation ihrer Wahl. Es könnte auch eine Organisation sein, an die das Unternehmen jährlich spendet; dann wird es deutlich schwieriger, jemanden zu entlassen, der Geld für eine Wohltätigkeitsorganisation einbringt
    • Das nennt man kommerzielle Bestechung. Allerdings regeln so etwas normalerweise bundesstaatliche Gesetze, daher hängt es von der Gerichtsbarkeit ab. Jemand anderes hat die kalifornischen Gesetzesstellen gepostet
      In Kalifornien greift das Gesetz nicht, wenn der Betrag unter 250 US-Dollar liegt, aber auf der ursprünglichen Website gibt es etliche „Prämien“, die über dieser Schwelle liegen
      Ich weiß nicht, ob es Standard ist, aber viele Mitarbeiter unterschreiben Dokumente, in denen sie zusagen, keine andere Beschäftigung anzunehmen. Ich weiß nicht, ob so etwas als „Beschäftigung“ gilt. Es würde mich aber nicht überraschen, wenn manche Arbeitsverträge weiter gefasste Formulierungen enthalten, etwa „keine externe bezahlte Tätigkeit“
      [0] https://news.ycombinator.com/item?id=40435890
    • Die Arbeitsverträge, die ich abgeschlossen habe, verlangten zumindest, kommerzielle Tätigkeiten außerhalb des Unternehmens offenzulegen, und manchmal, vor Beginn eine Genehmigung einzuholen. Wenn man eine nicht offengelegte zweite bezahlte Tätigkeit hat, reicht das als Kündigungsgrund aus, falls das Unternehmen das möchte
    • Aus Sicht des Mitarbeiters, der die Dienstleistung erbringt, ist es sehr wahrscheinlich zumindest ein Vertragsbruch

  • Nur zur Einordnung: Weil ich bei Google und Stripe Bekannte hatte, konnte mein Startup eine existenzbedrohende Katastrophe überleben. In beiden Fällen hatten uns automatisierte Systeme fälschlicherweise markiert und die Zahlungsabwicklung gestoppt; es gab keinen anderen Weg
    Nur weil es interne Kontakte gab, konnten wir Einspruch bei jemandem einlegen, der tatsächlich eine Entscheidung treffen konnte
    Ich halte solche Plattformen nicht für in Ordnung. Sie haben eine ethisch fragwürdige Seite. Wichtig ist aber: Wenn man nicht persönlich ein paar hochrangige Kontakte bei dem Unternehmen kennt, von dem man abhängig sein will, sollte man diese Abhängigkeit nicht eingehen

    • Für dich ist es also in Ordnung, Kontakte zu nutzen, um eine „existenzbedrohende Katastrophe“ zu vermeiden, aber wenn andere dasselbe versuchen, ist das ethisch fragwürdig?
    • Auf den ersten Blick wirkt das widersprüchlich. Es scheint gegen eine Ethik des Privilegs zu verstoßen. Vielleicht wäre es besser und fairer, wenn einfach alle dafür bezahlen würden