1. PMS Entegrasyonlarında Hata Ayıklama, Monitoring ve SLA: Sorun Çıkmadan Yönetmek
“Booking ile PMS bağlantısı koptu, ne yapayım?” Bu soru genelde çok geç gelir; çünkü entegrasyonlar bozulana kadar görünmezdir. Bozulduğunda ise etkisi görünür: fiyat/müsaitlik güncellenmez, OTA satışları düşer, web motoru yanlış gösterir, call center “oda var mı?” sorusuna güvenilir cevap veremez. Yani entegrasyon hatası, doğrudan gelir kaybıdır.
Bu nedenle entegrasyon yönetimi iki ayaklıdır: (1) Monitoring & erken uyarı (log, alarm, dashboard), (2) SLA & süreç (sorumluluk, yanıt süresi, kök neden analizi). Bu rehber; tipik hata tiplerini sınıflandırır, izleme mimarisini kurar, SLA maddelerini otel–tedarikçi–OTA tarafında netleştirir ve sorun çıktığında 8 adımda sistematik hata ayıklama iskeleti verir.
2. PMS Entegrasyonlarında Monitoring ve SLA Neden Bu Kadar Önemli?
Entegrasyonun değeri “kuruldu”ğu gün değil; her gün çalıştığı süre boyunca ortaya çıkar. Bu yüzden izleme yoksa, problem genelde “misafir şikâyeti” veya “ciddi gelir kaybı” ile fark edilir. SLA yoksa, herkes birbirine bakar: PMS sağlayıcısı, OTA, kanal yöneticisi, otel IT.
Net cevap bloğu
- • Monitoring ve SLA; PMS entegrasyon kesintilerinin gelir kaybına dönüşmesini önlemek için kritik çünkü hatayı erken tespit eder, doğru ekibe doğru zamanda uyarı gönderir ve sorumluluk/yanıt süresini netleştirerek hızlı çözümü mümkün kılar.
Erken uyarı yoksa ne olur?
- •fiyat/müsaitlik güncellenmez → yanlış satış/overbooking
- •web motoru yanlış fiyat gösterir → dönüşüm düşer
- •call center yanlış bilgi verir → güven kaybı
- •muhasebe/raporlar şaşar → kapanış zorlaşır (Varsayım)
SLA yoksa ne olur?
- •“sorun kimde?” tartışması uzar
- •MTTR uzar (çözüm süresi artar)
- •aynı hata tekrar eder (RCA yok)
Mini Check
- • Entegrasyon sağlığı için tek bir dashboard var mı?
- • Kritik hatalarda alarm doğru ekibe gidiyor mu?
- • SLA’da yanıt/çözüm süreleri yazılı mı?
- • RCA ve kalıcı düzeltme süreci var mı?
- • Gelir etkisi KPI’ları izleniyor mu?
Ne yapmalıyım?
- • “Sağlık metrikleri”ni kilitleyin (başarısız push, gecikme, boş envanter).
- • Alarmı doğru ekibe bağlayın (IT + revenue).
- • SLA sorumluluk matrisini yazılı hale getirin.
- • RCA’yı her kritik olay sonrası zorunlu yapın.
3. Entegrasyon Hatalarının Tipik Nedenleri: API, Mapping, Limitler
Hataların çoğu teknik olarak “beklenen” sınıflara girer. Önemli olan, sınıflandırmayı doğru yapmak ve her sınıf için hızlı teşhis sinyalleri oluşturmaktır.
API hataları
- •hata kodları (4xx/5xx), timeouts, rate limit
- •gecikme (latency) artışı
- •authentication/token sorunları (Varsayım)
Mapping hataları
- •oda tipi kapalı / yanlış eşleşmiş
- •rate plan eşleşmesi bozulmuş
- •stop-sale/limit kuralı yanlış uygulanmış
Limit ve envanter sorunları
- •“boş envanter” push’u (0) yanlış zamanda
- •minimum/maksimum limit çakışması
- •kanal yöneticisi/OTA tarafında manuel müdahale (Varsayım)
Mini Check
- • API hata kodları toplanıyor mu?
- • Mapping değişiklikleri versiyonlanıyor mu?
- • Limit/stop-sale kuralları izleniyor mu?
- • Manuel müdahale loglanıyor mu?
- • “Boş envanter” alarmı var mı?
Ne yapmalıyım?
- • Hata tiplerini 3 sınıfta raporlayın (API/mapping/limit).
- • Mapping değişikliklerini onay sürecine bağlayın.
- • Envanter “0” push’u için alarm ekleyin.
- • Manuel müdahaleyi görünür kılın (audit log).
4. Loglama, Alarm ve Dashboard Kurulumu
Monitoring, “log var” demek değildir. Log’un standardı, alarmın eşiği ve dashboard’un tek bakışta karar verdirmesi gerekir.
Log seviyeleri (info, warning, error)
- •info: normal akış (istek/yanıt özetleri)
- •warning: gecikme, retry, partial failure
- •error: başarısız push, mapping bulunamadı, auth hatası
Alarm tetikleyicileri (örnek)
- •son 15 dk içinde başarısız push > X (Varsayım)
- •envanter “0” anomali spike
- •API timeout oranı artışı
- •mapping not found
Dashboard: “tek ekran” mantığı
- •Kanal bazlı sağlık: OTA/web/call center
- •Veri akışı gecikmesi (lag)
- •Başarısız işlem listesi + hızlı drill-down
- •Gelir etkisi proxy KPI (Varsayım: satış düşüş sinyali)
| Senaryo | Log İpucu | Alarm | İlk Aksiyon |
|---|---|---|---|
| API timeout | warning: timeout | latency/timeout alarmı | retry + rate limit kontrol |
| Mapping yok | error: mapping_not_found | mapping alarmı | oda tipi/rate plan eşleştirme |
| Boş envanter | info: inventory=0 spike | inventory anomaly | limit/stop-sale kontrol |
| 5xx artışı | error: 5xx | provider outage | tedarikçi eskalasyon |
KVKK teknik not (sheet): Entegrasyon logları KVKK açısından kişisel veri içermemeli; log retention süreleri ve erişim hakları iyi tanımlanmalı; dashboard ve alarm sistemleri kritik hatalarda ilgili ekipleri e-posta/mesajla uyarmalıdır.
Mini Check
- • Log’larda PII maskeli mi? (KVKK)
- • Retention süresi ve erişim rolleri tanımlı mı?
- • Alarm eşiği ve “noise” kontrolü var mı?
- • Alarm kanalları net mi? (mail/mesaj)
- • Dashboard tek ekranda “sağlık” gösteriyor mu?
Ne yapmalıyım?
- • Log standardı belirleyin: PII yok, correlation ID var.
- • Alarm eşiklerini revenue ile birlikte ayarlayın (false positive azalt).
- • Dashboard’u “tek bakış” kuralıyla tasarlayın.
- • Kritik alarmı 7/24 eskalasyon akışına bağlayın.
5. Hizmet Seviyesi Anlaşmaları (SLA) ve Sorumluluk Dağılımı
SLA; “kim, hangi sürede ne yapacak?” sorusunun cevabıdır. Entegrasyon zincirinde genelde 4 taraf vardır: otel, PMS sağlayıcısı, kanal yöneticisi, OTA. Sorumluluk matrisi olmadan çözüm süresi uzar.
SLA maddeleri: minimum set
- •çalışma oranı (uptime) hedefi (Varsayım)
- •yanıt süresi (response)
- •çözüm süresi (resolution)
- •bakım penceresi (maintenance window)
- •eskalasyon seviyesi ve iletişim kanalı
- •RCA raporu teslim süresi
| Konu | Otel | PMS Sağlayıcı | Kanal Yöneticisi | OTA |
|---|---|---|---|---|
| Alarm takibi | R | C | C | C |
| API kesinti | C | R | R | R |
| Mapping değişikliği | R | C | R | C |
| Limit/stop-sale | R | C | R | C |
| RCA raporu | C | R | R | C |
R=Responsible, C=Consulted (Varsayım: örnek matristir.)
Mini Check
- • Yanıt/çözüm süreleri yazılı mı?
- • Eskalasyon listesi güncel mi?
- • Bakım penceresi tanımlı mı?
- • RCA zorunlu mu?
- • Sorumluluk matrisi imzalı mı? (Varsayım)
Ne yapmalıyım?
- • SLA’yı metrik + süreç olarak yazın (sadece uptime değil).
- • Sorumluluk matrisini 4 tarafla netleştirin.
- • RCA’yı “kritik olay sonrası” zorunlu yapın.
- • Eskalasyon kanallarını (mail/telefon/WA) test edin.
6. Sorun Çıktığında Adım Adım Hata Ayıklama Süreci
Bu bölüm “kriz anında” açılır. Hedef: panik değil, sistematik teşhis.
Hata durumunda 8 adım (kriz iskeleti)
- Etkiyi doğrula: hangi kanal? OTA/web/call center
- Son başarılı senkron zamanını kontrol et (lag)
- Hata tipini sınıflandır (API / mapping / limit)
- Loglardan correlation ID ile örnek işlem çek
- Hızlı “rollback/mitigation”: manuel düzeltme gerekiyorsa kontrollü yap (Varsayım)
- Tedarikçi eskalasyonu: SLA kanalından bildir
- Kalıcı düzeltme: mapping fix / limit fix / auth fix
- RCA + önleyici aksiyon: alarm eşiği/guardrail güncelle
RCA (Root Cause Analysis) şablonu
- •Problem: …
- •Etki: … (gelir/kuyruk/overbooking)
- •Kök neden: … (API/mapping/limit)
- •Düzeltme: …
- •Önleyici aksiyon: … (monitoring/guardrail)
| Problem | Kök Neden | Çözüm |
|---|---|---|
| Satış durdu | API outage/timeout | eskalasyon + retry + limit |
| Yanlış envanter | limit/stop-sale çakışması | kural düzeltme + test |
| Yanlış oda tipi | mapping bozuldu | mapping fix + onay |
| Geç fark edildi | alarm yok/yanlış eşik | alarm tuning |
| Tekrar etti | RCA yok | RCA + guardrail |
Key Statistics / Data Point (sheet – senaryo): Monitoring ve SLA yapısı oturmamış entegrasyonlarda hatalar çoğu zaman misafir şikâyeti veya ciddi gelir kaybı sonrası fark edilirken; iyi kurgulanmış yapılarda sorunlar daha erken tespit edilip sınırlı etkiyle çözülebilir. Farkı yaratan; “erken alarm + net sorumluluk + RCA” üçlüsüdür.
Mini Check
- • Kriz anında tek sorumlu (incident owner) belli mi?
- • 8 adım akışı ekipte biliniyor mu?
- • Alarm kanalları çalışıyor mu?
- • RCA aksiyonları takip ediliyor mu?
- • KVKK: loglarda PII yok mu?
Ne yapmalıyım?
- • Incident owner atayın ve “war-room” akışı yazın.
- • 8 adım kartını SOP’a ekleyin.
- • SLA eskalasyonunu test edin (tatbikat).
- • RCA aksiyonlarını backlog’a koyup kapatın.
7. Entegrasyon Hata Ayıklama Akışı & SLA Maddeleri Kontrol Listesini İndir — Otel / PMS Integrations
Entegrasyon Hata Ayıklama Akışı & SLA Maddeleri Kontrol Listesini İndir — Otel / PMS Integrations (v1.0)
Bu kontrol listesi, PMS entegrasyonlarında monitoring mimarisini (log–alarm–dashboard) standartlaştırır, SLA sorumluluklarını netleştirir ve hata çıktığında uygulanacak 8 adımlı debugging akışını tek sayfada toplar. Amaç; hatayı misafir şikâyetiyle değil erken alarm ile yakalamak, MTTR’ı düşürmek ve aynı hatanın tekrarını RCA ile önlemektir.
Kim Kullanır?
IT + revenue/dağıtım + operasyon liderleri ve tedarikçi yöneticileri birlikte.
Nasıl Kullanılır?
- Sağlık metriklerini ve alarm eşiklerini kurup dashboard’u tek ekrana toplayın.
- SLA sorumluluk matrisi ve eskalasyon kanallarını yazılı hale getirip test edin.
- Olay olduğunda 8 adımı uygulayıp RCA aksiyonlarını backlog’da kapatın.
Ölçüm & Önceliklendirme (Kısa sürüm)
- ▢ ✅ Hata sınıfları tanımlı (API / mapping / limit)
- ▢ ✅ Log standardı var (PII yok, correlation ID var)
- ▢ ✅ Alarm eşikleri tanımlı (başarısız push, timeout, inventory anomaly)
- ▢ ✅ Dashboard tek ekranda sağlık gösteriyor
- ▢ ✅ 7/24 eskalasyon kanalı ve kişi listesi güncel
- ▢ ✅ SLA yanıt/çözüm süreleri yazılı
- ▢ ✅ RCA şablonu ve zorunluluğu tanımlı
- ▢ ✅ KVKK: retention ve erişim rolleri net
- ▢ ✅ Monitoring metrik seti + dashboard
- ▢ ✅ Alarm eşik dokümanı + eskalasyon listesi
- ▢ ✅ SLA maddeleri + sorumluluk matrisi
- ▢ ✅ 8 adım hata ayıklama SOP’u
- ▢ ✅ RCA şablonu + takip sistemi
PDF içinde: Problem→Kök Neden→Çözüm tablosu + 14 gün sprint planı + önce/sonra KPI tablosu
Bir Sonraki Adım
Entegrasyon kesintilerini erken yakalayıp gelir kaybını azaltmak isteyen oteller için.
Sık Sorulan Sorular
PMS entegrasyonlarında en sık görülen hatalar nelerdir?▾
Entegrasyonun sağlığını izlemek için nasıl monitoring kurmalıyım?▾
API ve mapping hatalarını nasıl tespit ederim?▾
OTA ve PMS sağlayıcılarıyla SLA nasıl yapılandırılmalı?▾
Loglama KVKK açısından nasıl yönetilmeli?▾
İlgili İçerikler
İlgili Yazılar