Plsfix — Issue Brain สำหรับวิศวกรรมแพลตฟอร์ม

 (plsfix.co)
1 คะแนน โดย GN⁺ 2024-05-22 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • plsfix รวบรวมบันทึกอินซิเดนต์ที่เคยแก้ไขแล้วมาแปลงเป็น runbook ที่ผ่านการตรวจสอบแล้ว และ skill ที่สั่งรันได้ และเมื่อปัญหาเดิมเกิดซ้ำก็จะมีปุ่มรันให้ทันทีในเธรด
  • ลำดับการทำงานต่อเนื่องจากการเก็บข้อมูลแบบอ่านอย่างเดียว, การทำ clustering อินซิเดนต์ซ้ำ, การตรวจสอบโดยวิศวกร ไปจนถึงขั้นตอนการรัน โดยแต่ละขั้นอ้างอิงจากกรณีที่ทีมเคยแก้ไว้จริง
  • ในตัวอย่าง pilot พบ 7 คลัสเตอร์ที่เกิดซ้ำจาก 14,802 อีเวนต์ และ 22% ของอีเวนต์ใหม่ถูกแก้อัตโนมัติ ส่วนตัวอย่างบน Slack จับคู่ runbook ได้หลังแจ้งเตือน 4 วินาทีด้วยความเชื่อมั่น 94%
  • runbook จะถูกคอมไพล์เป็น YAML skill และขั้นตอนที่ปลอดภัยจะรันอัตโนมัติ แต่การแก้ไขที่มี blast radius จะหยุดรอผู้อนุมัติที่กำหนดไว้
  • pilot 6 สัปดาห์สำหรับทีมฟินเทคและแพลตฟอร์มจะไม่คิดค่าใช้จ่ายหากภายในสัปดาห์ที่ 4 ยังลดปริมาณอินซิเดนต์ซ้ำไม่ได้ 30% และการตั้งค่าเก็บข้อมูลแบบอ่านอย่างเดียวใช้เวลาราว 30 นาที

ผลิตภัณฑ์ที่เปลี่ยนปัญหาซ้ำให้เป็นความรู้ที่สั่งรันได้

  • plsfix ดึงอินซิเดนต์ที่ทีมเคยแก้แล้วจาก Slack, PagerDuty, GitHub, Claude และที่อื่น ๆ มาแปลงเป็น runbook ที่ผ่านการตรวจสอบแล้ว และ skill ที่สั่งรันได้
  • เมื่อปัญหาในรูปแบบเดิมเกิดขึ้นอีก บอตจะตอบกลับในเธรดเดิม และผู้ใช้กด Run playbook เพียงครั้งเดียวเพื่อสั่งรันได้
  • หน้าจอแรกแสดงตัวชี้วัดของ pilot จากข้อมูลสัปดาห์แรกของ acme pilot
    • เก็บอีเวนต์ได้ 14,802 รายการ
    • ระบุคลัสเตอร์ที่เกิดซ้ำได้ 7 คลัสเตอร์
    • แก้อัตโนมัติได้ 22% ของอีเวนต์ใหม่

ปัญหาที่ความรู้ในการแก้กระจัดกระจายจนทำให้อินซิเดนต์ซ้ำรุนแรงขึ้น

  • ปัญหาจำนวนมากไม่ใช่เรื่องใหม่ทั้งหมด แต่ใกล้เคียงกับ อินซิเดนต์ซ้ำ ที่เคยแก้แล้วในอดีตแต่ไม่มีใครจำได้
  • ตัวอย่างคือสถานการณ์ที่วิศวกรอาวุโสต้องกลับไปหาคำตอบที่ถูกต้องซึ่งเคยอยู่ในเธรด Slack ตอนตี 3 อีกครั้ง
  • กระบวนการแก้ปัญหาถูกทิ้งร่องรอยไว้กระจายตามหลายเครื่องมือ
    • ใน PagerDuty มีการ acknowledge
    • ในเธรด Claude มีการวิเคราะห์วินิจฉัย
    • ในคอมเมนต์ของ PR ที่ปิดไปแล้วมีการแก้ไขจริง
  • แทนที่จะสร้าง runbook จาก prompt อย่างเดียว plsfix จะติดตามแต่ละขั้นตอนจากอินซิเดนต์ที่ทีมเคยแก้จริงในอดีต

