Plsfix — Issue Brain untuk Rekayasa Platform

 (plsfix.co)
1 poin oleh GN⁺ 2024-05-22 | 1 komentar | Bagikan ke WhatsApp
  • plsfix mengumpulkan catatan insiden yang sudah pernah diselesaikan, mengubahnya menjadi runbook terverifikasi dan skill yang dapat dieksekusi, lalu menyediakan tombol eksekusi langsung di dalam thread ketika gangguan yang sama berulang
  • Alurnya berlanjut dari pengumpulan read-only, clustering insiden berulang, verifikasi engineer, hingga eksekusi; setiap tahap didasarkan pada kasus penyelesaian terdahulu milik tim
  • Dalam contoh pilot, dari 14.802 event ditemukan 7 cluster berulang, 22% event baru terselesaikan otomatis, dan contoh Slack mencocokkan runbook dengan tingkat keyakinan 94% dalam 4 detik setelah notifikasi
  • Runbook dikompilasi menjadi YAML skill; langkah yang aman dijalankan otomatis, tetapi perbaikan yang memiliki blast radius berhenti di pemberi persetujuan yang ditentukan
  • Pilot 6 minggu untuk tim fintech dan platform tidak mengenakan biaya jika hingga minggu ke-4 gagal mengurangi volume insiden berulang sebesar 30%; penyiapan pengumpulan read-only memakan waktu sekitar 30 menit

Produk yang mengubah gangguan berulang menjadi pengetahuan yang dapat dieksekusi

  • plsfix mengambil insiden yang sudah pernah diselesaikan tim dari Slack, PagerDuty, GitHub, Claude, dan lainnya, lalu mengubahnya menjadi runbook terverifikasi dan skill yang dapat dieksekusi
  • Ketika gangguan dengan bentuk yang sama terjadi lagi, bot memposting jawaban di thread yang sama, dan pengguna dapat menjalankannya dengan sekali klik pada Run playbook
  • Metrik pilot di layar awal ditampilkan sebagai data minggu pertama pilot acme
    • 14.802 event dikumpulkan
    • 7 cluster berulang diidentifikasi
    • 22% event baru terselesaikan otomatis

Masalah pengetahuan penyelesaian yang tersebar sehingga gangguan berulang membesar

  • Banyak gangguan bukan masalah yang benar-benar baru, melainkan lebih mirip gangguan berulang yang pernah diselesaikan sebelumnya tetapi tidak diingat
  • Contohnya adalah situasi ketika engineer senior harus kembali mencari solusi tepat yang dulu ada di thread Slack pada pukul 3 dini hari
  • Proses penyelesaian tersisa secara terpisah di berbagai tool
    • Di PagerDuty ada acknowledge
    • Di thread Claude ada diagnosis
    • Di komentar PR yang sudah ditutup ada perbaikan sebenarnya
  • Alih-alih membuat runbook hanya dari prompt, plsfix melacak setiap langkah dari insiden yang benar-benar pernah diselesaikan tim di masa lalu

4 tahap dari pengumpulan hingga eksekusi

  • Ingest

    • Konektor read-only mengambil pekerjaan yang sudah terselesaikan dari tempat tim benar-benar menyelesaikan masalah
    • PII dihapus sebelum clustering
    • Target koneksi mencakup Slack, PagerDuty, GitHub, Jira, Linear, ServiceNow, Notion, Claude / ChatGPT

  • Cluster

    • Mempelajari signature insiden berulang
    • Signature terdiri dari regex pada payload notifikasi, kumpulan layanan, kedekatan dengan deployment, pola channel dan pelapor, dan sebagainya
    • Gangguan dengan bentuk yang sama diklasifikasikan ke cluster yang sama

  • Verify

    • Membuat draf runbook berdasarkan kasus penyelesaian terdahulu
    • Engineer meninjaunya sekali, mengubahnya bila perlu, lalu menekan Verify
    • Setiap langkah diberi sumber

  • Execute

    • Runbook dikompilasi menjadi skill yang dapat dieksekusi
    • Langkah berisiko rendah dijalankan otomatis
    • Tugas yang memiliki blast radius berhenti di pemberi persetujuan yang ditentukan
    • Runbook yang sama dapat dijalankan dari Slack, CLI, PagerDuty, Linear, Jira, dan Web inbox

