Plsfix — Issue Brain para engenharia de plataformas

• O plsfix reúne registros de incidentes já resolvidos, transforma isso em runbooks validados e skills executáveis e, quando a mesma falha se repete, oferece um botão de execução diretamente na thread
• O fluxo segue de coleta somente leitura, clusterização de incidentes recorrentes, validação por engenheiros e execução, e cada etapa se baseia em casos de resolução anteriores da equipe
• No exemplo de piloto, encontrou 7 clusters recorrentes em 14.802 eventos, resolveu automaticamente 22% dos novos eventos e, no exemplo do Slack, associou um runbook 4 segundos após o alerta com 94% de confiança
• Os runbooks são compilados em skills YAML, etapas seguras são executadas automaticamente, mas correções com blast radius param no aprovador designado
• O piloto de 6 semanas para equipes de fintech e plataforma não cobra se, até a 4ª semana, não reduzir em 30% o volume de incidentes recorrentes, e a configuração da coleta somente leitura leva cerca de 30 minutos

---

Um produto que transforma falhas recorrentes em conhecimento executável

• O plsfix importa incidentes que a equipe já resolveu a partir de Slack, PagerDuty, GitHub, Claude e outros, e os converte em runbooks validados e skills executáveis
• Quando uma falha do mesmo tipo acontece de novo, o bot responde na mesma thread, e o usuário pode executar com um clique em Run playbook
• Os indicadores do piloto na tela inicial mostram dados da 1ª semana do piloto da acme
  • 14.802 eventos coletados
  • 7 clusters recorrentes identificados
  • 22% dos novos eventos resolvidos automaticamente

O problema do conhecimento de resolução espalhado, que amplia falhas recorrentes

• Muitas falhas não são problemas totalmente novos, mas sim incidentes recorrentes que já foram resolvidos no passado, porém não são lembrados
• O exemplo mostra um engenheiro sênior precisando reencontrar às 3 da manhã a solução exata que estava em uma thread do Slack
• O processo de resolução fica espalhado por várias ferramentas
  • No PagerDuty há o acknowledge
  • Na thread do Claude há o diagnóstico
  • Nos comentários do PR fechado está a correção real
• Em vez de criar runbooks só com prompts, o plsfix rastreia cada etapa a partir de incidentes que a equipe realmente resolveu no passado

As 4 etapas, da coleta à execução

• Ingest

  • Conectores somente leitura importam trabalhos resolvidos dos lugares onde a equipe realmente resolve problemas
  • Remove PII antes da clusterização
  • Os alvos de conexão são Slack, PagerDuty, GitHub, Jira, Linear, ServiceNow, Notion e Claude / ChatGPT

• Cluster

  • Aprende a signature de incidentes recorrentes
  • A signature é composta por regex do payload de alerta, conjunto de serviços, proximidade de deploy, padrões de canal e de quem reportou, entre outros
  • Falhas do mesmo tipo são classificadas no mesmo cluster

• Verify

  • Cria um rascunho de runbook com base em casos de resolução anteriores
  • Um engenheiro revisa uma vez e, se necessário, ajusta antes de clicar em Verify
  • Todas as etapas recebem sua fonte

• Execute

  • Os runbooks são compilados em skills executáveis
  • Etapas de baixo risco são executadas automaticamente
  • Ações com blast radius param no aprovador designado
  • O mesmo runbook pode ser executado no Slack, CLI, PagerDuty, Linear, Jira e Web inbox

Runbooks executados diretamente na thread do Slack

• Há um exemplo em que, 4 segundos após o alerta, o bot publica na mesma thread um runbook associado a um cluster existente com 94% de confiança
• O cluster do exemplo é FX rate cache TTL fallback, e o runbook validado v3 foi usado 6 vezes com taxa de sucesso de 83%
• Os sinais de associação são os seguintes
  • Signature regex 94%
  • Recent deploy proximity 87%
  • Service overlap 100%
  • Channel + reporter history 71%
• O exemplo de runbook trata do problema em que stale FX rates são usados na precificação de live trades
  • Durante eviction no Redis, o caminho de cache miss faz fallback para uma constante de TTL de 1 hora que sobrou de um load test de 2025
  • A última ocorrência é mostrada como tendo sido há 11 dias
  • As etapas check e verify são executadas automaticamente, e a etapa fix exige aprovação

