Olay izleme

7 dakika

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.

Bildiklerinizi değerlendirme

Belirli bir olayı kullanarak olay izleme yordamınızı değerlendirmenin iyi bir yolu kendinize bir dizi soru sormaktır:

Sorunu ilk ne zaman öğrendin? Amacınız olaylardan kurtarmak için gereken süreyi azaltmaksa, sorunları fark ettiğiniz andan itibaren bilgileri yakalamaya başlamanız gerekir.
Sorunu nasıl öğrendin? İzleme sisteminiz sizi olay hakkında uyarmış mıydı? Bunu ilk olarak doğrudan veya sosyal medyada şikayet eden müşterilerinizden mi duydunuz?
Eğer sorunu yeni öğreniyorsan, bunu ilk bilen sen misin? Öyleyse, kime bildirmeniz gerekiyor? Aksi takdirde, sorunun başka kimler farkındadır?
Başkaları farkındaysa, bu konuda (herhangi bir şey varsa) ne yapılıyor? Herkes başka birinin araştırdığını mı yoksa bu sorunu çözmek için eyleme mi başladığını varsayıyor?
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.

Hiçbir şey izlenmiyorsa bunları yanıtlamak zor olabilir.

Olay bilgilerinin nereye izleneceğini standartlaştırma

Olay listenizi (etkin veya başka bir şekilde) ve bu olaylarla ilgili tüm güncel bilgileri saklayıp paylaşabileceğiniz birçok olası 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ç nokta arasında, bu görev için kullanabileceğiniz biletleme ve iş takip 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 izlemede başarısız olmak için emin bir yol, destek alacağı kişilerin ihtiyaç duyduklarında sisteme nasıl ulaşacaklarını bilmemeleridir ("sistemimizin 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ğerlendirin bölümünde yer alan bazı soruları 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. Olay sonrası incelemenizde verileri alıp analiz edebilmeniz gerektiğinden, ilgisiz tartışmaları bu kanalın dışında tutmak önemlidir.

Bu modülde, olay iletişim yöntemimiz olarak Microsoft Teams'i kullanacağız.

Olay izleme başlatmayı otomatikleştirme

Şimdiye kadar bir araya getirdiğimiz parçaları gözden geçirelim. Bizde bir ...

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 çıkarmak, doğru kişileri getirmek ve izlemek için gereken tüm adımları hatırlamak zorunda kalmak istemezsiniz. Gerçekten yapmak istediğiniz tek şey" git" düğmesine basabilmektir, böylece iş hemen sorunla ilgilenmeye başlayabilir.

Kodsuz otomasyon için Logic Apps kullanma

İ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ştirme çözümleri oluşturmaya yönelik bir Azure bulut hizmetidir. Otomatik iş akışları oluşturmak için bağlayıcıları kullanır. Tetikleyicileri belirli bir olay gerçekleştiğinde veya veriler belirtilen ölçütleri karşıladığında Mantıksal Uygulamayı başlatır. Eylemler daha sonra Logic App iş akışında gerçekleştirilen işlemlerdir.

Örneğimizde, olay izleme için aşağıdaki Logic App bağlayıcılarını kullanacağız:

Sorunları/olayları oluşturmak ve izlemek için kullanabileceğiniz Azure Boards (Azure DevOps'un bir parçası).
Azure Depolama, olaylara yanıt vermesi için kimlerin aramada olduğunu belirten bilgileri depolayabilir ve alabilirsiniz, böylece uygun kişileri atayabilirsiniz. Örneğimizde, mühendislerin listesini ve nöbet durumlarını depolamayı kolaylaştıran çok basit bir "anahtar-değer" deposu sunduğu için Azure Tablo Depolama'yı kullanacağız.
Microsoft Teams, mühendislik ekiplerinizin belirli olaylar hakkında iletişim kurarken konuşmalarını gerçek zamanlı olarak izlemek üzere yeni, benzersiz bir olay kanalı oluşturmak için kullanabilirsiniz. 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 bunları bir Mantıksal Uygulama ile birleştirelim. İlk olarak, Logic Apps Tasarımcısı'nda gösterildiği gibi uygulamanın tamamına göz atın, ardından adım adım ilerleyeceğiz.

Logic Apps Tasarımcısı'nda gösterildiği gibi mantıksal uygulamanın uzaklaştırılmış görünümünün ekran görüntüsü.

İlk adım, bahsettiğimiz HTTP isteği olan bir tetikleyiciyi işlemektir. Mantıksal uygulamamıza bildirmek istediğimiz olay hakkında bilgi içeren bir JSON yükü içeren bir HTTP POST isteği yapılır. Biz bu veriyi ayrıştırır ve aldığımızı belirten bir onay göndeririz.

Mantıksal Uygulama Tasarımcısı görünümünde mantıksal uygulamanın HTTP ve Yanıt bloğunun ekran görüntüsü .

Bu bilgileri kullanarak Azure DevOps kuruluşumuzda bu olayı temsil eden yeni bir iş öğesi oluştururuz.

Logic App Tasarımcısı görünümünde iş öğesi yaratma bloğunun ekran görüntüsü.

Ardından olay için yeni bir Teams kanalı oluşturur:

Logic App Tasarımcısı'nda bir kanal bloğu oluşturma görünümünün ekran görüntüsü.

Kanal oluşturulduktan sonra, az önce oluşturduğumuz iş öğesi yeni kanalın bağlantısıyla güncelleştirilir. Bu, tüm bilgileri aynı yerde (iş öğesi) tutar ve daha sonra bakan kişilerin bu kanala katılmak istediklerinde nereye gideceklerini bilmelerini sağlar.

Logic App'in Mantıksal Uygulama Tasarımcısı görünümündeki iş öğesi blok güncellemesi ekran görüntüsü.

Şimdi, arayan kişiyi resme getirmenin zamanı geldi. Azure Tablo Depolama'da, 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.

Logic App içinde, Logic App Designer görünümündeki Varlıkları Getir bloğunun ekran görüntüsü.

Sorgumuz bir liste döndüreceği için, bir sonraki adım olarak bu listedeki her öğeyi yinelememiz gerekir. İş öğesini her kişiye atarız (bunlar artık olayın "sahipleri").

Mantıksal Uygulama Tasarımcısı görünümündeki Foreach bloğunun ekran görüntüsü.

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.

Logic App Designer görünümündeki Akış botu kanal bloğu üzerinden bir ileti gönderme işleminin ekran görüntüsü.

Bu, olay izleme ve iletişim mekanizmalarının ayarlanmasını otomatikleştirmenin yalnızca bir örneğidir. Bir sonraki ünitede, bir olayla ilgili iletişimin biraz daha derinine ineceğiz.