Plsfix — प्लेटफ़ॉर्म इंजीनियरिंग के लिए Issue Brain

 (plsfix.co)
1 पॉइंट द्वारा GN⁺ 2024-05-22 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • plsfix पहले से हल किए गए incidents के रिकॉर्ड इकट्ठा करके उन्हें verified runbooks और executable skills में बदलता है, और वही outage फिर से होने पर thread के अंदर तुरंत execute button देता है
  • flow read-only collection, recurring incident clustering, engineer verification, और execution चरणों से गुजरता है, और हर चरण टीम के पुराने resolution cases पर आधारित होता है
  • pilot example में 14,802 events में 7 recurring clusters मिले, नए events में से 22% अपने-आप हल हुए, और Slack example में alert के 4 सेकंड बाद 94% confidence के साथ runbook match किया गया
  • runbooks को YAML skills में compile किया जाता है, safe steps अपने-आप execute होते हैं, लेकिन blast radius वाले fixes तय approver पर रुक जाते हैं
  • fintech और platform teams के लिए 6 हफ्ते के pilot में अगर 4वें हफ्ते तक recurring incident volume 30% कम नहीं होता तो कोई charge नहीं लिया जाता, और read-only collection setup में लगभग 30 मिनट लगते हैं

दोहराई जाने वाली outages को executable knowledge में बदलने वाला product

  • plsfix उन incidents को Slack, PagerDuty, GitHub, Claude आदि से लाता है जिन्हें टीम पहले ही हल कर चुकी है, और उन्हें verified runbooks और executable skills में बदलता है
  • जब उसी तरह की outage फिर होती है, bot उसी thread में जवाब पोस्ट करता है, और user एक बार Run playbook क्लिक करके उसे चला सकता है
  • शुरुआती screen पर दिखने वाले pilot metrics acme pilot के पहले हफ्ते के data से हैं
    • 14,802 events collect किए गए
    • 7 recurring clusters पहचाने गए
    • नए events में से 22% auto-resolve हुए

बिखरी हुई resolution knowledge की वजह से recurring outages का बढ़ना

  • बहुत-सी outages पूरी तरह नई समस्या नहीं होतीं, बल्कि पहले हल की जा चुकी लेकिन याद न रहने वाली recurring outages के करीब होती हैं
  • उदाहरण में senior engineer को रात 3 बजे Slack thread में मौजूद वही सटीक समाधान फिर से ढूँढ़ना पड़ता है
  • resolution process कई tools में बँटा रह जाता है
    • PagerDuty में acknowledge होता है
    • Claude thread में diagnosis होता है
    • बंद PR comments में असली fix होता है
  • plsfix सिर्फ prompt के आधार पर runbook बनाने के बजाय, उन incidents के हर step को trace करता है जिन्हें टीम ने अतीत में वास्तव में हल किया था

collection से execution तक के 4 चरण

  • Ingest

    • read-only connectors उन जगहों से resolved work लाते हैं जहाँ टीम वास्तव में समस्याएँ हल करती है
    • clustering से पहले PII हटा दिया जाता है
    • connection targets हैं Slack, PagerDuty, GitHub, Jira, Linear, ServiceNow, Notion, Claude / ChatGPT

  • Cluster

    • recurring incidents के signature सीखे जाते हैं
    • signature में alert payload का regex, service sets, deploy proximity, channel और reporter patterns जैसी चीज़ें शामिल होती हैं
    • एक ही तरह की outages को एक ही cluster में classify किया जाता है

  • Verify

    • पुराने resolution cases के आधार पर runbook draft बनाया जाता है
    • engineer उसे एक बार review करता है, ज़रूरत हो तो edit करता है, फिर Verify दबाता है
    • हर step के साथ source जुड़ा होता है

  • Execute

    • runbooks को executable skills में compile किया जाता है
    • low-risk steps अपने-आप execute होते हैं
    • blast radius वाले actions तय approver पर रुकते हैं
    • वही runbook Slack, CLI, PagerDuty, Linear, Jira, Web inbox में चलाया जा सकता है

