Pegasus Havayolları: Bir IT ve Hizmet Rezaleti

Bu yazı Pegasus Havayolları'na bir açık mektuptur.

21 Mayıs 2012 tarihinde nişanlım Seylan Çınar, Pegasus Havayolları'na ait PC-2133 sefer sayılı, 16:30 Ankara Esenboğa - İzmir Adnan Menderes uçuşu için havaalanına gittiğinde Pegasus Havayolları'nın yakın zamanda reklamını da yapmakta olduğu mobil biniş kartının açılmadığını farkediyor. Öncelikle haklı olarak telefonundan ve internet bağlantısından şüpheleniyor, bir kaç kez deniyor ancak sayfa hala açılmıyor. Bunun üzerine beni arıyor, ve ben de denediğimde sayfanın açılmadığını, ilgili sunucunun sürekli olarak "Connection reset by peer" hatası verdiğini tespit ediyorum.

Sorunun Pegasus Havayolları sunucularında olduğunu anlar anlamaz check-in bankosuna koşan nişanlım görevlinin "check-in kapandı, bilet satışa gidin" yönlendirmesi ile bilet satış bölümüne gidiyor. Buradaki görevliye hızlıca derdini anlatıyor çünkü süresi kısıtlı. Görevli "telefonunuz sorunludur", "internet bağlantınız sorunludur", "açma sorumluluğu size ait", "uçağınız zaten kalkmak üzere, geçmiş olsun" benzeri umursamaz ve yardımcı olmaktan hayli uzak tavırlarıyla nişanlımı oyalıyor ve sonunda uçak kalkıyor. Sadece bu aşamada bile PNR numarası ile siteye girip oradan ilgili kağıt çıktısını alarak yardımcı olabilecek bu kişi IT biriminin başlattığı rezaletin hizmet birimindeki ilk halka oluyor.

Bu olayın devamında nişanlımı almak üzere, kafamdaki naif "belki daha teknik birisi olarak sorunu ben anlatırsam durum daha net anlaşılır ve yardımcı olurlar" düşüncesi ile yola çıkıyorum. Bu sırada nişanlım da telefonda müşteri hizmetleri ile 1 saate yakın görüşüyor ve vardıkları sonuç elimizde oturacağı koltuk numarasına kadar her türlü ispatı olan online check-in işleminin yapılmadığı!

Ben geldiğimde bilet satıştaki görevli değişmiş, en azından bize akşamki bir diğer uçuşa yanan biletimizde ödediğimiz, yaklaşık 10 TL tutarındaki alan vergisini düşerek bilet kesebileceğini söylüyor. Fazladan ödememiz gereken ücret 100 lira civarında. Sorunun çözümü için kendisinin bir şey yapamayacağını söylüyor ki artık uçağımız zaten gitmiş olduğu için nispeten haklı. Haklı olduğumuz halde aynı firmaya 100 TL daha ödemek istemediğimizden, bilet satışı terkediyoruz.

Müşteri hizmetleri ile bir de ben konuşayım diye yaptığım ilk aramada bir süre hatta bekledikten sonra ben "bilet ücret iadesi" derken hat kesiliyor. Kasıtlı yapıldığını sanmıyorum ancak bu olay o sırada içinde bulunduğumuz durum düşünüldüğünde bizi daha da sinirlendirmekten öteye gitmiyor.

Bir sonraki aramamızda yaklaşık 15 dakika boyunca sıkıntımı anlatmaya çalışıyorum, bir süre hatta beklemem rica ediliyor ve devamında çok net bir tavır ile "biletiniz ile ilgili hiçbir işlem yapılmayacak" cevabını alıyorum. Sebebini öğrenmek istediğimde arada bir yerde "zaten check-in de yapmamışsınız" benzeri bir cümle sarfediliyor ve o an karşımdaki kişinin beni aslında hiç anlamdığını farkediyorum. Tekrar, derdimi anlatıyorum. Devamında yine bir beklemenin ardından tam 20 dakika içerisinde beni mutlaka tekrar arayacaklarını ve alandan ayrılmamamızı söyleyip görüşmeyi sonlandırıyor müşteri temsilcisi.