Defeitos reais clusterizados no piloto

• Foram divulgados 3 exemplos entre os 7 que estão sendo clusterizados no piloto

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

  • As condições são fx.rate.age_ms > 60000 e order.execution.status = filled
  • O caminho de cache miss retorna a constante remanescente do load test TTL_FALLBACK_MS = 3_600_000
  • Durante eviction no Redis em horário de pico, cerca de 14k símbolos foram precificados com rates mais antigos que 60 segundos
  • Em um incidente anterior, ocorreram operações com preço incorreto no valor de US$ 340k durante 18 minutos antes da descoberta manual

• Idempotency keys regenerated on retry → duplicate ACH debits

  • As condições são ach.duplicate_debit e idempotency_key.reused = false
  • O middleware de retry emite um novo X-Idempotency-Key a cada 5xx em vez de reutilizar a chave original
  • Quando o banco responde 504 seguido de 200, o segundo retry registra um segundo débito
  • No mês passado houve 12 débitos duplicados, todos exigindo reversão manual e pedido de desculpas ao cliente

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

  • As condições são pnl.reconcile.diff > 0.01 e services.disagree = [risk, ledger]
  • O risk-svc desserializa valores como float64, enquanto o ledger-svc usa Decimal128
  • No round-trip de JSON, perde-se precisão abaixo de centavos, e a diferença se acumula em milhares de transações, acionando a reconciliação à tarde
  • O problema foi descoberto depois de 4 semanas, quando pequenas diferenças acumuladas viraram um delta de reconciliação de US$ 9,2k
  • Outros clusters do piloto listados são stripe webhook drops post-deploy, postgres pool exhaustion on report-gen, kafka rebalance storm e market-data WS subscription leak

Runbooks não são wiki, e sim especificações executáveis

• Todos os runbooks validados são compilados em skills YAML
• A skill inclui trigger signature, steps, expected outputs e o aprovador designado para operações de risco
• A cada salvamento, o runbook passa por drift check para evitar divergência entre a documentação e o executável
• As propriedades do runbook são as seguintes
  • As etapas são comandos shell reais, não pseudocódigo
  • Cada etapa fix tem aprovador designado e blast radius explicitado
  • Toda execução se torna um novo exemplo de treinamento para a próxima associação
• O exemplo em YAML mostra o runbook rb-fx-01
  • confidence_threshold é 0.85
  • confirm_cache_age verifica a idade do cache e a taxa de eviction no Redis
  • force_cache_refresh exige aprovação e tem blast radius de cerca de 14k símbolos e aproximadamente 2 segundos de pausa na precificação
  • confirm_fresh_rates verifica se a idade máxima é inferior a 60 segundos
  • Após a execução, notifica #payments-platform e #platform-oncall e grava logs em um caminho no S3

Confiança e governança

• A postura padrão é read-only, e a execução foi projetada para passar por gates de aprovação
• Foi criado para fintech e oferece uma postura em que a equipe de segurança pode aprovar o piloto e auditores podem assinar uma execução
• A retenção e a implantação dos dados são as seguintes
  • Dados brutos são mantidos por 90 dias
  • Dados redigidos são mantidos por 18 meses
  • O piloto recebeu aprovação do Jurídico
  • É possível usar implantação single-tenant
  • Os dados de treinamento não saem do tenant
• A redação de PII é feita antes de qualquer embedding ou chamada de LLM
  • São removidos e-mail, IP, customer-id e um dicionário configurável de segredos
  • O artefato original permanece no local de origem
• Todos os conectores começam em modo somente leitura
  • O escopo de execução é concedido por runbook
  • É necessário um aprovador designado
  • A revogação pode ser feita com um clique
• Todas as etapas do runbook mantêm provenance até o incidente resolvido que serviu de fonte de aprendizado
  • O audit log de cada execução é fornecido em estado assinado
  • Pode ser exportado para SIEM

Superfícies de execução e condições do piloto

