İnsan Faktörü: Şirketlerin Bulut Felaketlerini Önlemesi

Günlük ve haftalık bültenlerimize katılın, en güncel güncellemelerden ve sektör lideri yapay zeka haberlerinden özel içeriklere erişin. Daha Fazla Bilgi


Büyük şirketler, hizmetlerinin çökmemesi için çok çalışırlar ve nedeni basittir – ciddi arızalar markanıza zarar verir ve müşterileri daha iyi bir geçmişe sahip rakip ürünlere yönlendirir.

Güvenilir bir internet hizmeti oluşturmak teknik olarak zor bir problemdir, ancak şirket liderleri için aynı zamanda insanlarla ilgili bir sorundur. Mühendislik ekiplerini güvenilirlik çalışmalarına teşvik etmek zor olabilir, çünkü sık ​​sık yeni özellik geliştirmek kadar heyecan verici olmadığı düşünülür.

Ölçekte, teşvikler egemen olur. En büyük teknoloji şirketleri binlerce çalışanı istihdam eder ve yüzlerce internet hizmeti işletir. Yıllar içinde en başarılı teknoloji şirketlerinde ölçekte çalışmış olan insan mühendislik teknikleri hakkında konuşacağız. Bu teknikleri işveren ya da lider olarak şirketinize uygulayabilirsiniz.

Çarkı Çevir

AWS operasyonel gözden geçirmesi, şirket genelinde herkese açık bir haftalık toplantıdır. Her toplantıda, yüzlerce AWS hizmeti arasından rastgele seçilen bir “şansa çarkı çevrilir. İncelemeye alınan ekip, deneyimli operasyon liderlerinden dashboards ve metriklerle ilgili keskin soruları yanıtlamak zorundadır. Toplantıya yüzlerce çalışan, onlarca yönetici ve birkaç başkan katılır.

Bu her ekibin temel seviyede operasyonel yeterliliğe sahip olmasını teşvik eder. Tek başına bir ekibin seçilme olasılığı düşük olsa da (AWS’de %1’den az), ekibin yöneticisi veya teknik lideri olarak, şansınızın döndüğü gün şirketin yarısının önünde cahil görünmek istemezsiniz.

İtinalı bir şekilde güvenilirlik metriklerinizi düzenli olarak gözden geçirmek önemlidir. Operasyonel sağlık konusunda aktif ilgi gösteren liderler, tüm organizasyon için o tonu belirler. Çarkı çevir sadece bunu başarmanın bir yoludur.

Ölçülebilir Güvenilirlik Hedefleri Belirleyin

‘Yüksek işlem süresi’ ya da ‘beş dokuz’ sahip olmak istersiniz, ama bu gerçekten müşterileriniz için ne anlama geliyor? Canlı etkileşimlerin (sohbet) gecikme toleransı, asenkron iş yüklerinden (makine öğrenme modeli eğitme, video yükleme) çok daha düşüktür. Hedefleriniz, müşterilerinizin önemsediği şeyleri yansıtmalıdır.

Bir ekibin metriklerini incelediğinizde, onlardan ölçülebilir güvenilirlik hedeflerini tanımlamalarını isteyin. Bu hedeflerin neden seçildiğini hem sizin hem de onların anlamalarını sağlayın. Sonra, bu hedeflerin karşılandığını kanıtlamak için tabloları kullanmalarını isteyin. Ölçülebilir hedeflere sahip olmak, güvenilirlik çalışmalarını veri odaklı bir şekilde önceliklendirmenize yardımcı olacaktır.

Sorunların tespitine odaklanmak iyi bir fikirdir. Tablolarında bir anormallik görürseniz, sorunu açıklamalarını isteyin, ancak aynı zamanda nöbetçilerinin bu sorundan haberdar edilip edilmediğini de sorun. İdeal olarak, müşterilerinizden önce bir sorun olduğunu fark etmelisiniz.

Kaosa Sarılın

Bulut dayanıklılığındaki en devrimci düşünce kaynaklarından biri, hata enjekte etme konseptidir. Netflix, bu konsepti “kaos mühendisliği” olarak formalize etti ve fikir isminin çağrıştırdığı kadar ilginç.

Netflix, mühendislerinin mikro yönetimine başvurmadan hataya dayanıklı sistemler inşa etmelerini teşvik etmek istedi. Sistemik başarısızlık istisna değil, kural haline getirilirse, mühendislerin hataya dayanıklı sistemler inşa etmekten başka çaresi kalmaz. Netflix, bireysel sunuculardan tüm kullanılabilirlik bölgelerine kadar her şeyin üretimde düzenli olarak çöktürüldüğü bir modele ulaşmayı hedefledi. Her hizmetin, hizmetin kullanılabilirliğine hiçbir etkisi olmadan bu tür başarısızlıkları otomatik olarak absorbe etmesi beklenmektedir.

