Plsfix — Issue Brain cho kỹ thuật nền tảng

 (plsfix.co)
1 điểm bởi GN⁺ 2024-05-22 | 1 bình luận | Chia sẻ qua WhatsApp
  • plsfix tập hợp các bản ghi sự cố đã được giải quyết, biến chúng thành runbook đã được kiểm chứng và skill có thể thực thi; khi cùng một lỗi lặp lại, nó cung cấp nút chạy ngay trong thread
  • Luồng gồm thu thập chỉ đọc, clustering sự cố lặp lại, kỹ sư kiểm chứng và thực thi; mỗi bước đều dựa trên các trường hợp đội từng giải quyết trong quá khứ
  • Trong ví dụ pilot, hệ thống tìm được 7 cluster lặp lại từ 14.802 sự kiện, 22% sự kiện mới được tự động giải quyết, và ví dụ Slack khớp runbook với độ tin cậy 94% sau 4 giây kể từ cảnh báo
  • Runbook được biên dịch thành YAML skill; các bước an toàn được tự động thực thi, nhưng những sửa đổi có blast radius sẽ dừng lại ở người phê duyệt được chỉ định
  • Pilot 6 tuần dành cho các đội fintech và nền tảng sẽ không thu phí nếu đến tuần 4 không giảm được 30% khối lượng sự cố lặp lại; việc thiết lập thu thập chỉ đọc mất khoảng 30 phút

Sản phẩm biến sự cố lặp lại thành tri thức có thể thực thi

  • plsfix lấy các sự cố mà đội đã giải quyết từ Slack, PagerDuty, GitHub, Claude, v.v. và chuyển chúng thành runbook đã được kiểm chứng cùng skill có thể thực thi
  • Khi một lỗi cùng dạng xảy ra lại, bot đăng câu trả lời trong cùng thread, và người dùng có thể chạy bằng một lần nhấp vào Run playbook
  • Các chỉ số pilot trên màn hình ban đầu được hiển thị là dữ liệu tuần 1 của pilot acme
    • Thu thập 14.802 sự kiện
    • Xác định 7 cluster lặp lại
    • Tự động giải quyết 22% sự kiện mới

Vấn đề tri thức xử lý bị phân tán khiến sự cố lặp lại phình to

  • Nhiều sự cố không hẳn là vấn đề hoàn toàn mới, mà gần với sự cố lặp lại: đã từng được giải quyết nhưng không được ghi nhớ
  • Ví dụ là tình huống một kỹ sư senior phải tìm lại đúng cách xử lý từng nằm trong thread Slack lúc 3 giờ sáng
  • Quá trình xử lý còn rải rác trên nhiều công cụ
    • PagerDuty có acknowledge
    • Thread Claude có phần chẩn đoán
    • Comment trong PR đã đóng có bản sửa thực tế
  • Thay vì tạo runbook chỉ bằng prompt, plsfix truy vết từng bước từ các sự cố mà đội đã thực sự giải quyết trước đó

4 bước từ thu thập đến thực thi

  • Ingest

    • Connector chỉ đọc lấy các công việc đã được giải quyết từ nơi đội thực sự xử lý vấn đề
    • Loại bỏ PII trước khi clustering
    • Các đích kết nối gồm Slack, PagerDuty, GitHub, Jira, Linear, ServiceNow, Notion, Claude / ChatGPT

  • Cluster

    • Học signature của các sự cố lặp lại
    • Signature gồm regex của alert payload, tập hợp service, mức gần với lần deploy, pattern về channel và người báo cáo, v.v.
    • Các lỗi cùng dạng được phân loại vào cùng cluster

  • Verify

    • Tạo bản nháp runbook dựa trên các trường hợp xử lý trong quá khứ
    • Kỹ sư xem xét một lần, chỉnh sửa nếu cần rồi nhấn Verify
    • Mọi bước đều có nguồn tham chiếu

  • Execute

    • Runbook được biên dịch thành skill có thể thực thi
    • Các bước rủi ro thấp được tự động chạy
    • Tác vụ có blast radius sẽ dừng ở người phê duyệt được chỉ định
    • Có thể chạy cùng runbook từ Slack, CLI, PagerDuty, Linear, Jira, Web inbox

