BT ekibinin öğretici karşı hamlesi
- Avustralya’daki bir bankanın internet altyapı ekibinde çalışan "Bruce"un hikâyesi.
- İnternet bankacılığının ilk dönemlerinde ekip hızla büyüdü ve iş yükü de arttı.
- Ekip, ISDN bağlantılarının kullanım oranı yarıyı geçmeden önce ek bağlantı satın alma ihtiyacını fark edip CIO’ya bir teklif sundu.
Yönetimin reddi ve BT ekibinin tepkisi
- CIO, yönetime ek ISDN bağlantısı satın alma talebini iletti ancak mevcut bağlantıların kullanım oranı henüz yarıya bile ulaşmadığı gerekçesiyle talep reddedildi.
- BT ekibi, bağlantı kullanımı %50’yi geçince yeniden talepte bulundu ancak %100’e yaklaşana kadar beklemeleri söylendi.
BT ekibinin stratejik hamlesi
- BT ekibi, sorunu yönetime fark ettirmek için yöneticilerin ağ bağlantısını kademeli olarak kısıtlamaya karar verdi.
- İlk hafta bağlantıyı %10 azalttılar, ardından her hafta buna ek olarak %10 daha düşürdüler.
- Bir ay sonra ek ISDN bağlantılarının kurulumu onaylandı ve yönetim, "internet sorununu" çözdüğü için kendi kendini kutladı.
GN⁺ görüşü
Bu yazıdaki en önemli nokta, BT ekibinin yönetimin kararına meydan okuyup gerekli altyapı yatırımını gerçek kullanıcı deneyimi üzerinden kabul ettiren stratejik yaklaşımı. Bu, teknik sorunlarla iş kararları arasındaki boşluğu kapatmada yaratıcı ve etkili bir yöntem gösteriyor. Hikâye yalnızca BT profesyonelleri için ilgi çekici değil, aynı zamanda teknik olmayan karar vericilerin de teknoloji altyapısının önemini anlamasına yardımcı olabilecek dersler içeriyor.
1 yorum
Hacker News yorumları
Eskiden müşterilerimize büyük sorunlar yaşatan berbat bir üçüncü taraf yazılım kullanmıştık.
İçeride alternatif bir çözüm geliştiriyorduk ama bazıları sözleşmeyi yenileyip aynı bug dolu yazılımı kullanmaya devam etmeyi savunuyordu.
Müşterilerin açtığı tüm ticket’ların mevcut çözümü korumak isteyenlere gitmesini sağladık; sonunda bizim sisteme geçtikten sonra sorunlar neredeyse tamamen ortadan kalktı.
Uygulayıcılar çoğu zaman acının yukarı çıkmasını kahramanca engelliyor; organizasyon da sorunu ortadan kaldırmak yerine insanları ağrı kesici gibi devreye sokup bu duruma bağımlı hale geliyor.
Eski sistem, zaten yaptığı işler dışında büyük çaplı yeniden kablolama olmadan hiçbir şey yapamıyordu; ondan sorumlu ekip de bilgiyi paylaşmazlarsa ömür boyu iş garantileri olacağına inanıyordu.
Yeni sistem ise sorguları düzeltmek yerine daha fazla CPU eklemenin yeterli olduğuna inanıyordu, bu yüzden veritabanında ciddi gecikmeler vardı.
İki ekip yan yana oturuyordu ama birbirleriyle konuşmuyordu; eski sistem ekibi, IT direktörünün masasının altındaki paketi bomba diye ihbar etmeye kadar vardı.
Yeni sistem ekibi sonunda Oracle’ı çağırdı ve Oracle sorguları yeniden yazdı.
Riski net biçimde açıklayabilmek ve teknik sonuçların işi nasıl etkileyeceğini anlatabilmek, IT çalışanları için temel bir yetkinliktir.
Bu bankanın yönetimi gerçekten ağır biçimde kavrayışsız olabilir; ama teknik ekibin bunu düzgün anlatamamış olması da mümkün.
Aksine, belki IT’nin içinde olduğum için böyle hissediyorum ama biz oldukça iyi ve doğru iletişim kuruyoruz.
Asıl sorun, orta yönetim siyasetinin her şeyi bulandırması.
Ekibe “ben batırdım, düzeltmem gerekiyor” diyebilirsiniz; ama yukarıda, pek de önemli olmayan kararları bile geri almamak için her türlü bahaneyi üreten insanlar var.
Belki de biri o ekipmanı yöneticisine çoktan “önümüzdeki 10 yıl daha kullanılabilir” diye satmıştır.
Meslektaşlarımla çalışırken, alıcının seviyesine göre farklı derinliklerde açıklamak için epey çaba harcadıklarını görüyorum.
Daha sık olan şey, üst yönetimin ve altındaki yöneticilerin basitçe umursamaması.
Kafalarında zaten “büyük bir plan” var; geliştiriciler o hayalin gerçeğe dönüşemeyeceğini ne kadar söylese de değişmiyor.
Çoğu, ne söylediğimizi gayet iyi anlıyor.
Üst seviye nerd’lerin anlayabileceği anlaşılmaz jargonlar savurmuyoruz; sadece onlar umursamıyor.
MBA tarzı, kafası ve kalbi olmayan insanların şirketleri yönettiği durumlar azalsa ve mühendislerin daha fazla sorumluluk aldığı organizasyonlar artsa güzel olurdu; ama hayat böyle.
Kurumsal IT, ofis çalışanlarına destek işlerinden doğdu; faks makinesi ya da PC çalışıyor diye stratejik planlama gerekmiyordu, bu yüzden başlangıçta önemsiz bir departman muamelesi gördü.
Takım elbiseli insanların cimri ya da aptal olduğu için veya teknolojiden anlamadıkları için böyle davrandığını varsaymak kolay; ama gerçekte çoğu zaman mesele iletişim becerisi eksikliği olabiliyor.
İlk işimde CFO, AS/400 için düzgün bir yedekleme sistemi talebini sürekli reddediyordu.
O AS/400’de ERP, CRM, muhasebe dahil şirketin tüm işleri vardı; 300 kişinin işini 8 inçlik floppy disklere yedeklemek zaten mümkün değildi.
Bir gün büyük bir disk arızası yaşandı ve tüm şirket haftalarca durdu; sipariş işleme, destek talepleri, satış teklifleri, müşteri numarası ve adres sorgulama tamamen kilitlendi.
Bazı disklerin Kroll Ontrack’e gönderildiğini hatırlıyorum.
Ancak o felaketten sonra düzgün yedekleme ekipmanı satın alındı.
Birkaç ay sonra öğrenci bir geliştirici, prod ortamında
wherekoşulu yorum satırına alınmış bir silme sorgusu çalıştırdı ve bir tablo tamamen uçtu.Yedek vardı ama arka plan işi bunu algılayıp 4 yıllık faturaları yeniden oluşturdu ve geçmişteki tüm müşterilere yeniden ödeme yapmalarını isteyen e-postalar gönderdi.
Test ortamı kısa süre sonra kuruldu.
Bir süre önce ücra bir iki yıllık yüksekokulda çalıştım; tüm veriler eski bir AS/400 üzerindeydi ve birkaç haftada bir bir-iki günlüğüne ölüyordu.
Yedek yoktu, teyp sürücüsü bozuktu; o dönem için bile eski sayılan 10Mbps NIC gibi parçaların da yedeği bulunmuyordu.
Değiştirmemiz ya da bir bulut sunucuya taşımamız gerektiğini sürekli söyledim ama gelen yanıt hep “bütçede yok”, “çok pahalı” oldu.
Gerçek kullanıma göre aylık birkaç yüz dolar seviyesindeydi; sistem ölürse tüm okulun çökmesi ve kalıcı olarak kapanması riskiyle karşılaştırınca bu hiç mantıklı değildi.
Sonunda arıza patladı; birkaç gün boyunca ana terminalden erişilebiliyordu ama ağla hiç iletişim kuramıyordu.
İnsanlar paniğe kapılmaya başladı; saati 100 doların üzerinde olan bir AS/400 onarım uzmanı çağırma fikri bile konuşuldu.
Son bir deneme olarak NIC’i tamir etmeyi başardım; sistemin tekrar ayağa kalktığını bildirirken, bunun son açılış olabileceğini ve ondan önce bir yere yedek alınması gerektiğini kesin biçimde söyledim.
6 hafta sonra pırıl pırıl bulut tabanlı bir AS/400’ümüz vardı; o yaşlı, koca canavarı son kez kapatıp cenazesini kaldırdık.
Nihai çalışma süresi neredeyse 25 yıldı.
Bu hikâyenin düşük olasılıklı ya da tamamen uydurma olduğunu söyleyebilirsiniz, ama ben öyle görmüyorum.
Büyük bir organizasyonda bir şeyleri yaptırmak istiyorsanız yönetimin benim acımı hissetmesini sağlamanız gerekir.
Bu sinizm değil; dünya böyle işliyor.
Karşı tarafın, durumu anlamak için gereken tüm zihinsel adımları kendiliğinden atmasını bekleyen kişi sert bir sürprizle karşılaşır.
90’ların başında bile şube ofisleri dışında ISDN yaygın olmazdı.
Üstüne trafik şekillendirme/QoS konusu gelince inanması daha da zorlaşıyor.
O dönemde neredeyse herkesin kullandığı Cisco 2500/2600 yönlendiricilerin bu özellikleri çok daha sonra desteklediğini biliyorum.
Belki T1’den bahsediyordur; güçlü bir r/thathappened havası var.
Tanım gereği yöneticiler uygulayıcılardan farklı işler yapar.
Örneğin berbat bir kod tabanının acısını bir yöneticiye nasıl hissettirebilirsiniz?
İş yerinde Cisco 1604 ISDN yönlendiriciyi sürekli bağlı tutmak yerine otomatik arama yapacak şekilde ayarlayıp maliyetten tasarruf etmeye çalışıyorduk.
Ancak web tarayıcı paketi kurulu IBM AIX’in her saat Big Blue’ya periyodik telemetri araması yaptığını, bu yüzden laboratuvar ağının boşta kalıp kapanamadığını fark ettik.
Yönlendiriciye güvenlik duvarı kuralı ekleyerek bu sinsi davranışı engelledik.
90’ların sonunda bile Microsoft, Sun ve Novell telemetri konusunda IBM kadar yüzsüz değildi.
Burada ortaya çıkan asıl sorun, IT tarafının doğru olduğunu bildiği işleri iş tarafına karşı belli ölçüde bağımsız biçimde yürütecek özerkliğe ihtiyaç duyması.
Sonuçta bir organizasyonda ne kadar denetime katlanılması gerektiğini güven belirler.
Benim bulunduğum yerde müşteriyi etkileyen bir şey değilse izin istememiz gerekmiyor.
Bir makine zorlanıyor görünüyorsa ya da SaaS tarifesi limite yaklaşıyorsa, doğrudan yükseltme yapıyoruz.
Bazen yeni fatura ya da maliyet artışı hakkında soru soran oluyor, ama işi ilerletmek için defalarca sorguya çekilmek gerekmiyor.
Takım elbiseli insanlar, en küçük teknik iş için bile izin dilenmek zorunda kalınan bir ortamın dezavantajlarını düşünmeli.
On yıldan da uzun süre önce fildişi kulede hazırlanmış karmaşık değişiklik politikaları yüzünden ne kadar yenilik doğrudan yanan çöp konteynerine gidiyor?
Organizasyonu, işi IT ekibinin müşterisi olarak modelleyecek şekilde yeniden düşünemez miyiz?
Şirket başarısız olursa IT organizasyonunun da varlık nedeni kalmaz; bu çok daha basit bir düşünme biçimi gibi görünüyor.
Bu yüzden maliyet-fayda dengesi değişir ve iletişim gerekir.
“Senin işin hiyerarşinin kararlarına saygı duymak” tarzı tepkileri görünce, kurumsal organizasyonların hâlâ ne kadar askerî düşünceye saplanıp kaldığını hatırlıyorum.
Eski Prusya ordusunda görevler hedef odaklı aktarılırdı.
“Ben X’i başarmaya çalışıyorum, sen Y’yi üstleniyorsun, diğer birlik Z’yi yapacak” gibi; uygulama ise sahayı gerçekten gören ve gerekli bilgiye sahip yerel subaya bırakılırdı.
Ayrıca bir subay ya da astsubay doğrudan komutanının emrine karşı çıkarsa, bir üst kademeye itiraz edebilirdi.
Kurmay subayların eğitim sırasında komuta deneyimi de kazanmasını ve komutan emirlerini dengeleyebilmesini sağlayan kurmay sistemi de eklenince, değişen koşullara uyum sağlayan güçlü ve esnek bir yapı oluştu.
Subaylar üstleriyle tartışmaktan, konuyu daha yukarı taşımaktan ya da gerçekten gerekli olduğuna karar verirlerse emri reddetmekten çekinmezdi.
Çünkü alt rütbelerin onayı ve katılımı böyle sağlanıyor.
Kararların mümkün olan en alt kademede alınması yaklaşımıydı.
Modern dönemde modası biraz geçmiş olsa da, bildiğim hiçbir ordu yalnızca “senin işin hiyerarşik kararlara uymak” ilkesiyle yönetilmiyor.
Örneğin Extreme Ownership kitabı gibi.
Belki fazla kötü niyetliyim, ama böyle bir liderlik varsa ben sadece yeni bir iş bulur ve tüm geminin batmasına izin verirdim.
Liderlik açısından basitleştirirsek, her yıl benzer 100 öneri geldiğini ve her birinin 1 milyon dolar tuttuğunu varsayalım.
Amortisman ya da vergi oyunlarını çıkarsak bile bu, her yıl 100 milyon dolar saf maliyet demektir.
Banka için bile büyük para; stratejik harcanmalı, israf edilmemeli.
Bu düzende liderliğin acıyı hissetmesini ve bu 1 milyon doların neden iyi harcanmış para olduğunu içgüdüsel olarak anlamasını sağlamak; liderlik, IT ve iş açısından kendi içinde sağlıklı bir stratejidir.
Yöneticilerin şirketin sınırlı zamanını, çalışanlarını, maliyetlerini vb. yöneten kişiler olduğu gerçeği de var.
Elbette genelde bunu özellikle iyi yapmazlar ve şirket açısından tamamen rasyonel seçim, onlara sıradan çalışanlara benzer şekilde daha az lüks bir ücret vermek olurdu denebilir.
Ama karar veren “şirket” değil, insanlardır; bunun içinde siyasi oyunlar, teşvikler ve kişisel çıkarlar vardır.
Yöneticiler bilgi, karar, kaynak ve para akışını kontrol ettikleri için, ev sahibi şirketten aşırı pay emen parazitler gibi davranırlar.
Bu sorunun çözümü okuyucuya alıştırma olarak bırakılmıştır.
Yalnızca “X günü civarında hattın %50 doluluğa ulaşacağını öngörüyoruz” diye duyduysalar, IT gerçekten iyi açıklayamamış demektir.
Biz bu teknolojide %50 doluluğun müşteri gecikmeleri ya da bağlantı hataları anlamına geldiğini biliyoruz.
O zaman “X günü civarında müşterilerin bağlantı sorunları yaşamasını bekliyoruz” demek gerekir.
%100 sınırın yalnızca ideal koşullarda mümkün olan teorik değer olduğunu biliyorsak, fiilen kullanılabilir sınırı temel alarak konuşmalıyız.
İnsanların bilgiye dayalı karar verebilmesi için onlara doğru bilgiyi vermek gerekir; teknolojiyi anladığı için para alan taraf IT ise, bu özellikleri takım elbiseli insanların anlayabileceği şekilde aktarmak da IT’nin işidir.
Elbette ellerinden geleni yapmış olabilirler, ama yazıdan bakınca böyle bir bilgi olmadan sadece not göndermişler gibi duruyor.
“%50 kullanım oranı” ifadesinin, musluğu yarım açmış gibi kullanılmasını pek anlayamıyorum
Tek bir boruda yük sivri şekilde yoğunlaşırsa zaten aralıklı performans düşüşleri yaşanmaz mı?
“Kötü deneyim” yaşanan sürenin oranı, dağılıma bağlı olarak hızla artar; %60 bile dayanması zor olabilir
Kıyaslamak gerekirse, bir barın yalnızca ortalama talebe bakıp tek bir sunucu çalıştırmaya karar vermesi ve cuma gecesinin gelmesi gibi
Kingman formülü tam da bunu anlatır
“Kullanım oranı %50’yi aşınca BT ekibi yeniden ISDN siparişi verilmesini önerdi. Ve yine reddedildi. Kullanım oranı %100’e yaklaşana kadar tekrar sormamaları talimatıyla birlikte.”
Bu, yetkililerin COVID algısına epey benziyor
Sorumlular mevcut trendlere bakıp herhangi bir tahmin yapamıyor, felaket kapıya dayanmadıkça tepki vermiyor gibi görünüyor