Runbook yang langsung dieksekusi di thread Slack

  • Ada contoh ketika, 4 detik setelah notifikasi, bot memposting runbook yang cocok dengan cluster yang ada ke thread yang sama dengan keyakinan 94%
  • Contoh clusternya adalah FX rate cache TTL fallback, dan runbook terverifikasi v3 sudah digunakan 6 kali dengan tingkat keberhasilan 83%
  • Sinyal pencocokannya adalah sebagai berikut
    • Signature regex 94%
    • Recent deploy proximity 87%
    • Service overlap 100%
    • Channel + reporter history 71%
  • Contoh runbook menangani masalah stale FX rates yang digunakan untuk harga live trades
    • Saat Redis eviction, cache miss path fallback ke konstanta TTL 1 jam yang tersisa dari load test tahun 2025
    • Kejadian terakhir ditampilkan 11 hari sebelumnya
    • Langkah check dan verify dijalankan otomatis, sedangkan langkah fix memerlukan persetujuan

Cacat nyata yang di-cluster dalam pilot

  • Dari 7 cluster yang saat ini di-cluster dalam pilot, 3 contoh dipublikasikan

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

    • Kondisinya adalah fx.rate.age_ms > 60000 dan order.execution.status = filled
    • Cache miss path mengembalikan konstanta TTL_FALLBACK_MS = 3_600_000 yang tersisa dari load test
    • Saat Redis eviction pada jam sibuk, sekitar 14k symbol diberi harga dengan rate yang lebih lama dari 60 detik
    • Pada insiden sebelumnya, sebelum ditemukan secara manual, terjadi mispriced trades senilai $340k selama 18 menit

  • Idempotency keys regenerated on retry → duplicate ACH debits

    • Kondisinya adalah ach.duplicate_debit dan idempotency_key.reused = false
    • Retry middleware menerbitkan X-Idempotency-Key baru pada setiap 5xx, alih-alih menggunakan kembali key asli
    • Jika bank mengirim respons 200 setelah 504, retry kedua mem-posting debit kedua
    • Bulan lalu ada 12 debit duplikat, dan semuanya memerlukan reversal manual serta permintaan maaf kepada pelanggan

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

    • Kondisinya adalah pnl.reconcile.diff > 0.01 dan services.disagree = [risk, ledger]
    • risk-svc melakukan deserialisasi jumlah sebagai float64, sedangkan ledger-svc menggunakan Decimal128
    • Pada JSON round-trip, presisi sub-cent hilang, dan selisihnya terakumulasi pada ribuan transaksi sehingga memicu reconciliation pada sore hari
    • Ditemukan setelah selisih kecil terakumulasi selama 4 minggu menjadi recon delta sebesar $9,2k
    • Cluster pilot lainnya yang disebutkan adalah stripe webhook drops post-deploy, postgres pool exhaustion on report-gen, kafka rebalance storm, dan market-data WS subscription leak

Runbook bukan wiki, melainkan spesifikasi eksekusi

  • Semua runbook terverifikasi dikompilasi menjadi YAML skill
  • Skill mencakup trigger signature, steps, expected outputs, dan pemberi persetujuan yang ditentukan untuk pekerjaan berisiko
  • Setiap kali disimpan, runbook dan drift check dijalankan agar dokumen dan artefak eksekusi tidak menyimpang
  • Atribut runbook adalah sebagai berikut
    • Langkah bukan pseudocode, melainkan shell command nyata
    • Setiap langkah fix memiliki pemberi persetujuan yang ditentukan dan blast radius yang dinyatakan secara eksplisit
    • Setiap eksekusi menjadi training example baru untuk pencocokan berikutnya
  • Contoh YAML menunjukkan runbook rb-fx-01
    • confidence_threshold adalah 0,85
    • confirm_cache_age memeriksa cache age dan eviction rate di Redis
    • force_cache_refresh memerlukan persetujuan, dan blast radius-nya sekitar 14k symbols serta jeda pricing sekitar 2 detik
    • confirm_fresh_rates memeriksa apakah max age kurang dari 60 detik
    • Setelah eksekusi, memberi tahu #payments-platform, #platform-oncall, dan meninggalkan log di path S3

