การระบุคนที่กำลังจะออกจากบริษัท: วิธีการ 'dump', 'diff', 'repeat'

 (rachelbythebay.com)
1 คะแนน โดย GN⁺ 2024-02-10 | 1 ความคิดเห็น | แชร์ทาง WhatsApp

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2024-02-10
ความคิดเห็นบน Hacker News

  • เป็นคนสร้าง epitaphs เอง ถามมาได้เลย

    • ในบล็อกเขียนไว้ว่า “ต้องให้คนอื่นที่รู้จักคุณเป็นคนเพิ่มให้” แต่ไม่ถูกต้องนัก หรืออย่างน้อยตอนนี้ก็ไม่ใช่แล้ว
      ถ้าพนักงานส่งเนื้อหาไปยังอีเมลแอดเดรสพิเศษ เมื่อเขาออกจากบริษัท เนื้อหานั้นก็อาจถูกแสดงขึ้นมาได้ ผมทำแบบนั้นไว้ แต่ตอนนี้กลับไปยืนยันไม่ได้แล้วว่ามันทำงานถูกต้องหรือไม่
    • ขอถามได้ไหมว่าเป็นบริษัทไหน?
    • ยังเปิดใช้งานอยู่ไหม?
      HR เคยขอให้เปลี่ยนไหม? ผมลาออกไปเมื่อ 5 ปีก่อน และชอบฟีเจอร์นั้นมากจริง ๆ
    • ทำไมถึงสร้าง epitaphs ขึ้นมา? ระหว่างสร้างมีความท้าทายเชิงองค์กรหรือเชิงเทคนิคที่น่าสนใจไหม?

  • ถ้าจะรันอะไรแบบนี้ ขอแนะนำอย่างยิ่งให้ใช้ Git
    สามารถรันจาก cron ประมาณนี้ได้:
    curl https://internal.corp/employees.txt > employees.txt
    git add employees.txt
    git commit -m "Automated: $(date -u)" || exit 0
    || exit 0 จะช่วยไม่ให้เกิด error แม้ไม่มีอะไรให้ commit ตอนนี้การเปลี่ยนแปลงทั้งหมดจากแหล่งข้อมูลจะถูกเก็บเป็น commit และดูได้ด้วยการรัน git log เท่านั้น ผมมักรันของแบบนี้บ่อย ๆ ด้วย GitHub Actions แบบตั้งเวลาไว้ ตัวอย่างอยู่ที่ https://simonwillison.net/2020/Oct/9/git-scraping/

    • ทำคล้ายกัน แต่แทนที่จะใช้ || exit 0 ผมใช้ --allow-empty กับ git commit
      การมี empty commit ก็ไม่เป็นไร เพราะทำให้รู้ได้ว่า automated run ไม่ได้ล้มเหลว แต่รันสำเร็จแล้วเพียงแค่ไม่มีการเปลี่ยนแปลง
    • เพื่อความเป็น deterministic น่าจะเพิ่ม | sort ได้ด้วย สำหรับ ข้อมูลขนาดเล็ก แบบนี้ Git เป็นฐานข้อมูลที่ถูกประเมินค่าต่ำไป
    • ผมเริ่มสร้าง archive ที่ diff ได้ของรายการข่าวภาษาง่ายของฟินแลนด์ด้วยเทคนิคเดียวกัน
      ช่วยได้มากในการรวบรวม input ที่มีคุณภาพสูงและเข้าใจได้ ขอบคุณ
      https://github.com/hiAndrewQuinn/selkouutiset-scrape/
    • กำลังคิดอย่างจริงจังว่าจะใช้ Git กับข้อมูลทั่ว ๆ ไปที่เปลี่ยนบ่อยแต่ไม่ได้เปลี่ยนใหญ่ เช่น รายชื่อหนังสือบนชั้นหนังสือ
      แต่ก็อยากได้ความสามารถของฐานข้อมูลแบบ transaction อยู่บนสิ่งนี้ด้วย Git ทำส่วนนี้ได้ดี ขณะเดียวกันก็อยากได้ index ที่รวดเร็วสำหรับบาง field ซึ่ง Git ไม่ถนัด เลยกำลังคิดว่าจะลองใช้ “มาตรฐาน” ที่ dump sqlite ลง Git transaction ใด ๆ ก็สามารถแทนด้วย Git commit ได้ และสามารถรันทั้งสองอย่างคู่กันเพื่อความทนทานและการทำ index ที่สมเหตุสมผล ฐานข้อมูล sqlite สามารถสร้างใหม่และ re-index ได้ทุกเมื่อ และก็พอเหมาะกับการใช้เป็น backup ด้วย
      ตอนนี้ยังรู้สึกเหมือนแค่หมุนล้ออยู่กับที่ และคงต้องคอยดูว่าฐานข้อมูลจะไปทางไหนต่อ
    • ถ้าเป็นเพื่อนร่วมงาน ผมคงเอาข้อมูลนี้ไปทำ network analysis ตามเวลา เพื่อดูจากการที่ผู้คนย้ายไปอยู่กลุ่มต่าง ๆ เมื่อเวลาผ่านไป ว่าพวกเขาชอบทำงานด้วยกันหรือไม่ชอบกัน

  • ผมสร้างเครื่องมือสำหรับติดตาม LDAP แบบนี้ไว้ [0] LDAP เป็นขุมทรัพย์ของข้อมูล และเหมาะกับการสอดส่องมาก
    การได้เห็นคนลาออก และถ้าเป็นไปได้ก็เห็นว่าทำงานมานานแค่ไหน มันน่าสนใจอย่างประหลาด ที่น่าสนใจไม่น้อยคือเพื่อน ๆ ได้เห็นจาก LDAP ก่อนที่เจ้าตัวจะรู้ด้วยซ้ำว่าถูกเลิกจ้าง ใน README ผมเขียนไว้ว่าเมื่อเชื่อมกับ Slack webhook ก็สามารถดูแบบ on-demand ได้ว่าเกิดอะไรขึ้นใน LDAP directory ตรวจดูพนักงานเข้าใหม่·พนักงานลาออก·การเลื่อนตำแหน่ง, HR ทำอะไรเมื่อไหร่, การเปลี่ยนแปลงที่ไม่ได้รับอนุญาต, ข้อมูลที่หลุดโดยไม่ตั้งใจ, และการ login·logout ของผู้ใช้ใน LDAP ได้ นอกจากนี้ยังมี LDAPmonitor[1] ที่ทำสิ่งเดียวกันแทบทั้งหมดสำหรับ Microsoft และ Active Directory
    [0]https://github.com/MegaManSec/LDAP-Monitoring-Watchdog
    [1]https://github.com/p0dalirius/LDAPmonitor

  • การเลิกจ้างในยุคทำงานจากที่บ้าน เป็นอะไรที่แปลก เมื่อก่อนแค่เห็นใครถือกล่องใส่ของเดินออกไป ก็พอรู้ได้ค่อนข้างดีว่าใครถูกเลิกจ้าง และยังเดินเข้าไปชวนไปเจอกันที่บาร์แถวบ้านหรือแลกช่องทางติดต่อกันได้
    อย่างน้อยก็ยังรู้สึกว่ามีการปิดฉากบางอย่าง แต่ตอนนี้อยู่ ๆ วันหนึ่งหลายคนก็เริ่มไม่ตอบอีเมล และต้องรอไปเรื่อย ๆ กว่าจะรู้ว่าพวกเขาออกไปจริง ๆ หรือแค่ยุ่งอยู่ ถ้าคุณกำลังรอ deliverable ที่จำเป็นต่อโปรเจกต์อยู่ มันอาจไม่มีวันมาถึง และคุณก็อาจไม่รู้เหตุผลไปอีกพักใหญ่ แม้จะมีไดเรกทอรีของบริษัท แต่เพราะ WARN Act คนจำนวนมากมักยังอยู่ในระบบเกิน 60 วัน และบริษัทส่วนใหญ่ดูเหมือนจะไม่ทำ “รายชื่อผู้ถูกเลิกจ้าง” ถ้าไม่บอกด้วยซ้ำว่าใครถูกเลิกจ้าง และตัดสิทธิ์การเข้าถึงก่อนแจ้งข่าว ทำให้ไม่มีโอกาสได้บอกลา ก็ยากมากที่จะรู้สึกว่าทุกอย่างปิดฉากลงแล้ว

    • การเห็นบัญชีของผู้คนใน Slack เปลี่ยนเป็น สถานะไม่ใช้งาน โดยไม่มีคำลา เป็นเรื่องเศร้า
      หัวหน้าที่แย่ที่สุดที่ฉันเคยเจอมักขอสิทธิ์เข้าถึงบัญชี Slack ของอดีตพนักงาน โดยอ้างว่าจะค้นหาข้อมูลส่งต่องานของคนที่ลาออกไป ทุกครั้งที่เขาล็อกอินเป็นพวกเขา บางครั้งบัญชีก็จะเปลี่ยนเป็นสีเขียว การเห็นบัญชีของอดีตเพื่อนร่วมงานกลายเป็นสีเขียว แล้วรู้ว่าหัวหน้ากำลังคุ้ยข้อความส่วนตัวอยู่ เป็นเรื่องน่าขนลุก ฉันรู้ว่าบริษัทสามารถดูข้อความ Slack ได้อยู่แล้ว แต่การเห็นหัวหน้าทำแบบนั้นแบบเรียลไทม์ยิ่งชวนขนลุกกว่า
    • ตอนแรกก็พยายามทำอยู่ แต่ช่วงต้นของการระบาด จำนวนผู้เสียชีวิต เพิ่มขึ้นเร็วเกินกว่าที่องค์กรจะประกาศได้ทัน
      แค่การที่ HR ต้องพยายามรวบรวมคำพูดสักไม่กี่คำให้ทุกคน ก็เป็นงานที่บั่นทอนขวัญกำลังใจแล้ว และในที่ที่เคยมีความใส่ใจส่วนตัวอันมีชีวิตชีวา ก็เหลือไว้เพียงความซีดจางที่คงอยู่นาน ผู้คนยังคงหายไปเรื่อย ๆ แต่ก็ยังไม่มีประกาศว่าเขาจากไปแล้ว หรือจากไปอย่างไร
      ฉันได้พบ General Counsel ครั้งสุดท้ายในช่วงต้นของการระบาด เช่นเดียวกับคนส่วนใหญ่ในช่วงล็อกดาวน์ เขาไม่ได้เจอใครเลยนอกจากครอบครัวใกล้ชิด และไม่มีโอกาสได้คุยเรื่องดี ๆ มาหลายเดือน ซึ่งถ้ามีก็อาจทำให้เขาเสียชีวิตอยู่ดี เขาพรั่งพรูงานที่กำลังปิดจบออกมา แล้วหลังจากนั้น ในแบบฉบับทนาย เขาเขียนจดหมายยอดเยี่ยมถึง CIO จนนำไปสู่บทสนทนาที่ฉันชอบที่สุดระหว่างเรา
      หกเดือนต่อมา มีคนโทรมาบอกว่ากำลังไปฝ่ายกฎหมายและมีใครบางคนเสียชีวิต ฉันรู้สึกไม่ดีทันที ค้นทั้งเว็บไซต์ ไดเรกทอรี และประกาศข่าวมรณกรรมในท้องถิ่นก็ไม่พบอะไร เครือข่ายข่าวลือก็เงียบสนิท ดังนั้นฉันจึงโทรหาเลขานุการของเขา และเธอก็บอกค่อนข้างเรียบ ๆ ว่า GC เสียชีวิตไปเมื่อ 6 สัปดาห์ก่อนแล้ว
      เกือบครบหนึ่งปีพอดี ขั้นตอนขององค์กรจึงตามมาทันและออก “Remembering $generalCounselor” ตอนนั้นเราพลาดงานศพไปแล้ว ครอบครัวย้ายออกไปแล้ว และหลายคนรู้สึกกระอักกระอ่วนที่จะส่งความเสียใจช้าเกินไป การได้เห็นความตกใจ ความละอาย และความเศร้าของคนอื่นไม่ได้ทำให้สบายใจขึ้น แต่ก็ทำให้รู้ว่าฉันไม่ได้เป็นแบบนั้นคนเดียว
      องค์กรของเราไม่ได้เล็ก แต่ก็มีความเป็นส่วนตัว และการตายแต่ละครั้งทิ้งช่องว่างเล็ก ๆ ที่เราไม่ได้ยอมรับหรือรับมือร่วมกันไว้ เรายังไม่มีวิธีจัดการกับความสูญเสีย และไม่เคยพูดถึงมันด้วยซ้ำ รายชื่อติดต่อเก่าที่บันทึกไว้เมื่อโผล่ขึ้นมาอีกครั้งหลังเบอร์ภายในถูกจัดสรรใหม่ ย่อมให้ความรู้สึกเหมือนสายโทรมาจากหลุมศพอย่างหลีกเลี่ยงไม่ได้ ฉันพยายามติดต่อและติดตามต่อไป แต่สายสัมพันธ์ก็ค่อย ๆ จางลง และความทรงจำกับประวัติศาสตร์ที่เรามีกับพวกเขาก็เลือนรางไปด้วย
    • สิ่งหนึ่งที่คิดถึงจากรูปแบบการทำงานในออฟฟิศคือ สายสัมพันธ์ที่เป็นมนุษย์มากกว่า
      เรื่องที่ผู้คนแวะมาที่โต๊ะ คุยเล่นเรื่องชีวิต และเล่นมุกกัน ฉันไม่เคยหัวเราะดังขนาดนั้นในชีวิต โดยรวมแล้วเป็นความสัมพันธ์ที่ใกล้ชิดกว่า และถึงจะเศร้าเมื่อผู้คนจากไป แต่ถ้าเขาไปสู่ที่ที่ดีกว่า ก็ยังดีใจให้ได้ เมื่อเทียบกันแล้ว การทำงานจากที่บ้านให้ความรู้สึกปลอดเชื้อและไร้ตัวตนเกินไป ฉันทำงานจากที่บ้านมาตั้งแต่ราวปี 2015 ดังนั้นนี่ไม่ใช่การสนับสนุนให้กลับเข้าออฟฟิศ แค่เป็นความทรงจำเท่านั้น
    • การตัดสิทธิ์เข้าถึงทำให้รู้สึกว่าโง่เสมอ และตอนเป็นผู้จัดการฉันก็ไม่ทำแบบนั้น
      ถ้าเราไว้ใจให้ทำงานด้วยกันมา 3 ปีแล้ว ก็ไว้ใจได้อีก 1–2 สัปดาห์ ให้เขาปิดงานที่เหลือและใช้เวลาได้ เราทุกคนเป็นผู้ใหญ่กันแล้ว เข้าใจว่าในกรณีเลวร้ายที่สุดอาจมีเรื่องไม่ดีเกิดขึ้นได้ แต่มันก็เป็นแบบนั้นได้เสมออยู่แล้ว
    • นี่อาจเป็นครั้งเดียวที่ฉันจะพูดแบบนี้ แต่ดีใจที่มี LinkedIn อย่างน้อยก็รู้ว่าสามารถติดต่อคนที่จากไปได้อีกเมื่อไรก็ได้

  • ส่วนนี้ชอบมาก:
    “อีกอย่าง ถ้ามีใครโกรธเพราะคุณรันอะไรแบบนี้ ก็มีโอกาสสูงอยู่แล้วว่าคุณคงไม่อยากทำงานที่นั่น ในทางกลับกัน ถ้า IT หรือองค์กรลักษณะใกล้เคียงกันไม่รู้สึกว่าเครื่องมือแบบนี้เป็น ‘ภัยคุกคาม’ และปล่อยให้สร้างได้ คุณอาจอยู่ในที่ที่ผู้คนสนุกกับการทำสิ่งที่น่าสนใจและมีประโยชน์จริง ๆ ที่แบบนั้นควรถนอมไว้ เพราะมักอยู่ได้ไม่นาน”

    • ถึงอย่างนั้น ถ้ายังอยากทำงานที่นั่น ก็ควรตรวจสอบ สถานะทางกฎหมาย ก่อน
      แทบจะแน่นอนว่าอาจเข้าข่ายการประมวลผลข้อมูลส่วนบุคคลโดยไม่ได้รับอนุญาต การมีสิทธิ์เข้าถึงไม่ได้หมายความว่าจะทำอะไรก็ได้ตามใจ โดยเฉพาะการเก็บถาวร การเก็บประวัติ และการเชื่อมโยงกับข้อมูลภายนอก ไม่ใช่การใช้งานตามเจตนาของอินเทอร์เฟซแบบนั้น หากนำข้อมูลกลับบ้านในรูปแบบอย่างแล็ปท็อปงาน ก็อาจกลายเป็นอีกปัญหาหนึ่ง และอาจถูกมองว่าเป็นการนำความลับทางการค้าออกไปด้วย
      อย่างน้อยในยุโรป การใช้ประโยชน์จากอินเทอร์เฟซแบบนั้นในทางที่ผิดมีแนวโน้มสูงว่าจะผิดกฎหมาย และยิ่งเป็นเช่นนั้นหากเก็บสำเนาหรือ diff ไว้ นายจ้างอาจจำเป็นต้องดำเนินการ และถ้าไม่ทำก็อาจต้องรับผิด หรือภายหลังอาจใช้การละเมิดนี้เป็นข้ออ้างเพื่อยุติสัญญาได้อย่างสะดวก โดยเฉพาะถ้าคุณใช้ข้อมูลนั้นเป็นเครื่องต่อรอง
      ยิ่งเครือข่ายใหญ่เท่าไร โอกาสเข้าไปพัวพันกับปัญหาก็ดูจะยิ่งมากขึ้น ในทางกลับกัน ถ้าไม่ใหญ่ ประโยชน์ของการรวบรวมข้อมูลก็ยิ่งน้อยลง ถ้าอย่างนั้น การรวมตัวกับเพื่อนร่วมงานเพื่อแบ่งปันข้อมูลการจ้างงานโดยสมัครใจและสร้างอำนาจต่อรองร่วมกัน จะไม่ดีกว่าหรือ?
    • สงสัยว่านี่ถือเป็น ข้อมูลส่วนบุคคล หรือเปล่า เพราะเป็นสำเนาชื่อ ตำแหน่งงาน และระยะเวลาจ้างงานของทุกคน
      บริษัทในยุโรปจำนวนมากน่าจะระมัดระวังเรื่องที่พนักงานเก็บรายการแบบนี้ไว้
    • Amazon ไล่คนที่แชร์ LDAP query สำหรับค้นหาว่าใครได้รับผลกระทบหลังมีการเลิกจ้างออก ทั้งที่ไม่ได้ทำข้อมูลรั่วไหลด้วยซ้ำ
    • ไม่ดีเลยสักนิด เป็นแค่การทำท่าแข็งกร้าวเกินจริงเท่านั้น
      วิธีตรวจสอบคือไปดูคอมเมนต์ HN ที่ทำท่าแบบเดียวกัน หลังจากกรอบ Overton กว้างขึ้นแล้ว ก็ไม่มีการยั้งอีกต่อไป และพูดสิ่งที่เรารู้กันตรง ๆ ว่านี่คือการใช้ระบบในทางที่ผิด เปลี่ยนสมุดรายชื่อเก่า ๆ ให้กลายเป็นแท็บลอยด์ซุบซิบที่แม้แต่เจ้าตัวก็ยังตกใจ
      ตัวอย่างเช่น “ตอนแรกสนใจแค่ว่าบัญชีไหนถูกปิดใช้งาน จากนั้นก็เริ่มติดตามการเปลี่ยนตำแหน่ง การเปลี่ยนนามสกุล (แต่งงาน) ขนาดแผนก จำนวนพนักงานบริษัทตามเวลา ฯลฯ”, “LDAP เต็มไปด้วยความลับ แทบทุกอย่างเข้าถึงได้แบบ anonymous น่าเหลือเชื่อ เคยจับได้ก่อนประกาศว่ามีการรวมทีม/แผนก และ mailing list ลับของโปรเจกต์ภายใน ถ้าดูสมาชิกก็ขุดได้ว่าเกิดอะไรขึ้น”, “เรื่องแปลก ๆ จำนวนมากอาศัยการที่ LDAP tree เข้าถึงได้กว้าง เพียงแต่ข้อมูลรั่วมากกว่าที่คนส่วนใหญ่คิด”, “เฝ้าดูว่า HR ทำอะไรเมื่อไร และตรวจจับเวลาที่ผู้ใช้ login/logout ใน LDAP” อะไรทำนองนี้

  • LDAP เต็มไปด้วยความลับ เป็นวิธีที่ยอดเยี่ยมในการสอดส่องว่าเกิดอะไรขึ้นในบริษัท และน่าทึ่งด้วยที่แทบทุกอย่างเข้าถึงได้แบบ anonymous
    เคยจับได้ก่อนประกาศว่ามีการรวมทีมหรือแผนก mailing list ลับของโปรเจกต์ภายในก็ดูสมาชิกแล้วขุดได้ว่าเกิดอะไรขึ้น ถ้าอีเมลเผยอะไรบางอย่างออกมาก็ยิ่งดี ldapsearch ใช้ดีถ้าคุณรู้จัก LDAP ดีอยู่แล้ว และถ้าแค่อยากสำรวจ Apache LDAP Studio ก็เป็นเครื่องมือ UI ที่ยอดเยี่ยม ทุกคนควรรู้พอจะสร้างบริการล็อกอินที่ bind กับ LDAP สำหรับแอปภายในได้ คุณสามารถใช้กลุ่มที่ผู้ดูแลระบบดูแลอยู่เพื่อควบคุมสิทธิ์ของแอปได้ มันทรงพลังมากและเริ่มใช้งานได้ง่ายรวดเร็ว

    • ยังแปลกใจอยู่เลยเวลาเห็นบริษัทที่ยอมให้ผู้ใช้สุ่ม ๆ หรือแม้แต่ผู้ใช้ anonymous ทำดัชนี AD tree ทั้งหมด ของบริษัทได้
      ก็ใจดีอยู่หรอก แต่ก็ยังไงอยู่ดี และบ่อยครั้งมันเป็นวิธีเดียวที่จะได้ข้อมูลที่ไม่มีในหน้าอินทราเน็ต เช่น ใน IT มีทีมอะไรอยู่จริง ๆ บ้าง ออฟฟิศอยู่ที่ไหน ผู้จัดการของใครเป็นใคร และแน่นอนว่าฉันตกหล่นจาก distribution list ไหนที่ทำให้มีปัญหาการเข้าถึงพอร์ทัลภายใน ขณะที่ผู้ใช้อื่นอยู่ในลิสต์นั้น
    • จะใช้กลุ่ม LDAP สำหรับยืนยันตัวตนแอปภายในเหรอ? ถ้าอยากเป็น SolarWinds รายต่อไปก็เชิญ

  • น่าทึ่งที่หลายคนคิดไอเดียเดียวกันได้เองโดยอิสระ ที่ทำงานเก่าผมเคยสร้าง “the sackinator”
    sacked แปลว่าถูกไล่ออก มันเป็น cron job ที่ dump ไดเรกทอรี AD ทั้งหมดทุกคืน และมีสคริปต์สำหรับ diff เอาต์พุตของสองวันใดก็ได้ เพราะข้อมูลถูก dump ไว้แล้ว จึงย้อนกลับไปวิเคราะห์เพิ่มเติมได้ตลอด ตอนแรกดูแค่ว่าบัญชีไหนถูกปิดใช้งาน ต่อมาก็เริ่มติดตามการเปลี่ยนตำแหน่ง การเปลี่ยนนามสกุล (แต่งงาน) ขนาดแผนก จำนวนพนักงานบริษัทตามเวลา ฯลฯ ผมเห็นด้วยสุด ๆ กับคำพูดที่ว่าที่ไหนที่คุณสร้างเครื่องมือแบบนี้ได้และ IT ไม่รู้สึกถูกคุกคาม ที่นั่นควรถนอมไว้

  • ฮ่า ๆ ๆ มีสคริปต์ที่คล้ายกันมากซึ่งดูแลโดย ‘KTMJ’ จุดประสงค์ไม่ใช่เพื่อหาผู้ใช้ที่ปิดใช้งานแล้ว แต่เพื่อซิงก์ LDAP attribute บางตัวไปยังระบบอื่น
    องค์กรนี้ใหญ่พอสมควร มีผู้ใช้มากกว่า 300,000 คน แม้ในช่วงเวลาสั้น ๆ ระหว่างที่สคริปต์ query LDAP และเตรียมไฟล์ซิงก์ กับตอนที่การนำเข้าซิงก์จริงตรวจสอบว่าผู้ใช้แต่ละคนยังมีอยู่หรือไม่ ก็มีบัญชีหลายร้อยบัญชีถูกปิดใช้งานไปแล้วและถูกบันทึกในไฟล์ log ‘error’ การซิงก์จริงและไฟล์ log ‘error’ อยู่นอกเหนือการควบคุมโดยตรงของผม
    เหตุผลที่หัวเราะแทบบ้าคือ สัญญาของผมกำลังจะสิ้นสุดเพราะ ‘ข้อจำกัดด้านงบประมาณ’ เจอการเลิกจ้างมาหลายรอบแล้ว เลยคาดไว้อยู่ บัญชีของผมเองก็คงเป็นหนึ่งในบัญชีที่จะถูกปิดใช้งานในรอบรายเดือนถัดไป แต่ก่อนหน้านั้นผมต้องส่งมอบขั้นตอนการประมวลผลและพฤติกรรมการ log ‘error’ สำหรับผู้ใช้ที่ถูกปิดใช้งานตามที่คาดไว้ให้คนที่มารับช่วงต่อ

  • ไม่จำเป็นต้องมองในแง่ลบเกินไป ที่ที่ผมทำงานเรียกเครื่องมือนี้ว่า “new-hires”
    ใช้ API key แบบอ่านอย่างเดียวที่มีสิทธิ์จำกัดสำหรับเครื่องมือ HR ของบุคคลที่สาม และ key นั้น People Director เป็นคนให้ผมมา บางครั้งก็มีบรรทัดที่ขึ้นต้นด้วย - แต่ชื่อเครื่องมือมาจากบรรทัดที่ขึ้นต้นด้วย +
    new-hires สร้างอยู่บนโมดูล/CLI Python “people” ใน monorepo ของเรา เครื่องมือนี้มีประโยชน์กว่า diff ผังองค์กรมาก มันบอกได้ว่าใครอยู่ทีมไหน อยู่ที่ไหน วันนี้ทำงานไหม ถึงเวลาฉลองวันครบรอบการทำงานหรือยัง ฯลฯ และยังทำตาม “ZFS litmus test” ที่ผมสร้างไว้สำหรับเครื่องมือ CLI ที่ดีด้วย คือมี -pH สำหรับเอาต์พุตที่ parse ได้และไม่มี header ที่แบบนี้ควรค่าแก่การถนอมจริง ๆ

    • ที่ไหนครับ? ฟังดูเป็นที่ที่ดีมากเลย

  • ที่ทำงานแรกผมเคยพยายามสร้างระบบแบบนี้ แต่ผู้จัดการได้ยินแล้วสั่งห้ามอย่างชัดเจน
    ต่อมาบริษัทนั้นเลิกจ้าง 15% ของวิศวกรซอฟต์แวร์ภายในวันเดียว ทีมซัพพอร์ตสร้าง ticket สำหรับยกเลิกบัญชีพนักงานในตัวติดตาม issue สาธารณะ ทำให้หลายคนรู้เรื่องจากช่องทางนั้นก่อนที่จะได้รับการติดต่อเรื่องประชุม