Bu görüşmeden yarım saat sonra, kimse aramadığı için tekrar müşteri hizmetlerini arıyorum, durumu anlatıyorum kısaca, bu sefer çok daha kısa bir beklemenin ardından hava alanındaki görevlilerden alınan bilgiye göre durumla ilgili müracat yapmadığımız iddia ediliyor. Haklı iken yalancı yerine konduğumuz bu ikinci seferde bunun doğru olmadığını söylüyorum. Alan ile yapılan ikinci bir görüşme sonrasında online check-in yapmış olmamıza rağmen alana geç gittiğimiz için bu sorunla karşılaştığımız söylenerek sorumluluk bizim üzerimize yıkılıyor.

Havaalanına, otobüsün de biraz gecikmesi sebebiyle nispeten geç gidildiği doğru ancak bunu bana söyleyen görevliye de belirttiğim üzere nişanlım 1 saat önce bile havaalanında bulunup ikinci güvenlik kapısından hemen hemen aynı saatlerde geçmeyi deneyebilirdi. Bu durumda yine tamamen aynı sorun ve muamele ile karşılaşacağı oldukça açık. Üstelik bagaj bile teslim etmeyecek olduğum halde yine en az 40-50 dakika önceden alana gelmem gerekiyorsa(ki gerekmediğini daha önce uçuştan sadece 15 dakika önce alana gidip uçağa binerek gördüm) neden online check-in diye bir hizmet var diye düşünüyor insan. Kaldı ki Pegasus Havayolları'nın bile kafası bu konuda karışık sanıyorum çünkü sitelerinde "bagaj teslim edecekseniz 1 saat önceden alana gelmelisiniz" yazan yerin bir kaç madde altında "online check-in işlemi uçuştan 40 dakika öncesine kadar yapılabilir" deniyor ve yanlış hatırlamıyorsam işlemi yaptıktan sonra bize sunulan PDF dosyasında uçuştan en geç 15 dakika önce alanda olmamız gerektiği yazılı.

Yukarıdaki duruma ek olarak, telefonda müşteri temsilcilerine de söylediğim üzere Pegasus Havayolları'ndan bilet alarak yaptığımız anlaşma temel olarak ücret karşılığı hizmet alımına dayanıyor ve hem alandaki görevliler olsun hem telefondaki görevliler, bahse konu bu hizmetin sağlanması ve sürekliliği için bulunuyorlar. Durum böyle iken bu görevlilerden tek bir tanesinin bile ücreti çoktan ödenmiş bir hizmeti bize sağlamak için ufacık bir çaba bile sarfetmiyor olması(çağrı merkezi ile yaptığım son görüşme hariç) gerçekten korkunç bir durum. Çünkü bu olayın bir sonraki basamağı apaçık dolandırıcılık sınırlarında gezinmek.

O gün yaşanan bu olay bana sadece bilet ücreti olan 70-80 TL tutarında bir para kaybettirmedi. Oldukça fazla zaman, çokça yıpranan sinirler, ertelenen uçuştan dolayı nişanlımın değiştirmek zorunda kaldığı toplantı/etkinlik zamanları, havaalanına gidiş geliş için fazladan harcanan yakıt, müşteri hizmetleri ile yapılan görüşmelerin ücreti gibi pek çok şeye maloldu.

Firma tarafında ise, özellikle de alanda ve henüz bir kayıp yaşanmadan önce, bize yardımcı olmayan görevlilerin kendi firmalarına sebep oldukları zarardan ise haberdar olup olmadıklarını çok merak ediyorum. Bu olaydan sonra telafi amaçlı aldığımız bileti elbette ki Pegasus Havayolları'ndan almadık ve tüm tanıdığımız kişileri de şu an aktif olarak firmaya karşı uyarıyoruz. Yaptığımız uyarılara tepki olarak, yaşamış olduğumuz "mobil biniş kartının açılmaması" sorunu ile karşılaşan başka pek çok kişi olduğunu öğrenip bu konuda kimsenin firma tarafından uyarılmadığını gördüğümüzde ise durumun sandığımızdan çok daha vahim olduğunu anladık.

