TL;DR: Yazılım kurmak, çalışan bir sistemi ilk kez ortaya çıkarmaktır; işletmek ise o sistemin değişen veri, bağımlılık, kullanıcı ve mevzuat karşısında yıllarca doğru çalışmasını sağlamaktır. Lansman sonrası en sık kırılan beş alan izleme, veri büyümesi, bağımlılıklar, erişim yönetimi ve bilgi aktarımıdır. Uzun vadeli operasyon, bu beş alanın baştan tasarlanmasıyla mümkün olur.
Bir yazılım projesi genellikle lansman günüyle ölçülür: özellikler tamam, testler geçti, canlıya çıkıldı. Oysa bir kurumsal ürünün ömrünün büyük bölümü lansmandan sonra geçer ve maliyetin de büyük bölümü orada oluşur. Kuran ile işleten arasındaki fark, bu yazının konusudur.
Yazılım kurmak ile işletmek arasındaki fark nedir?
Yazılım kurmak, tanımlı gereksinimleri karşılayan bir sistemi tek seferlik bir hedefe doğru üretmektir. Yazılım işletmek ise bu sistemin süreklilik, güvenlik, veri bütünlüğü ve değişime uyum açısından sürekli sağlıklı kalmasını sağlayan, sonu olmayan bir iştir. İkisi farklı beceriler ve farklı ölçütler ister:
| Boyut | Kurmak | İşletmek |
|---|---|---|
| Hedef | Gereksinimleri karşılamak | Sürekliliği ve doğruluğu korumak |
| Zaman ufku | Proje takvimi | Ürünün tüm ömrü |
| Başarı ölçütü | Teslim edilen özellik | Kesintisiz çalışma, hızlı müdahale |
| Ana risk | Gecikme, kapsam kayması | Sessiz bozulma, bilgi kaybı |
| Maliyet profili | Yoğun ve sınırlı | Düşük ama süresiz |
Lansman sonrası ne kırılır?
Lansman sonrası kırılan şeyler çoğunlukla kod hataları değildir; kodun çevresindeki koşulların değişmesidir. Aşağıdaki beş alan tekrar eden sorun kaynaklarıdır.
1. İzleme: Sistem bozulduğunu kim görecek?
İzleme, sistemin sağlığını ve davranışını sürekli ölçüp sapmayı fark eden mekanizmadır. En tehlikeli arıza, gürültü çıkarmayan arızadır: işlem başarısız olur ama sistem başarılı yanıt verir, kimse fark etmez. Bu nedenle yalnızca "sunucu ayakta mı?" sorusu yetmez; kritik işlemlerin gerçekten sonuç üretip üretmediği de ölçülmelidir. Kontroller üç durumlu tasarlanmalıdır: temiz, bulgu, belirsiz. Ölçüm yapılamıyorsa sonuç "temiz" değil "belirsiz"dir.
2. Veri: Büyüdükçe ne olur?
Veri büyümesi, ilk günde fark edilmeyen sorguların, indekslerin ve yedekleme sürelerinin zamanla darboğaza dönüşmesidir. Test ortamındaki yüz kayıtla çalışan bir ekran, canlıda yüz binlerce kayıtla yavaşlar. Yeni bir alan eklenirken eski kayıtların da doldurulması gerekir; kod yeni alana bağlandığında eski kayıtlar boşsa arama ve raporlar sessizce eksik sonuç döner. Şema değişikliklerinde sıra bu yüzden önemlidir: önce geri doldurma, sonra yeni davranışın açılması.
3. Bağımlılıklar: Dışarıdaki dünya durmaz
Bağımlılıklar, kodunuzun dayandığı paketler, dış API'ler ve platformlardır. Güvenlik yamaları çıkar, bir API sürümü kullanımdan kalkar, bir model veya servis adı değişir. Güncellemeyi ertelemek bir borç biriktirir ve borç en kötü zamanda, kritik bir açık duyurulduğunda tahsil edilir. Düzenli ve küçük adımlarla ilerleyen bir güncelleme ritmi, tek seferlik büyük atlamadan daha ucuzdur.
4. Erişim: Kim neye hâlâ erişebiliyor?
Erişim yönetimi, kimlerin hangi sistemlere, anahtarlara ve yetkilere sahip olduğunun güncel tutulmasıdır. Projeden ayrılan birinin erişiminin kapatılmaması, süresi dolan bir sertifika, kimsenin sahip olmadığı bir gizli anahtar kurumsal sistemlerde sık görülen operasyon olaylarıdır. Her gizli bilgi ve yetkinin bir sahibi ve bir yenileme tarihi olmalıdır.
5. Bilgi aktarımı: Sistem kimin kafasında?
Bilgi aktarımı, sistemin neden böyle tasarlandığının, nasıl dağıtıldığının ve bozulduğunda ne yapılacağının yazılı hâle getirilmesidir. Bilgi yalnızca kişilerde duruyorsa, o kişi ulaşılamaz olduğunda sistem sahipsiz kalır. Tekrar eden sorunların kaydı, dağıtım adımları ve mimari kararların gerekçesi, kodun yanında yaşayan dokümantasyonda tutulmalıdır.
İşletmeye hazır bir sistem nasıl tasarlanır?
İşletmeye hazırlık, bu beş alanı lansmandan önce işe dahil etmektir. Pratik bir kontrol listesi:
- Kritik her işlem için "başarılı oldu" kanıtı üreten bir ölçüm tanımlayın.
- Veri modeli değişikliklerinin deploy sırasını yazılı hâle getirin: kod, geri doldurma, ardından yeniden başlatma.
- Bağımlılık güncellemesi için düzenli bir takvim ve sahip belirleyin.
- Tüm anahtar, sertifika ve yetkiler için sahip ve yenileme tarihi içeren bir envanter tutun.
- Tekrar eden sorunları ve çözümlerini ayrı bir kayıtta biriktirin; her yeni sorunda önce oraya bakın.
- Yedeklemenin geri yüklenebildiğini periyodik olarak deneyin; yedek almak, geri dönebildiğinizi kanıtlamaz.
Bu yaklaşım Exponential'da nasıl uygulanır?
Exponential Yazılım olarak ürünleri teslim edip çıkmayız; uçtan uca operasyonu, yani izleme, bakım, güvenlik güncellemesi ve dokümantasyonu sürecin parçası olarak yürütürüz. Düpas, DigiPilPass, Odimax ve Suversis gibi canlı çalışan kurumsal ürünlerde bu disiplin, tek tek olaylara tepki vermek yerine arızayı büyümeden yakalamayı hedefler.
Kurmak bir kez yapılır, işletmek her gün yapılır. Bir yazılım şirketini seçerken sorulması gereken soru "bunu kurabilir misiniz?" değil, "üç yıl sonra bu sistemi kim, nasıl ayakta tutacak?" sorusudur.