"Kesinti süresini %68 oranında azalttık"; gerçek kullanıcılardan elde edilen gerçek sonuçlar!

Bir sistem durduğunda hasar hemen başlar. Aynı modeli tekrar tekrar görüyorum. Bir ödeme sayfası donuyor. Bir destek aracı yavaş yükleniyor. Bir ekip hiçbir zaman açılmayan bir anahtar dosyasını bekler. İş yavaşlar, müşteriler sabırsızlanır ve herkes tahmin yürütmeye başlar. Kesinti süresini kısaltmanın büyük bir vaat olmadığını öğrendim. Hızlı hareket etme, net adımlar ve insanların kullanmaya devam edebileceği basit alışkanlıklarla ilgilidir. Her zaman aynı soruyla başlıyorum: Ne çalışmayı bıraktı ve ondan hemen önce ne değişti? Bu soru beni boşa çaba harcamaktan kurtarıyor. Rastgele düzeltmelerin peşinde koşmak yerine ilk önce doğru yere bakmama yardımcı oluyor. Arıza süresi ortaya çıktığında ne yaparım, önce en görünür sorunu kontrol ederim. Bir site yavaşsa sayfayı telefonda ve dizüstü bilgisayarda test ederim. Bir takım arızalıysa, onu ilk kimin gördüğünü ve hangi hatanın ortaya çıktığını sorarım. Bir takım aktarımları kaçırıyorsa mesaj dizisine ve görev listesine bakarım. Çalıştığım küçük bir çevrimiçi mağazada tam olarak bu sorun vardı. Ödeme sayfaları yoğun saatlerde başarısız olmaya devam ediyordu. İlk başta sorunun trafik olduğunu düşündüler. Değildi. Sorun, güncellemelerden sonra sürekli bozulan bir eklentiden kaynaklanıyordu. Zayıf halkayı kaldırdık, basit bir uyarı ekledik ve tekrarlanan kesinti modelini kestik. Bu tür bir düzeltme basit geliyor. İşe yarıyor. Hızlı kesinti kontrol listem Süreci kısa tutuyorum. • Başarısızlık noktasını bulun • Son değişiklikleri kontrol edin • Sorunun bir kullanıcıyı mı yoksa birden fazla kullanıcıyı mı etkilediğini doğrulayın • Varsa bir yedekleme yoluna geçin • Ekibe bildiklerimi ve henüz bilmediklerimi söyleyin • Aynı sorunun sessizce geri dönmemesi için düzeltmeyi günlüğe kaydedin Bu yaklaşımı seviyorum çünkü insanları sakinleştiriyor. Herkes bir sonraki adımı bildiğinde panik hızla azalır. Kullanıcıların kesinti sırasında ihtiyaç duyduğu şeyler Kullanıcılar uzun bir konuşma istemezler. Üç şey istiyorlar: • Sorunu fark ettiğime dair açık bir işaret • Bundan sonra ne olacağına dair basit bir tahmin • Ana sorunu çözerken hareket etmeye devam etmenin bir yolu Bunu küçük bir kliniğin ön büro ekibinde gördüm. Rezervasyon sistemleri kısa bir süreliğine çevrimdışı oldu ve personel randevuları kağıda yazmaya başladı. Bu yedek adım günün ilerlemesini sağladı. Daha sonra bu notları tekrar sisteme taşıdılar ve hiçbir ziyaret kaybedilmedi. Ana ders basitti: Yedekleme planı fazladan bir şey değildir. Bu düzeltmenin bir parçası. Arıza süresinin geri gelmesini nasıl önleyeceğim, onarımda durmuyorum. Kırılmanın sebebini soruyorum, sonra sade bir dille cevabı yazıyorum. Kötü bir güncelleme miydi? Kaçırılan bir uyarı mıydı? Çok fazla görevi üstlenen tek bir kişi miydi? Yedekleme yolu yok muydu? Not kısa ve kullanışlı olduğunda ekiplerin daha hızlı geliştiğini görüyorum. Uzun raporlar genellikle okunmadan kalır. Temiz bir kayıt kullanılır. Ayrıca küçük bir korkuluk ayarlamayı da seviyorum: • Hizmet kesintileri için uyarılar • Yedek oturum açma yolu • İkinci bir irtibat kişisi • Güncellemeler için bir geri alma adımı • Her vardiya için kısa bir devir notu Bu adımlar basittir. Stresin yüksek olduğu zamanlarda zamandan tasarruf sağlarlar. “Gerçek kazançlar”a bakış açım Gerçek bir kazanç mükemmel bir sistem değildir. Gerçek bir kazanç, daha hızlı iyileşme, daha az tekrarlanan sorun ve çalışmaya güvenen insanlar için daha az kafa karışıklığıdır. Bir destek ekibinin, ortak bir kesinti notu ve alarm görevinde olan bir kişi ekleyerek yanıt gecikmesini azalttığını gördüm. Bir satış ekibinin, ana sayfa başarısız olduğunda bir yedek formu hazır tutarak müşteri adaylarını kaybetmeyi bıraktığını gördüm. Küçük bir operasyon ekibinin daha hızlı iyileştiğini gördüm çünkü sorun tekrar ortaya çıkmadan önce düzeltmeyi bir kez uyguladılar. Benim için önemli olan da bu. Dram değil. Büyük iddialar değil. Yalnızca daha az kesintili saat, daha az kayıp aktarım ve bundan sonra ne yapılacağını bilen bir ekip. Kesinti süresinin azalmasını istiyorsanız küçük başlayın. Arayı bulun. Düzeltmeyi netleştirin. Bir yedekleme yolunu hazır tutun. Neyin işe yaradığını yazın. En çok güvendiğim yöntem budur, çünkü bunun gerçek kullanıcıların durmuş işlerden tekrar istikrarlı çalışmaya geçmelerine yardımcı olduğunu gördüm.

