Yazılım güncellemenizin bir sonraki CrowdStrike olmasını nasıl önleyebilirsiniz?

CrowdStrike Cuma günü nispeten küçük bir yama yayınladı ve bir şekilde Microsoft Windows çalıştıran BT dünyasının geniş bir alanına zarar vererek havalimanlarını, sağlık tesislerini ve 911 çağrı merkezlerini de çökertti. Soruna hatalı bir güncellemenin neden olduğunu bilsek de, ilk etapta nasıl yayınlandığını bilmiyoruz. CrowdStrike gibi bir şirketin, büyük olasılıkla yürürlükteki sürüm politikalarına sahip gelişmiş bir DevOps kanalı var, ancak buna rağmen hatalı kod bir şekilde gözden kaçmış.

Bu durumda belki de tüm hatalı kodların anasıydı. Şirketin itibarı büyük bir darbe aldı ve hisse senedi fiyatı Perşembe akşamı 345,10 Dolar’dan Pazartesi öğleden sonra 263,10 Dolar’a düştü. O zamandan bu yana biraz toparlandı.

Şirket Cuma günü yaptığı açıklamada hatalı güncellemenin sonuçlarını kabul etti: “CrowdStrike’ın tamamı durumun ciddiyetini ve etkisini anlıyor. Sorunu hızlı bir şekilde belirledik ve bir düzeltme uyguladık; bu, en büyük önceliğimiz olan müşteri sistemlerini geri yüklemeye özenle odaklanmamıza olanak sağladı.”

Ayrıca, nasıl olduğu açıklanmasa da kesintinin temel nedeni açıklandı. Bu, böyle bir şeyin tekrar yaşanmasını engellemek amacıyla şirket içinde muhtemelen bir süre daha devam edecek bir otopsi süreci.

Yazılımı son derece kontrollü bir şekilde dağıtmak için özellik bayrakları adı verilen bir kavramı kullanan bir firma olan LaunchDarkly’nin CEO’su Dan Rogers, CrowdStrike dağıtım sorunuyla doğrudan konuşamadı ancak yazılım dağıtım sorunları hakkında daha geniş bir şekilde konuşabilirdi.

TechCrunch’a “Yazılım hataları oluyor, ancak birinin karşılaşacağı yazılım deneyimi sorunlarının çoğu aslında altyapı sorunlarından kaynaklanmıyor” dedi. “Bunların nedeni, birisinin çalışmayan bir yazılımı piyasaya sürmesi ve bunların genel olarak oldukça kontrol edilebilir olması.” Özellik bayraklarıyla, yeni özelliklerin dağıtım hızını kontrol edebilir ve işler ters giderse sorunun geniş çapta yayılmasını önlemek için bir özelliği kapatabilirsiniz.

Bununla birlikte, bu durumda sorunun işletim sistemi çekirdeği seviyesinde olduğunu ve bir kez kontrolden çıktıktan sonra düzeltmenin bir web uygulamasını düzeltmekten daha zor olduğunu unutmamak önemlidir. Yine de daha yavaş bir dağıtım, şirketi sorun konusunda çok daha erken uyarabilirdi.

DevOps geliştirme araçları üreticisi Harness Labs’ın kurucusu ve CEO’su Jyoti Bansal, CrowdStrike’da yaşananların herhangi bir yazılım şirketinin, hatta iyi yazılım yayınlama uygulamalarına sahip olsa bile, potansiyel olarak başına gelebileceğini söyledi. CrowdStrike’da tam olarak ne olduğunu söyleyemese de genel olarak hatalı kodun nasıl gözden kaçabileceğinden bahsetti.

Tipik olarak, kodun dağıtılmadan önce kapsamlı bir şekilde test edildiği bir süreç vardır, ancak bazen bir mühendislik ekibi, özellikle de büyük bir mühendislik grubundaki, işin kolayına kaçabilir. Bansal, TechCrunch’a “Küçük güncellemelerde oldukça yaygın olan DevOps test hattını atladığınızda buna benzer bir şeyin gerçekleşmesi mümkündür” dedi.

Bunun genellikle yazılım sürümlerine yönelik tek bir yaklaşımın bulunmadığı büyük kuruluşlarda meydana geldiğini söylüyor. “Diyelim ki 5.000 mühendisiniz var ve bunlar muhtemelen 50 kadar farklı geliştiriciden oluşan 100 ekibe bölünecek. Bu takımlarda farklı uygulamalar yapılıyor” dedi. Ve standardizasyon olmadan kötü kodun gözden kaçması daha kolaydır.