Runbook chạy ngay trong thread Slack

  • Có ví dụ trong đó 4 giây sau cảnh báo, bot đăng vào cùng thread một runbook đã khớp với cluster hiện có ở độ tin cậy 94%
  • Cluster ví dụ là FX rate cache TTL fallback; runbook đã kiểm chứng v3 đã được dùng 6 lần với tỷ lệ thành công 83%
  • Các tín hiệu khớp gồm
    • Signature regex 94%
    • Recent deploy proximity 87%
    • Service overlap 100%
    • Channel + reporter history 71%
  • Ví dụ runbook xử lý vấn đề stale FX rates được dùng để định giá live trades
    • Trong lúc Redis eviction, cache miss path fallback về hằng số TTL 1 giờ còn sót lại từ load test năm 2025
    • Lần xảy ra gần nhất được hiển thị là 11 ngày trước
    • Các bước check và verify được tự động chạy, bước fix cần phê duyệt

Các lỗi thực tế được clustering trong pilot

  • Công khai 3 ví dụ trong số 7 cluster hiện đang được clustering trong pilot

  • FX rate cache TTL fallback đặt thành 1 giờ, không phải 1 phút

    • Điều kiện là fx.rate.age_ms > 60000 và order.execution.status = filled
    • Cache miss path trả về hằng số TTL_FALLBACK_MS = 3_600_000 còn sót lại từ load test
    • Trong giờ cao điểm Redis eviction, khoảng 14k symbol được định giá bằng rate cũ hơn 60 giây
    • Ở sự cố trước đó, trước khi được phát hiện thủ công, đã xảy ra $340k mispriced trades trong 18 phút

  • Idempotency keys được tạo lại khi retry → duplicate ACH debits

    • Điều kiện là ach.duplicate_debit và idempotency_key.reused = false
    • Retry middleware cấp X-Idempotency-Key mới sau mỗi 5xx thay vì dùng lại khóa ban đầu
    • Khi ngân hàng trả 504 rồi sau đó trả 200, lần retry thứ hai đăng debit thứ hai
    • Tháng trước có 12 giao dịch debit trùng lặp, tất cả đều cần reversal thủ công và xin lỗi khách hàng

  • Decimal precision drift giữa risk-svc và ledger-svc

    • Điều kiện là pnl.reconcile.diff > 0.01 và services.disagree = [risk, ledger]
    • risk-svc deserialize số tiền bằng float64, còn ledger-svc dùng Decimal128
    • Trong JSON round-trip, độ chính xác dưới cent bị mất, và chênh lệch tích lũy qua hàng nghìn giao dịch, kích hoạt reconciliation vào buổi chiều
    • Được phát hiện sau khi các chênh lệch nhỏ tích lũy trong 4 tuần thành $9.2k recon delta
    • Các cluster pilot khác được liệt kê gồm stripe webhook drops post-deploy, postgres pool exhaustion on report-gen, kafka rebalance storm, market-data WS subscription leak

Runbook không phải wiki mà là đặc tả thực thi

  • Mọi runbook đã kiểm chứng được biên dịch thành YAML skill
  • Skill bao gồm trigger signature, steps, expected outputs và người phê duyệt được chỉ định cho các tác vụ rủi ro
  • Mỗi lần lưu đều chạy runbook và drift check để tài liệu và artifact thực thi không bị lệch nhau
  • Các thuộc tính của runbook như sau
    • Các bước là shell command thực tế, không phải mã giả
    • Mỗi bước fix có người phê duyệt được chỉ định và blast radius được nêu rõ
    • Mọi lần chạy trở thành training example mới cho lần matching tiếp theo
  • Ví dụ YAML cho thấy runbook rb-fx-01
    • confidence_threshold là 0.85
    • confirm_cache_age kiểm tra cache age và eviction rate trong Redis
    • force_cache_refresh cần phê duyệt, và blast radius là khoảng 14k symbols cùng khoảng 2 giây pricing pause
    • confirm_fresh_rates kiểm tra max age có dưới 60 giây hay không
    • Sau khi chạy, thông báo tới #payments-platform, #platform-oncall và để lại log tại đường dẫn S3

