Xurrent’te Bir Talebi Bağımlı Görevlere Bölmek

Çok lokasyonlu bir kurumda “yeni sunucu kurulumu” kaydı açılmıştı. Merkezi sistem ekibi kuruluma hazır görünüyordu, fakat yerel ekip aktarılacak kullanıcı verisini henüz toplamamıştı. Ana kayıt tek kişiye atanmış olduğu için panelde iş başlamış, hatta SLA ilerliyor görünüyordu. Gerçekte iki ayrı teslimat ve bunlar arasında açık bir ön koşul vardı. Sorun teknik kapasiteden çok işin ITSM aracında yanlış modellenmesiydi.

Xurrent gibi platformlarda request, workflow ve task kavramlarını ayırmak yalnızca düzenli ekran elde etmek için yapılmaz. Doğru model, bir sonraki görevin ne zaman açılacağını, kimin beklediğini, hangi kanıtla tamamlanacağını ve talebin ne zaman kapanabileceğini belirler. Sahada en iyi sonuç, her ayrıntıyı yüzlerce göreve bölmekten değil, gerçek devir noktalarını görünür kılmaktan geldi.

Sorunun ortaya çıkışı

Talep kataloğunda sunucu kurulumu tek faaliyet olarak tanımlanmıştı. Oysa yerel BT veri listesini çıkaracak, iş sahibi kapsamı onaylayacak, merkezi ekip altyapıyı hazırlayacak ve son kabul yapılacaktı. İlk adım tamamlanmadan ikinci adımın başlaması veri kaybı ve yeniden çalışma riski yaratıyordu. E-posta ile koordinasyon yapıldığında bu bağımlılık yalnızca kişilerin hafızasında kalıyor, izin veya vardiya değişiminde süreç duruyordu.

İlk belirtiler ve yanlış varsayımlar

Yönetim raporunda merkezi ekip gecikiyor görünürken ekip, yerel hazırlığı beklediğini söylüyordu. İlk varsayım daha fazla hatırlatma göndermekti. Ancak bildirim sayısını artırmak sahipliği düzeltmez. Başka bir yanlış yaklaşım da her alt işi ayrı request yapmaktı; bu durumda ortak sonuç, ilişki ve kapanış koşulu parçalanacaktı. Tek kayıt altında yapılandırılmış görevler daha doğru bir hizmet görünümü sağladı.

Teknik analiz

Önce hizmetin aşamalarını ve giriş-çıkış kriterlerini yazdık. Yerel hazırlık görevinin çıktısı onaylı veri listesi, merkezi kurulum görevinin girdisi bu listeydi. Atama grupları lokasyona göre çözümlenmeli, görev bağımlılığı predecessor tamamlanmadan successor başlamayacak biçimde kurulmalıydı. Ana request tüm görevler tamamlanmadan kapanmamalı; iptal, ret ve eksik bilgi yolları da normal akış kadar açık olmalıydı.

Uygulanan çözüm veya önerilen mimari

Katalog öğesine iki temel görevli bir workflow bağladık. İlk görev ilgili lokasyonun destek grubuna atandı ve standart veri hazırlama kontrolünü içerdi. Tamamlanma kanıtı eklendiğinde merkezi kurulum görevi aktif oldu. Kurulumdan sonra talep sahibine kabul adımı gönderildi. Otomatik bildirimler yalnızca atama, gecikme eşiği ve devir anında üretildi; gereksiz e-posta gürültüsünden kaçınıldı. İstisnalar için hizmet yöneticisine kontrollü eskalasyon tanımlandı.

Alternatifler ve karar gerekçesi

Basit checklist daha az yapılandırma gerektirir, ancak görevlerin farklı ekiplere atanması ve ayrı sürelerinin ölçülmesi gerekiyorsa yetersiz kalır. Ayrı talepler bağımsız hizmetler için uygundur; aynı çıktının parçaları için ilişki yönetimini zorlaştırır. Tam otomasyon, yüksek hacimli ve kararlı süreçte değerlidir; düşük hacimde bakım maliyeti yaratabilir. Bu vakada iki bağımlı görev, görünürlük ile yönetim yükü arasında dengeli çözümdü.

Güvenlik ve operasyonel riskler

Görev açıklamasına kullanıcı parolası, gerçek sunucu adı veya hassas dosya yolu yazılmaması kuralını ekledik. Eklerin erişimi yalnızca ilgili gruplarla sınırlandı ve saklama politikası uygulandı. Yanlış lokasyona otomatik atama, işin gereksiz kişilere görünmesine yol açabileceğinden yönlendirme tablosu periyodik kontrol edildi. Acil taleplerin bağımlılığı yetkisizce atlamaması için bypass hakkı sınırlı ve kayıtlı tutuldu.

Çıkarılan Dersler

Kontrol Listesi