Sıfır Kesintisiz Yeniden Yapılandırma: Sistemleri Çevrimdışı Bırakmadan Nasıl Yeniden Yapılandırma Yapılır?

Üretim sistemlerinin durmasına izin verilmez. Gece 2'de işlemleri işleyen finansal platform, farklı zaman dilimlerinde klinisyenlere hizmet veren sağlık kayıt sistemi, kıtalar arası gönderileri takip eden lojistik uygulaması: bunların hiçbirinin yeniden yapılandırma çabasını absorbe edebilecek bir bakım penceresi yoktur. Yine de hepsi teknik borç biriktirir, önceki kısıtlamalar altında alınan mimari kararları taşır ve sonunda sürdürülebilir, ölçeklenebilir ve güvenli kalabilmek için yapısal değişiklik gerektirir. Sıfır kesinti süresiyle yeniden yapılandırma, bu gerilimi çözen disiplindir: sunduğu hizmeti kesintiye uğratmadan canlı bir sistemi geliştirmek.

Sorun sadece teknik değil, aynı zamanda organizasyonel ve mimari bir sorundur. Çevrimdışı çalışamayan bir sistemi yeniden yapılandırmak, geliştirme aşamasındaki bir sistemi yeniden yapılandırmaktan farklı bir zihinsel model gerektirir: her değişiklik, uyumlu olmadığı ana kadar geriye dönük uyumlu olmalı, her yapısal geçiş geri alınabilir olmalı ve her doğrulama sentetik testler yerine gerçek trafiğe karşı yapılmalıdır. Bunu mümkün kılan teknikler, mavi-yeşil dağıtımlar, özellik geçişleri, boğucu incir deseni, genişletme-daraltma veritabanı geçişleri ve idempotent olay odaklı mimariler dahil olmak üzere, ayrı ayrı iyi belgelenmiştir. Daha az ele alınan konu ise, bu tekniklerin, süreç boyunca kullanıcılara hizmet etmesi gereken sistemlerde sürdürülebilir, güvenli yapısal değişiklik için tutarlı bir strateji olarak nasıl birlikte çalıştığıdır.

Sıfır Kesinti Süresiyle Değişiklikler İçin Mimarinizin Nasıl Olması Gerekir?

Sıfır kesinti süresiyle yeniden yapılandırmaya karar verirken ekiplerin en sık sorduğu soru mimariyle ilgili: Yeniden yapılandırmaya başlamadan önce sistemin nasıl oluşturulduğu konusunda neyin değişmesi gerekiyor? Cevap tek bir kalıp değil, canlı yeniden yapılandırmanın güvenli olması için bir sistemin sergilemesi gereken bir dizi yapısal özelliktir. Bu özellikleri anlamak, bu kılavuzdaki diğer her şey için ön koşuldur.

İlk özellik bağımsız dağıtım yeteneğidir. Yeniden yapılandırılacak her bileşen, bağımlılıklarının eş zamanlı dağıtımını gerektirmeden dağıtılabilir olmalıdır. Eğer A servisinde değişiklik yapmak, arızayı önlemek için B ve C servislerinde de eş zamanlı değişiklik yapılmasını gerektiriyorsa, A servisinin sıfır kesintiyle dağıtımı yapısal olarak imkansızdır: üç servis, kaç depoda bulunduklarına bakılmaksızın, etkili bir şekilde tek bir dağıtım birimidir. Bağımsız dağıtım yeteneği, geriye dönük uyumlu arayüzler, sürümlü sözleşmeler ve servisler arasında koordineli dağıtım gereksinimlerinin ortadan kaldırılmasını gerektirir.

İkinci özellik ise geri alınabilirliktir. Canlı davranışı değiştiren her dağıtım, saatler değil, dakikalar içinde geri alınabilir olmalıdır. Geri alınabilirlik sadece eski ikili dosyanın kullanılabilir durumda tutulmasıyla ilgili değildir. Veritabanı durumu, önbellek durumu, oturum durumu ve yeni sürüm tarafından değiştirilen herhangi bir harici sistem durumunun eski sürümle uyumlu olmasını gerektirir. Yeni bir sürüm, eski sürümün okuyamadığı bir biçimde veri yazarsa, dağıtım tanım gereği geri alınamaz ve sıfır kesinti süresi imkansızdır çünkü herhangi bir geri alma işlemi hatalara yol açacaktır.

Üçüncü özellik, gözlemlenebilir durum geçişleridir. Davranışı bir kod yolundan diğerine taşıyan ancak her iki yolda da gözlemlenebilir ölçütler içermeyen bir yeniden yapılandırma çalışması, körleme çalışır. Ekip, geçişin başarılı olup olmadığını bilemez, gerilemeleri erken tespit edemez ve geçişi ne zaman hızlandıracağına veya durduracağına dair veriye dayalı kararlar alamaz. Gözlemlenebilirlik, bir sorun ortaya çıktıktan sonra değil, yeniden yapılandırma başlamadan önce sağlanmalıdır. Bu bağlamda incelendiğinde, artımlı yeniden yapılandırma ve teknik borçKodun ne yaptığının ve ona nelerin bağlı olduğunun yapısal olarak görünür olması, üretimde başarısızlığa tahammül edilemeyecek her türlü değişikliğin planlanmasının temelidir.

Mavi-Yeşil Dağıtım: Temel Model

Mavi-yeşil dağıtım, sıfır kesinti süresiyle sürüm yayınlamanın temel modelidir. İki özdeş üretim ortamı bulunur: canlı trafiğe hizmet veren mavi ortam ve yeni sürümü alan yeşil ortam. Yeni sürüm, yeşil ortamda dağıtılır, test edilir ve doğrulanır; bu sırada mavi ortam kullanıcılara kesintisiz hizmet vermeye devam eder. Yeşil ortam doğrulandığında, trafik atomik olarak değiştirilir. Geri alma işlemi bunun tersidir: trafik tekrar mavi ortama yönlendirilir ve mavi ortam kesintisiz olarak kullanılabilir durumda kalır.

Bu model basit gibi görünüyor. Zorluğu ise veritabanı katmanında yatıyor. Her iki ortamın da aynı veritabanından okuma ve yazma yapması gerektiğinde, veritabanı şemasının her iki sürümle de aynı anda uyumlu olması gerekir. Bir sütunu silen, bir alanı yeniden adlandıran veya bir veri türünü değiştiren bir geçiş, yürütüldüğü anda eski ortamı bozar. Bu nedenle, mavi-yeşil dağıtım, bu kılavuzun veritabanı bölümünde açıklanan genişletme-daraltma şema geçiş modelinden ayrı düşünülemez.

