AWS Türkçe Blog

AWS Cloud ile BT Dayanıklılığı, Bölüm I: Düşünce Yapısı ve Kültür

Orijinal makale: Link (Randy DeFauw, Amine Chigani ve Nigel Harris)

Müşterilerin pek çoğu buluta geçiş planlarını yaparken şirket içi veri merkezlerinde uyguladıkları iş sürekliliği ve operasyonel planlarını buluta uyarlamakta zorlanıyor. Bu da kritik iş uygulamalarının dayanıklılığını etkiliyor ve buluta geçiş adaptasyonunu geciktirebiliyor. Bu iki bölümlü blog serisini, Bilgi Teknolojileri’nde (BT) dayanıklılık stratejilerinin uygulanmasına rehberlik etmesini sağlamak üzere hazırladık. Bölüm I’de, yönetici geliştiriciler (executive builders) tarafından sıkça karşılaşılan zorlukları gözden geçireceğiz. Ayrıca buluttaki dayanıklılık tanımını, zihniyet ve organizasyon kültürünü uyarlamak için gereken önemli hususları da inceleyeceğiz. Bölüm II’de ise mimari ve şablonlarla (patterns) ilgili teknik konulara değineceğiz.

Müşterilerin yaşadığı zorluklar

Veri merkezi taşıma stratejisi ile ilgili bir tartışmada küresel bir finansal hizmetler şirketinde çalışan üst düzey bir BT yöneticisi, “Bugün veri merkezini AWS’e taşıma fikri için bir iş durumu düşünme konusunda daha olgun olduğumuzu hissediyorum. Ama asıl endişem, finansal mevzuatlara uyumluluk gereksinimlerimizi karşılarken bu hibrit ortamda dayanıklılığımızı sağladığımızdan nasıl emin olacağım konusunda.” diye anlatıyor. Fakat konu ilerleyip ek soruları sorulduktan sonra, asıl endişelerinin iki-lokasyonlu, veri merkezi felaket kurtarma (DR) yapısını bulutta nasıl uygulayacakları ile ilgili olduğu ortaya çıkıyor.

Geçtiğimiz 12 ay içinde iş liderlerinin, dayanıklılık konusunu doğrudan veya dolaylı olarak birinci sırada endişe duydukları alan olarak tanımladığını giderek daha fazla gözlemledik. Bu endişeler son dönemde çoğunlukla COVID-19 salgını nedeniyle iş sürekliliği hakkındaki tartışmalarda ortaya çıktı. Bununla birlikte bu konu herkesin duyduğu güvenlik açığı veya kesinti olaylarıyla ilgili endişelerle de çoğu zaman desteklenir. Diğer zamanlarda ise bulut teknolojisi durum tespiti (due diligence) ile ilgili tartışmalar sırasında ifade edilir. Bu şirketlerdeki yönetici geliştiriciler için, yönetmeliklerle belirlenmiş bir BT “uyum dengesi” ne ulaşmak yıllar almıştır. Eski iş yüklerini buluta geçirirken aynı anda dijital dönüşüm çabalarını dönüştürmek, operasyonel olarak zorlayıcı bir işlemdir. Bu zorluk, uyumluluk dengesini bozabilir ve bu da bulutun benimsenmesini geciktirebilir.

Başlamak için dikkat edilmesi gereken hususlar

Bulut adaptasyonu genellikle müşterinin işindeki büyük ölçekli dijital dönüşümlerin merkezidir. Ama dönüşümler bazen bozucu etkiler gösterebilir ve bu bozulmalar sinir bozucu olabilir. Bir dayanıklılık stratejisi belirleyip ve bunu dayanıklı bir altyapı kurarak desteklemek, dönüşümün bozucu etkisine karşı organizasyonunuzu rahatlatabilir. Ama dayanıklı sistemlerin dayanıklı organizasyonlara ihtiyacı vardır; ikisi de el ele birlikte hareket etmek durumundadır. Aşağıdaki adımlar yönetici geliştiricilerin bu dönüşüme başlamasına yardımcı olacaktır.

