Vardiya değişimlerine ve resmi tatillere dayanan SLA takvimi tasarımı

Her ITSM kurulumunda, genellikle canlıya alımdan yaklaşık altı hafta sonra bir an gelir: servis masası yöneticisi CIO'ya ilk çeyreklik SLA raporunu gönderir ve sayıların yanlış olduğunu sessizce fark eder. Çok değil — bir yerde bir puan, orada bir hayalet ihlal — ama yanlış. Örüntü hep aynıdır: Kurban Bayramı'ndan önceki cuma saat 16:55'te açılmış bir talep, pazartesi sabahı ihlal işaretlenmiş, oysa gerçekte hiçbir teknisyen görevde değildi. SLA politikası "09:00-17:00, Pazartesi-Cuma" diyordu, takvim Ramazan Bayramı'nın çarşamba olduğunu söylüyordu ve bu iki gerçek arasında bir yerden talep düşüp gitti.

Naif SLA takvimi — her ITSM'in varsayılan olarak sunduğu — bunun sebebidir. Güvenilmez SLA raporlamasının en yaygın tek kaynağıdır ve düzeltilebilir. Bu yazı, kullandığımız ve önerdiğimiz takvim modelini ve üretimdeki her takvimin karşılaması gereken dört karmaşıklık kategorisini işler.

Naif varsayılan: "09:00-17:00, Pazartesi-Cuma"

ITSM araçlarının çoğu, kutudan çıktığında şu görünümde bir iş saati SLA takvimi sunar:

• Pazartesi'den Cuma'ya, 09:00'dan 17:00'ye.
• Hafta sonları dışarıda.
• Birinin her aralıkta güncellemeyi hatırlaması gereken kısa bir "resmi tatiller" listesi.

Bu, tüm BT ekibinin aynı şehirde yaşadığı, aynı saatlerde çalıştığı ve aynı tatilleri kullandığı küçük bir şirket için yeterli. Başka her yer için yeterli değildir. Gerçek dünyada, ilk yıl içinde bu modeli en az dört karmaşıklık kategorisi kırar:

1. Kayan resmi tatiller — Türkiye'deki dini tatiller ay takvimi bazlıdır ve her yıl 10-11 gün geri kayar.
2. Vardiya modelleri — 7/24 NOC "iş saati" tanımı içinde çalışmaz.
3. Teknisyen izinleri — SLA sayacı, atanmış teknisyen masada olsun olmasın işlemeye devam eder.
4. Çok bölgeli operasyonlar — İstanbul saat 09:00 Europe/Istanbul'da açılır; Londra saat 09:00 Europe/London'da açılır; P1 talebin umurunda değildir.

Bunları tek tek ele alacağız.

1. Türkiye resmi tatilleri sabit tarihler değildir

Türkiye resmi tatil takviminde iki tür gün vardır:

• Sabit sivil tatiller. Yılbaşı (1 Ocak), Ulusal Egemenlik ve Çocuk Bayramı (23 Nisan), Emek ve Dayanışma Günü (1 Mayıs), Atatürk'ü Anma, Gençlik ve Spor Bayramı (19 Mayıs), Demokrasi ve Millî Birlik Günü (15 Temmuz), Zafer Bayramı (30 Ağustos), Cumhuriyet Bayramı (29 Ekim). Bunlar basit tarih kurallarıdır.
• Kayan dini bayramlar. Ramazan Bayramı (3,5 gün) ve Kurban Bayramı (4,5 gün) Hicri ay takvimine göre belirlenir ve her Miladi yılda kayar. 2026'da Ramazan Bayramı 20 Mart (yarım gün) ile 23 Mart arasında; 2027'de yaklaşık 10 Mart'ta başlar. 2026 Kurban Bayramı 27 Mayıs (yarım gün) ile 31 Mayıs arasında; 2027'de yaklaşık 17 Mayıs.

