Plsfix — Issue Brain para ingeniería de plataformas

 (plsfix.co)
1 puntos por GN⁺ 2024-05-22 | 1 comentarios | Compartir por WhatsApp
  • plsfix reúne registros de incidentes ya resueltos y los convierte en runbooks verificados y skills ejecutables; cuando se repite la misma falla, ofrece de inmediato un botón de ejecución dentro del hilo
  • El flujo va desde la ingesta de solo lectura, el clustering de incidentes recurrentes, la verificación por ingenieros y la ejecución; cada etapa se basa en casos de resolución previos del equipo
  • En un ejemplo piloto, encontró 7 clústeres recurrentes entre 14,802 eventos, resolvió automáticamente el 22% de los eventos nuevos y, en el ejemplo de Slack, emparejó un runbook 4 segundos después de la alerta con 94% de confianza
  • Los runbooks se compilan como skills en YAML, los pasos seguros se ejecutan automáticamente, pero las correcciones con blast radius se detienen en el aprobador designado
  • El piloto de 6 semanas para equipos de fintech y plataforma no cobra si para la semana 4 no reduce en 30% el volumen de incidentes recurrentes, y configurar la ingesta de solo lectura toma unos 30 minutos

Un producto que convierte fallas recurrentes en conocimiento ejecutable

  • plsfix toma incidentes que el equipo ya resolvió desde Slack, PagerDuty, GitHub, Claude y otros, y los transforma en runbooks verificados y skills ejecutables
  • Cuando vuelve a ocurrir una falla del mismo tipo, el bot responde en el mismo hilo y el usuario puede ejecutarlo con un clic en Run playbook
  • La pantalla inicial muestra métricas del piloto con datos de la semana 1 del piloto de acme
    • 14,802 eventos recopilados
    • 7 clústeres recurrentes identificados
    • 22% de los eventos nuevos resueltos automáticamente

El problema: el conocimiento de resolución está disperso y las fallas recurrentes crecen

  • Muchas fallas no son problemas completamente nuevos, sino más bien fallas recurrentes que ya se resolvieron antes pero nadie recuerda
  • El ejemplo es una situación donde un ingeniero senior tiene que volver a encontrar a las 3 a. m. la solución exacta que estaba en un hilo de Slack
  • El proceso de resolución queda repartido entre varias herramientas
    • En PagerDuty está el acknowledge
    • En el hilo de Claude está el diagnóstico
    • En los comentarios del PR cerrado está la corrección real
  • En lugar de crear runbooks solo con prompts, plsfix rastrea cada paso a partir de incidentes que el equipo realmente resolvió en el pasado

Cuatro etapas, desde la ingesta hasta la ejecución

  • Ingest

    • Los conectores de solo lectura traen el trabajo resuelto desde donde el equipo realmente soluciona problemas
    • Elimina PII antes del clustering
    • Puede conectarse a Slack, PagerDuty, GitHub, Jira, Linear, ServiceNow, Notion y Claude / ChatGPT

  • Cluster

    • Aprende las signatures de incidentes recurrentes
    • La signature se compone de regex del payload de alerta, conjunto de servicios, cercanía a despliegues y patrones de canal y reportero, entre otros
    • Las fallas del mismo tipo se clasifican en el mismo clúster

  • Verify

    • Crea un borrador de runbook basado en casos de resolución anteriores
    • Un ingeniero lo revisa una vez, lo ajusta si hace falta y luego pulsa Verify
    • Todos los pasos quedan con su fuente

  • Execute

    • Los runbooks se compilan como skills ejecutables
    • Los pasos de bajo riesgo se ejecutan automáticamente
    • Las acciones con blast radius se detienen en el aprobador designado
    • El mismo runbook puede ejecutarse desde Slack, CLI, PagerDuty, Linear, Jira y Web inbox

Runbooks que se ejecutan directamente desde un hilo de Slack

  • Hay un ejemplo donde, 4 segundos después de la alerta, el bot publica en el mismo hilo un runbook emparejado con un clúster existente con 94% de confianza
  • El clúster de ejemplo es FX rate cache TTL fallback, y el runbook verificado v3 se ha usado 6 veces con una tasa de éxito de 83%
  • Las señales de emparejamiento son las siguientes
    • Signature regex 94%
    • Recent deploy proximity 87%
    • Service overlap 100%
    • Channel + reporter history 71%
  • El ejemplo de runbook trata el problema de usar stale FX rates para fijar precios de live trades
    • Durante una Redis eviction, el cache miss path hace fallback a una constante TTL de 1 hora que quedó de una load test de 2025
    • La última ocurrencia aparece como hace 11 días
    • Los pasos check y verify se ejecutan automáticamente, pero el paso fix requiere aprobación