Türkiye'de özellikle yurt içinde havayolu ulaşımını herkesin kullanmasını sağlayan ve uzun süreler kendileriyle uçmaktan mutluluk duyduğum Pegasus Havayolları'nın hizmet ve IT konusundaki bu yetersizliği(hatta rezaleti) ve bana yaşattığı sinir bozukluğundan dolayı gerçekten üzgün ve kızgınım. Yakın gelecekte kendileri ile tekrar uçmayı da kesinlikle düşünmüyor, kimseye de tavsiye etmiyorum.

GitHub Badge projesinden neler öğrendik?

GitHub Badge başlangıçta kullanıcıların GitHub profilleri ile ilgili birkaç istatistiki bilginin gösterileceği ve geliştiricilerin özgeçmişlerine veya bloglarına koyabilecekleri basit bir bilgi alanından ibaretti. Aslında hala öyle ancak "birkaç istatistiki bilgi" kısmını biraz genişlettik.

İlk sürümü yayınlandıktan sonra,

• Google App Engine'in ücret politikasının değişmesi
• Kullanıcı sayısının hızla artması
• Yeni eklenen özelliklerle uygulamanın kullandığı kaynağın artması

gibi nedenlerle mevcut yapı App Engine'in ücretsiz kullanım limitlerini zorlamaya başladı.

Ölçeklenebilirlik

Memcache

İlk yaptığımız şey üretilen HTML sayfasının belirsiz süreyle Memcache üzerinde önbelleğe alınmasıydı ki bu oldukça etkili bir çözüm oldu. Her ne kadar sunduğumuz bilgiler her zaman en güncel bilgiler olmasa da iletilen bir şikayet olmadı. Kaldı ki çoğu durumda GitHub’ın agresif önbellekleme stratejisinden dolayı GitHub arayüzünden daha güncel veriler sunmamız rastlanmayan bir durum değil(eğer bir projeyi veya kullanıcıyı takip etmediyseniz ya da bir gönderi yapmadıysanız profilinize ait bilgiler GitHub Badge’e göre daha eski olabilir). Ancak gönderi yoğunluğunu gösteren "sparkline" özelliği yayına girdiğinde her öğenin yaşam süresini 24 saatle kısıtlamamız gerektiğine karar verdik.

Bu durumun üzerine “bizi destekleyin” ve “Google Analytics'i kapat” gibi HTML çıktısını değiştiren özelliklerin eklenmesiyle sadece üretilen HTML sayfasının önbelleğe alınması yetmemeye başladı. Bu durumu çözmek için hesaplanan kullanıcı bilgilerinin bulunduğu sözlük nesnesini de JSON biçiminde önbellekte saklamaya başladık.

Google App Engine, Memcache kullanımını ücretlendirmediği için alabildiğimiz tüm bilgileri Memcache ile önbelleğe aldık ya da önbelleğe aldığımız veri miktarını arttırmaya çalıştık. Bu durum, artan günlük ziyaretçi sayımıza ve kullanıcılarımıza rağmen hala ücretsiz kullanım sınırları içerisinde kalabilmemizin iki temel sebebinden bir tanesi.

Ön yüz

Ön yüzde neredeyse ilk sürümden beri HTML ve CSS sıkıştırma kullanıyoruz, Google App Engine de gzip kısmını kendisi hallediyor. Buna ek olarak tüm sayfanın yarım günlüğüne tarayıcı önbelleğine alınması ve kişilerin GitHub'da görünen resimlerinin de sunucu tarafında yeniden boyutlandırılıp sayfaya gömülmesi gibi optimizasyonlar ile bant genişliğimizi oldukça etkin kullanmayı başardık.

API kullanımı ve Pyresto