Kepercayaan dan tata kelola

  • Sikap dasarnya adalah read-only, dan eksekusi dirancang agar melewati approval gate
  • Dibuat untuk fintech, dengan posture yang memungkinkan tim keamanan menyetujui pilot dan auditor menandatangani run
  • Retensi dan deployment data adalah sebagai berikut
    • Data raw disimpan selama 90 hari
    • Data yang telah diredaksi disimpan selama 18 bulan
    • Dalam pilot, persetujuan Legal diperoleh
    • Single-tenant deployment dapat digunakan
    • Training data tidak keluar dari tenant
  • PII redaction dilakukan sebelum embedding atau LLM call
    • Email, IP, customer-id, dan configurable secrets dictionary dihapus
    • Artifact asli tetap berada di lokasi semula
  • Semua connector dimulai sebagai read-only
    • Scope eksekusi diberikan per runbook
    • Pemberi persetujuan yang ditentukan diperlukan
    • Dapat di-revoke dengan sekali klik
  • Setiap langkah runbook memiliki provenance hingga insiden penyelesaian yang menjadi sumber pembelajaran
    • Audit log per run disediakan dalam status signed
    • Dapat diekspor ke SIEM

Permukaan eksekusi dan ketentuan pilot

  • Skill yang sama bekerja di berbagai permukaan yang sudah digunakan tim
    • Slack thread auto-suggest: ketika signature yang familier terjadi, memposting runbook yang cocok ke thread yang sama
    • /pls fix CLI: menggunakan runbook dan approval gate yang sama dari terminal
    • PagerDuty incident page: sebelum on-call selesai mengetik, menampilkan runbook yang cocok dan one-click run di incident card
    • Linear / Jira issue: ketika issue dibuka dengan signature yang diketahui, menempelkan runbook sebagai comment dan menyarankan eksekusi
    • Web inbox: platform lead dapat melihat event, cluster, run, dan post-mortem di satu tempat
  • Pilot ini adalah Closed pilot dan ditampilkan untuk Q2 2026 bersama 4 design partner
  • Pilot 6 minggu ditujukan untuk grup kecil dari tim fintech dan platform
  • Cara berjalannya adalah ingest read-only, verifikasi bersama 1 cluster, lalu aktivasi auto-suggest
  • Jika pada minggu ke-4 tidak dapat mengurangi recurring incident volume sebesar 30%, biaya tidak dikenakan
  • Penyiapan ingest read-only memakan waktu sekitar 30 menit, joint cluster review dilakukan pada minggu pertama, dan tidak ada commitment hingga minggu ke-4

Bacaan terkait

