Blog yazısında “sizi tanıyan başka birinin eklemesi gerekiyordu” deniyor ama bu doğru değildi ya da artık değil.
Bir çalışan içeriği özel bir adrese e-postayla gönderirse, şirketten ayrıldığında bu içerik gösterilebiliyordu. Ben böyle yaptım ama gerçekten çalışıp çalışmadığını sonradan doğrulama şansım olmadı
Hangi şirket olduğunu sormamın sakıncası var mı?
Hâlâ kullanılıyor mu?
HR bunu değiştirmenizi hiç istedi mi? 5 yıl önce ayrıldım ama bu özelliği gerçekten seviyordum
epitaphs'ı neden yaptınız? Yaparken ilginç organizasyonel ya da teknik zorluklarla karşılaştınız mı?
Böyle bir şeyi işletmek için Git kullanmanızı şiddetle tavsiye ederim.
Bunu cron'da şöyle çalıştırabilirsiniz: curl https://internal.corp/employees.txt > employees.txt git add employees.txt git commit -m "Automated: $(date -u)" || exit 0 || exit 0, commit edilecek bir şey olmasa bile hata vermemesini sağlar. Böylece bilgi kaynağındaki tüm değişiklik geçmişi commit olarak kalır ve sadece git log çalıştırarak görebilirsiniz. Bunu zamanlanmış GitHub Actions ile sık sık yapıyorum; örnek için https://simonwillison.net/2020/Oct/9/git-scraping/ bağlantısına bakabilirsiniz
Benzerini yapıyorum ama || exit 0 yerine --allow-empty seçeneğini git commit ile kullanıyorum.
Boş commit oluşması sorun değil; çünkü bu, otomatik çalışmanın başarısız olmadığını, başarıyla çalıştığını ama değişiklik olmadığını gösteriyor
Determinizm için | sort eklemek de iyi olabilir. Bu tür küçük veri için Git, değeri bilinmeyen bir veritabanı
Aynı teknikle Fince kolay dil haber yayınının diff alınabilir bir arşivini oluşturmaya başladım.
Yüksek kaliteli, anlaşılabilir girdi toplamada çok yardımcı oldu. Teşekkürler https://github.com/hiAndrewQuinn/selkouutiset-scrape/
Sık değişen ama çok büyük değişimler göstermeyen veriler genelinde Git kullanmayı ciddi ciddi düşünüyorum. Örneğin kitaplıktaki kitapların listesi gibi.
Yine de bunun üzerinde işlemsel veritabanı özellikleri de istiyorum. Git bu kısmı iyi yapıyor. Aynı zamanda bazı alanlar için hızlı indeksleme de istiyorum ama Git bu konuda iyi değil. Bu yüzden sqlite'ı Git'e dump etme şeklinde bir “standart” kullanmayı düşünüyorum. Her işlem bir Git commit'i olarak ifade edilebilir; dayanıklılık ve makul indeksleme için ikisini birlikte çalıştırabilirsiniz. sqlite veritabanı her zaman yeniden üretilebilir, yeniden indekslenebilir ve bir ölçüde yedekleme amacıyla da uygundur.
Şimdilik yerimde sayıyor gibi hissediyorum; veritabanlarının bundan sonra nereye gideceğini göreceğiz
Benim bir iş arkadaşım olsa bu verilerle zamana bağlı ağ analizi yapar, insanların zaman içinde hangi gruplara geçtiğine bakarak birlikte çalışmaktan hoşlanıp hoşlanmadıklarını ya da birbirlerinden nefret edip etmediklerini çıkarmaya çalışırdı
Bu şekilde LDAP izlemek için bir araç yazdım [0]. LDAP bir bilgi hazinesi ve takipçilik için de harika.
İnsanların ayrıldığını görmek ve mümkünse ne kadar süre çalıştıklarını incelemek nedense ilginç geliyordu. Arkadaşların, kişiler kendileri öğrenmeden önce LDAP üzerinden işten çıkarıldıklarını fark etmesi de epey ilginçti. README'de, Slack webhook entegrasyonuyla LDAP dizininde neler olduğunu isteğe bağlı olarak görebileceğiniz; yeni işe alımlar, ayrılanlar ve terfiler, HR'nin neyi ne zaman yaptığı, yetkisiz değişiklikler, yanlışlıkla sızdırılan veriler ve kullanıcıların LDAP giriş/çıkışlarını izleyebileceğiniz yazıyordu. Microsoft ve Active Directory için temelde aynı işi yapan LDAPmonitor[1] da var
[0]https://github.com/MegaManSec/LDAP-Monitoring-Watchdog
[1]https://github.com/p0dalirius/LDAPmonitor
Uzaktan çalışma çağındaki işten çıkarmalar tuhaf. Eskiden eşyalarını kutuya koyup çıkanları görerek kimin işten çıkarıldığını oldukça iyi anlardınız; yanlarına gidip mahalledeki barda buluşmayı önerebilir ya da iletişim bilgilerinizi değiş tokuş edebilirdiniz
Bir ölçüde kapanış hissi elde edilebiliyordu. Şimdiyse bir gün birden fazla kişi e-postalara yanıt vermemeye başlıyor ve gerçekten ayrıldıklarını mı yoksa sadece meşgul mü olduklarını anlamak için beklemek gerekiyor. Proje için gereken teslimatları bekliyorsanız, onlar hiç gelmeyebilir ve nedenini de bir süre öğrenemezsiniz. Şirket dizini olsa bile, WARN Act nedeniyle insanlar çoğu zaman 60 günden uzun süre orada görünmeye devam ediyor ve çoğu şirketin bir “işten çıkarılanlar listesi” hazırlamadığı anlaşılıyor. Kimin işten çıkarıldığını söylememeleri ve bunu duyurmadan önce erişimlerini kesip veda etme şansı bile vermemeleri, kapanış hissini gerçekten çok zorlaştırıyor
Slack'te insanların hesaplarının vedalaşma bile olmadan devre dışı hale geldiğini görmek üzücü
Benim yaşadığım en kötü yönetici, ayrılan çalışanların devir teslim verilerini bulma bahanesiyle eski çalışanların Slack hesaplarına erişim isterdi. Onların hesabıyla her giriş yaptığında hesap bazen yeşile dönüyordu. Eski bir çalışma arkadaşının hesabının yeşile döndüğünü görüp yöneticinin özel mesajlarını karıştırdığını bilmek ürkütücüydü. Şirketin zaten Slack mesajlarını görebildiğini biliyorum ama bunu yöneticinin gerçek zamanlı yaptığını görmek daha da tüyler ürpertici
Başta yapmayı denediler ama pandeminin ilk döneminde vefat edenlerin sayısı o kadar hızlı arttı ki kurumun bunu sürekli duyurması mümkün olmadı
HR'ın herkes için birkaç söz toparlamaya çalışması bile moral bozucu bir işe dönüşmüştü ve bir zamanlar canlı, kişisel bir dokunuşun olduğu yerde kalıcı bir solgunluk bırakıyordu. İnsanlar kaybolmaya devam etti ama ayrıldıklarına ya da nasıl ayrıldıklarına dair hâlâ bir duyuru yoktu.
Pandeminin başlarında General Counsel ile son kez görüştüm. Kapanma döneminin çoğunda insanlar gibi o da birinci derece ailesi dışında kimseyi görememişti ve aylarca güzel bir sohbet etme fırsatı bulamamıştı; gerçi öyle bir fırsatı olsa bile bu onu yine öldürebilirdi. Bitirmek üzere olduğu işleri ardı ardına anlattı, ardından da bir avukat olarak CIO'ya harika bir mektup yazdı; bu da aramızdaki en sevdiğimiz konuşmaya dönüştü.
Altı ay sonra biri hukuk ekibine gidiyordu ve telefonda birinin öldüğünü söyledi; ben de hemen kötü bir hisse kapıldım. Web sitesini, dizini ve yerel vefat ilanlarını taradım ama hiçbir şey yoktu, dedikodu ağı da sessizdi. Bunun üzerine sekreterini aradım; o da oldukça sakin bir şekilde GC'nin 6 hafta önce vefat ettiğini söyledi.
Kurumun süreçleri ancak neredeyse tam 1 yıl sonra yetişebildi ve “Remembering $generalCounselor” yayımlandı. O zamana kadar cenazeyi çoktan kaçırmıştım, ailesi taşınmıştı ve bu kadar geç başsağlığı dilemek birçok kişiye garip geliyordu. Başkalarının şaşkınlığını, utancını ve üzüntüsünü görmek teselli edici değildi ama en azından bunu yaşayan tek kişinin ben olmadığını anlamış oldum.
Biz küçük sayılmayız ama kişisel bir kurumuz ve her ölüm, birlikte ne kabul edebildiğimiz ne de başa çıkabildiğimiz küçük bir boşluk bıraktı. Hâlâ kaybı işleme koymanın bir yolu yok ve bunun hakkında da konuşmadık. Kaydedilmiş eski bir kişinin iç hattı yeniden atandıktan sonra tekrar göründüğünde bu kaçınılmaz olarak mezardan gelen bir telefon gibi hissettiriyor. İrtibatta kalmaya, iz sürmeye devam ediyoruz ama bağlantılar yavaş yavaş silikleşiyor; onlarla paylaştığımız anılarımız ve tarihimiz de öyle
Ofis düzeninden özlediğim şeylerden biri daha insani bağlar
İnsanların masanıza uğrayıp hayattan konuşması, şakalaşması. Hayatımda hiç o kadar çok gülmemiştim. Genel olarak ilişkiler daha yakındı; insanlar ayrıldığında üzülüyorduk ama daha iyi bir yere gittilerse onlar adına seviniyorduk. Uzaktan çalışma bunun yanında fazla steril ve kişiliksiz geliyor. Yaklaşık 2015'ten beri uzaktan çalışıyorum; yani bu ofise dönüş çağrısı değil, sadece bir nostalji
Erişimi kesmek bana hep aptalca gelmiştir ve yönetici olarak ben bunu yapmadım
Üç yıl boyunca güvenip birlikte çalıştıysanız, 1-2 hafta daha güvenebilirsiniz. Kalan işlerini toparlayabilir, biraz zaman ayırabilirler. Hepimiz yetişkiniz. En kötü senaryoda kötü bir şey olabileceğini anlıyorum ama bu her zaman mümkündü
Bunu söyleyeceğim tek an belki de budur ama, LinkedIn olduğu için mutluyum. En azından ayrılan biriyle istediğiniz zaman yeniden iletişime geçebileceğinizi biliyorsunuz
Bu kısım hoşuma gitti:
“Ek olarak, birisi bunu çalıştırdığın için öfkeleniyorsa, zaten muhtemelen orada çalışmak istemezsin. Tersine, bir IT ya da benzeri organizasyon ‘tehdit’ hissetmeden böyle araçlar geliştirebiliyorsa, gerçekten ilginç ve faydalı şeyler üretmekten keyif alınan bir yerde olabilirsin. Böyle yerlerin kıymetini bilmek gerekir. Çoğu uzun sürmez”
Yine de orada çalışmak istiyorsan önce hukuki durumu kontrol etmek iyi olur
Bu neredeyse kesin olarak kişisel verilerin izinsiz işlenmesi sayılabilir. Erişim yetkinin olması, her şeyi kafana göre yapabileceğin anlamına gelmez. Özellikle arşivleme, geçmiş kayıtlarını tutma ve harici verilerle birleştirme, bu tür arayüzlerin amaçlanan kullanımı değildir. Bilgileri iş dizüstü bilgisayarı gibi bir biçimde eve götürmek ayrıca başka sorunlar yaratabilir ve ticari sırların dışarı çıkarılması olarak da görülebilir.
En azından Avrupa’da böyle arayüzleri kötüye kullanmak büyük olasılıkla yasa dışıdır; kopya veya diff saklamak da bunu daha da sorunlu hale getirir. İşveren önlem almak zorunda kalabilir, aksi halde sorumlu tutulabilir. Ya da daha sonra bu ihlali bahane ederek sözleşmeyi kolayca sonlandırabilir. Özellikle bu bilgiyi kaldıraç olarak kullanırsan bu daha da olasıdır.
Ağ ne kadar büyükse, başının derde girme ihtimali de o kadar yüksek görünüyor. Tersi durumda ise veriyi toplamanın getirisi az olur. Bunun yerine iş arkadaşlarınla örgütlenip istihdam bilgilerini gönüllü olarak paylaşarak kolektif pazarlık gücü kazanmak daha iyi olmaz mı?
Bunun kişisel veri sayılıp sayılmadığını merak ediyorum. Sonuçta herkesin adı, unvanı ve çalışma süresinin kopyası
Avrupa’daki birçok şirket çalışanların böyle listeler tutmasına temkinli yaklaşır gibi geliyor
Amazon, işten çıkarmalar olduktan sonra bundan etkilenen kişileri bulmak için kullanılan bir LDAP sorgusunu paylaşan birini işten çıkardı. Üstelik bilgiyi sızdırmamıştı bile
Hiç iyi değil. Sadece gösterişli bir poz kesme
Bunu anlamanın yolu, aynı şekilde poz kesen HN yorumlarına bakmak. Overton penceresi genişledikten sonra artık kendilerini tutmuyorlar ve bildiklerini açıkça söylüyorlar. Bunun, eski bir adres defterini tarafların bile şaşıracağı bir dedikodu gazetesine dönüştüren sistem istismarı olduğunu anlatıyorlar.
Mesela “Başta yalnızca hangi hesapların devre dışı bırakıldığıyla ilgileniyordum. Sonra unvan değişikliklerini, soyadı değişikliklerini (evlilik), bölüm büyüklüklerini, zaman içindeki şirket çalışan sayısını takip etmeye başladım”, “LDAP sırlarla dolu. Neredeyse her şeyi anonim erişimle alabilmek inanılmaz. Duyurudan önce ekip/bölüm birleşmelerini yakaladım, dahili projelerin gizli mailing listelerinden de üyelerine bakarak neler olduğunu çıkarabiliyorsun”, “Birçok tuhaf şey LDAP ağacının geniş erişilebilir olmasına dayanıyor. Sadece çoğu insanın düşündüğünden daha fazla bilgi sızdırıyor”, “İK’nın ne zaman ne yaptığını izliyor, kullanıcıların LDAP’a ne zaman giriş/çıkış yaptığını tespit ediyorum” gibi şeyler
LDAP sırlarla dolu. Şirkette neler olup bittiğini gözlemek için harika bir yöntem ve neredeyse her şeyi anonim erişimle elde edebilmek de şaşırtıcı
Duyurudan önce ekip ya da bölüm birleşmelerini yakaladığım oldu. Dahili projelerin gizli mailing listelerinde de üyelere bakarak neler döndüğünü çıkarabiliyorsun. Mail adresi bir şeyleri ele veriyorsa bu da bonus. LDAP’ı iyi biliyorsan ldapsearch iyidir; sadece keşfetmek istiyorsan Apache LDAP Studio harika bir UI aracıdır. Herkesin en azından dahili uygulamalar için LDAP’a bind olan bir giriş servisi yazabilecek kadar bilmesi gerekir. Sistem yöneticisinin yönettiği grupları kullanarak uygulama yetkilerini kontrol edebilirsin; çok güçlüdür ve hızlı başlamak kolaydır
Rastgele kullanıcıların, hatta anonim kullanıcıların bir şirketin tam AD ağacını indeksleyebilmesine izin veren şirketleri görünce hâlâ şaşırıyorum
Kibarca ama yine de olacak iş değil. Ayrıca çoğu zaman intranet sayfalarında olmayan bilgileri edinmenin tek yolu bu oluyor. Örneğin IT içinde gerçekte hangi ekiplerin olduğu, ofislerin nerede bulunduğu, birinin yöneticisinin kim olduğu ve tabii ki iç portala erişim sorunu çıkaran hangi dağıtım listesinde benim olmayıp başka kullanıcıların olduğu gibi şeyler
Dahili uygulama kimlik doğrulamasında LDAP gruplarını mı kullanacaksın? Bir sonraki SolarWinds olmak istiyorsan tabii
Birçok kişinin aynı fikre birbirinden bağımsız şekilde ulaşmış olmasına şaşırdım. Eski iş yerimde “the sackinator”ı yapmıştım
sacked, işten çıkarılmış demek. Her gece tüm AD dizinini dump eden bir cron işi ve rastgele iki günün çıktısını diff eden bir betikti. Veriler dump edildiği için istediğin zaman geri dönüp ek analiz yapabiliyordun. Başta sadece hangi hesapların devre dışı bırakıldığına baktım, sonra unvan değişikliklerini, soyadı değişikliklerini (evlilik), bölüm büyüklüklerini, zaman içindeki şirket çalışan sayısını izlemeye başladım. Böyle araçlar yapabildiğin ve IT’nin tehdit hissetmediği yerlerin kıymetini bilmek gerektiği görüşüne tamamen katılıyorum
Hahaha. ‘KTMJ’ tarafından yönetilen çok benzer bir betik var. Devre dışı kullanıcıları bulmak için değil, belirli LDAP özniteliklerini başka bir sistemle senkronize etmek için kullanılıyor
Bu organizasyon yeterince büyük; kullanıcı sayısı 300 binden fazla. Betiğin LDAP’ı sorgulayıp senkronizasyon dosyasını hazırlamasından, her kullanıcının hâlâ var olup olmadığını doğrulayan asıl senkronizasyon içe aktarımının çalışmasına kadar geçen o kısa sürede bile yüzlerce hesap zaten devre dışı bırakılıyor ve ‘error’ günlük dosyasına yazılıyor. Asıl senkronizasyon ve ‘error’ günlük dosyası benim doğrudan kontrolüm dışında.
Çılgınca gülmemin sebebi, ‘bütçe kısıtları’ nedeniyle sözleşmemin sona erecek olması. Zaten daha önce birkaç işten çıkarma turu yaşandığı için bunu bekliyordum. Benim hesabım da bir sonraki aylık döngüde devre dışı bırakılacak hesaplardan biri olacak; ondan önce işlem sürecini ve beklenen devre dışı kullanıcı ‘error’ kayıt davranışını yerime gelecek kişilere devretmem gerekiyor
Buna fazla olumsuz bakmamak lazım. Benim çalıştığım yerde bu araca “new-hires” deniyor
Üçüncü taraf bir İK aracına ait sınırlı, salt okunur bir API anahtarı kullanıyor ve bu anahtarı bana People Director verdi. Arada - ile başlayan satırlar da oluyor ama aracın adı + ile başlayan satırlardan geliyor.
new-hires, monorepomuzdaki “people” Python modülü/CLI’si üzerine kuruldu. Bu araç, organizasyon şeması diff’inden çok daha faydalı. Kimin hangi takımda olduğunu, nerede bulunduğunu, bugün çalışıp çalışmadığını, iş yıl dönümünü kutlama zamanının gelip gelmediğini görebiliyorsun. Ayrıca iyi CLI araçları için kendi “ZFS turnusol testi”me de uyuyor; ayrıştırılabilir ve başlıksız çıktı için -pH sağlıyor. Böyle yerlerin gerçekten kıymeti bilinmeli
Neresi? Gerçekten harika bir yer gibi geliyor
İlk işimde böyle bir sistem yapmaya çalışmıştım ama yöneticim bunu duyup açıkça yasakladı
Daha sonra o şirket bir günde yazılım mühendislerinin %15’ini işten çıkardı. Destek ekibi, açık issue tracker’da çalışan hesaplarının kapatılması için ticket’lar açtı; bu yüzden birçok kişi toplantı davetini almadan önce bunu o şekilde öğrendi
1 yorum
Hacker News yorumları
epitaphs'ı yapan kişiyim. Sorularınızı alayım
Bir çalışan içeriği özel bir adrese e-postayla gönderirse, şirketten ayrıldığında bu içerik gösterilebiliyordu. Ben böyle yaptım ama gerçekten çalışıp çalışmadığını sonradan doğrulama şansım olmadı
HR bunu değiştirmenizi hiç istedi mi? 5 yıl önce ayrıldım ama bu özelliği gerçekten seviyordum
Böyle bir şeyi işletmek için Git kullanmanızı şiddetle tavsiye ederim.
Bunu cron'da şöyle çalıştırabilirsiniz:
curl https://internal.corp/employees.txt > employees.txtgit add employees.txtgit commit -m "Automated: $(date -u)" || exit 0|| exit 0, commit edilecek bir şey olmasa bile hata vermemesini sağlar. Böylece bilgi kaynağındaki tüm değişiklik geçmişi commit olarak kalır ve sadecegit logçalıştırarak görebilirsiniz. Bunu zamanlanmış GitHub Actions ile sık sık yapıyorum; örnek için https://simonwillison.net/2020/Oct/9/git-scraping/ bağlantısına bakabilirsiniz|| exit 0yerine--allow-emptyseçeneğinigit commitile kullanıyorum.Boş commit oluşması sorun değil; çünkü bu, otomatik çalışmanın başarısız olmadığını, başarıyla çalıştığını ama değişiklik olmadığını gösteriyor
| sorteklemek de iyi olabilir. Bu tür küçük veri için Git, değeri bilinmeyen bir veritabanıYüksek kaliteli, anlaşılabilir girdi toplamada çok yardımcı oldu. Teşekkürler
https://github.com/hiAndrewQuinn/selkouutiset-scrape/
Yine de bunun üzerinde işlemsel veritabanı özellikleri de istiyorum. Git bu kısmı iyi yapıyor. Aynı zamanda bazı alanlar için hızlı indeksleme de istiyorum ama Git bu konuda iyi değil. Bu yüzden sqlite'ı Git'e dump etme şeklinde bir “standart” kullanmayı düşünüyorum. Her işlem bir Git commit'i olarak ifade edilebilir; dayanıklılık ve makul indeksleme için ikisini birlikte çalıştırabilirsiniz. sqlite veritabanı her zaman yeniden üretilebilir, yeniden indekslenebilir ve bir ölçüde yedekleme amacıyla da uygundur.
Şimdilik yerimde sayıyor gibi hissediyorum; veritabanlarının bundan sonra nereye gideceğini göreceğiz
Bu şekilde LDAP izlemek için bir araç yazdım [0]. LDAP bir bilgi hazinesi ve takipçilik için de harika.
İnsanların ayrıldığını görmek ve mümkünse ne kadar süre çalıştıklarını incelemek nedense ilginç geliyordu. Arkadaşların, kişiler kendileri öğrenmeden önce LDAP üzerinden işten çıkarıldıklarını fark etmesi de epey ilginçti. README'de, Slack webhook entegrasyonuyla LDAP dizininde neler olduğunu isteğe bağlı olarak görebileceğiniz; yeni işe alımlar, ayrılanlar ve terfiler, HR'nin neyi ne zaman yaptığı, yetkisiz değişiklikler, yanlışlıkla sızdırılan veriler ve kullanıcıların LDAP giriş/çıkışlarını izleyebileceğiniz yazıyordu. Microsoft ve Active Directory için temelde aynı işi yapan LDAPmonitor[1] da var
[0]https://github.com/MegaManSec/LDAP-Monitoring-Watchdog
[1]https://github.com/p0dalirius/LDAPmonitor
Uzaktan çalışma çağındaki işten çıkarmalar tuhaf. Eskiden eşyalarını kutuya koyup çıkanları görerek kimin işten çıkarıldığını oldukça iyi anlardınız; yanlarına gidip mahalledeki barda buluşmayı önerebilir ya da iletişim bilgilerinizi değiş tokuş edebilirdiniz
Bir ölçüde kapanış hissi elde edilebiliyordu. Şimdiyse bir gün birden fazla kişi e-postalara yanıt vermemeye başlıyor ve gerçekten ayrıldıklarını mı yoksa sadece meşgul mü olduklarını anlamak için beklemek gerekiyor. Proje için gereken teslimatları bekliyorsanız, onlar hiç gelmeyebilir ve nedenini de bir süre öğrenemezsiniz. Şirket dizini olsa bile, WARN Act nedeniyle insanlar çoğu zaman 60 günden uzun süre orada görünmeye devam ediyor ve çoğu şirketin bir “işten çıkarılanlar listesi” hazırlamadığı anlaşılıyor. Kimin işten çıkarıldığını söylememeleri ve bunu duyurmadan önce erişimlerini kesip veda etme şansı bile vermemeleri, kapanış hissini gerçekten çok zorlaştırıyor
Benim yaşadığım en kötü yönetici, ayrılan çalışanların devir teslim verilerini bulma bahanesiyle eski çalışanların Slack hesaplarına erişim isterdi. Onların hesabıyla her giriş yaptığında hesap bazen yeşile dönüyordu. Eski bir çalışma arkadaşının hesabının yeşile döndüğünü görüp yöneticinin özel mesajlarını karıştırdığını bilmek ürkütücüydü. Şirketin zaten Slack mesajlarını görebildiğini biliyorum ama bunu yöneticinin gerçek zamanlı yaptığını görmek daha da tüyler ürpertici
HR'ın herkes için birkaç söz toparlamaya çalışması bile moral bozucu bir işe dönüşmüştü ve bir zamanlar canlı, kişisel bir dokunuşun olduğu yerde kalıcı bir solgunluk bırakıyordu. İnsanlar kaybolmaya devam etti ama ayrıldıklarına ya da nasıl ayrıldıklarına dair hâlâ bir duyuru yoktu.
Pandeminin başlarında General Counsel ile son kez görüştüm. Kapanma döneminin çoğunda insanlar gibi o da birinci derece ailesi dışında kimseyi görememişti ve aylarca güzel bir sohbet etme fırsatı bulamamıştı; gerçi öyle bir fırsatı olsa bile bu onu yine öldürebilirdi. Bitirmek üzere olduğu işleri ardı ardına anlattı, ardından da bir avukat olarak CIO'ya harika bir mektup yazdı; bu da aramızdaki en sevdiğimiz konuşmaya dönüştü.
Altı ay sonra biri hukuk ekibine gidiyordu ve telefonda birinin öldüğünü söyledi; ben de hemen kötü bir hisse kapıldım. Web sitesini, dizini ve yerel vefat ilanlarını taradım ama hiçbir şey yoktu, dedikodu ağı da sessizdi. Bunun üzerine sekreterini aradım; o da oldukça sakin bir şekilde GC'nin 6 hafta önce vefat ettiğini söyledi.
Kurumun süreçleri ancak neredeyse tam 1 yıl sonra yetişebildi ve “Remembering $generalCounselor” yayımlandı. O zamana kadar cenazeyi çoktan kaçırmıştım, ailesi taşınmıştı ve bu kadar geç başsağlığı dilemek birçok kişiye garip geliyordu. Başkalarının şaşkınlığını, utancını ve üzüntüsünü görmek teselli edici değildi ama en azından bunu yaşayan tek kişinin ben olmadığını anlamış oldum.
Biz küçük sayılmayız ama kişisel bir kurumuz ve her ölüm, birlikte ne kabul edebildiğimiz ne de başa çıkabildiğimiz küçük bir boşluk bıraktı. Hâlâ kaybı işleme koymanın bir yolu yok ve bunun hakkında da konuşmadık. Kaydedilmiş eski bir kişinin iç hattı yeniden atandıktan sonra tekrar göründüğünde bu kaçınılmaz olarak mezardan gelen bir telefon gibi hissettiriyor. İrtibatta kalmaya, iz sürmeye devam ediyoruz ama bağlantılar yavaş yavaş silikleşiyor; onlarla paylaştığımız anılarımız ve tarihimiz de öyle
İnsanların masanıza uğrayıp hayattan konuşması, şakalaşması. Hayatımda hiç o kadar çok gülmemiştim. Genel olarak ilişkiler daha yakındı; insanlar ayrıldığında üzülüyorduk ama daha iyi bir yere gittilerse onlar adına seviniyorduk. Uzaktan çalışma bunun yanında fazla steril ve kişiliksiz geliyor. Yaklaşık 2015'ten beri uzaktan çalışıyorum; yani bu ofise dönüş çağrısı değil, sadece bir nostalji
Üç yıl boyunca güvenip birlikte çalıştıysanız, 1-2 hafta daha güvenebilirsiniz. Kalan işlerini toparlayabilir, biraz zaman ayırabilirler. Hepimiz yetişkiniz. En kötü senaryoda kötü bir şey olabileceğini anlıyorum ama bu her zaman mümkündü
Bu kısım hoşuma gitti:
“Ek olarak, birisi bunu çalıştırdığın için öfkeleniyorsa, zaten muhtemelen orada çalışmak istemezsin. Tersine, bir IT ya da benzeri organizasyon ‘tehdit’ hissetmeden böyle araçlar geliştirebiliyorsa, gerçekten ilginç ve faydalı şeyler üretmekten keyif alınan bir yerde olabilirsin. Böyle yerlerin kıymetini bilmek gerekir. Çoğu uzun sürmez”
Bu neredeyse kesin olarak kişisel verilerin izinsiz işlenmesi sayılabilir. Erişim yetkinin olması, her şeyi kafana göre yapabileceğin anlamına gelmez. Özellikle arşivleme, geçmiş kayıtlarını tutma ve harici verilerle birleştirme, bu tür arayüzlerin amaçlanan kullanımı değildir. Bilgileri iş dizüstü bilgisayarı gibi bir biçimde eve götürmek ayrıca başka sorunlar yaratabilir ve ticari sırların dışarı çıkarılması olarak da görülebilir.
En azından Avrupa’da böyle arayüzleri kötüye kullanmak büyük olasılıkla yasa dışıdır; kopya veya diff saklamak da bunu daha da sorunlu hale getirir. İşveren önlem almak zorunda kalabilir, aksi halde sorumlu tutulabilir. Ya da daha sonra bu ihlali bahane ederek sözleşmeyi kolayca sonlandırabilir. Özellikle bu bilgiyi kaldıraç olarak kullanırsan bu daha da olasıdır.
Ağ ne kadar büyükse, başının derde girme ihtimali de o kadar yüksek görünüyor. Tersi durumda ise veriyi toplamanın getirisi az olur. Bunun yerine iş arkadaşlarınla örgütlenip istihdam bilgilerini gönüllü olarak paylaşarak kolektif pazarlık gücü kazanmak daha iyi olmaz mı?
Avrupa’daki birçok şirket çalışanların böyle listeler tutmasına temkinli yaklaşır gibi geliyor
Bunu anlamanın yolu, aynı şekilde poz kesen HN yorumlarına bakmak. Overton penceresi genişledikten sonra artık kendilerini tutmuyorlar ve bildiklerini açıkça söylüyorlar. Bunun, eski bir adres defterini tarafların bile şaşıracağı bir dedikodu gazetesine dönüştüren sistem istismarı olduğunu anlatıyorlar.
Mesela “Başta yalnızca hangi hesapların devre dışı bırakıldığıyla ilgileniyordum. Sonra unvan değişikliklerini, soyadı değişikliklerini (evlilik), bölüm büyüklüklerini, zaman içindeki şirket çalışan sayısını takip etmeye başladım”, “LDAP sırlarla dolu. Neredeyse her şeyi anonim erişimle alabilmek inanılmaz. Duyurudan önce ekip/bölüm birleşmelerini yakaladım, dahili projelerin gizli mailing listelerinden de üyelerine bakarak neler olduğunu çıkarabiliyorsun”, “Birçok tuhaf şey LDAP ağacının geniş erişilebilir olmasına dayanıyor. Sadece çoğu insanın düşündüğünden daha fazla bilgi sızdırıyor”, “İK’nın ne zaman ne yaptığını izliyor, kullanıcıların LDAP’a ne zaman giriş/çıkış yaptığını tespit ediyorum” gibi şeyler
LDAP sırlarla dolu. Şirkette neler olup bittiğini gözlemek için harika bir yöntem ve neredeyse her şeyi anonim erişimle elde edebilmek de şaşırtıcı
Duyurudan önce ekip ya da bölüm birleşmelerini yakaladığım oldu. Dahili projelerin gizli mailing listelerinde de üyelere bakarak neler döndüğünü çıkarabiliyorsun. Mail adresi bir şeyleri ele veriyorsa bu da bonus. LDAP’ı iyi biliyorsan
ldapsearchiyidir; sadece keşfetmek istiyorsan Apache LDAP Studio harika bir UI aracıdır. Herkesin en azından dahili uygulamalar için LDAP’a bind olan bir giriş servisi yazabilecek kadar bilmesi gerekir. Sistem yöneticisinin yönettiği grupları kullanarak uygulama yetkilerini kontrol edebilirsin; çok güçlüdür ve hızlı başlamak kolaydırKibarca ama yine de olacak iş değil. Ayrıca çoğu zaman intranet sayfalarında olmayan bilgileri edinmenin tek yolu bu oluyor. Örneğin IT içinde gerçekte hangi ekiplerin olduğu, ofislerin nerede bulunduğu, birinin yöneticisinin kim olduğu ve tabii ki iç portala erişim sorunu çıkaran hangi dağıtım listesinde benim olmayıp başka kullanıcıların olduğu gibi şeyler
Birçok kişinin aynı fikre birbirinden bağımsız şekilde ulaşmış olmasına şaşırdım. Eski iş yerimde “the sackinator”ı yapmıştım
sacked, işten çıkarılmış demek. Her gece tüm AD dizinini dump eden bir cron işi ve rastgele iki günün çıktısını diff eden bir betikti. Veriler dump edildiği için istediğin zaman geri dönüp ek analiz yapabiliyordun. Başta sadece hangi hesapların devre dışı bırakıldığına baktım, sonra unvan değişikliklerini, soyadı değişikliklerini (evlilik), bölüm büyüklüklerini, zaman içindeki şirket çalışan sayısını izlemeye başladım. Böyle araçlar yapabildiğin ve IT’nin tehdit hissetmediği yerlerin kıymetini bilmek gerektiği görüşüne tamamen katılıyorum
Hahaha. ‘KTMJ’ tarafından yönetilen çok benzer bir betik var. Devre dışı kullanıcıları bulmak için değil, belirli LDAP özniteliklerini başka bir sistemle senkronize etmek için kullanılıyor
Bu organizasyon yeterince büyük; kullanıcı sayısı 300 binden fazla. Betiğin LDAP’ı sorgulayıp senkronizasyon dosyasını hazırlamasından, her kullanıcının hâlâ var olup olmadığını doğrulayan asıl senkronizasyon içe aktarımının çalışmasına kadar geçen o kısa sürede bile yüzlerce hesap zaten devre dışı bırakılıyor ve ‘error’ günlük dosyasına yazılıyor. Asıl senkronizasyon ve ‘error’ günlük dosyası benim doğrudan kontrolüm dışında.
Çılgınca gülmemin sebebi, ‘bütçe kısıtları’ nedeniyle sözleşmemin sona erecek olması. Zaten daha önce birkaç işten çıkarma turu yaşandığı için bunu bekliyordum. Benim hesabım da bir sonraki aylık döngüde devre dışı bırakılacak hesaplardan biri olacak; ondan önce işlem sürecini ve beklenen devre dışı kullanıcı ‘error’ kayıt davranışını yerime gelecek kişilere devretmem gerekiyor
Buna fazla olumsuz bakmamak lazım. Benim çalıştığım yerde bu araca “new-hires” deniyor
Üçüncü taraf bir İK aracına ait sınırlı, salt okunur bir API anahtarı kullanıyor ve bu anahtarı bana People Director verdi. Arada
-ile başlayan satırlar da oluyor ama aracın adı+ile başlayan satırlardan geliyor.new-hires, monorepomuzdaki “people” Python modülü/CLI’si üzerine kuruldu. Bu araç, organizasyon şeması diff’inden çok daha faydalı. Kimin hangi takımda olduğunu, nerede bulunduğunu, bugün çalışıp çalışmadığını, iş yıl dönümünü kutlama zamanının gelip gelmediğini görebiliyorsun. Ayrıca iyi CLI araçları için kendi “ZFS turnusol testi”me de uyuyor; ayrıştırılabilir ve başlıksız çıktı için
-pHsağlıyor. Böyle yerlerin gerçekten kıymeti bilinmeliİlk işimde böyle bir sistem yapmaya çalışmıştım ama yöneticim bunu duyup açıkça yasakladı
Daha sonra o şirket bir günde yazılım mühendislerinin %15’ini işten çıkardı. Destek ekibi, açık issue tracker’da çalışan hesaplarının kapatılması için ticket’lar açtı; bu yüzden birçok kişi toplantı davetini almadan önce bunu o şekilde öğrendi