• A mesma skill funciona em várias superfícies que a equipe já usa
  • Slack thread auto-suggest: quando uma signature conhecida ocorre, publica o runbook associado na mesma thread
  • /pls fix CLI: usa no terminal o mesmo runbook e os mesmos gates de aprovação
  • PagerDuty incident page: mostra o runbook associado e execução com um clique no card do incidente antes de o on-call terminar de preencher as informações
  • Linear / Jira issue: ao abrir uma issue com uma signature conhecida, anexa o runbook em comentário e sugere a execução
  • Web inbox: permite que o líder de plataforma veja eventos, clusters, execuções e post-mortems em um só lugar
• O piloto é um Closed pilot, com 4 design partners e indicação para o Q2 de 2026
• O piloto de 6 semanas é voltado a pequenos grupos de fintech e equipes de plataforma
• O andamento segue a ordem de ingest somente leitura, validação conjunta de 1 cluster e ativação do auto-suggest
• Se até a 4ª semana não reduzir em 30% o volume de incidentes recorrentes, não há cobrança
• A configuração do ingest somente leitura leva cerca de 30 minutos, a revisão conjunta de clusters acontece na 1ª semana e não há compromisso até a 4ª semana

[GN⁺]

Opiniões no Hacker News

• Na maior parte dos lugares, isso se enquadra como suborno comercial
  Segundo o California Penal Code § 641.3, se um funcionário recebe dinheiro ou algo de valor em troca de usar sua posição em benefício de outra pessoa, sem o conhecimento ou consentimento do empregador, isso configura crime de suborno comercial
  Porém, se o valor monetário ou equivalente for US$ 250 ou menos, essa disposição não se aplica

  • Parece que a lei já oferece uma solução conveniente. Bastaria colocar uma restrição de <=250 no campo de lance
  • Se não houver absolutamente nenhum outro meio, a questão central é se suborno é necessariamente ruim. Se a Big Tech se importasse, haveria suporte ao cliente; como não há, o mercado está criando sua própria solução
  • Acho que a ideia é que, se for menos de US$ 250 por caso, parece ok
  • Estranho. Então doações eleitorais também são limitadas a US$ 250?
  • Se você postar em qualquer rede social “minha conta foi bloqueada”, surgem enxames de bots dizendo com quem falar para recuperá-la
    Do meu ponto de vista, bloqueios de conta parecem uma estrutura de extorsão descontrolada operada por funcionários de redes sociais ou sobre a própria plataforma. As redes sociais em si também sempre foram, em certa medida, algo próximo de um golpe, e continuaram criando oportunidades para golpistas anônimos organizarem atividades que enganam pessoas
    As redes sociais impulsionaram NFTs, cripto, cultura de influenciadores e todo tipo de esquema de “finja até conseguir”; seria melhor voltar a comunidades independentes na web. Por um tempo seria doloroso, mas é muito melhor do que seus posts de divulgação de negócios terem 30 visualizações porque você não pagou

• Parece coisa de louco. Qualquer empresa obviamente demitiria alguém por fazer isso. O nome correto é corrupção, e as implicações legais também certamente deveriam ser motivo de preocupação

  • É claramente um enorme problema ético, mas é justamente isso que o torna mais interessante. Por causa das questões de ética, compliance e corrupção, isso pode chamar enorme atenção dentro da empresa e talvez fazer com que o problema de base seja de fato melhorado de uma forma duradoura
  • Como outros disseram, isso será um grande problema no futuro
    Alguém que realmente mereça ser suspenso, por exemplo por postar conteúdo ilegal, pode usar esse serviço. Se a empresa confiar em um formulário preenchido por um funcionário interno e remover a suspensão, essa pessoa continuará postando conteúdo ilegal e será suspensa de novo
    Se casos verdadeiramente positivos como esse se acumularem o bastante, a empresa acabará descobrindo que funcionários estão usando suas permissões para deixar qualquer um entrar. Uma empresa esperta poderia descobrir já no primeiro caso, porque marcaria as contas liberadas por funcionários internos
    O desfecho mais provável é a demissão desse funcionário. No pior caso, a empresa pode proibir todos os funcionários internos de enviar formulários em nome de pessoas de fora
    Se este site for uma piada, deveria ao menos deixar isso claro. Um aviso isentando responsabilidade e dizendo para verificar desconhecidos não basta. Também é duvidoso que um funcionário interno consiga verificar melhor do que o suporte ao cliente, e recursos como envio ou divulgação de e-mail deveriam ser removidos para impedir contato real e transferência de dinheiro
  • Concordo. É uma estrutura em que alguém recebe dinheiro pessoalmente e usa o tempo e os recursos da empresa para fazer algo que o empregador não quer. Soa como uma forma branda de suborno
    O FAQ diz que garante o anonimato do funcionário, mas ao mesmo tempo afirma que envia um e-mail de confirmação para um endereço google.com para verificar se a pessoa é funcionária do Google. Naturalmente, o Google consegue ver esse e-mail
  • Pelo menos na Meta/Facebook, há muito tempo é segredo aberto que a maneira mais rápida de resolver algo rapidamente na plataforma é ter alguém conhecido na Meta
  • Eu gostaria de pensar assim, mas, quando estava conduzindo algumas vagas publicadas apenas internamente na FAANG, pessoas de fora me mandaram e-mails perguntando sobre essas posições. Depois descobri que havia uma pequena indústria de intermediação em torno de indicações pagas

