Plsfix — Platform mühendisliği için Issue Brain

 (plsfix.co)
1 puan yazan GN⁺ 2024-05-22 | 1 yorum | WhatsApp'ta paylaş
  • plsfix, daha önce çözülmüş incident kayıtlarını toplayıp bunları doğrulanmış runbook'lara ve çalıştırılabilir skill'lere dönüştürüyor; aynı arıza tekrarlandığında ise thread içinde doğrudan bir çalıştırma düğmesi sunuyor
  • Akış, salt okunur toplama, tekrarlayan incident kümeleme, mühendis doğrulaması ve yürütme adımlarından oluşuyor; her aşama ekibin geçmiş çözüm örneklerine dayanıyor
  • Pilot örneğinde 14.802 event içinde 7 tekrarlayan küme bulundu, yeni event'lerin %22'si otomatik çözüldü ve Slack örneğinde uyarıdan 4 saniye sonra %94 güvenle bir runbook eşleştirildi
  • Runbook'lar YAML skill olarak derleniyor; güvenli adımlar otomatik çalıştırılıyor, ancak blast radius taşıyan düzeltmeler belirlenmiş onaylayıcıda duruyor
  • Fintech ve platform ekiplerine yönelik 6 haftalık pilotta 4. haftaya kadar tekrarlayan incident hacmi %30 azaltılamazsa ücret alınmıyor; salt okunur toplama kurulumu yaklaşık 30 dakika sürüyor

Tekrarlayan arızaları çalıştırılabilir bilgiye dönüştüren ürün

  • plsfix, ekibin daha önce çözdüğü incident'ları Slack, PagerDuty, GitHub, Claude gibi araçlardan alıp bunları doğrulanmış runbook'lara ve çalıştırılabilir skill'lere dönüştürüyor
  • Aynı türden arıza yeniden oluştuğunda bot aynı thread'e yanıt gönderiyor ve kullanıcı Run playbook'a tek tıklamayla çalıştırabiliyor
  • İlk ekrandaki pilot metrikleri acme pilotunun 1. hafta verileriyle gösteriliyor
    • 14.802 event toplandı
    • 7 tekrarlayan küme belirlendi
    • Yeni event'lerin %22'si otomatik çözüldü

Çözüm bilgisinin dağınık olması tekrarlayan arızaları büyütüyor

  • Birçok arıza tamamen yeni bir sorun değil; daha önce çözülmüş ama hatırlanmayan tekrarlayan arızalara daha yakın
  • Örnek senaryoda kıdemli bir mühendis gece 3'te Slack thread'inde bulunan doğru çözümü yeniden bulmak zorunda kalıyor
  • Çözüm süreci farklı araçlara dağılmış halde kalıyor
    • PagerDuty'de acknowledge var
    • Claude thread'inde teşhis var
    • Kapatılmış PR yorumlarında gerçek düzeltme var
  • plsfix, yalnızca prompt ile runbook üretmek yerine ekibin geçmişte gerçekten çözdüğü incident'lardaki her adımı izliyor

Toplamadan yürütmeye 4 aşama

  • Ingest

    • Salt okunur connector'lar, ekibin sorunları gerçekten çözdüğü yerlerden çözülmüş işleri alıyor
    • Kümeleme öncesinde PII kaldırılıyor
    • Bağlanılan hedefler Slack, PagerDuty, GitHub, Jira, Linear, ServiceNow, Notion, Claude / ChatGPT

  • Cluster

    • Tekrarlayan incident'ların signature'larını öğreniyor
    • Signature; alert payload regex'i, servis kümesi, deploy yakınlığı, kanal ve bildirici kalıpları gibi unsurlardan oluşuyor
    • Aynı tip arızalar aynı kümede sınıflandırılıyor

  • Verify

    • Geçmiş çözüm örneklerine dayanarak bir runbook taslağı oluşturuyor
    • Mühendis bunu bir kez gözden geçirip gerekirse düzenliyor, ardından Verify'ye basıyor
    • Tüm adımlara kaynak ekleniyor

  • Execute

    • Runbook'lar çalıştırılabilir skill'lere derleniyor
    • Düşük riskli adımlar otomatik yürütülüyor
    • blast radius taşıyan işlemler belirlenmiş onaylayıcıda duruyor
    • Aynı runbook Slack, CLI, PagerDuty, Linear, Jira, Web inbox üzerinden çalıştırılabiliyor