Kanarya Sürümleri ve Aşamalı Dağıtım Teknikleri

Kanarya sürümleri, trafiğin tamamını aynı anda değiştirmek yerine, trafiğin belirli bir yüzdesini yeni sürüme yönlendirerek mavi-yeşil modelini genişletir. Bir kanarya dağıtımı, kullanıcıların yüzde biriyle başlayabilir, bu grup için hata oranlarını, gecikmeyi ve iş metriklerini gözlemleyebilir ve ardından yüzdeyi kademeli olarak artırabilir: beş, yirmi, elli, yüz. Her aşamada, otomatik kontroller, temel metriklerin tanımlanmış eşiklerin ötesine düşmediğini kontrol eder. Bir kontrol başarısız olursa, dağıtım durdurulur ve kanarya yüzdesi sıfıra düşürülür.

Aşamalı dağıtım teknikleri, bu ilerlemeye hedefleme mantığı ekler. Yalnızca yüzdeye göre yönlendirme yerine, trafik kullanıcı grubu, coğrafi bölge, abonelik seviyesi veya oturum özelliklerine göre bölümlere ayrılabilir. Bu, yeni sürümün, söz konusu kullanıcı popülasyonu tamamen geçiş yapmadan önce, onu en çok zorlayan belirli kullanıcı popülasyonuna karşı doğrulanmasını sağlar. Temel gereksinim, yük dengeleyici, API ağ geçidi veya hizmet ağı gibi yönlendirme altyapısının, dağıtımın gerektirdiği hedefleme ayrıntı düzeyini desteklemesidir.

Dağıtım başlamadan önce, test aşamalarını yöneten ölçütler tanımlanmalıdır. Hata oranı, p99 gecikmesi, veritabanı sorgu süresi ve dönüşüm oranı veya ödeme başarı oranı gibi işletmeye özgü ölçütler geçerli test kriterleridir. Test eşikleri, teorik hedeflere göre değil, karşılaştırılabilir yük altında mevcut sürümden ölçülen bir temel değere göre kalibre edilmelidir. Trafiğin yüzde ikisinde bir test aşamasını geçen ancak yüzde yirmisinde başarısız olan bir dağıtım doğrulanmamıştır: test aşaması temsili olamayacak kadar küçüktür. Doğru aşamalı dağıtım, istatistiksel olarak anlamlı bir karşılaştırma üretmek için her aşamada yeterli trafik maruziyetini gerektirir.

Özellik Açma/Kapama Düğmeleri ve Kapatma Düğmeleri

Özellik anahtarları, kod dağıtımını davranış etkinleştirmesinden ayırır. Yeniden yapılandırılmış bir kod yolu, hangi kullanıcıların veya isteklerin yeni mantığı yürüteceğini belirleyen bir anahtar tarafından kontrol edilen, etkin olmayan bir durumda dağıtılır. Anahtar, kademeli olarak etkinleştirilebilir, belirli gruplara hedeflenebilir veya yeniden dağıtım olmadan anında geri alınabilir. Bu, özellik anahtarlarını, mavi-yeşil veya kanarya modellerinin daha uygun olduğu altyapı değişikliklerinin aksine, iş mantığının sıfır kesinti süresiyle taşınması için birincil mekanizma haline getirir.

Acil durdurma anahtarları, özellik anahtarlarının savunma amaçlı karşılığıdır: Amaçları yeni bir davranışı etkinleştirmek değil, yanlış davrandığında anında devre dışı bırakmaktır. Yeniden yapılandırılmış bir faturalama hesaplamasında, yeni bir kimlik doğrulama akışında veya değiştirilmiş bir veri erişim katmanında bulunan acil durdurma anahtarı, nöbetçi mühendise dağıtım, veritabanı geri alma veya ekipler arası koordinasyon gerektirmeyen tek işlemlik bir kurtarma yolu sağlar. Acil durdurma anahtarı, tetikleme gecikmesinin dakikalar yerine saniyeler olması için bir API çağrısı, özellik bayrağı yönetim konsolu veya otomatik uyarı entegrasyonu yoluyla tetiklenmesine izin veren bir sistemde yapılandırılmalıdır.

Toggle hijyeni gerçek bir operasyonel sorundur. Hiçbir zaman temizlenmeyen toggle'lar kod tabanında birikir, kontrol akışını anlamayı giderek zorlaştırır ve toggle durumu ile veri durumu arasında örtük bağımlılıklar yaratır. Her toggle'ın belgelenmiş bir sahibi, planlanmış bir son kullanma tarihi ve bir temizleme bileti olmalıdır. Toggle borcu, diğer teknik borç türleri kadar gerçektir ve toggle'lar genellikle sistemin en aktif değişen kısımlarını koruduğu için daha hızlı bir şekilde birikir.

Kesinti Olmadan Veritabanı Yeniden Yapılandırması

Veritabanı değişiklikleri, sıfır kesinti süresiyle yeniden yapılandırmanın en zor kısmıdır çünkü veritabanları durum bilgisi içerir, paylaşımlıdır ve büyük ölçekte değiştirilmesi yavaştır. Uygulama dakikalar içinde dağıtılabilir ve geri alınabilir. Yüz milyonlarca satır içeren bir tabloyu değiştiren bir veritabanı geçişi saatler sürebilir, bir kez onaylandıktan sonra kolayca geri alınamaz ve işlem süresince okuma ve yazma işlemlerini engelleyen kilitler tutar. Veritabanı yeniden yapılandırmasını doğru yapmak, uygulama kodu yeniden yapılandırmasından farklı bir yaklaşım gerektirir ve çoğu ekip bunu, canlı ve yüksek trafikli bir tabloda şema değişikliği yapmaya ilk kez çalıştıklarında keşfeder.

Temel prensip, önceki uygulama sürümü artık dağıtılmadığı sürece, her veritabanı değişikliğinin önceki uygulama sürümüyle geriye dönük uyumlu olmasıdır. Bu kulağa açık gelse de, açık olmayan sonuçları vardır. Bir sütunu yeniden adlandırmak, eski ad kaldırılmadan önce yeni adı bir takma ad veya kopya olarak eklemeyi gerektirir. Bir sütun türünü değiştirmek, eski sütun devre dışı bırakılmadan önce yeni türün gölge sütununun paralel olarak doldurulmasını gerektirir. Bir tabloyu silmek, uygulamanın dağıtılmış hiçbir sürümünün ondan okuma yapmadığını doğrulamayı gerektirir. Bu işlemlerin her biri, tek bir kez çalışan bir geçiş değil, birden fazla dağıtıma yayılmış çok adımlı bir süreçtir. Daha geniş bağlamda tartışıldığı gibi, Eski veri yapıları genelinde COBOL yeniden yapılandırmasıBirden fazla program ve sistemde paylaşılan veri yapılarının, koordineli bir geçiş olmaksızın evrimleşmesi zorluğu, kurumsal ölçekte yeniden yapılandırmanın belirleyici zorluklarından biridir.

