Bir servis kesildiğinde ekibin ilk hedefi işi yeniden çalışır hâle getirmektir. Fakat servis geri geldiğinde aynı olayın tekrar etmesini önleyecek çalışma yapılmıyorsa teknik ekip sürekli benzer arızalara döner. Incident, problem ve değişiklik yönetimi ayrımı, bu döngüyü daha anlaşılır görevler hâline getirmeye yardımcı olur.
Bu yazı ağır bir süreç veya yeni araç satın alma zorunluluğu önermiyor. Küçük bir IT ekibi de doğru kayıt ve sorumluluklarla aynı yaklaşımı kullanabilir. Önemli olan her bildirim için uzun form doldurmak değil; hizmeti geri getirme, nedeni araştırma ve değişikliği kontrollü uygulama işlerinin birbirine karışmamasıdır.
Üç farklı soru, üç farklı çalışma
Incident yönetimi, yaşanan kesinti veya hizmet kalitesi düşüşüne müdahaleyi ele alır. Problem yönetimi, olayların altında yatan nedenleri ve tekrarın azaltılmasını araştırır. Değişiklik yönetimi ise sistemde yapılacak müdahalenin planını, riskini ve doğrulamasını düzenler. Atlassian problem yönetimi açıklaması, bu ilişkileri bir ITSM üreticisinin çerçevesiyle ele alır.
Örneğin bir uygulama yeniden başlatıldıktan sonra çalışmaya dönmüş olabilir. Olayın etkisi sona ererken altta yatan bellek sorunu devam edebilir. Kalıcı düzeltme uygulama sürümü değişikliği gerektiriyorsa ayrıca bir değişiklik planı gerekir. Tek bir destek kaydına “çözüldü” yazmak bu üç işin tamamlandığını kanıtlamaz.
1. Olayı iş etkisiyle kaydedin
İlk kayıtta etkilenen hizmet, kullanıcı grubu, başlangıç zamanı ve gözlenen belirti bulunsun. Teknik ekip hangi sunucunun sorunlu olduğunu henüz bilmiyor olabilir; buna rağmen iş etkisi kaydedilebilir. Önceliği yalnızca en çok mesaj atan kişiye göre değil, etki ve aciliyete göre değerlendirin.
Olayın sahibi ve iletişim sorumlusu belli olsun. Birden fazla ekip çalışıyorsa herkesin ayrı kanaldan farklı bilgi vermesi karışıklık yaratabilir. Kısa ve doğrulanmış durum güncellemeleri kullanın. Henüz bilinmeyen neden için kesin ifade vermek yerine neyin bilindiğini ve hangi incelemenin sürdüğünü anlatın.
2. Geçici çözümü kalıcı çözümden ayırın
Hizmeti yeniden çalıştıran bir geçici çözüm, işletme açısından değerli olabilir. Bunu değersiz saymak yerine kapsamını ve yan etkisini belgeleyin. Geçici adımın hangi koşulda tekrar kullanılabileceği ve neyi çözmediği açık olmalıdır. Böylece sonraki nöbetçi aynı işlemi körlemesine tekrar etmek zorunda kalmaz.
İş sahibi hizmetin geri geldiğini doğruladığında olay kapatılabilir; tekrar riski varsa problem kaydıyla bağlantı korunur. Her küçük olay için ayrı uzun analiz gerekmez. Tekrar sıklığı, iş etkisi ve belirsizlik seviyesi hangi kayıtların daha derin inceleneceğini belirlemeye yardımcı olur. Kaynaklar en çok değer üretecek alanlara ayrılmalıdır.
3. Problem araştırmasını kanıta dayandırın
Problem kaydında varsayımlar ve kanıtlar ayrı dursun. Log, zaman çizelgesi, kapasite ölçümü ve son değişiklikler birlikte değerlendirilir. İlk bulunan teknik belirtiyi otomatik olarak kök neden ilan etmeyin. Bir dosyanın dolmasıyla neden izleme veya temizlik mekanizmasının çalışmadığı farklı inceleme katmanlarıdır.
Araştırmanın çıktısı yeni bir düzeltme, geçerli bir geçici çözüm veya ek ölçüm ihtiyacı olabilir. Her çalışmanın ilk toplantıda kesin neden üretmesi beklenmez. Ancak bir sonraki adımın sahibi ve beklenen kanıtı belli olmalıdır. Açık problem listesi, sorumlusu olmayan bir şikâyet arşivine dönüşmemelidir.
4. Değişikliği geri dönüşüyle planlayın
Bir güncelleme, yapılandırma veya kapasite değişikliği yapılacaksa etki alanı ve kabul ölçütü belirlenmelidir. Hangi hizmetler etkilenebilir, hangi testler yapılacak ve başarısızlıkta nasıl geri dönülecek? Bunların cevabı yalnızca komutu çalıştıracak kişinin zihninde kalmamalıdır. İlgili iş sahipleri takvimi bilmelidir.
Atlassian değişiklik türleri açıklaması, standart, normal ve acil değişiklikleri farklı değerlendirme ihtiyacını gösterir. Acil olması kayıtsız uygulanacağı anlamına gelmez. Kısa karar yolu, yetkili kişi ve sonradan tamamlanacak inceleme düzeni bulunabilir. Kurumun ölçeğine uygun bir model seçilmelidir.
5. Kapanışta öğrenilen bilgiyi erişilebilir tutun
Çözüm notunda yalnızca “düzeltildi” yazmak yerine yapılan işlem ve son test yer alsın. Yeniden kullanım değeri olan bilgiler kısa bir bilgi bankası maddesine dönüştürülebilir. Gereksiz iç ayrıntıları herkese açmadan, ilgili ekibin ihtiyaç duyduğu seviyede dokümantasyon hazırlayın. Gizli anahtar veya kullanıcı verisi çözüm notuna eklenmemelidir.
Varsayımsal bir disk doluluğu olayında sadece dosya silmek yerine log politikası, kapasite uyarısı ve uygulama davranışı birlikte incelenebilir. Kalıcı değişiklikten sonra doluluk eğilimi yeniden ölçülür. Sonuç beklenen gibi değilse problem kaydı tekrar değerlendirilir. Böylece kayıt kapatmakla hizmeti geliştirmek arasındaki fark görünür olur.
İşe yarayan göstergeler
Tekrar eden olaylar, uzun süre açık kalan problemler, başarısız değişiklikler ve doğrulanmış geri dönüşler izlenebilir. Ham kayıt sayısı tek başına ekip başarısını göstermez. Daha az kayıt açılması, sorunların azalmasından da kayıt disiplininin zayıflamasından da kaynaklanabilir. Ölçümleri bağlamıyla birlikte okuyun.
CieloSync ile yönetilen IT süreçlerinizi teknik işletim ve raporlamayla birlikte oluşturabilirsiniz. Mevcut destek modelinizi paylaşın; işinize uygun kayıt ve sorumluluk düzenini belirleyelim.