Açık kaynak yazılımın lisans ücreti düşük ya da sıfır olabilir; fakat güvenlik, güncelleme, izleme ve arıza müdahalesi için mutlaka bir bakım modeli gerekir.
Doğru seçim, sistemin ne kadar kritik olduğuna, kurum içi teknik kapasiteye ve kabul edilebilir kesinti riskine bağlıdır. Küçük ve kritik olmayan araçlarda topluluk desteği yeterli olabilir.
Müşteri verisi, ERP, e-ticaret veya operasyonun sürekliliği söz konusuysa kurumsal teknik destek, danışmanlık ya da yönetilen hizmet değerlendirilmelidir.
Teklifleri yalnızca aylık hizmet bedeliyle değil, SLA kapsamı ve hariç tutulan işler üzerinden karşılaştırmak daha sağlıklıdır. Özellikle tek kişiye bağlı BT yapılarında, dış kaynak BT hizmeti iş sürekliliği açısından önemli bir güvence katmanı oluşturabilir.
Bir Bakışta
- Açık kaynak bakım hizmeti; yalnızca sürüm güncellemesi değil, güvenlik, yedekleme, izleme ve arıza yönetimi işidir.
- Topluluk, iç ekip, danışman ve yönetilen hizmet seçenekleri; sistem kritikliğine ve ekip yetkinliğine göre değerlendirilmelidir.
- Teklif karşılaştırırken SLA kapsamı, mesai dışı müdahale, ek işler ve sorumluluk sınırları yazılı olarak incelenmelidir.
| Destek modeli | Uygun olabilecek durum | Güçlü yönü | Dikkat edilmesi gereken nokta |
|---|---|---|---|
| Topluluk desteği | Kritik olmayan, teknik ekibi güçlü sistemler | Düşük doğrudan maliyet, geniş bilgi havuzu | Yanıt ve çözüm süresi garanti edilmez |
| Şirket içi ekip | Sürekli operasyonu olan ve teknik kadrosu bulunan işletmeler | Sisteme ve iş süreçlerine yakınlık | Tek kişiye bağımlılık ve uzmanlık boşlukları oluşabilir |
| Dış danışmanlık | Belirli sorun, geçiş veya proje ihtiyacı | Belirli uzmanlığa hızlı erişim | Saatlik danışmanlık kapsamı ve müdahale zamanı netleşmelidir |
| Yönetilen hizmet | Kritik altyapı, sınırlı iç kaynak, düzenli izleme ihtiyacı | Planlı bakım, operasyon takibi ve kurumsal destek yapısı | SLA, istisnalar ve ek hizmet bedelleri sözleşmede açık olmalıdır |
Açık kaynak sistemlerde bakım neden yalnızca güncelleme yapmak değildir?
Açık kaynak sistemlerde bakım denince ilk akla sürüm yükseltme gelir. Ancak sağlıklı bir yazılım bakımı süreci bundan daha geniştir: güvenlik yamalarının izlenmesi, bağımlılıkların uyumluluğu, performans takibi, log incelemesi, yedekleme kontrolü ve hata durumunda geri dönüş planı birlikte ele alınmalıdır.
Güvenlik yamaları, uyumluluk ve performans takibi
Her açık kaynak projesinin sürüm politikası, resmi destek süresi ve güvenlik güncelleme takvimi farklı olabilir. Bu nedenle “güncel sürüm” ifadesi tek başına yeterli bir karar ölçütü değildir. Kullanılan eklentiler, işletim sistemi, veritabanı, entegrasyonlar ve özel geliştirmeler de değerlendirilmelidir.
Bakım sorumlusu; hangi bileşenin hangi sürümde olduğunu, hangi güncellemenin test edilmesi gerektiğini ve canlı sisteme ne zaman geçileceğini takip etmelidir. İzleme ve kayıt yönetimi olmadan performans düşüşü veya tekrarlayan hata işaretleri geç fark edilebilir.
Kesinti maliyeti ile lisans tasarrufunu birlikte değerlendirmek
Lisans maliyetinin düşük olması, toplam maliyetin düşük olduğu anlamına gelmez. Bir kesinti sırasında sipariş, müşteri iletişimi, muhasebe kaydı, saha operasyonu veya ekip verimliliği etkilenebilir. Bu nedenle değerlendirme yapılırken lisans tasarrufunun yanında bakım eforu, güvenlik riski, acil müdahale ihtiyacı ve iş kaybı olasılığı da düşünülmelidir.
Toplam sahip olma maliyeti yaklaşımı, yalnızca satın alma anındaki bütçeye değil, sistemin yaşam döngüsü boyunca ihtiyaç duyacağı kaynaklara bakar. Böylece aylık destek paketi daha pahalı görünse bile, kontrolsüz kesinti veya plansız danışmanlık ihtiyacını azaltma potansiyeli bakımından anlamlı olabilir.
Üst yönetim için ilk karar: kritik sistem mi, yardımcı araç mı?
İlk soru şudur: Sistem durursa işletme ne ölçüde etkilenir? İç iletişimde kullanılan yardımcı bir araç ile müşteri verisi veya satış süreçlerini taşıyan bir uygulama aynı destek seviyesini gerektirmez. Kritik sistemlerde müdahale sorumluluğu, iletişim kanalı ve eskalasyon adımları daha net kurulmalıdır.
Destek modeli karşılaştırması: topluluk, iç ekip, danışman ve yönetilen hizmet
Tek bir model her işletme için doğru değildir. Seçim, ekibin teknik becerisi, çalışma saatleri, altyapının karmaşıklığı ve sistemin iş sürekliliğindeki rolüne göre yapılmalıdır.
Hangi model hangi işletme koşulunda avantaj sağlar?
Topluluk desteği, dokümantasyon okumayı ve sorun çözmeyi bilen ekipler için değerli bir kaynaktır. Ancak forum veya hata kayıtlarında bulunan yanıtların işletmenizin ortamına uygunluğu ayrıca doğrulanmalıdır. Kritik bir olayda öncelik sırası ya da yanıt süresi genellikle işletmeniz tarafından belirlenemez.
Şirket içi ekip, günlük ihtiyaçlara hızlı bağlam bilgisiyle yaklaşabilir. Buna karşılık belirli bir uzmana bağımlılık oluştuysa izin, iş değişikliği veya yoğunluk dönemleri risk yaratabilir. Dış danışmanlık, uzmanlık açığını kapatmak için kullanılabilir; fakat hangi işlerin saatlik danışmanlığa dahil olduğu önceden tanımlanmalıdır.
Yönetilen hizmet, düzenli bakım, izleme ve belirli bir destek çerçevesi isteyen işletmeler için değerlendirilebilir. Bu modelde sağlayıcının sadece teknolojiyi değil, kurumun kullandığı sürümleri ve entegrasyonları da anlayıp anlamadığı önemlidir.
Yanıt süresi, çözüm sorumluluğu ve bilgi birikimi karşılaştırması
Teknik destek tekliflerinde “yanıt” ile “çözüm” aynı anlamda kullanılmamalıdır. Bir sağlayıcının kaydı aldığını bildirmesi yanıt süresidir; sorunun kalıcı olarak giderilmesi ise ayrı bir süreç olabilir. SLA kapsamı incelenirken öncelik seviyeleri, çalışma saatleri, iletişim kanalları ve eskalasyon yöntemleri ayrıntılı biçimde okunmalıdır.
Ayrıca bilgi birikiminin kime ait olacağı sorulmalıdır. Yapılan değişikliklerin dokümantasyonu, erişim bilgileri, mimari notlar ve geri dönüş prosedürleri tek bir kişi veya dış firma üzerinde kalmamalıdır.
Karma model: iç ekip ile dış desteği birlikte kullanmak
Birçok KOBİ için dengeli yaklaşım karma modeldir. İç ekip günlük kullanıcı taleplerini ve temel kontrolleri yürütür; dış kaynak BT hizmeti ise güvenlik, karmaşık hatalar, sürüm geçişleri veya acil durumlarda devreye girer. Bu yapı, hem kurum bilgisini içeride tutmaya hem de gerektiğinde uzman desteği almaya yardımcı olabilir.
Bu modelin çalışması için görev paylaşımı açık olmalıdır. “Yedeklemeyi kim kontrol ediyor?”, “Güvenlik güncellemesini kim onaylıyor?”, “Canlı ortama geçişi kim yapıyor?” gibi soruların cevabı yazılı değilse görevler kolayca boşlukta kalabilir.
Bütçe ve değer hesabı: fiyat teklifinde hangi kalemler olmalı?
Destek teklifleri karşılaştırılırken tek satırlık aylık ücret yeterli bilgi vermez. Hizmetin kapsamı, müdahale şekli ve kapsam dışı işlerin nasıl fiyatlandırıldığı toplam bütçeyi doğrudan etkileyebilir.
Aylık destek paketi, saatlik danışmanlık ve proje bazlı hizmet farkı
Aylık destek paketi düzenli kontrol, belirli sayıda destek talebi veya tanımlı operasyonlar içerebilir. Saatlik danışmanlık daha çok belirli bir hata, yapılandırma ihtiyacı veya uzman görüşü için uygun olabilir. Proje bazlı hizmet ise sürüm yükseltme, sistem taşıma, yeni entegrasyon veya mimari değişiklik gibi sınırları belli işler için değerlendirilebilir.
Bu modellerin hangisinin daha uygun olduğu, ihtiyaçların ne kadar öngörülebilir olduğuna bağlıdır. Düzenli bakım gerektiren kritik altyapıda yalnızca ihtiyaç anında danışman çağırmak yeterli olmayabilir. Buna karşılık nadiren kullanılan yardımcı araçlar için geniş kapsamlı bir yönetilen hizmet paketi gereğinden fazla olabilir.
SLA, mesai dışı müdahale ve ek işlerin maliyete etkisi
Sözleşmede standart çalışma saatleri ile mesai dışı müdahale koşulları ayrı görülmelidir. Acil durum tanımının kim tarafından ve hangi ölçütle belirlendiği de önem taşır. Bazı işler; veri kurtarma, altyapı değişikliği, özel geliştirme, yeni entegrasyon veya kapsamlı performans analizi olarak ayrıca ele alınabilir.
Teklif alırken şu noktaları yazılı sorun:
Hangi hizmetler aylık bedeldedir? Hangi işler ek ücrete tabidir? Acil talep nasıl açılır?
Kim onay verir?
TL bazındaki ücretler; kullanıcı sayısı, altyapı karmaşıklığı, müdahale süresi ve sözleşme kapsamına göre değişebileceğinden, tek bir standart fiyat varsayımıyla hareket edilmemelidir.
Toplam sahip olma maliyetinde görünmeyen kalemler
Görünmeyen maliyetler arasında test ortamı eksikliği, zayıf dokümantasyon, eski sürüm bağımlılıkları, yedeklerin geri dönüş testinin yapılmaması ve tek kişiye bağlı operasyon bulunabilir. Ayrıca güncellemenin canlı ortamda beklenmedik etki yaratması, yalnızca teknik değil operasyonel maliyet de doğurabilir.
Bu nedenle teklif değerlendirmesinde yalnızca destek süresini değil, sağlayıcının önleyici bakım yaklaşımını da inceleyin. Düzenli durum raporu, envanter takibi ve bakım planı gibi unsurların kapsama dahil olup olmadığı sorulmalıdır.
Uygulama süreci: bakım planı, güvenlik ve dokümantasyon
İyi bir destek sözleşmesi, düzensiz bir teknik ortamı tek başına düzenlemez. Hizmet başlamadan önce temel envanterin, erişim yapısının ve sorumlulukların netleşmesi gerekir.
Envanter, sürüm takvimi ve sorumluluk matrisi oluşturma
Önce kullanılan sunucular, uygulamalar, veritabanları, eklentiler, entegrasyonlar ve kritik erişimler listelenmelidir. Ardından her bileşen için sorumlu kişi veya ekip belirlenmelidir. Bu basit görünen çalışma, bir olay anında “sistemi kim yönetiyor?” belirsizliğini azaltır.
Sürüm takvimi oluştururken tüm güncellemeleri aynı anda yapmak yerine; önem derecesi, uyumluluk riski ve test ihtiyacına göre plan yapmak daha güvenlidir. Her projenin güncelleme politikası farklı olduğundan, resmi duyurular ve teknik dokümantasyon düzenli kontrol edilmelidir.
Yedekleme ve geri dönüş testlerini düzenli yapmak
Yedek alınması tek başına yeterli değildir. Asıl soru, ihtiyaç halinde geri dönüşün çalışıp çalışmayacağıdır. Yedekleme sorumlusu, saklama yöntemi, erişim yetkileri ve geri dönüş testinin kaydı belirlenmelidir.
Geri dönüş planı, başarısız güncelleme veya veri sorunu durumunda hangi adımların izleneceğini tanımlar. Bu planın yalnızca dış destek sağlayıcısında değil, işletme içinde de bilinen ve erişilebilir bir yerde bulunması yararlıdır.
Güncellemeleri doğrudan canlı ortama uygulamaktan kaçınmak
Güncelleme öncesinde mümkünse test veya benzer bir ortamda deneme yapılmalıdır. Özellikle özel geliştirmeler, eklentiler ve farklı sistemlerle bağlantılar varsa uyumluluk sorunu yaşanabilir. Canlıya geçiş için bakım penceresi, geri dönüş yöntemi ve ilgili kişilere bilgilendirme adımları önceden planlanmalıdır.
Hangi durumda profesyonel destek almak daha mantıklıdır?
Profesyonel teknik destek her açık kaynak kurulumu için zorunlu değildir. Ancak operasyonel risk yükseldikçe, yalnızca topluluk yanıtlarına veya tek bir çalışanın bilgisine dayanmak daha zor hale gelebilir.
E-ticaret, ERP, müşteri verisi ve kesintiye hassas operasyonlar
E-ticaret altyapısı, ERP, müşteri verisi içeren uygulamalar veya gün içinde kesintisiz erişim beklenen sistemler daha dikkatli bir destek planı gerektirir. Bu sistemlerde olay kaydı, önceliklendirme, müdahale yöntemi ve sorumluluk zinciri önceden tanımlanmalıdır.
Kurumsal teknik destek alınacaksa sağlayıcının kullanılan teknoloji ve mevcut mimariyle deneyimi, teklif aşamasında somut olarak sorgulanmalıdır. Genel bir hizmet açıklaması, her sistem için aynı uzmanlığın bulunduğu anlamına gelmez.
Teknik ekip yetersizliği veya tek kişiye bağımlılık riski
Bir sistemin tüm erişim bilgileri, kurulum geçmişi ve müdahale bilgisi tek bir kişideyse iş sürekliliği riski oluşur. Bu durumda dış danışmanlık veya yönetilen hizmet, bilgiyi dokümante etmek ve ikinci bir müdahale kanalı oluşturmak için değerlendirilebilir.
Buradaki amaç iç ekibi tamamen devre dışı bırakmak değildir. En sağlıklı yapı çoğu zaman, kurum içi karar vericinin ve dış teknik sağlayıcının düzenli iletişim kurduğu yapıdır.
Büyüme, denetim ve uyumluluk gereksinimleri
Kullanıcı sayısı, entegrasyon sayısı veya işlem hacmi arttıkça teknik ortam daha karmaşık hale gelebilir. Denetim, erişim kaydı veya dokümantasyon ihtiyacı doğduğunda bakım faaliyetlerinin izlenebilir olması önem kazanır. Hangi yükümlülüklerin geçerli olduğu kurumun faaliyet alanına göre ayrıca değerlendirilmelidir.
Seçim kriterleri ve karşılaştırma özeti
Karar vermeden önce şu noktaları aynı kapsamla karşılaştırın:
- Sistem kritiklik seviyesi: Kesinti olduğunda operasyon, müşteri ve ekip ne ölçüde etkilenir?
- Teknik kapsam: Uygulama, sunucu, veritabanı, güvenlik, yedekleme ve izleme hizmete dahil mi?
- SLA ve eskalasyon: Yanıt, iletişim, önceliklendirme ve mesai dışı destek koşulları yazılı mı?
- Kapsam dışı işler: Saatlik danışmanlık, proje çalışması, sürüm geçişi ve ek müdahaleler nasıl ele alınıyor?
- Dokümantasyon ve erişim: Yapılan işlemler, yapılandırmalar ve acil durum bilgileri kuruma teslim ediliyor mu?
- Uzmanlık uyumu: Sağlayıcının deneyimi, kullandığınız açık kaynak yazılım ve altyapıyla örtüşüyor mu?
Teklif almadan önce bu maddeleri yazılı olarak karşılaştırın. Resmî hizmet açıklamalarında ve sözleşme taslağında ayrıntılı koşulları kontrol etmek, farklı görünen teklifleri aynı karar çerçevesinde değerlendirmeyi kolaylaştırır.
Sonuç Olarak
Açık kaynak sistemlerde doğru destek modeli, yazılımın ücretsiz olup olmamasından çok iş için taşıdığı riskle ilgilidir. Kritik olmayan araçlarda iç ekip ve topluluk kaynakları yeterli olabilir. Kesintinin maliyeti yükseldiğinde ise SLA’lı teknik destek, dış kaynak BT hizmeti veya karma model daha kontrollü bir seçenek sunabilir.
En iyi karar, bütçeyi en düşük tutan değil; sorumlulukları, müdahale sürecini ve bakım kapsamını en açık biçimde tanımlayan karardır.
Bilmekte Fayda Var
1. Açık kaynak projelerinin desteklenen sürümleri birbirinden farklıdır; sürüm politikası resmi kaynaklardan kontrol edilmelidir.
2. “7/24 destek” ifadesi, her tür işin anında çözüleceği anlamına gelmeyebilir; sözleşmedeki yanıt ve çözüm koşulları ayrı okunmalıdır.
3. Yedekleme planı, geri dönüş testiyle doğrulanmadıkça iş sürekliliği açısından tamamlanmış sayılmaz.
4. Dış sağlayıcı değişse bile erişim, dokümantasyon ve yapılandırma bilgileri kurumun kontrolünde kalmalıdır.
Önemli Notlar
Bu değerlendirme genel bir rehberdir. Her açık kaynak yazılımın destek süresi, güvenlik güncelleme yaklaşımı ve teknik gereksinimi farklıdır. Destek sağlayıcılarının fiyatları; kullanıcı sayısı, sistem karmaşıklığı, müdahale süresi ve hizmet kapsamına göre değişebilir. SLA ile garanti edilen yanıt veya çözüm koşulları, ancak ilgili hizmet sözleşmesindeki maddeler doğrulanarak değerlendirilmelidir.
Sık Sorulan Sorular
Q1. Açık kaynak yazılım için ücretli destek almak gerekli mi?
A1. Her durumda gerekli değildir. Kritik olmayan sistemlerde, teknik yetkinliği yeterli bir ekip topluluk kaynakları ve iç süreçlerle bakım yapabilir. Ancak müşteri verisi, gelir üreten operasyonlar, ERP veya kesintiye hassas altyapı söz konusuysa profesyonel destek seçeneğini değerlendirmek daha uygun olabilir.
Q2. Açık kaynak bakım hizmeti fiyatı hangi unsurlara göre belirlenir?
A2. Fiyat; kullanıcı sayısı, altyapının karmaşıklığı, kullanılan bileşenler, istenen müdahale süresi, çalışma saatleri, SLA kapsamı ve sözleşmeye dahil edilen hizmetlere göre değişebilir. Aylık hizmet bedeline dahil olmayan işlerin de ayrıca sorulması gerekir.
Q3. Topluluk desteği ile kurumsal SLA desteği arasındaki temel fark nedir?
A3. Topluluk desteği; forumlar, dokümantasyon ve gönüllü katkılar üzerinden ilerler; işletmeye özel yanıt süresi veya çözüm sorumluluğu genellikle tanımlı değildir. Kurumsal SLA desteğinde ise hizmet kapsamı, iletişim kanalları, önceliklendirme ve yanıt koşulları sözleşmede belirlenebilir. Kesin koşullar için ilgili sözleşme maddeleri incelenmelidir.
