ब्लॉग पोस्ट में लिखा है, “आपको जानने वाले किसी और व्यक्ति को इसे जोड़ना पड़ता था”, लेकिन यह सटीक नहीं है, या अब ऐसा नहीं है
अगर कोई कर्मचारी किसी खास address पर content email कर दे, तो कंपनी छोड़ते समय वह content दिखाया जा सकता है। मैंने ऐसा किया था, लेकिन यह ठीक से काम किया या नहीं, अब दोबारा जांच नहीं कर सकता
क्या पूछ सकता हूं कि वह कौन-सी कंपनी थी?
क्या यह अभी भी चल रहा है?
क्या HR ने कभी इसे बदलने को कहा था? मैंने 5 साल पहले कंपनी छोड़ी थी, और मुझे वह feature बहुत पसंद था
आपने epitaphs क्यों बनाया? इसे बनाते समय कोई दिलचस्प organizational या technical चुनौती आई?
ऐसी चीज़ चलाने के लिए Git इस्तेमाल करने की मैं strongly recommend करूंगा
cron में इसे इस तरह चला सकते हैं: curl https://internal.corp/employees.txt > employees.txt git add employees.txt git commit -m "Automated: $(date -u)" || exit 0 || exit 0 यह सुनिश्चित करता है कि commit करने के लिए कुछ न हो तो भी error न आए। अब information source के हर बदलाव की history commits के रूप में रहेगी, और आप बस git log चलाकर देख सकते हैं। मैं ऐसी चीज़ें scheduled GitHub Actions से अक्सर चलाता हूं; उदाहरण https://simonwillison.net/2020/Oct/9/git-scraping/ पर है
कुछ इसी तरह, लेकिन || exit 0 के बजाय git commit में --allow-empty इस्तेमाल करता हूं
empty commit बन जाए तो भी ठीक है, क्योंकि इससे पता चलता है कि automated run fail नहीं हुआ, बल्कि सफलतापूर्वक चला और बस कोई बदलाव नहीं था
determinism के लिए | sort जोड़ना भी अच्छा हो सकता है। ऐसे छोटे डेटा के लिए Git एक underestimated database है
इसी technique से मैंने Finnish easy-language news broadcast का diff-able archive बनाना शुरू किया
high-quality, समझ में आने वाले input इकट्ठा करने में इससे बहुत मदद मिली। धन्यवाद https://github.com/hiAndrewQuinn/selkouutiset-scrape/
ऐसे data के लिए, जो अक्सर बदलता है लेकिन बहुत बड़े पैमाने पर नहीं, Git इस्तेमाल करने पर गंभीरता से सोच रहा हूं। जैसे bookshelf में रखी किताबों की list
हालांकि, ऐसी चीज़ के ऊपर मुझे transactional database features भी चाहिए। Git इस हिस्से में अच्छा है। साथ ही कुछ fields के लिए fast indexes भी चाहिए, लेकिन Git इसमें अच्छा नहीं है। इसलिए sqlite को Git में dump करने के किसी “standard” को आज़माने का सोच रहा हूं। कोई भी transaction Git commit के रूप में represent हो सकता है, और durability व reasonable indexing के लिए दोनों को साथ-साथ चलाया जा सकता है। sqlite database को कभी भी recreate और reindex किया जा सकता है, और backup use case के लिए भी यह कुछ हद तक ठीक है।
अभी तो ऐसा लग रहा है जैसे मैं वहीं खड़े-खड़े पहिए घुमा रहा हूं, और देखूंगा कि databases आगे कहां जाते हैं
अगर कोई colleague होता, तो वह इस data से समय के साथ network analysis करके यह देखने की कोशिश करता कि समय के साथ लोग किन groups में जा रहे हैं, और उसके आधार पर वे एक-दूसरे के साथ काम करना पसंद करते थे या नहीं, या नापसंद करते थे
मैंने इसी तरह LDAP track करने का tool बनाया था [0]। LDAP information का खजाना है और stalking के लिए भी बहुत बढ़िया है
लोगों को जाते देखना, और हो सके तो यह देखना कि उन्होंने कितने समय तक काम किया, किसी तरह दिलचस्प था। यह भी काफी दिलचस्प था कि दोस्तों को अपने निकाले जाने की बात खुद पता चलने से पहले LDAP में दिख गई। README में लिखा था कि Slack webhook integration से LDAP directory में क्या हो रहा है, इसे on-demand समझ सकते हैं, और नए hires, departures, promotions, HR कब क्या करता है, unauthorized changes, गलती से leak हुआ data, और users के LDAP login/logout को monitor कर सकते हैं। Microsoft और Active Directory के लिए लगभग यही काम करने वाला LDAPmonitor[1] भी है
[0]https://github.com/MegaManSec/LDAP-Monitoring-Watchdog
[1]https://github.com/p0dalirius/LDAPmonitor
वर्क-फ्रॉम-होम के दौर में layoffs अजीब लगते हैं। पहले आप किसी को सामान का डिब्बा उठाकर बाहर जाते देखते थे, तो काफी हद तक पता चल जाता था कि किसे निकाला गया है, और उसके पास जाकर मोहल्ले के बार में मिलने को कह सकते थे या संपर्क जानकारी एक्सचेंज कर सकते थे
कुछ हद तक closure मिल जाता था। अब किसी दिन कई लोग ईमेल का जवाब देना बंद कर देते हैं, और यह जानने के लिए इंतज़ार करना पड़ता है कि वे सचमुच चले गए हैं या बस व्यस्त हैं। अगर आप किसी प्रोजेक्ट के लिए जरूरी deliverable का इंतज़ार कर रहे हों, तो वह शायद कभी न आए, और कुछ समय तक वजह भी पता न चले। कंपनी directory हो तब भी WARN Act की वजह से वे अक्सर 60 दिन से ज़्यादा बने रहते हैं, और ज्यादातर कंपनियां “laid-off लोगों की सूची” बनाती नहीं लगतीं। अगर यह भी न बताया जाए कि किसे निकाला गया है, और layoff की सूचना देने से पहले ही access काट दिया जाए ताकि अलविदा कहने का मौका भी न मिले, तो closure पाना सचमुच मुश्किल हो जाता है
Slack में लोगों के accounts को बिना अलविदा कहे inactive status में बदलते देखना दुखद है
मेरा सबसे खराब boss, छोड़ चुके लोगों के काम के handover data को खोजने के नाम पर पूर्व कर्मचारियों के Slack accounts का access मांगता था। जब भी वह उनकी तरह login करता, account कभी-कभी हरा हो जाता था। किसी पूर्व सहकर्मी के account को हरा होते देखकर यह जानना कि boss उनके private messages खंगाल रहा है, बेहद creepy था। मुझे पता है कि कंपनी वैसे भी Slack messages देख सकती है, लेकिन boss को real time में ऐसा करते देखना और भी रोंगटे खड़े कर देने वाला है
शुरुआत में उन्होंने कोशिश की थी, लेकिन pandemic की शुरुआत में मौतों की संख्या इतनी तेजी से बढ़ी कि organization लगातार सबको बता ही नहीं पा रहा था
HR का सभी के लिए कुछ पंक्तियां लिखने की कोशिश करना ही morale तोड़ने वाला काम था, और जहां कभी जीवंत, निजी touch था, वहां लंबे समय तक रहने वाली फीकी-सी खाली जगह बन गई। लोग लगातार गायब होते रहते हैं, लेकिन उनके चले जाने या कैसे गए, इस बारे में अब भी कोई announcement नहीं होता।
Pandemic की शुरुआत में मेरी General Counsel से आखिरी मुलाकात हुई थी। lockdown के दौरान ज्यादातर लोगों की तरह, उन्होंने अपने immediate family के अलावा किसी को नहीं देखा था, और महीनों से अच्छी बातचीत का मौका भी नहीं मिला था—वैसे शायद वह भी उन्हें मार ही देता। उन्होंने वे बातें उंडेल दीं जिन्हें वे खत्म कर रहे थे, और बाद में, एक lawyer की तरह, CIO को एक शानदार पत्र लिखा, जिससे हमारे बीच मेरी सबसे पसंदीदा बातचीतों में से एक शुरू हुई।
6 महीने बाद किसी ने legal team की तरफ जाते हुए फोन किया कि किसी की मौत हो गई है, और मुझे तुरंत अशुभ-सा एहसास हुआ। मैंने website, directory, local obituaries सब खंगाल डाले, लेकिन कुछ नहीं मिला, और अफवाहों का network भी शांत था। इसलिए मैंने उनके assistant को फोन किया, तो उसने काफी सपाट ढंग से बताया कि GC का 6 हफ्ते पहले निधन हो गया था।
लगभग ठीक 1 साल बाद ही organization की प्रक्रिया ने इसे पकड़ पाया और “Remembering $generalCounselor” जारी किया। तब तक funeral छूट चुका था, परिवार shift हो चुका था, और इतनी देर से condolences भेजना बहुतों को awkward लगा। दूसरों की हैरानी, शर्म और दुख देखना कोई सुकून देने वाला नहीं था, लेकिन इतना पता चला कि ऐसा महसूस करने वाला मैं अकेला नहीं था।
हम छोटे नहीं हैं, लेकिन एक personal organization हैं, और हर मौत ने एक छोटी-सी खाली जगह छोड़ दी जिसे हम साथ मिलकर स्वीकार या संभाल नहीं पाए। अब भी loss को process करने का कोई तरीका नहीं है, और हमने इसके बारे में बात भी नहीं की। सेव किए हुए पुराने contacts का extensions reassign होने के बाद फिर से उभर आना अनिवार्य रूप से कब्र से आए फोन जैसा लगता है। हम संपर्क बनाए रखकर track करने की कोशिश करते हैं, लेकिन धीरे-धीरे connections धुंधले पड़ते जाते हैं, और उनके साथ हमारी यादें और इतिहास भी फीके पड़ते जाते हैं
office work culture की एक चीज़ जो याद आती है, वह है ज्यादा मानवीय connection
लोगों का desk पर आकर जिंदगी के बारे में छोटी-मोटी बातें करना और मज़ाक करना। मैंने जिंदगी में कभी इतना जोर से नहीं हंसा था। कुल मिलाकर रिश्ते ज्यादा करीबी थे, और जब लोग जाते थे तो दुख होता था, लेकिन अगर वे बेहतर जगह जा रहे हों तो खुशी भी होती थी। उसके मुकाबले work-from-home बहुत sterile और impersonal लगता है। मैं करीब 2015 से remote work कर रहा हूं, इसलिए यह office वापसी का समर्थन नहीं है, बस nostalgia है
access बंद करना मुझे हमेशा बेवकूफी लगा, और manager के तौर पर मैंने ऐसा नहीं किया
अगर आपने 3 साल तक किसी पर भरोसा करके उसके साथ काम किया है, तो 1–2 हफ्ते और भरोसा कर सकते हैं। बचे हुए काम निपटाने और थोड़ा समय लेने में कोई दिक्कत नहीं। हम सब adult हैं। मैं समझता हूं कि worst-case में बुरी चीज़ें हो सकती हैं, लेकिन वह तो हमेशा ही सच है
शायद यह कहने का यही एकमात्र मौका हो, लेकिन LinkedIn का होना अच्छा है। कम से कम इतना तो पता रहता है कि गए हुए व्यक्ति से कभी भी फिर संपर्क किया जा सकता है
यह हिस्सा अच्छा लगा:
“साथ ही, अगर ऐसा कुछ चलाने पर कोई नाराज़ हो जाए, तो शायद आप वैसे भी वहाँ काम नहीं करना चाहेंगे। उल्टा, अगर IT या कोई समान संगठन ‘खतरा’ महसूस किए बिना ऐसे टूल बना सकता है, तो हो सकता है आप ऐसी जगह हों जहाँ लोग सचमुच दिलचस्प और उपयोगी चीज़ें बनाना पसंद करते हैं। ऐसी जगहों को संजोकर रखना चाहिए। वे अक्सर ज़्यादा लंबे समय तक नहीं रहतीं”
फिर भी अगर आप वहाँ काम करना चाहते हैं, तो पहले कानूनी स्थिति जाँच लेना बेहतर है
यह लगभग निश्चित रूप से निजी डेटा की अनधिकृत प्रोसेसिंग हो सकती है। सिर्फ़ access permission होना मतलब यह नहीं कि आप मनमानी कर सकते हैं। खासकर archive बनाना, history रखना, और बाहरी डेटा से जोड़ना ऐसे interface का intended use नहीं है। जानकारी को work laptop जैसे रूप में घर ले जाना एक अलग समस्या बन सकता है, और इसे trade secrets बाहर ले जाना भी माना जा सकता है।
कम-से-कम Europe में ऐसे interface का दुरुपयोग करना काफ़ी संभव है कि illegal हो, और copies या diff संभालकर रखना तो और भी ज़्यादा। Employer को कार्रवाई करनी पड़ सकती है, और नहीं की तो वह liable हो सकता है। या फिर बाद में इसी violation को बहाना बनाकर contract आसानी से terminate कर सकता है। खासकर अगर आप उस जानकारी को leverage की तरह इस्तेमाल करें, तो और भी।
Network जितना बड़ा होगा, मुसीबत में फँसने की संभावना भी उतनी ही ज़्यादा लगती है। उल्टा, अगर ऐसा नहीं है तो data इकट्ठा करने की utility भी कम है। क्या बेहतर नहीं होगा कि colleagues के साथ organize करके employment information स्वेच्छा से share की जाए और collective bargaining power हासिल की जाए?
मुझे जिज्ञासा है कि क्या यह personal data में आता है। आखिर यह सबके नाम, job titles और employment duration की copy है
कई European companies शायद employees द्वारा ऐसी lists रखने को लेकर सावधान रहेंगी
Amazon ने layoffs होने के बाद प्रभावित लोगों को ढूँढने वाली LDAP query share करने वाले व्यक्ति को fire कर दिया था। उसने information leak भी नहीं की थी, फिर भी ऐसा हुआ
यह बिल्कुल अच्छा नहीं है। यह सिर्फ़ बढ़ा-चढ़ाकर posture लेना है
इसे check करने का तरीका है इसी तरह posture लेने वाले HN comments ढूँढना। Overton window चौड़ी होने के बाद लोग restraint छोड़ देते हैं और खुलकर बताते हैं कि हम क्या जानते हैं। मतलब यह एक पुराने address book को ऐसा gossip sheet बना देने वाला system abuse है जिससे संबंधित लोग भी चौंक जाएँ।
उदाहरण के लिए: “शुरुआत में मुझे सिर्फ़ इस बात की परवाह थी कि कौन-से accounts deactivate हुए। फिर job title changes, surname changes (marriage), department size, समय के साथ company headcount वगैरह track करने लगा”, “LDAP में secrets भरे पड़े हैं। लगभग सब कुछ anonymous access से मिल सकता है, यह हैरानी की बात है। announcement से पहले team/department mergers भी पकड़ लिए, और internal projects की secret mailing lists में members देखकर पता लगाया जा सकता है कि क्या चल रहा है”, “कई अजीब चीज़ें इस पर निर्भर करती हैं कि LDAP tree widely accessible है। बस ज़्यादातर लोगों की सोच से ज़्यादा information leak हो रही होती है”, “HR कब क्या करता है इसकी निगरानी करना, और users कब LDAP में login/logout करते हैं यह detect करना” जैसी बातें
LDAP में secrets भरे पड़े हैं। Company में क्या चल रहा है यह देखने का यह बढ़िया तरीका है, और यह भी हैरानी की बात है कि लगभग सब कुछ anonymous access से मिल सकता है
Announcement से पहले team या department mergers पकड़ चुका हूँ। Internal projects की secret mailing lists में members देखकर भी यह निकाला जा सकता है कि क्या चल रहा है। अगर email address कुछ reveal कर दे तो bonus है। अगर आप LDAP अच्छी तरह जानते हैं तो ldapsearch अच्छा है, और अगर बस explore करना चाहते हैं तो Apache LDAP Studio एक शानदार UI tool है। हर किसी को इतना तो पता होना चाहिए कि internal apps के लिए LDAP से bind करने वाली login service बना सके। System administrators द्वारा maintain किए गए groups का इस्तेमाल करके app permissions control किए जा सकते हैं; यह बहुत powerful है और जल्दी शुरू करना आसान है
उन companies को देखकर आज भी हैरानी होती है जो random users, यहाँ तक कि anonymous users, को company का पूरा AD tree index करने देती हैं
सहूलियत तो है, पर फिर भी। और अक्सर यह ऐसी जानकारी पाने का इकलौता तरीका होता है जो intranet pages पर नहीं होती। जैसे IT में असल में कौन-कौन सी teams हैं, offices कहाँ हैं, किसी का manager कौन है, और जाहिर है कि किस distribution list में मैं नहीं हूँ पर दूसरा user है, जिसके कारण internal portal access problem हो रही है
Internal app authentication के लिए LDAP groups इस्तेमाल करोगे? अगर अगला SolarWinds बनना चाहते हो तो ठीक है
यह हैरान करने वाला है कि इतने सारे लोग independently इसी idea तक पहुँचे। पिछली job में मैंने “the sackinator” बनाया था
sacked का मतलब fired होना है। यह एक cron job था जो हर रात पूरी AD directory dump करता था, और एक script थी जो किसी भी दो दिनों के outputs का diff निकालती थी। Data dump हो चुका होता था, इसलिए कभी भी पीछे जाकर extra analysis किया जा सकता था। शुरू में बस यह देखता था कि कौन-से accounts deactivate हुए हैं, बाद में job title changes, surname changes (marriage), department size, समय के साथ company headcount वगैरह track करने लगा। मैं पूरी तरह सहमत हूँ कि जहाँ आप ऐसे tools बना सकते हैं और IT threat महसूस नहीं करता, ऐसी जगहों को संजोकर रखना चाहिए
हाहाहा। ‘KTMJ’ द्वारा manage की जाने वाली एक बहुत मिलती-जुलती script है। मकसद inactive users ढूँढना नहीं, बल्कि कुछ खास LDAP attributes को दूसरे system में sync करना है
यह organization इतना बड़ा है कि users की संख्या 300,000 से ज़्यादा है। Script LDAP query करती है और sync file तैयार करती है, फिर असली sync import चलता है जो verify करता है कि हर user अभी मौजूद है या नहीं; उस छोटी-सी अवधि में ही सैकड़ों accounts deactivate हो चुके होते हैं और ‘error’ log file में record हो जाते हैं। असली sync और ‘error’ log file मेरे direct control से बाहर हैं।
मैं पागलों की तरह इसलिए हँसा क्योंकि ‘budget constraints’ की वजह से मेरा contract खत्म होने वाला है। कई rounds of layoffs पहले ही देख चुका हूँ, इसलिए उम्मीद थी। मेरा account भी अगले monthly cycle में deactivate होने वाले accounts में से एक होगा, लेकिन उससे पहले मुझे process और expected inactive-user ‘error’ logging behavior successors को hand over करना है
इसे ज़रूरत से ज़्यादा negative देखने की ज़रूरत नहीं। जहाँ मैं काम करता हूँ, वहाँ इस tool को “new-hires” कहा जाता है
यह third-party HR tool के लिए limited read-only API key इस्तेमाल करता है, और वह key मुझे People Director ने दी थी। कभी-कभी - से शुरू होने वाली lines भी होती हैं, लेकिन tool का नाम + से शुरू होने वाली lines से आया है।
new-hires हमारे monorepo के “people” Python module/CLI के ऊपर बना है। यह tool org chart diff से कहीं ज़्यादा useful है। इससे पता चलता है कि कौन किस team में है, कहाँ है, आज काम कर रहा है या नहीं, work anniversary celebrate करने का समय है या नहीं, वगैरह। यह अच्छे CLI tools के लिए मेरे बनाए “ZFS litmus test” को भी follow करता है: parseable और header-less output के लिए -pH देता है। ऐसी जगह सचमुच संजोकर रखने लायक है
कौन-सी जगह है? सच में अच्छी जगह लगती है
पहली job में मैंने ऐसा system बनाने की कोशिश की थी, लेकिन manager ने सुनकर साफ़ तौर पर मना कर दिया
बाद में उस company ने एक ही दिन में software engineers के 15% को lay off कर दिया। Support team ने public issue tracker में employee account decommissioning tickets बना दिए, इसलिए कई लोगों को meeting invite मिलने से पहले ही उसी तरीके से पता चल गया
1 टिप्पणियां
Hacker News टिप्पणियां
epitaphs बनाने वाला मैं ही हूं। कुछ भी पूछिए
अगर कोई कर्मचारी किसी खास address पर content email कर दे, तो कंपनी छोड़ते समय वह content दिखाया जा सकता है। मैंने ऐसा किया था, लेकिन यह ठीक से काम किया या नहीं, अब दोबारा जांच नहीं कर सकता
क्या HR ने कभी इसे बदलने को कहा था? मैंने 5 साल पहले कंपनी छोड़ी थी, और मुझे वह feature बहुत पसंद था
ऐसी चीज़ चलाने के लिए Git इस्तेमाल करने की मैं strongly recommend करूंगा
cron में इसे इस तरह चला सकते हैं:
curl https://internal.corp/employees.txt > employees.txtgit add employees.txtgit commit -m "Automated: $(date -u)" || exit 0|| exit 0यह सुनिश्चित करता है कि commit करने के लिए कुछ न हो तो भी error न आए। अब information source के हर बदलाव की history commits के रूप में रहेगी, और आप बसgit logचलाकर देख सकते हैं। मैं ऐसी चीज़ें scheduled GitHub Actions से अक्सर चलाता हूं; उदाहरण https://simonwillison.net/2020/Oct/9/git-scraping/ पर है|| exit 0के बजायgit commitमें--allow-emptyइस्तेमाल करता हूंempty commit बन जाए तो भी ठीक है, क्योंकि इससे पता चलता है कि automated run fail नहीं हुआ, बल्कि सफलतापूर्वक चला और बस कोई बदलाव नहीं था
| sortजोड़ना भी अच्छा हो सकता है। ऐसे छोटे डेटा के लिए Git एक underestimated database हैhigh-quality, समझ में आने वाले input इकट्ठा करने में इससे बहुत मदद मिली। धन्यवाद
https://github.com/hiAndrewQuinn/selkouutiset-scrape/
हालांकि, ऐसी चीज़ के ऊपर मुझे transactional database features भी चाहिए। Git इस हिस्से में अच्छा है। साथ ही कुछ fields के लिए fast indexes भी चाहिए, लेकिन Git इसमें अच्छा नहीं है। इसलिए sqlite को Git में dump करने के किसी “standard” को आज़माने का सोच रहा हूं। कोई भी transaction Git commit के रूप में represent हो सकता है, और durability व reasonable indexing के लिए दोनों को साथ-साथ चलाया जा सकता है। sqlite database को कभी भी recreate और reindex किया जा सकता है, और backup use case के लिए भी यह कुछ हद तक ठीक है।
अभी तो ऐसा लग रहा है जैसे मैं वहीं खड़े-खड़े पहिए घुमा रहा हूं, और देखूंगा कि databases आगे कहां जाते हैं
मैंने इसी तरह LDAP track करने का tool बनाया था [0]। LDAP information का खजाना है और stalking के लिए भी बहुत बढ़िया है
लोगों को जाते देखना, और हो सके तो यह देखना कि उन्होंने कितने समय तक काम किया, किसी तरह दिलचस्प था। यह भी काफी दिलचस्प था कि दोस्तों को अपने निकाले जाने की बात खुद पता चलने से पहले LDAP में दिख गई। README में लिखा था कि Slack webhook integration से LDAP directory में क्या हो रहा है, इसे on-demand समझ सकते हैं, और नए hires, departures, promotions, HR कब क्या करता है, unauthorized changes, गलती से leak हुआ data, और users के LDAP login/logout को monitor कर सकते हैं। Microsoft और Active Directory के लिए लगभग यही काम करने वाला LDAPmonitor[1] भी है
[0]https://github.com/MegaManSec/LDAP-Monitoring-Watchdog
[1]https://github.com/p0dalirius/LDAPmonitor
वर्क-फ्रॉम-होम के दौर में layoffs अजीब लगते हैं। पहले आप किसी को सामान का डिब्बा उठाकर बाहर जाते देखते थे, तो काफी हद तक पता चल जाता था कि किसे निकाला गया है, और उसके पास जाकर मोहल्ले के बार में मिलने को कह सकते थे या संपर्क जानकारी एक्सचेंज कर सकते थे
कुछ हद तक closure मिल जाता था। अब किसी दिन कई लोग ईमेल का जवाब देना बंद कर देते हैं, और यह जानने के लिए इंतज़ार करना पड़ता है कि वे सचमुच चले गए हैं या बस व्यस्त हैं। अगर आप किसी प्रोजेक्ट के लिए जरूरी deliverable का इंतज़ार कर रहे हों, तो वह शायद कभी न आए, और कुछ समय तक वजह भी पता न चले। कंपनी directory हो तब भी WARN Act की वजह से वे अक्सर 60 दिन से ज़्यादा बने रहते हैं, और ज्यादातर कंपनियां “laid-off लोगों की सूची” बनाती नहीं लगतीं। अगर यह भी न बताया जाए कि किसे निकाला गया है, और layoff की सूचना देने से पहले ही access काट दिया जाए ताकि अलविदा कहने का मौका भी न मिले, तो closure पाना सचमुच मुश्किल हो जाता है
मेरा सबसे खराब boss, छोड़ चुके लोगों के काम के handover data को खोजने के नाम पर पूर्व कर्मचारियों के Slack accounts का access मांगता था। जब भी वह उनकी तरह login करता, account कभी-कभी हरा हो जाता था। किसी पूर्व सहकर्मी के account को हरा होते देखकर यह जानना कि boss उनके private messages खंगाल रहा है, बेहद creepy था। मुझे पता है कि कंपनी वैसे भी Slack messages देख सकती है, लेकिन boss को real time में ऐसा करते देखना और भी रोंगटे खड़े कर देने वाला है
HR का सभी के लिए कुछ पंक्तियां लिखने की कोशिश करना ही morale तोड़ने वाला काम था, और जहां कभी जीवंत, निजी touch था, वहां लंबे समय तक रहने वाली फीकी-सी खाली जगह बन गई। लोग लगातार गायब होते रहते हैं, लेकिन उनके चले जाने या कैसे गए, इस बारे में अब भी कोई announcement नहीं होता।
Pandemic की शुरुआत में मेरी General Counsel से आखिरी मुलाकात हुई थी। lockdown के दौरान ज्यादातर लोगों की तरह, उन्होंने अपने immediate family के अलावा किसी को नहीं देखा था, और महीनों से अच्छी बातचीत का मौका भी नहीं मिला था—वैसे शायद वह भी उन्हें मार ही देता। उन्होंने वे बातें उंडेल दीं जिन्हें वे खत्म कर रहे थे, और बाद में, एक lawyer की तरह, CIO को एक शानदार पत्र लिखा, जिससे हमारे बीच मेरी सबसे पसंदीदा बातचीतों में से एक शुरू हुई।
6 महीने बाद किसी ने legal team की तरफ जाते हुए फोन किया कि किसी की मौत हो गई है, और मुझे तुरंत अशुभ-सा एहसास हुआ। मैंने website, directory, local obituaries सब खंगाल डाले, लेकिन कुछ नहीं मिला, और अफवाहों का network भी शांत था। इसलिए मैंने उनके assistant को फोन किया, तो उसने काफी सपाट ढंग से बताया कि GC का 6 हफ्ते पहले निधन हो गया था।
लगभग ठीक 1 साल बाद ही organization की प्रक्रिया ने इसे पकड़ पाया और “Remembering $generalCounselor” जारी किया। तब तक funeral छूट चुका था, परिवार shift हो चुका था, और इतनी देर से condolences भेजना बहुतों को awkward लगा। दूसरों की हैरानी, शर्म और दुख देखना कोई सुकून देने वाला नहीं था, लेकिन इतना पता चला कि ऐसा महसूस करने वाला मैं अकेला नहीं था।
हम छोटे नहीं हैं, लेकिन एक personal organization हैं, और हर मौत ने एक छोटी-सी खाली जगह छोड़ दी जिसे हम साथ मिलकर स्वीकार या संभाल नहीं पाए। अब भी loss को process करने का कोई तरीका नहीं है, और हमने इसके बारे में बात भी नहीं की। सेव किए हुए पुराने contacts का extensions reassign होने के बाद फिर से उभर आना अनिवार्य रूप से कब्र से आए फोन जैसा लगता है। हम संपर्क बनाए रखकर track करने की कोशिश करते हैं, लेकिन धीरे-धीरे connections धुंधले पड़ते जाते हैं, और उनके साथ हमारी यादें और इतिहास भी फीके पड़ते जाते हैं
लोगों का desk पर आकर जिंदगी के बारे में छोटी-मोटी बातें करना और मज़ाक करना। मैंने जिंदगी में कभी इतना जोर से नहीं हंसा था। कुल मिलाकर रिश्ते ज्यादा करीबी थे, और जब लोग जाते थे तो दुख होता था, लेकिन अगर वे बेहतर जगह जा रहे हों तो खुशी भी होती थी। उसके मुकाबले work-from-home बहुत sterile और impersonal लगता है। मैं करीब 2015 से remote work कर रहा हूं, इसलिए यह office वापसी का समर्थन नहीं है, बस nostalgia है
अगर आपने 3 साल तक किसी पर भरोसा करके उसके साथ काम किया है, तो 1–2 हफ्ते और भरोसा कर सकते हैं। बचे हुए काम निपटाने और थोड़ा समय लेने में कोई दिक्कत नहीं। हम सब adult हैं। मैं समझता हूं कि worst-case में बुरी चीज़ें हो सकती हैं, लेकिन वह तो हमेशा ही सच है
यह हिस्सा अच्छा लगा:
“साथ ही, अगर ऐसा कुछ चलाने पर कोई नाराज़ हो जाए, तो शायद आप वैसे भी वहाँ काम नहीं करना चाहेंगे। उल्टा, अगर IT या कोई समान संगठन ‘खतरा’ महसूस किए बिना ऐसे टूल बना सकता है, तो हो सकता है आप ऐसी जगह हों जहाँ लोग सचमुच दिलचस्प और उपयोगी चीज़ें बनाना पसंद करते हैं। ऐसी जगहों को संजोकर रखना चाहिए। वे अक्सर ज़्यादा लंबे समय तक नहीं रहतीं”
यह लगभग निश्चित रूप से निजी डेटा की अनधिकृत प्रोसेसिंग हो सकती है। सिर्फ़ access permission होना मतलब यह नहीं कि आप मनमानी कर सकते हैं। खासकर archive बनाना, history रखना, और बाहरी डेटा से जोड़ना ऐसे interface का intended use नहीं है। जानकारी को work laptop जैसे रूप में घर ले जाना एक अलग समस्या बन सकता है, और इसे trade secrets बाहर ले जाना भी माना जा सकता है।
कम-से-कम Europe में ऐसे interface का दुरुपयोग करना काफ़ी संभव है कि illegal हो, और copies या diff संभालकर रखना तो और भी ज़्यादा। Employer को कार्रवाई करनी पड़ सकती है, और नहीं की तो वह liable हो सकता है। या फिर बाद में इसी violation को बहाना बनाकर contract आसानी से terminate कर सकता है। खासकर अगर आप उस जानकारी को leverage की तरह इस्तेमाल करें, तो और भी।
Network जितना बड़ा होगा, मुसीबत में फँसने की संभावना भी उतनी ही ज़्यादा लगती है। उल्टा, अगर ऐसा नहीं है तो data इकट्ठा करने की utility भी कम है। क्या बेहतर नहीं होगा कि colleagues के साथ organize करके employment information स्वेच्छा से share की जाए और collective bargaining power हासिल की जाए?
कई European companies शायद employees द्वारा ऐसी lists रखने को लेकर सावधान रहेंगी
इसे check करने का तरीका है इसी तरह posture लेने वाले HN comments ढूँढना। Overton window चौड़ी होने के बाद लोग restraint छोड़ देते हैं और खुलकर बताते हैं कि हम क्या जानते हैं। मतलब यह एक पुराने address book को ऐसा gossip sheet बना देने वाला system abuse है जिससे संबंधित लोग भी चौंक जाएँ।
उदाहरण के लिए: “शुरुआत में मुझे सिर्फ़ इस बात की परवाह थी कि कौन-से accounts deactivate हुए। फिर job title changes, surname changes (marriage), department size, समय के साथ company headcount वगैरह track करने लगा”, “LDAP में secrets भरे पड़े हैं। लगभग सब कुछ anonymous access से मिल सकता है, यह हैरानी की बात है। announcement से पहले team/department mergers भी पकड़ लिए, और internal projects की secret mailing lists में members देखकर पता लगाया जा सकता है कि क्या चल रहा है”, “कई अजीब चीज़ें इस पर निर्भर करती हैं कि LDAP tree widely accessible है। बस ज़्यादातर लोगों की सोच से ज़्यादा information leak हो रही होती है”, “HR कब क्या करता है इसकी निगरानी करना, और users कब LDAP में login/logout करते हैं यह detect करना” जैसी बातें
LDAP में secrets भरे पड़े हैं। Company में क्या चल रहा है यह देखने का यह बढ़िया तरीका है, और यह भी हैरानी की बात है कि लगभग सब कुछ anonymous access से मिल सकता है
Announcement से पहले team या department mergers पकड़ चुका हूँ। Internal projects की secret mailing lists में members देखकर भी यह निकाला जा सकता है कि क्या चल रहा है। अगर email address कुछ reveal कर दे तो bonus है। अगर आप LDAP अच्छी तरह जानते हैं तो
ldapsearchअच्छा है, और अगर बस explore करना चाहते हैं तो Apache LDAP Studio एक शानदार UI tool है। हर किसी को इतना तो पता होना चाहिए कि internal apps के लिए LDAP से bind करने वाली login service बना सके। System administrators द्वारा maintain किए गए groups का इस्तेमाल करके app permissions control किए जा सकते हैं; यह बहुत powerful है और जल्दी शुरू करना आसान हैसहूलियत तो है, पर फिर भी। और अक्सर यह ऐसी जानकारी पाने का इकलौता तरीका होता है जो intranet pages पर नहीं होती। जैसे IT में असल में कौन-कौन सी teams हैं, offices कहाँ हैं, किसी का manager कौन है, और जाहिर है कि किस distribution list में मैं नहीं हूँ पर दूसरा user है, जिसके कारण internal portal access problem हो रही है
यह हैरान करने वाला है कि इतने सारे लोग independently इसी idea तक पहुँचे। पिछली job में मैंने “the sackinator” बनाया था
sacked का मतलब fired होना है। यह एक cron job था जो हर रात पूरी AD directory dump करता था, और एक script थी जो किसी भी दो दिनों के outputs का diff निकालती थी। Data dump हो चुका होता था, इसलिए कभी भी पीछे जाकर extra analysis किया जा सकता था। शुरू में बस यह देखता था कि कौन-से accounts deactivate हुए हैं, बाद में job title changes, surname changes (marriage), department size, समय के साथ company headcount वगैरह track करने लगा। मैं पूरी तरह सहमत हूँ कि जहाँ आप ऐसे tools बना सकते हैं और IT threat महसूस नहीं करता, ऐसी जगहों को संजोकर रखना चाहिए
हाहाहा। ‘KTMJ’ द्वारा manage की जाने वाली एक बहुत मिलती-जुलती script है। मकसद inactive users ढूँढना नहीं, बल्कि कुछ खास LDAP attributes को दूसरे system में sync करना है
यह organization इतना बड़ा है कि users की संख्या 300,000 से ज़्यादा है। Script LDAP query करती है और sync file तैयार करती है, फिर असली sync import चलता है जो verify करता है कि हर user अभी मौजूद है या नहीं; उस छोटी-सी अवधि में ही सैकड़ों accounts deactivate हो चुके होते हैं और ‘error’ log file में record हो जाते हैं। असली sync और ‘error’ log file मेरे direct control से बाहर हैं।
मैं पागलों की तरह इसलिए हँसा क्योंकि ‘budget constraints’ की वजह से मेरा contract खत्म होने वाला है। कई rounds of layoffs पहले ही देख चुका हूँ, इसलिए उम्मीद थी। मेरा account भी अगले monthly cycle में deactivate होने वाले accounts में से एक होगा, लेकिन उससे पहले मुझे process और expected inactive-user ‘error’ logging behavior successors को hand over करना है
इसे ज़रूरत से ज़्यादा negative देखने की ज़रूरत नहीं। जहाँ मैं काम करता हूँ, वहाँ इस tool को “new-hires” कहा जाता है
यह third-party HR tool के लिए limited read-only API key इस्तेमाल करता है, और वह key मुझे People Director ने दी थी। कभी-कभी
-से शुरू होने वाली lines भी होती हैं, लेकिन tool का नाम+से शुरू होने वाली lines से आया है।new-hires हमारे monorepo के “people” Python module/CLI के ऊपर बना है। यह tool org chart diff से कहीं ज़्यादा useful है। इससे पता चलता है कि कौन किस team में है, कहाँ है, आज काम कर रहा है या नहीं, work anniversary celebrate करने का समय है या नहीं, वगैरह। यह अच्छे CLI tools के लिए मेरे बनाए “ZFS litmus test” को भी follow करता है: parseable और header-less output के लिए
-pHदेता है। ऐसी जगह सचमुच संजोकर रखने लायक हैपहली job में मैंने ऐसा system बनाने की कोशिश की थी, लेकिन manager ने सुनकर साफ़ तौर पर मना कर दिया
बाद में उस company ने एक ही दिन में software engineers के 15% को lay off कर दिया। Support team ने public issue tracker में employee account decommissioning tickets बना दिए, इसलिए कई लोगों को meeting invite मिलने से पहले ही उसी तरीके से पता चल गया