Niềm tin và quản trị

  • Tư thế mặc định là read-only, và việc thực thi được thiết kế để đi qua cổng phê duyệt
  • Được xây dựng cho fintech, cung cấp posture để đội bảo mật có thể phê duyệt pilot và auditor có thể ký xác nhận run
  • Lưu giữ và triển khai dữ liệu như sau
    • Dữ liệu raw được lưu 90 ngày
    • Dữ liệu đã redacted được lưu 18 tháng
    • Có phê duyệt của Legal trong pilot
    • Có thể dùng single-tenant deployment
    • Training data không rời khỏi tenant
  • PII redaction được thực hiện trước embedding hoặc LLM call
    • Loại bỏ email, IP, customer-id và configurable secrets dictionary
    • Artifact gốc vẫn nằm ở vị trí ban đầu
  • Tất cả connector đều bắt đầu ở chế độ read-only
    • Scope thực thi được cấp theo từng runbook
    • Cần người phê duyệt được chỉ định
    • Có thể revoke bằng một lần nhấp
  • Mọi bước runbook đều có provenance truy ngược tới sự cố xử lý đã trở thành nguồn học
    • Audit log theo từng run được cung cấp ở trạng thái signed
    • Có thể export sang SIEM

Bề mặt thực thi và điều kiện pilot

  • Cùng một skill hoạt động trên nhiều bề mặt mà đội đã dùng
    • Slack thread auto-suggest: khi một signature quen thuộc xảy ra, đăng runbook khớp vào cùng thread
    • /pls fix CLI: dùng cùng runbook và cổng phê duyệt trong terminal
    • PagerDuty incident page: hiển thị runbook khớp và one-click run trên incident card trước khi on-call nhập xong
    • Linear / Jira issue: khi mở issue với signature đã biết, đính kèm runbook bằng comment và đề xuất thực thi
    • Web inbox: platform lead có thể xem event, cluster, run, post-mortem ở một nơi
  • Pilot là Closed pilot và được hiển thị là Q2 2026 với 4 design partner
  • Pilot 6 tuần nhắm tới nhóm nhỏ thuộc các đội fintech và platform
  • Cách tiến hành theo thứ tự: ingest chỉ đọc, cùng kiểm chứng 1 cluster, bật auto-suggest
  • Nếu đến tuần 4 không giảm được 30% recurring incident volume thì không thu phí
  • Thiết lập ingest chỉ đọc mất khoảng 30 phút; tuần 1 tiến hành joint cluster review, và không có commitment cho đến tuần 4

Bài viết liên quan