Yarım gün kuralı önemlidir. Bakanlar Kurulu bayram öncesi arefe gününü genellikle resmi yarım gün ilan eder; kamu kurumları 13:00'te kapanır. Özel sektör servis masaları değişir — bir kısmı devletin yarım gününü izler, bir kısmı tam iş günü uygular, bir kısmı tamamen kapatır. Kurumunuzun hangi politikayı izlediğinden bağımsız olarak SLA takvimi bunu açıkça kodlamalıdır. Yarım gün "yarı iş saati" değildir; olağan açılış saatinde başlayıp 13:00'te biten spesifik bir penceredir.

Bunlara ek olarak Cumhurbaşkanlığı zaman zaman anlık bir tatil ilan eder — millî futbol zaferi sonrası, bir olağanüstü matem günü veya sabit tatille hafta sonu arasında köprü günü. Bunlar hiçbir takvime önceden yüklenemez. SLA takvimi modeli, tek seferlik bir tatilin 24 saatlik ihbarla ve geçmişi yeniden hesaplamadan eklenmesini desteklemelidir.

Bir mühendisin tatil eklemek için kod deploy etmesini gerektiren herhangi bir SLA takvimi ilk operasyon yılında başarısız olur. Takvim yapılandırma değil, veri olmalıdır.

2. Vardiya modelleri "iş saati" değildir

7/24 bir ağ operasyon merkezinin iş saati yoktur. Vardiyası vardır. 7/24 bir masa için SLA takvimi, Pazartesi-Cuma bir masanınkinden tümüyle farklı olmalıdır. Ve gerçek kurumların çoğunda ikisi yan yana var olur — 7/24 NOC P1 altyapı olaylarını, 09:00-18:00 masa L1 taleplerini yönetir. İkisi için tek takvim kullanamazsınız.

En sık modellediğimiz üç vardiya deseni:

• Standart gündüz vardiyası. Pazartesi-Cuma, 09:00-18:00; SLA sayacını duraklatmayan bir saatlik öğle penceresiyle (teknisyenler öğleyi kasıtlı olarak üst üste bindirir).
• Uzatılmış gündüz. Pazar-Perşembe (iş takvimi Pazar-Perşembe olan finans sektörü masaları için), 07:00-21:00.
• Kesintisiz rotasyon. 7/24 üç vardiyalı; devir teslim 08:00, 16:00 ve 00:00'da. SLA sayacı kesintisiz işler; devir müşteriye görünmez.

Doğru takvim modeli servis masasının bütününe değil, SLA politikasına bağlanır. Bir P1 altyapı olayı 7/24 takvimine karşı ölçülür; bir P4 "beni grup posta kutusuna ekleyin" talebi 09:00-18:00 takvimine karşı ölçülür. Aynı kurum, iki takvim, talep bazında yönlendirme.

3. Teknisyen izni — kimsenin tartışmak istemediği tartışma

Er ya da geç bir SLA gözden geçirme toplantısında karşınıza çıkacak soru şudur: Cuma öğleden sonra Ayşe'ye bir P2 talep atandı. Ayşe ertesi Pazartesi'yi yıllık izin olarak aldı. SLA sayacı işlemeye devam etti. Dönüşünden dört iş saati sonra Salı sabahı çözdü ve rapor "ihlal etti" diyor. Bu adil mi?

İki ekol var:

1. Müşteri bakış açısı. Müşteri Ayşe'nin izinde olduğunu bilmez ya da umursamaz. SLA X iş saati içinde yanıt vaat ediyordu; yanıt gecikti; SLA ihlal etti. Kök neden: izin talep edildiğinde yönlendirme, talebi Ayşe'den almalıydı.
2. Ekip bakış açısı. Teknisyen izni SLA'yı duraklatmıyorsa, yüksek izin kullanımı olan servis masaları izin kullanmayı caydıran masalara göre suni olarak daha kötü görünür. Bu ters bir teşviktir.