4 ขั้นตอนจากการเก็บข้อมูลสู่การรัน

  • Ingest

    • คอนเน็กเตอร์แบบอ่านอย่างเดียวจะดึงงานที่แก้เสร็จแล้วจากจุดที่ทีมใช้แก้ปัญหาจริง
    • ลบ PII ออกก่อนทำ clustering
    • รองรับการเชื่อมต่อกับ Slack, PagerDuty, GitHub, Jira, Linear, ServiceNow, Notion, Claude / ChatGPT

  • Cluster

    • เรียนรู้ signature ของอินซิเดนต์ที่เกิดซ้ำ
    • signature ประกอบด้วย regex ของ payload การแจ้งเตือน, ชุดบริการ, ความใกล้กับการ deploy, รูปแบบของช่องทางและผู้รายงาน เป็นต้น
    • ปัญหาในรูปแบบเดียวกันจะถูกจัดเข้าคลัสเตอร์เดียวกัน

  • Verify

    • สร้างร่าง runbook จากกรณีที่เคยแก้มาก่อน
    • วิศวกรตรวจทานหนึ่งครั้ง แก้ไขได้หากจำเป็น แล้วกด Verify
    • ทุกขั้นตอนมีแหล่งที่มาระบุไว้

  • Execute

    • runbook จะถูกคอมไพล์เป็น skill ที่รันได้
    • ขั้นตอนที่ความเสี่ยงต่ำจะรันอัตโนมัติ
    • งานที่มี blast radius จะหยุดรอผู้อนุมัติที่กำหนดไว้
    • สามารถรัน runbook เดียวกันได้จาก Slack, CLI, PagerDuty, Linear, Jira และ Web inbox

runbook ที่รันได้ทันทีจากในเธรด Slack

  • มีตัวอย่างที่บอตโพสต์ runbook ที่จับคู่กับคลัสเตอร์เดิมในเธรดเดียวกันภายใน 4 วินาทีหลังแจ้งเตือน ด้วยความเชื่อมั่น 94%
  • คลัสเตอร์ตัวอย่างคือ FX rate cache TTL fallback และ runbook ที่ตรวจสอบแล้วเวอร์ชัน v3 ถูกใช้งาน 6 ครั้ง โดยมีอัตราสำเร็จ 83%
  • สัญญาณที่ใช้ในการจับคู่มีดังนี้
    • Signature regex 94%
    • Recent deploy proximity 87%
    • Service overlap 100%
    • Channel + reporter history 71%
  • ตัวอย่าง runbook จัดการปัญหาที่ stale FX rates ถูกนำไปใช้ตั้งราคาของ live trades
    • ระหว่าง Redis eviction เส้นทาง cache miss จะ fallback ไปใช้ค่าคงที่ TTL 1 ชั่วโมงที่หลงเหลือมาจาก load test ปี 2025
    • เหตุการณ์ล่าสุดแสดงว่าเกิดขึ้นเมื่อ 11 วันก่อน
    • ขั้นตอน check และ verify รันอัตโนมัติ ส่วนขั้นตอน fix ต้องได้รับอนุมัติก่อน

ข้อบกพร่องจริงที่ถูกจัดคลัสเตอร์ใน pilot

  • มีการเปิดเผยตัวอย่าง 3 รายการจาก 7 คลัสเตอร์ที่กำลังจัดใน pilot ตอนนี้

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

    • เงื่อนไขคือ fx.rate.age_ms > 60000 และ order.execution.status = filled
    • เส้นทาง cache miss คืนค่าคงที่ TTL_FALLBACK_MS = 3_600_000 ที่หลงเหลือจาก load test
    • ระหว่าง Redis eviction ช่วงพีก มีราว 14k สัญลักษณ์ที่ถูกตั้งราคาด้วย rate ที่เก่ากว่า 60 วินาที
    • ในอินซิเดนต์ก่อนหน้า มี mispriced trades มูลค่า $340k เกิดขึ้นเป็นเวลา 18 นาที ก่อนจะมีการพบด้วยมือ

  • Idempotency keys regenerated on retry → duplicate ACH debits

    • เงื่อนไขคือ ach.duplicate_debit และ idempotency_key.reused = false
    • retry middleware ออก X-Idempotency-Key ใหม่ทุกครั้งที่เจอ 5xx แทนที่จะใช้คีย์เดิมซ้ำ
    • หากธนาคารตอบ 504 แล้วตามด้วย 200 การ retry ครั้งที่สองจะโพสต์ debit ครั้งที่สอง
    • เดือนที่แล้วเกิด duplicate debit 12 ครั้ง และทั้งหมดต้อง reverse ด้วยมือพร้อมขอโทษลูกค้า

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

    • เงื่อนไขคือ pnl.reconcile.diff > 0.01 และ services.disagree = [risk, ledger]
    • risk-svc deserialize จำนวนเงินเป็น float64 ขณะที่ ledger-svc ใช้ Decimal128
    • ระหว่าง JSON round-trip ความละเอียดระดับต่ำกว่าเซ็นต์หายไป และความต่างสะสมข้ามหลายพันรายการจนทำให้เกิด reconciliation ตอนบ่าย
    • ความต่างเล็ก ๆ สะสมอยู่ 4 สัปดาห์จนกลายเป็น recon delta $9.2k ก่อนถูกค้นพบ
    • คลัสเตอร์อื่นใน pilot ที่ถูกระบุเพิ่มเติม ได้แก่ stripe webhook drops post-deploy, postgres pool exhaustion on report-gen, kafka rebalance storm และ market-data WS subscription leak