Fallas reales agrupadas en el piloto

  • Se muestran 3 ejemplos de las 7 fallas que actualmente se están agrupando en el piloto

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

    • Las condiciones son fx.rate.age_ms > 60000 y order.execution.status = filled
    • El cache miss path devuelve una constante TTL_FALLBACK_MS = 3_600_000 que quedó de la load test
    • Durante Redis eviction en hora pico, unos 14k símbolos se valuaron con rates de más de 60 segundos de antigüedad
    • En un incidente anterior, hubo $340k en mispriced trades durante 18 minutos antes de detectarlo manualmente

  • Idempotency keys regenerated on retry → duplicate ACH debits

    • Las condiciones son ach.duplicate_debit e idempotency_key.reused = false
    • El retry middleware emite un nuevo X-Idempotency-Key en cada 5xx en lugar de reutilizar la clave original
    • Si el banco responde 200 después de un 504, el segundo retry publica un segundo débito
    • El mes pasado hubo 12 débitos duplicados, y todos requirieron reversal manual y disculpas al cliente

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

    • Las condiciones son pnl.reconcile.diff > 0.01 y services.disagree = [risk, ledger]
    • risk-svc deserializa montos como float64 y ledger-svc usa Decimal128
    • En el round-trip de JSON se pierde precisión por debajo de un centavo, y la diferencia se acumula en miles de transacciones hasta disparar la reconciliación por la tarde
    • Se descubrió después de que pequeñas diferencias acumuladas durante 4 semanas se convirtieran en un recon delta de $9.2k
    • Otros clústeres del piloto listados son stripe webhook drops post-deploy, postgres pool exhaustion on report-gen, kafka rebalance storm y market-data WS subscription leak

El runbook no es una wiki, sino una especificación ejecutable

  • Todos los runbooks verificados se compilan como YAML skill
  • El skill incluye trigger signature, steps, expected outputs y el aprobador designado para operaciones riesgosas
  • En cada guardado se ejecuta un runbook y una verificación de drift para evitar que la documentación y lo ejecutable se separen
  • Las propiedades del runbook son las siguientes
    • Los pasos son comandos reales de shell, no pseudocódigo
    • Cada paso fix tiene un aprobador designado y un blast radius explícito
    • Cada ejecución se convierte en un nuevo ejemplo de entrenamiento para el siguiente emparejamiento
  • El ejemplo YAML muestra el runbook rb-fx-01
    • confidence_threshold es 0.85
    • confirm_cache_age verifica la edad del caché y la tasa de eviction en Redis
    • force_cache_refresh requiere aprobación y su blast radius es de unos 14k símbolos y una pausa de pricing de unos 2 segundos
    • confirm_fresh_rates verifica que la edad máxima sea menor a 60 segundos
    • Después de ejecutarse, notifica a #payments-platform, #platform-oncall y deja logs en una ruta de S3

Confianza y gobernanza

  • La postura por defecto es read-only, y la ejecución está diseñada para pasar por compuertas de aprobación
  • Está hecho para fintech y ofrece una postura que permite que el equipo de seguridad apruebe el piloto y que un auditor firme cada ejecución
  • La retención y el despliegue de datos son los siguientes
    • Los datos raw se guardan 90 días
    • Los datos redactados se guardan 18 meses
    • El piloto obtuvo aprobación de Legal
    • Se puede usar single-tenant deployment
    • Los datos de entrenamiento no salen fuera del tenant
  • La redacción de PII se hace antes del embedding o de cualquier llamada al LLM
    • Se eliminan email, IP, customer-id y un diccionario configurable de secretos
    • Los artifacts originales permanecen en su ubicación original
  • Todos los conectores comienzan en modo read-only
    • El alcance de ejecución se otorga por runbook
    • Se requiere un aprobador designado
    • Puede revocarse con un clic
  • Cada paso del runbook mantiene provenance hasta el incidente resuelto que sirvió como fuente de aprendizaje
    • El audit log de cada ejecución se ofrece firmado
    • Puede exportarse al SIEM

