Teknik lider olarak kullanıcı sayısının on kat artmasını nasıl planlarsınız?

Question

IT Interview Practice · Accepted Answer

Teknik lider olarak önce **“on kat fazla kullanıcı” ifadesini beklenen kullanım, hizmet hedefleri ve ekibin teslim edebileceği bir plana** dönüştürürdüm. Kayıtlı hesap sayısı tek başına en yoğun anda kaç istek geleceğini söylemez.

İşletmenin bir sipariş platformu için kampanya planladığını varsayalım. Soru, mevcut zaman ve bütçe içinde müşterilerin kampanya sırasında hâlâ ürünlere bakıp satın alabilmesi ve onay alabilmesidir.

## 1. Büyümeyi iş yüküne çevirin

Ürün ekibine kullanıcıların ne zaman geleceğini ve hangi işlemleri yapacağını sorun. Bir yıla yayılan kademeli artış, herkesi aynı anda çevrimiçi getiren kampanyadan farklıdır.

Örnek olarak 100.000 kayıtlı hesabın %1'i aynı anda aktifse 1.000 eşzamanlı kullanıcı vardır. %5 aktifse 5.000 olur. Bunlar örnek varsayımlardır, varsayılan oranlar değildir. İstek sıklığı ve istek başına iş de tahmin edilmelidir.

Kampanyanın oluşturduğu yükü listeleyin:

- Popüler ürünler dahil gezinme ve arama istekleri.
- Yoğun zamanlarda sipariş ve ödeme yazmaları.
- Büyüyen depolama ve saklanan geçmiş.
- Bildirimler ve raporlar gibi arka plan işleri.

Böylece sunucu sayısını onla çarpma şeklindeki belirsiz talimat yerine test edilecek iş yükleri elde ederiz.

## 2. Nelerin iyi kalması gerektiğinde anlaşın

Kritik kullanıcı akışları için kabul edilebilir yanıt süresini, hata oranını ve tamamlanmayı tanımlayın. Önemli olan yerlerde veri güncelliği ve kurtarma beklentilerini de belirleyin. Gecikmiş rapor kabul edilebilirken başarısız ödeme kabul edilemeyebilir.

```text
[Campaign assumptions] -> [Expected workload] -> [Service targets]
                                                   |
                                            [Acceptance tests]
```

Hedefler teknik işi müşteri sonuçlarına bağlar. Bir iyileştirmenin yeterli olup olmadığına ve baskı altında hangi hizmet azalmasının tolere edilebileceğine karar vermeyi sağlar.

## 3. Değişiklik seçmeden önce mevcut sınırı ölçün

Üretim gözlemlerini ve temsilî yük testlerini kullanın. Yavaş sorguları, veritabanı bağlantılarını, CPU'yu, belleği, kuyruktaki işlerin yaşını ve dış hizmet kotalarını inceleyin. Yalnızca rastgele istekler değil, popüler öğelere yığılan trafiği de dahil edin.

Sınır veritabanı bağlantılarıysa uygulama düğümü eklemek çekişmeyi artırabilir. Sınır ödeme sağlayıcısının kotasıysa daha hızlı uygulama kotayı yükseltmez.

Normal çalışmanın yanında soğuk önbellekleri ve bir örneğin kaybını test edin. Yalnızca ideal test koşuluna yetecek değil, kampanya sırasında kurtarmaya da yetecek kapasite gerekir.

## 4. Bulguları sahibi belli işlere dönüştürün

| Bulgu | Aday eylem | Gerekli kanıt |
| --- | --- | --- |
| Tekrarlanan pahalı okumalar | Sorguyu iyileştirin veya uygun sonuçları önbelleğe alın | Kabul edilebilir güncellikle daha az veritabanı işi. |
| Arka plan işleri satın alımlarla yarışıyor | Kapasitelerini sınırlayın veya ayırın | Arka plan yükü sırasında ödeme akışı sağlıklı kalır. |
| Bağımlılık kotası yetersiz | Artış sağlayın veya kabulü kontrol edin | Onaylanmış kota ve sınırda test edilmiş davranış. |
| Küçük düzeltmelerden sonra kapasite hâlâ yetersiz | Ölçeklemeyi veya daha büyük tasarım değişikliğini değerlendirin | Ölçülmüş fayda, geçiş planı ve maliyet. |

Her eyleme sahip, bütçe, bağımlılıklar, son tarih ve kabul testi atayın. Yalnızca uygulamayı değil dağıtım işini, operasyon eğitimini ve nöbet hazırlığını da dahil edin.

Müşteri etkisi ve teslim riskine göre önceliklendirin. Büyük bir yeniden yazım veya sharding projesi, gösterilmiş bir neden ve geçiş ile doğrulama için yeterli zaman gerektirir.

## 5. Kampanyanın provasını yapın ve trafiği kademeli artırın

Değişiklikleri yönetilebilir adımlarla yayınlayın ve beklenen akışları birlikte test edin. Trafiğin ne zaman artırılacağını, artışın durdurulacağını veya geri dönüleceğini tanımlayın. Veri biçimi değişiklikleri basit geri alma yerine ileriye doğru düzeltmeyle kurtarma gerektirebilir.

Kontrollü hizmet azaltımı hazırlayın: isteğe bağlı dışa aktarmaları geciktirin, arka plan işini sınırlayın veya kritik işlemleri koruyarak fazla istekleri reddedin. Bu kontrollerin yükü gerçekten azalttığını ve müşterinin açık bir sonuç aldığını doğrulayın.

Hedef tarih veya bütçeye sığmıyorsa ürün ekibine somut seçenekler sunun: kullanıcı kazanımını aşamalandırmak, pahalı bir özelliği azaltmak veya ölçülen darboğaza kaynak ayırmak. Her seçeneğin müşteri etkisini ve belirsizliğini açıklayın.

**Unutmayın:** büyüme varsayımları → hizmet hedefleri → ölçülen sınırlar → sahipli yol haritası → provası yapılmış yayın. Teknik lider insanı, parayı ve kurtarmayı içeren bir kapasite planı sunar.

Bulgu	Aday eylem	Gerekli kanıt
Tekrarlanan pahalı okumalar	Sorguyu iyileştirin veya uygun sonuçları önbelleğe alın	Kabul edilebilir güncellikle daha az veritabanı işi.
Arka plan işleri satın alımlarla yarışıyor	Kapasitelerini sınırlayın veya ayırın	Arka plan yükü sırasında ödeme akışı sağlıklı kalır.
Bağımlılık kotası yetersiz	Artış sağlayın veya kabulü kontrol edin	Onaylanmış kota ve sınırda test edilmiş davranış.
Küçük düzeltmelerden sonra kapasite hâlâ yetersiz	Ölçeklemeyi veya daha büyük tasarım değişikliğini değerlendirin	Ölçülmüş fayda, geçiş planı ve maliyet.

1. Büyümeyi iş yüküne çevirin

2. Nelerin iyi kalması gerektiğinde anlaşın

3. Değişiklik seçmeden önce mevcut sınırı ölçün

4. Bulguları sahibi belli işlere dönüştürün

5. Kampanyanın provasını yapın ve trafiği kademeli artırın

İlgili sorular