İnsan faktörü: Şirketler bulut felaketlerini nasıl önleyebilir?

Büyük şirketler hizmetlerinin kesintiye uğramamasını sağlamak için çok çalışırlar ve bunun nedeni de basittir; önemli kesintiler markanıza zarar verir ve müşterileri daha iyi performansa sahip rakip ürünlere yönlendirir.

Güvenilir bir web hizmeti oluşturmak zorlu bir teknik sorundur ancak şirket liderleri için aynı zamanda insani bir zorluk da teşkil etmektedir. Mühendislik ekiplerinizi güvenilirlik çalışmalarına yatırım yapmaya motive etmek zor olabilir çünkü bu genellikle yeni özellikler geliştirmekten daha az heyecan verici olarak algılanır.

Büyük ölçekte teşvikler hakimdir. En iyi teknoloji şirketleri binlerce çalışanı istihdam ediyor ve yüzlerce web hizmetini işletiyor. Yıllar geçtikçe mühendislerinin güvenilir sistemler oluşturmasını sağlayacak akıllı yollar buldular. Bu makale, tarihteki en başarılı teknoloji şirketlerinde geniş ölçekte işe yarayan insan mühendisliği tekniklerini tartışıyor. İster çalışan olun, ister lider olun, bunları şirketinize uygulayabilirsiniz.

Tekerleği döndür

AWS operasyonel incelemesi tüm şirketin katılımına açık haftalık bir toplantıdır. Her toplantıda bir “şans çarkı”, canlı inceleme için yüzlerce AWS hizmeti arasından rastgele bir AWS hizmeti seçmek üzere döndürülür. İncelenen ekibin, deneyimli operasyonel liderlerin gösterge tabloları ve ölçümleri hakkındaki keskin sorularına yanıt vermesi gerekiyor. Toplantıya yüzlerce çalışan, onlarca yönetici ve çok sayıda Başkan Yardımcısı katılıyor.

Bu, her ekibin temel düzeyde operasyonel yeterliliğe sahip olmasını teşvik eder. Bireysel bir ekibin seçilme olasılığı düşük olsa bile (AWS’de %1’den az), ekipteki bir yönetici veya teknoloji lideri olarak, işe başlayacağınız gün şirketin yarısının önünde bilgisiz görünmek istemezsiniz. şans biter.

Güvenilirlik ölçümlerinizi düzenli olarak gözden geçirmeniz önemlidir. Operasyonel sağlıkla aktif olarak ilgilenen liderler, tüm organizasyon için bu tavrı belirler. Tekerleği döndürmek bunu başarmak için yalnızca bir araçtır.

Peki bu operasyonel incelemelerde ne yapıyorsunuz? Bu bizi bir sonraki noktaya getiriyor.

Ölçülebilir güvenilirlik hedeflerini tanımlayın

