Trust

Geçmiş Olaylar

Bu sayfa, üretim ortamında yaşanmış operasyonel olayların şeffaf kaydını tutar. Her olay için etki, süre, kök sebep ve alınan aksiyonlar açıklanır.

0
Kritik olay (son 90 gün)
0
Açık olay
3
Toplam kayıtlı olay
Eski kurulum betiğinin web üzerinden erişilebilir olması — yönetim veritabanında kullanılmayan tablolar Düşük Çözüldü
28.09.2026 · Etkilenen: Yönetim veritabanı (kiracı verileri etkilenmedi)
  1. 2026-09-28 22:40 Oluşan tüm kalıntılar kaldırıldı; yönetim veritabanı olay öncesi haline döndü. Sağlık kontrolleri temiz. Çözüldü.
  2. 2026-09-28 22:09 Sunucu seviyesinde ikinci koruma eklendi: kurulum/test betikleri ve bağımlılık klasörü web sunucusunda doğrudan engellendi.
  3. 2026-09-28 21:53 Etki analizi: oluşan kayıtlar yedeklendi. Müşteri/kiracı veritabanlarına erişim olmadı; oluşan yönetici kaydı hiçbir giriş akışında kullanılamıyordu (giriş yalnızca kiracı veritabanlarında doğrulanır). Hizmette kesinti yaşanmadı.
  4. 2026-09-28 20:48 Betik yalnızca sunucu komut satırından çalışacak şekilde kilitlendi; web isteklerine artık 404 döner.
  5. 2026-09-28 20:43 Planlı iç güvenlik denetimi sırasında, ilk kurulumdan kalan eski bir betiğin web sunucusu üzerinden erişilebilir olduğu tespit edildi. Denetim aracının yaptığı tek istek betiği çalıştırdı; betik yönetim veritabanında eski şemaya ait boş tablolar ve kullanılamayan bir varsayılan yönetici kaydı oluşturdu.
Postmortem

Ne oldu: İlk kurulumda kullanılan bir betik, uygulama sunucusunun erişim kurallarından birinde engelliyken diğerinde engellenmemişti. Bu açık, dış bir saldırıyla değil, kendi planlı güvenlik denetimimiz sırasında ortaya çıktı.

Etki: Müşteri verisine erişim, veri kaybı veya kesinti yok. Sunucu erişim kayıtları (14–28 Eylül) betiğe gelen tüm isteklerin denetimimize ait olduğunu, tabloların oluşturulma zamanı da betiğin bu olaydan önce çalıştırıldığına dair iz bulunmadığını gösteriyor.

Önlemler:

  • Tüm kurulum/test betikleri artık yalnızca komut satırından çalışır (kod seviyesinde kilit).
  • Web sunucusu erişim kuralları iki katmanda birebir eşitlendi; yeni betik eklendiğinde her iki listeye de eklenmesi süreç kuralı oldu.
  • Otomatik denetim araçlarının canlı ortamda bu tür betiklere hiçbir koşulda istek atmaması kural olarak eklendi.
Super admin paneli 502 Bad Gateway — PDOStatement cast warning loop Yüksek Çözüldü
22.06.2026 · Etkilenen: Süper admin paneli (giriş sonrası dashboard)
  1. 2026-06-22 13:37 MigrationRunner DDL-unsafe çıktı: ilk migrate.php çağrısı "There is no active transaction" verdi. MySQL'de CREATE/ALTER TABLE implicit commit yapar. inTransaction() guard up() ve rollback() içine eklendi.
  2. 2026-06-22 13:35 İkincil noise tespit edildi: td_master.audit_log tablosu yoktu, SA login event'i audit'e yazılamıyor SQLSTATE 42S02 üretiyordu. Master DB'de tablo oluşturuldu, init_master.php + versioned migration 20260622_000001 eklendi.
  3. 2026-06-22 13:31 Hotfix deploy: ölü kod kaldırıldı, hemen altındaki $cntSt = $tdb->prepare(...); $cntSt->execute(); $cnt = (int)$cntSt->fetchColumn(); doğru kullanımı kaldı.
  4. 2026-06-22 13:30 Root cause tespit edildi: super_admin/index.php:41-44'te ölü kod ($cnt = (int)$tdb->prepare(...)) PDOStatement'i int'e cast etmeye çalışıyordu. Bu yalnızca warning, ama 22 aktif tenant'a karşı for-loop'ta tetiklenince Logger her seferinde tek satır JSON'u FastCGI stderr'e basıyordu. nginx tarafında upstream sent too big header → 502.
  5. 2026-06-22 09:48 İlk hata raporu: kullanıcı SA login sonrası /super_admin/index.php'te 502 Bad Gateway alıyor.
Postmortem
Tetikleyici: Geçen sprintlerde super_admin/index.php'e online users mantığı eklenirken eski 4 satırlık deneme blok silinmemiş, ölü kod kalmıştı. Tek başına PHP warning, ama Logger sayesinde her warning artık stderr'e structured log basıyor; aktif tenant sayısı arttıkça (22+) header buffer'a sığmaz oldu. Önlemler: (1) ölü kod kaldırıldı, (2) Logger'ın FastCGI stderr basma davranışı yeniden değerlendirilecek — same-message dedup (rate-limit per-request) bir sonraki sprintte eklenebilir, (3) MigrationRunner DDL-safe oldu — gelecekteki tüm CREATE/ALTER TABLE migration'ları "transaction yok" exception'ı yaşamayacak, (4) master DB'de artık audit_log tablosu var, SA işlemleri (login, tenant create/delete, ai_kb edit) cross-tenant audit_search'te görünecek.
Günlük backup script silent failure (geriye dönük tespit) Yüksek Çözüldü
21.06.2026 · Etkilenen: Günlük yedek, DR güveni
  1. 2026-06-22 02:26 Haftalık integrity check cron kuruldu (Pazar 04:00). İlk run: 8 dosya SHA256 OK, 7 sql.gz gunzip OK.
  2. 2026-06-22 00:04 Yeni multi-tenant aware backup script (v2) yazıldı, deploy edildi. Manuel run: master + 6 tenant + app files = 52MB başarılı.
  3. 2026-06-21 23:00 Logger pipeline kurulduktan sonra yapılan integrity audit'te tespit: 2 ay+ boyunca $DB_NAME env tanımsızlığı yüzünden 388 byte'lık boş dump üretiliyordu.
  4. 2026-04-28 Eski backup script son başarılı çalışmasını gerçekleştirdi (geriye dönük tespit edildi).
Postmortem
Tetikleyici: Yeni sistem secret'larından gelen $DB_NAME bağımlılığı; eski script config.php yerine bekliyordu. Tespit gecikmesinin sebebi: backup tar.gz boyutu kontrol edilmiyordu (bir dosya vardı, başarı sayıldı). Önlem: yeni script min 1KB sanity check + last_run.json meta + /health.php component + haftalık integrity check.

Bu sayfada ne yer alır?

Kronolojik olay listesi: tarih, etkilenen bileşen, önem seviyesi, zaman çizelgesi ve çözüm sonrası yayımlanan postmortem (kök sebep ve önleyici aksiyonlar). Hizmeti etkilemeyen ama şeffaflık gereği paylaştığımız olaylar da burada yer alır. Anlık durum için status.php.

Güncellemelerden haberdar olmak için

Kritik olaylar aktif müşterilere e-posta ile duyurulur. RSS/Atom feed desteği yol haritamızda yer alıyor.