1 komentar

 
GN⁺ 2024-05-22
Opini Hacker News

  • Di sebagian besar wilayah, ini termasuk suap komersial
    Menurut California Penal Code § 641.3, jika seorang karyawan menerima uang atau sesuatu yang bernilai sebagai imbalan karena menggunakan posisinya untuk kepentingan orang lain tanpa sepengetahuan atau persetujuan pemberi kerja, itu menjadi tindak pidana suap komersial
    Namun, jika jumlah atau nilainya $250 atau kurang, ketentuan ini tidak berlaku

    • Sepertinya hukum sudah menyediakan solusi yang praktis. Artinya cukup beri batasan <=250 pada field penawaran
    • Jika sama sekali tidak ada cara lain, inti persoalannya adalah apakah suap selalu buruk. Kalau Big Tech peduli, pasti ada dukungan pelanggan, tapi karena tidak, pasar sedang menciptakan solusinya sendiri
    • Sepertinya maksudnya aman-aman saja kalau di bawah $250 per kasus
    • Aneh. Kalau begitu, apakah sumbangan kampanye juga dibatasi $250?
    • Kalau Anda memposting “akun saya terkunci” di mana pun di media sosial, bot-bot akan berdatangan memberi tahu siapa yang harus dihubungi untuk pemulihan
      Dari sudut pandang saya, penguncian akun terlihat seperti struktur pemerasan yang tidak terkendali yang berjalan di atas platform atau oleh karyawan media sosial. Media sosial itu sendiri juga sampai batas tertentu mendekati penipuan, dan terus menciptakan peluang bagi penipu anonim untuk mengorganisasi aktivitas yang menyesatkan orang
      Media sosial telah mendorong NFT, Crypto, budaya influencer, dan berbagai skema “pura-pura berhasil sampai benar-benar berhasil”; lebih baik kembali ke komunitas web independen. Mungkin menyakitkan untuk sementara, tetapi jauh lebih baik daripada posting promosi bisnis hanya mendapat 30 tayangan karena Anda tidak membayar

  • Ini terlihat gila. Perusahaan mana pun tentu akan memecat orang yang melakukan hal seperti ini. Nama yang tepat adalah korupsi, dan dampak hukumnya juga jelas harus dikhawatirkan

    • Memang ini jelas masalah etika besar, tetapi justru itu bagian yang paling menarik. Karena isu etika, kepatuhan, dan korupsi, ini bisa menarik perhatian besar di dalam perusahaan dan berpotensi membuat masalah mendasarnya benar-benar diperbaiki dengan cara yang bertahan lama
    • Seperti yang dikatakan orang lain, ini akan menjadi masalah besar ke depan
      Orang yang memang pantas ditangguhkan, misalnya seseorang yang mengunggah konten ilegal, bisa menggunakan layanan ini. Jika perusahaan mempercayai formulir yang diajukan karyawan internal dan mencabut penangguhan, orang itu akan terus mengunggah konten ilegal dan akan ditangguhkan lagi
      Jika cukup banyak kasus true positive seperti ini menumpuk, perusahaan pada akhirnya akan menemukan bahwa karyawan menggunakan wewenangnya untuk memasukkan siapa saja. Perusahaan yang cerdas bahkan mungkin mengetahuinya sejak kasus pertama, karena mereka menandai akun yang dibuka kembali oleh karyawan internal
      Akhir yang paling mungkin adalah karyawan tersebut dipecat. Dalam skenario terburuk, perusahaan bisa melarang semua karyawan internal mengajukan formulir untuk pihak luar
      Jika situs ini lelucon, setidaknya hal itu harus ditandai dengan jelas. Dislaimer yang hanya meminta orang memverifikasi orang asing tidak cukup. Patut diragukan juga apakah karyawan internal bisa memverifikasi lebih baik daripada dukungan pelanggan, dan fitur seperti pengiriman email atau publikasi harus dihapus agar kontak nyata dan transfer uang tidak terjadi
    • Setuju. Ini adalah skema menerima uang pribadi lalu memakai waktu dan sumber daya perusahaan untuk melakukan sesuatu yang tidak diinginkan pemberi kerja. Terdengar seperti suap tingkat rendah
      FAQ mengatakan anonimitas karyawan dijamin, tetapi sekaligus menyatakan bahwa email konfirmasi dikirim ke alamat google.com untuk memverifikasi apakah mereka karyawan Google. Tentu saja Google bisa melihat email itu
    • Setidaknya di Meta/Facebook, sudah sejak lama menjadi rahasia umum bahwa cara tercepat untuk mempercepat sesuatu di platform adalah punya kenalan di Meta
    • Saya ingin berpikir begitu, tetapi ketika menangani beberapa lowongan yang hanya diposting internal di FAANG, orang luar mengirim email menanyakan posisi tersebut. Belakangan saya tahu ada industri perantara kecil-kecilan tersendiri di sekitar rekomendasi berbayar

  • Profesor Robert Klitgaard mengatakan korupsi = monopoli + diskresi - transparansi. Awalnya itu ditulis tentang sistem politik dan suap, tetapi juga berlaku di sini
    https://globalanticorruptionblog.com/2014/05/27/klitgaards-m...
    Banyak perusahaan teknologi memiliki monopoli di pasarnya sendiri, diskresi tak terbatas, dan transparansi yang mendekati nol. Justru mengejutkan bahwa belum ada orang yang memikirkan startup biaya jalur cepat lebih awal
    https://en.wikipedia.org/wiki/Facilitating_payment
    Sebagian besar komentar menganggap ini transaksi buruk bagi karyawan, dan untuk level membuka penangguhan akun seharga $500 mungkin memang begitu. Namun, seseorang bergaji $300k yang terikat pada sistem di mana kode 2FA untuk semua akun masuk ke email, atau seseorang yang menjalankan bisnis berbasis media sosial, bisa saja membayar jauh lebih dari $500 untuk mendapatkan kembali akunnya
    Tidak semua karyawan Big Tech berada di San Francisco. Di wilayah berbiaya lebih rendah seperti Eropa, banyak orang berpenghasilan sekitar setengah dari orang Amerika, dan semakin rendah pendapatan, semakin rentan mereka terhadap godaan seperti ini
    Saya tidak membela suap, tetapi mengejutkan bahwa reaksinya hampir bulat seolah membayar karyawan perusahaan media sosial itu tidak mungkin dilakukan. Secara historis, sistem yang tidak transparan dan memberi karyawan diskresi yang bisa dikonversi menjadi uang cenderung menjadi korup
    Perusahaan teknologi harus memandang ini lebih serius. Jika orang sudah terbiasa membayar agar diperlakukan adil oleh pengambil keputusan, perilaku itu akan sangat sulit diubah

    • Satu-satunya cara untuk menang adalah tidak ikut bermain. Media sosial adalah wabah bagi umat manusia

  • Di satu sisi ada tindakan yang pada praktiknya pasti berujung pemecatan, dan di sisi lain ada $150.
    Dulu saya pernah bekerja di FB, dan ada tim yang menangkap karyawan yang menjual akses dengan cara seperti ini. Sulit dibayangkan orang di sebagian besar posisi teknis di sana mau mengambil risiko seperti itu demi uang yang pada dasarnya setara upah sekitar satu jam bagi mereka.

    • Plot twist: ini bisa saja pasar honeypot untuk menangkap karyawan yang menjual akses dengan cara seperti ini.
    • Benar, menerima rabat untuk hal semacam ini terlihat tidak bermoral. Di sisi lain, kalau berada di posisi yang mengalami masalah seperti ini, rasanya orang bisa saja ingin membayar orang dalam agar masalahnya selesai.
      Intinya bukan sekadar masalah teknis sederhana seperti akun ditangguhkan, melainkan rasa bahwa sejak awal itu tidak adil dan kemarahan karena terjebak dalam loop neraka yang tak berujung.
    • Untuk yang tidak terlalu mengenal FB, maxrmk benar. Sebagai tambahan konteks, jika salah satu tim privasi menemukan pelanggaran seperti ini, karyawan biasanya dipanggil ke rapat HR dan langsung dipecat keesokan harinya.
      Teman saya pernah tanpa sengaja melakukan hal seperti ini ketika mencoba membantu masalah akun seorang teman yang ia kenal secara pribadi. Ia tidak tahu bahwa mengakses sistem itu merupakan pelanggaran privasi, tetapi beberapa bulan kemudian audit terpicu saat data proyek sedang diperiksa, dan sehari setelah catatan itu ditemukan, ia langsung diproses keluar.
      Jadi ini bukan ide bisnis yang bagus.
    • Yang benar-benar dibutuhkan adalah bekerja di tim deteksi itu, lalu menjual kemampuan agar tim tersebut pura-pura tidak melihat kasusnya. Namanya mungkin plsfixmyfix.com.
    • Sebagai orang yang bekerja di salah satu perusahaan seperti ini, risikonya sama sekali tidak sepadan.

  • Entah hanya saya yang merasa begitu, tetapi sepertinya banyak orang melewatkan gambaran besarnya. Layanan seperti ini hanya muncul ketika solusi normal gagal menyelesaikan masalah.
    Bagi saya, ini lebih merupakan tanda bahwa Big Tech gagal membuat proses banding yang efektif sesuai kebutuhan konsumen. Mungkin tidak terlalu menghasilkan uang, tetapi menarik untuk melihat bagaimana Big Tech akan memperbaiki bagian ini.

    • Sepertinya bukan begitu. Inefisiensi adalah intinya. Layanan ini adalah lelucon dan hampir pasti ilegal. Semua orang tahu sistem ini “rusak”, tetapi dukungan pelanggan gratis tidak bisa diskalakan selamanya.
      Permintaan yang sah terhadap layanan seperti ini membuktikan nilai akun-akun tersebut. Saya kira dalam beberapa tahun perusahaan teknologi akan terjun langsung ke sini dan menawarkan dukungan pelanggan berbayar seperti yang diterima pelanggan enterprise. Sekarang orang sudah bisa membayar untuk akun “terverifikasi”, jadi langkah berikutnya adalah ini. Jika perusahaan tidak memonetisasinya, pemerintah akan mengaturnya.
    • Sebelum ini muncul, kemungkinan besar sebagian besar permintaan internal benar-benar berasal dari karyawan yang ingin membantu orang. Tentu saja mungkin sudah ada karyawan yang dibayar untuk mengirim formulir internal, tetapi kecil kemungkinan praktik itu meluas.
      Jika prosesnya diformalkan seperti situs web ini, kemungkinan pengajuan formulir internal untuk membuka penangguhan akun dengan imbalan uang menjadi jauh lebih besar. Sebab, ini menciptakan pasar yang mempertemukan pemohon dengan karyawan yang tidak bermoral, mengurangi friksi eksekusi transaksi, dan secara terang-terangan menonjolkan uang sehingga menarik karyawan yang mengejar uang, alih-alih membantu orang yang akunnya ditangguhkan secara tidak adil.
      Karena itu, dibanding prosedur yang ada, struktur ini terlihat jauh lebih menjijikkan secara etis.
    • Mayoritas HN mungkin sudah tahu bahwa Big Tech gagal membuat proses banding yang efektif. Itu sama sekali bukan rahasia. Meski begitu, layanan ini tetap merupakan korupsi terang-terangan.

  • Saya pernah melihat pendekatan yang lebih entrepreneurial. Ceritanya seorang model OnlyFans menemukan karyawan di LinkedIn dan menukar hubungan seksual dengan pembatalan penangguhan akun, lalu mendapatkan kembali akun Instagram-nya.
    https://www.newsweek.com/onlyfans-star-slept-meta-employees-...

  • Bagaimana cara memverifikasi apakah pemohon benar-benar orang biasa yang diblokir tanpa alasan apa pun, atau orang yang memang pantas diblokir karena alasan hukum seperti CSAM atau pelanggaran ketentuan layanan?
    Jika Mike Meta dipecat karena mencoba memulihkan akun teroris sungguhan, apalagi jelas mereka pasti memantau penyebutan internal, apakah layanan ini akan menanggung tanggung jawabnya?

    • Kalau ia “karyawan terverifikasi” di perusahaan itu, mungkin ia bisa menyelidiki sendiri sebelum memasukkan dokumen yang tepat. Namun biasanya itu akan meninggalkan jejak catatan tersendiri dan pada akhirnya sangat mungkin kembali menjerat dirinya.
      Jujur saja, di sini risikonya jauh lebih besar daripada keuntungannya. Saya bahkan tidak tahu kenapa ada orang yang mau melakukan ini sejak awal.
      Kalau pilihannya “pekerjaan bergaji enam digit dengan penghasilan stabil” versus “$100 sekali bayar dari orang asing di internet”, jawabannya jelas.
      Jujur saja, ini berbau operasi jebakan.
    • Mungkin mirip dengan cara masalah terselesaikan ketika kisah sedih seseorang menjadi viral. Seorang karyawan melihatnya lalu membuat tiket yang mengatakan “orang asing ini mengalami masalah XYZ”, kemudian petugas dukungan menyelidiki dan mengambil tindakan yang sesuai.
      Saya tidak tahu prosedur Meta yang sebenarnya.
    • Setahu saya, salah satu penyebab umum akun dibekukan adalah ketika akun dianggap telah diambil alih oleh orang lain. Membuat kanal pintas yang dipercepat untuk memulihkan akses akun seperti itu harus diimplementasikan dengan sangat hati-hati.

  • Saya sampai harus mengecek apakah hari ini April Mop. Ini salah satu hal paling mengejutkan yang saya lihat belakangan ini. Saya sungguh berharap orang-orang yang mengambil untung dari ini setidaknya dipecat.

    • Konsepnya sendiri terlihat seperti semacam protes berbentuk seni performans.
      Membuat platform untuk menembus sistem non-dukungan pelanggan yang buram milik perusahaan-perusahaan ini lewat suap adalah korupsi tingkat rendah atau seni tingkat tinggi.
    • Karyawan yang mendaftar ke layanan ini harus berhati-hati. Facebook pasti akan menggugat orang ini, dan catatan pembayaran akan menjadi salah satu materi pertama yang harus diserahkan dalam proses discovery.
      Saya tidak melihat bagaimana anonimitas bisa terjamin lama.
    • Justru ini terlihat seperti mengembalikan sebagian hak orang biasa yang menurut perusahaan teknologi raksasa tidak perlu mereka hormati.

  • Saya sepenuhnya paham mengapa ini dianggap tidak etis. Saya juga paham bahwa karyawan yang menerima imbalan akan dipecat
    Tapi sebenarnya hukum apa yang dilanggar? Rasanya secara hukum ini bisa disebut suap karena mendorong tindakan yang tidak rutin. Namun maksud saya, justru karena bagian “tidak rutin” itu. Bisakah perusahaan membawa ini ke pengadilan dan menuntutnya sambil mengakui bahwa prosedur banding atas penangguhan mereka adalah sesuatu yang tidak rutin?
    Dan klausul apa dalam kontrak kerja standar yang dilanggar? Melakukan layanan yang tidak disediakan oleh pemberi kerja lalu menerima uang? Menariknya, jika pemberi kerja menyediakan layanan itu, maka ini bukan lagi suap melainkan biaya percepatan yang sah, jadi untuk mencegahnya harus ada klausul terpisah dalam kontrak kerja
    Ini bukan pertanyaan retoris; saya benar-benar mencari jawabannya
    Dalam banyak hal, proses ini sudah terjadi, dan pihak-pihak terkait pun sampai batas tertentu mengharapkannya. Saya sudah beberapa kali melihat kasus ketika keputusan tampaknya dibatalkan karena seorang figur terkenal di Twitter bisa membuat kegaduhan yang cukup besar, dan kasus seperti itu juga pernah masuk halaman depan di sini. Bedanya hanya jenis mata uang yang dipakai untuk memintas sistem

    • Ada solusi sederhana. Jadikan jumlahnya sebagai donasi ke badan amal pilihan mereka. Bisa juga badan amal yang didonasikan perusahaan setiap tahun; dengan begitu akan jauh lebih sulit memecat orang yang menghasilkan uang untuk badan amal
    • Ini disebut suap komersial. Namun biasanya hukum negara bagian yang menangani hal seperti ini, jadi akan bergantung pada yurisdiksi. Ada orang lain yang memposting pasal hukum California
      Untuk California, jika jumlahnya di bawah $250, hukumnya tidak berlaku, tetapi di situs postingan asli ada cukup banyak “imbalan” yang melewati ambang itu
      Saya tidak tahu apakah ini standar, tetapi banyak karyawan menandatangani dokumen yang menyatakan tidak akan menerima pekerjaan lain. Saya tidak tahu apakah hal seperti ini termasuk “pekerjaan”. Namun saya tidak akan heran jika sebagian kontrak kerja memuat redaksi yang lebih luas seperti “dilarang melakukan pekerjaan berbayar dari luar”
      [0] https://news.ycombinator.com/item?id=40435890
    • Kontrak kerja yang pernah saya tanda tangani setidaknya mewajibkan saya memberi tahu perusahaan tentang pekerjaan komersial di luar perusahaan, dan terkadang harus mendapat persetujuan sebelum memulainya. Jika ada pekerjaan berbayar kedua yang tidak diungkapkan, itu sudah cukup untuk menjadi alasan pemecatan bila perusahaan menginginkannya
    • Dari sudut pandang karyawan yang menyediakan layanan, setidaknya kemungkinan besar itu pelanggaran kontrak

  • Sebagai catatan, berkat adanya kenalan saya di Google dan Stripe, startup saya bisa selamat dari bencana yang nyaris mematikan. Di kedua tempat itu, sistem otomatis salah menandai kami dan menghentikan pemrosesan pembayaran, dan tidak ada cara lain
    Hanya karena ada orang dalam, kami benar-benar bisa mengajukan keberatan kepada orang yang mampu mengambil keputusan
    Saya tidak menganggap platform seperti ini baik-baik saja. Ada sisi yang secara etis mencurigakan. Namun poin pentingnya adalah: jika Anda tidak mengenal secara pribadi beberapa kenalan di posisi senior di perusahaan yang ingin Anda andalkan, sebaiknya Anda tidak mengambil ketergantungan itu

    • Jadi menurut Anda menggunakan koneksi untuk menghindari “bencana yang nyaris mematikan” itu boleh, tetapi ketika orang lain mencoba melakukan hal yang sama, itu secara etis mencurigakan?
    • Sekilas terasa kontradiktif. Sepertinya melanggar etika privilese. Bisa jadi lebih baik dan lebih adil jika semua orang membayar saja