Havacılık Verisi · Geriye Bakış · Kasım 2026

IST rötar veri hattını neden kapattım.

Mayıs – Ekim 2026 arasında küçük bir veri hattı İstanbul Havalimanı için bir rötar veri seti kurdu — Mayıs–Temmuz için ücretli geçmiş veri, sonra her gece toplama — ADS-B izleri ve hava durumuyla birleştirdi; burada bir rötar veri seti, bir model ve canlı bir tahmin panosu yayınladı. 14 Kasım 2026'da kapattım. Gerçek sonuçlar üretti, ama güvenilir veri üretmeyi bırakalı iki ay olmuştu ve bunu kimse fark etmedi — ben de dahil. Bu sayfa ne bulduğunu, onu neyin bozduğunu ve zamanımı neden makine mühendisliğine geri verdiğimi anlatıyor.

136.459uçuş, Mayıs – Eylül 2026 arasındaki 134 temiz günde toplandı

%11,8yolcu kalkışı kapıdan 15+ dk geç ayrıldı

0,729canlı AUC — kalkıştan önce puanlanan 1.067 gerçek uçuşta; aynı yöntemin çevrimdışı testi 0,711–0,716 demişti

3dış servise bağlıydı — artı onları bağlayan hesaplar ve anahtarlar

Zaman çizelgesi

Altı ay, üç veri kaynağı, tek kişi.

1 May – 26 Tem · ücretli geçmiş veriGünde ~1.500 uçuş. Veri setindeki her şeyin %96'sı bu 85 günden geliyor.
27 Tem · ücretsiz kotaGünde ~100 uçuşa düştü — ücretsiz tarife API'si ayda 100 isteğe izin veriyor. Canlı bir pano için yeterli, bütün bir havalimanı için değil.
17 Ağu – 5 Eyl · aynı anda üç arızaOpenSky İstanbul kapsamasını kaybetti, OpenSky API hesabım devre dışı kaldı ve bu siteye yayın yapan erişim anahtarının süresi doldu. Hesabı ve anahtarı elle düzelttim; kapsama Eylül başında kendiliğinden geri geldi.
13 Eyl · sessiz olanTarife sağlayıcısı "delay" alanının neyi ölçtüğünü değiştirdi. Hiçbir hata çıkmadı. Bu sitedeki rötar oranı bir gecede yaklaşık %13'ten %66'ya çıktı. Ayrıntılar aşağıda.
11 Eki · OpenSky yanıt vermiyorGitHub sunucularının OpenSky'a ulaşmasını sağlayan aracı üzerinden giden her istek HTTP 502 ile dönmeye başladı. Günlük uçuş sayısı ~100'den 0–2'ye düştü. Her çalıştırma yine de "başarılı" göründü.
14 Kas · kapatıldıİş akışları devre dışı bırakıldı, sayfalar temiz döneme (1 Mayıs – 12 Eylül) sabitlendi, bu yazı yayınlandı.

Sessiz arıza

İstanbul birden beş kat gecikmeli olmadı. Tanım değişti.

Rötar etiketi tarife sağlayıcısından geliyordu ve bu sağlayıcı rötar değerini yalnızca bazı uçuşlar için bildiriyordu. Boş değeri "zamanında" saydım ve bunu bir kez bağımsız bir kaynakla — OpenSky'ın ADS-B zaman damgalarıyla — doğruladım; tuttu. Sonra 13 Eylül'de sağlayıcı değeri uçuşların ~%30'u yerine %98'i için doldurmaya başladı ve 15+ dk rötarlı sayılan kalkışların payı yaklaşık %13'ten yaklaşık %66'ya sıçradı.

Bağımsız zaman damgaları neyin değiştiğini gösteriyor. 13 Eylül'den önce bildirilen rötar, uçağın havada görülmesinden yaklaşık 25 dakika önce bitiyordu — kapıdan ayrılışı ölçüyordu, taksi sonra geliyordu. 13 Eylül'den itibaren havalanmadan yalnızca ~1,5 dakika önce bitiyordu — artık kalkışı ölçüyor, yani İstanbul'un ~20 dakikalık taksisini de içine alıyordu. Bu arada tarifeden havalanmaya geçen süre hiç değişmedi.

Sayıları göster

Hafta	Kalkış	Rötar değeri dolu	15+ rötarlı	Tarife→havalanma (dk)
27 Nis	532	24%	9.0%	—
4 May	3.914	29%	11.7%	—
11 May	4.377	38%	17.2%	—
18 May	4.731	29%	12.6%	—
25 May	4.956	26%	10.3%	22.4
1 Haz	4.658	26%	10.3%	22.3
8 Haz	2.688	32%	12.9%	23.1
15 Haz	5.275	27%	11.5%	21.9
22 Haz	5.264	25%	11.4%	22.4
29 Haz	5.912	26%	12.1%	22.5
6 Tem	5.543	30%	12.6%	22.4
13 Tem	5.663	30%	14.1%	23.3
20 Tem	5.668	43%	19.5%	24.4
27 Tem	1.196	35%	13.1%	25.0
3 Ağu	736	31%	12.0%	21.0
10 Ağu	688	35%	14.2%	23.6
17 Ağu	568	42%	16.5%	—
24 Ağu	740	44%	21.1%	—
31 Ağu	323	40%	13.9%	19.8
7 Eyl	693	45%	17.3%	25.0
14 Eyl	644	99%	61.6%	19.7
21 Eyl	664	99%	65.2%	21.2
28 Eyl	640	99%	74.2%	22.6
5 Eki	579	99%	65.8%	20.4