Genişletme-Daraltma Modeli

Genişletme-daraltma modeli, şema değişikliklerine yönelik çok adımlı yaklaşımı resmileştirir. Genişletme aşamasında, yeni şema öğeleri eklemeli olarak eklenir: eski sütunun yanına yeni bir sütun, eski tablonun yanına yeni bir tablo, eski indeksin yanına yeni bir indeks. Uygulama hem eski hem de yeni yapılara yazacak şekilde güncellenir, ancak eski yapıdan okumaya devam eder. Hiçbir veri kaybolmaz, mevcut sorgular bozulmaz ve eski şema öğeleri hala mevcut olduğundan uygulamanın eski sürümü çalışmaya devam eder.

Yeni sürüm tamamen dağıtılıp doğrulandıktan sonra ayrı bir dağıtım aşamasında gerçekleşen daraltma aşamasında, eski şema öğeleri kaldırılır. Bu noktada, uygulamanın çalışan hiçbir sürümü bunlara bağımlı değildir. Kaldırma işlemi güvenlidir çünkü planlama yoluyla varsayılmak yerine gözlem yoluyla doğrulanmıştır.

Genişletme-daraltma modeli, dağıtım sıralaması konusunda disiplin gerektirir. Yeni sütunu ekleyen veritabanı geçişi, bu sütuna yazan uygulama sürümünden önce dağıtılmalıdır. Eski sütunu silen veritabanı geçişi ise, bu sütundan okuyan tüm uygulama sürümleri kullanımdan kaldırıldıktan sonra dağıtılmalıdır. Bu sıralama gereksinimleri, geçişlerin sırasız uygulanmaması için dağıtım hattına kodlanmalıdır.

Kod yeniden yazmadan eski veri işlem hatlarını yeniden yapılandırmak için araçlar

Eski veri işlem hatları, özellikle toplu işleme çerçeveleri, ETL araçları veya ana bilgisayar tabanlı veri taşıma sistemleri üzerine kurulu olanlar, belirli bir zorluk teşkil eder: verileri sürekli olarak dönüştürür ve taşırlar, bir geçiş süresince durdurulamazlar ve genellikle tam olarak ne yaptıklarının kapsamı bir sorun ortaya çıkana kadar bilinmeyecek kadar yetersiz belgelendirilmişlerdir. Bu işlem hatlarını tamamen yeniden yazmadan yeniden yapılandırmak, işlem hattının şu anda ne yaptığını gözlemleyebilen, yeniden yapılandırılmış sürümün eşdeğer çıktı ürettiğini doğrulayabilen ve geçişin ani değil, aşamalı olarak yapılmasını sağlayabilen araçlar gerektirir.

Değişiklik verisi yakalama (CDC), canlı işlem hattı yeniden yapılandırması için en yaygın uygulanabilir araçtır. CDC, kaynak tablodaki her yazma işlemini bir olay akışı olarak yakalar ve bu sayede eski işlem hattını ve yeni yedek işlem hattını aynı kaynaktan, ikisini de değiştirmeden beslemek mümkün olur. Eski işlem hattı çalışmaya devam eder, yeni işlem hattı aynı olay akışına karşı paralel olarak çalıştırılır ve çıktılar karşılaştırılır. Tutarsızlıklar, doğru şekilde yeniden uygulanmamış olan dönüşüm mantığını belirler. Eşitlik doğrulandığında, eski işlem hattı devre dışı bırakılır.

Liquibase ve Flyway gibi şema geçiş araçları, kademeli olarak uygulanabilen ve genişletme-daraltma disipliniyle birleştirildiğinde geri alınabilen sürümlü, sıralı geçişler sağlar. Hangi geçişlerin hangi ortama uygulandığını izler ve sırasız uygulamayı önler. Ana bilgisayar veya VSAM tabanlı veri depolarında çalışan eski işlem hatları için eşdeğeri, şu şekilde yönetilir: JCL genişletme ve veri kümesi yönetimi Bu, geçiş sırasında programların verilere nasıl erişeceğini kontrol ederek, ne eski ne de yeni programın uyumsuz bir veri kümesi düzenine karşı çalışmamasını sağlar.

Kesinti Olmadan Eski Veritabanlarını Nasıl Modernleştirebilirsiniz?

Eski bir veritabanını modernize etme, ana bilgisayar DB2 şemasından bulut tabanlı bir ortamda ilişkisel bir veritabanına geçme, dosya tabanlı VSAM yapısından ilişkisel bir şemaya geçiş yapma veya birden fazla eski veritabanını yeni bir birleşik depoda birleştirme gibi özel zorluklar, yukarıdaki tüm tekniklerin uzun bir süre boyunca sırayla uygulanmasını gerektirir.

Sürekli olarak işe yarayan yaklaşım şudur: önce okuma eşliği sağlanır, ardından yazma eşliği elde edilir, sonra okuma işlemleri taşınır, ardından yazma işlemleri taşınır ve son olarak eski depolama alanı devre dışı bırakılır. Okuma eşliği, yeni depolama alanının eski depolama alanının içerdiği tüm verileri içerdiği ve uygulamanın yaptığı tüm sorguları karşılayabildiği anlamına gelir. Yazma eşliği, uygulamanın eski depolama alanına yaptığı her yazma işleminin, uygulamadaki çift yazma işlemleri veya CDC replikasyonu yoluyla yeni depolama alanına da uygulandığı anlamına gelir. Üretim yükü altında her iki eşliği koşulu da doğrulandıktan sonra, okuma işlemleri yeni depolama alanına taşınabilir (çıktıları doğrulayarak), ardından yazma işlemleri taşınabilir ve son olarak eski depolama alanı devre dışı bırakılabilir.

Bu işlem dizisinin hiçbir aşamasında herhangi bir hizmet kesintiye uğramaz. Her aşamada, okuma veya yazma işlemlerini önceki depoya geri taşıyarak önceki durum geri yüklenebilir. Her aşamanın süresi, sabit bir takvim tarihine değil, doğrulama tarafından üretilen güven düzeyine göre belirlenir.

