16 | Bulut Hizmetlerinde Kesinti Anı Kullanıcıya Nasıl Anlatılmalı?
Bir web sitesinin sunucu altyapısı çalışmadığında ziyaretçi çoğu zaman yalnızca beyaz ekran veya belirsiz hata kodu görüyor. Oysa modern platformlar birden çok bulut hizmetine bağlı olabilir; sorunun yeri ile kullanıcının gördüğü belirti farklıdır. Teknoloji gündeminde dayanıklılık denildiğinde yedek sunucu kadar açık durum iletişimi de önem kazanıyor. İnsanlar işlemin tamamlanıp tamamlanmadığını bilmek ister.
Hata mesajı işlem bilgisidir
Giriş sayfası açılmazsa tekrar denemek kolay görünebilir. Fakat ödeme veya form gönderimi sırasında hata çıkarsa aynı işlemi tekrarlamak sonuçları karıştırabilir. Bu nedenle ürün, ‘istek alınmadı’, ‘işlem sürüyor’ ve ‘sonuç bilinmiyor’ durumlarını ayırmalı. Belirsizliğin dürüstçe belirtilmesi, sahte kesinlikten daha güvenlidir. Durum sayfası bağımsız bir altyapıda barındırılıyorsa ana sistem kapalıyken de bilgi verebilir.
Arama trafiği kesintide artabilir
betrupi ya da betrupi giriş aramalarının ardından bir siteye ulaşamayan kullanıcı, sorunun kendi bağlantısında mı yoksa hedef sistemde mi olduğunu anlamaya çalışır. Bu bağlantılar ilgili adresin kesinti geçmişine dair bilgi vermez; yalnızca kullanıcı davranışını örnekler. Platformların kesinti sırasında sahte destek hesaplarının ortaya çıkabileceğini de hesaba katması gerekir. Resmi duyuru kanalı önceden belirlenmiş olmalı.
Dayanıklılık testinin kapsamı
Yedek veri merkezi bulunması tek başına yeterli olmayabilir. Kimlik doğrulama sağlayıcısı, ödeme bağlantısı veya içerik ağı çalışmadığında hangi işlevlerin devam edeceği test edilmelidir. Deneme tatbikatları yalnızca mühendisler arasında değil, destek ve iletişim ekipleriyle de yapılmalı. Çünkü kullanıcı teknik kök nedeni değil, kendi işleminin durumunu sorar. Yanıtı veren ekip güncel bilgiye erişemiyorsa sistemin iç koordinasyonu da aksıyordur.
16 | Olay sonrası iletişim
Kesinti sona erdiğinde yalnızca yeşil durum göstergesi paylaşmak güven için yeterli olmayabilir. İşlemleri beklemede kalan kişiler hangi kayıtların tamamlandığını öğrenmek ister. Kurum olay zaman çizelgesini paylaşırken ilk belirti, tespit, müdahale ve normalleşme saatlerini ayırabilir. Sebep henüz kesinleşmediyse tahmin ile bulguyu karıştırmamalı. Sonradan yayımlanan inceleme, önleyici değişiklikleri ve tekrarlanabilecek riskleri açıklamalı. Hizmetin bir kısmı çalışırken başka kısmı aksadıysa ‘tam kesinti’ gibi tek ifade yetersiz kalabilir. Kullanıcı odaklı durum sayfasında giriş, işlem ve destek ayrı başlıklarla gösterilebilir. Ayrıca erişim sorunu yaşandığında sahte destek hesaplarının yayılmaması için resmi kanallar tek yerde listelenmeli. Dayanıklı hizmet, aksiliği gizlemek yerine etkisini doğru tarif eden hizmettir.
16 | Kullanıcının takip yolu
Sorun sırasında sosyal medyadaki her açıklamaya güvenmek yerine kurumun önceden bilinen durum sayfasına veya resmi hesabına bakmak gerekir. İşlem durumu belirsizse destekten teyit almadan aynı talebi defalarca göndermek yanlış sonuç yaratabilir. Sistem iyileştiğinde de önceki işlemlerin akıbeti açıklanmalıdır. Kesintiyi bitiren teknik müdahale ile kullanıcıdaki belirsizliği bitiren iletişim farklı işlerdir; ikisi tamamlanınca olay gerçekten kapanır.
Kesinti haberi yalnızca kaç dakika sürdüğüyle ölçülmemeli. Yanlış yönlendirme, tekrarlanan işlem ve açıklamasız bekleme kullanıcı etkisinin parçalarıdır. Şeffaf zaman çizelgesi paylaşan ve olay sonrası neyi değiştirdiğini anlatan ekipler güveni daha sağlıklı kurar. Teknoloji hizmetinin kalitesi kusursuz çalışma iddiasında değil; aksilik yaşandığında kontrolü, bilgiyi ve seçenekleri kullanıcıya geri verebilmesindedir.