• O professor Robert Klitgaard disse que corrupção = monopólio + discricionariedade - transparência. Ele escreveu isso originalmente sobre sistemas políticos e suborno, mas também se aplica aqui
  https://globalanticorruptionblog.com/2014/05/27/klitgaards-m...
  Muitas empresas de tecnologia têm monopólio em seus mercados, discricionariedade ilimitada e transparência próxima de zero. O surpreendente é ninguém ter pensado antes em uma startup de taxa de agilização
  https://en.wikipedia.org/wiki/Facilitating_payment
  A maioria dos comentários vê isso como um mau negócio para o funcionário, e pode ser mesmo se estivermos falando de remover uma suspensão de conta por US$ 500. Mas, se alguém que ganha US$ 300 mil por ano está preso a uma estrutura em que os códigos de 2FA de todas as contas vão para o e-mail, ou se toca um negócio baseado em redes sociais, pode pagar muito mais do que US$ 500 para recuperar a conta
  Nem todos os funcionários de Big Tech estão em San Francisco. Em regiões de menor custo, como a Europa, há muitas pessoas que ganham cerca de metade do que um americano ganha, e quanto menor a renda, mais vulnerável a esse tipo de tentação a pessoa fica
  Não estou defendendo subornos, mas é surpreendente que a reação quase unânime seja a de que pagar funcionários de empresas de redes sociais é inviável. Historicamente, sistemas sem transparência e nos quais funcionários têm discricionariedade que pode ser convertida em dinheiro acabam se corrompendo
  Empresas de tecnologia deveriam levar isso mais a sério. Quando as pessoas se acostumam a pagar para receber tratamento justo de quem toma decisões, é muito difícil mudar esse comportamento

  • A única forma de vencer é não participar. Redes sociais são uma praga para a humanidade

• De um lado há uma ação que, na prática, garante uma demissão, e do outro há US$ 150.
  Trabalhei no FB antigamente, e havia uma equipe que pegava funcionários que vendiam acesso desse jeito. É difícil imaginar alguém assumindo esse risco por uma quantia que, para a maioria dos cargos técnicos de lá, é basicamente o salário de uma hora.

  • Reviravolta: isto pode ser um marketplace honeypot para pegar funcionários que vendem acesso desse jeito.
  • Sim, e receber propina por esse tipo de coisa parece antiético. Por outro lado, se você está sofrendo com esse problema, imagino que queira pagar até um insider para resolvê-lo.
    O ponto central não é só um problema técnico simples, como uma conta suspensa, mas a sensação de injustiça desde o início e a raiva de ficar preso num loop infernal sem fim.
  • Para quem não conhece bem o FB, o maxrmk está certo. Acrescentando um pouco mais de contexto: se uma das equipes de privacidade descobre uma violação dessas, o funcionário normalmente é chamado para uma reunião com o RH e é demitido logo no dia seguinte.
    Um amigo meu acabou fazendo isso sem querer ao tentar ajudar, em caráter pessoal, com o problema na conta de um amigo que conhecia. Ele não sabia que era uma violação de privacidade e acessou o sistema; meses depois, ao investigarem dados de um projeto, uma auditoria foi acionada, e no dia seguinte ao registro ser encontrado ele foi desligado.
    Então isto não é uma boa ideia de negócio.
  • O que realmente é necessário é conseguir um emprego nessa equipe de detecção e vender a capacidade de fazer a equipe fingir que não viu os casos. O nome poderia ser algo como plsfixmyfix.com.
  • Como alguém que trabalha em uma dessas empresas, esse risco absolutamente não vale a pena.

