15 Yıllık Yazılım Olay Yönetiminden Bir Düzine (ya da O Kadar) Ders

Bir yazılım mühendisi olarak olaylarla uğraşmak berbat bir şey. Cumartesi sabahı saat 3'te çağrı sayfasını mı alıyorsunuz? Korku uyandıran, ruh emen ve tamamen iğrenç bir olay olabilir. İşyerinizde sık sık oluyorsa, kelimenin tam anlamıyla TSSB'yi tetikleyebilir.

Ne yazık ki bu, yazılımın ruhunun bir parçası. Aksine, bunlar gerçek mühendisliğin şekillendiği ateşlerdir. Bu olaylar size sağlamlaştırılmış sistemlerin nasıl tasarlanacağını ve çoğu durumda nasıl yapılmayacağını öğretir.

Bu makale, yazılım olaylarıyla nasıl başa çıkılacağına ilişkin 2 hususu ele almaktadır:

• 🛠️Bu deneyimleri önlemek ve bunlardan ders çıkarmak için kişinin yazılım platformuna ve ekiplerine aşılaması gereken uygulamalar.

• 🧘 Kişinin sahip olması gereken tutum, dirençli olmak ve bu deneyimlerden sadece zarar görmeden değil, girdiklerinden daha fazlasıyla ayrılmaktır.

Ele alacağımız konular şunlar;

1. Sistemlerinizi mümkün olduğunca otomatikleştirin
2. Öncü ve gecikmeli göstergelerin takibi
3. "Harekete geçirilebilir" Uyarılar apaçık olmalıdır
4. Açık çağrı zincirleri ve yükseltme yolları oluşturun
5. Büyük kararlar almak için ön safları güçlendirin
6. Tüm olaylar eşit yaratılmamıştır
7. Önce çöz, sonra soru sor
8. Bir kişinin sorumlu olduğundan emin olun
9. Açık ve sık iletişim kurun
10. Suçsuz otopsiler çok önemli
11. Otopsi sonrası takipler hayati önem taşıyor
12. MTTD düşük olduğu sürece olaylar kötü değil
13. Mizah harika bir dengeleyicidir

Biraz ayrıntıya girelim!

Sistemlerinizi Mümkün Olduğu Kadar Otomatikleştirin

Müşterileriniz aracılığıyla veya olayın başladığı günden günler veya haftalar sonra bazı ciddi muhasebe tutarsızlıkları nedeniyle öğrendiğiniz olay sayısını gerçekten en aza indirmek istiyorsunuz. "Otomasyon" mühendislikte aşırı kullanılan bir kelime olsa da, bu, sinyal-gürültü oranının doğru dengesini bulmayı ve sizin ve ekibinizin herhangi bir insan müdahalesine ihtiyaç duymadan uyarılar almasını sağlamayı gerçekten istediğiniz alanlardan biridir.

Aralarından seçim yapabileceğiniz çok fazla şey varsa, süper üst seviyeye geçin. Seçebileceğiniz en üst düzey metrik nedir? Bileşen sistemleri beklendiği gibi çalışmazsa normdan sapacak mı? Bu, platform üzerinden akan gelirin (e-ticaret, finans veya $ tabanlı bir platform için) veya mevcut aktif kullanıcı sayısının (sosyal medya platformları için) izlenmesi olabilir.

Rakamların kraterlendiğini veya bir veya iki standart sapma düştüğünü görürseniz derhal geliştirme ekibini uyarın. İlk (veya en önemli) uyarıları işin nabzına veya temel kullanıcı deneyimine odaklamak, izlenmesi harika bir ölçüm olacaktır. Daha karmaşık hale geldikçe ve sistemi daha iyi anladıkça, gözlemlenebilirlik açısından yığının daha derinlerine inmeye başlayabilirsiniz.

Öncü ve Gecikmeli Göstergelerin Takibi

