Güvenli dağıtım uygulamaları

Bazen bir sürüm beklentileri karşılamıyor. En iyi yöntemlerin kullanılmasına ve tüm kalite geçitlerinin geçirilmesine rağmen, bazen üretim dağıtımının kullanıcılar için öngörülemeyen sorunlara neden olmasına neden olan sorunlar vardır. Bu sorunların etkisini en aza indirmek ve azaltmak için DevOps ekiplerinin, belirli bir sürümün maruz kalmasını kanıtlanmış performansıyla dengeleyen aşamalı bir pozlama stratejisi benimsemeleri önerilir. Bir sürüm üretimde kendini kanıtladıkça, herkes kullanana kadar daha geniş kitlelerin katmanları için kullanılabilir hale gelir. Teams, üretimdeki yayınların kalitesini ve hızını en üst düzeye çıkarmak için güvenli dağıtım uygulamalarını kullanabilir.

Müşterilerin maruz kalmasını denetleme

DevOps ekipleri, güncelleştirmelerin müşterilere açık olmasını denetlemek için çeşitli uygulamalar kullanabilir. Geçmişte, hizmet veya kullanıcı arabiriminin farklı sürümlerinin hedef hedeflere karşı nasıl performans sergilediğini görmek isteyen ekipler için A/B testi popüler bir seçimdi. A/B testi de nispeten kolaydır çünkü değişiklikler genellikle küçük olur ve genellikle bir hizmetin müşteriye yönelik kenarındaki farklı sürümleri karşılaştırır.

Halkalar aracılığıyla dağıtımı Kasa

Platformlar büyüdükçe altyapı ölçeği ve hedef kitle gereksinimleri de büyümeye eğilimlidir. Bu, yeni bir dağıtımla ilişkili riskleri söz verdiği güncelleştirmelerin avantajlarıyla dengeleyen bir dağıtım modeline yönelik bir talep oluşturur. Genel fikir, belirli bir sürümün ilk olarak yalnızca risk için en yüksek toleransa sahip küçük bir kullanıcı grubuna açık olması gerektiğidir. Ardından, sürüm beklendiği gibi çalışıyorsa daha geniş bir kullanıcı grubuna gösterilebilir. Herhangi bir sorun yoksa, herkes yeni sürümü kullanana kadar işlem daha geniş kullanıcı grupları veya halkalar aracılığıyla devam edebilir. GitHub Actions ve Azure Pipelines gibi modern sürekli teslim platformları ile halkalarla dağıtım süreci oluşturmak, her boyuttaki DevOps ekipleri tarafından erişilebilir.

Özellik bayrakları

Bazı işlevlerin bazen bir sürümün parçası olarak dağıtılması gerekir, ancak başlangıçta kullanıcılara sunulmaz. Bu gibi durumlarda özellik bayrakları, işlevselliğin ortama, halkaya veya diğer belirli dağıtımlara göre yapılandırma değişiklikleriyle etkinleştirilebileceği bir çözüm sağlar.

Kullanıcı kabul etme

Özellik bayraklarına benzer şekilde, kullanıcı kabul etme özelliği de pozlamayı sınırlamak için bir yol sağlar. Bu modelde, belirli bir özellik yayında etkinleştirilir, ancak özellikle istemediği sürece bir kullanıcı için etkinleştirilmez. Belirli güncelleştirmeleri ne kadar hızlı benimsemek istediklerine karar verebilmeleri için risk toleransı kararı kullanıcılara yüklenir.

Aynı anda birden çok uygulama kullanılır. Örneğin, bir ekibin çok belirli bir kullanım örneğine yönelik deneysel bir özelliği olabilir. Riskli olduğundan, şirket içi kullanıcıların denemesi için ilk kademeye dağıtırlar. Ancak, özellikler kodda olsa bile, bir kişinin özellik kullanıcı arabirimi aracılığıyla kullanıma sunulacak şekilde halka içindeki belirli bir dağıtım için özellik bayrağını ayarlaması gerekir. Bu durumda bile özellik bayrağı yalnızca kullanıcının yeni özelliği kullanmayı kabul etme seçeneğini kullanıma sunabilir. Halkada, bu dağıtımda olmayan veya kabul etmeyen herkes bu özelliğe maruz kalmaz. Bu oldukça karmaşık bir örnek olsa da, aşamalı maruz kalma esnekliğini ve pratikliğini göstermeye hizmet eder.

Ekiplerin erken saatlerde karşılaştığı yaygın sorunlar