• Não sei se sou só eu, mas parece que muita gente está perdendo a visão geral. Serviços assim só surgem quando as soluções normais não resolvem o problema.
  Para mim, isso é mais um sinal de que a Big Tech não conseguiu criar um processo de contestação eficaz à altura da demanda dos consumidores. Talvez não dê muito dinheiro, mas seria bom observar como a Big Tech vai melhorar essa parte.

  • Acho que não é isso. A ineficiência é o ponto central. Este serviço é uma piada e quase certamente ilegal. Todo mundo sabe que esse sistema está “quebrado”, mas não dá para escalar suporte gratuito ao cliente para sempre.
    A demanda legítima por esse tipo de serviço prova o valor dessas contas. Acho que, em poucos anos, as empresas de tecnologia vão entrar diretamente nisso e oferecer suporte pago ao cliente, como o que clientes corporativos recebem. Como já é possível pagar por contas “verificadas”, o próximo passo é esse. Se a empresa não monetizar, o governo vai regulamentar.
  • Antes disto surgir, é provável que a maior parte das solicitações internas viesse de funcionários que realmente queriam ajudar alguém. Claro, talvez já houvesse funcionários recebendo dinheiro para enviar formulários internos, mas é pouco provável que isso fosse generalizado.
    Ao formalizar o processo como este site faz, fica muito mais provável que o envio de formulários internos para reverter suspensões de conta passe a ocorrer em troca de dinheiro. Isso porque ele cria um marketplace que conecta solicitantes a funcionários antiéticos, reduz o atrito para executar a transação e atrai abertamente funcionários interessados em dinheiro, em vez de ajudar pessoas suspensas injustamente.
    Por isso, parece uma estrutura muito mais eticamente repulsiva do que o processo existente.
  • A maioria do HN provavelmente sabe que a Big Tech não conseguiu criar processos de contestação eficazes. Isso não é segredo algum. Ainda assim, este serviço é corrupção explícita.

• Já vi uma abordagem mais empreendedora antes. Era sobre uma modelo do OnlyFans que encontrou funcionários no LinkedIn e trocou sexo por reversão de suspensão de conta para recuperar sua conta do Instagram.
  https://www.newsweek.com/onlyfans-star-slept-meta-employees-...

• Como verificar se o solicitante é mesmo uma pessoa comum bloqueada sem motivo algum, ou alguém legitimamente bloqueado por motivos legais, como CSAM, ou por violar os termos de serviço?
  Se o Mike da Meta for demitido por tentar liberar a conta de um terrorista de verdade, especialmente quando é óbvio que eles estarão monitorando menções internas, este serviço assume essa responsabilidade?

  • Se for um “funcionário verificado” da empresa, talvez ele possa investigar por conta própria antes de inserir a documentação adequada. Mas isso normalmente deixa um rastro de registros separado e provavelmente acabará voltando contra ele.
    Sinceramente, aqui o risco é muito maior que o benefício. Para começo de conversa, nem sei por que alguém tentaria fazer isso.
    “Emprego estável com salário anual de seis dígitos” versus “US$ 100 pontuais de um desconhecido da internet” tem uma resposta óbvia.
    Sinceramente, isso tem cheiro de operação armadilha.
  • Deve ser parecido com a forma como problemas são resolvidos quando a história triste de alguém viraliza. Um funcionário vê aquilo e abre um ticket dizendo “este desconhecido está com o problema XYZ”, e então alguém do suporte investiga e toma a medida apropriada.
    Não conheço o processo real da Meta.
  • Pelo que sei, uma causa comum para congelamento de contas é quando a conta é percebida como tendo sido tomada por outra pessoa. Para criar um canal alternativo acelerado de recuperação de acesso a essas contas, seria preciso implementar isso com muito cuidado.