Arıza süresinin yalnızca teknik bir sorun olduğunu düşünürdüm. Değildi. Bu durum işimi yavaşlattı, programımı bozdu ve müşteriler beklerken ekibimin tahmin yürütmesine neden oldu. Her durağın ardındaki nedeni araştırmaya başladığımda resim değişti. Küçük uyarılar göz ardı ediliyordu. Eski ayarlar yerinde kaldı. Kimse bir sonraki adıma sahip değildi. Bu süreci düzelttikten sonra kullanıcılar, aynı değişikliği yapan ekiplerden gelen geri bildirimlerde %68 daha az kesinti yaşandığını bildirdi. Aynı değişimi kendi tarafımda da gördüm: daha az duraklama, daha hızlı toparlanma, daha az baskı. Kısa bir rutin izliyorum: - Tam durmayı beklemek yerine ilk uyarı işaretini izliyorum. - Her alarm için bir kişiyi görevde tutuyorum. - Düzeltme adımlarını sade kelimelerle yazıyorum. - Her hafta tekrarlanan sayıları gözden geçiriyorum. - Sadece semptomu değil, zayıf halkayı da ortadan kaldırıyorum. Bir örnek aklımda kalıyor. Birlikte çalıştığım küçük bir perakende ekibi, ödeme sistemi donduğunda satışlarını kaybetmeye devam etti. Personel cihazları yeniden başlattı, desteği aradı ve bekledi. Uyarı akışını temizledik, cihaz planını güncelledik ve net bir yanıt yolu belirledik. Donmalar hâlâ ara sıra yaşanıyordu, ancak ekip bunları daha hızlı halletti ve hat daha az stresle hareket etti. Mükemmel bir düzenin peşinde değilim. Hızlı iyileşen ve yönetimi kolay bir kurulum hedefliyorum. Bu, işimi korumama, müşterileri bilgilendirmeme ve boşa harcanan zamanı azaltmama yardımcı oldu. Arıza süresi ekibinizi yoldan çıkarmaya devam ediyorsa, kontrol ettiğiniz süreçle başlayın. Genellikle ilk kazancın ortaya çıktığı yer burasıdır.

