Hazırlık neden teknik işin bir parçasıdır?
Saha ekibi ofise geldiğinde ağ dolabının kilitli olduğunu, yönetici hesabının kimde olduğunu kimsenin bilmediğini veya yapılacak değişiklik için kesinti izni olmadığını öğrenirse teknik olarak basit bir iş saatlerce bekleyebilir.
Hazırlığın amacı sorunu uzaktan tamamen çözmek değildir. Bildiklerimizi ve henüz bilmediklerimizi ayırmak, hangi erişimlerin gerekeceğini görmek ve çalışma sırasında kimden karar alınacağını önceden belirlemektir.
Örneğin switch değişecekse yalnızca yeni cihazı getirmek yeterli olmaz. Mevcut VLAN yapısı, uplink bağlantıları, yönetim erişimi, gerekiyorsa mevcut yapılandırmanın kopyası ve değişiklik sırasında hangi hizmetlerin kesileceği de bilinmelidir.
Bunlar ziyaret öncesinde görülürse saha zamanı kapı, parola veya parça aramak yerine gerçek teknik işe ayrılır.
Sorun nasıl tarif edilmeli?
Saha talebinde yalnızca cihazın veya sistemin adını yazmak yeterli bilgi vermez. Sorunun ne zaman başladığı, sürekli mi yoksa aralıklı mı olduğu, hangi kullanıcı veya alanları etkilediği ve tam olarak neyin yapılamadığı bilinmelidir.
Mümkünse hata mesajı, cihaz etiketi, oda veya bağlantı noktası gibi bilgiler de eklenir. Yakın zamanda kablo, cihaz, yazılım veya yerleşim değiştiyse bunun belirtilmesi tanıyı ciddi biçimde hızlandırabilir.
Teknik arıza ile iş etkisini de birbirinden ayırmak gerekir. Tek bir yazıcının çalışmaması küçük görünebilir ama o yazıcı sevkiyat etiketi basan tek cihazsa işletme açısından önceliği yüksektir.
Aynı nedenle 'sunucu CPU kullanımı yüksek' ifadesi tek başına aciliyet belirlemez. Kullanıcıların çalışmasını etkileyip etkilemediği ve hangi hizmete bağlı olduğu daha önemlidir.
- Sorun ne zaman başladı?
- Sürekli mi, belirli zamanlarda mı tekrar ediyor?
- Hangi kullanıcı, cihaz, oda veya hizmet etkileniyor?
- Ekranda görülen tam hata veya belirti ne?
- Yakın zamanda fiziksel veya yazılımsal bir değişiklik yapıldı mı?
- Geçici çözüm var mı?
- İş tamamen durdu mu, yavaşladı mı veya yalnızca bir işlev mi kayboldu?
Erişim ve üçüncü taraf bağımlılıkları neden önceden kontrol edilmeli?
Teknisyenin çalışacağı fiziksel alana ve yönetim ekranlarına nasıl erişeceği ziyaret öncesinde bilinmeli. Ağ dolabı, sunucu odası veya cihazın bulunduğu bölüm için özel yetki gerekiyorsa ilgili kişi çalışma saatinde erişilebilir olmalıdır.
Yönetici parolalarının e-posta, mesaj veya açık metin bir notla paylaşılması doğru yöntem değildir. Gereken erişim mümkünse görev için oluşturulmalı, ihtiyaç kadar yetki vermeli ve çalışma bittikten sonra kapatılmalıdır.
Sorunun tamamı işletmenin kendi altyapısında olmayabilir. İnternet servis sağlayıcısı, bina yönetimi, elektrik firması, yazılım üreticisi veya başka bir donanım tedarikçisi zincirin bir parçası olabilir.
Örneğin internet hattında fiziksel sinyal problemi varsa firewall üzerinde saatlerce ayar değiştirmek çözüm üretmez. Hangi tarafın hangi noktadan sorumlu olduğunu önceden bilmek yanlış yerde zaman kaybetmeyi azaltır.
Değişiklikten önce geri dönüş yolu neden düşünülmeli?
Çalışan bir firewall, switch, sunucu, DNS kaydı veya depolama sistemi üzerinde değişiklik yaparken yalnızca hedef durumu düşünmek yeterli değildir. Beklenmeyen sonuç çıkarsa hangi noktaya geri dönebileceğimizi de bilmemiz gerekir.
Buradaki 'yedek var' cümlesi tek başına fazla geniştir. Firewall yapılandırma dosyası, sunucu veri yedeği ve sanal makine geri dönüş noktası aynı şeyi sağlamaz. Yapılacak değişiklik neyse geri dönüş planı da onu gerçekten eski haline getirebilmelidir.
Örneğin DNS değişikliğinde önce eski kayıtların bilinmesi gerekir. Switch değişikliğinde mevcut port ve VLAN yapısı gerekebilir. Bir uygulama güncellenecekse veritabanı ve uygulama sürümünün birlikte geri döndürülüp döndürülemeyeceği önem kazanabilir.
Ayrıca geri dönüş kararı için bir eşik belirlemek faydalıdır. Beklenen sonuç alınmıyorsa ne kadar daha deneme yapılacak? Hangi noktada değişiklik durdurulup önceki yapı geri getirilecek? Bu karar olay sırasında ilk kez tartışılırsa kesinti gereksiz yere uzayabilir.
Teknisyen ayrılmadan önce ne doğrulanmalı?
Teknik işlem tamamlandıktan sonra ilk baştaki sorun yeniden test edilmelidir. Bir parçanın değiştirilmiş veya yeni ayarın kaydedilmiş olması sonucu kanıtlamaz.
Mümkünse etkilenen kullanıcı veya hizmet sahibi gerçek işini tekrar dener. Yazıcı sorunu çözüldüyse test sayfası kadar kullanıcının gerçek belgesini basabilmesi de önemlidir. Ağ değişikliğinde yalnızca cihazların ping atması değil ilgili uygulamaların çalışması kontrol edilmelidir.
Yapılan değişiklik de kayda geçirilir. Değiştirilen parça, yeni IP, port, VLAN, yapılandırma veya geçici çözüm daha sonra tekrar ihtiyaç duyulabilecek bilgidir.
Geçici yönetici hesabı, açık bırakılmış uzak erişim veya bakım için verilmiş fiziksel izin varsa çalışma sonunda kapatılmalıdır. Açık bir risk kaldıysa kimin takip edeceği ve ne zaman yeniden bakılacağı belli olmalı.
- Başlangıçtaki problem tekrar test edildi mi?
- Kullanıcı veya hizmet sahibi gerçek iş akışını doğruladı mı?
- Yapılan değişiklik ve kullanılan parça kaydedildi mi?
- Geçici çözüm kaldıysa bunun sahibi ve tarihi belli mi?
- Takip edilmesi gereken alarm veya metrik var mı?
- Geçici yönetici ve fiziksel erişimler kapatıldı mı?
Saha çalışmasının kalitesi yalnızca müdahale anında belirlenmez.
Sorunun belirtisi, iş etkisi, erişimler, üçüncü taraf bağımlılıkları ve geri dönüş yolu önceden düşünülürse ziyaret daha az belirsizlikle ilerler. Sonunda da yapılan iş gerçek kullanım üzerinden doğrulanır.
Bu içerik genel bilgilendirme amaçlıdır. İşletmenize özel teknik inceleme, güvenlik garantisi veya hukuki görüş yerine geçmez.