runbook ไม่ใช่วิกิ แต่เป็นสเปกสำหรับการรัน

  • runbook ที่ผ่านการตรวจสอบทั้งหมดจะถูกคอมไพล์เป็น YAML skill
  • skill จะมี trigger signature, steps, expected outputs และผู้อนุมัติที่กำหนดไว้สำหรับงานเสี่ยง
  • ทุกครั้งที่บันทึกจะมีการตรวจ runbook และ drift check เพื่อไม่ให้เอกสารกับสิ่งที่รันได้แยกออกจากกัน
  • คุณสมบัติของ runbook มีดังนี้
    • ขั้นตอนไม่ใช่ pseudocode แต่เป็น shell command จริง
    • ทุกขั้น fix มีผู้อนุมัติที่กำหนดไว้และระบุ blast radius ไว้อย่างชัดเจน
    • การรันทุกครั้งจะกลายเป็น training example ใหม่สำหรับการจับคู่ครั้งถัดไป
  • ตัวอย่าง YAML แสดง runbook rb-fx-01
    • confidence_threshold เท่ากับ 0.85
    • confirm_cache_age ตรวจอายุ cache และอัตรา eviction จาก Redis
    • force_cache_refresh ต้องได้รับอนุมัติ และมี blast radius ราว 14k symbols กับการหยุด pricing ประมาณ 2 วินาที
    • confirm_fresh_rates ตรวจว่า max age ต่ำกว่า 60 วินาทีหรือไม่
    • หลังรันเสร็จจะส่งแจ้งเตือนไปยัง #payments-platform, #platform-oncall และบันทึก log ลงในเส้นทาง S3

ความน่าเชื่อถือและการกำกับดูแล

  • แนวทางเริ่มต้นคือ read-only และการรันถูกออกแบบให้ต้องผ่าน approval gate
  • สร้างมาสำหรับฟินเทค และมี posture ที่ช่วยให้ทีมความปลอดภัยอนุมัติ pilot และ auditor ลงนามรับรองการรันได้
  • การเก็บรักษาและการวางระบบข้อมูลมีดังนี้
    • เก็บ raw data ไว้ 90 วัน
    • เก็บ redacted data ไว้ 18 เดือน
    • ได้รับการอนุมัติจากฝ่ายกฎหมายใน pilot
    • รองรับ single-tenant deployment
    • training data จะไม่ออกนอก tenant
  • การทำ PII redaction จะเกิดขึ้นก่อน embedding หรือการเรียก LLM
    • email, IP, customer-id และ configurable secrets dictionary จะถูกลบออก
    • artifact ต้นฉบับจะคงอยู่ในตำแหน่งเดิม
  • คอนเน็กเตอร์ทั้งหมดเริ่มต้นแบบ read-only
    • ขอบเขตการรันจะถูกกำหนดเป็นราย runbook
    • ต้องมีผู้อนุมัติที่กำหนดไว้
    • ยกเลิกสิทธิ์ได้ในคลิกเดียว
  • ทุกขั้นตอนของ runbook เชื่อมโยง provenance ย้อนกลับไปถึงอินซิเดนต์ที่เป็นแหล่งเรียนรู้ได้
    • มี audit log แบบ signed ให้สำหรับแต่ละการรัน
    • ส่งออกไปยัง SIEM ได้