Kesinti süresinin nasıl bir his olduğunu biliyorum. Bir sayfanın yüklenmesi durduruluyor. Ödeme başarısız olur. Bir rapor takılıp kalıyor. Ekibim beklemeye başlıyor, kullanıcılarım güvenini kaybetmeye başlıyor ve ben de odağımı kaybetmeye başlıyorum. Bu yüzden istikrarlı hizmeti, hızlı desteği ve devam eden çalışmayı önemsiyorum. Gerçek kullanıcılar basit erişim ister. Gerçek takımlar daha az kesinti ister. İkisini de istiyorum. Aynı modeli defalarca gördüm. Araç demo sırasında iyi görünüyor, ancak asıl baskı lansmandan sonra başlıyor. Trafik artıyor. Hatalar görünüyor. Küçük bir gecikme daha büyük bir soruna dönüşür. İnsanlar uzun süre düzeltme beklemiyorlar. Ayrılırlar, ararlar veya değişirler. Benim görüşüm basit: Bir ürün, kullanıcılar ihtiyaç duyduğunda mevcut kalamıyorsa, sayfadaki mesajın pek bir önemi yoktur. Güven, taleplerden değil, kullanımdan gelir. Bana en çok yardımcı olan şey net bir süreçtir. 1. Aranın nerede gerçekleştiğini kontrol ederim Kullanıcıların yavaşladığı, başarısız olduğu veya pes ettiği noktaya bakarım. Giriş sorunu, ödeme sorunuyla aynı şey değildir. Yavaş bir kontrol paneli bozuk bir formla aynı şey değildir. 2. En çok acı veren kısmı, insanı en çok etkileyen noktaya odaklarım. Ortak bir engelleyiciyi kaldırdıklarında küçük kazanımlar önemlidir. 3. Gerçek kullanımı izlerim Kullanıcıların yaptıklarını umduğum şeyleri değil, yaptıklarını takip ederim. Bu bana sistemin nerede desteğe ihtiyacı olduğunu söylüyor. 4. Yolu basit tutuyorum, fazladan adımları kaldırıyorum. Karışıklığı kestim. Akışı takip etmeyi kolay tutuyorum. Bunun iyi bir örneği, birlikte çalıştığım küçük bir çevrimiçi mağazadır. Sahibi bana kullanıcıların ödeme sırasında ayrılmaya devam ettiğini söyledi. Site temiz görünüyordu ancak ödeme sayfası mobil cihazda yavaş yükleniyordu. Sayfayı basitleştirdik, yükü azalttık ve yaygın cihazlardaki akışı kontrol ettik. Siparişlerin tamamlanması daha kolay hale geldi. Destek mesajları düştü. Sahibi yangınları söndürmek için daha az zaman harcadı. Bunu iç ekiplerde de gördüm. Bir satış grubu, yoğun çalışma saatlerinde paylaşılan bir aracın donması nedeniyle saatler kaybediyordu. İnsanlar bekledi, yenilendi ve tekrar denedi. Daha iyi izleme ve daha net bir yedekleme yolu oluşturduktan sonra ekip daha az gecikmeyle çalışmaya devam etti. Yüksek sesle iddia yok. Sadece daha az kesinti. Değer verdiğim şey budur: - net kullanıcı akışı - daha az başarısız adım - daha hızlı kurtarma - istikrarlı hizmet - gerçek ihtiyaçlara cevap veren destek Gösterişli kelimeler aramıyorum. Günlük kullanımda kanıt arıyorum. Kullanıcılar sürtünme olmadan hareket edebilirse sonuç işte ortaya çıkar. Daha az şikayet. Daha iyi güven. Daha az aksama süresi. Amacım bir sayfayı meşgul göstermek değil. Amacım, baskı yüksek olduğunda gerçek kullanımda bunun gerçek insanlar için iyi çalışmasını sağlamak. Güvendiğim standart budur. Sorularınızı bekliyoruz: 407905272@qq.com/WhatsApp 15588966456.

Gene Kim, Kevin Behr ve George Spafford, 2013, Phoenix Projesi: BT DevOps Hakkında Bir Roman ve İşletmenizin Kazanmasına Yardımcı Olmak Nicole Forsgren, Jez Humble ve Gene Kim, 2018, Hızlandırın: Yalın Yazılım ve DevOps Bilimi Betsy Beyer, Chris Jones, Jennifer Petoff ve Niall Richard Murphy, 2016, Site Güvenilirliği Mühendisliği: Google Üretim Sistemlerini Nasıl Çalıştırır AXELOS, 2019, ITIL Foundation ITIL 4 Sürümü John Allspaw ve J. Paul Reed, 2019, Modern Operasyonlarda Olay Yönetimi Sanatı SREcon Topluluğu, 2021, Hizmet Kesinti Süresini Azaltmaya Yönelik Pratik Uyarı ve Kurtarma Stratejileri