Superficies de ejecución y condiciones del piloto

  • El mismo skill funciona en varias superficies que el equipo ya usa
    • Slack thread auto-suggest: cuando aparece una signature conocida, publica el runbook emparejado en el mismo hilo
    • /pls fix CLI: usa el mismo runbook y las mismas compuertas de aprobación desde la terminal
    • PagerDuty incident page: muestra el runbook emparejado y la ejecución con un clic en la tarjeta del incidente antes de que el on-call termine de escribir
    • Linear / Jira issue: al abrir un issue con una signature conocida, adjunta el runbook en un comentario y sugiere ejecutarlo
    • Web inbox: el platform lead puede ver eventos, clústeres, ejecuciones y post-mortems en un solo lugar
  • El piloto es un Closed pilot y aparece con 4 design partners y Q2 de 2026
  • El piloto de 6 semanas está dirigido a grupos pequeños de fintech y platform team
  • El avance sigue este orden: ingesta read-only, verificación conjunta de 1 clúster y activación de auto-suggest
  • Si para la semana 4 no reduce en 30% el volumen de incidentes recurrentes, no cobra
  • Configurar la ingesta read-only toma unos 30 minutos, la revisión conjunta del clúster se hace en la semana 1 y no hay compromiso hasta la semana 4

Lecturas relacionadas