Öncü göstergeler doğası gereği öngörüye dayalıdır ve muhtemelen gerçekleşmek üzere olan bir soruna işaret eder; geri kalan göstergeler ise post-hoc'tur ve sorun iyice ilerledikten sonraki sonuçları temsil eder. Gecikmeli göstergelerin ("verilen siparişlerin sayısı düşüyor" gibi) yanı sıra veya bunların yerine öncü göstergelerden ("Oturum süresi"nin düşmeye başlaması gibi) faydalanabilirseniz, muhtemelen oldukça felaket.

"Harekete Geçilebilir" Uyarılar Açıkça Belirtilmelidir

Uyarılarınız, kovulduklarında atılacak sonraki adımların net olması için açık olmalıdır. Sorunun ciddiyetini tespit etmek, olayı gidermek veya sorunu düzeltmek için olsun, uyarıyla ilişkili yeterli ayrıntı bulunmalıdır. Uyarıyla ne yapacağınızı belirlemek için çok fazla ön tartışma gerektirmediğinden emin olmak istiyorsunuz.

Bu ayrıntıları uyarının içeriğine yapıştırabilir veya oldukça ayrıntılıysa ekibin bu tür sorunlar için tuttuğu runbook'lara bağlantı verebilirsiniz.

Net Çağrı Zincirleri ve Yükseltme Yolları Oluşturun

Hizmet sahipliği, saat dilimi farkındalığı vb. temel alınarak uyarının kime yönlendirileceği de dahil olmak üzere, bir uyarı tetiklendiğinde ne olacağına ilişkin net bir taslağa sahip olmak, hızlı yanıt verilmesi açısından kritik öneme sahiptir. İlk savunma hattının ötesinde, olaya müdahale eden kişinin olayı nasıl ve kime iletebileceği konusunda netliğin sağlanması da aynı derecede önemlidir.