GitHub Badge’in ilk sürümünde, GitHub API ile ilgili işleri yapmak, takipçi sayısı gibi bilgileri hesaplamak için bir nesne ve buna bağlı birkaç yöntem yeterliydi. Gönderi grafiği, kişinin kendisi dışındaki toplam proje takipçi sayısı gibi veri işleme gerektiren, daha ayrıntılı bilgileri göstermek istediğimizdeyse bu basit sınıfın işimizi görmeyeceğini anlayıp farklı çözümler aramaya karar verdik. Yaptığımız küçük araştırmada GitHub için halihazırda yazılmış olan Python istemcilerinin ya eski ya da istediğimiz gibi olmadığını gördük ve “hepsine hükmedecek tek bir yüzük olmalı” diyerek “adam gibi yazılmış” REST tabanlı her türlü uygulama arayüzü ile çalışacak bir ORM projesi yazmaya karar verdik. İlk kurbanımız elbette ki GitHub olacaktı.

Bu noktada GitHub’ın sunduğu uygulama geliştirme arayüzünün üçüncü sürümünün gerçekten mükemmele çok yakın olduğunu, mükemmel olmayan kısımlarında da GitHub ekibinin yaptığımız hata bildirimleri ve özellik isteklerine olumlu ve hızlı yanıt verdiğini belirtmekte fayda var ki bu da geliştirme sürecinde işimizi oldukça kolaylaştırdı. Pyresto’nun asıl yaptığı şey veri ile uğraşmak isteyen programcıyı arkaplanda dönen karmaşık işlemlere bulaştırmamak, basitçe onun önünden çekilmek ve veriyle rahatça uğraşmasına izin vermek, bunu yaparken de farklı platformların geliştirme arayüzü tanımlamalarını olabildiğince basite indirgemek. Örneğin şu an kullanmakta olduğumuz GitHub modülü sadece 70 satırlık bir dosyadan ibaret. Bu kod elbette tam değil ve herşeyi kapsamıyor ancak yaptığımız ve sıradan olmaktan uzak GitHub uygulaması için fazlasıyla yeterli. İşin güzel yanı bu 70 satırın çoğu aslında veri modelini tanımlıyor, yani gerçek kod değil.

Sözün özü GitHub Badge projesinin kalbinde aslında Pyresto yatıyor ve bir sonraki hedefimiz bu kütüphaneyi hem belgelemesi hem de testleri ile herkesin rahatça kullanabileceği bir hale getirip yaygınlaşmasını sağlamak. Şu anki hali de PyPI üzerinden indirilebilir durumda.

Arayüz

Eklenen yeni özelliklerle beraber, bu özelliklerin son kullanıcıya nasıl sunulacağı da önemli bir soru haline geldi. Bu nedenle arayüz toplamda üç kez değişti. Bu süreç, ürünün özelliklerini kısıtlı bir alanda, kullanıcının kafasını karıştırmadan, mümkün olan en sade ve güzel tasarımla, olabilecek en fazla bilgiyi sunmaya çalışmak gibi hedefler nedeniyle epey öğretici ancak bize göre sunum konusunda hala olması gerekenden uzakta olan bir tasarım deneyimi oldu. Yani bu konuda tavsiyelere açığız.

Açık kaynak topluluğu ile iletişim

GitHub Badge öncesinde başta Mozilla ve Python olmak üzere açık kaynak projelere katkıda bulunuyorduk ancak jGrow haricinde sıfırdan yazdığımız ve topluluktan geribildirim aldığımız bir proje geliştirmemiştik. GitHub Badge ilk katkılarını yayına girdikten birkaç saat sonra aldı. Test sürecinde farketmediğimiz hataları da yine bu sayede düzelttik.

Bir açık kaynak projeye katkıda bulunmanın tek yolu kod yazmak değil. Başlangıçta çok basit olarak düşündüğümüz proje, Emre Sevinç’in katkılarıyla çok daha fazla bilgi sunar hale geldi. Her ne kadar yeni sürümlerde eklediğimiz JSONP ve CORS tabanlı API’ler için beklediğimiz geri bildirimi alamamış olsak da sağlıklı bir açık kaynak proje nasıl olur ve nasıl gelişir konularında bir miktar tecrübe kazandık, mutlu olduk falan.

Bu yazı projenin diğer geliştiricisi olan Berker Peksağ ile birlikte hazırlanmış olup, onun blogunda da yayınlanmıştır.