Ekipler daha çevik bir DevOps uygulamasına doğru ilerledikçe, geleneksel monolitik teslimatlardan uzaklaşmış olan diğer kişilerle tutarlı sorunlarla karşılaşabilir. Birkaç ayda bir dağıtım yapmak için kullanılan ekiplerin kararlı hale getirmek için arabelleğe alınan bir zihniyetleri vardır. Her dağıtımın hizmetlerinde önemli bir değişiklik yapmasını ve öngörülemeyen sorunlar olmasını beklerler.

Yük çok büyük

Birkaç ayda bir dağıtılan hizmetler genellikle birçok değişiklikle doldurulur. Bu, anında sorunlarla karşılaşılma olasılığını artırır ve çok fazla yeni şey olduğundan bu sorunları gidermeyi zorlaştırır. Daha sık yapılan teslimatlara geçerek dağıtılanlar arasındaki farklar küçülerek daha odaklanmış testlere ve daha kolay hata ayıklamaya olanak tanır.

Hizmet yalıtımı yok

Monolitik sistemler, dağıtıldıkları donanımın düzeyi artırılarak geleneksel olarak ölçeklendirilir. Ancak örnekte bir sorun oluştuğunda herkes için sorunlara yol açar. Basit çözümlerden biri, kullanıcıları yük dengelemek için birden çok örnek eklemektir. Ancak, birçok eski sistem çok örnekli olacak şekilde derlenmemiş olduğundan, bu önemli mimari konuları gerektirebilir. Ayrıca, başka bir yerde daha iyi birleştirilebilen işlevler için önemli yinelenen kaynakların ayrılması gerekebilir.

Yeni özellikler eklendikçe, mikro hizmet mimarisinin daha iyi hizmet yalıtımı sayesinde çalışmanıza ve ölçeklendirmenize yardımcı olup olmadığını keşfedin.

El ile uygulanan adımlar hatalara yol açar

Bir ekip yılda yalnızca birkaç kez dağıtım yaparken, teslimatları otomatikleştirmek yatırıma değmeyebilir. Sonuç olarak, birçok dağıtım işlemi el ile yönetilir. Bu önemli miktarda zaman ve çaba gerektirir ve insan hatasına açıktır. En yaygın derleme ve dağıtım görevlerini otomatikleştirmek, kayıp zamanı ve uygulanamayan hataları azaltmaya yönelik uzun bir yol kat edebilir.

Teams, dağıtım ortamları üzerinde daha iyi denetim sahibi olmak için kod olarak altyapıyı da kullanabilir. Bu, çeşitli dağıtım ortamlarında yeni özellikler veya bağımlılıklar kullanıma sunulduğundan, operasyon ekibine el ile değişiklik yapma isteği gereksinimini ortadan kaldırır.

Dağıtımları yalnızca Ops yapabilir

Bazı kuruluşlar, tüm dağıtımların operasyon personeli tarafından başlatılmasını ve yönetilmesini gerektiren ilkelere sahiptir. Geçmişte bunun için iyi nedenler olsa da, geliştirme ekibinin dağıtımları başlatıp denetleyebildiği durumlarda Çevik DevOps süreci büyük ölçüde avantaj sağlar. Modern sürekli teslim platformları, kimlerin hangi dağıtımları başlatabileceği ve kimlerin durum günlüklerine ve diğer tanılama bilgilerine erişebileceği üzerinde ayrıntılı denetim sağlar ve doğru kişilerin doğru bilgilere mümkün olan en kısa sürede sahip olduğundan emin olur.

Hatalı dağıtımlar devam eder ve geri alınamaz

Bazen bir dağıtım yanlış gider ve ekiplerin bu sorunu gidermesi gerekir. Ancak, işlemler el ile yapıldığında ve bilgilere erişim yavaş ve sınırlı olduğunda, önceki bir çalışma dağıtımına geri dönmek zor olabilir. Neyse ki, başarısız dağıtım riskini azaltmaya yönelik çeşitli araçlar ve uygulamalar vardır.

Temel ilkeler

Güvenli dağıtım uygulamalarını benimsemek isteyen ekiplerin bu çabayı temel alan bazı temel ilkeler belirlemesi gerekir.

Tutarlı olun

Üretim ortamında dağıtmak için kullanılan araçlar geliştirme ve test ortamlarında kullanılmalıdır. Bağımlılıkların veya araçların yeni sürümlerinden kaynaklanan sorunlar gibi sorunlar varsa, kod üretime sunulmaya yaklaşılmadan önce iyi yakalanmalıdır.

Kalite sinyallerine dikkat edin

Çok fazla takım, kalite sinyallerini gerçekten önemsememe tuzağına düşer. Zamanla, sarı bir uyarıyı yeşil onay olarak değiştirmek için test yazdıklarını veya kalite görevlerini üstlendiğini fark edebilir. Kalite sinyalleri, bir projenin nabzını temsil ettikleri için gerçekten önemlidir. Dağıtımları onaylamak için kullanılan kalite sinyalleri her gün sürekli izlenmelidir.

