Tasarım ve ilkede dayanıklılık
"Olağanüstü durum kurtarma" ile birlikte en sık "iş sürekliliği" ifadesinin okunma olasılığı yüksektir. Sürekliliğin olumlu bir çağrışımları vardır. Olağanüstü durum kurtarmanın kapsamını veya daha düşük kapsamlı bir konuyu veri merkezi duvarları içinde sınırlama idealini ifade eder.
Ancak tüm çabalara rağmen "devamlılık" bir mühendislik terimi değildir. İş devamlılığı için tek bir formül, metodoloji veya reçete yoktur. Tüm kuruluşlar için, yürüttüğü faaliyetlerin türü ve şekli ile ilgili bir dizi benzersiz en iyi uygulamalar olabilir. Olumlu bir sonuç elde etmek için bu uygulamaların başarılı şekilde yerine getirilmesi, devamlılığı sağlar.
Dayanıklılığın anlamı
Mühendisler dayanıklılık kavramını anlar. Bir sistem, değişen koşullar altında iyi performans gösterdiğinde dayanıklı olduğu söylenebilir. Risk yöneticisi, bir işletme karşılaşabileceği tüm olumsuz etkilere yanıt vermeye hazır şekilde yedekleri, güvenlik önlemlerini ve olağanüstü durum yordamlarını uyguladığında o işletmenin hazırlıklı olduğunu düşünür. Mühendis, bir sistemin içinde çalıştığı ortamı "normal" ve "tehdit edilen", "güvenlik" ve "olağanüstü durum" gibi siyah beyaz terimlerle algılamayabilir. Bu kişi, olumsuz koşullar karşısında sürekli ve öngörülebilir hizmet düzeyleri sağladığında, bir işletmeyi destekleyen sistemin düzgün çalışır durumda olduğunu algılar.
2011'de, bulut bilişimin veri merkezinde yükselen bir eğilim haline geldiği gibi, Avrupa Ağ ve Bilgi Güvenliği Ajansı (Avrupa Birliği'nin bir birimi olan ENISA), E.U. hükümetinin bilgi toplamak ve toplamak için kullandıkları sistemlerin dayanıklılığı hakkında içgörü isteğine yanıt olarak bir rapor yayınladı. Raporda, ICT personeli (Avrupa’da “ICT”, iletişimi de kapsayan “BT” için kullanılan terimdir) arasında “dayanıklılık” kavramının gerçekte ne anlama geldiği veya dayanıklılığın nasıl ölçüleceği konusunda kesinlikle fikir birliği olması gerektiği belirtildi.
Bu, ENISA'nın Abd Savunma Bakanlığı'na dağıtılmak amacıyla, Prof. James P. G. Sterbenz liderliğindeki Kansas Üniversitesi'nde (KU) bir araştırmacı ekibi tarafından başlatılan bir projeyi keşfetmesine yol açtı. Bu, Resilient and Survivable Networking Initiative (ResiliNets)1 olarak adlandırılır ve çeşitli koşullarda bilgi sistemlerindeki dalgalanan dayanıklılık durumunu görselleştirmeye yönelik bir yöntemdir. ResiliNets, kuruluşlardaki dayanıklılık ilkesi için konsensus modeline yönelik prototiptir.
KU modeli, bazıları bu bölümde halihazırda sunulmuş olan birçok bilindik ve kolayca açıklanabilen ölçümleri kullanır. Bu ölçümler şunlardır:
Hataya dayanıklılık - Daha önce açıklandığı gibi, bir sistemin hatalar mevcut olduğunda beklenen hizmet düzeylerini koruyabilme yeteneğidir
Kesintiye dayanıklılık - Aynı sistemin, sistemin kendisinden kaynaklanmayan (örneğin, elektrik kesintileri, İnternet bant genişliği yetersizlikleri ve trafik ani artışları), öngörülemeyen ve çoğunlukla aşırı olan çalışma koşullarında beklenen hizmet düzeylerini koruyabilme yeteneğidir
Sürdürülebilirlik - Bir sistemin, doğal afetler de dahil olmak üzere tüm olası koşullarda her zaman nominal olmasa da makul hizmet performansı düzeyleri sağlayabilme yeteneği tahminidir
ResiliNets tarafından geliştirilen temel teori, bilgi sistemlerinin, sistem mühendisliği ve insan çabasının birleşimiyle çok daha esnek hale getirilmesidir. İnsanların yaptıkları (konuyla ilgili) ve gündelik uygulamalarında yapmaya devam ettikleri şeyler, sistemleri daha güçlü hale getirir.
Aktif bir operasyon tiyatrosundaki askerlerin, denizcilerin ve Denizcilerin taktiksel dağıtım ilkelerini nasıl öğrendiklerinden ve hatırlalarından bir ipucu alan KU ekibi, ResiliNets uygulamasının yaşam döngüsünü hatırlamak için peçete arkası anımsatıcısı önerdi: D2R2 + DR. Şekil 9’da gösterildiği gibi buradaki değişkenler, şu sırayla aşağıdakileri ifade eder:**
Defend (Savunma) - Sistemi normal çalışmasına yönelik tehditlere karşı savunma
Detect (Algılama) - Olası hatalardan ve dış koşullardan kaynaklanan olumsuz etkilerin oluşumlarını algılama
Remediate (Düzeltme) - Bu etkilerin sisteminizde oluşturabileceği sonraki etkileri, bu etkilerin sürdürülmesi gerekse bile düzeltme
Recover (Kurtarma) - Normal hizmet düzeylerine geri getirme
Diagnose (Tanılama) - Olayların kök nedenlerini tanılama
Refine (Geliştirme) - Gelecekteki davranışları, yeniden oluşumlarına karşı daha hazırlıklı olmak için gerektiği şekilde geliştirme
Şekil 9: ResiliNets kullanan bir ortamdaki en iyi uygulama etkinliklerinin yaşam döngüsü.
Bu aşamaların her birinde hem kişiler hem de sistemler için belirli performans ve operasyon ölçümleri alınır. Bu ölçümlerin birleşimi, Öklidyen geometrik düzlemi kullanılarak Şekil 9.10’dakine benzer bir grafikte çizilebilen noktalarla sonuçlanır. Her ölçüm iki tek boyutlu değere düşürülebilir: biri hizmet düzeyi P parametrelerini yansıtan, diğeri ise işletimsel durumu N'yi temsil eder. ResiliNets döngüsündeki altı aşamanın tümü uygulanıp tekrarlandığından, hizmet durumu S, grafiğe koordinatlarda (N, P) çizilir.
Şekil 10: ResiliNets durum alanı ve strateji iç döngüsü.
Hizmet hedeflerini yerine getiren bir kuruluşun S durumu, grafın sol alt köşesinde dönüp durur; böylece iç döngü adı verilen süre boyunca orada veya oranın yakınlarında kalır. Hizmet hedeflerinin düzeyi düşürüldükçe durum, sağ üst köşeye doğru istenmeyen bir vektörde hareket eder.
ResiliNets modeli, işletmede BT dayanıklılığının ortak bir gösterimi olmamış olsa da, özellikle de kamu sektöründeki bazı önde gelen kuruluşlarca benimsenmesi sayesinde bulut devriminde katalizör görevi gören bazı değişiklikler tetiklendi:
Performans görselleştirmesi. Mevcut durumun ilgili paydaşlara aktarılması için dayanıklılığın bir felsefe olması gerekmez. Aslında bu, birden az sözcük kullanılarak ifade edilebilir. Buluttaki ölçümleri barındıran modern performans yönetimi platformları, kendilerine verimlilik kazandıran panolara ve benzer araçlara yer verdi.
Kurtarma önlemleri ve yordamlarının olağanüstü bir durumu beklemesi gerekmez. Sürekli olarak dikkatli mühendisler ve operatörlerle donatılmış olan kapsamlı ve düzgün tasarlanmış bir bilgi sistemi, bir kriz sırasında düzeltme yordamlarından çok az fark (varsa) gösteren günlük bakım yordamları uygular. Örneğin, etkin beklemedeki olağanüstü durum kurtarma ortamında hizmet düzeyi sorununun düzeltilmesi gerçekten otomatik olabilir; ana yönlendirici, trafiği etkilenen bileşenlerden dışarı yönlendirir. Başka bir deyişle, hataya hazırlığın, hatanın gerçekleşmesini beklemekle aynı olması gerekmez.
Bilgi sistemleri insanlardan oluşur. Otomasyon, insanların işini daha etkili hale getirebilir ve ürünlerinin daha verimli şekilde üretilmesini sağlayabilir. Ancak öngörülemeyen koşul ve çevre değişikliklerine yanıt verecek şekilde tasarlanan bir sistemde bu, insanların yerini tutamaz.
Kurtarma odaklı bilgi işlem
ResiliNets, Microsoft’un adının koyulmasına yardımcı olduğu Kurtarma Odaklı Bilgi İşlem (ROC) adlı bir kavramın uygulama örneklerinden biridir.2 Bunun temel ilkesi, hata ve arızaların, bilgi işlem ortamının değişmez gerçekleri olmasıdır. Bu ortamı hatalardan arındırmak için gereğinden fazla zaman ayırmak yerine kuruluşların, ortamın korunmasına katkıda bulunan sağduyu çerçevesinde önlemler uygulaması daha faydalı olabilir. Bu, 20. yüzyıldan önce hayatımıza giren, insanların günde birkaç defa elini yıkaması gerektiği kavramının bilgi işlemdeki karşılığıdır.
Genel bulutta dayanıklılık
Genel bulut hizmeti sağlayıcılarının tümü, farklı adlarla ifade etse de, dayanıklılık ilkelerine ve çerçevelerine bağlı kalır. Öte yandan bulut platformu, kuruluşun bilgi varlıklarını tamamen buluta koymadığı sürece kuruluşun veri merkezine dayanıklılık katmaz. Hibrit bulut uygulaması yalnızca en az özen gösteren yöneticisi kadar dayanıklıdır. CSP yöneticilerinin dayanıklılığa bağlı kalmaya özen göstereceğini (aksi takdirde hizmet düzeyi sözleşmesinin koşullarını ihlal ettiğini) varsayabilirsek, tüm sistemin dayanıklılığını korumak her zaman müşterinin görevi olmalıdır.
Azure Dayanıklılık Çerçevesi
İş devamlılığı stratejisi için uluslararası standart yönergesi ISO 22301’dir. Diğer Uluslararası Standardizasyon Teşkilatı (ISO) çerçeveleri gibi bu da en iyi uygulama ve operasyon yönergelerini ve kuruluşun profesyonel sertifikasyonunu sağlayan uyumluluğu belirtir.
Bu ISO çerçevesi aslında iş devamlılığını veya dayanıklılığı tanımlamaz. Bunun yerine, kuruluşun kendi bağlamında devamlılığın ne anlama geldiğini tanımlar. Yol gösterici belgesinde "Kuruluş, iş etkisi analizi ve risk değerlendirmesinden elde edilen çıktılara göre iş devamlılığı stratejilerini tanımlayıp seçmelidir. İş sürekliliği stratejileri bir veya daha fazla çözümden oluşur." Bu çözümlerin ne olabileceği veya olması gerektiği listelenmez.3
Şekil 11’de, ISO 22301 uyumluluğuna dair Azure’ın çok aşamalı uygulamasının Microsoft tarafından sunulan gösterimi yer almaktadır. Hizmet düzeyi sözleşmesinin (SLA) çalışma süresi hedeflerinin eklendiğine dikkat edin. Bu dayanıklılık düzeyini seçen müşteriler için Azure, yerel kullanılabilirlik alanı içinde sanal veri merkezlerini çoğaltır, ancak sonra coğrafi konumu birbirinden yüzlerce mil uzakta olan ayrı çoğaltmalar sağlar. Öte yandan yasal nedenlerle (özellikle de Avrupa Birliği’nin gizlilik yasalarıyla uyumluluğu korumak için) bu coğrafi konumu ayrılmış yedeklilik genellikle Kuzey Amerika veya Avrupa gibi “veri yerleşimi sınırları” ile sınırlıdır.
![Figure 11: Azure Resiliency Framework, which protects active components on multiple levels, in accordance with ISO 22301. [Courtesy Microsoft]](../../cmu-cloud-admin/cmu-disaster-recovery-backup/media/fig9-11.jpg)
Şekil 11: ISO 22301'e uygun olarak birden çok düzeyde etkin bileşenleri koruyan Azure Dayanıklılık Çerçevesi. [Sayıştay Microsoft]
ISO 22301, dayanıklılıkla ilişkilendirilmiş olup çoğu zaman dayanıklılık yönergeleri kümesi olarak tanımlansa da, Azure’ın test edildiği dayanıklılık düzeyleri, Azure platformunda barındırılan müşteri varlıkları için değil, yalnızca Azure platformu için geçerlidir. Azure bulutta ve başka yerlerde varlıklarının çoğaltılma şekli de dahil, süreçlerini yönetmek, korumak ve sıklıkla iyileştirmek yine müşterinin sorumluluğundadır.
Google Container Engine
Yakın zamana kadar yazılım, işlevsel olarak donanımla aynı olan, ancak dijital biçimde bir makine durumu olarak algılanıyordu. Bu açıdan bakıldığında yazılım bir bilgi sisteminde nispeten statik bir bileşen olarak algılandı. Güvenlik protokolleri, yazılımın düzenli olarak güncelleştirilmesini zorunlu tutuyordu ve “düzenli olarak” ifadesiyle genellikle güncelleştirmelerin ve hata düzeltmelerinin mevcut olduğu yılda birkaç defa sıklığı ima ediliyordu.
Bulut dinamiklerinin mümkün hale getirdiği, ancak çoğu BT mühendisinin öngöremediği şey, yazılımın sık ve artımlı şekilde değişip gelişme özelliğiydi. Sürekli Tümleştirme ve Sürekli Teslim (CI/CD), otomasyonun sıklıkla, çoğu zaman günlük olarak hem sunucu hem de istemci tarafında yazılım üzerindeki artımlı değişikliklerin hazırlanmasına olanak sağladığı bir dizi ilkedir. Akıllı telefon kullanıcıları, uygulama mağazalarında haftada birkaç kez gibi yüksek sıklıkta güncelleştirilen uygulamalar nedeniyle düzenli olarak CI/CD ile karşılaşır. CI/CD ile birlikte gelen her bir değişiklik küçük ölçekli olabilir, ancak küçük değişikliklerin zorluksuz ve hızlı şekilde dağıtılabiliyor olması, öngörülmeyen, ancak hoş karşılanan bir yan etkiyle sonuçlandı: çok daha dayanıklı bilgi sistemleri.
CI/CD dağıtım modelleri sayesinde, çoğunlukla genel bulut altyapısında, hem yeni üretilen yazılım bileşenlerinin hatalar açısından testi hem de olası hataları ortaya çıkarmak için bu bileşenlerin simülasyonlu bir çalışma ortamında hazırlanması yoluyla tamamen yedekli sunucu kümeleri sağlanır ve korunur. Böylece düzeltme işlemleri, düzeltmeler uygulanıp test edilip dağıtım için onaylanıncaya kadar müşteriye dönük veya kullanıcıya dönük hizmet düzeyleri üzerinde doğrudan etkisi olmayan güvenli bir ortamda gerçekleşebilir.
Google Container Engine (GKE; burada "K", "Kubernetes"i ifade eder), sanal makine tabanlı uygulamalar yerine kapsayıcı tabanlı uygulamaları ve hizmetleri dağıtan müşteriler için Google Cloud Platform ortamıdır. Tam kapsayıcılı dağıtım; mikro hizmetleri ("µ hizmetleri"), iş yüklerinden ayrı olan ve bağımsız şekilde çalışacak şekilde tasarlanan veritabanlarını ("durum bilgisi olan veri kümeleri"), bağımlı kod kitaplıklarını ve uygulama kodunun, kapsayıcının kendi dosya sistemini kullanması gerekmesi durumunda kullanılan küçük işletim sistemlerini kapsayabilir. Şekil 9.12’de, Google’ın kendi GKE müşterileri için gerçekten önerdiği stildeki dağıtım gösterilmektedir.
Şekil 12: Google Container Engine için CI/CD hazırlama ortamı olarak etkin bekleme seçeneği.
GKE’de proje, normalde bir veri merkezinin sahip olacağı her şeye yalnızca sanal biçimde sahip olması açısından bakıldığında, veri merkezine benzer. Bir projeye atanmış bir veya daha fazla sunucu kümesi olabilir. Kapsayıcılı bileşenler, kendi ana evrenleri gibi olan kendi ad alanlarında bulunur. Bunların her biri, üye kapsayıcılarının erişmesine izin verilen tüm adreslenebilir bileşenlerden oluşur ve ad alanının dışındaki her şey, uzak IP adresleri kullanılarak adreslenmelidir. Google’ın mühendisleri, her bir sınıf aynı projeyi paylaşırken güvenlik için kendi ad alanını kullandığı sürece, eski stil istemci/sunucu uygulamalarının (kapsayıcı geliştiricileri bunlara "monolith" adını verir), kapsayıcılı uygulamalarla bir arada bulunabileceğini belirtmektedir.
Bu önerilen dağıtım diyagramında, biri eski yazılım, biri de yeni yazılım için olmak üzere her biri iki ad alanını çalıştıran üç etkin küme vardır. Biri ilk geliştirme testi, biri de son hazırlama için olmak üzere, bu kümelerin ikisi test için atanır. CI/CD ardışık düzeninde yeni kod kapsayıcıları, test kümelerinden birine eklenir. Hazır aşamasına aktarılmadan önce burada, bir dizi otomatikleştirilmiş testi geçerek nispeten hata içermediğini kanıtlamalıdır. İkinci bir dizi de burada yeni yazılım kapsayıcılarını bekler. Yalnızca ikinci katman hazırlama testinden geçen kod, son müşterilerin kullandığı canlı üretim kümesine eklenebilir.
Ancak burada bile yedekler vardır. A/B dağıtım senaryosunda, belirtilen bir süre boyunca eski kodla birlikte yeni kod bulunur. Yeni kod belirtimlere göre performans gösteremiyorsa veya sistemde hatalara neden oluyorsa, yeni kod geri çekilerek eski kod bırakılabilir. İzin verilen süre dolarsa ve yeni kod düzgün performans gösteriyorsa eski kod geri çekilir.
Bu işlem, bilgi sistemlerinin hatalara (failure) neden olan hataların (fault) oluşmasını engellemesinin sistematik ve yarı otomatikleştirilmiş bir yoludur. Ancak üretim kümesi, etkin bekleme modunda çoğaltılmadığı sürece bu, olağanüstü duruma dayanıklı bir senaryo değildir. Bu çoğaltma düzeninde kesinlikle çok miktarda bulut tabanlı kaynak tüketilir. Ancak söz konusu maliyet, bir kuruluşun sistem kesintisine karşı korunmaması durumunda oluşacak maliyete kıyasla çok daha düşük olacaktır.
Başvurular
Sterbenz, James P.G., ve diğerleri. "ResiliNets: Çok Düzeyli Dayanıklı ve Hayatta Kalan Ağ Girişimi." https://resilinets.org/main_page.html.
Patterson, David ve diğerleri. "Kurtarma Odaklı Bilgi İşlem: Motivasyon, Tanım, İlkeler ve Örnekler." Microsoft Research, Mart 2002. https://www.microsoft.com/research/publication/recovery-oriented-computing-motivation-definition-principles-and-examples/.
ISO. "Güvenlik ve dayanıklılık - İş sürekliliği yönetim sistemleri - Gereksinimler." https://dri.ca/docs/ISO_DIS_22301_(E).pdf.