พื้นที่การรันและเงื่อนไขของ pilot

  • skill เดียวกันทำงานได้บนหลายพื้นผิวที่ทีมใช้อยู่แล้ว
    • Slack thread auto-suggest: เมื่อเกิด signature ที่คุ้นเคย จะโพสต์ runbook ที่จับคู่ได้ในเธรดเดียวกัน
    • /pls fix CLI: ใช้ runbook และ approval gate เดียวกันจากในเทอร์มินัล
    • PagerDuty incident page: แสดง runbook ที่จับคู่และ one-click run บน incident card ก่อนที่ on-call จะกรอกข้อมูลเสร็จ
    • Linear / Jira issue: เมื่อเปิด issue ด้วย signature ที่รู้จัก ระบบจะใส่ runbook เป็นคอมเมนต์และเสนอให้รัน
    • Web inbox: ให้ platform lead ดู event, cluster, run และ post-mortem ได้ในที่เดียว
  • pilot เป็น Closed pilot โดยมี 4 design partner และระบุเป็น Q2 ปี 2026
  • pilot 6 สัปดาห์มุ่งเป้าไปที่กลุ่มเล็กของทีม fintech และ platform
  • ลำดับการดำเนินงานคือ ingest แบบอ่านอย่างเดียว, ร่วมกันตรวจสอบ 1 cluster, แล้วเปิดใช้ auto-suggest
  • หากภายในสัปดาห์ที่ 4 ยังลด recurring incident volume ไม่ได้ 30% จะไม่คิดค่าใช้จ่าย
  • การตั้งค่า ingest แบบอ่านอย่างเดียวใช้เวลาประมาณ 30 นาที, มี joint cluster review ในสัปดาห์แรก และไม่มี commitment จนถึงสัปดาห์ที่ 4

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2024-05-22
ความคิดเห็นบน Hacker News

  • ในพื้นที่ส่วนใหญ่ นี่เข้าข่าย การติดสินบนเชิงพาณิชย์
    ตาม California Penal Code § 641.3 หากพนักงานรับเงินหรือสิ่งมีค่าเป็นการตอบแทนในการใช้ตำแหน่งของตนเพื่อผู้อื่น โดยที่นายจ้างไม่รับรู้หรือไม่ยินยอม จะถือเป็นความผิดฐานติดสินบนเชิงพาณิชย์
    แต่ถ้าจำนวนเงินหรือมูลค่า ไม่เกิน $250 มาตรานี้จะไม่ถูกนำมาใช้

    • ดูเหมือนกฎหมายจะให้ทางออกที่สะดวกไว้อยู่แล้ว แค่ใส่ ข้อจำกัด <=250 ในช่องเสนอราคาก็น่าจะพอ
    • ถ้าไม่มีวิธีอื่นเลย ประเด็นสำคัญคือสินบนจำเป็นต้องเลวร้ายเสมอไปไหม ถ้า Big Tech ใส่ใจก็คงมีฝ่ายซัพพอร์ตลูกค้าแล้ว แต่เพราะไม่เป็นแบบนั้น ตลาดจึงกำลังสร้างทางออกของตัวเอง
    • คงหมายความว่าถ้าต่ำกว่า $250 ต่อเคสก็ดูจะโอเค
    • แปลกนะ งั้น เงินบริจาคเลือกตั้ง ก็ถูกจำกัดไว้ที่ $250 ด้วยหรือเปล่า?
    • ถ้าโพสต์ที่ไหนก็ได้บนโซเชียลมีเดียว่า “บัญชีของฉันถูกล็อก” บอตจะกรูกันเข้ามาบอกให้ติดต่อใครเพื่อกู้คืน
      จากมุมมองของผม การล็อกบัญชีดูเหมือนเป็น โครงสร้างรีดไถ ที่ไม่ได้รับการควบคุม ซึ่งดำเนินอยู่โดยพนักงานโซเชียลมีเดียหรือบนแพลตฟอร์มเอง โซเชียลมีเดียเองก็ใกล้เคียงกับการหลอกลวงในระดับหนึ่งอยู่แล้ว และยังสร้างโอกาสให้มิจฉาชีพนิรนามจัดกิจกรรมที่ทำให้ผู้คนเข้าใจผิดมาโดยตลอด
      โซเชียลมีเดียผลักดัน NFT, Crypto, วัฒนธรรมอินฟลูเอนเซอร์ และโครงสร้างแบบ “แกล้งทำจนกว่าจะทำได้จริง” สารพัดรูปแบบ กลับไปใช้ชุมชนเว็บอิสระยังจะดีกว่า ช่วงแรกอาจเจ็บปวดอยู่บ้าง แต่ก็ดีกว่าการที่โพสต์โปรโมตธุรกิจมีคนดูแค่ 30 ครั้งเพราะไม่ได้จ่ายเงินมากนัก

  • ดูบ้ามาก บริษัทไหนเจอเรื่องแบบนี้ก็ต้องไล่ออกอยู่แล้ว ชื่อที่ถูกต้องของมันคือ คอร์รัปชัน และแน่นอนว่าควรกังวลผลทางกฎหมายด้วย

    • แน่นอนว่านี่เป็น ปัญหาด้านจริยธรรม ครั้งใหญ่ แต่กลับเป็นจุดที่น่าสนใจที่สุดด้วยซ้ำ เพราะประเด็นจริยธรรม การปฏิบัติตามกฎ และคอร์รัปชัน อาจดึงความสนใจมหาศาลภายในบริษัท และอาจทำให้ปัญหาต้นตอได้รับการปรับปรุงจริงในแบบที่ยั่งยืน
    • อย่างที่หลายคนพูด นี่จะเป็นปัญหาใหญ่ขึ้นในอนาคต
      คนที่สมควรถูกระงับจริง ๆ เช่น คนที่โพสต์คอนเทนต์ผิดกฎหมาย ก็สามารถใช้บริการนี้ได้ ถ้าบริษัทเชื่อแบบฟอร์มที่พนักงานภายในเขียนและปลดระงับให้ คนคนนั้นก็จะโพสต์คอนเทนต์ผิดกฎหมายต่อไปและถูกระงับอีก
      เมื่อมีกรณี false positive แบบนี้สะสมมากพอ สุดท้ายบริษัทจะพบว่าพนักงานกำลังใช้อำนาจพาใครก็ได้เข้ามา บริษัทที่ฉลาดอาจทำเครื่องหมายบัญชีที่พนักงานภายในปลดให้ไว้ จึงอาจจับได้ตั้งแต่กรณีแรก
      จุดจบที่เป็นไปได้มากที่สุดคือพนักงานคนนั้นถูกไล่ออก กรณีแย่ที่สุด บริษัทอาจสั่งห้ามพนักงานภายในทั้งหมดส่งแบบฟอร์มแทนคนนอก
      ถ้าไซต์นี้เป็นมุกตลก อย่างน้อยก็ควรระบุให้ชัดเจน แค่มีข้อจำกัดความรับผิดว่าให้ตรวจสอบคนแปลกหน้ายังไม่พอ ยังน่าสงสัยด้วยว่าพนักงานภายในจะตรวจสอบได้ดีกว่าฝ่ายซัพพอร์ตลูกค้าหรือไม่ และควรเอาฟีเจอร์อย่างการส่งอีเมลหรือการเผยแพร่ออกเพื่อป้องกันการติดต่อและการโอนเงินจริง
    • เห็นด้วย นี่คือโครงสร้างที่รับเงินส่วนตัว แล้วใช้เวลางานและทรัพยากรของบริษัททำสิ่งที่นายจ้างไม่ต้องการ ฟังดูเหมือน สินบน ระดับเบา
      ใน FAQ บอกว่าจะรับประกันความเป็นนิรนามของพนักงาน แต่ขณะเดียวกันก็บอกว่าจะส่งอีเมลยืนยันไปยังอีเมล google.com เพื่อตรวจสอบว่าเป็นพนักงาน Google แน่นอนว่า Google ย่อมเห็นอีเมลนั้นได้
    • อย่างน้อยที่ Meta/Facebook ก็เป็นความลับที่รู้กันทั่วไปมานานแล้วว่า วิธีที่เร็วที่สุดในการทำให้บางอย่างบนแพลตฟอร์มถูกจัดการอย่างรวดเร็วคือการมี คนรู้จักที่ Meta
    • ผมก็อยากคิดแบบนั้น แต่ตอนดำเนินการกับประกาศรับสมัครงานไม่กี่ตำแหน่งที่โพสต์เฉพาะภายใน FAANG คนนอกกลับส่งอีเมลมาถามเกี่ยวกับตำแหน่งเหล่านั้น ทีหลังถึงเห็นว่ามี อุตสาหกรรมนายหน้าขนาดเล็ก เกี่ยวกับการแนะนำแบบจ่ายเงินอยู่ต่างหาก

  • ศาสตราจารย์ 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 และมีทีมที่คอยจับพนักงานที่ขายสิทธิ์เข้าถึงแบบนี้อยู่ สำหรับตำแหน่งสายเทคนิคส่วนใหญ่ที่นั่น เงินจำนวนนี้แทบจะเท่าค่าจ้างประมาณหนึ่งชั่วโมง จึงนึกไม่ออกเลยว่าจะยอมเสี่ยงขนาดนั้นเพื่อเงินแค่นี้

    • พลิกมุม: นี่อาจเป็น ตลาดล่อซื้อ เพื่อจับพนักงานที่ขายสิทธิ์เข้าถึงแบบนี้ก็ได้
    • ใช่ และการรับเงินใต้โต๊ะกับเรื่องแบบนี้ดูไร้จริยธรรมมาก ในทางกลับกัน ถ้าเป็นคนที่เจอปัญหาแบบนี้ ก็คงอยากจ่ายเงินให้คนวงในเพื่อให้แก้ได้
      ประเด็นหลักไม่ใช่แค่ปัญหาทางเทคนิคธรรมดาๆ อย่างบัญชีถูกระงับ แต่คือความรู้สึกว่ามันไม่ยุติธรรมตั้งแต่แรก และความโกรธที่ติดอยู่ในลูปนรกไม่รู้จบ
    • สำหรับคนที่ไม่คุ้นกับ FB สิ่งที่ maxrmk พูดนั้นถูกต้อง ขอเสริมบริบทอีกนิดว่า ถ้าทีม privacy ทีมใดทีมหนึ่งพบการละเมิดแบบนี้ พนักงานมักจะถูกเรียกไปพบ HR แล้วถูกไล่ออกในวันถัดไปทันที
      เพื่อนของผมเคยทำแบบนี้โดยไม่ตั้งใจ ตอนพยายามช่วยเรื่องบัญชีของเพื่อนที่รู้จักเป็นการส่วนตัว เขาไม่รู้ว่ามันเป็นการละเมิด privacy จึงเข้าไปใช้ระบบ แต่หลายเดือนต่อมา ระหว่างตรวจสอบข้อมูลโปรเจกต์ ระบบ audit ถูกทริกเกอร์ และหลังจากพบร่องรอยนั้น วันถัดมาก็ถูกให้ออกจากงานทันที
      ดังนั้นนี่ไม่ใช่ไอเดียธุรกิจที่ดี
    • สิ่งที่ต้องทำจริงๆ คือไปสมัครงานในทีมตรวจจับนั้น แล้วขายความสามารถในการทำให้ทีมนั้นทำเป็นไม่เห็นเคสเหล่านี้ ชื่อเว็บน่าจะประมาณ plsfixmyfix.com
    • ในฐานะคนที่ทำงานอยู่ในบริษัทประเภทนี้แห่งหนึ่ง มันไม่คุ้มที่จะเสี่ยงเลยแม้แต่น้อย

  • ไม่รู้ว่ามีแค่ผมหรือเปล่าที่รู้สึกแบบนี้ แต่ดูเหมือนหลายคนกำลังพลาดภาพใหญ่ บริการแบบนี้เกิดขึ้นก็ต่อเมื่อทางแก้ปกติไม่สามารถแก้ปัญหาได้
    สำหรับผม มันเหมือนสัญญาณว่า Big Tech ไม่สามารถสร้าง กระบวนการอุทธรณ์ที่มีประสิทธิภาพ ให้สอดคล้องกับความต้องการของผู้บริโภคได้มากกว่า แม้มันอาจไม่ได้ทำเงินมากนัก แต่ก็น่าดูว่า Big Tech จะปรับปรุงส่วนนี้อย่างไร

    • ไม่น่าจะใช่ ประเด็นหลักคือความไร้ประสิทธิภาพ บริการนี้เป็นเรื่องตลก และเกือบจะแน่นอนว่าผิดกฎหมาย ทุกคนรู้ว่าระบบนี้ “พัง” แต่การขยายบริการลูกค้าฟรีไปตลอดกาลก็ทำไม่ได้
      ความต้องการที่สมเหตุสมผลต่อบริการแบบนี้พิสูจน์ให้เห็นถึงมูลค่าของบัญชีเหล่านั้น ผมคิดว่าในอีกไม่กี่ปี บริษัทเทคโนโลยีจะลงมาเล่นตรงนี้เองโดยตรง และให้ บริการลูกค้าแบบเสียเงิน เหมือนที่ลูกค้าองค์กรได้รับ ตอนนี้ก็จ่ายเงินซื้อบัญชี “ยืนยันแล้ว” ได้อยู่แล้ว ขั้นต่อไปก็คือทางนี้ ถ้าบริษัทไม่ทำเงินจากมัน รัฐบาลก็จะเข้ามากำกับ
    • ก่อนจะมีสิ่งนี้ คำขอจากภายในส่วนใหญ่น่าจะมาจากพนักงานที่ต้องการช่วยคนจริงๆ แน่นอนว่าอาจมีพนักงานบางคนที่รับเงินเพื่อส่งแบบฟอร์มภายในอยู่แล้ว แต่ไม่น่าจะแพร่หลาย
      การทำให้ขั้นตอนนี้เป็นทางการแบบเว็บไซต์นี้ จะเพิ่มโอกาสอย่างมากที่การส่งแบบฟอร์มภายในเพื่อปลดระงับบัญชีจะเกิดขึ้นเพื่อแลกกับเงิน เพราะมันสร้างตลาดที่จับคู่ผู้ยื่นคำขอกับพนักงานไร้จริยธรรม ลดแรงเสียดทานในการทำธุรกรรม และชูเรื่องเงินอย่างโจ่งแจ้ง ดึงดูดพนักงานที่หวังเงินมากกว่าต้องการช่วยคนที่ถูกระงับบัญชีอย่างไม่เป็นธรรม
      ดังนั้นมันจึงดูเป็นโครงสร้างที่ น่ารังเกียจทางจริยธรรม มากกว่ากระบวนการเดิมอย่างมาก
    • คนส่วนใหญ่ใน HN น่าจะรู้ดีว่า Big Tech ไม่สามารถสร้างกระบวนการอุทธรณ์ที่มีประสิทธิภาพได้ ไม่ใช่ความลับเลย แต่ถึงอย่างนั้นบริการนี้ก็เป็นการทุจริตอย่างโจ่งแจ้ง

  • เคยเห็นแนวทางที่เป็นผู้ประกอบการมากกว่านี้มาก่อน เป็นเรื่องที่โมเดล OnlyFans ค้นหาพนักงานบน LinkedIn แล้วแลก การมีเพศสัมพันธ์กับการปลดระงับบัญชี เพื่อเอาบัญชี Instagram กลับคืนมา
    https://www.newsweek.com/onlyfans-star-slept-meta-employees-...

  • จะตรวจสอบได้อย่างไรว่าผู้ร้องขอเป็นคนธรรมดาที่ถูกบล็อกโดยไม่มีเหตุผลจริงๆ หรือเป็นคนที่ถูกบล็อกอย่างชอบธรรมด้วยเหตุผลทางกฎหมายอย่าง CSAM หรือเพราะละเมิดข้อกำหนดการให้บริการ?
    ถ้า Mike Meta ปลดล็อกบัญชีผู้ก่อการร้ายตัวจริงแล้วถูกไล่ออก โดยเฉพาะเมื่อเห็นได้ชัดว่าบริษัทคงมอนิเตอร์การกล่าวถึงภายในอยู่ บริการนี้จะรับผิดชอบหรือเปล่า?

    • ถ้าเป็น “พนักงานที่ผ่านการตรวจสอบแล้ว” ของบริษัท เขาอาจตรวจสอบเองก่อนยื่นเอกสารที่เหมาะสมได้ แต่ถ้าทำแบบนั้น ปกติจะทิ้ง ร่องรอยบันทึก แยกต่างหากไว้ และมีโอกาสสูงที่จะย้อนกลับมาหาตัวเองในที่สุด
      พูดตรงๆ ตรงนี้ความเสี่ยงสูงกว่าผลตอบแทนมาก ไม่เข้าใจเลยว่าทำไมใครถึงอยากทำตั้งแต่แรก
      ระหว่าง “งานเงินเดือนหกหลักที่มั่นคง” กับ “เงินครั้งเดียว $100 จากคนแปลกหน้าบนอินเทอร์เน็ต” คำตอบก็ชัดเจน
      พูดตรงๆ มีกลิ่นเหมือนการล่อซื้อ
    • น่าจะคล้ายกับวิธีที่ปัญหาถูกแก้เมื่อเรื่องราวน่าสงสารของใครสักคนกลายเป็นไวรัล พนักงานเห็นเรื่องนั้นแล้วส่ง ticket ว่า “คนแปลกหน้าคนนี้กำลังเจอปัญหา XYZ” จากนั้นฝ่ายซัพพอร์ตตรวจสอบและดำเนินการที่เหมาะสม
      ไม่รู้ว่ากระบวนการจริงของ Meta เป็นอย่างไร
    • เท่าที่รู้ สาเหตุทั่วไปอย่างหนึ่งที่บัญชีถูกแช่แข็งคือระบบมองว่าบัญชีถูกคนอื่นยึดไป การสร้าง ช่องทางลัดแบบเร่งด่วน เพื่อกู้สิทธิ์เข้าถึงบัญชีแบบนั้นต้องทำอย่างระมัดระวังมาก

  • ต้องเช็กเลยว่าวันนี้เป็นวันเมษาหน้าโง่หรือเปล่า นี่เป็นหนึ่งในโพสต์ที่ช็อกที่สุดที่เห็นช่วงหลังๆ หวังจากใจว่าคนที่ได้ประโยชน์จากสิ่งนี้อย่างน้อยจะถูกไล่ออก

    • ตัวแนวคิดเองดูเหมือน การประท้วงเชิงศิลปะการแสดง แบบหนึ่ง
      การสร้างแพลตฟอร์มสำหรับติดสินบนเพื่อฝ่าระบบที่ไม่โปร่งใสและแทบไม่มีบริการลูกค้าของบริษัทเหล่านี้ อาจเป็นคอร์รัปชันระดับต่ำ หรือเป็นศิลปะระดับสูงก็ได้
    • พนักงานที่จะสมัครใช้บริการนี้ควรระวัง Facebook จะต้องฟ้องคนนี้แน่นอน และบันทึกการชำระเงินจะเป็นเอกสารชุดแรกๆ ที่ต้องส่งมอบในกระบวนการเปิดเผยพยานหลักฐาน
      มองไม่เห็นเลยว่าจะรักษาความเป็นนิรนามได้นานแค่ไหน
    • กลับกัน มันดูเหมือนช่วยคืน สิทธิของคนธรรมดา บางส่วนที่บริษัทยักษ์ใหญ่ด้านเทคโนโลยีไม่รู้สึกว่าจำเป็นต้องเคารพ

  • ผมเข้าใจเต็มที่ว่าทำไมสิ่งนี้ถึงถูกมองว่าไร้จริยธรรม และก็เข้าใจด้วยว่าพนักงานที่รับเงินรางวัลอาจถูกไล่ออก
    แต่ในทางปฏิบัติแล้วมันผิดกฎหมายข้อไหนกันแน่? ผมคิดว่าทางกฎหมายมันน่าจะเป็นสินบน เพราะเป็นการส่งเสริมให้มีการดำเนินการที่ไม่ปกติ เพียงแต่ว่าประเด็นคือมันเป็นเพราะส่วนที่ว่า “ไม่ปกติ” นั่นแหละ บริษัทจะไปขึ้นศาลแล้วดำเนินคดีเรื่องนี้ได้หรือ โดยต้องยอมรับว่ากระบวนการอุทธรณ์การระงับบัญชีของตัวเองเป็นเรื่องไม่ปกติ?
    แล้วมันละเมิดข้อไหนในสัญญาจ้างมาตรฐาน? การทำบริการที่นายจ้างไม่ได้จัดให้แล้วรับเงินงั้นหรือ? ที่น่าสนใจคือ ถ้านายจ้างเป็นผู้ให้บริการนั้นเอง มันก็จะไม่ใช่สินบนอีกต่อไป แต่กลายเป็นค่าธรรมเนียมเร่งด่วนที่ถูกกฎหมาย ดังนั้นถ้าจะป้องกันเรื่องนี้ ก็คงต้องใส่ข้อกำหนดแยกต่างหากไว้ในสัญญาจ้าง
    ไม่ได้ถามเชิงวาทศิลป์ แต่กำลังหาคำตอบจริง ๆ
    ในหลายแง่ กระบวนการนี้เกิดขึ้นอยู่แล้ว และผู้ที่เกี่ยวข้องก็คาดหวังอยู่ระดับหนึ่ง ผมเคยเห็นหลายกรณีที่การตัดสินใจดูเหมือนจะถูกพลิกกลับเพราะคนดังบน Twitter สามารถสร้างกระแสได้มากพอ และยังเคยขึ้นหน้าแรกที่นี่ด้วย ความแตกต่างมีแค่ ชนิดของสกุลเงิน ที่ใช้เพื่อเลี่ยงระบบเท่านั้น

    • มีวิธีแก้ง่าย ๆ อยู่ ให้เปลี่ยนจำนวนเงินเป็นเงินบริจาคให้การกุศลที่คนคนนั้นเลือกเอง อาจเป็นองค์กรที่บริษัทบริจาคให้ทุกปีอยู่แล้วก็ได้ และแบบนั้นก็จะทำให้การไล่คนที่หาเงินให้การกุศลออกทำได้ยากขึ้นมาก
    • เรื่องนี้เรียกว่า สินบนเชิงพาณิชย์ เพียงแต่โดยปกติกฎหมายของรัฐจะเป็นผู้จัดการเรื่องเหล่านี้ จึงขึ้นอยู่กับเขตอำนาจศาล มีคนอื่นโพสต์บทบัญญัติกฎหมายของแคลิฟอร์เนียไว้แล้ว
      ในกรณีของแคลิฟอร์เนีย ถ้าจำนวนเงินต่ำกว่า $250 กฎหมายจะไม่บังคับใช้ แต่ในเว็บต้นทางมี “เงินรางวัล” จำนวนไม่น้อยที่เกินเกณฑ์นั้น
      ไม่แน่ใจว่าเป็นมาตรฐานหรือไม่ แต่พนักงานจำนวนมากเซ็นเอกสารว่าจะไม่รับงานจ้างอื่น ผมไม่รู้ว่าสิ่งนี้นับเป็น “การจ้างงาน” หรือเปล่า แต่ก็คงไม่น่าแปลกใจถ้าสัญญาจ้างบางฉบับมีถ้อยคำที่กว้างกว่านั้น เช่น “ห้ามทำงานรับค่าจ้างภายนอก”
      [0] https://news.ycombinator.com/item?id=40435890
    • สัญญาจ้างที่ผมเคยทำ อย่างน้อยก็กำหนดให้ต้องแจ้ง งานเชิงพาณิชย์ ที่ทำนอกบริษัท และบางครั้งต้องได้รับอนุมัติก่อนเริ่มด้วย หากมีงานรับค่าจ้างที่สองโดยไม่เปิดเผย ก็เพียงพอที่จะเป็นเหตุให้บริษัทไล่ออกได้ หากบริษัทต้องการ
    • จากมุมมองของพนักงานที่ให้บริการ อย่างน้อยก็มีความเป็นไปได้สูงว่าเป็นการละเมิดสัญญา

  • อ้างอิงไว้ว่า ด้วยการมีคนรู้จักที่ Google และ Stripe สตาร์ทอัพของผมจึงรอดจากหายนะระดับพังพินาศมาได้ ทั้งสองแห่งมีระบบอัตโนมัติที่ตรวจจับเราผิดพลาดและหยุดการประมวลผลการชำระเงินของเรา และเราไม่มีทางอื่นเลย
    เฉพาะเพราะมีคนข้างในเท่านั้น เราจึงสามารถอุทธรณ์ต่อคนที่ตัดสินใจได้จริง
    ผมไม่ได้มองว่าแพลตฟอร์มแบบนี้โอเค มันมีด้านที่น่าสงสัยในเชิงจริยธรรม แต่ประเด็นสำคัญคือ ถ้าคุณไม่ได้รู้จักเป็นการส่วนตัวกับ คนรู้จักระดับสูง สักหลายคนในบริษัทที่คุณตั้งใจจะพึ่งพา ก็ไม่ควรรับความเสี่ยงจากการพึ่งพานั้น

    • คุณกำลังบอกว่าการใช้เส้นสายเพื่อหลีกเลี่ยง “หายนะระดับพังพินาศ” ของตัวเองนั้นโอเค แต่การที่คนอื่นพยายามทำสิ่งเดียวกันกลับน่าสงสัยในเชิงจริยธรรมหรือ?
    • มองเผิน ๆ ก็รู้สึกเหมือนขัดแย้งกัน ดูเหมือนละเมิด จริยธรรมของอภิสิทธิ์ บางทีให้ทุกคนจ่ายเงินอาจดีกว่าและยุติธรรมกว่าด้วยซ้ำ