Slack thread'inde doğrudan çalışan runbook'lar

  • Uyarıdan 4 saniye sonra botun %94 güvenle mevcut bir kümedeki runbook'u aynı thread'e gönderdiği bir örnek bulunuyor
  • Örnek küme FX rate cache TTL fallback; doğrulanmış runbook v3 6 kez kullanılmış ve başarı oranı %83
  • Eşleştirme sinyalleri şöyle
    • Signature regex %94
    • Recent deploy proximity %87
    • Service overlap %100
    • Channel + reporter history %71
  • Runbook örneği, stale FX rate'lerin live trade fiyatlamasında kullanılması sorununu ele alıyor
    • Redis eviction sırasında cache miss path, 2025 load test'inden kalma 1 saatlik TTL sabitine fallback yapıyor
    • Son görülme zamanı 11 gün önce olarak gösteriliyor
    • check ve verify adımları otomatik çalıştırılıyor, fix adımı ise onay gerektiriyor

Pilotta kümelenen gerçek hatalar

  • Pilotta şu anda kümelenen 7 olaydan 3 örnek paylaşılıyor

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

    • Koşullar fx.rate.age_ms > 60000 ve order.execution.status = filled
    • Cache miss path, load test'ten kalan TTL_FALLBACK_MS = 3_600_000 sabitini döndürüyor
    • Yoğun saatlerdeki Redis eviction sırasında yaklaşık 14k sembol, 60 saniyeden eski rate'lerle fiyatlandı
    • Önceki incident'ta manuel fark edilmeden önce 18 dakika boyunca 340k dolar tutarında mispriced trade oluştu

  • Idempotency keys regenerated on retry → duplicate ACH debits

    • Koşullar ach.duplicate_debit ve idempotency_key.reused = false
    • Retry middleware, her 5xx sonrasında orijinal anahtarı yeniden kullanmak yerine yeni bir X-Idempotency-Key üretiyor
    • Bankadan 504 sonrası 200 yanıtı geldiğinde ikinci retry ikinci bir debit gönderiyor
    • Geçen ay 12 çift debit yaşandı; hepsi manuel reversal ve müşteri özrü gerektirdi

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

    • Koşullar pnl.reconcile.diff > 0.01 ve services.disagree = [risk, ledger]
    • risk-svc tutarları float64 olarak deserialize ediyor, ledger-svc ise Decimal128 kullanıyor
    • JSON round-trip sırasında sub-cent precision kayboluyor ve fark binlerce işlemde birikerek öğleden sonra reconciliation'ı tetikliyor
    • 4 hafta boyunca küçük farklar birikerek 9.2k dolarlık recon delta'ya ulaştıktan sonra fark edildi
    • Diğer pilot kümeleri olarak stripe webhook drops post-deploy, postgres pool exhaustion on report-gen, kafka rebalance storm, market-data WS subscription leak listeleniyor

Runbook bir wiki değil, yürütme spesifikasyonu

  • Doğrulanmış tüm runbook'lar YAML skill olarak derleniyor
  • Skill; trigger signature, steps, expected outputs ve riskli işlemler için atanmış onaylayıcıyı içeriyor
  • Her kayıtta runbook ile drift check yapılarak belge ile çalıştırılabilir sürümün birbirinden kopması engelleniyor
  • Runbook özellikleri şöyle
    • Adımlar sözde kod değil, gerçek shell command'lar
    • Her fix adımında atanmış onaylayıcı ve açıkça belirtilmiş bir blast radius bulunuyor
    • Her yürütme, bir sonraki eşleştirme için yeni bir training example oluyor
  • YAML örneği rb-fx-01 runbook'unu gösteriyor
    • confidence_threshold 0.85
    • confirm_cache_age, Redis'ten cache age ve eviction rate'i kontrol ediyor
    • force_cache_refresh onay gerektiriyor ve blast radius yaklaşık 14k symbol ile yaklaşık 2 saniyelik pricing pause
    • confirm_fresh_rates, max age'in 60 saniyenin altında olduğunu doğruluyor
    • Çalıştırma sonrasında #payments-platform, #platform-oncall kanallarına bildirim gidiyor ve log'lar bir S3 yoluna yazılıyor