‘Yüksek çalışma süresine’ veya ‘beş dokuzluya’ sahip olmak istiyorsunuz, ancak bu müşterileriniz için gerçekten ne anlama geliyor? Canlı etkileşimlerin (sohbet) gecikme toleransı, eşzamansız iş yüklerinden (makine öğrenimi modeli eğitimi, 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 açıklamalarını isteyin. Bu hedeflerin neden seçildiğini anladığınızdan ve onların da anladığından emin olun. Daha sonra bu hedeflere ulaşıldığını kanıtlamak için gösterge tablolarını kullanmalarını sağlayın. Ölçülebilir hedeflere sahip olmak, güvenilirlik çalışmalarına veri odaklı bir şekilde öncelik vermenize yardımcı olacaktır.

Sorunların tespitine odaklanmak iyi bir fikirdir. Kontrol panellerinde bir anormallik görürseniz, onlardan sorunu açıklamalarını isteyin, ancak aynı zamanda onlara sorunla ilgili olarak kendilerine bilgi verilip verilmediğini de sorun. İdeal olarak, bir şeylerin ters gittiğini müşterileriniz fark etmeden önce siz fark etmelisiniz.

Kaosu kucaklayın

Bulut esnekliğindeki en devrim niteliğindeki zihniyet değişimlerinden biri, başarısızlığın üretime enjekte edilmesi kavramıdır. Netflix bu kavramı şu şekilde resmileştirdi: “kaos mühendisliği”- ve fikir, adından da anlaşılacağı gibi harika.

Netflix, mühendislerini mikro yönetime başvurmadan hataya dayanıklı sistemler oluşturmaya teşvik etmek istiyordu. Eğer sistemik arıza istisna yerine norm haline getirilirse, mühendislerin hataya dayanıklı sistemler oluşturmaktan başka seçeneği kalmayacağını düşündüler. Oraya ulaşmak zaman aldı ancak Netflix’te bireysel sunuculardan tüm kullanılabilirlik bölgelerine kadar her şey üretim sırasında rutin olarak devre dışı bırakılır. Her hizmetin, hizmet kullanılabilirliğini etkilemeden bu tür arızaları otomatik olarak gidermesi beklenir.

Bu strateji pahalı ve karmaşıktır. Ancak, yüksek çalışma süresinin mutlak bir gereklilik olduğu bir ürünü gönderiyorsanız, üretimde arıza enjeksiyonu, ‘doğruluk kanıtına’ benzer bir şey elde etmenin çok etkili bir yoludur. Ürününüzün buna ihtiyacı varsa mümkün olduğu kadar erken tanıtın. Hiçbir zaman bugün olduğundan daha kolay ve daha ucuz olmayacak.

Kaos mühendisliği abartılı görünüyorsa, en azından ekiplerinizin yılda bir veya iki kez ‘oyun günleri’ (simüle edilmiş kesinti uygulama çalışmaları) yapmasını veya herhangi bir önemli özelliğin lansmanına öncülük etmesini talep etmelisiniz. Bir oyun günü boyunca belirlenmiş üç rolünüz olacak; ilk rol kesintiyi simüle eder, ikincisi neyin bozulduğunu önceden bilmeden sorunu giderir ve üçüncüsü gözlemleyip ayrıntılı notlar alır. Daha sonra tüm ekip bir araya gelmeli ve simüle edilen olayla ilgili otopsi yapmalıdır (aşağıya bakınız). Maç günü, yalnızca sistemlerinizin kesintilerle nasıl başa çıktığı konusundaki boşlukları değil, aynı zamanda mühendislerinizin bunları nasıl ele aldığı konusundaki boşlukları da ortaya çıkaracaktır.

Titiz bir otopsi sürecine sahip olun

Bir şirketin otopsi süreci, o şirketin kültürü hakkında pek çok şeyi ortaya çıkarır. En iyi teknoloji şirketlerinin her biri, ekiplerin önemli kesintiler için otopsi yazmasını şart koşuyor. Rapor olayı tanımlamalı, temel nedenlerini araştırmalı ve önleyici eylemleri belirlemelidir. Otopsi titiz olmalı ve yüksek standartta tutulmalıdır, ancak süreç hiçbir zaman suçlanacak kişileri seçmemelidir. Ölüm sonrası yazı yazmak cezalandırıcı değil, düzeltici bir egzersizdir. Bir mühendis hata yaptıysa, bu hatanın oluşmasına neden olan temel sorunlar vardır. Belki de daha iyi testlere veya kritik sistemlerinizin etrafında daha iyi korkuluklara ihtiyacınız var. Bu sistemik boşlukları derinlemesine inceleyin ve düzeltin.

Sağlam bir otopsi süreci tasarlamak kendi makalesinin konusu olabilir, ancak buna sahip olmanın bir sonraki kesintiyi önlemede uzun bir yol kat edeceğini söylemek yanlış olmaz.

Ödül güvenilirliği çalışması

Mühendisler yalnızca yeni özelliklerin maaş artışlarına ve terfilere yol açacağına dair bir algıya sahipse, güvenilirlik çalışması arka planda kalacaktır. Çoğu mühendis, kıdemlerine bakılmaksızın operasyonel mükemmelliğe katkıda bulunmalıdır. Performans incelemelerinizde güvenilirlik iyileştirmelerini ödüllendirin. En kıdemli mühendislerinizi denetledikleri sistemlerin istikrarından sorumlu tutun.

Bu öneri bariz görünse de, gözden kaçırılması şaşırtıcı derecede kolaydır.

Çözüm

Bu makalede, güvenilirliği şirket kültürünüze dahil eden bazı temel araçları araştırdık. Startup’lar ve erken aşamadaki şirketler genellikle güvenilirliği bir öncelik haline getirmezler. Bu anlaşılabilir bir durumdur; yeni başlayan şirketiniz hayatta kalmayı garantilemek için saplantılı bir şekilde ürün pazarına uygunluğunu kanıtlamaya odaklanmış olmalıdır. Ancak, geri dönen bir müşteri tabanınız olduğunda şirketinizin geleceği güvenin korunmasına bağlıdır. İnsanlar güvenilir olmakla güven kazanırlar. Aynı durum web hizmetleri için de geçerlidir.

Aditya Visweswaran, kıdemli bir yazılım mühendisidir. Google Cloud’un güvenlik platformu ekibi.