6 korkutucu kesinti hikayesi

1. Honeycomb CTO'su Charity Majors

• Belirli bir bölgedeki (Doğu Avrupa) kullanıcılara push bildirimi gitmiyordu

• ASG boyutu değiştirildikten hemen sonra başladı

• Round Robin DNS kaydı UDP paket boyutunu aştığı için meydana geldi

2. Gremlin CTO'su Matthew Fornaciari

• Disk dolduğu için log yazılamadı ve kesinti yaşandı

• Log rotasyonu özelliği geliştirildi

• Disk kullanım uyarısı ayarlandı

• Gremlin üzerinden test edilebilir olacak şekilde eklendi (kaos mühendisliği)

3. Rookout CTO'su Lirran Haimovitch

"Sunucunun her gün belirli bir saatte çöktüğüne dair bir şehir efsanesi vardı,

haftalar süren araştırmanın sonunda sebebin güvenlik kamerası olduğu ortaya çıktı,

temizlik görevlisi elektrikli süpürgeyi bağlamak için sunucu bağlantısını kesiyordu"

4. Lightstep CTO'su Daniel "Spoons" Spoonhower

• Uygulama yüklenmiyordu

• O gün dağıtım yapılmamış, altyapıda da değişiklik olmamıştı

• Sorunun yalnızca iç kullanıcılarda yaşandığı doğrulandı

• Uygulama yükleme API'si incelenirken, iç kullanıcılar için ek veri döndüren bölüm tespit edildi

• Son birkaç haftadır payload yavaş yavaş büyüyordu ve o gün öğleden sonra maksimum payload boyutunu aşarak uygulamanın yüklenememesine yol açtı

5. LogDNA CTO'su Lee liu

6. Transpoit CTO'su Ting Huang

• Twitter mobilde okunamıyordu

• Yeni kütüphanede session cookie ayrıştırılamama sorunu bulundu

[kunggom]

Özetlenmeyen 5. durumda mesele sertifika süresinin dolmasıyla ilgili görünüyor.

Sertifikanın planlandığı gibi süresinin dolmasının sorun yaratmayacağını düşünmüşler, ancak bunun yalnızca yeni geliştirilen sistemler için geçerli olduğu; hâlâ kullanılan legacy sistemlerde ise sorun çıktığı anlatılıyor. Üstelik kullandıkları CI/CD çözümünde de aynı sorun patlayınca işler daha da karmaşıklaşmış.

[kbumsik]

"Temizlik görevlisi, elektrikli süpürgeyi bağlamak için sunucu bağlantısını kesti"

Aman tanrım...

[kunggom]

Aslını okuyunca, söz konusu kısmın sadece giriş yapmak için yazıldığı; asıl sorunun ise müşteri tarafındaki yöneticinin toplantı sırasında ya da ara sıra kullandığı bir sorgunun tüm tabloyu kilitlemesi yüzünden, her seferinde backend servisinin gecikme süresinin sınırsızca uzaması olduğu anlaşılıyor. Şüpheli sorguyu optimize etmişler ama yanlış izi takip ettikleri için, müşteri tarafı sayfa çok yavaş diye sürekli yeniledikçe aynı durumun tekrar tekrar yaşandığı söyleniyor.

[kunggom]

Benzer sayılabilecek bir kişisel deneyimim var. Freelance olarak aceleyle gelen bir e-ticaret sitesi işi aldığım zamandı.

Şafak vakti sitede büyük bir çalışma yaptık (çözümün kapsamlı bir sürüm yükseltmesi), ürün ödemesi gibi ana işlevlerde sorun olmadığını doğruladıktan sonra siteyi yeniden açtık. Ancak öğleden sonra birden e-ticaret sitesi aşırı yavaşlamaya başladı, sonunda neredeyse durma noktasına geldi. Sonradan anlaşıldı ki sebep, siteye ayrı olarak bağlı satıcı sayfasıymış. E-ticaret çözümüne özel geliştirilmiş bir satıcı yönetim sayfası entegre edilerek işletiliyordu ve oraya girildiği anda çok ağır bir sorgu çalışıyordu. Site yeniden açıldıktan sonra satıcılar satış durumlarını görmek için her bağlandığında MySQL üzerindeki yük arttı ve sonuçta sitenin kendisi yavaşladı. Baktığımda, ilgili tabloda nedense indekslerin düzgün tanımlanmadığını gördüm. Sonunda indeksleri düzgün ekleyip birkaç parametreyi tune ederek sitenin yavaşlama sorununu çözebildik.

[kbumsik]

Vay, deneyim paylaşımı için teşekkürler.

Gerçi admin işleri ya da iş kararları için kullanılan verilerde aggregation kullanıldıkça yük epey artıyordur. Ben web geliştiricisi olmadığım için tam bilmiyorum ama bugünlerde buna veri mühendisliği deyip verileri ayrı yerde topluyor gibiler.

[kunggom]

Dediğiniz gibi, böyle verileri ayrı şekilde ayırıp işlemek işin doğrusu olurdu ama benim üzerinde çalıştığım e-ticaret sitesi, mantıksız tarafı epey fazla olan bir legacy sistemdi; bu yüzden mimari açıdan böyle bir değerlendirme hiç yapılmamıştı. Oldukça eski bir MySQL sürümü (InnoDB değil MyISAM'ın varsayılan motor olduğu dönemin sürümü), yine eski bir Apache web sunucusuyla birlikte aynı VM instance içinde çalışıyordu. E-ticaret sitesini işletmek için kullanılan çözüm de artık legacy olarak sınıflandırılmış, sadece yama alan bir durumdaydı. Çalışırken hissettiğim çözümün yapısal sorunları, anlaşılan sıfırdan geliştirilen yeni sürümde en baştan çözülmüş, ama legacy sürüme dokunan benim için bunun hiçbir etkisi olmadı. Düşününce bunun üzerinden daha geçen yıl geçmiş.