Sunucu sistemlerinde uptime, işletim sisteminin açıldığından beri kapanmadan çalıştığı süreyi ifade ediyor. Uptime süresinin uzunluğu bir sağlamlık ve güvenilirlik göstergesi olarak görüldü.
GNU/Linux’ta bir komutu da olan uptime çıktılarını, sunucu sistemini yönetenler övünçle paylaşırlar:
[root@xxxxx ~]# uptime
12:32:52 up 1243 days, 11:34, 2 users, load average: 1.20, 0.77, 0.54
“Öyle kaya gibi bir sistem ki, bak bu kadar zamandır hiç dokunmadan tıkır tıkır çalışıyor”.
Günümüzde böyle bir sunucu ile karşılaştığımda ise, bende tam tersine bir güvensizlik hissi oluşuyor. Şu sorular aklıma geliyor:
- Yazılımlarda sürekli güvenlik açıkları bulunuyor ve düzeltiliyor. Bu sistemin güvenlik güncellemeleri yapıldı ve devreye alındı mı? Yoksa ciddi güvenlik açıkları mı var?
- Sistem bir nedenden tekrar başlatıldığında gerçekten olduğu gibi açılacak mı? Bu kadar yıl boyunca sisteme elle müdahaleler olduysa, bu değişiklikler sistem açılırken uygulanacak şekilde değiştirilmiş miydi acaba?
- Bir sorun yaşansa, sistem başka bir sunucuya sıfırdan olduğu gibi hızlıca kurulabilir mi gerçekten? Kurum içinde bu bilgi var mı?
Kurumlarda sistem yöneticileri de haklı olarak bu sistemlere müdahale etmekten çekinirler. “Aman, dokunmayayım, kimin nasıl kurduğu da belli değil, yapılan değişiklikleri hatırlayan da yok, bir şey olsa içinden nasıl çıkarız” diye çok temel işlemleri bile zorunda kalmadıkça uygulamamaya çalışırlar. Teknik borcumuz biriktikçe birikir.
Kısaca bu “sağlam”lıklarıyla övündüğümüz sistemler, zamanla birer saatli bombaya dönüşürler. Sadece ne zaman patlayacakları belli değildir. Çünkü her sistem eninde sonunda ya tekrar başlatılır ya da baştan kurularak taşınır.
Peki bu sarmaldan nasıl çıkacağız?
Hiç istemediğimiz ve hazırlıksız olduğumuz bir zamanda bunun başımıza gelmesindense, koşullarını kendimiz belirleyeceğimiz ve hazırlanacağımız bir zamanda saatli bombamızı kontrollü “patlatabiliriz”.
Eğer donanım parkımız yeterliyse, güncellemek yerine, sistemi ayrı bir yerde baştan kurup göç etmek çok daha risksiz olur. Çünkü bir sorun yaşarsak eski sisteme geri dönebiliriz, onu hiç bozmayız. Öteki türlü “yerinde” (in-place) bir güncelleme yaparak, bir sorun yaşarsak o sistemin üzerinde tamirata girişmek zorunda kalırız.
Sağlamlığı ile övündüğümüz bir sistem için, durduk yere bir sürü iş yapıyoruz ve başımıza dert alıyoruz değil mi?
Sorunu bugüne kadar ötelememizin ve bugünden sonra rahat uyumak istememizin bedeli bu. Bedelin karşılığında ise bu kez hiç kapanmayan bir sistem değil, kapansa bile aynı şekilde ayağa kalkabilen bir sistemi hedefleriz. Bir kez kurulan ve unutulan bir sunucu değil, gerektiğinde sıfırdan aynı şekilde hızla kurabileceğimiz bir yapı hazırlarız. Tıpkı konteynerlerde hedeflediğimiz gibi. Bu da bize farklı bir “güvenme” hissi verir. Elimiz titremeden üzerinde işlem yapabilir hale geliriz.
Ya da hiçbir şey yapmayız. İleride bir gece, ansızın, en beklemediğimiz ve en hazırlıksız olduğumuz anda, çok daha fazla kesinti yaşayarak bu sorunla yüzleşmemiz gerekir.
Pick your poison (hangi zehri içeceğimizi seçmemiz gerekiyor).