Bakım penceresi önce kapsamdır
Bakım planının en önemli cümlesi çoğu zaman şudur: “Bu bakımda ne yapmıyoruz?” Çünkü kapsam belirsizse, küçük bir minor upgrade sırasında parametre değişikliği, indeks bakımı ve uygulama yayına almau aynı pencereye sıkışır. Bir şey ters giderse nedenini ayırmak zorlaşır.
İyi bakım tek bir ana değişiklik etrafında kurulur. Önce amaç, etkilenecek clusterlar, beklenen kullanıcı etkisi, geri dönüş eşiği ve doğrulama adımları yazılır.
- Bakım amacı: minor upgrade, parametre değişikliği, indeks bakımı veya kapasite değişimi açık yazılır.
- Etki beklentisi: kesinti yok, kısa reconnect, degraded read veya bakım modu gibi ifade edilir.
- Rollback eşiği: hangi metrik veya hata oranında geri dönüleceği önceden belirlenir.
- İletişim zamanı: müşteriye veya iç ekibe hangi saatlerde güncelleme geçileceği netleşir.
Preflight: yapmadan önce durup bakma alışkanlığı
Preflight kontrolü, bakımın gerçekten başlamadan önceki emniyet kemeridir. Cluster sağlıklı mı, son yedek başarılı mı, PITR penceresi beklenen yerde mi, devam eden olay veya migration var mı? Bunlar temiz değilse bakım ertelenebilir.
Bakım öncesi TürkDB kontrolü
turkdb cluster get app-db turkdb cluster events app-db --limit 30 turkdb backup list app-db turkdb cluster pitr window app-db turkdb cluster maintenance rollout create app-db \ --type db_minor_update \ --preflight \ --dry-run
Dry-run çıktısı temiz değilse bakım penceresini “bir bakıp çıkarız” diye zorlamayın; önce nedeni anlayın.
Bakım sırasında tek değişiklik, net gözlem
Bakım başladığında amaç hızlı olmak değil, okunabilir olmaktır. Değişikliği yapın, beklenen sinyalleri izleyin, uygulama temel doğrulama testini çalıştırın. Bu sırada yeni yayına alma, farklı parametre değişikliği veya plansız indeks operasyonu eklemeyin.
Uygulama tarafında sadece veritabanı bağlantısı değil, kritik iş akışları da test edilmelidir. Ödeme, sipariş, raporlama veya login gibi sisteminiz için en anlamlı küçük akışı seçin.
Kısa bakım temel doğrulama testi
turkdb connect app-db --no-tunnel curl -fsS https://app.example.com/healthz curl -fsS https://app.example.com/internal/smoke/db-read curl -fsS https://app.example.com/internal/smoke/db-write
Gerçek uç nokta adları uygulamanıza göre değişir. Önemli olan temel doğrulama testin bakımdan önce hazır ve güvenilir olmasıdır.
Rollback kararını olay anında icat etmeyin
Bakımda en zor an, “biraz daha bekleyelim mi, geri mi dönelim?” anıdır. Bu karar önceden yazılmadıysa ekipler doğal olarak umutla bekler. Oysa bazı sinyaller geri dönüş gerektirir: hata oranı, veri yazma sorunu, beklenmeyen gecikme veya replikasyon gecikmesi.
Rollback planının varlığı bakımın başarısız olacağını göstermez; tam tersine, ekibin sistemi ciddiye aldığını gösterir.
Rollback eşiği örneği
Rollback kararı ver: - 10 dakika boyunca API hata oranı > %2 - db-write temel doğrulama testi başarısız - p95 gecikme bakım öncesinin 3 katı ve düşmüyor - yeni bağlantı hataları artmaya devam ediyor Rollback sonrası: - uygulama temel doğrulama testi tekrar çalıştırılır - cluster events not edilir - müşteri/ekip güncellemesi geçilir
Bakım kapanışı küçük bir rapor ister
Bakım bittiğinde takvim davetini kapatıp gitmeyin. Başlangıç/bitiş zamanı, yapılan değişiklik, görülen etki, doğrulama sonucu ve takip işleri kısa bir notla yazılsın. Bir sonraki bakımın kalitesi bu notlardan doğar.
- Preflight sonucu temiz miydi?
- Beklenen kullanıcı etkisi gerçekleşti mi?
- Smoke testler hangi saatte geçti?
- Alarm eşiği doğru muydu?
- Tekrar eden manuel adım varsa otomatikleştirilecek mi?