Bu strateji pahalı ve karmaşıktır. Ancak yüksek işlem süresinin mutlak bir gereklilik olduğu bir ürün gönderiyorsanız, üretimde hata enjeksiyonu çok etkili bir doğruluk kanıtı elde etmenin yollarından biridir. Ürününüzün buna ihtiyacı varsa, bunu mümkün olan en kısa sürede tanıtın. Bugün olduğundan daha kolay veya ucuz olmayacak.

Kaos mühendisliği gereğinden fazla görünüyorsa, en azından ekiplerinizin “oyun günleri” (simüle arıza uygulaması çalışmaları) yapmasını gerektirmelisiniz, yılda bir veya iki kez veya büyük bir özellik başlatmadan önce. Bir oyun günü sırasında üç belirlenmiş rolünüz olacak – ilk rol arızayı simüle edecek, ikinci rol öncesinde neyin bozulduğunu bilmeksizin bunu düzeltecek ve üçüncü rol gözlemci olacak ve detaylı notlar alacak. Daha sonra, tüm ekip bir araya gelmeli ve simüle edilen hadise üzerine bir değerlendirme yapmalı (aşağıya bakınız). Oyun günü, sistemlerinizin arızalarla nasıl başa çıktığını değil, aynı zamanda mühendislerinizin bunlarla nasıl başa çıktığını ortaya çıkaracaktır.

Katı Bir Cover Mortem Süreciniz Olmalı

Bir firmanın post-mortem süreci, kültürü hakkında çok şey açıklar. En üst düzey teknoloji şirketlerinden her birinin, önemli arızalar için ekiplerin post-mortem’lar yazmasını gerektirir. Rapor, olayı açıklamalı, kök nedenlerini araştırmalı ve önleyici önlemleri belirlemelidir. Post-mortem katı bir standarda ve yüksek bir standarda uygun olmalı, ancak süreç asla suçlayıcı olduğu kişileri hedef almamalıdır. Post-mortem yazma düzeltici bir egzersizdir, cezalandırmaya yönelik değil. Bir mühendis bir hata yapmışsa, o hatayı yapmasına izin veren temel sorunlar var demektir. Belki daha iyi testlerinize veya kritik sistemlerinizin etrafındaki daha iyi korumalara ihtiyacınız vardır. Bu sistemik boşlukları ayrıntılı olarak işleyin ve düzeltin.

Güçlü bir post-mortem süreci tasarlama konusu başlı başına bir makale konusu olabilir, ancak bir tane bulundurmanızın bir sonraki arızayı önlemenize büyük ölçüde yardımcı olacağına güvenebilirsiniz.

Güvenilirlik Çalışmasını Ödüllendirin

Mühendislerin sadece yeni özelliklerin terfi ve zamana yol açtığı algısı varsa, güvenilirlik çalışması geri planda kalacaktır. Çoğu mühendis, kıdemli veya kıdemli olmalarına bakılmaksızın operasyonel mükemmelliğe katkıda bulunmalıdır. Performans değerlendirmelerinizde güvenilirlik iyileştirmelerini ödüllendirin. En kıdemli mühendislerinizi gözetlediği sistemlerin kararlılığından sorumlu tutun.

Bu tavsiye açık görünse de, şaşırtıcı derecede kolay gözden kaçırılabilecektir.

Sonuç

Bu makalede, güvenilirliği şirket kültürünüze yerleştiren bazı temel araçları inceledik. Başlangıç şirketleri ve erken aşamadaki şirketler genellikle güvenilirliği bir öncelik haline getirmezler. Bu anlaşılabilir – yeni bir müşteri tabanı oluşturmak için şirketinizin hayatta kalmasını sağlamak için ürün-pazar uyumunu kanıtlamaya odaklanmanız gerekmektedir. Ancak, bir kez geri dönen bir müşteri tabanınız olduğunda, şirketinizin geleceği güveni korumaya bağlıdır. İnsanlar güvenirlikleri ile güven kazanırlar. Aynısı internet hizmetleri için de geçerlidir.

Aditya Visweswaran, Google Cloud’un güvenlik platform ekibinde kıdemli yazılım mühendisidir.

DataDecisionMakers

Yeni yolcuları, DataDecisionMakers’a hoş geldiniz!

DataDecisionMakers, veri çalışmalarını yürüten teknik uzmanlar da dahil olmak üzere, veri ile ilgili içgörüleri ve yenilikleri paylaşabileceğiniz bir platformdur.

Eğilimleri, güncel bilgileri, en iyi uygulamaları ve veri ve veri teknolojisinin geleceğini okumak istiyorsanız, bize DataDecisionMakers’da katılın.

Kendi makalenizi yazmayı bile düşünebilirsiniz!

DataDecisionMakers’dan Daha Fazla Okuma

Exit mobile version