Bedeli: sorunsuz görünen dört haftalık veri, bunun üzerinde yeniden eğitilen bir model ve tahminleri %16 derken "gerçek" oranı %59 gösteren canlı bir pano. Pano uçuşları hâlâ makul bir sırayla diziyordu (AUC 0,667), ama olasılıkları anlamını yitirmişti. Bunların hepsi arşivlenmiş sayfaların dışında bırakıldı.

Neden bırakıyorum

Ayakta tutmak mühendislik değil, bakım olmuştu.

Böyle bir veri hattı üç dış servisin birlikte çalışmasına bağlı: bir uçuş takip ağı, ticari bir tarife API'si ve bir aracı sunucu — bir de bunları birbirine bağlayan anahtarlar ve hesaplar. Her biri kendi takviminde, haber vermeden değişiyor: kapsama kayboluyor, bir hesap kapatılıyor, bir alanın anlamı sessizce değişiyor, bir sunucu hata döndürmeye başlıyor. Bunların hiçbiri benim kontrolümde değil ve neredeyse hiçbiri başarısız bir çalıştırma olarak görünmüyor. Hepsine yetişmek tek kişi için zor — ve yakından izlemeyi bıraktığım anda iki ay boyunca kimse fark etmeden saptı.

Onu bitiren iki arıza da sessizdi: veri hattı bir uyarı yazıp "başarıyla" çıktı, site de makul görünen sayılar sunmaya devam etti. Devam ettirseydim sıradaki iş izleme olurdu — sıfır satırda alarm, etiketin hâlâ aynı şeyi ölçtüğünü denetleyen kontroller. Bu gerçek bir iş, ama bu portfolyonun anlatmasını istediğim iş değil. Ben bir makine mühendisliği öğrencisiyim ve zaman artık oraya gidiyor.

Geriye kalan

Temiz dönemin sonuçları hâlâ geçerli.

0,729canlı AUC — tahminler kalkıştan önce kaydedildi, sonra puanlandı, 5 Ağu – 12 Eyl

%10,2 / %11,7bu 1.067 uçuşta ortalama tahmin edilen ve gerçekleşen rötar oranı — kalibrasyona yakın

%53,9yerde 60 dakikadan az kalan kalkışların rötar oranı; 60–90 dk'da %13,7 — tek başına en güçlü sinyal

Canlı panonun olasılıkları ne kadar tuttu

Her uçuşa kalkıştan önce bir rötar olasılığı verildi. Bu olasılığa göre gruplandığında, gerçekte ne sıklıkla rötar yaptıkları:

Tahmin edilen risk	Uçuş	Ortalama tahmin	Gerçekte rötarlı
%0–8	607	%3,5	%6,1
%8–12	181	%9,8	%10,5
%12–20	101	%14,9	%17,8
%20–35	136	%26,7	%27,2
%35+	42	%43,4	%33,3

Aralığın ortası neredeyse tam isabetli. "Güvenli" uçuşlar ise tahminin yaklaşık iki katı sıklıkla rötar yaptı — çevrimdışı testlerin gösterdiği zayıflığın aynısı: kötü bir gün normalde dakik uçuşları da vuruyor ve geçmişlerinde bunu haber veren hiçbir şey yok.

Dersler

Neyi farklı yapardım.

Hiçbir şey toplamayan bir çalıştırma başarısız bir çalıştırmadır. Sıfır uçuş, uyarı yazmak yerine işi kırmızıya çevirmeli.
Etiket, başkasının tanımıdır. Bağımsız bir kaynakla bir kez doğrulamak yetmez — her gün, otomatik olarak doğrulanmalı.
Her bağımlılığı bir maliyet say. Her dış servis, kendi takviminde bozulabilecek ayrı bir parçadır.
Nasıl biteceğini baştan planla. Bitiş tarihi olmayan canlı bir proje, sonunda hâlâ "canlı" yazan bayat bir sayfaya dönüşür.

Arşiv

Sayfalar yayında kalıyor, temiz veriye sabitlenmiş olarak.

IST rötar veri seti →Pano, 12 Eylül 2026'ya sabitlendi Rötar modeli →Tablo ve model, dönüş süresi, göremedikleri Kalkış panosu →Son temiz pano ve gerçekte ne olduğu Üç merkez →IST, LHR ve FRA — aynı kaynak, aynı dönem