Plsfix — プラットフォームエンジニアリングのための Issue Brain
(plsfix.co)- plsfixは、すでに解決済みのインシデント記録を集めて検証済みランブックと実行可能なskillに変換し、同じ障害が繰り返された場合はスレッド内でそのまま実行ボタンを提供する
- フローは読み取り専用の収集、反復インシデントのクラスタリング、エンジニアによる検証、実行の段階へと進み、各段階はチームの過去の解決事例に基づく
- パイロット例では14,802件のイベントから7つの反復クラスターを見つけ、新規イベントの22%が自動解決され、Slackの例では通知の4秒後に94%の信頼度でランブックをマッチングしている
- ランブックはYAML skillにコンパイルされ、安全なステップは自動実行されるが、blast radiusのある修正は指定された承認者のところで停止する
- フィンテックおよびプラットフォームチーム向けの6週間パイロットは、4週目までに反復インシデント量を30%削減できなければ費用を請求せず、読み取り専用の収集設定には約30分かかる
反復障害を実行可能な知識に変えるプロダクト
- plsfixは、チームがすでに解決したインシデントをSlack、PagerDuty、GitHub、Claudeなどから取り込み、検証済みランブックと実行可能なskillに変換する
- 同じ形の障害が再び発生すると、ボットが同じスレッドに回答を投稿し、ユーザーはRun playbookを1回クリックするだけで実行できる
- 初期画面のパイロット指標は、acmeパイロット1週目のデータとして表示されている
- 14,802件のイベントを収集
- 7つの反復クラスターを特定
- 新規イベントの22%を自動解決
解決知識が散在し、反復障害が大きくなる問題
- 多くの障害は完全に新しい問題ではなく、過去に解決したものの記憶されていない反復障害に近い
- 例として、シニアエンジニアが午前3時にSlackスレッドにあった正確な解決策をもう一度探さなければならない状況が挙げられている
- 解決プロセスは複数のツールに分散して残る
- PagerDutyにはacknowledgeがある
- Claudeスレッドには診断がある
- クローズ済みPRコメントには実際の修正がある
- plsfixはプロンプトだけでランブックを作るのではなく、チームが過去に実際に解決したインシデントから各ステップを追跡する
収集から実行までの4段階
-
Ingest
- 読み取り専用コネクターが、チームが実際に問題を解決している場所から解決済みの作業を取り込む
- クラスタリングの前にPIIを削除する
- 接続先はSlack、PagerDuty、GitHub、Jira、Linear、ServiceNow、Notion、Claude / ChatGPT
-
Cluster
- 反復インシデントのsignatureを学習する
- signatureは、アラートpayloadのregex、サービス群、デプロイとの近接性、チャネルと報告者のパターンなどで構成される
- 同じ形の障害は同じクラスターに分類される
-
Verify
- 過去の解決事例をもとにランブックのドラフトを作る
- エンジニアが一度レビューし、必要に応じて修正したうえでVerifyを押す
- すべてのステップに出典が付く
-
Execute
- ランブックは実行可能なskillにコンパイルされる
- 低リスクのステップは自動実行される
- blast radiusのある作業は指定された承認者のところで停止する
- Slack、CLI、PagerDuty、Linear、Jira、Web inboxから同じランブックを実行できる
Slackスレッドからそのまま実行されるランブック
- 通知の4秒後に、ボットが94%の信頼度で既存クラスターとマッチしたランブックを同じスレッドに投稿する例がある
- 例のクラスターはFX rate cache TTL fallbackで、検証済みランブックv3は6回使用され、成功率は83%
- マッチングシグナルは次のとおり
- Signature regex 94%
- Recent deploy proximity 87%
- Service overlap 100%
- Channel + reporter history 71%
- ランブック例は、古いFXレートがlive tradesの価格に使われる問題を扱う
- Redis eviction中にcache miss pathが、2025年のload testから残った1時間TTL定数へfallbackする
- 最後の発生は11日前と表示される
- checkとverifyステップは自動実行され、fixステップは承認が必要
パイロットでクラスタリングした実際の欠陥
- パイロットで現在クラスタリングしている7件のうち、3件の例が公開されている
-
FX rate cache TTL fallback set to 1 hour, not 1 minute
- 条件は
fx.rate.age_ms > 60000およびorder.execution.status = filled - cache miss pathがload testから残った
TTL_FALLBACK_MS = 3_600_000定数を返す - ピーク時のRedis eviction中に、約14k個のsymbolが60秒より古いrateで価格算定された
- 以前のインシデントでは、手動で発見されるまでの18分間に$340k規模のmispriced tradesが発生した
- 条件は
-
Idempotency keys regenerated on retry → duplicate ACH debits
- 条件は
ach.duplicate_debitおよびidempotency_key.reused = false - retry middlewareが5xxごとに元のキーを再利用せず、新しい
X-Idempotency-Keyを発行する - 銀行から504の後に200応答が来る場合、2回目のretryが2回目のdebitを投稿する
- 先月は12件の重複debitがあり、すべて手動reversalと顧客への謝罪が必要だった
- 条件は
-
Decimal precision drift between risk-svc and ledger-svc
- 条件は
pnl.reconcile.diff > 0.01およびservices.disagree = [risk, ledger] risk-svcは金額をfloat64としてデシリアライズし、ledger-svcはDecimal128を使用する- JSON round-tripでsub-cent precisionが失われ、差分が数千件の取引に蓄積して午後中にreconciliationをトリガーする
- 4週間にわたって小さな差分が蓄積し、$9.2kのrecon deltaになった後で発見された
- その他のpilotクラスターとして、stripe webhook drops post-deploy、postgres pool exhaustion on report-gen、kafka rebalance storm、market-data WS subscription leakが挙げられている
- 条件は
ランブックはWikiではなく実行仕様
- 検証済みのすべてのランブックはYAML skillにコンパイルされる
- skillにはtrigger signature、steps、expected outputs、リスクのある作業の指定承認者が含まれる
- 保存するたびにランブックとdrift checkを実行し、ドキュメントと実行物が分岐しないようにする
- ランブックの属性は次のとおり
- ステップは擬似コードではなく実際のshell command
- 各
fixステップには指定承認者と明示されたblast radiusがある - すべての実行は次のマッチングのための新しいtraining exampleになる
- YAML例は
rb-fx-01ランブックを示しているconfidence_thresholdは0.85confirm_cache_ageはRedisでcache ageとeviction rateを確認するforce_cache_refreshは承認が必要で、blast radiusは約14k symbolsと約2秒のpricing pauseconfirm_fresh_ratesはmax ageが60秒未満かを確認する- 実行後、
#payments-platform、#platform-oncallに通知し、S3パスにログを残す
信頼とガバナンス
- 基本姿勢はread-onlyであり、実行は承認ゲートを通過するよう設計されている
- フィンテック向けに作られており、セキュリティチームがpilotを承認し、auditorがrunに署名できるpostureを提供する
- データ保持と配置は次のとおり
- rawデータは90日保持
- redactedデータは18カ月保持
- pilotでLegal承認を取得
- single-tenant deploymentを利用可能
- training dataはtenantの外に出ない
- PII redactionはembeddingまたはLLM callの前に実行される
- email、IP、customer-id、configurable secrets dictionaryが削除される
- 元のartifactは元の場所に残る
- connectorはすべてread-onlyで開始する
- 実行scopeはrunbookごとに付与される
- 指定承認者が必要
- 1クリックでrevokeできる
- すべてのrunbookステップは、学習元となった解決インシデントまでprovenanceがつながる
- runごとのaudit logはsigned状態で提供される
- SIEMへexportできる
実行面とパイロット条件
- 同じskillは、チームがすでに使っている複数の表面で動作する
- Slack thread auto-suggest: 見慣れたsignatureが発生すると、同じスレッドにマッチしたランブックを投稿する
/pls fixCLI: ターミナルで同じランブックと承認ゲートを使用する- PagerDuty incident page: on-callが入力を終える前に、incident cardにマッチしたランブックとone-click runを表示する
- Linear / Jira issue: 既知のsignatureでissueを開くと、commentとしてランブックを添付し、実行を提案する
- Web inbox: platform leadがevent、cluster、run、post-mortemを1カ所で確認できる
- パイロットはClosed pilotで、4社のdesign partnerと2026年Q2と表示されている
- 6週間のpilotは、fintechとplatform teamの小規模グループを対象とする
- 進め方は、読み取り専用ingest、1つのclusterの共同検証、auto-suggest有効化の順
- 4週目にrecurring incident volumeを30%削減できなければ費用を請求しない
- 読み取り専用ingestの設定には約30分かかり、1週目にjoint cluster reviewを行い、4週目まではcommitmentがない
1件のコメント
Hacker Newsのコメント
ほとんどの地域では、これは商業賄賂に当たる
California Penal Code § 641.3 によれば、従業員が雇用主の認識または同意なしに、自分の地位を他者のために使う対価として金銭や価値のあるものを受け取ると、商業賄賂罪になる
ただし、金額または価値が**$250以下**の場合、この条項は適用されない
私の見方では、アカウントロックはソーシャルメディア従業員、あるいはプラットフォーム上で動く制御されていない恐喝の仕組みのように見える。ソーシャルメディア自体もある程度詐欺に近く、匿名の詐欺師たちが人を惑わせる活動を組織する機会を作り続けてきた
ソーシャルメディアは NFT、Crypto、インフルエンサー文化、各種の「できるまでできるふりをする」類いの仕組みを後押ししてきたし、いっそ独立した Web コミュニティに戻るほうがいい。しばらくは痛みを伴うだろうが、お金を払わなかったという理由で事業宣伝の投稿の閲覧数が 30 回にとどまるよりは、はるかにましだ
狂っているように見える。どの会社でもこんなことをしたら当然解雇されるはずだ。正確な名前は汚職であり、法的影響も明らかに懸念すべきだ
実際に停止されるべき人、たとえば違法コンテンツを投稿した人がこのサービスを利用できる。会社が社内従業員の作成したフォームを信じて停止を解除すれば、その人は違法コンテンツを投稿し続け、また停止されるだろう
こうした真陽性の事例が十分に積み上がれば、会社は最終的に従業員が権限を使って誰でも通していることに気づく。賢い会社なら社内従業員が解除したアカウントに印を付けているはずなので、最初の事例から見抜けるかもしれない
もっとも可能性の高い結末は、その従業員の解雇だ。最悪の場合、会社がすべての社内従業員に対して外部者のためのフォーム提出を禁じることもありうる
このサイトが冗談なら、少なくともその点を明確に表示すべきだ。単に知らない相手を検証しろという免責文では不十分だ。社内従業員がカスタマーサポートよりうまく検証できるかも疑わしいし、実際の連絡や送金を防ぐためにメール送信や公開といった機能を削除すべきだ
FAQ では従業員の匿名性を保証するとしているが、同時に google.com のメールアドレスに確認メールを送り、Google 従業員かどうかを検証すると書かれている。もちろん Google はそのメールを見ることができる
Robert Klitgaard 教授は、汚職 = 独占 + 裁量 - 透明性だと言った。もともとは政治システムと賄賂について書かれた言葉だが、ここにも当てはまる
https://globalanticorruptionblog.com/2014/05/27/klitgaards-m...
多くのテック企業は、自らの市場で独占、無限の裁量、ゼロに近い透明性を持っている。通行料スタートアップを誰かがもっと早く思いつかなかったことのほうがむしろ驚きだ
https://en.wikipedia.org/wiki/Facilitating_payment
コメントの大半は従業員にとって割に合わない取引だと見ているが、$500 でアカウント停止を解除する程度ならそうかもしれない。しかし年収 $300k を受け取る人でも、すべてのアカウントの 2FA コードがメールに送られる構造に縛られていたり、ソーシャルメディアベースの事業をしていたりするなら、アカウントを取り戻すために $500 よりはるかに多く払えるだろう
Big Tech の従業員がみな San Francisco にいるわけでもない。ヨーロッパのような低コスト地域には、米国人の半分程度しか稼がない人も多く、所得が低いほどこうした誘惑に弱い
賄賂を擁護するつもりはないが、ソーシャルメディア企業の従業員に金を払うことが非現実的だという反応がほぼ満場一致なのは驚きだ。歴史的に見て、透明性がなく、従業員に金銭換算可能な裁量があるシステムは腐敗してきた
テック企業はこれをもっと深刻に受け止めるべきだ。意思決定者から公正な扱いを受けるために金を払うことに人々が慣れてしまうと、その行動を変えるのは非常に難しくなる
片方には事実上 解雇が確定する行為 があり、もう片方には150ドルがある
昔FBで働いていたが、こういう形でアクセス権を売る社員を摘発するチームがあった。そこの大半の技術職にとって、実質1時間分の給料ほどの金のためにそんなリスクを負うのは想像しがたい
単なる技術的な問題、つまりアカウント停止だけでなく、そもそも不当だという感覚と、終わりのない地獄ループに閉じ込められた怒りが核心だ
私の友人は、個人的に知っている友人のアカウント問題を助けようとして、意図せずこうしたことをしてしまった。本人はプライバシー違反だと知らずにシステムへアクセスしたが、数か月後にプロジェクトデータを調査していた際に監査がトリガーされ、その記録が見つかった翌日に退職処理された
だから、これは良いビジネスアイデアではない
自分だけかもしれないが、多くの人が大きな構図を見落としている気がする。こういうサービスは、通常の解決策が問題を解決できないときにしか生まれない
私には、Big Tech が消費者の需要に合った 実効的な異議申し立て手続き を作れていないことのシグナルに見える。大きな収益にはならないだろうが、Big Tech がこの部分をどう改善するのか見てみたい
こうしたサービスへの正当な需要は、それらのアカウントに価値があることを示している。数年以内にテック企業がここへ直接参入して、法人顧客が受けているような 有料カスタマーサポート を提供するようになると思う。すでに「認証」アカウントに金を払えるのだから、次の段階はこれだ。企業が収益化しなければ政府が規制するだろう
このウェブサイトのように手続きを公式化すると、アカウント停止解除用の社内フォーム提出が金銭の対価として行われる可能性がはるかに高くなる。申請者と不誠実な社員をマッチングする市場を作り、取引実行の摩擦を減らし、露骨に金を前面に出すことで、不当に停止された人を助けるより金目当ての社員を引き寄せるからだ
だから、既存の手続きよりはるかに 倫理的におぞましい構造 に見える
以前、もっと起業家的なアプローチを見たことがある。OnlyFans モデルが LinkedIn で社員を見つけ、性行為とアカウント停止解除 を取引して Instagram アカウントを取り戻したという話だ
https://www.newsweek.com/onlyfans-star-slept-meta-employees-...
依頼者が本当に理由もなくブロックされた普通の人なのか、それとも CSAM のような法的理由や利用規約違反で正当にブロックされた人なのか、どうやって検証するのか?
Mike Meta が実際にテロリストのアカウントを解除しようとして解雇されたら、特に社内での言及が監視されているのは明らかなのに、その責任をこのサービスが負うのか?
正直、ここでは利益よりリスクのほうがはるかに大きい。そもそもなぜ誰かがこれをやろうとするのか分からない
「安定収入の6桁年収の仕事」対「インターネットに疎い人から受け取る一度きりの100ドル」なら、答えは明らかだ
正直、おとり捜査の匂いがする
Meta の実際の手順は知らない
今日がエイプリルフールか確認しなければならなかった。最近見た投稿の中でも最も衝撃的なものの1つだ。これで利益を得る人たちは、少なくとも解雇されることを心から願う
こうした企業の不透明な非カスタマーサポートシステムを、賄賂で通り抜けるためのプラットフォームを作るというのは、低レベルの腐敗か高レベルのアートだ
匿名性が長く保証される方法には見えない
これが非倫理的だと見なされる理由は完全に理解できる。報奨金を受け取る従業員が解雇されることも理解できる。
ただ、実際にはどの法律に違反するのだろうか？ 異例の措置を促すので、法的には賄賂に当たりそうではある。ただし、それはその「異例の」という部分ゆえだと思う。会社が法廷で、自社の停止に対する異議申し立て手続きが異例のものだと認めたうえで、これを起訴できるのだろうか？
そして標準的な雇用契約のどの条項に違反するのだろうか？ 雇用主が提供していないサービスを行って金を受け取ることだろうか？ 興味深いことに、雇用主がそのサービスを提供しているなら、それはもはや賄賂ではなく合法的な優先料金になるので、これを防ぐには雇用契約に別の条項を入れる必要があるはずだ。
修辞的な質問ではなく、本当に答えを探している。
多くの面でこのプロセスはすでに起きており、関係者もある程度は予期している。Twitterの有名人が十分な騒ぎを起こせたために決定が覆ったように見えるケースを何度も見たし、それがここのフロントページに載ったこともあった。違いは、システムを迂回するために使われる通貨の種類だけだ。
カリフォルニア州では金額が$250未満なら法律は適用されないが、元記事のサイトにはその基準を超える「報奨金」がかなりある。
標準的かどうかはわからないが、多くの従業員は他の雇用を受けないという文書に署名している。これが「雇用」に当たるのかはわからない。ただ、一部の雇用契約に「外部の有償業務禁止」のような、より広い表現が入っていても驚きではない。
[0] https://news.ycombinator.com/item?id=40435890
参考までに、GoogleとStripeに知り合いがいたおかげで、私のスタートアップは壊滅級の災害から生き延びることができた。両社とも自動化システムが私たちを誤検知して決済処理を止めてしまい、他に手段がなかった。
内部の人がいたからこそ、実際に判断できる人に異議申し立てを届けることができた。
こうしたプラットフォームが良いとは思わない。倫理的に疑わしい面がある。しかし、依存しようとしている会社に上級職の知人を何人か個人的に知らないのなら、その依存関係を持つべきではない、という点は重要だ。