1 comentarios

 
GN⁺ 2024-05-22
Opiniones en Hacker News

  • En la mayoría de las jurisdicciones, esto constituye soborno comercial.
    Según el California Penal Code § 641.3, si un empleado recibe dinero o algo de valor a cambio de usar su puesto en beneficio de otra persona sin el conocimiento o consentimiento de su empleador, comete el delito de soborno comercial.
    Sin embargo, esta disposición no aplica si el monto o valor es de $250 o menos.

    • Parece que la ley ya ofrece una solución conveniente. Bastaría con poner una restricción <=250 en el campo de la oferta.
    • Si no hay absolutamente ningún otro medio, la cuestión clave es si el soborno necesariamente es malo. Si a Big Tech le importara, habría soporte al cliente, pero como no es así, el mercado está creando su propia solución.
    • Supongo que quieren decir que, si es menos de $250 por caso, parece estar bien.
    • Qué raro. Entonces, ¿las donaciones electorales también están limitadas a $250?
    • Si publicas en cualquier red social “me bloquearon la cuenta”, te caen bots diciendo a quién contactar para recuperarla.
      Desde mi punto de vista, los bloqueos de cuentas parecen una estructura de extorsión no controlada, operada por empleados de redes sociales o sobre la plataforma. Las redes sociales en sí ya eran, en cierta medida, algo cercano a una estafa, y han seguido creando oportunidades para que estafadores anónimos organicen actividades que engañan a la gente.
      Las redes sociales impulsaron NFT, Crypto, la cultura de influencers y todo tipo de esquemas de “finge hasta que lo logres”; sería mejor volver a las comunidades web independientes. Por un tiempo dolerá, pero es mucho mejor que tener 30 vistas en las publicaciones que promocionan tu negocio solo porque no pagaste.

  • Parece una locura. Cualquier empresa despediría sin dudar a alguien que hiciera esto. El nombre correcto es corrupción, y sin duda también hay que preocuparse por las implicaciones legales.

    • Claramente es un enorme problema ético, pero justamente eso lo hace más interesante. Por los temas de ética, cumplimiento y corrupción, podría atraer muchísima atención dentro de la empresa y hacer que el problema de fondo se mejore de una forma realmente duradera.
    • Como dijeron otros, esto será un gran problema en el futuro.
      Alguien que en realidad merezca ser suspendido, por ejemplo quien haya publicado contenido ilegal, podría usar este servicio. Si la empresa confía en un formulario enviado por un empleado interno y levanta la suspensión, esa persona seguirá publicando contenido ilegal y volverá a ser suspendida.
      Si se acumulan suficientes falsos positivos de este tipo, la empresa terminará descubriendo que empleados internos están usando su autoridad para dejar entrar a cualquiera. Una empresa inteligente podría detectarlo desde el primer caso si marca las cuentas desbloqueadas por empleados internos.
      El desenlace más probable es el despido de ese empleado. En el peor de los casos, la empresa podría prohibir a todos los empleados internos enviar formularios para personas externas.
      Si este sitio es una broma, al menos deberían indicarlo claramente. No basta con un descargo que diga que se verifique a desconocidos. También es dudoso que un empleado interno pueda verificar mejor que atención al cliente, y deberían eliminar funciones como enviar o publicar emails para impedir el contacto real y las transferencias de dinero.
    • Estoy de acuerdo. Es una estructura en la que alguien recibe dinero personal y usa tiempo y recursos de la empresa para hacer algo que su empleador no quiere. Suena como una forma leve de soborno.
      En el FAQ dicen que garantizan el anonimato del empleado, pero al mismo tiempo dicen que envían un correo de confirmación a una dirección google.com para verificar que sea empleado de Google. Obviamente Google puede ver ese correo.
    • Al menos en Meta/Facebook, desde hace mucho era un secreto a voces que la forma más rápida de que algo se atendiera rápido en la plataforma era tener un conocido en Meta.
    • Me gustaría pensar eso, pero cuando gestioné algunas vacantes publicadas solo internamente dentro de FAANG, personas externas enviaron emails preguntando por esos puestos. Después vi que existía toda una pequeña industria de intermediación alrededor de las referencias pagadas.

  • El profesor Robert Klitgaard dijo que corrupción = monopolio + discrecionalidad - transparencia. Lo escribió originalmente sobre sistemas políticos y sobornos, pero también aplica aquí.
    https://globalanticorruptionblog.com/2014/05/27/klitgaards-m...
    Muchas empresas tecnológicas tienen monopolios en sus mercados, discrecionalidad ilimitada y una transparencia cercana a cero. Lo sorprendente es que a alguien no se le haya ocurrido antes una startup de pago para agilizar trámites.
    https://en.wikipedia.org/wiki/Facilitating_payment
    La mayoría de los comentarios lo ven como un mal negocio para el empleado, y si hablamos de desbloquear una cuenta por $500, puede ser cierto. Pero si alguien que gana $300k al año depende de una estructura en la que los códigos 2FA de todas sus cuentas llegan al email, o si tiene un negocio basado en redes sociales, podría pagar mucho más de $500 para recuperar la cuenta.
    No todos los empleados de Big Tech están en San Francisco. En regiones de menor costo, como Europa, hay muchos que ganan más o menos la mitad que un estadounidense, y cuanto menor es el ingreso, más vulnerables son a esta tentación.
    No estoy defendiendo los sobornos, pero me sorprende que la reacción casi unánime sea que pagarle a un empleado de una empresa de redes sociales es inviable. Históricamente, los sistemas sin transparencia y con empleados que tienen discrecionalidad monetizable se han corrompido.
    Las empresas tecnológicas deberían tomarse esto más en serio. Cuando la gente se acostumbra a pagar para recibir un trato justo de quienes toman decisiones, es muy difícil cambiar ese comportamiento.

    • La única forma de ganar es no participar. Las redes sociales son una plaga para la humanidad.

  • De un lado hay una acción que prácticamente garantiza el despido, y del otro hay USD 150.
    Antes trabajé en FB, y había un equipo que se dedicaba a atrapar a empleados que vendían acceso de esta manera. Es difícil imaginar que alguien en la mayoría de los roles técnicos allí asumiría ese riesgo por una cantidad que, en la práctica, equivale más o menos a una hora de sueldo.

    • Giro: esto podría ser un mercado honeypot para atrapar a empleados que venden acceso de esta forma.
    • Sí, y recibir una comisión por algo así parece poco ético. Por otro lado, si estás del lado de quien sufre este problema, me imagino que querrías pagarle incluso a un interno con tal de resolverlo.
      El punto central no es solo el problema técnico en sí, como una suspensión de cuenta, sino la sensación de que fue injusto desde el principio y la rabia de quedar atrapado en un bucle infernal interminable.
    • Para quienes no conocen bien FB, maxrmk tiene razón. Agregando un poco más de contexto: si uno de los equipos de privacidad detecta una infracción de este tipo, por lo general el empleado es citado a una reunión con RR. HH. y lo despiden al día siguiente.
      Un amigo mío hizo algo así sin querer al intentar ayudar con un problema de cuenta de un amigo que conocía personalmente. No sabía que era una violación de privacidad y accedió al sistema; meses después, al investigar datos de un proyecto, se activó una auditoría, y al día siguiente de encontrarse ese registro lo dieron de baja.
      Así que esta no es una buena idea de negocio.
    • Lo que realmente se necesita es conseguir empleo en ese equipo de detección y vender la capacidad de que ese equipo mire para otro lado en esos casos. El nombre podría ser algo como plsfixmyfix.com.
    • Como alguien que trabaja en una de estas empresas, definitivamente no vale la pena asumir ese riesgo.

  • No sé si soy el único que lo ve así, pero creo que mucha gente se está perdiendo el panorama general. Servicios como este aparecen solo cuando las soluciones normales no logran resolver el problema.
    Para mí, esto es más bien una señal de que Big Tech no ha sabido crear un proceso de apelación efectivo acorde con la demanda de los consumidores. Probablemente no dé mucho dinero, pero sería bueno ver cómo Big Tech mejora esta parte.

    • No creo que sea eso. La ineficiencia es el punto clave. Este servicio es una broma y casi seguro es ilegal. Todos sabemos que este sistema está “roto”, pero no se puede escalar eternamente el soporte al cliente gratuito.
      La demanda legítima por servicios como este demuestra el valor de esas cuentas. Creo que en unos años las empresas tecnológicas se meterán directamente en esto y ofrecerán soporte al cliente de pago, como el que reciben los clientes empresariales. Ya se puede pagar por cuentas “verificadas”, así que este es el siguiente paso. Si la empresa no lo monetiza, el gobierno lo regulará.
    • Antes de que existiera esto, es probable que la mayoría de las solicitudes internas vinieran de empleados que de verdad querían ayudar a alguien. Claro que quizá ya había empleados que cobraban por enviar formularios internos, pero es poco probable que estuviera muy extendido.
      Formalizar el proceso con un sitio como este aumenta mucho la probabilidad de que el envío de formularios internos para levantar suspensiones de cuentas se haga a cambio de dinero. Porque crea un mercado que empareja a solicitantes con empleados sin escrúpulos, reduce la fricción para ejecutar la transacción y, al poner el dinero de forma explícita por delante, atrae a empleados motivados por el pago más que por ayudar a personas suspendidas injustamente.
      Por eso me parece una estructura mucho más éticamente repugnante que el proceso existente.
    • La mayoría de HN probablemente sabe que Big Tech no ha logrado crear procesos de apelación efectivos. No es ningún secreto. Aun así, este servicio es corrupción descarada.

  • Antes vi un enfoque más emprendedor: una modelo de OnlyFans encontró empleados en LinkedIn e intercambió sexo y levantamiento de suspensión de cuenta para recuperar su cuenta de Instagram.
    https://www.newsweek.com/onlyfans-star-slept-meta-employees-...

  • ¿Cómo verifican si quien hace la solicitud es realmente una persona común bloqueada sin motivo, o alguien bloqueado justificadamente por razones legales, como CSAM, o por violar los términos de servicio?
    Si Mike Meta termina despedido por intentar desbloquear la cuenta de un terrorista real, especialmente cuando es obvio que estarán monitoreando las menciones internas, ¿este servicio se hace responsable?

    • Si se trata de un “empleado verificado” de la empresa, podría investigar por su cuenta antes de presentar la documentación correspondiente. Pero eso normalmente dejaría un rastro de registros separado y probablemente terminaría volviéndose en su contra.
      Sinceramente, aquí el riesgo supera por mucho el beneficio. Ni siquiera entiendo por qué alguien querría hacer esto.
      Entre “un empleo estable de seis cifras” y “USD 100 únicos de un desconocido de internet”, la respuesta es obvia.
      Sinceramente, esto huele a operación encubierta.
    • Supongo que sería parecido a cómo se resuelven los problemas cuando la historia triste de alguien se vuelve viral. Un empleado la ve y abre un ticket diciendo “esta persona desconocida tiene el problema XYZ”, y luego alguien de soporte investiga y toma la acción adecuada.
      No conozco el proceso real de Meta.
    • Entiendo que una causa común de congelamiento de cuentas es cuando se considera que la cuenta fue secuestrada por otra persona. Crear un canal acelerado alternativo para restaurar el acceso a esas cuentas tendría que implementarse con muchísimo cuidado.

  • Tuve que revisar si hoy era Día de los Inocentes. Es una de las cosas más impactantes que he visto últimamente. De verdad espero que quienes se beneficien de esto sean despedidos como mínimo.

    • El concepto en sí parece una especie de protesta en forma de arte performático.
      Crear una plataforma para atravesar con sobornos los sistemas opacos de no-soporte al cliente de estas empresas es o corrupción de bajo nivel o arte de alto nivel.
    • Cualquier empleado que se registre en este servicio debería tener cuidado. Facebook seguramente demandará a esta persona, y los registros de pago serán de los primeros materiales que tendrán que entregar durante el discovery.
      No veo forma de que el anonimato dure mucho.
    • Más bien parece devolverles algo de los derechos de la gente común que los gigantes tecnológicos no sienten necesidad de respetar.

  • Entiendo perfectamente por qué esto se considera poco ético. También entiendo que los empleados que reciban recompensas sean despedidos.
    Pero, en la práctica, ¿qué ley se estaría violando? Supongo que legalmente sería un soborno porque incentiva medidas no rutinarias. Aunque me refiero justamente a esa parte de “no rutinarias”. ¿Podría una empresa ir a tribunales y procesar esto admitiendo que su procedimiento de apelación de suspensiones no es rutinario?
    ¿Y qué cláusula de un contrato laboral estándar se estaría violando? ¿Realizar un servicio que el empleador no ofrece y cobrar por ello? Curiosamente, si el empleador sí ofreciera ese servicio, ya no sería un soborno sino una tarifa exprés legal, así que para impedirlo habría que incluir una cláusula aparte en el contrato laboral.
    No es una pregunta retórica; realmente estoy buscando la respuesta.
    En muchos sentidos, este proceso ya está ocurriendo, y los involucrados también lo esperan en cierta medida. He visto varias veces casos en los que una decisión parece revertirse porque una celebridad de Twitter logró hacer suficiente ruido, y también han llegado a la portada aquí. La diferencia es solo el tipo de moneda que se usa para saltarse el sistema.

    • Hay una solución sencilla. Que el monto sea una donación a una organización benéfica elegida por ellos. Incluso podría ser una organización a la que la empresa done todos los años, y entonces sería mucho más difícil despedir a alguien por recaudar dinero para una entidad benéfica.
    • A esto se le llama soborno comercial. Pero como normalmente las leyes estatales se encargan de este tipo de cosas, dependerá de la jurisdicción. Alguien más publicó el texto de la ley de California.
      En el caso de California, si el monto es inferior a $250 la ley no aplica, pero en el sitio del post original hay bastantes “recompensas” que superan ese umbral.
      No sé si sea estándar, pero muchos empleados firman documentos en los que se comprometen a no aceptar otro empleo. No sé si esto calificaría como “empleo”. Pero no me sorprendería que algunos contratos laborales incluyan formulaciones más amplias, como “prohibición de trabajo remunerado externo”.
      [0] https://news.ycombinator.com/item?id=40435890
    • Los contratos laborales que he firmado, como mínimo, exigían informar cualquier trabajo comercial realizado fuera de la empresa, y a veces obtener aprobación antes de empezarlo. Si tienes un segundo trabajo remunerado no declarado, eso es suficiente para que la empresa te despida si quiere.
    • Desde el punto de vista del empleado que presta el servicio, como mínimo es muy probable que sea un incumplimiento contractual.

  • Como referencia, gracias a que conocía a gente en Google y Stripe, mi startup pudo sobrevivir a un desastre de proporciones terminales. En ambos casos, sus sistemas automatizados nos marcaron por error y suspendieron el procesamiento de pagos, y no había otra vía.
    Solo porque había alguien adentro pudimos apelar ante una persona que realmente podía tomar una decisión.
    No creo que estas plataformas estén bien. Tienen un aspecto éticamente dudoso. Pero es importante entender que, si no conoces personalmente a algunas personas en puestos altos dentro de una empresa de la que planeas depender, no deberías asumir esa dependencia.

    • ¿O sea que está bien que tú uses tus contactos para evitar un “desastre de proporciones terminales”, pero que otras personas intenten hacer lo mismo es éticamente dudoso?
    • A primera vista se siente contradictorio. Parece violar la ética del privilegio. Tal vez sería mejor y más justo que todos pagaran.