Zarif Bozulma: Siteyi Bütün Halinde Değil, Parça Parça Bozmak

Bir sitenin hiç açılmaması, tek bir özelliğin çalışmamasından çok daha kötüdür. Yine de çoğu arayüz tam olarak buna müsait kurulur: harita servisi yanıt vermeyince sayfa boş kalır, tek bir script hata verince form gönderilemez. Zarif bozulma bu zinciri kırar, sitenin bütün halinde değil parçalar halinde bozulmasını sağlar.

Parça parça bozulmak ne demek

Yürüyen merdiven durduğunda normal merdiven olur. Yavaştır, keyifsizdir, ama insanları hâlâ üst kata çıkarır. Bir arayüzden beklenen davranış da budur: tek hata noktası bırakmamak, bir bileşen düştüğünde geri kalanı ayakta tutmak.

BBC Haber sayfası bunun yerleşmiş örneği. Görselden önce gezinme ve haber metni yüklenir, bağlantı yavaşsa ya da bir eklenti çalışmıyorsa görseller gelmez, haber okunur. Adobe Express ise ters tarafta duruyor: bazı tarayıcılarda tek tek özellikler kapanmıyor, sitenin tamamı açılmıyor. Kullanıcının bir cümlelik metni okuyabilmesi için tarayıcı güncellemesi gerekiyorsa orada verilen karar yanlıştır.

Aşamalı geliştirme mi, zarif bozulma mı

İkisi aynı problemin iki ucundan tutuyor. Aşamalı geliştirmede çalışan bir çekirdekle başlarsın, tarayıcı destekliyorsa üstüne katman eklersin. Zarif bozulmada tam donanımlı halden başlar, desteklenmeyen ortamda özellikleri tek tek kapatırsın.

Sıfırdan kurulan projede aşamalı geliştirmeyi zarif bozulmadan daha güvenilir bulurum, çünkü çekirdek yol her ortamda çalıştığı için sürekli test edilir. Zarif bozulmanın yedek yolu ise gerçek hayatta yılda birkaç kez, hep de en kötü anda devreye girer. İkisi rakip değil: aşamalı geliştirme yeni kod içindir, zarif bozulma zaten yayında olan ve baştan yazma lüksü bulunmayan sistemi kurtarma yöntemidir. Çoğu ekip ikincisinin içinde yaşar.

Önce neyi kurtaracağına karar ver

Her işlevi ayakta tutamazsın, tutmaya çalışmak da yanlış yatırım. Kullanıcı verilerine bak, en çok dokunulan akışları çıkar. Kimlik doğrulama, ödeme, içeriğin okunabilmesi kritik listede. Video oynatıcı, gömülü harita, animasyonlu karşılaştırma aracı: bunlar sessizce kapanabilir, yerlerine bir bağlantı ya da düz metin bırakmak yeter.

Bu ayrımı yapmadan yedeklilik konuşmak boşa gider. Neyin kritik olduğu yazılı değilse, hata anında herkes kendi parçasını kritik sanır.

Yedek yolun gizli maliyeti

Yedek yol bedava değil, üstelik maliyeti kod satırında değil test tarafında birikiyor. Birbirinden bağımsız k tane yedek anahtarı koyduğunda ortaya 2^k farklı çalışma durumu çıkar. Beş anahtar 32 kombinasyon demek, bunların hepsini gerçekten deneyen ekip yok. Sonuç tanıdık: yedek yol yazılır, hiç çalıştırılmaz, gerçekten lazım olduğu gün kendisi de patlar.

Bu yüzden az sayıda yedek yol tutup her birini elle tetiklenebilir hale getirmek, çok sayıda yedek yolu ummaktan daha iyi çalışır. Önbellek bunun en kolay örneği: dış API yanıt vermediğinde bayat veriyle sayfayı ayakta tutabilirsin, gecikme de düşer, ama her şeyi önbelleğe alamazsın. Kritik olan birkaç uç nokta yeter. Donanım tarafında yük dengeleme aynı işi görür, trafiği tek sunucuya bağlamaz. Kaç katman yedeklilik gerektiğine karar verirken Uptime Institute'un veri merkezi katmanları makul bir çerçeve veriyor.

Eski tarayıcı ve güvenlik ayarları

Fairleigh Dickinson Üniversitesi'nin Flash duyurusu bu işin nasıl kilitlendiğini gösteriyor: çok faktörlü doğrulama Flash'a bağlıysa, Flash'ı kaldırmış kullanıcı giriş bile yapamıyor. Kimlik doğrulama gibi bir işlevi tek bir eklentiye bağlamamak gerekiyordu.

Aynı sorunun güncel hali güvenlik protokollerinde çıkıyor. Sunucu tarafı eski bir TLS yapılandırmasında kalmışsa tarayıcı siteyi doğrudan engelliyor, arada bozulacak bir şey kalmıyor. Bu tarafta zarif bozulma yok, sadece güncel kalmak var.

Yayına almadan önce bilerek boz

Yedek yolun çalıştığını görmenin tek yolu, ana yolu kapatmak. Tarayıcının ağ sekmesinden ilgili alan adını engelle, bağlantıyı yavaş profile al, JavaScript'i kapat, sayfayı öyle aç. Beş dakikalık bu denemenin bulduğu şeyi, tarayıcı matrisinde gezmek çoğu zaman bulamaz.

Bunun üstüne BrowserStack ile gerçek cihazlarda, WAVE ile erişilebilirlik tarafında kontrol edersin. Mimariyi bu ilkeye göre kurmak isteyen için AWS'nin bozulmayı yönetme rehberi iyi bir başlangıç.

Bir site ancak çalıştığı sürece erişilebilir. Ekran okuyucu uyumu, kontrast, klavye gezinmesi, hepsi sayfa açıldıktan sonra devreye giren şeyler. Zarif bozulma da bunların ön koşulunu kurar: kötü günde bile açılan bir sayfa.