Slack thread में सीधे चलने वाले runbooks

  • एक example में alert के 4 सेकंड बाद bot 94% confidence के साथ मौजूदा cluster से match हुआ runbook उसी thread में पोस्ट करता है
  • example cluster FX rate cache TTL fallback है, और verified runbook v3 को 6 बार इस्तेमाल किया गया है, जिसकी success rate 83% है
  • matching signals इस प्रकार हैं
    • Signature regex 94%
    • Recent deploy proximity 87%
    • Service overlap 100%
    • Channel + reporter history 71%
  • runbook example उस समस्या को संभालता है जिसमें stale FX rates live trades की pricing में इस्तेमाल हो रहे हैं
    • Redis eviction के दौरान cache miss path 2025 load test से बचा हुआ 1 घंटे का TTL constant fallback के रूप में इस्तेमाल करता है
    • last occurrence 11 दिन पहले दिखाया गया है
    • check और verify steps auto-execute होते हैं, जबकि fix step के लिए approval चाहिए

pilot में cluster की गई असली defects

  • pilot में अभी cluster की जा रही 7 defects में से 3 examples साझा किए गए हैं

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

    • condition है fx.rate.age_ms > 60000 और order.execution.status = filled
    • cache miss path load test से बचा हुआ TTL_FALLBACK_MS = 3_600_000 constant लौटाता है
    • peak hours में Redis eviction के दौरान लगभग 14k symbols की pricing 60 सेकंड से पुराने rates पर हुई
    • पिछली incident में manual detection से पहले 18 मिनट तक $340k के mispriced trades हुए

  • Idempotency keys regenerated on retry → duplicate ACH debits

    • condition है ach.duplicate_debit और idempotency_key.reused = false
    • retry middleware हर 5xx पर original key reuse करने के बजाय नया X-Idempotency-Key जारी करता है
    • जब bank 504 के बाद 200 response देता है, तो दूसरा retry दूसरी debit post कर देता है
    • पिछले महीने 12 duplicate debits हुए, और सभी में manual reversal और customer apology की ज़रूरत पड़ी

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

    • condition है pnl.reconcile.diff > 0.01 और services.disagree = [risk, ledger]
    • risk-svc amounts को float64 के रूप में deserialize करता है और ledger-svc Decimal128 का उपयोग करता है
    • JSON round-trip में sub-cent precision खो जाती है, और यह अंतर हज़ारों trades में जमा होकर दोपहर में reconciliation trigger करता है
    • 4 हफ्तों में छोटे अंतर जमा होकर $9.2k recon delta बन गए, उसके बाद यह पकड़ा गया
    • इसके अलावा pilot clusters में stripe webhook drops post-deploy, postgres pool exhaustion on report-gen, kafka rebalance storm, market-data WS subscription leak सूचीबद्ध हैं

runbooks wiki नहीं, बल्कि execution specification हैं

  • हर verified runbook को YAML skill में compile किया जाता है
  • skill में trigger signature, steps, expected outputs, और risky actions के लिए designated approver शामिल होते हैं
  • हर save पर runbook के साथ drift check किया जाता है ताकि documentation और executable output अलग न हो जाएँ
  • runbook properties इस प्रकार हैं
    • steps pseudocode नहीं, बल्कि असली shell commands होते हैं
    • हर fix step में designated approver और साफ़ तौर पर बताया गया blast radius होता है
    • हर execution अगली matching के लिए नया training example बन जाता है
  • YAML example rb-fx-01 runbook दिखाता है
    • confidence_threshold 0.85 है
    • confirm_cache_age Redis में cache age और eviction rate check करता है
    • force_cache_refresh के लिए approval चाहिए और इसका blast radius लगभग 14k symbols और लगभग 2 सेकंड की pricing pause है
    • confirm_fresh_rates जाँचता है कि max age 60 सेकंड से कम है या नहीं
    • execution के बाद #payments-platform, #platform-oncall को notify किया जाता है और S3 path में logs छोड़े जाते हैं

