Ülkemiz yazılım üreticilerinin, geliştirmiş oldukları yazılımlara destek verme konusundaki performansları hızla düşüyor. Ekosistem geliştikçe bağımlılıklar artıyor ve çözülemeyen problemler hızla çoğalıyor. "Çözüm Ortağı" firmaların DevOps olarak üstlendikleri rol ise bu performans düşüşüyle birlikte bir kabusa dönüşüyor.
Başlangıçta, yani daha önceki yıllarda sorunlar oldukça hızlı çözülebilirken, artık her bir sorun bir krize dönüşüyor. Sahada koşturan "Bayi" ya da "Çözüm Ortağı" firmalar da giderek başarısız birer DevOps departmanına dönüşüyor.
Bu sorunun çözümü, yazılım üreticilerinin birbirlerinden görüp benimsedikleri destek izleme sistemlerinin ve destek ekibi kompozisyonlarının yeniden yapılandırılması ile mümkün görünüyor. Eğer üreticiler müşteri memnuniyetini olay bazlı toplayıp analiz etselerdi, yaşanan bu sorunu daha erken görebilir, destek ekiplerini uygulama desteği ve DevOps desteği olarak ayırmaları gerektiğini fark edebilirlerdi.
Problem
Önceki dönemlerde basitçe bir sunucuda host edilen tekil uygulamalar, bugün birbiriyle sürekli gelişen entegrasyonların içinde ayakta kalmakta zorlanıyor. Problem çözme hızı ve şekli zaman içinde yavaş yavaş değiştiği için, aslında sorunu fark etmek çoğu zaman son ana kadar kolay değil.
Bir yazılım ürünü için yaşam döngüsünde oldukça kritik olan "DevOps" ve "Uyarlama" fonksiyonlarının, üretici tarafından çeşitli gerekçelerle tamamen "Çözüm Ortağı"na yüklenmesi; sorunun azalmasını değil, tam tersine kontrol edilemez hale gelmesini sağlıyor.
Ürün geliştiricileri, kademelendirilmiş destek hizmetlerini müşteri memnuniyeti temelinde değil, minimum maliyet temelinde yapılandırmakta kararlı görünüyorlar. Üstelik bu yaklaşımı birbirlerinden kopyaladıkları için sorunu fark etseler bile çözüm için harekete geçemiyorlar.
On yılı aşkın süredir bu alanda çalışan ve güçlü ürünleri olan firmaların sahipleriyle görüşüldüğünde ise, yetkin personelin elde tutulamamasından ve doğal olarak destek faaliyetlerinin toplam maliyetinin yüksekliğinden şikayet ediyorlar. Dolayısıyla müşteri memnuniyeti, artık ilk öncelik olmaktan çıkıp arka sıralara düşüyor.
Semptomlar
Bu sorun, temel tehlike olarak kararsız ve zayıf sistemlerin ortaya çıkmasına neden oluyor. Eskiden sıkı ve kapalı kod entegrasyonlar varken, bugün daha esnek ve performanslı REST gibi açık iletişim kanalları tercih ediliyor. Bu durum olağanüstü fırsatlar sunsa da, servisi sağlayan ya da tüketen uygulamada bir hata olduğunda krizlere hızla dönüşebiliyor. Çünkü "Çözüm Ortağı"nın elinde kaynak kod bulunmuyor, üretici ise sadece ürün içindeki fonksiyonlara destek veriyor. Dolayısıyla herhangi bir ürünü güncellemek çoğu zaman tam bir kabusa dönüşüyor.
Basit bir örnek üzerinden ilerleyelim:
Bir uygulamanın web tabanlı olduğunu ve bir reverse proxy arkasında çalıştığını düşünelim. Uygulamanın internete açılması gerektiğinde SSL endpoint’in reverse proxy’de bitecek şekilde yapılandırılması gerekir. Bu durumda DevOps ekibinde hem müşteri tarafı hem de üretici tarafı birlikte çalışmalıdır. İlk kurulumda üretici kendi DevOps ekibinden kaynak tahsis ettiği için kurulum sorunsuz yapılır. Sistem çalışır, ancak bir güncelleme gerektiğinde üretici artık "Ben sadece uygulama içi desteği veririm, DevOps benim işim değil" diyerek desteği reddeder.
Kurulumda beraber çalışabildiğiniz üretici, işletim sürecinde DevOps desteği gerektiğinde konuyu kapsam dışına çıkarmış olur.
Bu sorun, ne yazılım ekosisteminin doğasından ne de müşteri tarafındaki kaynak yetersizliğinden kaynaklanmaktadır.
Çözüm
Üretici firma, saha uygulamalarında "Çözüm Ortağı"nı öne sürüp kendisi geri çekilmezse; son kullanıcılar daha efektif çözümler için daha talepkar olur. "Çözüm Ortağı" tarafından yapılan uyarlamaların uzun vadede tutarlı çalışacağından emin olunabilir. "Firmaya Yazdık" klişesi de yerini "Birlikte çalışıyoruz" anlayışına bırakabilir.
Bu sorun çözüldüğünde, son kullanıcı tarafındaki belirsizlikler ortadan kalkar ve doğrudan iş sürekliliğine katkı sağlar. Aynı zamanda ekosisteme sonradan katılan uygulamaların uyarlanabilmesi için de daha büyük fırsatlar yaratır.
Tüm bu süreçte, nitelikli personelin sahadaki kapasite gereksinimini karşılayacak sayıda ve kalitede bulunması kritik bir faktör olarak göz ardı edilmemelidir.
"Nasıl başlamalı?" sorusuna cevap olarak, ürün desteği ile DevOps desteğinin iki ayrı destek hattı olarak sunulması iyi bir başlangıç noktasıdır. DevOps ekipleri uygulamalar arası etkileşim ve uyumlulukla ilgilenirken, uygulama destek ekipleri ürün içi sorunları çözebilir. Bu ikisi çok farklı yetkinlikler gerektirdiği için tek kişide toplanmaları mümkün görünmemektedir.
Sonuç
Yazılım üreticileri, son kullanıcı desteği konusunda ekiplerini geliştirme, uygulama desteği ve DevOps desteği olarak ayırmalı; destek hizmetleri yönetimini müşteri memnuniyetini olay bazlı takip edebilecekleri bir yapıya dönüştürmelidir.