• Tive que conferir se hoje era Primeiro de Abril. É uma das coisas mais chocantes que vi recentemente. Sinceramente espero que as pessoas que lucram com isso sejam, no mínimo, demitidas.

  • O conceito em si parece uma espécie de protesto em forma de arte performática.
    Criar uma plataforma para atravessar, via suborno, os sistemas opacos de não suporte ao cliente dessas empresas é corrupção de baixo nível ou arte de alto nível.
  • Funcionários que se cadastrarem neste serviço devem tomar cuidado. O Facebook certamente vai processar essa pessoa, e os registros de pagamento serão alguns dos primeiros materiais a serem entregues na fase de discovery.
    Não vejo como o anonimato possa ser garantido por muito tempo.
  • Pelo contrário, parece devolver parte dos direitos das pessoas comuns que as gigantes de tecnologia não sentem necessidade de respeitar.

• Entendo perfeitamente por que isso é visto como antiético. Também entendo que funcionários que recebam recompensas serão demitidos
  Mas que lei, exatamente, isso viola? Parece juridicamente um suborno, porque incentiva uma medida não rotineira. Quero dizer, porém, que seria por causa dessa parte “não rotineira”. A empresa conseguiria levar isso ao tribunal e processar alguém admitindo que seu procedimento de contestação de suspensão é não rotineiro?
  E qual cláusula de um contrato de trabalho padrão isso viola? Executar e receber por um serviço que o empregador não oferece? Curiosamente, se o empregador oferecesse esse serviço, deixaria de ser suborno e passaria a ser uma taxa de urgência legal; então, para impedir isso, seria preciso incluir uma cláusula separada no contrato de trabalho
  Não é uma pergunta retórica; estou realmente procurando uma resposta
  De várias maneiras, esse processo já acontece, e as partes envolvidas até certo ponto já esperam isso. Vi vários casos em que uma decisão parecia ser revertida porque uma celebridade do Twitter conseguiu fazer barulho suficiente, e alguns chegaram à primeira página aqui. A diferença é apenas o tipo de moeda usado para contornar o sistema

  • Há uma solução simples. Basta fazer com que o valor seja uma doação a uma instituição de caridade escolhida por eles. Pode até ser uma organização para a qual a empresa já doa todo ano; assim fica muito mais difícil demitir alguém que esteja arrecadando dinheiro para uma instituição de caridade
  • Isso se chama suborno comercial. Mas, como normalmente leis estaduais tratam desse tipo de coisa, vai depender da jurisdição. Outra pessoa postou o texto da lei da Califórnia
    No caso da Califórnia, a lei não se aplica se o valor for inferior a US$ 250, mas no site do post original há várias “recompensas” acima desse limite
    Não sei se é padrão, mas muitos funcionários assinam documentos dizendo que não aceitarão outro emprego. Não sei se isso se enquadra como “emprego”. Mas não me surpreenderia se alguns contratos de trabalho tivessem uma formulação mais ampla, como “proibição de trabalho remunerado externo”
    [0] https://news.ycombinator.com/item?id=40435890
  • Os contratos de trabalho que assinei exigiam, no mínimo, que eu informasse qualquer atividade comercial feita fora da empresa e, às vezes, que obtivesse aprovação antes de começar. Se alguém tiver um segundo trabalho remunerado não divulgado, isso é suficiente para justificar uma demissão, se a empresa quiser
  • Do ponto de vista do funcionário que presta o serviço, é muito provável que seja ao menos uma violação contratual

• Como referência, graças a pessoas que eu conhecia no Google e na Stripe, minha startup conseguiu sobreviver a desastres existenciais. Nos dois casos, sistemas automatizados nos marcaram falsamente como problema e interromperam o processamento de pagamentos, e não havia outro caminho
  Só porque havia alguém lá dentro é que conseguimos contestar a decisão junto a uma pessoa que podia realmente avaliá-la
  Não acho que plataformas como essa sejam ok. Há um aspecto eticamente suspeito. Mas é importante entender que, se você não conhece pessoalmente algumas pessoas em cargos altos na empresa da qual pretende depender, então não deveria assumir essa dependência

  • Então, para você, é aceitável usar contatos para evitar um “desastre existencial”, mas é eticamente suspeito quando outras pessoas tentam fazer a mesma coisa?
  • À primeira vista, parece uma contradição. Parece violar a ética do privilégio. Talvez fosse melhor e mais justo se todo mundo simplesmente pagasse