Güven ve yönetişim

  • Varsayılan yaklaşım read-only; yürütme ise onay kapılarından geçecek şekilde tasarlanmış
  • Fintech için üretildi ve güvenlik ekibinin pilotu onaylayabileceği, denetçinin ise run'ı imzalayabileceği bir duruş sunuyor
  • Veri saklama ve dağıtım yapısı şöyle
    • raw data 90 gün saklanıyor
    • redacted data 18 ay saklanıyor
    • Pilotta Legal onayı alındı
    • single-tenant deployment kullanılabiliyor
    • training data tenant dışına çıkmıyor
  • PII redaction, embedding veya LLM call öncesinde yapılıyor
    • email, IP, customer-id ve yapılandırılabilir secrets dictionary kaldırılıyor
    • Orijinal artifact'ler kendi konumlarında kalıyor
  • Tüm connector'lar read-only olarak başlıyor
    • Yürütme scope'u runbook bazında veriliyor
    • Atanmış onaylayıcı gerekiyor
    • Tek tıkla revoke edilebiliyor
  • Tüm runbook adımlarında, öğrenme kaynağı olan çözülmüş incident'a kadar uzanan provenance korunuyor
    • Her run için imzalı audit log sağlanıyor
    • SIEM'e export edilebiliyor

Çalıştırma yüzeyleri ve pilot koşulları

  • Aynı skill, ekibin zaten kullandığı farklı yüzeylerde çalışıyor
    • Slack thread auto-suggest: Tanıdık bir signature oluştuğunda aynı thread'e eşleşen runbook'u gönderiyor
    • /pls fix CLI: Terminalde aynı runbook ve onay kapılarını kullanıyor
    • PagerDuty incident page: on-call kişi girdileri tamamlamadan incident kartında eşleşen runbook ve one-click run gösteriliyor
    • Linear / Jira issue: Bilinen bir signature ile issue açıldığında yorum olarak runbook ekleniyor ve çalıştırma öneriliyor
    • Web inbox: platform lideri event, cluster, run ve post-mortem'i tek yerde görebiliyor
  • Pilot Closed pilot olarak ve 4 design partner ile 2026 Q2 şeklinde gösteriliyor
  • 6 haftalık pilot, fintech ve platform ekiplerindeki küçük grupları hedefliyor
  • İlerleyiş sırası salt okunur ingest, 1 kümenin ortak doğrulanması ve auto-suggest'in etkinleştirilmesi
    1. haftada recurring incident volume %30 azaltılamazsa ücret alınmıyor
  • Salt okunur ingest kurulumu yaklaşık 30 dakika sürüyor, 1. haftada joint cluster review yapılıyor ve 4. haftaya kadar commitment yok

İlgili okumalar

