Kısa cevap: Müdahale süresi sorunun incelenmeye başlanmasını, çözüm süresi ise belirlenmiş sonuca ulaşılmasını ifade eder. Bunlar erişilebilirlik yüzdesiyle de aynı ölçü değildir; hizmet kapsamında ayrı tanımlanmalıdır.
Bu çalışma ne zaman gerekli?
Teklifleri karşılaştırırken zaman ölçümünün başlangıcını ve destek saatlerini sorun. Bu rehber hukuki sözleşme incelemesi değildir.
Operasyon bağlamında değerlendirme
Yönetilen IT hizmetinde araç kurulumu kadar görevin sahipliği de önemlidir. Bir işi başlatan talep, gerekli onay, uygulayan kişi ve sonucu kabul eden taraf aynı olmak zorunda değildir. Roller belli değilse teknik olarak yapılmış iş bile kullanıcı açısından tamamlanmamış kalabilir. Bu nedenle her süreç için giriş bilgisi, beklenen çıktı ve istisna yolu tanımlayın. Ölçüm sırasında yalnızca adet veya ortalama süreye bakmayın; tekrar eden olayları, açık iş yaşını ve iş etkisini de görünür kılın. Her toplantının sonunda sorumlusu ve hedef tarihi belli aksiyon bulunsun. Gerçekte sağlanmayan destek saatlerini veya çözüm taahhütlerini varsaymayın. Hizmet modeli kurumun çalışma takvimi ve mevcut iç ekiple birlikte şekillenmelidir.
Somut kontrol tablosu
| Başlık | İnceleme ve beklenen çıktı |
|---|---|
| Başlangıç | Talebin hangi kanalda kayıt altına alındığında sürenin başladığını yazın. |
| Takvim | Mesai, tatil ve nöbet kapsamını açıklaştırın. |
| Bekleme | Kullanıcı veya tedarikçi yanıtı beklerken durumun nasıl raporlandığını belirleyin. |
| Sonuç | Geçici toparlama ile kalıcı çözümü ayrı kaydedin. |
Çalışmayı hangi sırayla yürütmelisiniz?
- Başlangıcı kaydedin. Etkilenen sistem, sürüm, iş akışı ve sorumluları belirleyin. Varsayımları ölçülmüş veriyle karıştırmayın.
- Küçük kapsamla deneyin. Gerekli onayları aldıktan sonra temsili pilot seçin. Üretim verisi ve erişimlerini kurumun güvenli yöntemleriyle koruyun.
- Sonucu karşılaştırın. Aynı işi önce ve sonra değerlendirin. Tek bir başarılı denemeyi bütün koşullar için garanti saymayın.
- Açık işleri devredin. Eksik kalan başlığa sorumlu ve hedef tarih verin. Geçici istisnaları görünmez hale getirmeyin.
Örnek karar senaryosu
Örneğin uygulama dış üretici hatasına bağlı çalışmıyor olsun. IT ekibi hızlı müdahale etmiş olabilir, fakat düzeltme sürümü beklenir. Kayıt iki süreyi ayrı gösterdiğinde iş sahibi durumun nedenini daha doğru anlar.
Bu senaryo açıklama amacıyla oluşturulmuştur; gerçek müşteri projesi veya ölçülmüş başarı iddiası değildir.
Hangi yanılgıdan kaçınmalısınız?
Belirsiz hızlı destek ifadesinden ölçülebilir süre çıkarılamaz. Kurumun gerçekten ihtiyaç duyduğu destek modelini yazılı kapsamla doğrulayın.
Kabul ölçütü ve teslim kaydı
Örnek bir olayın bütün zaman noktaları aynı tanımlarla hesaplanabilmeli ve kapsam dışı bağımlılıklar görülebilmelidir.
Teslim notunda ölçüm tarihi, kullanılan veri kapsamı, yapılan değişiklik, doğrulanan iş ve kapsam dışında kalan durumlar bulunsun. Başarısız veya denenmemiş adımları başarılı gibi göstermeyin. Aynı konu başka ekip tarafından ele alındığında tekrar başlangıç araştırması yapılmaması için ilgili talep ve belge bağlantılarını koruyun. Kontrolün ne zaman yeniden yapılacağı da belli olsun.
İlgili araç ve sonraki adım
İlgili ücretsiz CieloSync aracı ile başlangıç bilgilerinizi düzenleyebilirsiniz. Araç sonucu teknik uygunluk veya fiyat teklifi yerine geçmez. Kapsam için ilgili CieloSync çözümünü inceleyin; mevcut yapınızı değerlendirmek için bizimle iletişime geçin.
Teknik başvuru
Azure Monitor başvuru belgeleri. Resmî başvuru kavram ve ürün çerçevesini sağlar; bu rehberdeki örnekler ve işletim kontrol listesi CieloSync için özgün olarak hazırlanmıştır. Uygulamadan önce kullandığınız ürünün tam sürümüne ait belgeleri doğrulayın.