Kodu yeniden yazmadan eski sistemleri yeniden yapılandırmak için araçlar

Eski bir sistemi sıfırdan yeniden yazmak, onu kademeli olarak yeniden yapılandırmaktan neredeyse her zaman daha pahalı ve risklidir. Tamamen yeniden yazma işlemleri, eski sistemi üretimde tutarken aynı anda benzer işlevselliğe sahip bir yedek sistem oluşturmayı, iki sistem arasındaki özellik eşdeğerliği açığını yönetmeyi ve esasen tamamen farklı bir sistemin sıfır kesinti süresiyle devreye alınmasını gerektiren bir geçiş işlemini gerçekleştirmeyi gerektirir. Tamamen yeniden yazma girişiminde bulunan çoğu kuruluş, sürecin ortasında, eski sistemin belgelenmemiş davranışlar içerdiğini, yedek sistemin henüz bunları kopyalamadığını ve kullanıcıların bunlara bağlı olduğunu keşfeder.

Doğru araçlarla artımlı yeniden yapılandırma, eski sistemi değiştirmeden önce okunabilir hale getirerek bu tuzağı önler. Başlangıç ​​noktası yapısal analizdir: mevcut sistemin her bileşeninin ne yaptığını, ona neyin bağlı olduğunu ve onun neye bağlı olduğunu anlamak. Bu analiz, dokümanları okuyarak (ki bu genellikle eski sistemler için eksik veya yanlıştır) veya büyük ölçekte kodu manuel olarak okuyarak yapılamaz. Mevcut kodu ayrıştıran, bir bağımlılık grafiği oluşturan ve bu grafiği sorgulanabilir hale getiren otomatik araçlar gerektirir. Aşağıda açıklandığı gibi, eski sistem entegrasyonu zorluklarını yönetmekEski sistemlerin yeniden yapılandırılması programının ilk adımı, insan eliyle oluşturulan hiçbir yapıda bulunmayan yapısal görünürlüğü sağlamaktır.

Monolitler için Boğucu İncir Deseni

"Boğucu incir" deseni, tam bir yeniden yazma veya geçiş olayı olmadan, bir monolit yapıyı kademeli olarak değiştirmek için baskın mimari stratejidir. Yeni işlevsellik, monolit yapının yanında bağımsız hizmetler olarak oluşturulur. Tipik olarak bir API ağ geçidi veya ters proxy olan bir yönlendirme katmanı, gelen istekleri yakalar ve yönlendirme kurallarına göre bunları ya monolit yapıya ya da yeni hizmete yönlendirir. Monolit yapı, henüz taşınmamış tüm trafiğe hizmet etmeye devam eder. Yeni hizmet yalnızca kendisine açıkça yönlendirilen trafiği işler.

Zamanla daha fazla yönlendirme kuralı eklenir. Daha fazla yol yeni hizmetlere yönlendirilir. Monolit, toplam trafiğin giderek daha azını yönetir. Sonunda, monolit hiçbir şeyi yönetmez ve devre dışı bırakılabilir. Bu süreçte hiçbir tekil dağıtım, önemli bir risk oluşturacak kadar büyük değildir. Her yönlendirme kuralı değişikliği ayrı ayrı test edilebilir ve ayrı ayrı geri alınabilir. Boğucu incir, hızlı bir dönüşüm tekniği değil; boğulan sistemin karmaşıklığına bağlı olarak haftalar, aylar veya yıllar boyunca güvenli bir dönüşüm tekniğidir.

Strangler fig deseninin en önemli uygulama gereksinimi, yönlendirme katmanının hem monolit hem de yeni hizmetlerden bağımsız olmasıdır. Monolitin içine yerleştirilmiş bir yönlendirme katmanı, trafiği monolit dışına yönlendiremez. Vekil sunucu, her ikisinin de önünde yer almalı ve monolit veya yeni hizmeti değiştirmeden değiştirilebilen bir yapılandırmaya bağlı olarak trafiği her ikisine de yönlendirebilmelidir.

Eski API'leri Kesinti Olmadan Bulut Tabanlı Hizmetlere Yeniden Yapılandırma

Eski bir API'yi bulut tabanlı bir alternatife geçirmek, ek kısıtlamalarla birlikte boğucu incir deseninin özel bir uygulamasıdır: eski API'nin aynı anda güncellenemeyen tüketicileri olabilir, API sözleşmesi geçiş boyunca korunmalıdır ve bulut tabanlı alternatifin, tüketicileri beklenmedik şekillerde etkileyebilecek farklı performans özellikleri olabilir.

Standart yaklaşım, bulut tabanlı alternatifi eski API ile aynı API sözleşmesinin arkasına yerleştirmek, trafik akışının bir yüzdesini kademeli geçiş teknikleri kullanarak alternatife yönlendirmek, bu trafik yüzdesi için çıktı eşitliğini doğrulamak ve yönlendirilen yüzdesini kademeli olarak artırmaktır. API sözleşmesi korunduğu için tüketicilerin bu geçiş sırasında herhangi bir değişiklik yapmasına gerek yoktur. Yönlendirme katmanı geçişi şeffaf bir şekilde yönetir.

Bu makale için Arama Konsolu verilerinde yüksek amaçlı bir sorgu olarak görünen, temel entegrasyonlardan ara katman API'lerine sıfır kesintiyle geçiş, tam olarak bu senaryodur: yönlendirme katmanının trafiğin tamamını yeni sisteme yönlendirecek şekilde güncellendiği ve eski API'nin devre dışı bırakıldığı an. Bu geçiş asla tek bir atomik olay olmamalıdır. Yeni sistemin giderek artan trafik yüzdelerinde zaten doğrulanmış olduğu kademeli bir dağıtımın son adımı olmalıdır. Son geçiş gerçekleştiğinde, yeni sistem zaten tüm trafik hacmini yönetmiş olur; geçiş yalnızca artık ihtiyaç duyulmayan yedek yolu kaldırır.

Yeniden Yapılandırılmış Sistemlerde İdempotans, Yeniden Denemeler ve Yük Devretme

Olay odaklı mimari, mesaj kuyrukları veya dağıtılmış servis çağrıları kullanan bir sistemi yeniden yapılandırmak, yalnızca dağıtım odaklı kalıpların ele almadığı bir dizi sorunu ortaya çıkarır: Bir servis eski sürümden yeni sürüme geçtiğinde devam eden işlemlere ne olur? Eski sürüm altında yayınlanan olaylar, yeni sürümü çalıştıran bir işleyiciye ulaşabilir. Eski API'ye karşı başlatılan istekler, zaten yeni bir iç yapıya yeniden yapılandırılmış bir işleyiciye ulaşabilir. Eski mantık altında kısmen tamamlanan işlemlerin, yeni mantık altında tamamlanması veya telafi edilmesi gerekebilir.