Çoğu zaman, eğer konu karmaşıksa veya kapsam olarak tek bir kişinin baş edebileceğinden çok daha büyükse, daha fazla kıdemli kişinin (veya ekipteki birden fazla kişinin) yanı sıra işlevler arası paydaşların da sürece dahil edilmesi gerekebilir. Tüm bunları araçlarla (PagerDuty, OpsGenie gibi) veya çok net belgelerle (kitapları, wiki sayfalarını, repo README'leri çalıştırarak) kolayca erişilebilir hale getirmek, felaketle sonuçlanan bir olay ile hiçbir şey olmayan bir olay arasındaki fark olabilir.

Ön Hatları Büyük Kararlar Almaları İçin Güçlendirin

Açık yükseltme yollarına ihtiyacınız olsa da bunun varsayılan yanıt olmasını istemezsiniz. Üst düzey yönetime danışmaya gerek kalmadan, ilk müdahale ekiplerine kanamayı durdurmak için gerçek eylemde bulunabilmeleri veya iyileştirme için yerinde kararlar alabilmeleri konusunda yetki vermelisiniz. Bu, hem sonuçların sınırlandırılması açısından şirket açısından hem de büyük kararlar alma konusunda kendilerine güvenilen yüksek sorumluluk verilen çalışanlar için iyidir. Bürokrasiyi azaltın ve bireylerin eylemliliğini artırın.

Tüm Olaylar Eşit Yaratılmamıştır

Çağrı zincirleri ve yükseltme yolları gibi şeylerin yanı sıra, önemli olan diğer bir teminat da olay öncelik ölçeğidir. Bu genellikle ilk müdahaleyi yapan kişi veya olay komutanı için hızlı bir referanstır. Olayın ciddiyetinin ne olduğunu hızlı bir şekilde belirlemelerine ve farklı derecelerde yanıtlar gerektirebileceği için olayı bu şekilde etiketlemelerine yardımcı olur.

Kritik olaylar (sistem kesintileri veya finansal veri bozulması gibi) ile küçük sorunlar (renk paleti hataları gibi) arasında ayrım yapmak, müdahale ekiplerinin yanlış alarmlardan kaçınması açısından çok önemlidir. Ayrıca ekibin tepkisinin etkili ve odaklanmış kalmasını da sağlar.

Önce Çözün, Soruları Sonra Sorun

Hiç şüphesiz yapılması gereken en önemli şeylerden biri olayın mümkün olan en kısa sürede çözülmesidir. Olay devam ederken bir şeyin neden olduğunu veya nasıl önlenebileceğini düşünerek zaman harcamak istemezsiniz. Bunu otopsi için ayırabilirsiniz. Şimdilik acımasızca olayı çözmeye odaklanın ve zor soruları daha sonra sorun.

Bir Kişinin Sorumlu Olduğundan Emin Olun

Bazen olaylar çok büyüyebiliyor. Çok fazla hizmete dokunuyorlar, birden fazla iş alanına yayılıyorlar veya gelir veya itibar açısından gerçekten etkili oluyorlar. İşte o zaman olayın tamamında bir kişinin “trafik polisi” olarak görevlendirilmesi son derece önemlidir. Place Exchange'de, karmaşık olaylara müdahale konusunda eğitim almış küçük bir grup insandan oluşan "Olay Komutanları" oluşturduk.

Bu tür bir role sahip olmanın bu kadar önemli olmasının nedeni, birden fazla tarafın söz konusu olduğu durumlarda birinin trafiği yönlendirmesinin gerekmesidir. Mühendisler çoğu zaman sorunun karmaşıklığı konusunda tavşan deliklerine inmeye veya sorunun nasıl çözüleceğini anlamaya çalışmaya başlarlar.

Olay Komutanı'nın rolü, grubun olaya hızlı çözüm üretmeye odaklanmasını sağlamaktır. Herkesin eyleme geçme konusunda önyargılı olmasını sağlarlar ve yan araştırmalar önemli olsa da ileriye yönelik ivmenin sağlanması daha da önemlidir. Ayrıca hem iç hem de dış paydaşlar ve ortaklarla açık ve sürekli iletişimin sağlanmasından da sorumludurlar.

Olay komutanları genellikle Slack toplantısı veya Google Meet toplantısı gibi senkronize bir sesli iletişim hattı başlatır. Bu, olayın çözümünde kritik öneme sahip kişilerin sürekli iletişim halinde olmasını sağlar. Bu küçük şeyin, insanların sohbeti kullanarak sorunları eşzamansız olarak çözmelerine olanak sağlamasıyla karşılaştırıldığında ne kadar etkili olduğu şaşırtıcı.

Olay komutanları ayrıca yapılması gereken görevler için net bir yetki devrinin sağlanmasından ve bu görevler için yanıtların veya sonuçların geri alınması konusunda hesap verebilirliğin sağlanmasından da sorumludur.

Denildiği gibi 2 kişiden bir atı beslemelerini isterseniz at ölür. Olay amiri bunun olmasını engeller ve sonuçta olayın hızlı bir şekilde çözülmesinden sorumludur.

Açık ve Sık İletişim Kurun

Ekibin olayı çözmek için ne kadar sıkı çalıştığı konusunda bilgilendirildikleri takdirde insanlar genellikle en sevdikleri uygulama veya yazılımın devre dışı bırakılmasını affederler. Olayı tam olarak kontrol edemediğiniz için veya siz ve ekibiniz bundan utandığınız için işleri gizli tutmaya çalışmak, iletişimin dışarıya doğru akmasını engellemek için bir neden değildir.

İyi niyet oluşturmanıza yardımcı olacağından, iletişimin hem iç hem de dış ortaklarınız için kısa, sık ve şeffaf olduğundan emin olun.

Suçsuz Ölüm Sonrası Ölümler Çok Önemlidir

Otopsiler veya olay sonrası geriye dönük incelemeler, bir öğrenme kültürü oluşturmak için önemlidir ve bunların kesinlikle suçsuz olması gerekir. Kişiyi değil süreci eleştirin. Hiç kimse, buna sebep olmuş olabilecek kişi(ler)den daha sert olamaz ve onları toplum içinde kırbaçlamaktan hiçbir şey kazanamazsınız. Aksine, tüm araştırmalar bunu yaparak aslında kaybettiğinizi gösteriyor. Etsy'dekiler bunun hakkında konuşmakta çok daha iyiler, bu yüzden daha fazla bilgi edinmek istiyorsanız https://www.etsy.com/codeascraft/blameless-postmortems adresini okuyun.

Otopsi Takipleri Önemlidir

Ölüm sonrası işlemleri kendi başlarına yürütmek, farkındalık oluşturmak ve bu olaylardan ders çıkarmak için geri bildirim döngüleri oluşturmak açısından önemli olsa da, bunların gelecekte gerçekleşmesini önlemek için tartışılan eylem maddeleri belki daha önemlidir. Grup sistemde bir dizi boşluk veya güvenlik açığı tespit ederse, aynı sorunun tekrar yaşanmasını önlemek için bunların zamanında çözülmesine odaklanılması ve dikkat gösterilmesi son derece önemlidir.

Olayların meydana gelmesini önlemek zordur ve bu genellikle işletmeniz ve müşterilerinizle zorlu bir konuşmadır. Ancak aynı olay tekrar tekrar yaşanıyorsa, bu hem savunmayı daha da zorlaştırıyor, hem de takımın sağlığında ve becerisinde ciddi bir sorun olduğunu gösteriyor.

MTTD Düşük Olduğu Sürece Olaylar Kötü Değil

Herkes anlıyor. İş adamları bile bunu anlıyor. Yazılım oluşturmak ZORDUR ve tüm yazılımlarımızın 100'lerce, 1000'lerce bağımlılığa sahip olduğu, fay hatlarının çatlayabileceği bir dünyada tahmin etmek imkansızdır. Bok vantilatöre çarpacak ve sorun değil. Olayların yaşanmasını engelleyemeyiz. Ancak asıl yardımcı olan, olaylarınızın MTTD'sinin gerçekten düşük olduğundan emin olmaktır.

Ortalama Algılama Süresi (MTTD), bir kuruluşun bir olayı veya güvenlik tehdidini tanımlaması için geçen ortalama süreyi ölçen önemli bir performans göstergesidir (KPI). İş alanı, etkinin ciddiyeti vb. göz önüne alındığında genelleme yapmak zordur, ancak MTTD'nizi saniyelere, dakikalara indirebilirseniz, muhtemelen bir olayın etkisini söylemek yerine önemli ölçüde azaltabileceksiniz. saatlerden günlere (ne yazık ki tamamen mümkün olan haftaları veya ayları bırakın) oldu.

Mizah Sizi Anın Acısından Kurtarır

Bunların hepsi çok CİDDİ! Para kayboluyor! Korkunç bir deneyim yaşayan müşteriler! Ancak tüm bunların ortasında mizah anlayışına sahip olmanın önemli olduğunu gördüm. Bu süreçte herkesin insan olduğunu ve farklı derecelerde stres yaşadığını unutmamalıyız. Uygun noktalara mizah dozlarının enjekte edilmesi bu baskının bir kısmının hafifletilmesine yardımcı olur.

Takımın cehennemdeki bir adada değil de birlikteymiş gibi hissetmesini sağlayan bir dostluk duygusu yaratır.

Bu bir sarma. Okuduğunuz için teşekkürler!

⭐ Bu tür içerikleri seviyorsanız beni takip etmeyi veya https://a1engineering.substack.com/subscribe adresine abone olmayı unutmayın! ⭐

Unsplash'ta Julien L'nin öne çıkan fotoğrafı