Otel sistem mimarisi ve yapay zekâ: her eylemi bir kez tanımlamak

Otel sistem mimarisi, her otel eyleminin nerede tanımlandığına, kimin ona erişebileceğine ve neyin kayda geçeceğine dair kararlar bütünüdür. Bir eylemi girdileri, kuralları, onayları ve kaydıyla tek bir yerde tanımlamak; personele, iş ortağı sistemlerine ve yapay zekâ asistanlarına ayrı kapılar vermek, üç ayrı kopya yerine tek bir politika tutar.

Bir misafir varıştan iki gün önce iptal ediyor. Resepsiyon ekranı bir gecelik cezayı uyguluyor. Seyahat acentesinin bağlantısı odayı cezasız serbest bırakıyor. Asistan onay istiyor, sonra hiçbir şey kaydetmiyor. Tek soruya üç yanıt, ve otel hangisinin kendi politikası olduğunu seçmek zorunda. Bu yazı bunun neden olduğunu, bir otel eylemini bir kez tanımlamanın ne demek olduğunu ve herhangi bir sistemi, satın alınmış ya da kendi ekibinizce geliştirilmiş olsun, bunun için nasıl sınayacağınızı anlatıyor.

Bir otel eylemi neden üç kez yazılmış oluyor?#

Çünkü her yeni kanal genellikle kendi küçük sistemi olarak kurulur ve her biri ihtiyacı olan kuralı yeniden yazar. Üç sürümün uyuşmasını zorunlu kılan bir şey yoktur.

Resepsiyon ekranı, iş ortağı bağlantısı ve asistan, aynı iş olayına giden üç ayrı kod yoludur ve her biri yerel bir sorunu çözen biri tarafından yazılmıştır. Ekran aceleci bir resepsiyonist için yazılmıştır. İş ortağı yolu bir acentenin dosya biçimini karşılamak için. Asistan katmanı bir misafir sorusunu yanıtlamak için. Her biri tek başına makuldür.

Örneğin, varıştan 48 saat önce iptal edilen ve bir gecelik cezaya tabi bir rezervasyon düşünün. Ekran fiyat planındaki politika kodunu okur ve geceyi ücretlendirir. İş ortağı yolu o politika kodu var olmadan önce yazılmıştır ve odayı ücretsiz serbest bırakır. Asistan misafirden onay ister, sonra iptali onaylayanın adı olmadan kaydeder. Her sürüm yerel olarak doğru, bütünsel olarak tutarsızdır; her birini ayrı ayrı test etmek sorunu bu yüzden hiç yakalayamaz.

Sapmayı ortaya çıkaran soru basittir: iptal politikamızı yarın değiştirsek, kaç yerde düzenleme yapardık? Bir tanesi mimaridir. Üç tanesi sapmadır.

Her yeni yüzey dördüncü kopyayı ekler. Ağustos 2026'da bir arama şirketi, yapay zekâ modunun içinde otel rezervasyonunu ABD'li gezginler için aşamalı olarak sunmaya başladı; gezgin seçiyor ve ödüyor, asistan kendi başına rezervasyon yapmıyor (Skift, 27 Ağustos 2026). Ama her böyle yüzey, aynı kurallara ulaşması gereken bir kapı daha demektir. Maliyet geç görünür: bir anlaşmazlık, bir denetim ya da bir misafir şikâyeti hangi sürümün o anda geçerli olduğunu sorar ve sistemden kimse yanıtlayamaz. Otel teknoloji altyapısındaki temel sistemlerin birbirine nasıl bağlandığının geniş resmine bakmak isterseniz, aynı ilke orada da geçerlidir.

Bir otel eylemini bir kez tanımlamak ne demektir?#

Eylemi dört parçayla tek bir yerde yazmak demektir: ne alıyor, hangi kurallar sonucu belirliyor, kim onaylamalı ve hangi kaydı bırakıyor. Sonra her kapı o tek tanımı çağırır.

Girdiler, eylemin ihtiyaç duyduğu olgulardır: rezervasyon referansı, varış tarihi, fiyat planının iptal politikası ve istekte bulunanın kim olduğu. Kurallar, koşullar ve aritmetiktir; bir kez tutulur, böylece bir ceza tek bir kod parçasınca hesaplanır, üç parçayla değil. Onaylar, eylemin bulunduğu seviyedir: doğrudan mı çalışır, bir kişiyi mi bekler, iki kişiyi mi. Kayıt, sonradan neyin yazıldığıdır: kim ya da ne tarafından, önceki değer ve yeni değerle, değişikliğin geri alınıp alınamayacağı dahil.

Tanım bir belge değildir. Politika PDF'i kod kadar hızlı sapar; tanım, her kapının gerçekten çağırdığı kod yolu olmak zorundadır. Pratik test düzenleme sayısıdır: bir kuralı değiştirin ve dokunmanız gereken yerleri sayın. Hedef birdir. Üç, sapmadır.