Bulut adaptasyonu genellikle müşterinin işindeki büyük ölçekli dijital dönüşümlerin merkezidir. Ama dönüşümler bazen bozucu etkiler gösterebilir ve bu bozulmalar sinir bozucu olabilir. Bir dayanıklılık stratejisi belirleyip ve bunu dayanıklı bir altyapı kurarak desteklemek, dönüşümün bozucu etkisine karşı organizasyonunuzu rahatlatabilir. Ama dayanıklı sistemlerin dayanıklı organizasyonlara ihtiyacı vardır; ikisi de el ele birlikte hareket etmek durumundadır. Aşağıdaki adımlar yönetici geliştiricilerin bu dönüşüme başlamasına yardımcı olacaktır.

  1. Buluttaki dayanıklılığı anlama

    Yönetici geliştirici bulutta dayanıklılığı nasıl düşünmelidir? Dayanıklılık bir altyapının, iş yükünün veya platformun olumsuz olayların ve koşulların neden olduğu kesintilere karşı kendini nasıl koruyabileceğinin bir ölçüsüdür. Diğer mimari özellikler gibi dayanıklılık bir ölçekte ölçümlenir (yani bir sistemin dayanıklı olduğunun bir değeri vardır). 0 ya da 1 (doğru ya da yanlış) gibi İkili bir özellik olarak ölçülmez (diğer bir deyişle, dayanıklı ya da dayanıksız gibi ölçülmez).

    Ayrıca dayanıklılık kullanılabilirlik, güvenlik ve performans gibi diğer mimari özelliklere bağlı olan kapsamlı bir mimari özelliğidir. İş sürekliliği nedeniyle teknoloji dışı liderler genellikle “dayanıklılık” terimini diğer ilgili mimari özelliklerini ifade etmek için daha geniş bir kapsamda kullanırlar. Ancak yönetici geliştiricileri için dayanıklılık stratejilerini kullanılabilirlik, performans ve felaket kurtarma konularının merkezine almaları özellikle önerilir.

  2. Dayanıklılık stratejilerini uygulama ve otomatikleştirme

    Yönetici geliştiriciler dayanıklılığa yapılan yatırımın karşılığını almasını nasıl sağlar? Cevabımız: Sistemlerinizi sürekli olarak, normal ve anormal zamanlarda bu sistemleri destekleyecek kurumsal refleksin gelişmesini sağlayacak olan koşullara maruz bırakarak sağlayabilirsiniz.

    Aşağıdaki bölümlerde dayanıklılık için tasarım yapmanın ötesine geçmenize ve giderek daha da artan karmaşık ortamlarda otomasyon yapmanıza yardımcı olmak için uzun zamandır bulut adaptasyonunu sağlamış kullanıcılardan gözlemlediğimiz etkili uygulama pratiklerini paylaşacağız.

    Mimari incelemeleri

    AWS Well-Architected Framework dayanıklı altyapılar, uygulamalar ve veriler oluşturulmasında ve sürdürülmesinde liderlere rehberlik eder. En azından AWS Well-Architected incelemelerini yaşam döngüsü yönetimi süreçlerinize sık sık dahil etmenizi ve AWS Well-Architected Aracı‘nı zaman içinde dayanıklılığı sürekli kılmak ve geliştirmek için kullanmanızı öneririz. Ayrıca analitik ya da yüksek performanslı işlemler (HPC) gibi kritik iş yüklerini ve teknoloji alanlarını göz önünde bulundurmak için hazırlanan AWS Well-Architected Lens adı verilen özelleştirilmiş incelemeleri kullanmanızı da öneririz. Bu pratikler, örneğin “X”in ortamınızdaki kritik bileşenlerden biri olduğu durumda “X başarısız olduğunda ne olur?” sorusunun dayanıklılık ile ilgili tartışmalarda daha çok dikkate alınmasını sağlar.

    Masa üstü (Tabletop) olay simülasyonları

    Rutin yangın tatbikatları gibi, yönetici geliştiriciler de bir olaya (incident) yanıt vermek için operasyonel planlarını periyodik olarak test etmelidir.

    İş yükleri, altyapı veya verilerle ilgili operasyonel kurtarma senaryolarınız kurumun geliştirme yaşam döngüsü hızına göre test edilmelidir. Öncelikle başlangıç için üç aylık periyotlarda testlere başlamanızı ve yalnızca ana yaşam döngüsündeki kritik adımlarda test yapmaya çalışmanızı öneririz.

    Tam felaket kurtarma senaryoları için ise uyumluluk yönetmelikleri gereği için de gerekli olabileceğinden yıllık gözden geçirmeler ile başlamanızı öneririz. Buna bağlı olarak da dayanıklılığınızı güçlendirmenin yollarını belirlemek için üç aylık incelemeler yapmanız faydalı olacaktır.

    Kaos mühendisliği

    Zamanla, bulut mimarisini benimsemiş kurumlar sistemlerinin dayanıklılığını zorlayacak birçok muhtemel vaka (event) ve olayı (incident) otomatikleştirmek için yatırım yapabilir. Bu yetkinliği ortamlarınızda uygulamak için kaos mühendisliğinin prensiplerini benimsemek iyi bir pratik olacaktır. Örneğin, AWS Fault Injection Simulator servisi, ekiplerin ölçeklenebilir ortamlarındaki zayıf yönleri keşfetmesini kolaylaştırmak için kullanılabilir. Bu uygulama ekibinizin “Her şey her an başarısız olabilir.” düşüncesini benimsemesine yardımcı olur ve bu da dayanıklılık tasarım kalıplarını ortamlarında uyarlamayı önceliklendirmelerini sağlar.

  3. Büyük Düşün, Küçük başlaGeleneksel BT altyapı modellerini buluta geçirmek ve ardından dayanıklılık süreçlerini oluşturmak, özellikle hepsini aynı anda yapmayı hedefliyorsanız oldukça zordur. Ancak imkansız değildir, yapılabilir. Birçok başarıyla gerçekleştirilmiş bulut geçişini yönetici geliştiriciler aşağıdaki gibi yönetilebilir bir kapsamla başladığında, tekrarladığında ve ardından ölçeklendirdiğinde istenilen sonuçlara ulaştıklarını gördük.
    • İlk olarak teknoloji varlıklarınızı iş kritikliğine göre sınıflandırın. Bir teknoloji varlığı, tek bir uygulama veya birden fazla uygulamanın bağlı olduğu müşteri ilişkileri yönetimi çözümü gibi hayati bir sistem olabilir. Birçok müşterinin kritik varlıklarını tanımlamak için “Seviye 0 (Tier 0)”, “Kırmızı (Red)” veya “Kritik Görev (Mission Critical)” gibi terimler kullandığını görüyoruz.
    • Ardından tek bir kritik varlık veya birbiriyle ilişkili küçük bir varlık kümesi için dayanıklılık planı uygulayın.
      • Kullanılabilirlik ve performans gereksinimleri belirlemek ve bu gereksinimleri bir iş planına dönüştürmeye yardımcı olmak için farklı fonksiyonel yetkinlikleri olan bir ekibe ihtiyacınız olacak.
      • Ekip kaos mühendisliği prensiplerini kullanarak teknoloji varlıklarınının zayıf noktalarını belirlemeye yönelik analizler yapmalıdır.
      • İş birimleri tamamlanmamış siparişlerde azalma veya müşteri memnuniyetinde iyileşme gibi iş ile ilgili metriklerin belirlenmesinde yardımcı olmalıdır.

    İlk kritik varlığınızda (veya ilgili varlıklar kümesinde) dayanıklılık planını uygulayan ekip yeni bir dayanıklılık merkezinin çekirdeğini oluşturacaktır. Bu ekip bilgi birikimini ve en iyi pratiklerini kurum genelinde paylaşmaya da istekli olmalıdır. Bu amaçla ekibe başarılarını kutlamak, diğer takımları kendi örneklerini takip etmeye teşvik etmek ya da üç aylık periyotlarda dayanıklılık planlarını gözden geçirip diğer ekiplerle paylaşmak gibi çalışmaları yapabilecekleri bir platform vermek dönüşümü hızlandıracaktır.

Sonuç

Yönetici geliştiriciler, iş liderlerine BT varlıklarının dayanıklı olduğuna dair güvence vermekten ve aynı zamanda ekiplerinin dayanıklılığa ulaşmasına liderlik etmekten sorumludur. Bu yazıda bu liderlerin, iş paydaşlarının dayanıklılık endişelerini ifade etme biçimlerine uyum sağlamalarına yardımcı olmak ve geliştiricilerin dayanıklılık tasarımına bulutta farklı şekilde yaklaşmalarını sağlamak için rehberlik etmeyi amaçladık. Takip eden bir makalede daha fazla teknik dayanıklılık hususlarına değineceğiz.

Figür: Dayanıklılık stratejisi ve uygulamaları oluşturmak için önerilen üç adım.