Önerimiz ve varsayılan olarak inşa ettiğimiz model:

• Teknisyen izni atanmış talebin SLA'sını duraklatmaz.
• Bunun yerine, teknisyenin izni kuyruğundaki aktif taleplerle başladığında takvim sistemi yeniden atama tetikler.
• Yeniden atanan talep orijinal SLA'sını ve orijinal sayacını korur.
• Yönetici, teknisyenin SLA hedefi izin dönemine düşen talepleri varsa izin talebi anında uyarı alır.

Bu, doğru davranışı zorlar: izin planlaması bir yönetim sorumluluğudur ve SLA raporu iç kadro düzenlemesini değil, müşteri deneyimini yansıtır. Ekip teşviki korunmuş olur çünkü sayaç değil, talep taşınır.

4. Kullanıcı başı sessiz saatler

Ayrı ama komşu bir kavram: bazı kurumlar müşteriye "talebinize dört iş saati içinde yanıt verilir" vaat ederken, aynı zamanda teknisyene "SLA takvimi çalışsa bile 22:00 ile 07:00 arasında push bildirim almazsın" da vaat etmek ister. Modern ITSM bu ikisini ayrı ayrı modellemelidir.

Ayrım:

• SLA takvimi = işletmenin müşteriye vaadi. Sayacın ne zaman işleyeceğini yönetir.
• Kullanıcı başı bildirim takvimi = teknisyenin kişisel push/e-posta tercihi. Telefonun titreyip titremeyeceğini yönetir.

Bu ikisi çakışacaktır. 7/24 takvimde saat 03:00'te açılan bir P1 olayı, kimse üstlenmezse gerçek bir ihlaldir. Nöbetteki her teknisyenin bildirimleri sessizse, talep 07:00'ye kadar bekler ve müşterinin dört saatlik sayacı biter. Cevap ikisini birleştirmek değildir; nöbet rotasyonunu, nöbet penceresinde kişisel sessiz saatleri geçersiz kılan ayrı bir takvim olarak modellemektir.

5. Çok bölge ve saat dilimleri

İstanbul, Ankara ve Londra'da ofisleri olan bir kurumun tek bir iş günü yoktur — üç örtüşen iş günü vardır. SLA takvimi sunucunun yerel saatinde saklanırsa yaz saati geçişleri yılda iki kez raporlamayı sessizce bozar. UTC'de saklanırsa, arayüz dikkatli olmadıkça iş saatleri farklı bölgelerdeki kullanıcılar için kaymış görünecektir.

Kuralımız: tüm takvim girdileri depolamada UTC'dir ve her takvim kendi görüntüleme saat dilimini taşır. SLA hesaplaması UTC'ye karşı çalışır; arayüz takvimin saat dilimine göre render eder. Farklı saat diliminden kullanıcılar bile baktıkları takvim için doğru açılış saatini görür.

İstanbul takvimine karşı Europe/Istanbul saat 08:55'te açılan bir P1 iş saati içindedir. Aynı talep, London takvimine karşı 08:55 Europe/London'da açılırsa henüz iş saati içinde değildir (Londra 09:00 GMT = kışın 11:00 Europe/Istanbul, yazın 12:00 saatinde açılır). Hangi takvimin uygulanacağını yönlendirme belirler.

6. Acil değişiklik pencereleri

Değişiklik yönetimi bir kırışıklık daha ekler. Bir üretim sistemine acil değişiklik, servis masasının o sisteme bağımlı çözümü olan taleplerde SLA'yı duraklatmasını gerektirebilir. Bu, yönetici tetiklemeli SLA askıya alma için tek meşru durumdur.

Uyguladığımız kural:

• Acil değişiklik, başlangıç ve bitiş penceresine sahip birinci sınıf bir nesnedir.
• CI X'e bağlı olarak işaretli ve CI X değişiklikten etkileniyorsa, ilgili talebin SLA sayacı değişiklik penceresi boyunca duraklatılır.
• Duraksama, değişiklik ID'siyle birlikte kaydedilir; böylece denetim izi hangi talebin hangi değişiklik için duraklatıldığını gösterir.
• Değişiklik kapandığında duraklatılan tüm talepler otomatik olarak devam eder.

Bu, ihlalleri gizlemenin yolu değildir. Kontrollü bir kesinti sırasında çözümün gerçekten imkânsız olduğu gerçeğini modellemenin yoludur.

Hepsini bir araya getirmek

Tam takvim modeli, varlıklar düzeyinde şöyle görünür:

Bunlar ayrı endişelerdir ve öngörülebilir biçimde etkileşirler. SLA hesaplaması WorkCalendar + WorkCalendarHoliday + WorkCalendarOverride + SlaPauseWindow'u okur. Bildirim katmanı OnCallRotation + UserSilentHours'u okur. Raporlama; takvime, duraksama nedenine veya ihlal nedenine göre dilimlenebilir — çünkü her bilgi parçası saklanır, çıkarılmaz.

Bunun raporlama için önemi

İyi tasarlanmış bir takvim, ikinci ya da üçüncü çeyreklik gözden geçirmede kesinlikle ortaya çıkan soruya cevap verir: Talep #4728 neden ihlal etti? Cevap "etti" olmakla bitmez. İdeal olarak, talep açıldığında SLA paneli görünür ve panel hangi takvimin uygulandığını, hangi pencerelerin açık olduğunu, hangi duraksamaların gerçekleştiğini ve yanıttan önce kaç iş dakikasının geçtiğini tam olarak gösterir. Duraksama değişiklik kaynaklıysa değişiklik ID'si bağlanır. Teknisyen izindeydi ve talep yeniden atandıysa, yeniden atama zaman çizelgesinde görünür.

Bunu doğru modellemenin amacı mükemmeliyetçilik değildir. SLA raporlarının incelemeye alındığı gerçeğidir. CIO P2 uyum oranının neden düştüğünü sorduğunda, operasyon ekibinin ya değişimi tetikleyen spesifik talepler, takvimler ve duraksamalarla birlikte savunulabilir bir cevabı vardır — ya da yoktur ve SLA raporu bir araç olmaktan çıkıp şüphe nesnesine dönüşür.

LinaDesk uygulaması, kısaca

LinaDesk yukarıdaki tabloda geçen varlıkların her birini birinci sınıf Domain agregasyonu olarak modeller. WorkCalendar ana çıpadır; WorkCalendarHoliday ve WorkCalendarOverride alt kayıtlardır; SlaPolicy bir WorkCalendarId'ye referans verir. SLA hesaplaması, talebin durum geçişlerinin ve her geçişte görünen takvim varlıklarının saf bir fonksiyonudur. Duraksamalar açık kayıt olarak saklandığından, herhangi bir geçmiş talep için SLA hesaplamasını yeniden çalıştırmak bugün de kapandığı gün ürettiği aynı sonucu üretir — denetim ekiplerinin istediği budur ve mevcut takvime karşı yeniden hesap yapan ITSM sistemleri için doğru değildir.

Yazının başındaki Ramazan Bayramı talebi bu modelde bir ihlal değildir. Talep bayramdan önceki son iş günü saat 16:55'te açılır. Dört bayram günü için WorkCalendarHoliday takvimi kapalıya çeker. SLA sayacı yalnızca o cuma 17:00'ye kalan beş iş dakikasını sayar, sonra bayramdan sonraki ilk iş günü 09:00'da devam eder. Yanıt penceresi hayatta kalır.

İlgili yazılar

• 2026'da on-premise ITSM neden yeniden gündemde
• ManageEngine Service Desk Plus'tan geçiş — saha rehberi
• LinaDesk vs ServiceNow, ManageEngine, Freshservice — karşılaştırma tablosu
• LinaDesk Güvenlik ve Uyumluluk