CrowdStrike Cuma günü nispeten küçük bir yama yayınladı ve bir şekilde Microsoft Windows çalıştıran BT dünyasının büyük kesimlerinde tahribata yol açtı, havaalanlarını, sağlık tesislerini ve 911 çağrı merkezlerini de beraberinde çökertti. Hatalı bir güncellemenin soruna neden olduğunu bilsek de, ilk etapta nasıl yayınlandığını bilmiyoruz. CrowdStrike gibi bir şirketin büyük ihtimalle yayın politikalarının yürürlükte olduğu karmaşık bir DevOps hattı vardır, ancak buna rağmen hatalı kod bir şekilde sıyrılıp geçti.
Bu durumda belki de tüm hatalı kodların anasıydı. Şirket itibarında sert bir darbe aldı ve hisse senedi fiyatı Perşembe akşamı 345,10 dolardan Pazartesi öğleden sonra 263,10 dolara düştü. O zamandan beri biraz toparlandı.
İçinde Bir deyim Cuma günü şirket hatalı güncellemenin sonuçlarını kabul etti: “CrowdStrike’ın tamamı durumun ciddiyetini ve etkisini anlıyor. Sorunu hızla tespit ettik ve bir düzeltme uyguladık, bu da en yüksek önceliğimiz olan müşteri sistemlerini geri yüklemeye odaklanmamızı sağladı.”
Ayrıca, kesintinin temel nedenini açıkladı, ancak nasıl gerçekleştiğini açıklamadı. Bu, böyle bir şeyin tekrar olmasını önlemek için şirket içinde muhtemelen bir süre devam edecek bir ölüm sonrası sürecidir.
Yazılımları 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 sorununa doğrudan değinemedi, ancak yazılım dağıtım sorunları hakkında daha geniş bir şekilde konuşabildi.
TechCrunch’a verdiği demeçte, “Yazılım hataları olur, ancak birinin deneyimleyeceği yazılım deneyimi sorunlarının çoğu aslında altyapı sorunlarından kaynaklanmaz,” dedi. “Bunlar, birinin çalışmayan bir yazılım parçası çıkarmasından kaynaklanır ve bunlar genel olarak çok kontrol edilebilirdir.” Özellik bayraklarıyla, yeni özelliklerin dağıtım hızını kontrol edebilir ve bir sorun giderse sorunun yaygın şekilde yayılmasını önlemek için özelliği kapatabilirsiniz.
Ancak, bu durumda sorunun işletim sistemi çekirdeği seviyesinde olduğunu ve bir kez kontrolden çıktığında, örneğin bir web uygulamasından daha zor düzeltildiğini belirtmek önemlidir. Yine de, daha yavaş bir dağıtım, şirketi soruna çok daha erken uyarabilirdi.
DevOps boru hattı geliştirici araçları üreticisi Harness Labs’ın kurucusu ve CEO’su Jyoti Bansal, CrowdStrike’ta yaşananların, iyi yazılım yayınlama uygulamalarına sahip olan herhangi bir yazılım şirketinin başına gelebileceğini söyledi. CrowdStrike’ta tam olarak ne olduğunu söyleyemese de, hatalı kodun çatlaklardan nasıl sızabileceğinden genel olarak bahsetti.
Genellikle, dağıtılmadan önce kodun kapsamlı bir şekilde test edildiği bir süreç vardır, ancak bazen bir mühendislik ekibi, özellikle büyük bir mühendislik grubunda, köşe kesebilir. Bansal, TechCrunch’a “Küçük güncellemelerde oldukça yaygın olan DevOps test hattını atladığınızda bunun gibi bir şeyin olması mümkündür,” dedi.
Bunun genellikle yazılım sürümlerine yönelik tek bir yaklaşımın olmadığı daha büyük organizasyonlarda gerçekleştiğini söylüyor. “Diyelim ki 5.000 mühendisiniz var ve bunlar muhtemelen 50 veya daha fazla farklı geliştiriciden oluşan 100 takıma bölünecektir. Bu takımlar farklı uygulamaları benimsiyor,” diyor. Ve standardizasyon olmadan, kötü kodun çatlaklardan sızması daha kolaydır.
Böceklerin içeri sızması nasıl önlenir
Her iki CEO da hataların bazen geçebildiğini kabul ediyor, ancak riski en aza indirmenin yolları var, bunlardan biri de belki de en bariz olanı: standart yazılım sürümü hijyenini uygulamak. Bu, dağıtımdan önce test etmeyi ve ardından kontrollü bir şekilde dağıtım yapmayı içerir.
Rogers şirketinin yazılımına işaret ediyor ve kademeli dağıtımların başlamak için doğru yer olduğunu belirtiyor. Değişikliği her kullanıcıya aynı anda sunmak yerine, küçük bir alt kümeye yayınlıyor ve dağıtımı genişletmeden önce ne olacağını görüyorsunuz. Aynı şekilde, 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 gitmezse 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, ayrıca “kanarya dağıtımları” olarak adlandırdığı, küçük kontrollü test dağıtımlarını öneriyor. Bunlara bu ad verilmesinin sebebi, karbon monoksit sızıntısını test etmek için kömür madenlerine gönderilen kanaryalara gönderme yapmasıdır. Test dağıtımının iyi göründüğünü kanıtladıktan sonra, Rogers’ın değindiği kademeli dağıtıma geçebilirsiniz.
Bansal’ın da dediği gibi, testlerde iyi görünebilir, ancak bir laboratuvar testi her zaman her şeyi yakalayamaz ve bu nedenle laboratuvar testlerinin kaçırdığı şeyleri yakalamak için iyi DevOps testini kontrollü dağıtımla birleştirmelisiniz.
Rogers, yazılım test rejiminizin bir analizini yaparken üç temel alana bakmanızı öneriyor: platform, insanlar ve süreçler ve bunların hepsi onun görüşüne göre birlikte çalışıyor. “Sadece harika bir yazılım platformuna sahip olmak yeterli değil. Son derece yetenekli geliştiricilere sahip olmak yeterli değil. Ayrıca sadece önceden tanımlanmış iş akışlarına ve yönetişime sahip olmak da yeterli değil. Bu üçünün de bir araya gelmesi gerekiyor” dedi.
Bireysel mühendislerin veya ekiplerin boru hattını atlatmasını engellemenin bir yolu, herkes için aynı yaklaşımı talep etmektir, ancak ekipleri yavaşlatmayacak şekilde. Bansal, “Geliştiricileri yavaşlatan bir boru hattı inşa ederseniz, bir noktada işlerini bunun dışında yapmanın yollarını bulacaklardır çünkü sürecin yazdığımız kodu göndermemizden önce iki hafta veya bir ay daha ekleyeceğini düşüneceklerdir” dedi.
Rogers, tek bir kötü olaya yanıt olarak katı sistemler kurmamanın önemli olduğunu kabul ediyor. “Şu anda olmasını istemediğiniz şey, yazılım değişiklikleri yapma konusunda o kadar endişeli olmanız ki, çok uzun ve uzamış bir test döngüsüne sahip olmanız ve yazılım inovasyonunu engellemenizdir,” dedi.
Bansal, düşünceli bir otomatik yaklaşımın, özellikle daha büyük mühendislik gruplarıyla birlikte, aslında yardımcı olabileceğini söylüyor. Ancak güvenlik ve yönetişim ile yayın hızına duyulan ihtiyaç arasında her zaman bir miktar gerilim olacaktır ve doğru dengeyi bulmak zordur.
CrowdStrike’ta ne olduğunu bir süre bilmiyor olabiliriz, ancak belirli yaklaşımların yazılım dağıtımıyla ilgili riskleri en aza indirmeye yardımcı olduğunu biliyoruz. Zaman zaman kötü kodlar ortaya çıkacaktır, ancak en iyi uygulamaları takip ederseniz, muhtemelen geçen hafta olan kadar felaket olmayacaktır.