İkinci test geri okumadır: sisteme, verilen bir ücreti üreten kuralı göstermesini isteyin ve gösterebilir mi diye bakın. Kuralları tek yerde tutan sistem kendi sonuçlarını açıklayabilir. Üç kopyası olan sistem yalnızca o anda baktığınız kopyayı açıklayabilir.

Her kullanıcı kitlesi kendi kapısını nasıl alır?#

Her kitle, kendi kimlik denetimi, kendi izinli eylem kümesi ve kendi sınırlarıyla ayrı bir giriş alır; hepsi arkadaki aynı tanımlara bağlanır.

Personel ekranları alışılmış kapıdır: adı bilinen bir kişi rolüyle oturum açar ve ekran o rolün yapabileceği eylemleri sunar. Ekran bir görünümdür, kural değil. Resepsiyon ekranı iade düğmesini kıdemli olmayan rollerden gizliyorsa, bu sunumdur; kural, iade eyleminin kendisinin uyguladığı şeydir.

İş ortağı bağlantıları, ortağın kim olduğunu kanıtladığı ve ne yapmak istediğini bildirdiği sürümlü bir arayüzdür. IETF standardı OAuth 2.0 (RFC 6749, Ekim 2012) (yeni sekmede açılır) tam bunu yapar: üçüncü taraf bir uygulama bir web hizmetine sınırlı erişim alır, ya kaynağın sahibi adına onun onayını alan bir adımla ya da kendi adına; uygulama istediği erişimin kapsamını da belirtir. Kapsam kapının genişliğidir ve arkasındaki eyleme dokunmadan daraltılabilir.

Sürekli sorgulama (yoklama) yerine olaylar: giriş, çıkış ya da bir odanın hizmet dışı kalması gibi olayları bilmesi gereken bir sistem bu olaylara abone olur ve olduklarında haberdar edilir. Bu, HTNG'nin Olay Bildirim Spesifikasyonunda (sürüm 3.0, 24 Nisan 2015) (yeni sekmede açılır) tanımlanan yayınla-abone ol yöntemidir. Olay, onu üreten eylem tarafından bir kez duyurulur ve her abone aynı şeyi duyar.

Yapay zekâ asistanları da herhangi bir kapı gibi kapı alır: daha dar bir izinli kümeyle ve hassas her şeyin arkasında bir insanla. Asistan sistemin istemcisidir, asla ikinci bir kayıt sistemi değildir. En az yetki ilkesi, insanlarda olduğu gibi yazılımda da geçerlidir: NIST sözlüğü, CNSSI 4009-2022'ye dayanarak (yeni sekmede açılır), kullanıcıların ve onlar adına çalışan süreçlerin erişim yetkilerinin verilen görevleri yerine getirmek için gereken asgari düzeyle sınırlanmasını öngören güvenlik ilkesi olarak tanımlar.

Kapılar duvarları yener. Amaç asistanları dışarıda tutmak değil, her birinin hangi eylemlere ulaşabileceğini tam olarak bilmek ve o listeyi eylemi yeniden yazmadan değiştirebilmektir. Bu kapıların ardındaki tesisat için bkz. PMS entegrasyonu nasıl çalışır? API'yi sade bir dille anlamak.

Sınırlar ve onaylar eylemle birlikte nasıl taşınır?#

Sınır eyleme aittir, ekrana değil. Bir eşiğin üzerindeki iade ikinci bir kişi gerektiriyorsa, bunu bir resepsiyonist, bir iş ortağı sistemi ya da bir asistan tetiklese de geçerlidir.

Düz bir dille üç seviye: bazı eylemler doğrudan çalışır, bazıları bir kişinin onayını bekler, en hassas olanlar iki kişiyi. Görevler ayrılığı bunu destekler. NIST sözlüğü, NIST SP 800-192'ye dayanarak (yeni sekmede açılır), görevler ayrılığını hiçbir kullanıcıya sistemi tek başına kötüye kullanabileceği kadar yetki verilmemesi ilkesi olarak tanımlar; ilke çatışan roller tanımlanarak durağan biçimde ya da erişim anında denetlenerek dinamik biçimde uygulanabilir ve iki kişi kuralı dinamik biçime bir örnektir.

Veri koruma tarafı aynı sonuca varır. Kişisel Verileri Koruma Kurumunun Kişisel Veri Güvenliği Rehberi (Teknik ve İdari Tedbirler, Nisan 2025) (yeni sekmede açılır), çalışanlara yalnızca işleri, yetkileri ve sorumlulukları için gerekli olduğu ölçüde, kullanıcı adı ve şifreyle erişim tanınmasını önerir. Rehber, "İzin Verilmedikçe Her Şey Yasaktır" ilkesine dayalı bir erişim yetki ve kontrol matrisi kurulmasını tavsiye eder; yönetici yetkisinin yalnızca ihtiyaç olduğunda açılmasını, ilişiği kesilen çalışanların hesaplarının zaman kaybetmeden kapatılmasını ve tüm kullanıcıların işlem hareketlerinin düzenli kayıt altına alınmasını ister.

