Olay izleme
Olayların bir yaşam döngüsü vardır. En etkili şekilde yanıt vermek için, olayın kendisinin evrimini ve bu yaşam döngüsünün başından itibaren yanıtınızın evrimini izleyebilmelisiniz.
Neleri bildiğinizi değerlendirin
Belirli bir olayı kullanarak olay izleme yordamınızı değerlendirmenin iyi bir yolu kendinize bir dizi soru sormaktır:
- Sorun hakkında ne zaman bilgi sahibi oldunuz? Hedefiniz olaylardan kurtarmak için geçen süreyi kısaltmaksa sorundan haberdar olduğunuz andan itibaren bilgileri yakalamaya başlamanız gerekir.
- Sorunu nasıl tespit ettiniz? İzleme sisteminiz sizi olayla ilgili uyardı mı? Olayı doğrudan veya sosyal medya üzerinden şikayette bulunan müşterilerinizden mi duyduğunuz?
- Eğer sorunu yeni öğreniyorsan, bunu ilk bilen sen misin? Öyleyse kimleri bilgilendirmeniz gerekiyor? Değilseniz bu sorunu başka kim biliyor?
- Başkaları da haberdarsa bu konuda ne yapılıyor (bir şey yapılıyorsa)? Herkes bir başkasının ilgilendiğini mi düşünüyor yoksa bu konuda birileri bir şeyler yapmaya başladı mı?
- Durum ne kadar kötü? Önem derecesi veya etkiyle ilgili bir fikrimiz olmayabilir ve sorunun gerçekten ne kadar kötü olduğunu ve kimin etkilendiğini öğrenebileceğimiz bir yer yok.
İzlenen herhangi bir bileşen yoksa bu soruları yanıtlamak zor olabilir.
Olay bilgilerinin izleneceği yer için bir standart belirleyin
Olay listenizi (etkin veya diğer) ve bu olaylar hakkında sahip olduğunuz güncel bilgileri tutabileceğiniz ve paylaşabileceğiniz birçok yer vardır. Bunlar, Word belgeleriyle paylaşılan bir dosya alanı kadar basit ve son derece özelleştirilmiş olay izleme yazılımları ve hizmetleri kadar karmaşık olabilir. Bu iki uç noktada, bu görev için hizmete basabileceğiniz bilet oluşturma ve iş izleme sistemleri bulunur. Seçtiğiniz sistem aslında nasıl kullandığınızdan daha az önemlidir. Hangi sistemi kullanırsanız kullanın, olaylarla (mühendisler, müşteri desteği, yönetim, halkla ilişkiler, yasal vb.) herhangi bir bağlantısı olabilecek herkesin sistemi bulmak için nereye gideceğini, bir olayın nasıl tetikleneceğini ve uygun olduğunda verilere nasıl erişebileceğini bilmesi gerekir. Olay izleme konusunda başarısızlık garantili durumlardan biri, bu sistemi kullanacak olan kişilerin sisteme ihtiyaç duyduğunda erişim sağlayamamasıdır ("Bizim şu sistemin URL'si neydi?).
Bu modülde örnek izleme sistemimiz için Azure DevOps'un iş öğesi işlevselliğini kullanacağız.
Konuşma köprüsü oluşturma
Önceki Bildiklerinizi değerlendir bölümünde yer alan soruların bazılarını yanıtlamak ve olay yanıtı sürecini başlatmak için olay hakkında başkalarıyla iletişim kurmanın bir yolunun olması gerekir. İdeal olarak, bu konuşma için bir tür "ekip işbirliği" elektronik ortamı olacaktır, ancak telefon köprüleri de çalışır. Konferans aramaları/telefon köprüleri daha az tercih edilir, çünkü olay iletişimini geriye dönük olarak gözden geçirmek daha zordur (bu nedenle daha önce bahsedilen "Scribe" rolü).
Hangi ortamı seçerseniz seçin, bu olayla ilgili tartışmalarla sınırlı olan ve başka hiçbir şey yapmayan benzersiz bir kanal oluşturduğunuzdan emin olmalısınız. Verileri olay sonrası gözden geçirme sürecinde incelemeniz gerekeceğinden gereksiz konuşmaları bu kanalın dışında tutmanız önemlidir.
Bu modülde, olay iletişim yöntemimiz olarak Microsoft Teams'i kullanacağız.
Olay izleme sürecini başlatmayı otomatikleştirme
Şimdi buraya kadar öğrendiklerimizi gözden geçirelim. Elimizde olanlar:
- Aramadaki kişilerin listesi (ve onlar için tanımlanmış bir rotasyon).
- Bir olay üzerinde çalışan kişilere atayabileceğiniz rol.
- Olayı bildireceğimiz ve izleyeceğimiz belirli bir yer.
- Bu olay üzerinde çalışan kişilerin bu olay hakkında iletişim kurması için benzersiz kanal.
Tüm bunları mümkün olan en kapsamlı şekilde oluşturmayı ve yönetmeyi otomatikleştirebilir ve otomatikleştirmeniz gerekir. Acil bir sorun ortaya çıktığında olay oluşturmak, doğru kişileri çağırmak ve izlemek için gerekli tüm adımları tekrarlamak istemezsiniz. Tek istediğiniz tek bir düğmeye basarak hemen sorunla ilgilenmeye başlamaktır.
Kodsuz otomasyon için Logic Apps kullanın
İlk yanıtınızı otomatikleştirmenin bir yolu, görevleri, iş süreçlerini ve iş akışlarını zamanlama, otomatikleştirme ve düzenleme işini basitleştirebilen Logic Apps'i kullanmaktır.
Logic Apps, tümleşik çözümler oluşturmayı sağlayan bir Azure bulut hizmetidir. Otomatik iş akışları oluşturmak için bağlayıcıları kullanır. Tetikleyiciler , belirli bir olay gerçekleştiğinde veya veriler belirtilen ölçütleri karşıladığında Mantıksal Uygulamayı başlatır. Eylemler, sonrasında Logic Apps iş akışında gerçekleştirilen işlemlerdir.
Örneğimizde, olay izleme için aşağıdaki Logic Uygulama bağlayıcısı s kullanacağız:
- Sorunları/olayları oluşturmak ve izlemek için kullanabileceğiniz Azure Boards (Azure DevOps'un bir parçası).
- Azure Depolama' de, olaya yanıt vermek için uygun kişileri atayabilmeniz için kimlerin çağrıda olduğu hakkında bilgileri depolayabilir ve alabilirsiniz. Örneğimizde, mühendislerin listesini ve arama durumlarını depolamayı kolaylaştıran çok basit bir "anahtar-değer" deposu sunduğundan Azure Tablo Depolama kullanacağız.
- Mühendislik ekiplerinizin belirli olaylar hakkında iletişim kurarken konuşmalarını gerçek zamanlı olarak izlemek için yeni, benzersiz bir olay kanalı oluşturmak için kullanabileceğiniz Microsoft Teams. Bu, daha sonra olay sonrası gözden geçirme gerçekleştirirken olayların zaman çizelgesiyle ilgili etkileşimleri korumanıza olanak tanır.
Şimdi tüm bu parçaları bir mantıksal uygulamada bir araya getirelim. İlk olarak, Logic Apps Tasarım Aracı gösterildiği gibi uygulamanın tamamına göz atın, ardından adım adım ilerleyeceğiz.
İlk adım, bahsettiğimiz HTTP isteği olan bir tetikleyiciyi işlemektir. Mantıksal uygulamamıza bildirmek istediğimiz olay hakkında bilgiler içeren bir JSON yüküne sahip olan bir HTTP POST isteği gönderilir. Bu yükü ayrıştırıp aldığımıza dair bir onay göndeririz:
Bu bilgileri kullanarak Azure DevOps kuruluşumuzda bu olayı temsil eden yeni bir iş öğesi oluşturuyoruz.
Ardından olay için yeni bir Teams kanalı oluşturur:
Kanal oluşturulduktan sonra, az önce oluşturduğumuz iş öğesi yeni kanalın bağlantısıyla güncelleştirilir. Bu sayede tüm bilgiler aynı yerde (aynı iş öğesinde) tutulur ve daha sonra bunu inceleyenler kanala katılmak için nereye gitmeleri gerektiğini öğrenmiş olur.
Şimdi, arayan kişiyi resme getirmenin zamanı geldi. Azure Tablo Depolama'nde, aramada olarak listelenen mühendisin e-posta adresi için bir arama gerçekleştiririz. Bu, daha sonra ayrıştırdığımız bir JSON yanıtı döndürür.
Sorgumuz bir liste döndüreceği için, bir sonraki adım olarak bu listedeki her öğeyi yinelememiz gerekir. İş öğesini bu kişilerin her birine atıyoruz (bunlar artık olayın "sahipleri").
Ardından, son adım olarak Teams kanalına, kanala katılan ve bu olayla ilgili yetkili bilgilerin nerede depolandığını öğrenmek isteyen kişiler için iş öğesine geri dönen bir işaretçiyle bir ileti göndeririz.
Bu, olay izleme ve iletişim mekanizmalarının ayarlanmasını otomatikleştirmenin yalnızca bir örneğidir. Bir sonraki ünitede olayla ilgili iletişim konusunda daha fazla ayrıntıya gireceğiz.