Bài blog có nói rằng “cần một người khác biết bạn thêm vào”, nhưng điều đó không chính xác hoặc giờ không còn đúng nữa
Nhân viên có thể gửi nội dung qua email đến một địa chỉ đặc biệt, và nội dung đó có thể được hiển thị khi họ rời công ty. Tôi đã làm như vậy, nhưng không thể kiểm tra lại xem nó có hoạt động đúng hay không
Cho hỏi đó là công ty nào được không?
Nó vẫn còn hoạt động chứ?
HR có từng yêu cầu thay đổi nó không? Tôi nghỉ việc từ 5 năm trước, nhưng thực sự rất thích tính năng đó
Vì sao bạn tạo ra epitaphs? Trong quá trình làm có gặp khó khăn thú vị nào về mặt tổ chức hoặc kỹ thuật không?
Nếu muốn vận hành kiểu này, tôi cực kỳ khuyến nghị dùng Git
Có thể chạy từ cron như sau: curl https://internal.corp/employees.txt > employees.txt git add employees.txt git commit -m "Automated: $(date -u)" || exit 0 || exit 0 giúp không báo lỗi nếu không có gì để commit. Giờ thì toàn bộ lịch sử thay đổi của nguồn dữ liệu sẽ được lưu thành commit, và chỉ cần chạy git log là xem được. Tôi thường làm việc này bằng GitHub Actions theo lịch, ví dụ ở https://simonwillison.net/2020/Oct/9/git-scraping/
Tôi làm tương tự nhưng thay vì || exit 0 thì dùng --allow-empty cho git commit
Có thêm commit rỗng cũng không sao, vì như vậy biết được lần chạy tự động đó không phải bị lỗi, mà là đã chạy thành công nhưng không có thay đổi
Có lẽ cũng nên thêm | sort để đảm bảo tính quyết định. Với loại dữ liệu nhỏ này, Git là một cơ sở dữ liệu bị đánh giá thấp
Tôi cũng bắt đầu tạo một kho lưu trữ có thể diff được cho bản tin thời sự ngôn ngữ đơn giản của Phần Lan bằng chính kỹ thuật này
Nó đã giúp ích rất nhiều trong việc thu thập đầu vào chất lượng cao, dễ hiểu. Xin cảm ơn https://github.com/hiAndrewQuinn/selkouutiset-scrape/
Tôi đang nghiêm túc cân nhắc dùng Git cho các loại dữ liệu thường xuyên thay đổi nhưng không thay đổi quá lớn nói chung. Ví dụ như danh sách sách trên giá sách
Tuy vậy, tôi cũng muốn có các tính năng cơ sở dữ liệu giao dịch bên trên kiểu dữ liệu này. Git làm tốt phần đó. Đồng thời tôi cũng muốn có khả năng lập chỉ mục nhanh cho một số trường, nhưng Git lại không làm tốt chuyện ấy. Vì vậy tôi đang nghĩ tới việc dùng một “chuẩn” dump sqlite vào Git. Bất kỳ giao dịch nào cũng có thể được biểu diễn thành một commit Git, và có thể chạy cả hai song song để có độ bền dữ liệu cùng khả năng lập chỉ mục hợp lý. Cơ sở dữ liệu sqlite có thể được tái tạo và lập chỉ mục lại bất cứ lúc nào, đồng thời cũng khá phù hợp cho mục đích sao lưu.
Hiện tại tôi vẫn có cảm giác như đang quay bánh xe tại chỗ, nên sẽ tiếp tục theo dõi xem cơ sở dữ liệu rồi sẽ đi về đâu
Nếu là đồng nghiệp của tôi, hẳn tôi sẽ dùng dữ liệu này để làm phân tích mạng lưới theo thời gian, xem mọi người chuyển giữa các nhóm như thế nào theo thời gian, từ đó suy ra họ có thích làm việc cùng nhau hay không, hoặc là ghét nhau
Tôi đã làm một công cụ để theo dõi LDAP theo kiểu này [0]. LDAP là kho báu thông tin, và cũng rất hợp để theo dõi người khác
Việc thấy mọi người rời đi, và nếu có thể thì xem họ đã làm việc bao lâu, bằng cách nào đó lại khá thú vị. Cũng khá thú vị khi bạn bè thấy trên LDAP rằng họ bị sa thải trước cả khi chính họ biết điều đó. README nói rằng với tích hợp webhook Slack, bạn có thể nắm bắt theo yêu cầu những gì đang diễn ra trong thư mục LDAP, giám sát nhân viên mới, người rời đi, thăng chức, HR làm gì và khi nào, các thay đổi trái phép, dữ liệu vô tình bị lộ, cũng như đăng nhập và đăng xuất LDAP của người dùng. Cũng có LDAPmonitor[1] làm gần như y hệt cho Microsoft và Active Directory
[0]https://github.com/MegaManSec/LDAP-Monitoring-Watchdog
[1]https://github.com/p0dalirius/LDAPmonitor
Việc sa thải trong thời đại làm việc từ xa thật kỳ lạ. Ngày trước, chỉ cần nhìn ai đó ôm thùng đồ rời đi là có thể biết khá rõ ai đã bị sa thải, rồi còn có thể lại gần rủ họ gặp ở quán bar gần đó hoặc trao đổi thông tin liên lạc.
Cũng có được một cảm giác khép lại ở mức nào đó. Giờ thì đến một ngày nào đó, nhiều người bắt đầu không trả lời email nữa, và phải chờ mới biết là họ thực sự đã rời đi hay chỉ đang bận. Nếu đang chờ đầu ra cần cho dự án thì có khi sẽ chẳng bao giờ đến, và trong một thời gian dài cũng không biết lý do. Dù có danh bạ công ty, nhiều trường hợp vẫn còn đó hơn 60 ngày vì WARN Act, và có vẻ hầu hết các công ty không tạo “danh sách người bị sa thải”. Họ không nói ai đã bị sa thải, và nếu còn cắt quyền truy cập trước khi thông báo việc sa thải để người ta không có cơ hội nói lời tạm biệt, thì thực sự rất khó có được cảm giác khép lại
Thấy tài khoản của mọi người trên Slack chuyển sang không hoạt động mà không có cả lời chào tạm biệt thì thật buồn
Người sếp tệ nhất tôi từng gặp thường yêu cầu quyền truy cập tài khoản Slack của toàn bộ nhân viên cũ với lý do tìm dữ liệu bàn giao công việc của người nghỉ việc. Mỗi lần ông ta đăng nhập bằng tài khoản của họ, tài khoản đó thỉnh thoảng lại chuyển sang màu xanh. Nhìn tài khoản của đồng nghiệp cũ bật xanh và biết rằng sếp đang lục tin nhắn riêng của họ thật rợn người. Tôi biết công ty đằng nào cũng có thể xem tin nhắn Slack, nhưng nhìn thấy sếp làm vậy theo thời gian thực còn đáng sợ hơn nhiều
Ban đầu họ cũng định làm, nhưng đầu thời kỳ đại dịch thì số người qua đời tăng quá nhanh đến mức tổ chức không thể cứ tiếp tục thông báo mãi
Bản thân việc HR cố gắng gom vài lời cho mọi người đã là chuyện làm suy sụp tinh thần, và ở chỗ từng có sự chạm tới cá nhân đầy sinh khí giờ chỉ còn lại một vẻ nhợt nhạt kéo dài. Mọi người cứ tiếp tục biến mất, nhưng vẫn không có thông báo rằng họ đã rời đi hay rời đi bằng cách nào.
Lần cuối tôi gặp General Counsel là vào đầu đại dịch. Giống như phần lớn mọi người trong thời kỳ phong tỏa, ông ấy không gặp ai ngoài gia đình trực hệ, cũng không có cơ hội để kể một câu chuyện vui nào trong nhiều tháng, mà nếu có thì có lẽ rồi nó cũng giết ông ấy thôi. Ông ấy trút ra những việc còn đang hoàn tất, rồi đúng kiểu một luật sư, đã viết cho CIO một lá thư rất hay, dẫn đến cuộc trò chuyện mà chúng tôi thích nhất với nhau.
Sáu tháng sau, có người gọi nói đang trên đường đến bộ phận pháp lý và có ai đó đã qua đời, và tôi lập tức có linh cảm xấu. Tôi lục trang web, danh bạ và cáo phó địa phương nhưng không thấy gì, mạng lưới tin đồn cũng im ắng. Thế là tôi gọi cho thư ký của ông ấy, và cô ấy khá điềm nhiên nói rằng GC đã qua đời từ 6 tuần trước.
Phải gần đúng 1 năm sau thì quy trình của tổ chức mới theo kịp và mới đăng “Remembering $generalCounselor”. Đến lúc đó tôi đã lỡ tang lễ, gia đình đã chuyển nhà, và nhiều người cảm thấy ngượng ngập khi gửi lời chia buồn quá muộn. Nhìn sự ngạc nhiên, xấu hổ và buồn bã của những người khác không phải là điều an ủi, nhưng ít ra tôi biết không chỉ mình tôi như vậy.
Chúng tôi không phải là một tổ chức nhỏ, nhưng vẫn mang tính cá nhân, và mỗi cái chết đều để lại một khoảng trống nhỏ mà chúng tôi đã không thể cùng nhau thừa nhận hay đối diện. Đến giờ chúng tôi vẫn không có cách xử lý mất mát và cũng chưa từng nói về điều đó. Những liên hệ cũ đã lưu sẵn lâu ngày lại hiện lên sau khi máy lẻ được phân lại, không tránh khỏi khiến nó giống như một cuộc gọi từ nấm mồ. Tôi vẫn cố giữ liên lạc và lần theo mọi người, nhưng từng chút một các kết nối mờ dần, và ký ức cũng như lịch sử của chúng tôi với họ cũng phai đi theo
Một điều tôi nhớ ở kiểu làm việc tại văn phòng là sự kết nối mang tính con người hơn
Mọi người ghé qua bàn nhau để tán gẫu về cuộc sống và đùa vui. Tôi chưa từng cười nhiều đến thế trong đời. Nhìn chung các mối quan hệ gần gũi hơn, và khi mọi người rời đi thì thấy buồn, nhưng nếu họ đến một nơi tốt hơn thì cũng thấy vui cho họ. So với vậy, làm việc từ xa tạo cảm giác quá vô trùng và phi cá nhân. Tôi đã làm việc từ xa từ khoảng năm 2015, nên đây không phải là ủng hộ quay lại văn phòng, chỉ là hoài niệm thôi
Tôi luôn thấy việc cắt quyền truy cập là ngu ngốc, và khi làm quản lý tôi đã không làm vậy
Nếu đã tin tưởng và làm việc cùng nhau 3 năm, thì có thể tin thêm 1~2 tuần nữa. Họ có thể hoàn tất những việc còn lại rồi dành thời gian cho mình. Chúng ta đều là người trưởng thành. Tôi hiểu rằng trong tình huống xấu nhất có thể xảy ra chuyện tồi tệ, nhưng điều đó thì lúc nào cũng vậy
Có lẽ đây là lúc duy nhất để nói điều này, nhưng tôi biết ơn vì có LinkedIn. Ít nhất cũng biết rằng mình luôn có thể liên lạc lại với những người đã rời đi bất cứ lúc nào
Phần này khá hay:
“Nói thêm, nếu ai đó nổi giận vì bạn chạy thứ này thì có lẽ dù sao bạn cũng không muốn làm ở đó. Ngược lại, nếu một bộ phận IT hay tổ chức tương tự có thể tạo ra công cụ kiểu này mà không cảm thấy bị ‘đe dọa’, thì có thể bạn đang ở một nơi thực sự thích tạo ra những thứ thú vị và hữu ích. Nên trân trọng những nơi như vậy. Chúng thường không tồn tại được lâu”
Dù vậy, nếu bạn vẫn muốn làm ở đó thì tốt nhất nên kiểm tra tình hình pháp lý trước
Gần như chắc chắn chuyện này có thể bị xem là xử lý dữ liệu cá nhân trái phép. Có quyền truy cập không có nghĩa là muốn làm gì thì làm. Đặc biệt là lưu trữ, giữ lịch sử, hay liên kết với dữ liệu bên ngoài đều không phải là mục đích sử dụng dự kiến của các giao diện đó. Nếu bạn mang thông tin về nhà dưới dạng như trên laptop công việc thì còn có thể phát sinh vấn đề khác, thậm chí bị xem là mang bí mật kinh doanh ra ngoài.
Ít nhất ở châu Âu, việc lạm dụng các giao diện như vậy nhiều khả năng là bất hợp pháp, và nếu còn giữ bản sao hay diff thì lại càng như vậy. Người sử dụng lao động có thể phải hành động, nếu không họ cũng có thể phải chịu trách nhiệm. Hoặc sau này họ có thể vin vào vi phạm này để chấm dứt hợp đồng cho tiện. Nhất là nếu bạn dùng thông tin đó làm đòn bẩy thì càng dễ xảy ra.
Mạng lưới càng lớn thì dường như khả năng dính rắc rối cũng càng cao. Ngược lại, nếu không lớn thì giá trị của việc thu thập dữ liệu cũng thấp. Hay là thay vào đó nên cùng đồng nghiệp tổ chức lại, tự nguyện chia sẻ thông tin việc làm và có được sức mạnh đàm phán tập thể?
Tôi tự hỏi liệu chuyện này có được xem là dữ liệu cá nhân hay không. Vì đây là bản sao tên, chức danh và thời gian làm việc của mọi người
Nhiều công ty châu Âu có lẽ sẽ rất dè chừng việc nhân viên giữ một danh sách như vậy
Amazon đã sa thải người chia sẻ truy vấn LDAP để tìm những người bị ảnh hưởng sau khi đợt sa thải diễn ra. Họ làm vậy dù thông tin đó không hề bị rò rỉ ra ngoài
Hoàn toàn không tốt chút nào. Chỉ là kiểu ra vẻ quá mức thôi
Cách để kiểm tra là tìm các bình luận HN cũng lên giọng theo kiểu tương tự. Sau khi cửa sổ Overton đã mở rộng, người ta không còn tự kiềm chế nữa mà nói thẳng ra điều chúng ta đều biết: đây là lạm dụng hệ thống để biến một cuốn sổ địa chỉ cũ thành tờ lá cải nhiều chuyện khiến chính người trong cuộc cũng phải giật mình.
Ví dụ như: “Lúc đầu tôi chỉ quan tâm tài khoản nào bị vô hiệu hóa. Rồi sau đó bắt đầu theo dõi thay đổi chức danh, đổi họ (kết hôn), quy mô phòng ban, số lượng nhân sự công ty theo thời gian”, “LDAP đầy bí mật. Thật ngạc nhiên khi gần như mọi thứ đều có thể lấy được qua truy cập ẩn danh. Tôi từng phát hiện việc sáp nhập nhóm/phòng ban trước khi công bố, và từ danh sách thành viên của các mailing list bí mật cho dự án nội bộ cũng có thể moi ra đang có chuyện gì”, “Rất nhiều thứ kỳ lạ phụ thuộc vào việc cây LDAP có thể truy cập rộng rãi. Chỉ là nó làm rò rỉ nhiều thông tin hơn hầu hết mọi người nghĩ”, “Theo dõi HR làm gì và khi nào, phát hiện thời điểm người dùng đăng nhập/đăng xuất LDAP”
LDAP đầy bí mật. Đây là cách tuyệt vời để quan sát chuyện gì đang diễn ra trong công ty, và còn đáng ngạc nhiên hơn ở chỗ gần như mọi thứ đều có thể lấy được bằng truy cập ẩn danh
Tôi từng phát hiện việc sáp nhập nhóm hoặc phòng ban trước khi công bố. Với các mailing list bí mật cho dự án nội bộ, chỉ cần nhìn thành viên cũng có thể moi ra đang có chuyện gì. Nếu địa chỉ email để lộ thêm vài thứ thì càng lời. ldapsearch rất hữu ích nếu bạn hiểu rõ LDAP, còn nếu chỉ muốn khám phá thì Apache LDAP Studio là một công cụ UI rất tốt. Ai cũng nên biết đủ để tạo một dịch vụ đăng nhập bind vào LDAP cho ứng dụng nội bộ. Bạn có thể dùng các nhóm do quản trị viên hệ thống duy trì để kiểm soát quyền của ứng dụng; nó rất mạnh và dễ bắt đầu nhanh
Tôi vẫn ngạc nhiên khi thấy có công ty cho phép người dùng ngẫu nhiên, thậm chí cả người dùng ẩn danh, lập chỉ mục toàn bộ cây AD của công ty
Dù là thiện ý thì vẫn hơi quá. Mặt khác, đó cũng thường là cách duy nhất để có được thông tin không có trên các trang intranet. Ví dụ như thực tế IT có những nhóm nào, các văn phòng ở đâu, ai là quản lý của ai, và dĩ nhiên là tôi đang bị thiếu khỏi danh sách phân phối nào trong khi người khác lại có, thứ đang gây ra vấn đề truy cập cổng nội bộ
Dùng nhóm LDAP để xác thực cho ứng dụng nội bộ à? Nếu muốn trở thành SolarWinds tiếp theo thì cứ thế thôi
Thật đáng ngạc nhiên khi nhiều người đã độc lập đi đến cùng một ý tưởng. Ở chỗ làm cũ tôi đã tạo ra “the sackinator”
sacked nghĩa là bị sa thải. Đó là một cron job dump toàn bộ thư mục AD mỗi đêm, cùng với một script diff đầu ra của hai ngày bất kỳ. Vì dữ liệu đã được dump sẵn nên lúc nào cũng có thể quay lại để phân tích thêm. Ban đầu tôi chỉ xem tài khoản nào bị vô hiệu hóa, nhưng sau đó còn bắt đầu theo dõi thay đổi chức danh, đổi họ (kết hôn), quy mô phòng ban, số lượng nhân sự công ty theo thời gian. Tôi hoàn toàn đồng ý rằng những nơi cho phép làm ra công cụ như vậy mà IT không cảm thấy bị đe dọa là những nơi đáng được trân trọng
Ha ha ha. Có một script rất giống như vậy được quản lý ở ‘KTMJ’. Mục đích của nó không phải để tìm người dùng bị vô hiệu hóa, mà để đồng bộ một thuộc tính LDAP cụ thể sang hệ thống khác
Tổ chức này đủ lớn, có hơn 300.000 người dùng. Trong khoảng thời gian ngắn từ lúc script truy vấn LDAP và chuẩn bị file đồng bộ đến lúc chạy phần import đồng bộ thực tế để xác minh từng người dùng còn tồn tại hay không, đã có hàng trăm tài khoản bị vô hiệu hóa và bị ghi vào file log ‘error’. Việc đồng bộ thực tế và file log ‘error’ nằm ngoài sự kiểm soát trực tiếp của tôi.
Lý do tôi cười như điên là vì hợp đồng của tôi sắp bị chấm dứt do ‘hạn chế ngân sách’. Tôi đã trải qua nhiều đợt sa thải nên cũng đoán trước được. Tài khoản của tôi rồi cũng sẽ là một trong những tài khoản bị vô hiệu hóa ở chu kỳ hàng tháng tiếp theo, nhưng trước đó tôi vẫn phải bàn giao cho người kế nhiệm quy trình xử lý và cách hoạt động dự kiến của việc ghi log ‘error’ cho người dùng bị vô hiệu hóa
Không cần nhìn quá tiêu cực. Ở chỗ tôi làm, công cụ này được gọi là “new-hires”
Nó dùng API key chỉ đọc, phạm vi hạn chế, cho một công cụ HR của bên thứ ba, và People Director đã đưa key đó cho tôi. Thỉnh thoảng cũng có dòng bắt đầu bằng -, nhưng tên công cụ được lấy từ các dòng bắt đầu bằng +.
new-hires được xây trên mô-đun/CLI Python “people” trong monorepo của chúng tôi. Công cụ này hữu ích hơn rất nhiều so với việc diff sơ đồ tổ chức. Nó cho biết ai đang ở đội nào, ở đâu, hôm nay có đi làm không, đã đến lúc chúc mừng kỷ niệm làm việc chưa, v.v. Nó cũng tuân theo “phép thử quỳ tím ZFS” do tôi đặt ra cho các công cụ CLI tốt, tức là cung cấp -pH để có đầu ra không tiêu đề và có thể parse được. Những nơi như vậy thực sự đáng trân trọng
Ở đâu vậy? Nghe như một nơi thật sự rất ổn
Ở công việc đầu tiên, tôi từng định xây một hệ thống như thế này, nhưng quản lý nghe xong và cấm thẳng
Sau đó công ty đó đã sa thải 15% kỹ sư phần mềm chỉ trong một ngày. Đội hỗ trợ tạo ticket hủy tài khoản nhân viên trên hệ thống theo dõi issue công khai, nên nhiều người biết tin theo cách đó trước cả khi nhận được thư mời họp
1 bình luận
Ý kiến trên Hacker News
Tôi là người tạo ra epitaphs. Cứ hỏi gì cũng được
Nhân viên có thể gửi nội dung qua email đến một địa chỉ đặc biệt, và nội dung đó có thể được hiển thị khi họ rời công ty. Tôi đã làm như vậy, nhưng không thể kiểm tra lại xem nó có hoạt động đúng hay không
HR có từng yêu cầu thay đổi nó không? Tôi nghỉ việc từ 5 năm trước, nhưng thực sự rất thích tính năng đó
Nếu muốn vận hành kiểu này, tôi cực kỳ khuyến nghị dùng Git
Có thể chạy từ cron như sau:
curl https://internal.corp/employees.txt > employees.txtgit add employees.txtgit commit -m "Automated: $(date -u)" || exit 0|| exit 0giúp không báo lỗi nếu không có gì để commit. Giờ thì toàn bộ lịch sử thay đổi của nguồn dữ liệu sẽ được lưu thành commit, và chỉ cần chạygit loglà xem được. Tôi thường làm việc này bằng GitHub Actions theo lịch, ví dụ ở https://simonwillison.net/2020/Oct/9/git-scraping/|| exit 0thì dùng--allow-emptychogit commitCó thêm commit rỗng cũng không sao, vì như vậy biết được lần chạy tự động đó không phải bị lỗi, mà là đã chạy thành công nhưng không có thay đổi
| sortđể đảm bảo tính quyết định. Với loại dữ liệu nhỏ này, Git là một cơ sở dữ liệu bị đánh giá thấpNó đã giúp ích rất nhiều trong việc thu thập đầu vào chất lượng cao, dễ hiểu. Xin cảm ơn
https://github.com/hiAndrewQuinn/selkouutiset-scrape/
Tuy vậy, tôi cũng muốn có các tính năng cơ sở dữ liệu giao dịch bên trên kiểu dữ liệu này. Git làm tốt phần đó. Đồng thời tôi cũng muốn có khả năng lập chỉ mục nhanh cho một số trường, nhưng Git lại không làm tốt chuyện ấy. Vì vậy tôi đang nghĩ tới việc dùng một “chuẩn” dump sqlite vào Git. Bất kỳ giao dịch nào cũng có thể được biểu diễn thành một commit Git, và có thể chạy cả hai song song để có độ bền dữ liệu cùng khả năng lập chỉ mục hợp lý. Cơ sở dữ liệu sqlite có thể được tái tạo và lập chỉ mục lại bất cứ lúc nào, đồng thời cũng khá phù hợp cho mục đích sao lưu.
Hiện tại tôi vẫn có cảm giác như đang quay bánh xe tại chỗ, nên sẽ tiếp tục theo dõi xem cơ sở dữ liệu rồi sẽ đi về đâu
Tôi đã làm một công cụ để theo dõi LDAP theo kiểu này [0]. LDAP là kho báu thông tin, và cũng rất hợp để theo dõi người khác
Việc thấy mọi người rời đi, và nếu có thể thì xem họ đã làm việc bao lâu, bằng cách nào đó lại khá thú vị. Cũng khá thú vị khi bạn bè thấy trên LDAP rằng họ bị sa thải trước cả khi chính họ biết điều đó. README nói rằng với tích hợp webhook Slack, bạn có thể nắm bắt theo yêu cầu những gì đang diễn ra trong thư mục LDAP, giám sát nhân viên mới, người rời đi, thăng chức, HR làm gì và khi nào, các thay đổi trái phép, dữ liệu vô tình bị lộ, cũng như đăng nhập và đăng xuất LDAP của người dùng. Cũng có LDAPmonitor[1] làm gần như y hệt cho Microsoft và Active Directory
[0]https://github.com/MegaManSec/LDAP-Monitoring-Watchdog
[1]https://github.com/p0dalirius/LDAPmonitor
Việc sa thải trong thời đại làm việc từ xa thật kỳ lạ. Ngày trước, chỉ cần nhìn ai đó ôm thùng đồ rời đi là có thể biết khá rõ ai đã bị sa thải, rồi còn có thể lại gần rủ họ gặp ở quán bar gần đó hoặc trao đổi thông tin liên lạc.
Cũng có được một cảm giác khép lại ở mức nào đó. Giờ thì đến một ngày nào đó, nhiều người bắt đầu không trả lời email nữa, và phải chờ mới biết là họ thực sự đã rời đi hay chỉ đang bận. Nếu đang chờ đầu ra cần cho dự án thì có khi sẽ chẳng bao giờ đến, và trong một thời gian dài cũng không biết lý do. Dù có danh bạ công ty, nhiều trường hợp vẫn còn đó hơn 60 ngày vì WARN Act, và có vẻ hầu hết các công ty không tạo “danh sách người bị sa thải”. Họ không nói ai đã bị sa thải, và nếu còn cắt quyền truy cập trước khi thông báo việc sa thải để người ta không có cơ hội nói lời tạm biệt, thì thực sự rất khó có được cảm giác khép lại
Người sếp tệ nhất tôi từng gặp thường yêu cầu quyền truy cập tài khoản Slack của toàn bộ nhân viên cũ với lý do tìm dữ liệu bàn giao công việc của người nghỉ việc. Mỗi lần ông ta đăng nhập bằng tài khoản của họ, tài khoản đó thỉnh thoảng lại chuyển sang màu xanh. Nhìn tài khoản của đồng nghiệp cũ bật xanh và biết rằng sếp đang lục tin nhắn riêng của họ thật rợn người. Tôi biết công ty đằng nào cũng có thể xem tin nhắn Slack, nhưng nhìn thấy sếp làm vậy theo thời gian thực còn đáng sợ hơn nhiều
Bản thân việc HR cố gắng gom vài lời cho mọi người đã là chuyện làm suy sụp tinh thần, và ở chỗ từng có sự chạm tới cá nhân đầy sinh khí giờ chỉ còn lại một vẻ nhợt nhạt kéo dài. Mọi người cứ tiếp tục biến mất, nhưng vẫn không có thông báo rằng họ đã rời đi hay rời đi bằng cách nào.
Lần cuối tôi gặp General Counsel là vào đầu đại dịch. Giống như phần lớn mọi người trong thời kỳ phong tỏa, ông ấy không gặp ai ngoài gia đình trực hệ, cũng không có cơ hội để kể một câu chuyện vui nào trong nhiều tháng, mà nếu có thì có lẽ rồi nó cũng giết ông ấy thôi. Ông ấy trút ra những việc còn đang hoàn tất, rồi đúng kiểu một luật sư, đã viết cho CIO một lá thư rất hay, dẫn đến cuộc trò chuyện mà chúng tôi thích nhất với nhau.
Sáu tháng sau, có người gọi nói đang trên đường đến bộ phận pháp lý và có ai đó đã qua đời, và tôi lập tức có linh cảm xấu. Tôi lục trang web, danh bạ và cáo phó địa phương nhưng không thấy gì, mạng lưới tin đồn cũng im ắng. Thế là tôi gọi cho thư ký của ông ấy, và cô ấy khá điềm nhiên nói rằng GC đã qua đời từ 6 tuần trước.
Phải gần đúng 1 năm sau thì quy trình của tổ chức mới theo kịp và mới đăng “Remembering $generalCounselor”. Đến lúc đó tôi đã lỡ tang lễ, gia đình đã chuyển nhà, và nhiều người cảm thấy ngượng ngập khi gửi lời chia buồn quá muộn. Nhìn sự ngạc nhiên, xấu hổ và buồn bã của những người khác không phải là điều an ủi, nhưng ít ra tôi biết không chỉ mình tôi như vậy.
Chúng tôi không phải là một tổ chức nhỏ, nhưng vẫn mang tính cá nhân, và mỗi cái chết đều để lại một khoảng trống nhỏ mà chúng tôi đã không thể cùng nhau thừa nhận hay đối diện. Đến giờ chúng tôi vẫn không có cách xử lý mất mát và cũng chưa từng nói về điều đó. Những liên hệ cũ đã lưu sẵn lâu ngày lại hiện lên sau khi máy lẻ được phân lại, không tránh khỏi khiến nó giống như một cuộc gọi từ nấm mồ. Tôi vẫn cố giữ liên lạc và lần theo mọi người, nhưng từng chút một các kết nối mờ dần, và ký ức cũng như lịch sử của chúng tôi với họ cũng phai đi theo
Mọi người ghé qua bàn nhau để tán gẫu về cuộc sống và đùa vui. Tôi chưa từng cười nhiều đến thế trong đời. Nhìn chung các mối quan hệ gần gũi hơn, và khi mọi người rời đi thì thấy buồn, nhưng nếu họ đến một nơi tốt hơn thì cũng thấy vui cho họ. So với vậy, làm việc từ xa tạo cảm giác quá vô trùng và phi cá nhân. Tôi đã làm việc từ xa từ khoảng năm 2015, nên đây không phải là ủng hộ quay lại văn phòng, chỉ là hoài niệm thôi
Nếu đã tin tưởng và làm việc cùng nhau 3 năm, thì có thể tin thêm 1~2 tuần nữa. Họ có thể hoàn tất những việc còn lại rồi dành thời gian cho mình. Chúng ta đều là người trưởng thành. Tôi hiểu rằng trong tình huống xấu nhất có thể xảy ra chuyện tồi tệ, nhưng điều đó thì lúc nào cũng vậy
Phần này khá hay:
“Nói thêm, nếu ai đó nổi giận vì bạn chạy thứ này thì có lẽ dù sao bạn cũng không muốn làm ở đó. Ngược lại, nếu một bộ phận IT hay tổ chức tương tự có thể tạo ra công cụ kiểu này mà không cảm thấy bị ‘đe dọa’, thì có thể bạn đang ở một nơi thực sự thích tạo ra những thứ thú vị và hữu ích. Nên trân trọng những nơi như vậy. Chúng thường không tồn tại được lâu”
Gần như chắc chắn chuyện này có thể bị xem là xử lý dữ liệu cá nhân trái phép. Có quyền truy cập không có nghĩa là muốn làm gì thì làm. Đặc biệt là lưu trữ, giữ lịch sử, hay liên kết với dữ liệu bên ngoài đều không phải là mục đích sử dụng dự kiến của các giao diện đó. Nếu bạn mang thông tin về nhà dưới dạng như trên laptop công việc thì còn có thể phát sinh vấn đề khác, thậm chí bị xem là mang bí mật kinh doanh ra ngoài.
Ít nhất ở châu Âu, việc lạm dụng các giao diện như vậy nhiều khả năng là bất hợp pháp, và nếu còn giữ bản sao hay diff thì lại càng như vậy. Người sử dụng lao động có thể phải hành động, nếu không họ cũng có thể phải chịu trách nhiệm. Hoặc sau này họ có thể vin vào vi phạm này để chấm dứt hợp đồng cho tiện. Nhất là nếu bạn dùng thông tin đó làm đòn bẩy thì càng dễ xảy ra.
Mạng lưới càng lớn thì dường như khả năng dính rắc rối cũng càng cao. Ngược lại, nếu không lớn thì giá trị của việc thu thập dữ liệu cũng thấp. Hay là thay vào đó nên cùng đồng nghiệp tổ chức lại, tự nguyện chia sẻ thông tin việc làm và có được sức mạnh đàm phán tập thể?
Nhiều công ty châu Âu có lẽ sẽ rất dè chừng việc nhân viên giữ một danh sách như vậy
Cách để kiểm tra là tìm các bình luận HN cũng lên giọng theo kiểu tương tự. Sau khi cửa sổ Overton đã mở rộng, người ta không còn tự kiềm chế nữa mà nói thẳng ra điều chúng ta đều biết: đây là lạm dụng hệ thống để biến một cuốn sổ địa chỉ cũ thành tờ lá cải nhiều chuyện khiến chính người trong cuộc cũng phải giật mình.
Ví dụ như: “Lúc đầu tôi chỉ quan tâm tài khoản nào bị vô hiệu hóa. Rồi sau đó bắt đầu theo dõi thay đổi chức danh, đổi họ (kết hôn), quy mô phòng ban, số lượng nhân sự công ty theo thời gian”, “LDAP đầy bí mật. Thật ngạc nhiên khi gần như mọi thứ đều có thể lấy được qua truy cập ẩn danh. Tôi từng phát hiện việc sáp nhập nhóm/phòng ban trước khi công bố, và từ danh sách thành viên của các mailing list bí mật cho dự án nội bộ cũng có thể moi ra đang có chuyện gì”, “Rất nhiều thứ kỳ lạ phụ thuộc vào việc cây LDAP có thể truy cập rộng rãi. Chỉ là nó làm rò rỉ nhiều thông tin hơn hầu hết mọi người nghĩ”, “Theo dõi HR làm gì và khi nào, phát hiện thời điểm người dùng đăng nhập/đăng xuất LDAP”
LDAP đầy bí mật. Đây là cách tuyệt vời để quan sát chuyện gì đang diễn ra trong công ty, và còn đáng ngạc nhiên hơn ở chỗ gần như mọi thứ đều có thể lấy được bằng truy cập ẩn danh
Tôi từng phát hiện việc sáp nhập nhóm hoặc phòng ban trước khi công bố. Với các mailing list bí mật cho dự án nội bộ, chỉ cần nhìn thành viên cũng có thể moi ra đang có chuyện gì. Nếu địa chỉ email để lộ thêm vài thứ thì càng lời.
ldapsearchrất hữu ích nếu bạn hiểu rõ LDAP, còn nếu chỉ muốn khám phá thì Apache LDAP Studio là một công cụ UI rất tốt. Ai cũng nên biết đủ để tạo một dịch vụ đăng nhập bind vào LDAP cho ứng dụng nội bộ. Bạn có thể dùng các nhóm do quản trị viên hệ thống duy trì để kiểm soát quyền của ứng dụng; nó rất mạnh và dễ bắt đầu nhanhDù là thiện ý thì vẫn hơi quá. Mặt khác, đó cũng thường là cách duy nhất để có được thông tin không có trên các trang intranet. Ví dụ như thực tế IT có những nhóm nào, các văn phòng ở đâu, ai là quản lý của ai, và dĩ nhiên là tôi đang bị thiếu khỏi danh sách phân phối nào trong khi người khác lại có, thứ đang gây ra vấn đề truy cập cổng nội bộ
Thật đáng ngạc nhiên khi nhiều người đã độc lập đi đến cùng một ý tưởng. Ở chỗ làm cũ tôi đã tạo ra “the sackinator”
sacked nghĩa là bị sa thải. Đó là một cron job dump toàn bộ thư mục AD mỗi đêm, cùng với một script diff đầu ra của hai ngày bất kỳ. Vì dữ liệu đã được dump sẵn nên lúc nào cũng có thể quay lại để phân tích thêm. Ban đầu tôi chỉ xem tài khoản nào bị vô hiệu hóa, nhưng sau đó còn bắt đầu theo dõi thay đổi chức danh, đổi họ (kết hôn), quy mô phòng ban, số lượng nhân sự công ty theo thời gian. Tôi hoàn toàn đồng ý rằng những nơi cho phép làm ra công cụ như vậy mà IT không cảm thấy bị đe dọa là những nơi đáng được trân trọng
Ha ha ha. Có một script rất giống như vậy được quản lý ở ‘KTMJ’. Mục đích của nó không phải để tìm người dùng bị vô hiệu hóa, mà để đồng bộ một thuộc tính LDAP cụ thể sang hệ thống khác
Tổ chức này đủ lớn, có hơn 300.000 người dùng. Trong khoảng thời gian ngắn từ lúc script truy vấn LDAP và chuẩn bị file đồng bộ đến lúc chạy phần import đồng bộ thực tế để xác minh từng người dùng còn tồn tại hay không, đã có hàng trăm tài khoản bị vô hiệu hóa và bị ghi vào file log ‘error’. Việc đồng bộ thực tế và file log ‘error’ nằm ngoài sự kiểm soát trực tiếp của tôi.
Lý do tôi cười như điên là vì hợp đồng của tôi sắp bị chấm dứt do ‘hạn chế ngân sách’. Tôi đã trải qua nhiều đợt sa thải nên cũng đoán trước được. Tài khoản của tôi rồi cũng sẽ là một trong những tài khoản bị vô hiệu hóa ở chu kỳ hàng tháng tiếp theo, nhưng trước đó tôi vẫn phải bàn giao cho người kế nhiệm quy trình xử lý và cách hoạt động dự kiến của việc ghi log ‘error’ cho người dùng bị vô hiệu hóa
Không cần nhìn quá tiêu cực. Ở chỗ tôi làm, công cụ này được gọi là “new-hires”
Nó dùng API key chỉ đọc, phạm vi hạn chế, cho một công cụ HR của bên thứ ba, và People Director đã đưa key đó cho tôi. Thỉnh thoảng cũng có dòng bắt đầu bằng
-, nhưng tên công cụ được lấy từ các dòng bắt đầu bằng+.new-hires được xây trên mô-đun/CLI Python “people” trong monorepo của chúng tôi. Công cụ này hữu ích hơn rất nhiều so với việc diff sơ đồ tổ chức. Nó cho biết ai đang ở đội nào, ở đâu, hôm nay có đi làm không, đã đến lúc chúc mừng kỷ niệm làm việc chưa, v.v. Nó cũng tuân theo “phép thử quỳ tím ZFS” do tôi đặt ra cho các công cụ CLI tốt, tức là cung cấp
-pHđể có đầu ra không tiêu đề và có thể parse được. Những nơi như vậy thực sự đáng trân trọngỞ công việc đầu tiên, tôi từng định xây một hệ thống như thế này, nhưng quản lý nghe xong và cấm thẳng
Sau đó công ty đó đã sa thải 15% kỹ sư phần mềm chỉ trong một ngày. Đội hỗ trợ tạo ticket hủy tài khoản nhân viên trên hệ thống theo dõi issue công khai, nên nhiều người biết tin theo cách đó trước cả khi nhận được thư mời họp