trust और governance

  • default posture read-only है, और execution approval gate से गुजरने के लिए design किया गया है
  • इसे fintech के लिए बनाया गया है, और ऐसा posture देता है जिसे security team pilot के लिए approve कर सके और auditor run पर sign off कर सके
  • data retention और deployment इस प्रकार हैं
    • raw data 90 दिन तक रखा जाता है
    • redacted data 18 महीने तक रखा जाता है
    • pilot में Legal approval मिल चुका है
    • single-tenant deployment उपलब्ध है
    • training data tenant के बाहर नहीं जाता
  • PII redaction embedding या LLM call से पहले किया जाता है
    • email, IP, customer-id, configurable secrets dictionary हटाए जाते हैं
    • original artifacts अपनी मूल location पर ही रहते हैं
  • सभी connectors read-only mode में शुरू होते हैं
    • execution scope runbook के हिसाब से दिया जाता है
    • designated approver ज़रूरी होता है
    • एक click में revoke किया जा सकता है
  • हर runbook step की provenance उस resolution incident तक जुड़ी रहती है जो learning source था
    • हर run का audit log signed state में दिया जाता है
    • इसे SIEM में export किया जा सकता है

execution surfaces और pilot terms

  • वही skill कई surfaces पर काम करती है जिन्हें टीम पहले से इस्तेमाल करती है
    • Slack thread auto-suggest: जब familiar signature आता है, तो match हुआ runbook उसी thread में पोस्ट किया जाता है
    • /pls fix CLI: terminal से वही runbook और approval gate इस्तेमाल होता है
    • PagerDuty incident page: on-call के input पूरा करने से पहले incident card पर matched runbook और one-click run दिखाया जाता है
    • Linear / Jira issue: known signature के साथ issue खुलने पर comment में runbook जोड़कर execution suggest किया जाता है
    • Web inbox: platform lead event, cluster, run, और post-mortem को एक ही जगह देख सकता है
  • pilot Closed pilot है और 4 design partners व 2026 के Q2 के साथ दिखाया गया है
  • 6 हफ्ते का pilot fintech और platform team के छोटे groups के लिए है
  • प्रक्रिया read-only ingest, 1 cluster का joint verification, और auto-suggest enable करने के क्रम में चलती है
  • अगर 4वें हफ्ते तक recurring incident volume 30% कम नहीं होता, तो कोई fee नहीं ली जाती
  • read-only ingest setup में लगभग 30 मिनट लगते हैं, पहले हफ्ते में joint cluster review किया जाता है, और 4वें हफ्ते तक कोई commitment नहीं है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2024-05-22