Tüm bu sorunların cevabı, her işlemin bir kez veya birden fazla kez çalıştırıldığında aynı sonucu üretecek şekilde tasarlanması olan idempotansiyeldir. Dağıtım geçişi sırasında yinelenen bir olayı alan idempotent bir işleyici, olayı tam olarak bir kez alan bir işleyiciyle aynı çıktıyı üretir. Geri alma işleminin bir parçası olarak tekrar oynatılan idempotent bir yazma işlemi, orijinal yazma işlemiyle aynı veritabanı durumunu üretir. İdempotansiyel sadece yeniden yapılandırma sorunu değildir: dayanıklı dağıtılmış sistemlerin genel bir özelliğidir. Ancak, yokluğu en belirgin hatalara yeniden yapılandırma geçişleri sırasında neden olur.

Büyük Bir Yeniden Yapılandırma Yapmadan Yeniden Deneme ve Sağlayıcı Yük Devretme Özelliği Ekleme

Bu makaledeki Arama Konsolu verilerinde en sık sorulan sorulardan biri, özellikle Rails veya benzeri bir çerçeve uygulaması olmak üzere mevcut bir uygulamaya kapsamlı bir yeniden yapılandırma çabası göstermeden yeniden deneme ve arıza durumunda yedekleme özelliklerinin nasıl eklenebileceğidir. Cevap şudur: Yeniden deneme ve arıza durumunda yedekleme, bireysel hizmet uygulamalarını değiştirmeden altyapı katmanında genel bir unsur olarak eklenebilir.

Altyapı katmanında, Istio veya Linkerd gibi bir servis ağı, tanımlanmış bir yeniden deneme sayısına kadar, başarısız istekleri otomatik olarak yeniden denemek üzere yapılandırılabilir; bu işlemde, aşırı isteklerden kaçınmak için üstel geri çekilme ve titreşim (jitter) kullanılır. Bu, uygulama kodunda herhangi bir değişiklik gerektirmez çünkü yeniden deneme davranışı, gelen ve giden tüm istekleri yakalayan yan proxy'de uygulanır. Sağlayıcı arıza durumunda devralma da benzer şekilde uygulanabilir: birincil sağlayıcı eşik oranının üzerinde bir hata döndürürse, ağ, birincil sağlayıcı düzelene kadar sonraki istekleri ikincil bir sağlayıcıya yönlendirir.

Uygulama katmanında, altyapı düzeyindeki yeniden denemeler yetersiz kaldığında, çünkü yeniden deneme mantığının iş durumunun farkında olması gerektiğinden, uygulamayı dahili olarak yeniden yapılandırmadan, uygulama ile harici bağımlılıklar arasındaki sınıra hafif bir yeniden deneme kütüphanesi veya iş kuyruğu eklenebilir. Buradaki kilit nokta, yeniden deneme ve arıza durumunda devralma mantığını iş mantığı katmanına dağıtmak yerine entegrasyon sınırına izole etmektir. Bu, yeniden deneme davranışını, temel uygulama yapısına dokunmadan görünür, test edilebilir ve yapılandırılabilir hale getirir. Daha önce tartışıldığı gibi, çevik yeniden yapılandırma uygulamalarıİş mantığını yeniden düzenlemeden önce altyapı düzeyinde güvenilirlik kalıplarını uygulamak, her değişiklikten sonra doğrulanması gereken alanın kapsamını azaltır.

Redis Streams ile Olay Odaklı Mimari Yapılarda İdempotans

Redis Streams veya benzer teknolojileri kullanan düşük gecikmeli olay odaklı mimariler, yeniden yapılandırma sırasında belirli bir tekrarlanabilirlik sorunuyla karşı karşıya kalır: tüketici grupları olayları farklı hızlarda işleyebilir, yeni sürüm altında olayları okuyan tüketici, eski sürümün işlemediği olayları zaten işlemiş olabilir ve tekrar oynatma veya kurtarma işlemleri, aynı olayı, kopyaları işlemek üzere tasarlanmamış işleyicilere birden fazla kez iletebilir.

Standart yaklaşım, yayın anında her olaya benzersiz bir tanımlayıcı atamak ve işlenmiş olay tanımlayıcılarını kalıcı bir depoda izlemektir. Bir olayı işlemeden önce, işleyici tanımlayıcının daha önce işlenip işlenmediğini kontrol eder. İşlenmişse, olay onaylanır ve yeniden işlenmeden atılır. İşlenmemişse, olay işlenir ve tanımlayıcı kaydedilir. Bu tekilleştirme mantığı atomik olmalıdır: işleyici olayı işler ancak tanımlayıcıyı kaydetmeden önce başarısız olursa, olay bir sonraki teslimatta yeniden işlenecektir. Redis atomik işlemlerini veya işlemsel yazmaları kullanarak tanımlayıcıyı işleme işleminin bir parçası olarak kaydetmek, bu yarış durumunu önler.

Tüketici mantığının değiştiği bir yeniden yapılandırma geçişi sırasında, idempotentlik tanımlayıcıları ek bir avantaj sağlar: olay akışını yeni tüketici mantığına karşı yeniden oynatmayı ve çıktıları eski tüketici mantığının kaydedilmiş çıktılarıyla karşılaştırmayı mümkün kılarak, kullanıcıları yeni mantığa maruz bırakmadan karşılaştırmalı test yapılmasına olanak tanır.

CI/CD İşlem Hatlarında Yeniden Yapılandırmanın Otomasyonu

Sıfır kesinti süresiyle yeniden yapılandırma disiplini, manuel süreçlerle sürdürülemez. Sıfır kesinti süresi programındaki her dağıtım, bir dizi doğrulama gerektirir: yeni sürümün mevcut veritabanı durumuyla uyumlu olup olmadığını kontrol eden dağıtım öncesi kontroller, her trafik yüzdesi artışında kademeli kontroller, eski ve yeni kod yolları arasındaki çıktıların otomatik karşılaştırılması ve temel metriklerin bozulmadığını doğrulayan dağıtım sonrası doğrulama. Bu adımları her değişiklik için manuel olarak gerçekleştirmek operasyonel olarak sürdürülebilir değildir ve sürecin en kritik noktalarında insan hatasına yol açar.