Onay, eylemle aynı kaydın içine yazılmalıdır. Yalnızca bir sohbet mesajında ya da telefon görüşmesinde var olan bir onay, sistemin sonradan gösterebileceği bir onay değildir. Seviyelerin de bir sahibi olmalıdır: otelin içinde biri, insansız çalışan eylemlerin listesini elinde tutmalı ve yeni bir kapı açıldığında gözden geçirmelidir.

Yeni bir kanal, eski kanalın ekranında uygulanan her denetimi sessizce atlatır. Bu tasarımın ortadan kaldırmak için var olduğu hata biçimi budur.

Kayıt, kim eylem yaptıysa ne göstermeli?#

Ne değiştiğini, kim ya da neyin istediğini, kimin onayladığını ve önceki değerin ne olduğunu göstermelidir; sonradan, yazanın dürüstlüğüne güvenmeden okunabilecek bir biçimde.

Kayıt eylem tanımı tarafından yazıldığı için, her kapı aynı biçimde kayıt üretir. Resepsiyondan gelen bir iptalle iş ortağı bağlantısından gelen bir iptal satır satır karşılaştırılabilir. Bu karşılaştırılabilirlik, bir aylık kaydı anekdot yığınından kullanışlı hale getiren şeydir.

Geri alma bir kural ister, umut değil. Küçük değişiklikler geri alınabilir; bazıları alınamaz, örneğin misafire çoktan gönderilmiş bir mesaj. Hangisinin hangisi olduğunu ihtiyaç doğmadan önce belirtin. Yalnızca eklenebilir kayıtlara ekleme yapılabilir; düzenlenemez ve silinemezler, biri yine de değiştirirse zincir bunu gösterir. Buna değişikliğin iz bırakması denir (İngilizcede tamper-evident) ve dürüst bir sistem bundan fazlasını vaat etmez.

Bir asistanın eylemi kimlere atfedilebilir olmalıdır: hangi asistan, kimin yetkisiyle, hangi kapsamda ve kişi gerekiyorsa hangi kişi onayladı. Yukarıda anılan rehber de tüm kullanıcıların işlem hareketlerinin düzenli kaydını istiyor; bu, aynı gereksinimin işletme tarafından değil veri koruma tarafından görülen yüzüdür.

Bir anlaşmazlığın ya da bir denetçinin gerçekten ihtiyaç duyduğu şey, eylemin yapıldığı anda yürürlükte olan politika sürümüdür, bugün okunduğu haliyle değil. Yalnızca sonucu değil, uygulanan kuralı da saklayan bir kayıt bu soruyu yanıtlar. Bunun geleneksel bir otel yönetim sisteminden farkı için bkz. otel işletim sistemi nedir? Otel yönetim sisteminden (PMS) farkı.

Bu mimarinin maliyeti nedir ve bir tedarikçi nasıl sınanır?#

İlk sürümden önce tasarım zamanı ister ve erken sürümleri yavaşlatır. Ödünü, ikinci ve üçüncü kanal geldiğinde kuralların yeniden yazmaya ihtiyaç duymamasıyla alır.

Baştan, biri her eylemi girdileri, kuralları, seviyesi ve kaydıyla ekranlar kurulmadan önce yazmak zorundadır. Bu iş yavaştır ve bir ürün tanıtımında görünmez. İlk sürüm kanal kanal kurulmuş bir yapıya göre sonra gelir ve zaman çizelgelerini karşılaştıran bir alıcı bunu fark eder.

Geri dönüşü yapısaldır: yeni kanal, kuralların kendi kopyasıyla gelen bir proje değil, mevcut tanımlara açılan bir kapı olur. Bunu atlamak maliyeti bir çöküş değildir. Üç politika, bir ücreti açıklayamayan bir destek ekibi ve hangi sürümün resmi olduğu sorusunun yanıtsız kalmasıdır.

Özellik listesi değil, uçtan uca tek bir eylem isteyin. Bu işi yapmış bir tedarikçi dakikalar içinde gösterebilir; yapmamış olan ekran gösterir. Aynı sorular, yazılım kendi ekibinizce geliştiriliyorsa ekibinize ve yeni bir kanal için ayrı bir yol öneren her entegratöre de uygulanır.

Bir tedarikçiye sorulacak yedi soru#

Şimdi ne yapmalı#

Tek bir eylem seçin, genellikle en uygun aday iptaldir, ve elinizdeki her kapıdan izini sürün: resepsiyon ekranı, her iş ortağı bağlantısı, her asistan. Dört parça, yani girdiler, kurallar, onaylar ve kayıt, tek bir yerde değilse, yapılacak işi buldunuz demektir. Sonra yukarıdaki yedi soruyu tedarikçinize ya da kendi ekibinize yöneltin ve tanıtımı değil, yanıtları değerlendirin.