# Trendyol Asistan uygulamasinda sorun yasanmasi

## Olay ozeti
Vault sunucularinda 1 saniyeden fazla surede cevap vermesinden dolayi config-sidecar-injector mutating web hook'unun time out almasi ve kubernetes clusterlarinda podlarin kalkmamasi. Dolayisiyla Trendyol Asistan'in scale olamamasi ve , config-sidecar-injector kullanan uygulamalarin yeni deployment yapamamasi.

## Zaman cizelgesi
Saat 3:13 civari config-sidecar-injector kullanan uygulamalarin kalkmadigina dair sorun bildirildi


Saat 3:32 de ortak kanallarda sorunun bildirilimi yapildi

Saat 4:09 da Trendyol genelinde, config-sidecar-injector kullanan uygulamalarin deployment yapmamasi istendi

Saat 6:02 de sorunun cozuldugune emin olundu

## Etki
Trendyol Asistan'in scale olamamasi

config-sidecar-injector kullanan uygulamalarin yeni deployment yapamamasi

## Nasil haberimiz oldu
Trendyol asistanda scale sorunu yasadiginda

## Nasil daha once haberimiz olabilirdi

- Kube apiserver config-sidecar-injector mutating webhookdan yuksek miktarda request kirilmasi aldiginda alarm
uretebilirdik
- config-sidecar-injector Mutating web hook vaulttan yuksek miktarda time out aldiginda alarm uretebilirdi
- Vault sunucusu yuksek miktar timeout kaynakli request kesilmesi yasadiginda alarm uretebilirdi ayni zamanda 99th percentile response timeler 1 saniyeden uzun oldugunda alarm uretebilirdi

## Neden oldu
config-sidecar-injector Mutating web hook `reasonable defaults` olacak sekilde vault ile iletisiminde vault servisini etkilememek icin 1 saniyeden uzun requestlerin kesilmesini sagliyor, Vault sunucusu 1 saniyeden uzun cevap verdiginde mutating webhook sorun yasadigi icin podlarin kalkmasini engelliyor

Earth datacenter'imizda Vault sunuculari shared resource kullanacak sekilde deployment yapildigi icin o an vmlerin bulundugu hosttaki kaynak durumuna gore darbogaz yasayabiliyor.

## Ne iyi gitti
Yapilan design'a gore consul ve vault servislerini kullanan servisler (monitoring, service discovery, config ve secret management) consul ve vault sunucularindan cevap alamasa bile son aldiklari configle calismaya devam edebiliyor. Bu da bu servislerde olasabilecek her hangi bir kesinti aninda halihazirda calisan seylerin oldugu gibi calismasina sadece yeni kalkmaya calisan uygulamalarin sorun yasamasi anlamina geliyor

## Ne kotu gitti
Monitoring tarafindaki eksiklerimiz yuzunden bu sorunu boyle bir problem yaratmadan once farkedemedik.
Kullandigimiz 4 datacenterin 3 tanesinde tum kaynaklari dedicated olarak verdigimiz icin vault'un shared kaynak kullandigi aklimiza gelmedi. Buda aslinda sorunu yanlis yerde aramamiza neden oldu.

## Nasil cozduk
Earth dc sinde vault servisinin kullandigi kaynaklari dedicated yaparak cozduk

## Ne ogrendik

Monitoring de eksiklerimizin oldugunu SLI/SLO bazli alarmlarin monitoring sistemine dahil edilmesi

Hizmet verdigimiz servislerin tamamini elma elma olmasina emin olmamiz gerekiyor