Sıfır kesinti süresiyle yeniden yapılandırma için bir CI/CD işlem hattı, yalnızca bir derleme ve dağıtım işlem hattı değildir. Bu bir doğrulama işlem hattıdır: bir değişikliğin dağıtımın bir sonraki aşamasına geçmeden önce geçmesi gereken otomatikleştirilmiş bir dizi kontrol noktası. Her kontrol noktası, belirli, ölçülebilir bir kriterdir. Bir kontrol noktasından geçememek işlem hattını durdurur ve bir uyarı tetikler. Tüm kontrol noktalarından geçmek, dağıtımı otomatik olarak bir sonraki aşamaya taşır. Daha geniş kapsamlı tartışmada açıklandığı gibi, Ana bilgisayar ve kurumsal ortamlar için CI/CD uygulamalarıTemel gereklilik, işlem hattının, büyüklüğünden bağımsız olarak her değişiklik için aynı dağıtım disiplinini uygulaması ve bu uygulamanın bireysel mühendislerin dikkatine bağlı olmak yerine otomatikleştirilmiş olmasıdır.

Canlı Yeniden Yapılandırma için Boru Hattı Aşama Kapıları

Aşama kapıları, bir dağıtımın ilerlemeden önce geçmesi gereken doğrulama kontrol noktalarıdır. Sıfır kesinti süresiyle çalışan bir yeniden yapılandırma işlem hattı için minimum aşama kapıları aşağıdaki gibidir.

Dağıtım öncesi: şema uyumluluk kontrolü, veritabanı geçişinin uygulamanın mevcut sürümüyle geriye dönük uyumlu olduğunu doğrular; otomatik sözleşme testleri, yeni sürümün API yanıtlarının önceki sürümün sözleşmesiyle uyumlu olduğunu doğrular; ve statik bağımlılık analizi, yeni sürümün getirdiği hiçbir bağımlılığın mevcut ortamın gerektirdiği bir bağımlılıkla çakışmayacağını doğrular.

Dağıtım sonrası canary aşamasına geçiş: canary ve temel trafik arasındaki hata oranı karşılaştırması, p50, p95 ve p99'daki gecikme karşılaştırması, değiştirilen kod yolunun etkilediği herhangi bir metrik için iş metriği karşılaştırması ve trafik yüzdesinin artırılmadan önce canary aşamasının stabil kalması gereken minimum gözlem süresi.

Tam dağıtım sonrası: üretim uç noktalarına karşı regresyon test paketi, çift yazma veya genişletme-daraltma geçişlerinin tutarlılığını koruduğunu doğrulayan veritabanı tutarlılık kontrolleri ve önceki dağıtım yapısının geri alma için kullanılabilir durumda olduğunun doğrulanması.

Uyumluluk Odaklı Yeniden Yapılandırma ve Uygulama

Uyumluluk odaklı yeniden yapılandırma, işlem hattı kapılarının uygulaması gereken ek bir kısıtlama getirir: her değişiklik, geçerli düzenleyici veya kurumsal politika gereklilikleriyle kanıtlanabilir şekilde tutarlı olmalıdır. Düzenlemeye tabi sektörlerde bu, dağıtım işlem hattının neyin değiştirildiğini, ne zaman dağıtıldığını, hangi doğrulamanın yapıldığını ve kimin onayladığını gösteren bir denetim izi oluşturması gerektiği anlamına gelir. Giriş durumu, kapı kriterleri ve geçme/kalma sonucu da dahil olmak üzere kendi yürütmelerini kaydeden otomatik işlem hattı kapıları, manuel dokümantasyon çabası olmadan bu denetim izini sağlar.

Bu makalenin Arama Konsolu verilerinde sorgu olarak görünen, ekip genelinde uygulama yeteneklerine sahip akıllı yeniden düzenleme platformları, uyumluluk doğrulamasını yeniden düzenleme iş akışına entegre eden araçlardır: yeniden düzenleme kalıplarının ekipler arasında tutarlı bir şekilde uygulanmasını, kullanımdan kaldırılmış arayüzlerin yeniden tanıtılmamasını ve yapısal değişikliklerin kuruluş düzeyinde tanımlanan mimari standartlara uygun olmasını sağlarlar. Bu yetenekler, yalnızca derlenip testlerden geçip geçmediğini değil, değiştirilen kodun anlamını da anlamayı gerektirdiğinden, tek başına bir CI/CD hattının sağladığının ötesine geçer.

Ana Bilgisayar ve CICS Sistemlerinin Kesintisiz Yeniden Yapılandırılması

Ana bilgisayar ortamları, yapılandırma kısıtlamaları yapısal olduğundan, sıfır kesinti süresiyle yeniden yapılandırmanın en zorlu versiyonunu sunar. Bir CICS işlem programı, yeni bir konteyner imajı dağıtarak ve yük dengeleyiciyi değiştirerek değiştirilemez. CICS'te program değiştirme, programın yeni bir sürümünü belleğe yükleyen bir NEWCOPY veya PHASEIN komutu gerektirir. NEWCOPY, eski sürümü hemen değiştirir ve komut çalıştırıldıktan sonra başlayan tüm işlemleri etkiler. PHASEIN, eski sürümü kullanan tüm aktif işlemlerin tamamlanmasını bekler ve ardından değiştirir; bu da uzun süren işlemler için daha temiz bir geçiş sağlar.

Her iki mekanizma da anında geri alma imkanı sağlamaz. Programın yeni sürümünde bir hata varsa, eski sürüme geri dönmek için önceki yükleme modülüyle NEWCOPY veya PHASEIN komutunun yeniden verilmesi gerekir. Bu, önceki yükleme modülünün yükleme kütüphanesinde saklanmasını ve geri alma prosedürünün belgelenmesini, prova edilmesini ve orijinal geliştiriciye gerek kalmadan nöbetçi ekip tarafından yürütülebilir olmasını gerektirir.

Paylaşılan VSAM dosyaları ek bir kısıtlama getirir. Birden fazla CICS işlemi ve toplu iş programı aynı VSAM dosyasına eş zamanlı olarak erişebilir. Dosyanın düzeninde yapısal bir değişiklik, örneğin bir kayıt segmentinin eklenmesi veya genişletilmesi, dosyaya erişen tüm programların düzen değişikliğinden önce veya eş zamanlı olarak güncellenmesini veya dosyanın geçiş döneminde birden fazla kayıt biçimini desteklemesini gerektirir. Bu, ana bilgisayardaki genişletme-daraltma modelinin karşılığıdır: yeni düzen, geçiş sırasında eski programlarla uyumlu olmalı ve eski programlar, eski düzen kullanımdan kaldırılmadan önce güncellenmelidir. Veri kümesi düzenlerinin ve program erişim parametrelerinin kontrollü genişletilmesi, dosya değiştirme olmadan bu uyumlu birlikte varoluşu mümkün kılan mekanizmadır.