1 bình luận

 
GN⁺ 2024-05-22
Các ý kiến trên Hacker News

  • Ở hầu hết các khu vực, việc này thuộc dạng hối lộ thương mại
    Theo California Penal Code § 641.3, nếu một nhân viên nhận tiền hoặc thứ gì có giá trị để đổi lấy việc sử dụng vị trí của mình vì lợi ích của người khác mà chủ lao động không biết hoặc không đồng ý, thì đó là tội hối lộ thương mại
    Tuy nhiên, điều khoản này không áp dụng nếu số tiền hoặc giá trị từ $250 trở xuống

    • Có vẻ luật đã đưa ra một cách xử lý tiện lợi. Tức là chỉ cần đặt ràng buộc <=250 cho trường đấu giá
    • Vấn đề cốt lõi là liệu hối lộ có nhất thiết là xấu hay không khi hoàn toàn không còn cách nào khác. Nếu Big Tech quan tâm thì đã có hỗ trợ khách hàng, nhưng vì không có nên thị trường đang tự tạo ra giải pháp
    • Có vẻ ý là nếu dưới $250 mỗi vụ thì ổn
    • Kỳ lạ. Vậy khoản đóng góp bầu cử cũng bị giới hạn ở $250 à?
    • Cứ đăng “tài khoản của tôi bị khóa” ở bất cứ đâu trên mạng xã hội, là bot sẽ kéo đến bảo bạn liên hệ với ai để khôi phục
      Theo góc nhìn của tôi, việc khóa tài khoản trông giống như một cơ chế tống tiền không được kiểm soát do nhân viên mạng xã hội hoặc những người hoạt động trên nền tảng vận hành. Bản thân mạng xã hội cũng phần nào gần với lừa đảo, và liên tục tạo cơ hội để những kẻ lừa đảo ẩn danh tổ chức hoạt động đánh lừa người khác
      Mạng xã hội đã thúc đẩy NFT, Crypto, văn hóa influencer và đủ kiểu cấu trúc “giả vờ cho đến khi thành công”; thà quay lại các cộng đồng web độc lập còn hơn. Ban đầu sẽ đau đớn một chút, nhưng vẫn tốt hơn nhiều so với việc bài quảng bá doanh nghiệp chỉ có 30 lượt xem vì bạn không trả tiền

  • Trông thật điên rồ. Bất kỳ công ty nào cũng đương nhiên sẽ sa thải người làm chuyện như thế. Tên gọi chính xác là tham nhũng, và rõ ràng cũng phải lo về hệ quả pháp lý

    • Rõ ràng đây là một vấn đề đạo đức rất lớn, nhưng chính điểm đó lại là điều thú vị nhất. Vì các vấn đề đạo đức, tuân thủ và tham nhũng, nó có thể thu hút sự chú ý rất lớn trong nội bộ công ty và có khả năng khiến vấn đề gốc rễ được cải thiện theo cách thực sự bền vững
    • Như những người khác đã nói, đây là một vấn đề lớn sẽ ngày càng nghiêm trọng
      Một người đáng bị đình chỉ thật sự, chẳng hạn người đăng nội dung bất hợp pháp, có thể sử dụng dịch vụ này. Nếu công ty tin vào biểu mẫu do nhân viên nội bộ viết và gỡ đình chỉ, người đó sẽ tiếp tục đăng nội dung bất hợp pháp rồi lại bị đình chỉ
      Khi tích lũy đủ các trường hợp dương tính thật như vậy, cuối cùng công ty sẽ phát hiện nhân viên đang dùng quyền hạn để cho bất kỳ ai vào. Một công ty thông minh có thể phát hiện ngay từ trường hợp đầu tiên, vì họ sẽ đánh dấu các tài khoản được nhân viên nội bộ gỡ khóa
      Kết cục có khả năng cao nhất là nhân viên đó bị sa thải. Trong trường hợp xấu nhất, công ty có thể cấm toàn bộ nhân viên nội bộ gửi biểu mẫu thay cho người ngoài
      Nếu trang này là trò đùa thì ít nhất phải ghi rõ điều đó. Chỉ có tuyên bố miễn trừ trách nhiệm rằng hãy xác minh người lạ là không đủ. Cũng đáng nghi liệu nhân viên nội bộ có xác minh tốt hơn hỗ trợ khách hàng hay không, và cần loại bỏ các chức năng như gửi email hoặc công khai để ngăn liên hệ và chuyển tiền thực tế
    • Đồng ý. Đây là cấu trúc nhận tiền cá nhân rồi dùng thời gian và tài nguyên của công ty để làm việc mà chủ lao động không muốn. Nghe giống một dạng hối lộ cường độ thấp
      FAQ nói rằng đảm bảo ẩn danh cho nhân viên, nhưng đồng thời lại nói họ gửi email xác nhận đến địa chỉ google.com để xác minh đó là nhân viên Google. Đương nhiên Google có thể xem email đó
    • Ít nhất tại Meta/Facebook, từ lâu đã là bí mật công khai rằng cách nhanh nhất để xử lý một việc gì đó trên nền tảng là có người quen ở Meta
    • Tôi cũng muốn nghĩ vậy, nhưng khi xử lý vài tin tuyển dụng chỉ đăng nội bộ trong FAANG, có những người bên ngoài đã gửi email hỏi về các vị trí đó. Sau này mới thấy có hẳn một ngành môi giới nhỏ xoay quanh việc giới thiệu có trả phí

  • Giáo sư Robert Klitgaard từng nói tham nhũng = độc quyền + quyền tùy nghi - minh bạch. Ban đầu câu này viết về hệ thống chính trị và hối lộ, nhưng cũng áp dụng được ở đây
    https://globalanticorruptionblog.com/2014/05/27/klitgaards-m...
    Nhiều công ty công nghệ có độc quyền trong thị trường của mình, quyền tùy nghi vô hạn và mức minh bạch gần như bằng 0. Điều đáng ngạc nhiên hơn là chưa có ai nghĩ ra startup phí xử lý nhanh sớm hơn
    https://en.wikipedia.org/wiki/Facilitating_payment
    Phần lớn bình luận xem đây là giao dịch bất lợi cho nhân viên, và nếu chỉ là gỡ đình chỉ tài khoản với $500 thì có thể đúng. Nhưng nếu một người lương $300k bị kẹt trong tình huống mã 2FA của mọi tài khoản đều được gửi về email, hoặc là người làm kinh doanh dựa trên mạng xã hội, họ có thể sẵn sàng trả nhiều hơn $500 rất nhiều để lấy lại tài khoản
    Không phải mọi nhân viên Big Tech đều ở San Francisco. Ở các khu vực chi phí thấp như châu Âu, có nhiều người chỉ kiếm được khoảng một nửa người Mỹ, và thu nhập càng thấp thì càng dễ bị cám dỗ kiểu này
    Tôi không bênh vực hối lộ, nhưng thật ngạc nhiên khi phản ứng gần như nhất trí là việc trả tiền cho nhân viên công ty mạng xã hội là không khả thi. Trong lịch sử, các hệ thống thiếu minh bạch và nơi nhân viên có quyền tùy nghi có thể quy đổi thành tiền đều đã bị tham nhũng
    Các công ty công nghệ nên nhìn nhận việc này nghiêm túc hơn. Một khi mọi người quen với việc trả tiền để được đối xử công bằng bởi người ra quyết định, sẽ rất khó thay đổi hành vi đó

    • Cách duy nhất để thắng là không tham gia. Mạng xã hội là dịch bệnh của nhân loại

  • Một bên thực chất là hành vi gần như chắc chắn bị sa thải, bên kia là 150 USD.
    Trước đây tôi từng làm ở FB, và có một đội chuyên bắt những nhân viên bán quyền truy cập kiểu này. Với hầu hết các vị trí kỹ thuật ở đó, thật khó tưởng tượng ai lại chấp nhận rủi ro như vậy chỉ vì số tiền về cơ bản tương đương khoảng một giờ lương.

    • Cú twist: đây có thể là một chợ honeypot để bắt những nhân viên bán quyền truy cập kiểu này.
    • Đúng vậy, nhận kickback cho những việc như thế này trông rất vô đạo đức. Mặt khác, nếu ở vị thế người gặp vấn đề này, tôi nghĩ họ sẽ muốn trả tiền cho người nội bộ để được giải quyết.
      Vấn đề cốt lõi không chỉ là một sự cố kỹ thuật đơn giản, như tài khoản bị khóa, mà là cảm giác bị đối xử bất công ngay từ đầu và sự phẫn nộ khi mắc kẹt trong một vòng lặp địa ngục vô tận.
    • Với những ai không rành FB, maxrmk nói đúng. Bổ sung thêm một chút bối cảnh: nếu một trong các đội privacy phát hiện vi phạm kiểu này, nhân viên thường sẽ bị gọi vào cuộc họp với HR và bị sa thải ngay ngày hôm sau.
      Một người bạn của tôi đã vô tình làm chuyện như vậy khi cố giúp xử lý vấn đề tài khoản cho một người bạn quen ngoài đời. Anh ấy không biết đó là vi phạm privacy và đã truy cập hệ thống; vài tháng sau, khi dữ liệu dự án được điều tra, một cuộc audit được kích hoạt, và ngay ngày sau khi log đó được phát hiện, anh ấy bị cho nghỉ việc.
      Vì vậy đây không phải là ý tưởng kinh doanh hay.
    • Thứ thật sự cần là xin vào làm ở đội phát hiện đó, rồi bán khả năng khiến đội đó làm ngơ trước các vụ việc. Tên miền có thể là plsfixmyfix.com.
    • Với tư cách người làm ở một trong những công ty như vậy, rủi ro đó tuyệt đối không đáng.

  • Không biết chỉ mình tôi cảm thấy vậy không, nhưng có vẻ nhiều người đang bỏ lỡ bức tranh lớn. Những dịch vụ kiểu này chỉ xuất hiện khi các kênh giải quyết bình thường không xử lý được vấn đề.
    Với tôi, đây giống một tín hiệu cho thấy Big Tech đã không tạo được quy trình khiếu nại hiệu quả phù hợp với nhu cầu của người tiêu dùng. Có lẽ không kiếm được nhiều tiền, nhưng sẽ tốt nếu xem Big Tech cải thiện phần này như thế nào.

    • Tôi không nghĩ vậy. Sự kém hiệu quả mới là trọng tâm. Dịch vụ này là một trò đùa, và gần như chắc chắn là bất hợp pháp. Ai cũng biết hệ thống này “hỏng”, nhưng không thể mở rộng hỗ trợ khách hàng miễn phí mãi mãi.
      Nhu cầu chính đáng đối với những dịch vụ như thế này chứng minh giá trị của các tài khoản đó. Tôi nghĩ trong vài năm nữa, các công ty công nghệ sẽ tự nhảy vào lĩnh vực này và cung cấp hỗ trợ khách hàng trả phí giống như khách hàng doanh nghiệp đang nhận được. Giờ đã có thể trả tiền cho tài khoản “verified”, nên bước tiếp theo là đây. Nếu công ty không kiếm tiền từ nó, chính phủ sẽ quản lý.
    • Trước khi thứ này xuất hiện, phần lớn các yêu cầu nội bộ có lẽ thực sự đến từ những nhân viên muốn giúp người khác. Tất nhiên cũng có thể đã có nhân viên nhận tiền để nộp biểu mẫu nội bộ, nhưng khả năng phổ biến rộng là thấp.
      Khi chính thức hóa quy trình như website này, khả năng việc nộp biểu mẫu nội bộ để gỡ khóa tài khoản được thực hiện để đổi lấy tiền sẽ cao hơn nhiều. Vì nó tạo ra một chợ ghép nối người nộp đơn với nhân viên vô lương tâm, giảm ma sát trong việc thực hiện giao dịch, và công khai đặt tiền lên trước, thu hút những nhân viên nhắm đến tiền hơn là giúp người bị khóa tài khoản một cách bất công.
      Vì vậy, cấu trúc này trông đáng ghê tởm về mặt đạo đức hơn nhiều so với quy trình hiện có.
    • Đa số HN hẳn đều biết Big Tech đã không tạo được quy trình khiếu nại hiệu quả. Chuyện đó chẳng phải bí mật gì. Nhưng dịch vụ này vẫn là tham nhũng trắng trợn.

  • Trước đây tôi từng thấy một cách tiếp cận “khởi nghiệp” hơn. Chuyện là một model OnlyFans tìm nhân viên trên LinkedIn và trao đổi quan hệ tình dục lấy việc gỡ khóa tài khoản, nhờ đó lấy lại tài khoản Instagram.
    https://www.newsweek.com/onlyfans-star-slept-meta-employees-...

  • Làm sao xác minh người yêu cầu thực sự là một người bình thường bị chặn vô cớ, hay là người bị chặn chính đáng vì lý do pháp lý như CSAM hoặc vi phạm điều khoản dịch vụ?
    Nếu Mike Meta bị sa thải vì cố mở khóa tài khoản của một kẻ khủng bố thật sự, nhất là khi chắc chắn họ sẽ giám sát các nhắc đến nội bộ, thì dịch vụ này có chịu trách nhiệm không?

    • Nếu là “nhân viên đã được xác minh” của công ty, họ có thể tự điều tra trước khi nộp giấy tờ phù hợp. Nhưng như vậy thường sẽ để lại dấu vết hồ sơ riêng và rất có khả năng cuối cùng quay lại chính họ.
      Nói thật, ở đây rủi ro lớn hơn lợi ích rất nhiều. Ngay từ đầu tôi không hiểu vì sao có ai lại muốn làm chuyện này.
      “Công việc ổn định lương sáu chữ số” so với “100 USD một lần từ người lạ trên Internet” thì câu trả lời quá rõ.
      Thành thật mà nói, có mùi gài bẫy.
    • Có lẽ nó sẽ giống cách vấn đề được giải quyết khi câu chuyện đáng thương của ai đó trở nên viral. Một nhân viên thấy chuyện đó và tạo ticket kiểu “người lạ này đang gặp vấn đề XYZ”, rồi nhân viên hỗ trợ điều tra và có hành động phù hợp.
      Tôi không biết quy trình thực tế của Meta.
    • Theo tôi biết, một nguyên nhân phổ biến khiến tài khoản bị đóng băng là khi tài khoản bị nhận diện là đã bị người khác chiếm đoạt. Nếu muốn tạo một kênh tắt tăng tốc để khôi phục quyền truy cập cho những tài khoản như vậy, nó phải được triển khai cực kỳ cẩn trọng.

  • Tôi đã phải kiểm tra xem hôm nay có phải Cá tháng Tư không. Đây là một trong những bài gây sốc nhất tôi thấy gần đây. Tôi thật lòng hy vọng những người kiếm lợi từ việc này ít nhất sẽ bị sa thải.

    • Bản thân ý tưởng này trông giống một dạng phản đối kiểu nghệ thuật trình diễn.
      Tạo một nền tảng để hối lộ nhằm vượt qua hệ thống “không hỗ trợ khách hàng” mờ ám của các công ty này hoặc là tham nhũng cấp thấp, hoặc là nghệ thuật cấp cao.
    • Nhân viên đăng ký dịch vụ này nên cẩn thận. Facebook chắc chắn sẽ kiện người này, và lịch sử thanh toán sẽ là một trong những tài liệu đầu tiên phải giao nộp trong quá trình discovery.
      Tôi không thấy có cách nào để ẩn danh được đảm bảo lâu dài.
    • Ngược lại, nó trông giống như đang trả lại một phần quyền của người bình thường mà các gã khổng lồ công nghệ không cảm thấy cần phải tôn trọng.

  • Tôi hoàn toàn hiểu vì sao chuyện này bị xem là phi đạo đức. Tôi cũng hiểu việc các nhân viên nhận tiền thưởng có thể bị sa thải
    Nhưng thực tế là nó vi phạm luật nào? Có vẻ về mặt pháp lý nó là hối lộ vì thúc đẩy một biện pháp không thường lệ. Tuy nhiên ý tôi là chính phần “không thường lệ” đó. Liệu công ty có thể ra tòa và truy tố việc này trong khi thừa nhận quy trình khiếu nại lệnh đình chỉ của chính mình là không thường lệ không?
    Và nó vi phạm điều khoản nào trong hợp đồng lao động tiêu chuẩn? Nhận tiền để thực hiện một dịch vụ mà chủ lao động không cung cấp? Điều thú vị là nếu chủ lao động cung cấp dịch vụ đó thì nó không còn là hối lộ nữa mà trở thành phí xử lý nhanh hợp pháp, nên để ngăn chuyện này có lẽ phải thêm một điều khoản riêng vào hợp đồng lao động
    Đây không phải câu hỏi tu từ, tôi thực sự đang tìm câu trả lời
    Theo nhiều cách, quá trình này vốn đã đang diễn ra, và những người liên quan cũng phần nào kỳ vọng như vậy. Tôi đã thấy nhiều trường hợp quyết định dường như bị đảo ngược vì một người nổi tiếng trên Twitter có thể tạo đủ ồn ào, và những trường hợp đó cũng từng lên trang nhất ở đây. Khác biệt chỉ là loại tiền tệ được dùng để lách hệ thống

    • Có một cách giải quyết đơn giản. Hãy biến số tiền đó thành khoản quyên góp cho tổ chức từ thiện do họ chọn. Đó cũng có thể là tổ chức mà công ty quyên góp hằng năm; khi đó sẽ khó hơn nhiều để sa thải một người đang kiếm tiền cho tổ chức từ thiện
    • Việc này được gọi là hối lộ thương mại. Tuy nhiên thường thì luật tiểu bang xử lý những chuyện như thế này, nên sẽ tùy theo thẩm quyền. Có người khác đã đăng điều khoản luật của California
      Trong trường hợp California, nếu số tiền dưới $250 thì luật không áp dụng, nhưng trên trang gốc có khá nhiều “tiền thưởng” vượt ngưỡng đó
      Tôi không biết có phải tiêu chuẩn hay không, nhưng nhiều nhân viên ký văn bản cam kết không nhận công việc khác. Tôi không biết việc này có được coi là “việc làm” hay không. Nhưng cũng không ngạc nhiên nếu một số hợp đồng lao động có cách diễn đạt rộng hơn như “cấm công việc bên ngoài có trả tiền”
      [0] https://news.ycombinator.com/item?id=40435890
    • Các hợp đồng lao động mà tôi từng ký ít nhất đều yêu cầu thông báo về công việc thương mại làm ngoài công ty, và đôi khi phải được chấp thuận trước khi bắt đầu. Nếu có công việc trả lương thứ hai mà không công khai, thì chừng đó là đủ để công ty sa thải nếu họ muốn
    • Từ góc nhìn của nhân viên cung cấp dịch vụ, ít nhất rất có khả năng đó là vi phạm hợp đồng

  • Nhân tiện, nhờ có người quen ở Google và Stripe mà startup của tôi đã sống sót qua một thảm họa cấp độ diệt vong. Cả hai nơi đều bị hệ thống tự động nhận diện nhầm chúng tôi và ngừng xử lý thanh toán, và chúng tôi không còn cách nào khác
    Chỉ nhờ có người bên trong mà chúng tôi mới có thể khiếu nại lên một người thực sự có thể phán đoán
    Tôi không cho rằng những nền tảng như vậy là ổn. Có những khía cạnh đáng ngờ về mặt đạo đức. Nhưng điều quan trọng là nếu bạn không đích thân quen biết vài người ở vị trí cao tại công ty mà mình định phụ thuộc vào, thì bạn không nên chấp nhận sự phụ thuộc đó

    • Ý bạn là việc bạn dùng quan hệ để tránh “thảm họa cấp độ diệt vong” thì ổn, còn người khác cố làm điều tương tự thì lại đáng ngờ về mặt đạo đức sao?
    • Thoạt nhìn thì thấy mâu thuẫn. Có vẻ như vi phạm đạo đức của đặc quyền. Có khi để tất cả mọi người trả tiền lại tốt hơn và công bằng hơn