CDN kullanan yüksek kullanılabilirlikli bir uygulamanın ölçülmesi için bir öneri arıyorum

Yüksek kullanılabilirlikli uygulamalar için performansı ve kullanılabilirliği doğru bir şekilde ölçmekle uğraşan bir Fortune 500 şirketinde çalışıyorum (örneğin, 5 saniyelik sayfalar arasında gezinme ile% 99,5'e kadar çıkan uygulamalar). Bu kullanılabilirlik numarasını belirlemek için hem planlı hem de programlanmamış kesinti sürelerini hesaba katıyoruz. Ancak, son zamanlarda karışıma bir CDN ekledik, bu da metriklerimizi biraz karmaşıklaştırıyor. CDN artık trafiğimizin yaklaşık% 75'ini yönetirken, geri kalanını kendi sunucularımıza gönderiyor.

"Gerçek kullanıcı deneyimi" dediğimiz şeyi ölçmeye çalışıyoruz (yani, test komut dosyalarımız uygulama üzerinden tıklayan tipik bir kullanıcıyı taklit ediyor.) Bu izleme komut dosyaları ağımızın dışında oturuyor, yani CDN'ye yaklaşık% 75 zaman.

Yönetim kullanılabilirliği ölçmek için en kötü senaryoyu almaya karar verdi. Bu nedenle, kaynak sunucularımızda sorunlar varsa, ancak CDN içeriğe gayet iyi hizmet veriyorsa, kullanılabilirliğe hala değiniyoruz. Aynı şey başka bir yol için de geçerlidir. Benim düşüncem, "kullanıcı deneyimi" başarılı olduğu sürece, kendimizi gereksiz yere cezalandırmamamız gerektiğidir. Sonuçta, performansı ve kullanılabilirliği artırmak için bir CDN var!

Herkesin diğer Fortune 500 şirketlerinin kullanılabilirlik numaralarını nasıl hesapladığı hakkında bilgi sahibi olup olmadığını merak ediyorum. Apple.com'a, örneğin, hiç indirilmemiş gibi görünen bir CDN kullanan bir mağazaya bakıyorum (büyük bir ürün duyurusu olmayacaksa). Sert, olgusal verilerim olması harika olurdu çünkü bu metriklere gereksiz yere zarar vermemiz gerektiğine inanmıyoruz. Biz edilir bu rakamlara dayanan iş kararları.

Bununla birlikte, bu metriklerin yönetime görünür olduğu göz önüne alındığında, sorunlar oldukça hızlı bir şekilde ele alınmakta ve çözülmektedir (okuma: bürokrasiyi oldukça hızlı bir şekilde kestik.) Ne yazık ki, bir geliştirici olarak, yönetimin düşünmesini istemiyorum bazı harici faktörlerin (yani CDN) sayıları etkilemesi nedeniyle uygulamanın yukarı veya aşağı olması.

Düşünceler?

(Yanlışlıkla bu soruyu StackOverflow'a gönderdim, çapraz gönderi için üzgünüm)

Özetde, "mevcut" ile "kullanılamaz" olanı neyin oluşturduğunu keskin bir şekilde tanımlamanız ve kendinizi buna karşı ölçmeniz gerektiğini söyleyebilirim. Örneğin, 1 saniyeden "katlamaya" kadar bir site için ve tamamen oluşturulmuş bir sayfa için 3 saniyelik bir istemci tarafı performans SLA'nız olabilir. Performans SLA'sını karşılamadığınızda, bunu o zaman dilimi için kullanılabilirlik hatası olarak saymalısınız. CDN'ye vurup vurmamanız önemli değil - önemli olan kullanıcı deneyimi.

Ancak, yalnızca 5 dakikada bir ölçüm yaptığınızdan, CDN'ye karşı ana siteye yapılan isabetlerin ayrı ayrı ölçülmesi ve kullanılabilirliğin% 75'inin CDN'den ve% 25'inin master'dan geldiğini hesaplamak mantıklı görünmektedir. Buradaki zorluk,% 75'in sadece bir ortalama olmasıdır. Suçu belirli bir süre boyunca doğru bir şekilde dağıtmak için, bir sitenin veya diğer sitenin ne zaman müşteriyle karşı karşıya olmadığını, örneğin planlanan bir değişiklik sırasında veya bir sorun tespit edildiğinde manuel işlemden sonra bilmeniz gerekir. Ayrıca, ana siteden biri veya CDN kapalı olduğunda ne olacağını da hesaba katmanız gerekir. Müşteri bir HTTP 500 alıyor mu yoksa şeffaf bir şekilde çalışma sitesine geçiyor mu? Çok şey yük dengeleme çözümünüze bağlıdır. Tanımladığınız "en kötü durum" metriği çok basit görünüyor. Kendine sor, "

CDN kapalıyken “suçlama” alıp almamanız gerektiğinde: kesinlikle. İsabetlerinizin% 75'i CDN'ye gidiyorsa, müşteri deneyiminizin% 75'i onlara bağlıdır. Müşterilerinize iyi bir deneyim sağlamaktan sorumlusunuz, bu nedenle CDN'de sorun varsa, bunu kanıtlamak ve sağlayıcı ile takip etmek için mühendislik kaynaklarınızı kullanmanız gerekir.

Düşünülmesi gereken diğer bir şey, ana site uzun süre kullanılamadığında ne olacağıdır. Açıkladığınız gibi, CDN ana sitedeki içeriğin statik bir kopyası gibi görünüyor. Ana site uzun süre kapalı kalırsa, CDN bayatlamaya başlayabilir. Bu nedenle, SLA'nızın bir kısmı tazelik olmalıdır: Tamamen oluşturulmuş bir sayfa için 1 saniyeden 1 saniyeye ve 3 saniyeden fazla, içeriği 15 dakikadan eski olmamalıdır.

User44700 ile hemfikirim, sunucularınız için kullanılabilirlik testini CDN'ye göre ayırmak ve bağımsız olarak ikisini izlemek daha iyidir. Gerçek kullanılabilirliğiniz Sunucu Kullanılabilir * CDN Kullanılabilir olacaktır, çünkü herhangi biri azalırsa - sayfanızın / sitenizin kapalı olduğunu düşünüyorsunuz. Bu, izleme sağlayıcılarından herhangi biri için size daha az maliyetli olacaktır.

Bir tarayıcı testi oluşturma yoluna gitmem ve hangi öğelerin başarısız olduğuna bakmam, Catchpoint gibi bazı şirketlerin "içerik kullanılabilirliği" kavramı var - bu durum için tam olarak istediğiniz şey olmayabilir. Diyelim ki web sayfanızda 404 teslim eden bir dosya için CDN çağrısı var, çoğu izleme çözümü size bunun bir hata olduğunu söyleyecektir - ama gerçekten başarısız olan CDN miydi? Bu dosya daha önemli miydi? belki birisi sadece hiçbir kullanıcı fark bazı kalıntı referans kaldırmayı unuttum.

Daha fazla fikir için bu blog gönderisini okuyabilirsiniz: http://blog.catchpoint.com/2010/07/21/true-availability-of-a-webpage/

SLA raporlaması gerçeği doğru bir şekilde yansıtmalıdır. Kullanılabilirliği bir kullanıcı açısından ölçüyorsanız ve yalnızca ölçümü yapan sunucuda sorunlar yaşanıyorsa, SLA'nızdaki bu sorunu bildirmek kullanıcı deneyimini yansıtmaz.

Kaynak bilgileri yüksek bir standartta tutmak istemeyi anlayabilirim, belki de yanlış olsa bile her zaman rapor eder, ancak nedenini belirten bir notla.

Anlaşmaya varamazsanız, ölçüm sunucusunu daha az yanıltıcı hale getirmek için belki de teknik bir çözüm vardır.

Bilgiler bir kesinti olarak rapor edilirse ve verilmiyorsa, raporlamanın değeri nedir?

Çevremde birden çok kaynaktan rapor alıyoruz. Kullanılabilirliği harici bir perspektiften raporlamak ve insan tarafından girilen ve durumu en doğru şekilde yansıtan birçok faktörü dikkate alan dahili kesinti kayıt sistemimizi rapor etmek için harici bir izleme metodolojisi.

Gomez ve Keynote, bahsettiğiniz metrik türlerini toplamak için kurumsal olarak kabul edilen çözümlerdir. Gomez ayrıca bir google-analytics-esque javascript dosyası sağlayarak son kullanıcı UX'inizi izleyen bir hizmete sahiptir.

Pingdom iyidir: http://www.pingdom.com/

CDN etkin bir siteye sahip bir Fortune 500'üz ve birkaç şey kullanıyoruz. Farklı şeyleri tespit etmek istiyorsanız, farklı şeyleri ölçmeniz gerektiğini doğru bir şekilde belirlediniz. Özellikle ne istediğinizi net değil - bir uygulamanın gerçekte ne zaman kapandığını belirlemenize yardımcı olacak kullanılabilirlik numaraları veya yönetimi arkanızda tutan sayılar. Neyse ...

1. Dış sentetik izleme - Keynote / Gomez / Webmetrics. Eskiden Keynote kullanıyorduk, şimdi Gomez kullanıyoruz. Tabii ki not ettiğiniz gibi, bu aynı zamanda CDN'yi ve diğer harici bileşenleri de içerir - bu da genel SLA'nızı ölçmek için iyidir, ancak uygulamalarınızın SLA'larını belirlemek için çok iyi değildir.

"Bunun dışında CDN" almak için başka Keynote / Gomez monitörü alıp, uygulamalarınızda olarak o noktaya olabilir değil alternatif DNS adını durumlarda ne kullanarak CDN yoluyla. Ancak hala statik varlıkları olduğundan, performans için kullanılabilirlikten daha kullanışlıdır. Ve internet kesintilerini, ajan kesintilerini, vb. Döngüde tutar, bu da bazı amaçlar için uygundur, diğerleri için uygundur.

2. Gerçek kullanıcı izleme. Ağ tabanlı (Coradiant, Tealeaf) ve etiket tabanlı (Jiffy, Gomez) var. Coradiant'ı bir ağ dinleyicisi olarak kullanıyoruz ve burada veri merkezimizde barındırılan varlıkların gerçek kullanıcı tarafından görülebilen performansını belirler - diğer bir deyişle CDN'deki statik önemsiz tüm verileri değil, gerçek uygulamaları belirler. Daha sonra uygulama hata oranlarını ve performansını belirlemek için raporlar yazdık ve Apdex'i (apdex.org) türetilmiş bir metrik olarak kullandık. Bazı durumlarda ağ tabanlı kullanamazsınız (çok fazla trafik var veya öğeleriniz ağda alabileceğiniz yerde barındırılmıyor) ve etiket tabanlı bu kadar güvenilir değil. Son kullanıcı yanıt süresini ve hatalarını görmenin çok büyük bir yararı vardır - gerçek bir kullanıcının yaptığı tüm durumlarda hata yapmayan sentetik bir monitör kurmak kolaydır.

3. Yerel sentetik izleme. Nagios / zabbix / sitescope / diğer yüzlerce. Bir monitörü uygulamanıza yerel olarak yönlendirin (CDN'den geçmeyin). Harekete geçirilebilirlik (olduğu gibi, birini uyandırmak için bir sayfa gönderin) kullanılabilirlik izlemesi için bu altın standarttır. Ağ öğelerini dikkate almaz.

4. Günlük izleme. Bir anlamda, bu getto gerçek kullanıcı izleme. Ama gerçekten ne zaman hatalı olduğunu görmek istiyorsanız, oldukça kullanışlı. Gerçek kullanıcı izlemenin "gerçekten böyle oldu" avantajı vardır. Genellikle Web katmanında zaman harcadığınız sürece yalnızca kullanılabilirlik, bu durumda sunucunuzun sonunun ne kadar sürdüğünü gösterir - SLA ile karşılaşan kullanıcılar için yararlı değildir, ancak "hangi kod üzerinde çalışmamız gerekir?" ." Splunk kullanın.

Ya bir ya da değil, tüm bunları kullanıyoruz, çünkü "son kullanıcı hikayesini" ve "hangi programcıya dayanmamız gerekiyor?"

BrowserMob harika