Toplu Pencere Eleme Stratejileri

Geleneksel ana bilgisayar toplu işleme, bir toplu işlem penceresinin varlığını varsayar: çevrimiçi işlem işlemenin askıya alındığı, toplu işlerin çekişme olmadan çalıştığı ve elde edilen verilerin bir sonraki çevrimiçi işleme dönemi için hazır olduğu bir süre. Gerçek sıfır kesinti süresiyle çalışma için gerekli olan toplu işlem penceresinin ortadan kaldırılması, toplu işlerin paylaşılan verileri bozmadan çevrimiçi işlemlerle eş zamanlı olarak çalışabilmesi için toplu işleme modelinin yeniden tasarlanması anlamına gelir.

Standart yaklaşımlar, dosya düzeyinde değil kayıt düzeyinde kaynak düzeyinde kilitleme, büyük iş yüklerini periyodik olarak değil, küçük iş yüklerini sürekli olarak işleyen olay odaklı mini toplu işleme ve yazma erişimi için çevrimiçi işlem işlemeyle rekabet etmeden toplu raporlama iş yüklerine hizmet eden okuma-çoğaltma veritabanlarıdır. Bu yaklaşımların her biri hem programlarda hem de veri erişim modellerinde değişiklikler gerektirir, ancak hiçbiri geçiş sırasında toplu işlem penceresinin yerinde kalmasını gerektirmez: geçişin kendisi, diğer herhangi bir canlı sistem yeniden yapılandırması için kullanılan aynı çift çalıştırma doğrulama yaklaşımı kullanılarak aşamalandırılabilir.

Etki Analizi Kullanarak COBOL Programının Yeniden Yapılandırılması

Bir COBOL programını güvenli bir şekilde yeniden düzenlemek, herhangi bir değişiklik yapmadan önce, hangi diğer programların onu çağırdığını, hangi copybook'ları diğer programlarla paylaştığını, hangi veri kümelerini okuyup yazdığını ve hangi alt sistemlerin ürettiği verilere bağımlı olduğunu tam olarak bilmeyi gerektirir. Bu yapısal bilgi olmadan, programda yapılacak herhangi bir değişiklik bilinmeyen riskler taşır: yeniden düzenlenmiş program, tanımlanmamış bir çağırıcıyı bozabilir, alt sistemin ayrıştıramayacağı bir biçimde çıktı üretebilir veya aynı copybook'u içeren diğer programları etkileyecek şekilde paylaşılan bir veri yapısını değiştirebilir.

Otomatik etki analizi, yeniden düzenleme başlamadan önce COBOL programının eksiksiz bir bağımlılık grafiğini oluşturarak bu sorunu çözer. Grafik, ilişki türüne ve belirli referans konumuna göre düzenlenmiş her çağırıcıyı, her paylaşılan copybook'u, her veri kümesi erişimini ve her alt düzey tüketiciyi gösterir. Yeniden düzenleme planı daha sonra etki grafiğinden türetilir: değiştirilen programı çağıran programlar yeni sürüme karşı test edilmeli, değiştirilen copybook'lar bunları içeren tüm programlara karşı doğrulanmalı ve değişen veri kümesi düzenleri aynı veri kümelerine erişen tüm programlara karşı doğrulanmalıdır. Açıklandığı gibi, etki analizi çözümleri IN-COM'un sağladığı bu özellik, sonuçlarını dağıtımdan sonra keşfeden bir yeniden yapılandırma programı ile bunları dağıtımdan önce ölçen bir program arasındaki farkı oluşturur.

Doğrulama, Geri Alma ve Gözlemlenebilirlik

Sıfır kesinti süresiyle yeniden yapılandırma, sürekli olarak izlenmesi gereken sürekli bir çıktı üretir. İzleme, her şeyin yolunda gittiğini sonradan kontrol eden bir işlem değildir: dağıtım sürecinin her aşamasında aktif bir kontrol noktasıdır ve sorunları kullanıcı etkisini önleyecek kadar erken tespit etmenin birincil mekanizmasıdır.

Sıfır kesinti süresiyle yeniden yapılandırma için doğrulama modeli üç katmandan oluşur. Birincisi sentetik izleme: Kullanıcı davranışını simüle eden ve üretim ortamında sürekli olarak çalışan, temel akışların başarıyla tamamlandığını doğrulayan betiklenmiş işlemler. Sentetik izleyiciler, gerçek kullanıcıların düşük trafik dönemlerinde kullanmayabileceği belirli kod yollarında meydana gelen hataları yakalar ve canary sonuçlarının karşılaştırılabileceği bir davranış temeli sağlar.

İkinci katman ise diferansiyel izlemedir: hata oranları, gecikme dağılımları, iş metrikleri ve kaynak tüketimi de dahil olmak üzere, test sürümü ile temel sürüm arasındaki metriklerin gerçek zamanlı karşılaştırılması. Diferansiyel izleme mutlak eşikler gerektirmez: göreceli karşılaştırma gerektirir. Mutlak hata oranının herhangi bir tanımlanmış eşiği aşıp aşmadığına bakılmaksızın, temel sürüme göre yüzde iki daha yüksek hata oranı gösteren bir test sürümü sorun teşkil eder.

Üçüncü katman, veri tutarlılığı doğrulamasıdır. Çift yazma, şema geçişleri veya paralel sistem çalıştırmaları içeren herhangi bir yeniden yapılandırmada, eski ve yeni gösterimler arasındaki veri tutarlılığı sürekli olarak doğrulanmalıdır. Sağlama toplamı karşılaştırmaları, kayıt sayısı karşılaştırmaları ve belirli alan değerlerini beklenen dönüşümlere karşı doğrulayan nokta kontrol sorguları, veri katmanının geçiş sırasında doğru şekilde davrandığına dair güvene katkıda bulunur. Bu bağlamda incelendiğinde, Etki analizi nedir ve neden önemlidir?Yapılandırılmış yeniden yapılandırmayı spekülatif değişiklikten ayıran şey, bir değişikliğin sonuçlarını tanımlanmış bir beklenti kümesine göre doğrulama yeteneğidir.

Anında Geri Alma Mekanizmaları

Yürütülmesi otuz dakika süren bir geri alma planı, sıfır kesinti süresi olan bir sistem için geçerli bir geri alma planı değildir. Tamamlandığında, kullanıcılara otuz dakika boyunca düşük performanslı hizmet sunulmuş olur. Anında geri alma, her dağıtımın baştan itibaren geri alınabilir olacak şekilde tasarlanmasını gerektirir; bir sorun ortaya çıktığında sonradan uyarlanmamalıdır.