Dağıtımlar sıfır kapalı kalma süresi gerektirmelidir

Her hizmetin her zaman kullanılabilir olması kritik olmasa da, ekiplerin DevOps teslim ve işlem aşamalarına, yeni sürümleri herhangi bir zamanda indirebilmek zorunda kalmadan dağıtabilecekleri ve dağıtabilecekleri düşünce yapısıyla yaklaşması gerekir. Modern altyapı ve işlem hattı araçları, neredeyse tüm ekiplerin %100 çalışma süresini hedeflemesi için uygun olan yeterince gelişmiştir.

Dağıtımlar çalışma saatlerinde gerçekleşmelidir

Ekip, dağıtımların sıfır kapalı kalma süresi gerektirdiği zihniyetiyle çalışıyorsa, bir dağıtımın ne zaman gönderilip gönderilmediği önemli değildir. Ayrıca, özellikle günün erken saatlerinde ve haftanın erken saatlerinde dağıtımların gönderilmesi avantajlı hale gelir. Bir sorun olursa patlama yarıçapını kontrol edecek kadar erken izlenmelidir. Ayrıca, herkes zaten çalışır ve sorunları düzeltmeye odaklanır.

Halka tabanlı dağıtım

Olgun DevOps sürüm uygulamalarına sahip ekipler halka tabanlı dağıtıma alınacak bir konumdadır. Bu modelde, yeni özellikler ilk olarak en fazla riski kabul etmeye istekli müşterilere dağıtılır. Dağıtım kanıtlandığından, herkes kullanana kadar hedef kitle daha fazla kullanıcı içerecek şekilde genişler.

Örnek halka modeli

Tipik bir halka dağıtım modeli, kullanıcıları ve altyapıyı dikkatli bir şekilde segmentlere ayırma yoluyla sorunları mümkün olan en erken zamanda bulmak için tasarlanmıştır. Aşağıdaki örnekte, halkaların Microsoft'taki büyük bir ekip tarafından nasıl kullanıldığı gösterilmektedir.

Pişirme zamanına izin ver

Pişirme zamanı terimi, bir dağıtımın sonraki halkaya genişletilmeden önce çalışmasına izin verilen süreyi ifade eder. Bazı sorunların belirtileri göstermeye başlaması saatler veya daha uzun sürebilir, bu nedenle yayın hazır olarak kabul edilmeden önce uygun bir süre kullanımda olmalıdır.

Genel olarak, 24 saatlik bir gün çoğu senaryo için gizli hataları ortaya çıkarmak için yeterli zaman olmalıdır. Ancak bu süre, iş saatlerinde en yoğun olan hizmetler için tam iş günü gerektiren en yoğun kullanım süresini içermelidir.

Düzeltmeleri hızlandır

Bir hata üretimde ciddi bir etkiye sahip olduğunda canlı site olayı (LSI) oluşur. LSI'ler, yüksek öncelikli bir sorunu gidermek için tasarlanmış bant dışı bir güncelleştirme olan bir düzeltme oluşturulmasını gerektirir.

Bir hata en ciddi hata türü olan Önem Derecesi 0 ise, düzeltme doğrudan etkilenen ölçek birimine mümkün olduğunca hızlı bir şekilde dağıtılabilir. Düzeltmenin işleri daha kötü hale getirmemesi kritik olsa da, bu önem derecesine sahip hataların hemen ele alınması gereken kadar kesintiye neden olduğu kabul edilir.

Önem Derecesi 1 olan hataların halka 0 üzerinden dağıtılması gerekir, ancak onaylanan en kısa sürede etkilenen ölçek birimlerine dağıtılabilir.

Daha düşük önem derecesinde hatalar için düzeltmelerin planlandığı gibi tüm halkalar aracılığıyla dağıtılması gerekir.

Önemli temel bilgiler

Her ekip güncelleştirmeleri hızlı ve mümkün olan en yüksek kalitede sunmak istiyor. Doğru uygulamalarla teslim, DevOps döngüsünün üretken ve sorunsuz bir parçası olabilir.

• Sık sık dağıtın.
• Sprint boyunca yeşil kalın.
• Geliştirme, test ve üretimde tutarlı dağıtım araçlarını kullanın.
• Otomasyona ve yetkilendirmeye izin veren sürekli bir teslim platformu kullanın.
• Güvenli dağıtım uygulamalarını izleyin.

Sonraki adımlar

Özellik bayraklarının yeni özelliklerin kullanıcılara açık olmasını denetlemeye nasıl yardımcı olduğunu öğrenin.