On-Prem Çilesi

 

On-Prem Çilesi

O da ne ki diyorsanız, şanslısınız. Ne yiğitler harcandı bu uğurda.

Öyle bir müşteri düşünün ki verileri çok kıymetli, hatta bazı sistemleri intenete kapalı. Bazen mevzuat gereği böyle olmak zorunda bazen ise çözülmek istenmeyen güvenlik sorunları nedeniyle, bazen ise bir nedeni olmayabiliyor. 

Bu kablonun bir ucu sunucuya diğer ucu … — Fotoğraf: Andre Moura

Hayaller SaaS gerçekler on-prem. Düşündüğünüzden çok daha fazla on-prem yazılım hayatınızda. SaaS olarak baslayan bir ürün kurumsal müşterilerin dikkatini çektiginde yolculuk on-prem olarak devam edebiliyor. Neyse, var işte on-prem yazılımlar. Ben çalışmam bunlarla diyorsanız demeyin. Kötü söz döner dolaşır sahibini bulur.

Gelelim sorunlara:

Release cycle planlamak nedir bilir misiniz? Patch icin tarih ayarlamak, release dokümanları yazmak, known-issues dokümanı tutmak, müşteriye özel destek personeli ayarlamak. İşte bunlar hep acıtıyor.

Müşterilerde kalan eski sürümler, kimi eski, kimi cok eski, kimisinden haber yok. Kimisi kullandığı sürümü bilmiyor, kimisi kendi sunucusunun ayarlarını bile yapamıyor. “Bir hata var”dan yola çıkıp hatanın ne olduğunu anlamak bazen haftalar sürebiliyor.

Sadece eski sürümde olan bir hata ile karşılaştığınızı düşünün. Bu hatayı düzeltmek ne kadar zor olabilir? Umarım elinizde o eski sürümün git branch’i duruyordur. Duruyor mu? O kadar da sevinmeyin. Eskiyi anlamak şimdikini anlamaktan daha zor. Mimari değişikliğine, design pattern değişikliğine karar vermiş olabilirsiniz. Diyelim ki hatayı bir şekilde düzelttiniz. Nasıl test edeceksiniz? Yeni bir environment ayağa kaldırarak mı? Ya eski sürümün beraber çalıştığı diğer eski sürüm paketlere ulaşamıyorsanız? Hatta işletim sisteminin o sürümüne erişemiyorsaniz? Ya hataya bozuk veri neden oluyorsa? Kullanıcının eski kullanım alışkanlıklarını taklit edebilecek misiniz? Bununla uğraşmak isteyen bir yazılımcı bulabilecek misiniz? Hadi bu yazılımcı bir kere yaptı bunu defalarca yapmak isteyecek mi bunu? Yazılımcıların uykusunu, havalı yazılım fırmasının havasını kaçırır bu durum.

Veri tabanındaki değişiklikler bitmez. Yeni sütun gelir eski tablo gider. NoSQL de kurtarmaz sizi. Eski bir sürümden yeni bir sürüme geçerken eski kayıtlarla uyum sorunu yaşanabilir. Yeni sürüme geçmiş ama eski sürümü sevdiği için eskisine devam etmek isteyen müşterinin veritabanını kullanılabilir hale getirmek mi? Öyle birşey var mı? Var! 

Bir log dosyasına erişmek için atılan taklalar. “Hata var” dendikten sonra bakılan ilk yer. Log dosyasına erişim için yetkisi olmayan kullanıcılar, log dosyasını ekran görüntüsü olarak paylaşanlar, log dosyasının birkaç satırını paylaşan güvenlik takıntılı kullanıcılar derken o log dosyasını almak herkse nasip olmaz.

Single Sign On’da (SSO) oluşan sorunlar için uygulamanızın suçlanması bir gelenektir. Uygulamaya giremeyen kullanıcılar hemen sizin uygulamanızı suçlar. E-postasına bile giremeyen kullanıcı, parolasını yanlış girdiğini kabul etmez. 

Acil diye önceliklendirilen sorunların bir çoğunun aslında acil olmadığını görünce acilen sakin olmanız gerekir. Acil diye açılan bir destek isteğine işini gücünü bırakıp çözüm bulmaya calışan kişi, karşısındaki kişinin toplantıya katılmadığını, sorunu hatırlamadıgını hatta izne cıktığını görünce yazılımı bırakıp çiftçiliğe başlamayı düşünebilir.

İzne çıkan bir sistem yetkilisi nedeniyle tüm işlerinizin aksaması olası bir durum. Çok güvenlikli çok kurumsal bir müşterinin yedeksiz calışması nedeniyle işlerinizi muhterem bir zata göre ayarlamanız gerekebilir.

Entegrasyon yaptığınız sistemlerde yapılan bir değişiklikten en son sizin haberinizin olması ve sizin suçlanmanız gayet de normal. Kullanıcı ilk yakaldığını öper. 

Yetersiz disk alanı hatasını en son ne zaman gördünüz. Gariptir ki müşteri de bunu görmez. Çıldırmak üzere olan, hatayı bir türlü bulamayan yazılımcıya yukarıdan bir rahmet üzere vahiy indirilirek çektiği acılara son verilir. Kul sıkışmadan Hızır yetismez.

Hiçbir sorun yok mu? Herşey yolunda mı? Alın o zaman size performans sorunları. Müşteri tarafında işler birikir. Daha da birikir. Sonra biriken işler kapıya dayanır. Çok kurumsal müşteri işlerin hemen bitirilmesini personeline söyler. Tüm kullanıcılar sizin uygulmanıza yüklenir. Bir sürü işimiz var uygulamanız calışmıyor diye şikayetler yağmaya başlar. Küçücük bir sanal sunucuya verilen avuç kadar RAM ile uygulamanızı çalıştıran kurumsal müşteri sorunun çözülmesini ister. RAM’in yetersiz olduğunu söyleyen yazılımcıya hemen vaazlar verilir. Bir tek sizin uygulamada sorun var, bizim sistemimiz cok sağlam … Yazılımcı duvara bakar. Çiftçiliğin aslında güzel bir meslek olduğunu düşünür tekrar.

Yazılım nasıl kullanıldığına dair veri alamazsiniz. Kullanıcıların ne şekilde hangi sorunu çözmeye calıştıklari hep bir sır olarak kalır. 

Belki iyi bir şirin olursanız on-prem yazılım geliştirmeden bu dünyadan ayrılabilirsiniz.


Yorumlar

Bu blogdaki popüler yayınlar

KPSS Çalışan Yazılımcı

Yeteneğini Kaybeden Yazılımcı