Uygulama dağıtımları için anlık geri alma, önceki dağıtım dosyasının kullanılabilir, önceden ısıtılmış ve aynı veritabanı durumuna işaret edecek şekilde saklanması anlamına gelir. Önceki sürüme geri dönmek için gereken tek işlem, yük dengeleyici veya API ağ geçidi kuralı değişikliği yoluyla trafik yönlendirmesi olmalıdır. Bu, veritabanı durumu önceki sürümle geriye dönük uyumlu olduğunda mümkündür; bu da veritabanı geçiş katmanındaki genişletme-daraltma disipliniyle garanti edilir.

Veritabanı geçişlerinde, anında geri alma işlemi, genişletme aşamasında uygulanan her geçişin veri kaybı olmadan geri alınabilir olmasını gerektirir. Genişletme aşamasında eklenen bir sütun, geri alma işleminde silinebilir. Veri kaybına yol açacak şekilde değiştirilen bir sütun, yedekleme olmadan geri yüklenemez. Bu nedenle, sütunları silen, türleri uyumsuz şekillerde değiştiren veya hassasiyeti azaltan yıkıcı şema değişiklikleri, yeni sürüm tamamen dağıtılıp doğrulanana ve eski sürüm tamamen kullanımdan kaldırılana kadar asla uygulanmamalıdır.

Ne kadar SMART TS XL Kesintisiz Yeniden Yapılandırma Programlarını Destekler

SMART TS XL Bu platform, sıfır kesinti süresiyle gerçekleştirilen her yeniden yapılandırma başarısızlığının altında yatan yapısal görünürlük sorununu ele alıyor: ekiplerin, bu sistemlerin ne içerdiğine, neyin neye bağlı olduğuna ve planlanan her değişikliğin sonuçlarının ne olacağına dair eksiksiz bir resme sahip olmadan canlı sistemleri yeniden yapılandırmaya çalışması. Platform, COBOL, JCL, Java, .NET, Python, JavaScript ve SQL dahil olmak üzere ortamdaki her dil ve platformdan kaynak kodunu alır ve tüm sistemin yapısal ilişkilerini temsil eden birleşik bir çapraz referans modeli oluşturur.

Yeniden yapılandırma değişikliği yapılmadan önce, SMART TS XLEtki analizi yeteneği, değiştirilen bileşenden başlayarak her çağırıcıya, her paylaşılan veri yapısına, her alt düzey tüketiciye ve değişiklikten etkilenecek her programa kadar bağımlılık grafiğini izler. Sonuç, genel bir risk değerlendirmesi değil, ciddiyet ve bileşene göre düzenlenmiş, belirli, numaralandırılmış bir sonuç listesidir. Bu liste, sıfır kesinti süresiyle yeniden yapılandırma dizisini doğru bir şekilde planlamayı mümkün kılar: değiştirilen bileşen dağıtılmadan önce hangi tüketicilerin güncellenmesi gerektiğini, hangi veritabanı geçişlerinin hangi uygulama dağıtımlarından önce sıralanması gerektiğini ve eski sürüm devre dışı bırakılmadan önce hangi alt düzey sistemlerin doğrulanması gerektiğini bilmek.

SMART TS XLKod görselleştirme özelliği, yeniden yapılandırılan sistemin her katmanına derinlemesine aşina olmayan ekipler için bağımlılık grafiğini gezilebilir hale getirir. Mimarlar, bağlantı yapısını yeniden tasarlamadan önce bileşenlerin nasıl bağlandığını görebilirler. Geliştiriciler, imzasını değiştirmeden önce bir fonksiyonu neyin çağırdığını görebilirler. Operasyon ekipleri, düzenini değiştirmeden önce bir veri kümesinin ne tarafından kullanıldığını görebilirler. Bu görünürlük, sıfır kesinti süresi gerektiren yapılandırılmış, geri alınabilir, aşamalı yeniden yapılandırma programının ön koşuludur.

Kesintisiz Yeniden Yapılandırma, Sürekli Bir Uygulama Olarak

Bu kılavuzdaki teknikler tek seferlik müdahaleler değildir. Bunlar, üretim sistemlerini periyodik olarak değiştirilmek yerine sürekli gelişen sistemler olarak ele almaya karar vermiş bir geliştirme organizasyonunun operasyonel terminolojisidir. Mavi-yeşil dağıtımlar, kademeli sürüm yayınları, özellik geçişleri, genişletme-daraltma geçişleri, boğucu şekil çıkarma işlemleri, tekrarlanabilir olay işleme ve işlem hattı tarafından uygulanan dağıtım kapıları acil durum prosedürleri değildir: bunlar, yapısal değişiklikleri yüksek sıklıkta güvenli bir şekilde yayınlayan bir ekibin standart işletim prosedürleridir.

Bu duruma ulaşmak, bireysel yeniden yapılandırma girişimlerinin ötesine geçen araçlara, altyapıya ve organizasyonel uygulamalara yatırım yapılmasını gerektirir. Araçlar, bağımsız dağıtım olanağını, gözlemlenebilir durum geçişlerini ve anında geri almayı desteklemelidir. Altyapı, trafik bölme, mavi-yeşil ortamlar ve CDC tabanlı veri senkronizasyonunu desteklemelidir. Organizasyonel uygulama, dağıtım öncesi etki analizini, dağıtım sonrası fark izlemeyi ve geri alma yolunun gerçekçi koşullar altında çalıştığını doğrulayan düzenli geri alma tatbikatlarını içermelidir.

Bu yatırımı yapan kuruluşlar, uygulama olgunlaştıkça değişiklik başına maliyetin azaldığını görüyor: destekleyici altyapı zaten mevcut olduğundan, ekip hangi değişiklikler için hangi eşiklerin uygun olduğuna dair bir yargı geliştirdiğinden ve araçlardaki birikmiş yapısal bilgi sayesinde her ardışık yeniden yapılandırma bir öncekinden daha az risklidir. SMART TS XL Bu, planlanan her değişikliği bir öncekinden daha kesin bir kapsamda gerçekleştirir. Sıfır kesinti süresiyle yeniden yapılandırmanın amacı, tek bir değişikliği güvenli bir şekilde yapmak değildir. Amaç, her değişikliği güvenli bir şekilde, sürekli olarak ve kullanıcıların bakım penceresini kabul etmelerini istemeden yapmaktır.