Hacker News की राय

  • ज़्यादातर क्षेत्रों में यह commercial bribery के दायरे में आएगा
    California Penal Code § 641.3 के मुताबिक, अगर कोई कर्मचारी अपने employer की जानकारी या सहमति के बिना अपनी position का इस्तेमाल किसी और के लिए करने के बदले पैसे या कोई मूल्यवान चीज़ लेता है, तो यह commercial bribery का अपराध बनता है
    हालांकि, अगर रकम या मूल्य $250 या उससे कम है, तो यह धारा लागू नहीं होती

    • लगता है कानून पहले से ही एक सुविधाजनक समाधान दे रहा है। मतलब bid field पर बस <=250 constraint लगाना होगा
    • अगर कोई और तरीका बिल्कुल नहीं है, तो असली सवाल यह है कि रिश्वत हमेशा बुरी ही है क्या। अगर Big Tech को परवाह होती तो customer support होता, लेकिन ऐसा नहीं है, इसलिए market अपना समाधान खुद बना रहा है
    • शायद मतलब यह है कि प्रति मामले $250 से कम हो तो ठीक दिखता है
    • अजीब है। तो क्या election donations भी $250 तक सीमित होती हैं?
    • सोशल मीडिया पर कहीं भी “मेरा account locked हो गया है” लिख दें, तो recovery के लिए किससे संपर्क करें बताने वाले bots टूट पड़ते हैं
      मेरी नज़र में account lock होना social media कर्मचारियों या platform के ऊपर चलने वाली अनियंत्रित extortion scheme जैसा लगता है। Social media खुद भी कुछ हद तक scam जैसा था, और इसने गुमनाम scammers को लोगों को गुमराह करने वाली गतिविधियां संगठित करने के मौके लगातार दिए हैं
      Social media ने NFT, Crypto, influencer culture और तरह-तरह की “fake it till you make it” वाली संरचनाओं को बढ़ावा दिया है; इससे बेहतर है कि स्वतंत्र web communities की ओर लौटें। थोड़ी देर तक तकलीफ होगी, लेकिन सिर्फ इसलिए कि आपने पैसे नहीं दिए, आपके business promotion post के views 30 पर रुक जाएं—उससे यह कहीं बेहतर है

  • यह पागलपन जैसा दिखता है। कोई भी company इस तरह का काम करने पर स्वाभाविक रूप से निकाल देगी। इसका सही नाम corruption है, और कानूनी असर की भी साफ तौर पर चिंता होनी चाहिए

    • यह निश्चित रूप से बहुत बड़ा ethical issue है, लेकिन उल्टा यही बात सबसे दिलचस्प है। Ethics, compliance और corruption issues की वजह से company के अंदर इस पर भारी ध्यान जा सकता है, और यह मूल समस्या को सच में लंबे समय तक टिकने वाले तरीके से सुधारने के लिए मजबूर कर सकता है
    • जैसा दूसरों ने कहा है, यह आगे चलकर बड़ा issue बनेगा
      कोई ऐसा व्यक्ति जिसे सचमुच suspend होना चाहिए—मसलन illegal content डालने वाला—इस service का इस्तेमाल कर सकता है। अगर company किसी internal employee द्वारा भरे गए form पर भरोसा करके suspension हटा दे, तो वह व्यक्ति illegal content डालता रहेगा और फिर से suspend होगा
      ऐसे false-positive cases पर्याप्त संख्या में जमा हो जाएं, तो company आखिरकार पाएगी कि employee अपने अधिकार का इस्तेमाल करके किसी को भी अंदर ला रहा है। कोई समझदार company internal employee द्वारा unlock किए गए accounts को flag करती होगी, इसलिए पहले case से ही पता चल सकता है
      सबसे संभावित नतीजा उस employee की firing है। सबसे खराब स्थिति में company सभी internal employees को बाहरी लोगों के लिए forms submit करने से रोक सकती है
      अगर यह site मजाक है, तो कम से कम इसे साफ तौर पर बताना चाहिए। सिर्फ यह disclaimer कि किसी अनजान व्यक्ति को verify करें, काफी नहीं है। मुझे यह भी शक है कि internal employee customer support से बेहतर verification कर पाएगा, और actual contact तथा money transfer रोकने के लिए email sending या public posting जैसे features हटाए जाने चाहिए
    • सहमत। यह ऐसा model है जिसमें व्यक्ति निजी पैसे लेकर company time और resources का इस्तेमाल करके employer की इच्छा के खिलाफ काम करता है। यह low-intensity bribery जैसा लगता है
      FAQ में कहा गया है कि employees की anonymity की गारंटी है, लेकिन साथ ही यह भी कहा गया है कि google.com email पर confirmation mail भेजकर verify किया जाता है कि वह Google employee है। जाहिर है, Google वह email देख सकता है
    • कम से कम Meta/Facebook में तो यह लंबे समय से public secret रहा है कि platform पर कुछ जल्दी करवाने का सबसे तेज तरीका Meta में किसी जान-पहचान वाले का होना है
    • मैं भी ऐसा सोचना चाहूंगा, लेकिन FAANG के अंदर ही पोस्ट की गई कुछ job openings पर काम करते समय बाहरी लोगों ने उन positions के बारे में inquiry emails भेजे। बाद में पता चला कि paid referrals के इर्द-गिर्द एक अलग छोटी referral-broker industry थी

  • Professor Robert Klitgaard ने कहा था कि corruption = monopoly + discretion - transparency। मूल रूप से यह political systems और bribery के बारे में लिखा गया था, लेकिन यहां भी लागू होता है
    https://globalanticorruptionblog.com/2014/05/27/klitgaards-m...
    कई tech companies के पास अपने market में monopoly, असीम discretion और लगभग शून्य transparency होती है। बल्कि हैरानी यह है कि किसी ने expedite fee startup के बारे में पहले क्यों नहीं सोचा
    https://en.wikipedia.org/wiki/Facilitating_payment
    ज्यादातर comments इसे employee के लिए खराब deal मानते हैं, और अगर बात $500 देकर account suspension हटाने की हो तो ऐसा हो सकता है। लेकिन अगर कोई $300k salary वाला व्यक्ति ऐसी व्यवस्था में फंसा हो जहां सभी accounts के 2FA codes email पर जाते हैं, या जिसका social media-based business हो, तो वह account वापस पाने के लिए $500 से कहीं ज्यादा दे सकता है
    Big Tech employees सभी San Francisco में नहीं हैं। Europe जैसे lower-cost regions में बहुत से लोग Americans का लगभग आधा कमाते हैं, और income जितनी कम हो, ऐसे प्रलोभन के प्रति vulnerability उतनी ज्यादा होती है
    मैं रिश्वत का समर्थन नहीं कर रहा, लेकिन यह देखकर हैरानी होती है कि लगभग सर्वसम्मति से प्रतिक्रिया यह है कि social media company employee को पैसे देना practical नहीं है। ऐतिहासिक रूप से जिन systems में transparency नहीं होती और employees के पास money-convertible discretion होता है, वे corrupt हुए हैं
    Tech companies को इसे ज्यादा गंभीरता से देखना चाहिए। जब लोग decision-maker से fair treatment पाने के लिए पैसे देने के आदी हो जाते हैं, तो उस व्यवहार को बदलना बहुत मुश्किल हो जाता है

    • जीतने का एकमात्र तरीका है इसमें भाग न लेना। Social media मानवता की महामारी है

  • एक तरफ ऐसा व्यवहार है जिससे व्यावहारिक रूप से नौकरी से निकाला जाना तय है, और दूसरी तरफ $150 हैं
    मैंने पहले FB में काम किया है, और ऐसी टीम थी जो इस तरह access अधिकार बेचने वाले कर्मचारियों को पकड़ती थी। वहां ज्यादातर tech roles के लिए यह रकम लगभग एक घंटे की सैलरी जितनी है; इतने पैसे के लिए ऐसा जोखिम उठाना कल्पना से परे है

    • ट्विस्ट: यह इस तरह access अधिकार बेचने वाले कर्मचारियों को पकड़ने के लिए honeypot marketplace हो सकता है
    • सही, और ऐसे काम के लिए rebate लेना अनैतिक लगता है। दूसरी तरफ, जो लोग ऐसी समस्या झेल रहे हैं, वे शायद अंदर के किसी व्यक्ति को पैसे देकर भी इसे हल करवाना चाहेंगे
      मुद्दा सिर्फ कोई साधारण तकनीकी समस्या, जैसे account suspension, नहीं है; असली बात शुरुआत से ही अन्याय महसूस होना और अंतहीन नरक-जैसे loop में फंसे होने का गुस्सा है
    • जो लोग FB को अच्छी तरह नहीं जानते, उनके लिए: maxrmk सही कह रहे हैं। थोड़ा और context जोड़ूं तो, अगर privacy teams में से कोई ऐसी violation पकड़ ले, तो कर्मचारी को आमतौर पर HR meeting में बुलाया जाता है और अगले ही दिन निकाल दिया जाता है
      मेरे दोस्त ने अनजाने में ऐसा कर दिया था, जब वह अपने निजी तौर पर जानने वाले दोस्त के account issue में मदद करने की कोशिश कर रहा था। उसे नहीं पता था कि यह privacy violation है और उसने system access किया; कुछ महीनों बाद project data की जांच के दौरान audit trigger हुआ, और वह record मिलने के अगले दिन ही उसे exit करा दिया गया
      इसलिए यह अच्छा business idea नहीं है
    • असल में जो चाहिए वह है उस detection team में नौकरी पाना, और फिर यह क्षमता बेचना कि वह team cases को अनदेखा कर दे। नाम कुछ plsfixmyfix.com जैसा हो सकता है
    • ऐसी ही कंपनियों में से एक में काम करने वाले के तौर पर कहूं तो, यह जोखिम उठाना बिल्कुल भी वाजिब नहीं है

  • पता नहीं सिर्फ मुझे ऐसा लगता है या नहीं, लेकिन लगता है बहुत लोग बड़ी तस्वीर miss कर रहे हैं। ऐसी services तभी पैदा होती हैं जब सामान्य समाधान समस्या हल नहीं कर पाते
    मेरे लिए यह इस बात का संकेत ज्यादा है कि Big Tech उपभोक्ता मांग के अनुरूप प्रभावी appeal प्रक्रिया बनाने में विफल रहा है। इसमें बहुत पैसा शायद न बने, लेकिन अच्छा होगा अगर Big Tech देखे कि इस हिस्से को कैसे सुधारा जाए

    • मुझे ऐसा नहीं लगता। inefficiency ही असली मुद्दा है। यह service एक joke है, और लगभग निश्चित रूप से illegal है। सभी जानते हैं कि यह system “टूटा हुआ” है, लेकिन free customer support को हमेशा तक scale नहीं किया जा सकता
      ऐसी service की वैध demand उन accounts की value साबित करती है। मुझे लगता है कुछ वर्षों में tech कंपनियां खुद इसमें उतरेंगी और enterprise customers को मिलने वाली तरह paid customer support देंगी। आप पहले से “verified” accounts के लिए पैसे दे सकते हैं, तो अगला कदम यही है। अगर company इसे monetize नहीं करेगी, तो government regulate करेगी
    • इसके आने से पहले, internal requests में से ज्यादातर शायद उन employees से आती थीं जो सच में लोगों की मदद करना चाहते थे। बेशक, पहले से ही पैसे लेकर internal form submit करने वाले कर्मचारी हो सकते हैं, लेकिन यह व्यापक रहा हो ऐसा कम लगता है
      इस website की तरह प्रक्रिया को formalize करने से account suspension हटाने के लिए internal form submissions पैसे के बदले होने की संभावना बहुत बढ़ जाती है। क्योंकि यह applicants और बेईमान employees को match करने वाला marketplace बनाता है, transaction करने की friction घटाता है, और खुलेआम पैसे को आगे रखकर अन्यायपूर्ण तरीके से suspended लोगों की मदद करने वालों के बजाय पैसे के लालची employees को आकर्षित करता है
      इसलिए यह मौजूदा प्रक्रिया से कहीं ज्यादा नैतिक रूप से घिनौना ढांचा लगता है
    • HN के अधिकांश लोगों को पता होगा कि Big Tech प्रभावी appeal प्रक्रिया बनाने में विफल रहा है। यह कोई secret नहीं है। फिर भी यह service खुला भ्रष्टाचार है

  • पहले मैंने इससे ज्यादा entrepreneurial approach देखी थी। खबर थी कि एक OnlyFans model ने LinkedIn पर employees खोजे और sex और account unsuspension का सौदा करके अपना Instagram account वापस पाया
    https://www.newsweek.com/onlyfans-star-slept-meta-employees-...

  • कैसे verify करेंगे कि requester सच में बिना किसी कारण block हुआ कोई आम व्यक्ति है, या CSAM जैसे कानूनी कारणों या terms of service violation के चलते सही तरीके से block किया गया व्यक्ति?
    अगर Mike Meta किसी असली terrorist account को खोलने की कोशिश में निकाल दिया जाता है—खासकर जबकि साफ है कि internal mentions monitor हो रहे होंगे—तो क्या इसकी जिम्मेदारी यह service लेगी?

    • अगर वह company का “verified employee” है, तो उचित paperwork डालने से पहले वह खुद जांच कर सकता है। लेकिन ऐसा करने पर आमतौर पर अलग record trail रह जाता है और अंत में उसके अपने खिलाफ लौटने की संभावना बड़ी होती है
      सच कहूं तो यहां risk, benefit से कहीं ज्यादा है। शुरुआत में ही समझ नहीं आता कि कोई यह करना क्यों चाहेगा
      “stable income वाली six-figure salary job” बनाम “internet के किसी अनजान व्यक्ति से मिला one-time $100” — जवाब साफ है
      सच कहूं तो यह sting operation जैसा लगता है
    • शायद यह वैसा ही होगा जैसे किसी की दुखभरी कहानी viral होने पर समस्या हल होती है। कोई employee उसे देखकर “यह अजनबी XYZ समस्या झेल रहा है” वाला ticket डालता है, और support का जिम्मेदार व्यक्ति जांचकर उचित कार्रवाई करता है
      Meta की वास्तविक प्रक्रिया मुझे नहीं पता
    • account freeze होने के आम कारणों में से एक, मेरी जानकारी में, यह है कि account को किसी और ने hijack कर लिया है ऐसा समझा जाता है। ऐसे account का access restore करने के लिए accelerated bypass channel बनाना हो तो उसे बहुत सावधानी से implement करना होगा

  • मुझे check करना पड़ा कि आज April Fools' Day तो नहीं है। हाल में पढ़ी चीजों में यह सबसे चौंकाने वाली में से एक है। जो लोग इससे फायदा उठा रहे हैं, मैं सच में चाहता हूं कि कम से कम उन्हें नौकरी से निकाला जाए

    • concept खुद एक तरह का performance-art protest लगता है
      इन companies के opaque non-customer-support systems को bribe देकर पार कराने वाला platform बनाना या तो low-level corruption है या high-level art
    • इस service में sign up करने वाले employees को सावधान रहना चाहिए। Facebook निश्चित रूप से इस व्यक्ति पर मुकदमा करेगा, और payment records discovery में सबसे पहले सौंपे जाने वाले materials होंगे
      anonymity लंबे समय तक बची रहे, इसका कोई तरीका मुझे नहीं दिखता
    • बल्कि यह उन आम लोगों के अधिकारों का कुछ हिस्सा वापस देता दिखता है, जिनका सम्मान करने की जरूरत giant tech companies महसूस नहीं करतीं

  • यह गैर-नैतिक क्यों माना जाता है, मैं पूरी तरह समझता हूँ। इनाम पाने वाले कर्मचारियों को निकाला जाएगा, यह भी समझता हूँ
    लेकिन असल में यह कौन-सा कानून तोड़ता है? चूँकि यह गैर-रूटीन कार्रवाई को बढ़ावा देता है, इसलिए कानूनी तौर पर यह रिश्वत जैसा लगता है। मेरा मतलब है कि बात उसी “गैर-रूटीन” हिस्से की वजह से है। क्या कंपनी अदालत जाकर यह स्वीकार करते हुए कि उसकी suspension appeal process गैर-रूटीन है, इस पर मुकदमा चला पाएगी?
    और यह standard employment contract की कौन-सी धारा तोड़ता है? employer द्वारा उपलब्ध न कराई गई service करके पैसे लेना? दिलचस्प बात यह है कि अगर employer वही service उपलब्ध कराए, तो वह रिश्वत नहीं रह जाएगी बल्कि वैध expedite fee बन जाएगी, इसलिए इसे रोकने के लिए employment contract में अलग clause डालना पड़ेगा
    यह rhetorical question नहीं है, मैं सच में जवाब ढूँढ रहा हूँ
    कई मायनों में यह प्रक्रिया पहले से हो रही है, और संबंधित लोग भी कुछ हद तक इसकी अपेक्षा रखते हैं। मैंने कई बार देखा है कि Twitter पर मशहूर व्यक्ति पर्याप्त शोर मचा पाया तो फैसला पलटता दिखा, और ऐसी बातें यहाँ front page पर भी आई हैं। फर्क सिर्फ किस तरह की currency का है जिससे system को bypass किया जाता है

    • एक आसान समाधान है। रकम को उनकी चुनी हुई charity में donation बना दें। वह ऐसी संस्था भी हो सकती है जिसे कंपनी हर साल donate करती है, और तब charity के लिए पैसा जुटाने वाले व्यक्ति को निकालना कहीं ज्यादा मुश्किल हो जाएगा
    • इसे commercial bribery कहा जाता है। हालाँकि आम तौर पर state law ऐसी चीजों को संभालता है, इसलिए jurisdiction के हिसाब से फर्क पड़ेगा। किसी और ने California law की धारा पोस्ट की थी
      California के मामले में अगर रकम $250 से कम है तो कानून लागू नहीं होता, लेकिन मूल साइट पर उस सीमा से ऊपर के “इनाम” काफी हैं
      पता नहीं यह standard है या नहीं, लेकिन कई कर्मचारी ऐसे दस्तावेज़ पर sign करते हैं कि वे कोई दूसरा employment नहीं लेंगे। यह चीज़ “employment” में आती है या नहीं, पता नहीं। लेकिन मुझे हैरानी नहीं होगी अगर कुछ employment contracts में “बाहरी paid work निषिद्ध” जैसे ज्यादा व्यापक शब्द हों
      [0] https://news.ycombinator.com/item?id=40435890
    • जिन employment contracts में मैं रहा हूँ, उन्होंने कम से कम कंपनी के बाहर किए जाने वाले commercial work की जानकारी देने की मांग की थी, और कभी-कभी शुरू करने से पहले approval भी चाहिए होता था। अगर कोई दूसरा paid work है जिसे disclose नहीं किया गया, तो कंपनी चाहे तो वह नौकरी से निकालने के लिए पर्याप्त कारण है
    • service देने वाले कर्मचारी के नजरिए से, कम से कम contract breach होने की संभावना काफी ज्यादा है

  • संदर्भ के लिए, Google और Stripe में जान-पहचान होने की वजह से मेरा startup विनाशकारी आपदा से बच पाया था। दोनों जगह automated systems ने हमें false positive के तौर पर flag कर दिया और payment processing बंद कर दी, और कोई दूसरा रास्ता नहीं था
    केवल इसलिए कि अंदर कोई व्यक्ति था, हम किसी ऐसे व्यक्ति तक appeal पहुँचा पाए जो वास्तव में judgment ले सकता था
    मुझे ऐसे platform ठीक नहीं लगते। इसमें नैतिक रूप से संदिग्ध पहलू है। लेकिन जिस कंपनी पर आप निर्भर होना चाहते हैं, वहाँ अगर आप व्यक्तिगत रूप से कुछ senior contacts को नहीं जानते, तो उस dependency को लेना ही नहीं चाहिए—यह बात महत्वपूर्ण है

    • यानी आप अपने connections का इस्तेमाल करके “विनाशकारी आपदा” से बचें तो ठीक है, और दूसरे लोग वही काम करना चाहें तो नैतिक रूप से संदिग्ध है?
    • पहली नजर में यह विरोधाभास जैसा लगता है। यह privilege ethics का उल्लंघन लगता है। शायद सभी का पैसे देकर काम करवाना ज्यादा बेहतर और fair हो सकता है