Hataların gözden kaçması nasıl önlenir

Her iki CEO da hataların bazen çözüldüğünü kabul ediyor, ancak riski en aza indirmenin yolları var; bunlar arasında belki de en bariz olanı: standart yazılım sürümü hijyenini uygulamak. Bu, konuşlandırmadan önce test etmeyi ve ardından kontrollü bir şekilde konuşlandırmayı içerir.

Rogers, şirketinin yazılımına dikkat çekiyor ve başlangıç ​​noktasının aşamalı dağıtımlar olduğunu belirtiyor. Değişikliği her kullanıcıya aynı anda iletmek yerine, bunu küçük bir alt kümeye yayınlarsınız ve kullanıma sunma kapsamını genişletmeden önce ne olacağını görürsünüz. Aynı doğrultuda, kontrollü dağıtımlarınız varsa ve bir şeyler ters giderse geri alabilirsiniz. “Bu özellik yönetimi veya özellik kontrolü fikri, çalışmayan özellikleri geri almanıza ve işler yolunda gitmediğinde insanları önceki sürüme geri döndürmenize olanak tanır.”

Şirketi Mayıs ayında özellik bayrağı girişimi Split.io’yu satın alan Bansal, aynı zamanda küçük kontrollü test dağıtımları olan “kanarya dağıtımları” adını verdiği şeyi de öneriyor. Karbon monoksit sızıntısını test etmek için kömür madenlerine gönderilen kanaryaları anımsattıkları için bunlara bu ad verilmiştir. Test dağıtımının iyi göründüğünü kanıtladıktan sonra Rogers’ın bahsettiği aşamalı dağıtıma geçebilirsiniz.

Bansal’ın söylediği gibi, testlerde iyi görünebilir, ancak laboratuvar testi her zaman her şeyi yakalamaz ve bu nedenle laboratuvar testlerinin kaçırdığı şeyleri yakalamak için iyi DevOps testini kontrollü dağıtımla birleştirmeniz gerekir.

Rogers, yazılım test rejiminizin analizini yaparken üç temel alana (platform, insanlar ve süreçler) bakmanızı ve onun görüşüne göre bunların hepsinin birlikte çalışmasını öneriyor. “Sadece harika bir yazılım platformuna sahip olmak yeterli değil. Yüksek düzeyde etkin geliştiricilere sahip olmak yeterli değildir. Ayrıca yalnızca önceden tanımlanmış iş akışlarına ve yönetime sahip olmak da yeterli değildir. Bunların üçünün bir araya gelmesi gerekiyor” dedi.

Tek tek mühendislerin veya ekiplerin boru hattını atlatmasını engellemenin bir yolu, herkes için aynı yaklaşımın uygulanmasını ancak ekipleri yavaşlatmayacak şekilde zorunlu kılmaktır. “Geliştiricileri yavaşlatan bir boru hattı oluşturursanız, bir noktada işlerini bunun dışında yapmanın yollarını bulacaklar çünkü kodu göndermeden önce sürecin iki hafta veya bir ay daha ekleneceğini düşünecekler. Biz yazdık” dedi Bansal.

Rogers, tek bir kötü olaya tepki olarak katı sistemleri uygulamaya koymamanın önemli olduğunu kabul ediyor. “Şu anda olmasını istemediğiniz şey, yazılım değişiklikleri yapma konusunda o kadar endişelenmeniz ki, çok uzun ve uzayan bir test döngüsüne sahip olmanız ve sonuçta yazılım inovasyonunu engellemenizdir” dedi.

Bansal, düşünceli bir otomatik yaklaşımın özellikle daha büyük mühendislik gruplarında gerçekten yararlı olabileceğini söylüyor. Ancak güvenlik ve yönetişim ile serbest bırakma hızı ihtiyacı arasında her zaman bir miktar gerilim olacaktır ve doğru dengeyi bulmak zordur.

CrowdStrike’da ne olduğunu bir süredir bilmiyor olabiliriz ancak bazı yaklaşımların yazılım dağıtımıyla ilgili riskleri en aza indirmeye yardımcı olduğunu biliyoruz. Kötü kod zaman zaman ortaya çıkacaktır, ancak en iyi uygulamaları takip ederseniz muhtemelen geçen hafta yaşananlar kadar felaket olmayacaktır.