1 yorum

 
GN⁺ 2024-05-22
Hacker News yorumları

  • Çoğu bölgede bu ticari rüşvet kapsamına girer
    California Penal Code § 641.3’e göre, bir çalışan işvereninin bilgisi ya da rızası olmadan kendi konumunu başkası için kullanması karşılığında para veya değerli bir şey alırsa ticari rüşvet suçu oluşur
    Ancak tutar ya da değer 250 dolar veya altındaysa bu madde uygulanmaz

    • Görünüşe göre yasa zaten kullanışlı bir çözüm sunuyor. Tek gereken teklif alanına <=250 kısıtı koymak
    • Başka hiçbir yol yoksa asıl mesele rüşvetin mutlaka kötü olup olmadığı. Big Tech umursasaydı müşteri desteği olurdu; olmadığı için piyasa kendi çözümünü üretiyor
    • Sanırım işlem başına 250 doların altındaysa sorun yok gibi görünüyor denmek isteniyor
    • Garip. O zaman seçim bağışları da 250 dolarla mı sınırlı?
    • Sosyal medyada herhangi bir yere “hesabım kilitlendi” diye yazarsanız, hesabı kurtarmak için kiminle iletişime geçmeniz gerektiğini söyleyen botlar üşüşür
      Benim açımdan hesap kilitleme, sosyal medya çalışanları ya da platformun üzerinde işleyen denetimsiz bir haraç düzeni gibi görünüyor. Sosyal medyanın kendisi de bir ölçüde dolandırıcılığa yakındı ve anonim dolandırıcıların insanları yanıltan faaliyetler örgütlemesi için sürekli fırsatlar yarattı
      Sosyal medya NFT’leri, Crypto’yu, influencer kültürünü ve türlü “başarana kadar başarmış gibi yap” yapısını öne sürdü; bağımsız web topluluklarına dönmek çok daha iyi. Kısa süreli acı verici olur ama ödeme yapmadığınız için işletme tanıtım gönderinizin 30 görüntülemede kalmasından çok daha iyidir

  • Delice görünüyor. Herhangi bir şirket böyle bir şey yaparsa elbette işten çıkarır. Bunun doğru adı yolsuzluk ve hukuki etkilerinden de kesinlikle endişe etmek gerekir

    • Kesinlikle devasa bir etik sorun, ama onu en ilginç kılan da bu. Etik, uyum ve yolsuzluk meseleleri yüzünden şirket içinde muazzam ilgi çekebilir ve temel sorunun gerçekten uzun vadeli şekilde iyileştirilmesini sağlayabilir
    • Başkalarının söylediği gibi, bu ileride büyüyecek büyük bir sorun
      Gerçekten askıya alınmayı hak eden biri, örneğin yasa dışı içerik paylaşan biri bu hizmeti kullanabilir. Şirket, içeriden bir çalışanın doldurduğu forma güvenip askıyı kaldırırsa o kişi yasa dışı içerik paylaşmaya devam edecek ve yeniden askıya alınacaktır
      Bu tür gerçek pozitif örnekler yeterince birikirse şirket sonunda çalışanın yetkisini kullanarak rastgele insanları içeri aldığını fark eder. Akıllı bir şirket, içeriden çalışanların kilidini açtığı hesapları işaretleyeceği için bunu ilk örnekten itibaren de anlayabilir
      En olası sonuç ilgili çalışanın işten çıkarılmasıdır. En kötü durumda şirket, tüm iç çalışanlara dışarıdakiler adına form göndermeyi yasaklayabilir
      Bu site bir şakaysa en azından bunu açıkça belirtmeli. Tanımadığınız kişiyi doğrulayın şeklindeki basit bir sorumluluk reddi yeterli değil. İçeriden bir çalışanın bunu müşteri desteğinden daha iyi doğrulayabileceği de şüpheli; gerçek iletişimi ve para transferini engellemek için e-posta gönderme ya da herkese açık paylaşım gibi özellikler kaldırılmalı
    • Katılıyorum. Kişisel para alıp şirket zamanını ve kaynaklarını kullanarak işverenin istemediği bir şeyi yapma yapısı bu. Düşük yoğunluklu rüşvet gibi geliyor
      FAQ’da çalışan anonimliği garanti ediliyor deniyor ama aynı zamanda kişinin Google çalışanı olduğunu doğrulamak için google.com e-postasına onay e-postası gönderildiği söyleniyor. Elbette Google o e-postayı görebilir
    • En azından Meta/Facebook’ta, platformda bir şeyi hızlıca halletmenin en hızlı yolunun Meta’da tanıdık birinin olması olduğu uzun zamandır herkesçe bilinen bir sırdı
    • Öyle düşünmek isterdim ama FAANG içinde açılmış birkaç iş ilanı için süreç yürütürken dışarıdan insanlar ilgili pozisyonları sormak üzere e-postalar göndermişti. Sonradan ücretli referanslar etrafında ayrı bir küçük aracılık sektörü olduğunu gördüm

  • Profesör Robert Klitgaard, yolsuzluk = tekel + takdir yetkisi - şeffaflık demişti. Aslında siyasi sistemler ve rüşvet hakkında yazılmış bir söz ama buraya da uyuyor
    https://globalanticorruptionblog.com/2014/05/27/klitgaards-m...
    Birçok teknoloji şirketi kendi pazarında tekele, sınırsız takdir yetkisine ve sıfıra yakın şeffaflığa sahip. Birinin hızlandırma ücreti startup’ını daha önce düşünmemiş olması asıl şaşırtıcı olan
    https://en.wikipedia.org/wiki/Facilitating_payment
    Yorumların çoğu bunun çalışan için kötü bir anlaşma olduğunu düşünüyor; hesabın askıdan kaldırılması için 500 dolar seviyesindeyse bu doğru olabilir. Ama yıllık 300 bin dolar kazanan biri tüm hesaplarının 2FA kodlarının e-postaya gittiği bir düzene bağlıysa ya da sosyal medya tabanlı bir iş yürütüyorsa, hesabını geri almak için 500 dolardan çok daha fazlasını ödeyebilir
    Big Tech çalışanlarının hepsi San Francisco’da değil. Avrupa gibi daha düşük maliyetli bölgelerde Amerikalıların yaklaşık yarısı kadar kazanan çok kişi var ve gelir düştükçe bu tür ayartmalara açıklık artıyor
    Rüşveti savunmuyorum ama sosyal medya şirketi çalışanına para vermenin uygulanamaz olduğuna dair tepkinin neredeyse oybirliğiyle gelmesi şaşırtıcı. Tarihsel olarak, şeffaflığın olmadığı ve çalışanların paraya çevrilebilir takdir yetkisine sahip olduğu sistemler yozlaşmıştır
    Teknoloji şirketleri bunu daha ciddiye almalı. İnsanlar karar vericilerden adil muamele görmek için para ödemeye alışırsa, bu davranışı değiştirmek çok zor olur

    • Kazanmanın tek yolu katılmamaktır. Sosyal medya insanlığın vebasıdır

  • Bir tarafta fiilen kovulmayı garantileyen bir davranış, diğer tarafta ise 150 dolar var.
    Eskiden FB’de çalışıyordum; bu şekilde erişim yetkisi satan çalışanları yakalayan bir ekip vardı. Oradaki çoğu teknik rol için fiilen bir saatlik ücrete denk gelen bir para uğruna böyle bir riski almayı hayal etmek zor.

    • Ters köşe: Bu, bu şekilde erişim yetkisi satan çalışanları yakalamaya yönelik bir honeypot pazaryeri olabilir.
    • Doğru; böyle bir işten komisyon almak vicdansızca görünüyor. Öte yandan bu tür bir sorun yaşayan biri açısından, içeriden birine para ödeyerek bile olsa çözmek istemesi anlaşılır.
      Mesele yalnızca basit bir teknik sorun, yani hesap askıya alma gibi şeyler değil; en baştan bunun haksız olduğu hissi ve bitmek bilmeyen bir cehennem döngüsüne sıkışmanın öfkesi asıl nokta.
    • FB’yi iyi bilmeyenler için söyleyeyim, maxrmk haklı. Biraz daha arka plan eklemek gerekirse, gizlilik ekiplerinden biri böyle bir ihlali tespit ederse çalışan genelde bir İK toplantısına çağrılır ve hemen ertesi gün işten çıkarılır.
      Bir arkadaşım, şahsen tanıdığı bir arkadaşının hesap sorununa yardım etmeye çalışırken istemeden böyle bir şey yaptı. Bunun bir gizlilik ihlali olduğunu bilmeden sisteme erişmişti; birkaç ay sonra proje verileri incelenirken bir denetim tetiklendi ve o kayıt bulunur bulunmaz ertesi gün işten çıkarıldı.
      Yani bu iyi bir iş fikri değil.
    • Asıl gereken, o tespit ekibinde işe girip söz konusu ekibin olayları görmezden gelmesini sağlama becerisini satmak. Adı da plsfixmyfix.com gibi bir şey olurdu.
    • Bu şirketlerden birinde çalışan biri olarak, bu riski almaya kesinlikle değmez.

  • Sadece bana mı öyle geliyor bilmiyorum ama birçok kişi büyük resmi kaçırıyor gibi. Böyle hizmetler ancak normal çözüm yolları sorunu çözemediğinde ortaya çıkar.
    Bana göre bu daha çok Big Tech’in tüketici talebine uygun etkili bir itiraz süreci kuramadığının işareti. Çok para kazandırmayabilir, ama Big Tech’in bu alanı nasıl iyileştireceğini görmek isterim.

    • Bence öyle değil. Verimsizlik işin özü. Bu hizmet bir şaka ve neredeyse kesinlikle yasa dışı. Herkes bu sistemin “bozuk” olduğunu biliyor, ama ücretsiz müşteri desteğini sonsuza kadar ölçeklendiremezsiniz.
      Bu tür hizmetlere yönelik meşru talep, o hesapların değerini kanıtlıyor. Birkaç yıl içinde teknoloji şirketlerinin buna doğrudan girip kurumsal müşterilerin aldığına benzer ücretli müşteri desteği sunacağını düşünüyorum. Zaten “doğrulanmış” hesap için para ödeyebiliyorsunuz; bir sonraki adım burası. Şirketler bunu paraya çevirmese devlet düzenler.
    • Bu ortaya çıkmadan önce içeriden gelen taleplerin çoğu muhtemelen gerçekten insanlara yardım etmeye çalışan çalışanlardan geliyordu. Elbette zaten para alıp dahili form gönderen çalışanlar da olabilir, ama bunun yaygınlaşmış olması pek olası değil.
      Bu web sitesi gibi süreci resmileştirmek, hesap askısını kaldırmaya yönelik dahili form gönderimlerinin para karşılığında yapılma ihtimalini çok artırıyor. Çünkü başvuranlarla vicdansız çalışanları eşleştiren bir pazaryeri yaratıyor, işlemin gerçekleşmesindeki sürtünmeyi azaltıyor ve açıkça parayı öne çıkararak haksız yere askıya alınan insanlara yardım etmekten çok para peşindeki çalışanları cezbediyor.
      Bu yüzden mevcut süreçten çok daha etik açıdan tiksindirici bir yapı gibi görünüyor.
    • HN’deki çoğunluk Big Tech’in etkili bir itiraz süreci kuramadığını biliyordur. Hiç de sır değil. Yine de bu hizmet düpedüz yolsuzluk.

  • Daha önce daha girişimci bir yaklaşım görmüştüm. Bir OnlyFans modelinin LinkedIn’den çalışanları bulup cinsel ilişki ve hesap askısının kaldırılması karşılığında Instagram hesabını geri aldığına dair bir haberdi.
    https://www.newsweek.com/onlyfans-star-slept-meta-employees-...

  • Talep eden kişinin gerçekten hiçbir sebep yokken engellenmiş sıradan biri mi, yoksa CSAM gibi yasal bir nedenle veya hizmet şartları ihlali yüzünden haklı olarak engellenmiş biri mi olduğunu nasıl doğruluyorsunuz?
    Mike Meta gerçek bir terörist hesabını açmaya çalışırken kovulursa, üstelik içerideki atıfları izliyor olacakları aşikârken, bunun sorumluluğunu bu hizmet mi üstleniyor?

    • Şirketin “doğrulanmış çalışanı” ise uygun evrakı koymadan önce kendisi araştırma yapabilir. Ama o zaman genelde ayrı bir kayıt izi kalır ve sonunda kendisine dönme ihtimali yüksektir.
      Açıkçası burada risk, getiriden çok daha büyük. Zaten birinin bunu neden yapmak isteyeceğini anlamıyorum.
      “İstikrarlı gelir sağlayan altı haneli maaşlı iş” ile “internetten tanımadığın birinden alınan tek seferlik 100 dolar” karşılaştırıldığında cevap belli.
      Açıkçası tuzak operasyon kokusu alıyorum.
    • Birinin iç burkan hikâyesi viral olduğunda sorunun çözülme şekline benzer olacaktır. Bir çalışan bunu görüp “bu yabancı XYZ sorunu yaşıyor” diye bir ticket açar, destek ekibi de araştırıp uygun işlemi yapar gibi.
      Meta’nın gerçek prosedürünü bilmiyorum.
    • Hesapların dondurulmasının yaygın nedenlerinden birinin, hesabın başkası tarafından ele geçirilmiş gibi algılanması olduğunu biliyorum. Böyle hesaplara erişimi geri kazandıracak hızlandırılmış bir arka kanal oluşturmak çok dikkatli uygulanmalı.

  • Bugünün 1 Nisan olup olmadığını kontrol etmek zorunda kaldım. Son zamanlarda gördüğüm en şoke edici şeylerden biri. Bundan çıkar sağlayan insanların en azından işten çıkarılmasını içtenlikle umuyorum.

    • Kavramın kendisi bir tür performans sanatı biçiminde protesto gibi görünüyor.
      Bu şirketlerin opak, müşteri desteği olmayan sistemlerinden rüşvetle geçmek için bir platform kurmak ya düşük seviyeli yolsuzluk ya da yüksek seviyeli sanat.
    • Bu hizmete kaydolan çalışanlar dikkatli olmalı. Facebook bu kişiye kesinlikle dava açacaktır ve ödeme kayıtları, delil keşfinde ilk teslim edilmesi gerekecek materyallerden biri olacaktır.
      Anonimliğin uzun süre korunmasının bir yolunu göremiyorum.
    • Aksine, dev teknoloji şirketlerinin saygı gösterme ihtiyacı duymadığı sıradan insanların haklarının bir kısmını geri veriyor gibi görünüyor.

  • Bunun etik dışı görülmesinin nedenini tamamen anlıyorum. Ödülü alan çalışanların işten çıkarılacağını da anlıyorum.
    Ama gerçekte hangi yasayı ihlal ediyor? Olağan dışı bir işlemi teşvik ettiği için hukuken rüşvet gibi görünüyor. Ancak bunun nedeni tam da o “olağan dışı” kısmı. Bir şirket mahkemeye gidip kendi askıya alma itiraz sürecinin olağan dışı olduğunu kabul ederek bunu dava konusu yapabilir mi?
    Peki standart iş sözleşmesinin hangi maddesini ihlal ediyor? İşverenin sunmadığı bir hizmeti yerine getirip para almak mı? İlginçtir, işveren o hizmeti sunuyorsa bu artık rüşvet değil, yasal bir hızlandırma ücreti olur; dolayısıyla bunu engellemek için iş sözleşmesine ayrı bir madde koymak gerekir.
    Retorik bir soru sormuyorum, gerçekten yanıt arıyorum.
    Birçok açıdan bu süreç zaten yaşanıyor ve ilgili kişiler de bunu bir ölçüde bekliyor. Twitter’da ünlü biri yeterince gürültü çıkarabildiği için kararın tersine döndüğü gibi görünen vakaları birkaç kez gördüm; bunlar burada ana sayfaya da çıktı. Fark yalnızca sistemi aşmak için kullanılan para biriminin türünde.

    • Basit bir çözüm var. Tutarı, kendilerinin seçeceği bir hayır kurumuna bağış hâline getirmek yeterli. Bu, şirketin her yıl bağış yaptığı bir kurum da olabilir; böyle olunca bir hayır kurumu için para kazandıran kişiyi işten çıkarmak çok daha zorlaşır.
    • Buna ticari rüşvet denir. Ancak bu tür işleri genelde eyalet yasaları ele aldığı için yargı alanına göre değişir. Başka biri Kaliforniya yasa metnini paylaşmıştı.
      Kaliforniya’da tutar $250’nin altındaysa yasa uygulanmıyor, ancak özgün gönderideki sitede bu eşiği aşan epey “ödül” var.
      Standart mı bilmiyorum ama birçok çalışan başka bir işte çalışmayacağını belirten bir belge imzalıyor. Böyle bir şeyin “istihdam” sayılıp sayılmayacağını bilmiyorum. Ama bazı iş sözleşmelerinde “dışarıda ücretli iş yapma yasağı” gibi daha geniş ifadeler bulunsa şaşırmam.
      [0] https://news.ycombinator.com/item?id=40435890
    • Benim yaptığım iş sözleşmeleri en azından şirket dışında yapılan ticari işleri bildirmeyi, bazen de başlamadan önce onay almayı gerektiriyordu. Açıklanmamış ikinci bir ücretli iş varsa, şirket isterse bu işten çıkarma nedeni olmaya yeter.
    • Hizmeti sağlayan çalışan açısından en azından sözleşme ihlali olma olasılığı yüksek.

  • Bu arada, Google ve Stripe’ta tanıdıklarım olması sayesinde startup’ım yok oluş düzeyinde bir felaketten kurtulabildi. Her iki yerde de otomasyon sistemleri bizi yanlış pozitif olarak işaretleyip ödeme işlemeyi durdurdu; başka hiçbir yol yoktu.
    Ancak içeride birileri olduğu için gerçekten karar verebilecek bir kişiye itirazımı ulaştırabildim.
    Böyle platformların iyi olduğunu düşünmüyorum. Etik açıdan şüpheli yanları var. Ama bağımlı olmak istediğiniz şirkette birkaç üst düzey tanıdığı kişisel olarak tanımıyorsanız, o bağımlılığı üstlenmemeniz gerektiği önemli bir nokta.

    • Yani kendiniz bağlantılarınızı kullanarak “yok oluş düzeyinde bir felaketi” atlatınca sorun yok, ama başkaları aynı şeyi yapmaya çalışınca etik açıdan şüpheli mi oluyor?
    • İlk bakışta çelişki gibi geliyor. Ayrıcalık etiğini ihlal ediyor gibi. Belki de herkesin para ödemesi daha iyi ve daha adil olabilir.