Operasyonel Mükemmellik yolculuğu, sürekli iyileşme prensibi üzerine kurulu olup, her aşama iş yükü tasarımı, uygulama ve desteği genelinde daha fazla etkinlik ve verimlilik sağlamak için bir önceki aşamanın üzerine katmanlar ekler.
Temel olarak dağıtım, izleme, test ve otomasyon gibi temel uygulamaları basitleştirmeyle ilgilidir. Yolculuk güçlü bir temelle başlar: paylaşılan bir sözlük, standartlaştırılmış uygulamalar ve işbirliği ve kararlılığı teşvik eden bir DevOps zihniyeti. Buradan standartlaştırma, süreçlere tutarlılık ve öngörülebilirlik sağlar. Ekipler daha becerikli hale gelince, tek tek görevler otomatik test, akıllı izleme ve sürekli tümleştirme gibi üretime hazır özelliklerle desteklenen tümleşik iş akışlarına dönüşmektedir.
Sistemler üretim ortamında canlı hale geldiğinde operasyonlar daha da gelişmiş hale gelir. Ekipler, değişikliği hızlı ve güvenilir bir şekilde yönetecek, kalite karşılaştırmalarını karşılayıp ürün sahiplerinden gelen özellik isteklerini güvenle uygulayacak şekilde donatılmıştır.
En olgun aşama, iyileştirme ve yenilikle ilgilidir. Burada ekipler, değişen iş ihtiyaçlarını ve teknolojik değişimleri karşılamak için sistemleri gerçek zamanlı olarak sürekli uyarlayarak büyük ölçekte çalışır. Ancak bu sabit bir hedef değildir; bu, her zaman geliştirmenin, her zaman uyum sağlamanın dinamik bir düşünce yapısıdır.
Model, her biri birincil hedefe ve bir dizi temel stratejiye sahip beş ayrı olgunluk düzeyine yapılandırılmıştır. Anlamlı üretkenlik kazançları için en başından itibaren yapay zekanın operasyonlarınıza nereye ekleyebileceğinizi değerlendirmeye başlayın. Her düzeyi keşfetmek için aşağıdaki sekmeli görünümleri kullanın. İlerledikçe vurgulanan dengeleri ve ilişkili riskleri de gözden geçirmeyi unutmayın.
El ile, hataya açık iş yüklerini azaltmak ve ölçülebilir değer sunmak için yapay zeka temelli araçları bilerek ekleyerek işlemleri modernleştirin.
Yapay zekanın tutarlılığı ve üretkenliği nerede geliştirebileceğini belirlemek için operasyonel iş akışlarını uçtan uca değerlendirirken maliyet, risk ve değere kadar olan süreyi pragmatik olarak dengeleyebilirsiniz.
Satın alın: Kullanıma açık GenAI çözümleri
Kullanıma sunulan GenAI araçlarının yerleşik yapay zeka özellikleri vardır. Bunlar, amaca göre geniş bir şekilde kategorilere ayırılabilir. Bunlardan biri, bağlama bağımlı olan ve çeşitli görevler için kullanılabilen GitHub Copilot gibi genel, etkileşimli yardım araçlarıdır. Bu araçlar, az ya da hiç kurulum gerektirmeden doğrudan mevcut geliştirici iş akışlarına entegre edilmiş bağlamsal yardım sağlar. Diğer kategori ise belirli işlevler için tasarlanmış dağıtım aracıları, SRE aracıları gibi amaca yönelik araçlar ve aracılardır. IDE ve CLI yardımcıları aracılığıyla geliştirici üretkenliği için tümleştirilebilir.
Ek maliyetlerle birlikte gelebilen tümleşik yapay zeka özelliklerine sahip Azure hizmetleri de vardır.
GenAI: Özel uygulama ile yapı oluşturma
Özel GenAI, yapay zekayı belirli bir iş yüküne göre uyarlanmış operasyonel ve geliştirme iş akışlarına doğrudan ekler. Özel aracılar, işlemlerin güncel durumunu yansıtan içgörüler oluşturmak ve tanımlı sınırlar içinde hareket etmek için biletlerden, kod depolarından, ölçümlerden ve izleme sistemlerinden bağlamı çekebilirler.
Daha gelişmiş uygulamalar dahili standartlara göre kod veya altyapı oluşturup doğrulayabilir, uzmanlık veya kullanılabilirliğe göre çalışmayı yönlendirebilir ve özel tahminler için özel ML modelleri uygulayabilir. Bu yaklaşım, daha derin otomasyon ve kurumsal süreçlerle daha sıkı bir uyum sağlar, ancak mühendislik, veri kalitesi, idare, güvenlik ve bakım için sürekli yatırım gerektirir.
Yapay zeka işlevsel desenleri
Uygulamada kullanılan en yaygın ve ulaşılabilir yapay zeka özelliklerinden bazıları aşağıdadır, ancak bu liste kapsamlı değildir. Bunu, operasyonlarınızda üretkenlik kazanımları için yapay zekanın nereye ekleyebileceğinizi değerlendirmek için ilham kaynağı olarak kullanın.
Uyarı
Uyarlama zaman içinde planlı olarak ilerlemelidir: Özetleme veya içerik oluşturma gibi odaklanmış kullanım örnekleriyle başlayın, ardından yetenekler ve güven arttıkça görevler ve iş akışları üzerinde akıl yürüten aracı arabirimleri tanıtın. Daha yüksek olgunluk düzeylerinde, çok aracılı sistemler daha karmaşık operasyonel senaryoları desteklemek için tümleşik sistemler ve veriler arasında çalışır.
-
Özetleme. Belgelerden, raporlardan, günlüklerden veya konuşmalardan bilgileri okuyan ve daraltan, kısa özetler, önemli noktalar oluşturan, kullanıcıların anlayacağı dil ve terminolojiyi kullanan yapay zeka araçları.
-
Öneriler. Desenleri algılamak ve operasyonel kararlar için bağlama duyarlı öneriler sağlamak için birden çok veri kaynağını birlikte analiz eden yapay zeka araçları.
-
Yapıt oluşturma. Tanımlı standartlara uyarken yazılı gereksinimleri yürütülebilir koda, altyapı tanımlarına ve otomatikleştirilmiş testlere dönüştüren yapay zeka araçları.
-
İlke doğrulaması. Uyumluluğu zorlamak için ilkeleri, standartları ve tasarım belgelerini karşı kod, yapılandırma ve iş akışlarını gözden geçiren yapay zeka araçları.
-
İyileştirme eylemleri. Nesneler arasında içgörüler kullanan ve işi yönlendiren, kararlar üzerinde eylemde bulunan yapay zeka araçları.
Dikkat
Güvenceler, ajanlar dahil edildiğinde varsayımsal değildir. Denetlenmeyen bir model, bir yanlış uygulanan otomasyon veya bir aşırı izinli erişim ayarı hataları yayabilir, hassas verileri sızdırabilir veya büyük ölçekte operasyonel bütünlüğü tehlikeye atabilir.
Hassas verileri korumak için, tüm platformların kişisel olarak tanımlanabilir bilgileri (PII) maskeleme ve güvenlik ayarlamalarını sıkı bir şekilde uygulaması gerekir. Kullanıcılar yalnızca erişim yetkisine sahip oldukları çıkışları görür. Bu, yapay zeka çıktısının eksik olabileceği anlamına gelir, ancak tam görünürlük, potansiyel risklere maruz kalma pahasına elde edilebilir.
İnsan incelemesi, özellikle mimari, güvenlik ve operasyonel kaygılar için bir zorunluluk olmaya devam etmektedir. Gözden geçirmeler daha çok amaç, risk ve kuruluş standartlarıyla uyuma odaklanmalı, düşük düzeyli söz dizimine değil. İstemleri, şablonları ve standartları sürekli iyileştirmek için incelemelerden gelen geri bildirimler yakalanmalıdır.
✓ Özetleme aracıları
Özetleme aracıları genellikle basit alma ve yanıt oluşturma özelliğine sahip basit, Copilot stilinde bir mimari kullanır ve bu da bunları uygulamayı ve çalıştırmayı nispeten kolaylaştırır.
Risk: Özetleme, özellikle birden çok belge arasında sentezlenirken doğal doğruluk riski taşır. Hatalar tam olarak ortadan kaldırılamaz ancak operasyonel risk, açıklanabilirlik ve artımlı gezinti yoluyla azaltılabilir. Sistemler hangi içeriğin özetlendiğini açıkça belirtmeli ve kullanıcıların doğrulama için kaynak malzemede detaya gitmelerine izin vermelidir.
Çıkarım maliyetleri zaman içinde birikebilir. Basit istekleri daha küçük, daha düşük maliyetli modellere yönlendirin ve karmaşık çok belgeli sentez için daha gelişmiş modeller ayırarak bunun gerektirebileceği ek düzenlemeyi kabul edin. Kısa ilk özetler sağlayın ve kullanıcıların ayrıntılara ve kaynak içeriğe inmesine izin verin.
Veri yönetimi ek gizli maliyetler sağlar. Güncel olmayan belgelerin veya yedekli sürümlerin neden olduğu dizin şişkinliklerini önlemek için veri yaşam döngüsünü etkin bir şekilde yönetin. Geçmiş bağlam gerekli olduğunda, denetimsiz yineleme yerine kasıtlı sürüm oluşturma yoluyla önceki içeriği koruyun.
Doğrudan kullanıcı geri bildirimi değerlidir. Özet kalitesi ve kullanışlılığıyla ilgili girdileri yakalayın ve model yönlendirme kararlarını, dizin verimliliğini ve önbelleğe alma veya ön işleme stratejilerinin etkisini değerlendirmek için kullanın.
Örnekler
-
OE:01 DevOps kültürü. Yapılandırılmamış belgelerden eylem öğeleri, sahipler, son tarihler ve risk deyimleri gibi yapılandırılmış öğeleri ayıklayın.
-
OE:08 Olay yanıtı. Kapsam, etki ve sonuçları hızla anlamak için olayları, otopsileri, güvenlik bulgularını ve denetim raporlarını özetleyin
✓ Öneri aracıları
Öneriler sağlayan yapay zeka aracıları, birden çok veri kaynağını analiz edebilen akıl yürütme odaklı modellere dayanır. Bu modellerin basit veya tamamen üretken yaklaşımlara güvenmek yerine kaynaklar arası bağıntıyı desteklemek için yeterli analiz derinliğine sahip olması gerekir.
Tradeoff: Daha geniş kapsam değer katabilir, ancak çapraz referans verilen kaynaklar orijinal amaçla yanlış değerlendirilebilir veya hizalanmayabilir; yapay zeka tarafından oluşturulan bu tür yanıtlara aşırı bağımlılık, hataların çoğalması ve yinelemeli çağrılarla sorunun büyüme riskini taşır.
Genellikle istek başına maliyeti ve çıkarım gecikme süresini artırır. Çok sayıda ayrıntılı sorguya göre daha az, daha zengin sorgular ekleyerek dış çağrıları en aza indirin. Çalışma zamanında birden çok dış kaynağa erişmek ve bunları ilişkilendirmek pahalı olabilir, bu nedenle veri erişimini paralelleştirin ve mümkün olduğunda verileri paylaşılan dizinlere önceden yükleyin.
Birden çok kaynakla çalışmak tümleştirme karmaşıklığını artırır. Tek bir kaynaktaki hatalar öneri işlem hattı aracılığıyla yayılabilir. Girişleri birleştirirken doğrulama ve güvenlik korumaları uygulayın. Düşük gecikme süresi gerektiğinde, kaynakları paralel olarak sorgular. Sınıflandırma, zenginleştirme ve aramalar gibi belirli bir isteğe bağlı olmayan adımları ön işleme. Yinelenen hesaplamaları azaltmak için ara sonuçları ve sık kullanılan özellikleri önbelleğe alın.
Öneri motorlarını kara kutular yerine karar destek sistemleri olarak değerlendirin. Açıklanabilirlik, güven ve operasyonel güvenilirlik oluşturmanın merkezidir. Sistemler öneriler, önemli sinyalleri vurgulama ve veri kaynaklarına katkıda bulunma konusunda net gerekçeler sağlamalıdır. Aşağı akış sistemlerinin veya kullanıcıların güvenilirliği ölçmesine yardımcı olmak için güvenilirlik göstergelerini (örneğin, 0-100%) eklemeyi göz önünde bulundurun.
Örnekler
-
OE:06 İş yükü tedarik zinciri tasarlama. Test paketinize dahil etmek için tespiti zor ve genellikle göz ardı edilen müşteri odaklı uç durumlarını ve senaryoları bulun.
-
OE:08 Olay yönetimi. Yapay zeka kullanarak yalnızca sağlanan belgeler, playbook'lar, sağlık modelleri ve eskalasyon yolları üzerinden satıcı destek ekibinin benzetimini yaparak satıcı geçiş planlarını doğrulayın. Simülasyonda, iletim öncesinde boşluklar ve gizli bağımlılıklar vurgulanır.
-
OE:10 Otomasyon tasarımı. Hangi otomasyonların iyileştirilmesi, kullanımdan kaldırılması veya genişletilmesi gerektiğini önermek için otomasyon kodunu, telemetri verilerini ve olay verilerini değerlendirin.
Artefakt üreten ajanlar
Yapay zeka aracıları kod, altyapı tanımları ve testler oluşturmaya yardımcı olabilir, ancak çıktıları bir üretim iş yükünün parçası haline gelebilir. Kod oluşturma doğal olarak belirleyici değildir ve doğal dil gereksinimlerini yürütülebilir yapıtlara çevirmek özgün amaçtan farklı sonuçlar üretebilir. Bu nedenle, açık sahiplik, açık denetimler ve mevcut mühendislik uygulamalarıyla tümleştirme temel öneme sahip olur. Yapay zeka, sorun alanının iyi anlaşıldığı ve yinelenen veya standartlaştırılmış kodlama görevleri gibi varyasyonların sınırlı olduğu ve çıkışlarını yönlendirmek için koruyucuların uygulanması gerektiği durumlarda en etkili olandır.
Doğru modellerin seçilmesi kritik önem taşır. Kod oluşturma ve araç yürütme için uygun modelleri kullanın ve uygun yerlerde birleştirin. Bir akıl yürütme modeli sistem analizi, planlama veya ayrıştırma konusunda yardımcı olabilir, kod odaklı bir model yapıtları kendileri oluşturabilir ve ek modeller test veya dağıtım adımlarını destekleyebilir.
Oluşturma, kuruluş ve sektör standartlarını yansıtan şablonlar, başvuru uygulamaları, kodlama yönergeleri ve örneklerle temel alınmalıdır. Net standartlar kaymayı algılamaya ve tutarlılığı zorlamaya yardımcı olur. Şablonları kullanarak yapay zeka çıkışı daha tahmin edilebilir.
Çoğu aracı gibi kod oluşturucular da birden çok kaynaktan çizim yapabilir. Doğrulanana kadar tüm çıkışlar güvenilmeyen olarak kabul edilmelidir. Araç yürütme izinlerini ve kapsamını sınırlamak için en az ayrıcalıklı ilkeleri uygulayın. Ajanlar, açık ve kontrollü onay olmadan asla üretim kaynaklarını dağıtmamalı veya değiştirmemelidir.
Oluşturulan yapıtları standart geliştirici yaşam döngüsüyle tümleştirin. Buna kod incelemeleri, pull istekleri, otomatik testler ve güvenlik taramaları dahildir. Güvenilirlik ve uyumluluk sağlamak için bağımlılık denetimleri ve kod olarak altyapı taraması dahil olmak üzere insan tarafından yazılan kodlar için de aynı titizliği uygulayın.
Tradeoff: İnsan incelemesi maliyet modelinin bir parçası olmaya devam eder ve yatırım getirisi olarak hesaba katılmalıdır. Ayrıca artan yapıt oluşturma, aktarım hızı basıncını aşağı doğru kaydırır; yeni performans sorunlarını önlemek için test, doğrulama ve dağıtım iş akışlarının uygun şekilde ölçeklendirilmesi gerekir. Linterler, testler, statik analiz ve ilke denetimleri aracılığıyla doğrulamayı mümkün olan her yerde otomatikleştirmek, uçtan uca akışı ve değer elde etme süresini korumak için gereklidir.
Örnekler
-
OE:02 İşlemleri standartlaştırma. Kuruluş standartlarına uygun kod ve belge yapıtları oluşturun ve varlıklar geliştikçe standartlar belgelerini güncel tutun.
-
OE:07 İzleme sistemi tasarlama. Kaynaklar arasında doğru ölçümleri otomatik olarak seçerek mühendislik ölçümlerini iş sonuçlarıyla uyumlu hale getiren tümleşik pano yapılandırmaları oluşturun.
-
OE:10 Otomasyon tasarımı. Üretim ortamlarını yapılandırma kayması için otonom olarak izleyin, istenen durumu çıkarsayın ve sistemleri zaman içinde hizalı tutmak için önyükleme tanımlarını güncelleştirin.
✓ İlke doğrulama aracıları
Yapay zeka aracıları, varlıkların ilke ve standartlara göre gözden geçirilmesine ve doğrulanmasında yardımcı olabilir. İnsanların rolü kararları desteklemek, sapmaları tespit etmek ve uyumluluğu sağlamakken, son gözetim yetkisi hâlâ insanlarda kalır.
Doğrulama, kullanıma sunulmadan önce dikkatli bir değerlendirme ve test ile başlar. Standartlar sürüm numaralandırılmalıdır ve her varlık, izlenebilirliği sağlamak için geçerli ilkeye açıkça referans vermelidir. İlkeler geliştikçe bakım yükü dikkate alınmalı ve doğrulama işlemleri buna göre güncelleştirilmelidir. Mümkün olduğunda, gözden geçirmeleri toplu işleyip paralelleştirin ve tüm varlıkları yeniden taramak yerine değişiklikler üzerinde artımlı denetimlere odaklanın.
Maliyet ve performans için dikkatli bir denge gerekir. Depolama, işleme ve gecikme süresi üzerindeki etkisine karşı doğru tahminlerde bulunmak için gereken geçmiş veri miktarını göz önünde bulundurun. Çok az veri güvenilirliği azaltırken maliyeti çok fazla artırır.
Güvenlik önemli bir faktör olmaya devam eder. Doğrulama çıkışlarına erişim, hassas bilgilerin korunduğundan emin olmak için güvenlik gözden geçirenleri gibi yetkili kullanıcılarla sınırlandırılmalıdır.
Etkinlik ölçülür, varsayılmaz. Algılanan sorunlar ile üretimdeki sorunlar, hatalı pozitifler ve kapsam gibi ölçümleri izlemek için panoları kullanın. Bu içgörüleri doğrulama mantığına, istemlerine ve operasyonel süreçlere aktararak aracının katkısını sürekli olarak iyileştirin.
Örnekler
✓ Eylem iyileştirme aracıları
Eylem iyileştirme aracıları, doğrudan operasyonel eylemler gerçekleştirerek analiz ve önerilerin ötesine uzanır. Çıkışları sistemleri veya işlemleri değiştirebildiğinden, bu aracılar dikkatli bir tasarım, gözetim ve iş akışlarıyla tümleştirme gerektirir.
Risk: Güvenlik öncelikli bir konudur. Aracılar ideal olarak, önerilen eylemlerin üretimde yürütülmeden önce gözden geçirildiği ve onaylandığı döngüdeki insan iş akışında çalışmalıdır. Araçlara ve sistemlere erişim, aracıyı yalnızca görevlerini gerçekleştirmek için gereken izinlerle sınırlayarak en az ayrıcalık ilkesini izlemelidir. Ayrıntılı denetim, hangi eylemlerin önerildiğini, kimlerin onaylandığını ve izlenebilirlik için yürütme günlüklerini yakalama açısından önemlidir.
Her değişikliğin kapsamını sınırlı tutarak minimum bir patlama yarıçapı uygulayan korumalar uygulayın. Güvenli yeniden denemelere izin vermek için araç çalışmaları idempotent olmalı ve sistem doğrulama ile geri alma mekanizmalarını içermelidir. Denetim noktaları, yedeklemeler veya diğer kurtarma stratejileri istenmeyen değişikliklerin güvenli bir şekilde düzeltilmesine destek olabilir.
Örnekler
-
OE:08 Olay yönetimi. Bir uyarı tetiklendiğinde bağlam bilgilerini otomatik olarak toplayın, verileri eşleştirin ve ilk incelemeyi gerçekleştirin. Mühendisler el ile veri toplama yerine net bir olay resmiyle başlar.
-
OE:10 Otomasyon tasarımı. önbellek boyutları ve zaman aşımı değerleri gibi düşük riskli üretim ayarlarını, izleme verilerinin analizinden alınan değerleri kullanarak insan tanımlı sınırlar içinde sürekli olarak iyileştirin.
-
OE:11 Güvenli dağıtım uygulamaları. Aşamalı maruz bırakma dağıtım stratejinizi, en uygun kullanım zamanlamasını ve kanarya dağıtımlarınız için doğru hedef segment ve yüzdeleri otonom olarak belirleyerek otomatikleştirin.
Sonraki aşamalarda tutarlı ve kararlı operasyonlar oluşturan güçlü bir temel oluşturmak için sorun çözmede ekip çalışmasını ve birliği vurgulayın.
Gelecekteki stratejilerin başarısını sağlamak için Düzey 1'de bir DevOps düşünce yapısı oluşturun. İşlem verimliliğini artırmak için iyi oluşturulmuş DevOps yöntemleri uygulayın. Kararlı operasyonlar için temel ve ortak sözlük, süreçler ve araçlar oluşturmaya odaklanın.
Temel stratejiler
✓ İşbirliğini teşvik edin ve suçsuz bir kültürü teşvik edin
ekip çalışmalarını iş gereksinimleriyle uyumlu hale getirme ve işbirliğine dayalı bir kültür geliştirme.
Merkezi ekiplerin üyeleri, iş yükü işlevselliğine adanmış tam zamanlı personel, iş ortakları veya satıcılar genellikle iş yükü işlemlerini yönetir. Bu bireyler, karşılıklı saygı ve birbirlerinin uzmanlığını onaylayarak kolektif bir güç olarak çalışmalıdır. Takımlar bağımsız parçalar olarak çalışırsa, karmaşıklıklar ve uyuşmalar oluşabilir. Bağımsız ekipler, iş sonuçlarını yönlendiren tek ve verimli bir sistem olarak çalışma hedefini baltalar.
Yalıtılmış sahiplik duygusunu azaltmak için, problem çözme için birleşik bir yaklaşım savunucusu olun. Tüm çabalar işletmenin ihtiyaçlarını karşılamalıdır. Hem başarıları hem de hataları paylaşılan sonuçlar olarak görüntüleyin.
İş yükünüz için uygun olan ve geliştirme verimliliğini artıran, sektörde kanıtlanmış araçlar ve yazılım geliştirme yaşam döngüsü (SDLC) süreçleriyle başlayın. Kanıtlanmış yöntemlerden ayrışmayın ve genellikle daha yüksek sürtüşmeler ortaya çıkardığından özel metodolojilerden kaçının.
Agile, Scrum ve Kanban panoları popüler seçeneklerdir. Çoğu deneyimli geliştirici, DevOps mühendisi ve ürün sahibi, yeni işe alımlar için öğrenme eğrisini en aza indiren bu araçlar hakkında bilgi sahibidir.
Başlangıçta, standartlaştırmayı dahil etmek için yerleşik endüstri standartlarını kullanın. İşlemleri daha sonra iyileştirin. En yeni çözümlere erken geçiş yapmanıza gerek kalmadan, seçtiğiniz araçların gereksinimlerinizle birlikte büyüyebileceğinden emin olun.
✓ Kaynak kontrol işlemlerini ayarlama
Uygulamanın ölçeğine göre kaynak kodun nasıl yapılandır gerektiğine karar verin. Daha büyük sistemler için her ekibin sorumlu oldukları bileşenleri oluşturmak ve dağıtmak için kendi süreçleri olmalıdır. Bileşen bulunabilirliği ve sistemin diğer bölümleriyle paylaşılması için açık bir şekilde tanımlanmış arabirimlere sahip olmalıdır. Bir kaynak denetimi teknolojisi seçin ve ekip üyelerinin birbirlerinin çalışmalarına müdahale etmediğinden emin olmak için süreçleri ayarlayın.
Benzer şekilde, tek bir dağıtım işlem hattı daha küçük ölçekli uygulamalar için daha etkili olabilir. Bu, koordinasyonu basitleştirir ve güvenilirlik açısından da daha iyi olabilir. Ancak, sistemin belirli bölümlerini güncelleştirmek veya geçirmek zor olabilir.
✓ Birincil dağıtım yaklaşımınız olarak kod olarak altyapıyı (IaC) kullanın
Tutarlılık, tekrarlanabilirlik ve uzun vadeli avantajlar sağlamak için dağıtımlar için standart olarak bildirim temelli bir yaklaşım kullanın. Bu avantajlar arasında otomasyon, kendi kendini belgeleme ve değişiklik geçmişi de bulunur.
Tutarsız yapılandırmalardan ve test eksikliğinden kaynaklanan riskleri önlemek için portal dağıtımları yerine IaC dağıtımlarını tercih edin. Belirli programlarla sınırlı olan derlenmiş dillerden veya özel biçimlerden kaçının.
Azure'ın yerel olarak desteklediği Bicep ve Terraform gibi araçları kullanarak iyi bir temelle başlayın. Araçları değerlendirerek gelecekteki yolculuğunuzu kolaylaştırmalarını sağlayın. Teknoloji sağlayıcısının iyi belgelere ve güvenilir bir hizmet destek programına sahip olduğundan emin olun.
Risk: Kaçırılan modernizasyon fırsatlarını risk olarak değerlendirin. Örneğin, şirket içi çözümlerde kullandığınız araçları ve işlemleri modernleştirmeniz gerekir. Buluta geçiş yaptığınızda, bu araçlar genellikle yönetilmesi zor özel betikler gerektirir ve modernleştirmezseniz sorunlara neden olabilir.
Bu riski azaltmak için modern teknoloji seçeneklerini keşfedin ve şirket içi süreçleri güncelleştirin.
IaC'yi benimseme hedeflerinden biri tutarlılıktır. Şablonları çeşitli ortamlara dağıtacak kadar esnek hale getirin. Her ortamın kaynak ayarlarını değiştirmek için parametreleri, değişkenleri ve yapılandırma dosyalarını kullanın. Gerekli ayarları soyutlayın ve nadiren değişen ayarların aşırı soyutlanmasından kaçının. Ayrıca, kapsamlı şablon kitaplıklarına güvenerek çözümleri aşırı karmaşık hale getirmekten kaçının. Bu uygulama bakım sorunlarına yol açabilir.
Gelecek düzeylerde dağıtım ve sistem yönetimi iyileştirmesi için daha fazla fırsat oluşturmak için sağlam bir IaC temeli oluşturun. Örneğin, istediğiniz durum yapılandırmasını veya GitOps'yi ekleyebilirsiniz.
✓ Başlangıçtan itibaren güvenliğin önceliğini belirleme
Bu erken aşamada bile güvenliğin önceliğini belirleyin. Güvenlik önlemleri genellikle roller, kaynaklar ve ağ gibi bölümlere ayırmayı temel alır ve bu da karmaşıklıkları ortaya çıkarmaktadır. Ekip bu karmaşıklıkları kabul etmeli, güvenlik önlemlerini erken oluşturmalı ve zaman içinde güvenliğe yatırım yapmayı planlamalıdır. Bu yaklaşım, güvenlik uygulamalarının sonraki aşamalara ertelenmesi önlenir.
Risk: Geliştirme, destek ve operasyon süreçleri uyuşmalara neden olabilir. Ekipler iyi niyetle güçlü başlasa da güvenlik çalışmaları genellikle dirençle karşı karşıya kalır.
Riski azaltmak için iş listelerine güvenlik görevleri ekleyin. Bu uygulama, ekip içinde sorumluluk sağlar ve geliştirme görevleriyle birlikte ilerlemeyi izlenebilir hale getirir.
Denetimler ve eş gözden geçirmeleri aracılığıyla güvenlik açıklarını kolayca algılamak için araçları ve işlemleri saydam hale getirin. Henüz tam olarak uygulamasanız bile güvenlik açığı tarama ve güvenlik denetimlerini destekleyen endüstri standardı araçları keşfedin.
Farklı kimlik denetimi düzlemlerini en aza indirmek için araçlarınızın ve dağıtım uygulamalarınızın üretim ortamlarınızla aynı kimlik sağlayıcısını kullandığından emin olun.
Temel işlemleri standartlaştırın. Bu yaklaşım, karar alma sorumluluklarını kolaylaştırır ve sistem dağıtımı ve izleme gereksinimlerini tanımlar.
Düzey 2'de ekip daha yapılandırılmış bir yaklaşım benimsemeli ve geliştirme etkinliklerini iş yükünün temel işlevlerine odaklamalıdır. Önceden tutarlılık sağlamak, sonraki aşamalarda operasyonel yüklerin en aza indirilmesine yardımcı olur.
Temel stratejiler
✓ Ekip rollerini ve karar alma sorumluluklarını tanımlama
Bir ürün düşünce yapısı benimseyin. İş yükünü araçlar, teknolojiler veya iş işlevlerinin tümleştirmesi olarak görüntülemek yerine, son hedefe net bir şekilde odaklanarak uyumlu bir ürün olarak değerlendirin. Düzey 2'de, her rolün açıkça tanımlandığı ve dikkate alındığı daha yapılandırılmış bir yaklaşım uygulayın.
Ekip içindeki uzmanlık genellikle değişir. Bu çeşitlilik, karar alma sürecini çeşitli iş işlevleri arasında dağıtmada yararlı olabilir. Örneğin, belirli ekip üyeleri teknik kararlar alma konusunda başarılı olabilirken, diğer ekip üyeleri ekosistemde rekabet gücünü korumak için iş sonuçlarını tanımlama konusunda uzman olabilir.
Risk: Bazı iş yükü ekipleri, yalnızca herkesin kabul ettiği durumlarda görevlere taahhüt ettikleri, konsensüs temelli bir kültür benimser. Bu kültür, kapsayıcılığı teşvik eder, ancak tam fikir birliği sağlanamaması halinde genellikle girişimleri bastırır.
Aşağıdaki ilkeleri kullanarak iyi yapılandırılmış bir karar alma süreci sağlayın:
Karar vermenin ekip üyeleri arasında dağıtıldığından ve tek bir kişiyle merkezileştirilmek yerine uzmanlık alanlarıyla uyumlu olduğundan emin olmak için doğrudan sorumlu bir kişi belirleyin.
Karar alıcıların kim olduğunu belgeleyip bu bilgileri yeni çalışanlar için ekleme malzemelerine ekleyin.
Belirli rolleri ve sorumlulukları açıkça tanımlayan bir karar verme metodolojisi benimsemeyi göz önünde bulundurun. Bu yaklaşımların, bölme ve ürün hedeflerinden uzak odaklanma oluşturabileceğine dikkat edin. Silolu karar almalarını önlemek ve uyuşmaları azaltmak için denetimler ve dengeler oluşturun.
✓ Ne kadar küçük olursa olsun iyileştirmeler yapmak için çaba gösterin
Sürekli bir geliştirme anlayışını teşvik etme, kararların yarın geliştirilebileceği anlayışıyla bugün alınması anlamına gelir.
Değişikliklerin gecikmesi, ekibin mevcut geliştirme fırsatlarını kaçırmasına neden olabilir. Aşırı düşünmekten ve kararsızlıktan kaçının. Mükemmel bir çözüm için çabalama küçük ama anlamlı ilerlemeyi engelleyebilir. Sürekli iyileştirme yolları ararken şimdi iyileştirmeler yapmaya odaklanın.
Teknik borç, kısa vadeli kararları yakalamak için stratejik bir geliştirme aracıdır. Gereksiz birikimi önleyen artımlı güncelleştirmeler için bir motivasyon görevi görebilir. Teknik borcu, iş listesinde yineleyen bir görev olarak ele al.
✓ Temel süreçleri standartlaştırma
Farklı iş yükleri sınıfları, özel özelliklerine göre uyarlanmış benzersiz süreç gereksinimlerine sahiptir. Örneğin yapay zeka iş yükleri, veri işlem hatlarını modele yönlendirmek için makine öğrenmesi işlemlerine ve üretken yapay zeka işlemlerine dayanır. Görev açısından kritik iş yükleri, site güvenilirliği mühendislerinin hızla üzerinde işlem yapabilecekleri gerçek zamanlı izleme panolarının önceliklerini oluşturur.
bir iş yükü sınıfı içinde, tutarlılığı geliştirmek ve operasyonel yükü azaltmak için standartlaştırma için çaba gösterin. Hem ayrımcı hem de üretken modeller içeren yapay zeka iş yükleri için veri işlemleriyle ilgili süreçleri standartlaştırın. Bu işlemler, modelleri veya temel oluşturucu yapay zeka modellerini eğitmek için kullanılmadan önce veri erişimini, temizlemeyi ve dönüştürmeyi içerir.
Aşağıdaki kullanım örnekleri için standartlaştırma önerilir:
| İşlem |
Fayda |
| Sorun izleme ve yönetim |
Roller arasında daha iyi iletişim sağlar, öncelik belirlemeye yardımcı olur ve geçmiş sorunların geçmiş analizi için gereklidir |
| Özellikle olayları işlemek için iletişim araçları ve süreçleri |
Yanlış iletişim riskini en aza indirir ve sorunları daha hızlı çözmek için ekip üyeleri arasındaki koordinasyonu artırır |
| Kod stilleri, kaynak adlandırma kuralları ve belge standartları |
Yönergeler oluşturarak kod okunabilirliğini ve sürdürülebilirliğini artırır |
| Test yordamları |
Tüm değişikliklerin kalite güvencesi sağlayan seçili bir test kümesinden geçmesine olanak sağlar |
| Sürekli tümleştirme ve sürekli dağıtım |
Kod değişikliklerinin otomatik olarak test edilmesini, tümleştirilmesini ve dağıtılmasını sağlar ve bu da daha güvenilir sürümlere neden olur |
Risk: Sürekli iyileştirme ve yenilik genellikle bir ekip daha iyi yaklaşımları keşfetmek için yerleşik standartlardan biraz saptığında ortaya çıkar. Bu sapmalar teşvik edilmeli ancak yapılandırılmalıdır. Örneğin, yenilik günlerine ev sahipliği yapmak, ekibin yeni fikirler ve denemeler geliştiren önceden seçilmiş iyileştirme projelerine odaklanmasını sağlar.
Standartlaştırılmış süreçler etkili uygulama için gerekli araçları içerir. Bu düzeyde, özel olarak oluşturulmuş çözümler yerine kullanıma hazır çözümlerin önceliklerini belirleyin. Daha sonra özel kullanım örnekleri için yeniden düşünebilirsiniz.
İş yükleri için günlük araçlar geliştirme, test, izleme ve dağıtım araçlarını içerir. Satın alınan araçlar iş akışlarını kolaylaştırır ve tutarlılık sağlar. Bu tutarlılık, ekiplerin özel çözümler geliştirme ve bakımını yapma karmaşıklığı olmadan özellikleri sunmaya odaklanmasını sağlar.
Risk: Araçlar göz önünde bulundurulduğunda genellikle temel işlevselliği yerine aracın genişletilebilirliğini ve gelecekteki potansiyelini aşırı vurgulama eğilimi vardır. Bu aşamada, pratik araçlara odaklanın, mevcut sorunlarınızı çözün ve geçerli iş akışınıza uygun olun.
✓ İş yükü genelinde otomasyonu benimseyin
Yeni veya mevcut bir iş yükü geliştirirken otomasyonu tümleştirme fırsatları arayın. Başlangıçtan itibaren otomasyon düşünülerek yeni bir iş yükü tasarlamak, gelecekteki benimsemeyi sorunsuz hale getirir. Benzer şekilde, otomasyonu mevcut iş yüklerine veya brownfield iş yüklerine dahil etmek, yaşam döngüsünün başlarında verimlilik kazanmanıza ve zaman içinde tutarlılığı korumanıza yardımcı olur.
Benimsemeyi kolaylaştırmak için sıfırdan çözümler oluşturmak yerine bulut platformunuzla uyumlu olgun ve tanıdık kullanıma açık araçları kullanın. Tasarımı basitleştirmek için bulut sağlayıcınızın yerel otomasyon araçlarını keşfedin. Örneğin, birçok Azure hizmeti olağanüstü durum kurtarma için performans ve yük devretme özellikleri için otomatik ölçeklendirmeyi destekler. Microsoft dışı araçları değerlendirirken, ekibinizin uzmanlığını ve ilgili iş standartlarını dikkate alırsınız.
Aşağıdaki alanlar otomasyondan yararlanabilir:
İzleme ve uyarı oluşturma ve güncelleştirme yönetimi gibi rutin operasyonel görevler
Dağıtımlar ve test gibi yazılım geliştirme yaşam döngüsü görevleri
Kaynak ölçeklendirme gibi iş yükü performansı iyileştirmeleri
Taramalar ve ilke uygulama gibi güvenlik ve idare mekanizmaları
Yedekleme ve kurtarma etkinlikleri
Kaynak ayırmaları ve kapatmalar gibi maliyet iyileştirmeleri
Risk: İş yükü geliştirmenizin ilk aşamalarında, dikkati iş yükünün teslim edilmesinden üretime yönlendirebileceği için otomasyon oluşturmaya veya tümleştirmeye çok fazla odaklanmaya dikkat edin. Geliştirme hızınızı korurken iş yükünüzün yönetilebilir olduğundan emin olmak için ölçülen bir yaklaşım benimsersiniz.
Denge: Bir görev insanlar tarafından seyrek, verimli ve güvenli bir şekilde yapılabiliyorsa, otomatikleştirmeye değmeyebilir. Örneğin, bir sertifikanın yıllık yenilemesini otomatikleştirmek, geliştirme döngülerinin yatırımını haklı çıkarmayabilir.
Düzey 1'de, uygulama kodu için altyapı ve işlem hatlarını dağıtmak üzere kod olarak altyapı (IaC) araçlarını benimsemeye odaklanılır. Düzey 2'de, bu uygulamayı dağıtılan altyapı ve uygulamaların yapılandırmasını ve yönetimini içerecek şekilde genişletin.
Kaynaklarınızı önyüklemek ve yapılandırma kaymasını önlemek için istenen durum yapılandırma yaklaşımını kullanın. Farklı görevler ve platformlar farklı otomasyon araçları gerektirir. Örneğin Ansible, sanal makineler (VM) için istenen durum yapılandırmasını yönetmek için uygunken, Flux gibi bir GitOps çözümü Kubernetes kümeleri için uygundur.
Tasarımı basit tutarken operasyonel yükünüzü en aza indirmek için dağıtım sonrası görevleriniz için doğru otomasyon düzeyini belirleyin. Sertifikaları yükleme, işletim sistemi yapılandırmaları ve veritabanı tohumlama gibi görevlerin tümü otomatikleştirme için iyi seçeneklerdir. Ayrıca, otomasyonunuzu uygulamanızı yeni dağıtılan VM'lerde veya kapsayıcı konaklarında dağıtmayı ve yapılandırmayı içerecek şekilde genişletmeyi göz önünde bulundurun.
Risk: Gereksiz araç kullanımı dağınıklığından kaçının. Farklı yaklaşımlar ve teknoloji kullanan geliştiriciler veya geliştirme ekipleri, araç ekosisteminde kırılmalara neden olabilir. İş yükünüz için gereksinimlerinizi karşılayan belirli sayıda aracı standartlaştırın ve iş yükü ekibinizin bu araçlar üzerinde eğitildiğinden emin olun. Benzer şekilde, araçlar için kuruluş standartlarını benimseme konusunda seçici olun. Kuruluşunuz iş yükünüz için aşırı risk oluşturan araçlar önerirse, daha uygun alternatif araçları değerlendirin.
✓ İş yükünüzün dağıtım stratejisini tanımlama
Dağıtım stratejisi, operasyonel mükemmellik açısından kritik bir bileşendir. İyi tasarlanmış bir dağıtım stratejisi, güncelleştirmeler veya değişiklikler sırasında kapalı kalma süresini azaltarak veya ortadan kaldırarak hizmetlerin kullanıcıların kullanımına açık kalmasını sağlar. Değişikliklerin üretime nasıl ve ne zaman dağıtılacağı konusunda paydaşlardan fikir birliği elde edin. Aşağıdaki noktaları göz önünde bulundurun:
Tolere edilmiş kapalı kalma süresini tanımlayın. İş yükünün önemli sorunlara veya finansal kayıplara yol açmadan bir kesinti süresini destekleyip destekleyemediğini belirleyin. Düzenli dağıtımlar için sıfır kapalı kalma süresinin gerekli olup olmadığını açıkça belirtin.
Dağıtım sıklığını belirleme. Özellik geliştirme temelinde dağıtım sıklığını belirleyin. Günlük, haftalık, üç aylık veya başka bir uygun yaklaşım olsun, bir zamanlama üzerinde anlaşın. Mümkün olduğunda, senaryonuzla uyumluysa daha küçük ve daha sık dağıtımların önceliğini belirleyin.
Acil durum dağıtımlarını planlama. Güvenlik düzeltmeleri gibi acil durum dağıtımlarını yöneten yordamları uygulamak için bir plan geliştirin. Bu yaklaşım, ekip üyelerinin sorumluluklarını anlamasını ve gerektiğinde hızla harekete geçebilmesini sağlar.
Hataları en aza indirmek ve tutarlılık sağlamak için otomatik olarak oluşturulabilen tekrarlanabilir bir dağıtım sistemi tasarlayın. Son dağıtımda hatalar oluşursa, sistemi işlevsel bir duruma geri yüklemek için geri alma işlemleri için düzenlemeler ekleyin.
✓ İş yükü izleme yığınını tasarlama
İzleme sistemi tasarlamak için nelerin izleneceğini seçmeniz ve bu ölçümlerin kullanıcılar için önemini anlamanız gerekir.
İş yükündeki tüm bileşenlerden günlükleri ve ölçümleri toplayarak başlayın. Platform tarafından sağlanan izleme araçlarından yararlanın. Bu araçlar hizmetlerle tümleşiktir ve çok az yapılandırmayla işlevsel ve operasyonel içgörüler sağlar. Bu verileri analiz için sorgulanabilecek güvenilir bir depolama çözümünde güvenli bir şekilde depolayın.
Risk: Aşırı veri toplamaktan kaçının çünkü bu, gürültü oluşturabilir ve maliyetleri artırabilir. CPU, bellek kullanımı ve depolama kullanımı gibi temel ölçümlerle başlayın. Zaman içinde yararlı uygulama durumu ölçümleri ekleyin.
İlk analize dayanarak, hem iyi durumdaki hem de iyi durumda olmayan durumların iş yükü için ne anlama geldiğinden emin olmak için paydaşlarla birlikte çalışın. Bu bilgileri sonraki aşamalarda sağlık durumunu doğru yansıtan bir sağlık modeli geliştirmek için kullanırsınız.
Risk: İzleme işlem hattınız, geri ödemeler, işlem hizmeti düzeyi sözleşmeleri, kapasite güvenceleri ve satış toplamları dahil olmak üzere iş ölçümlerini toplamak için bir araç görevi görür. İş yükü sağlığı ölçümleri ile iş ölçümleri arasında net bir ayrım sağlayın.
İş ölçümlerini izleme yapılandırmaları yerine uygulama özelliği olarak toplayın. Veri akışlarını izleme, örneklenebilir ve felaket durumunda genellikle kurtarılamaz. İş açısından kritik verileri iş yükü verileri olarak değerlendirin ve iş yükü sistem durumu sinyallerinden ayrı tutun.
Kapalı kalma süresine neden olabilecek dağıtım hataları riskini azaltın. Kapanma süresi oluşursa, site güvenilirliği mühendislerinin analiz için ölçüm toplamaya zaman harcamadan kritik sorunlara odaklanadığından emin olun.
Önceki düzeylerde yazılım geliştirme yaşam döngüsünü standartlaştırıp dağıtım yöntemleri, test ve telemetri koleksiyonu hakkında önemli kararlar alırsınız.
Düzey 3'te, dağıtıma olan güveni artırmak için işlemler olgunlaşmalıdır. Test, güvenli ve kararlı dağıtımlar sağlamak için canlı kullanıma yönelik bir gereksinim haline gelir. Dağıtım süreçleri de gelişir ve iş yüklerini derlemek ve üretime dağıtmak için otomatik işlem hatlarını benimser. Risklerin patlama yarıçapını en aza indirmek için temel kaynaklar ve uygulama kodu arasında uygun segmentasyon korunur.
İzleme uygulamaları da olgunlaşır. İzleme sistemi, operasyonel bilgileri uygulanabilir içgörülere çeviren bir sağlık modeli uygulamak amacıyla genişletilir. Uyarılar iş bağlamı için kolaylaştırılmıştır, bu nedenle ilgisiz uyarılar yanlış alarmlara neden olmaz ve izleme sisteminde güvensizliklere neden olmaz.
Temel stratejiler
Bu düzeyde, canlı yayına geçmeden önce resmi bir değişiklik denetimi protokolü olarak sürüm tanıtımını oluşturmak önemlidir. Bu süreç, önerilen değişiklikleri çeşitli aşamalardan geçirirken kalite kontrol noktalarından geçer. Her aşama kapsamlı testlerden geçer ve değişiklikler yalnızca bu denetimleri geçip onay alırsa ilerler.
Geliştirme/test, kalite güvencesi, kullanıcı kabul testi (UAT) ve üretim gibi farklı aşamalar için ayrı ortamlar oluşturun. Bu yaklaşım, sonraki aşamaya geçmeden önce kapsamlı doğrulama sağlar. Amaç, patlama yarıçapını en aza indirmek için hataların erken yakalanması gerektiğinden düşük ortamlardaki riskleri yönetmektir.
Bu düzeyde, testin sistemin kritik bölümleri için önceliklendirildiği bir stratejiye karar verin. Güçlü bir test stratejisi sağlamak için aşağıdaki adımları kullanın:
Test çalışmalarını tanımlayın. Uygulama kodu, altyapı şablonları ve yapılandırma için test çalışmaları oluşturun.
Çeşitli test türleri gerçekleştirin. Her ortamda farklı türlerde testler gerçekleştirin. Düşük riskli ortamlarda yüksek riskli değişiklikleri test etmeye başlayın. Güvenilirlik arttıkça yüksek riskli değişiklikleri aşamalı olarak daha yüksek riskli ortamlara taşıyın.
Ayrı test ortamları ayarlayın. Farklı test etkinlikleri için ayrı ortamlar oluşturun. Örneğin, ui testi yapıyorsanız, hem geliştirme hem de üretim ortamlarından ayrı bir ayrılmış ortam oluşturun.
İdeal olarak, geliştirme ve test ortamlarını üretim ortamına olabildiğince benzer şekilde tutun. Yalnızca bir örnek olsa bile test verilerinin üretim verileriyle yakından eşleştiğinden emin olun. Kaynaklar da karşılaştırılabilir olmalıdır. Örneğin, birkaç megabayt veri içeren küçük test veritabanları bazı durumlarda yeterli olabilir, ancak gerçek dünya performansını değerlendirmek için birkaç terabayt içeren üretim boyutuna yakın bir veritabanı kullanarak özellikleri doğrulamak önemlidir.
Taviz: Bu ortamları yakın tutmak önemlidir, ancak dikkate alınması gereken tavizler vardır. Geliştirme aşamasında üretim ortamının tüm ölçeğini dağıtmak mümkün değildir.
Üretim ortamına yakınlık ile uygun maliyetli üretim dışı bir ortama sahip olma arasındaki dengeyi bulun. Örneğin, test geçişi sonrasında parçalanan kısa ömürlü geliştirme/test ortamları oluşturmayı göz önünde bulundurun.
Ortamları test durumuna göre boyutlandırın. Birim testi için yalnızca daha küçük bir kurulumda eşleşen kitaplık ve işletim sistemi sürümleri gerekebilir. Dayanıklılık testinin aynı hizmet SKU'ları ile üretim öncesi bir ortama ihtiyacı olabilir. Performans testi, üretim ölçeğinde dağıtım talep edebilir.
✓ Mümkün olduğunda test ve diğer kalite kontrollerini otomatikleştirin
Otomasyon, tutarlılık sağlamak ve beklenmeyen yapılandırma değişikliklerini hızla tespit etme için mükemmeldir. Otomatikleştirilmiş test aracılığıyla hangi değişikliklerin denetlenebileceğini belirleyin. Örneğin, bir geliştirici ortamına geçiş yaptığınızda güvenlik taramaları otomasyon için mükemmeldir. Tüm testlerin otomatikleştirilmesi gerekmez ve bazı testler otomatikleştirilemez. Örneğin UAT, uygulamanın kullanıcıların beklentileriyle karşılaştırmasını ve onaylarını almayı gerektirir.
Uyarı
Yüksek oranda otomatikleştirilmiş bir ortamda bile karar alıcılar çok önemlidir. İnsan katılımı düzeyi farklılık gösterebilir, ancak bir sonraki ortama geçiş her zaman birisi sorumludur. Bu işlem, otomatik denetimler için kurallar tanımlamayı veya el ile incelemeler gerçekleştirmeyi içerebilir. Daha düşük risk toleransı olan sonraki ortamlarda el ile denetim yapılması gerekebilir.
Otomatikleştirilmiş testi düzenlemeye yönelik Azure Yük Testi ve Azure Pipelines gibi farklı test türlerini otomatikleştirmek ve kolaylaştırmak için çeşitli test araçları mevcuttur.
✓ Onay süreçlerini ayarlama
Dağıtımınız farklı ortamlarda ilerledikçe, değişiklikleri doğrulamak için test ve onay işlemlerini kullanmanız önemlidir. Bu doğrulama zamanla olgunlaşıp daha sıkı hale gelmelidir. Örneğin, bir geliştirici iş istasyonundan paylaşılan bir geliştirici ortamına geçiş yaptığınızda, temel güvenlik taramaları ve eş gözden geçirme işlemleri genellikle yeterlidir. Ancak daha sonra iş paydaşlarını da eklemeniz gerekebilir. Yapılandırılmış ve verimli bir dağıtım işlemi sağlamak için aşağıdaki yönergeleri göz önünde bulundurun:
Normal sürümler için onay: Normal sürümler söz konusu olduğunda, hazırlama aşamasından üretime geçmek için farklı bir ölçüt kümesi gerekir. Sürümlerle ilgili kararlar, örneğin üretime geçme gibi, paydaşların onayını, net belgeleri veya her ikisini gerektirir. İş yükü ekibi, onay sürecinin kimin parçası olduğunu ve sorumluluklarını tanımlamalıdır. Bazı yasal durumlarda denetçiler de karar alma sürecine dahil edilebilir. Düzey 2'de bu rolleri ve sorumlulukları oluşturun.
Düzeltmeler için ayrı bir işlem olmalıdır: Güvenlik düzeltme eklerini dağıtma gibi kritik durumlar için bir doğaçlama dağıtım işlemine ihtiyacınız olabilir. Bu yüksek öncelikli düzeltmeleri hızlandırmak için bir acil durum süreci oluşturun. Bu süreç yalnızca önemli paydaşların ve teknik üyelerin onayını içerebilir. Alternatif olarak, daha hızlı dağıtım için bazı onayları atlayan bir işlem hattı geliştirebilirsiniz.
Atlanması gereken adımları belirlerken işletme veya müşteriler için riski göz önünde bulundurun. Acil durumlarda yüksek yatırım ve düşük riskli testler atlanabilirken, yüksek riskli ve düşük yatırımlı testler her zaman çalıştırılmalıdır. Doğrudan sorumlu kişi (DRI), önemli paydaşların ve teknik karar alıcıların görüşleriyle nihai kararları vermelidir.
✓ Otomatik dağıtımları uygulama
Beklenen değişiklik oranına göre farklı katmanlar için ayrı dağıtım döngüleri sağlayın. Bazı durumlarda, bağımlılıklar ve kapalı kalma süresi gereksinimlerine bağlı olarak döngüleri birleştirmek gerekebilir. Ancak çoğu durumda, her katmanı en az ayrıcalıkla bağımsız olarak yöneterek ayrıntı düzeyi için çaba gösterin. Bir katmandaki değişikliklerin diğerlerini etkilemediğinden emin olun.
Örneğin, ağ altyapısı değişiklikleri uygulama kodu değişikliklerinden daha az sıklıkta olmalıdır. Kalite denetimi aracılığıyla kolaylaştırılmış bir işlemle bu değişiklikleri ayrı ayrı yönetin. İşlem oluşturmak için iş yükü katmanlarıyla uyumlu dağıtım işlem hatları oluşturun. Üretim ortamına dağıtmadan önce denetimli bir ortamda kod olarak altyapı varlıkları üzerinde testler çalıştırın.
✓ Bir sağlık modeli geliştirin
Temel bir izleme sisteminiz olduktan sonra, iş bağlamını izleme verileriyle birleştirerek iş yükü bileşenlerinin ve genel sistemin sağlık durumunu hesaplayın.
Sistem durumu modellemesi olarak bilinen bu alıştırma, altyapıdan ve uygulamalardan izleme değerlerini iş bağlamı ile bağlamsallaştırmayı içerir. Etkili bir sağlık modeli oluşturmak için aşağıdaki temel ilkeleri göz önünde bulundurun:
Sistem tarafından gözlemlenen veri bağlamı verin. Eşiklerin ayarlanması, sistem durumu modellemesinin önemli bir parçasıdır. Eşiklerin iş yükünüz için anlamlı olduğundan emin olmak için bağlamla sayısal değerler sağlayın. Örneğin, 70% ile 90% arasındaki yüksek CPU kullanımı genellikle bir iş yükünde iyi durumda olmadığını gösterirken, kullanılabilir kaynakları verimli bir şekilde kullanan başka bir iş yükü için iyi durumda olabilir.
Değişikliklerle ilgili uyarı verin. Bu değerlerdeki değişiklikler sağlık durumundaki değişiklikleri gösterir ve DRI'leri harekete geçirmelidir. Bu nedenle uyarı, sistem durumu modellemesinin bir diğer temel bileşenidir. Standart ölçümleri açmaktan ve tüm uyarıları destek merkezine göndermekten kaçının. Bunun yerine, sağlık modelinizdeki değişikliklere göre uyarılar oluşturun. Uyarılarda yer alan bilgiler anlamlı ve eyleme dönüştürülebilir olmalı ve araştırma veya düzeltici eylem gerektiren belirli sorunlar hakkında doğru ekiplere bildirilmelidir.
Sağlık modelinizi görselleştirin. İş yükü sistem durumu sinyallerini farklı paydaşlarla kolayca paylaşmak için izleme platformunuzun görselleştirme araçlarını kullanın. Bazı paydaşlar, uygulama kullanılabilirliği gibi belirli istatistikler gerektirebilir. Operasyon takımlarının tüm sistem durumu sinyallerine erişim sağlaması gerekir. Farklı panolar ayarlamak, her ekibİn ihtiyaç duyduğu bilgileri sağlamasına yardımcı olabilir.
Zamanla geçmiş iş yükü sağlığı eğilimlerini izlemek ve analiz etmek için bir strateji geliştirin.
✓ Olay yönetimi sürecinizi ayarlayın
İş yükünüz üretim aşamasındayken platform kesintileri, veri bozulması ve daha fazlası gibi olaylarla ilgilenmeniz normaldir. Önemli olan, bu olayları iş yükünüz için ayarladığınız hedefler içinde etkili bir şekilde işlemektir. Bu nedenle, üretime geçmeden önce olay yönetiminin ilk adımı olarak yapılandırılmış bir destek planına sahip olun.
Kimlerin görevde olduğunu, görevlerini ve arama personeli arasındaki iletimlerin nasıl yönetildiğini tanımlayarak destek işlemlerini resmileştirin. İdeal olarak, arama rotasyonunda boşluk olmaması gerekir ve herkes herhangi bir zamanda olayların işlenmesinden kimin sorumlu olduğunu bilir.
Her olay türü için iyi tanımlanmış bir playbook veya yanıt sürecine sahip olduğunuzdan emin olun. Örneğin, hata modu analizinizden (FMA) veya güvenlik temelinden elde ettiğiniz sonuçları kullanabilirsiniz.
Olay yönetiminin hazır olma durumuyla ilgili temel testleri çalıştırmak için sistem durumu modelini kullanın. Burada operatör sanal bir sorunun etkisini izlerken, aramadaki bir geliştiricinin sorunları gidermesi gerekebilir.
Sistemin kullanıcılara söz verilen kalite standartlarını karşıladığından ve hizmet düzeyi sözleşmelerinin ihlal edilmesini önlediğinden emin olun.
önceki aşamalarda iş yükü takımı, özellik geliştirmeye ve sistemi üretime almaya odaklanır. Bu düzeyde odak, özellik oluşturmadan canlı bir sistemin bakımını yapmaya ve geliştirmeye geçer. Gerçek kullanıcılar artık buna güveniyorken, öncelik verimli ikinci gün operasyonları, yani triyaj, bakım, yükseltmeler ve sorun giderme aracılığıyla değişiklik yönetimine dönüşür.
Ana strateji, operasyonları geliştirmek için gerçek dünya deneyimini kullanmaktır. Test, değişikliklerle ilişkili riskleri azaltmak için de tartışılamaz bir uygulama haline gelir. Hataları düzeltmeden özellik eklemeye ve olay yanıtını iyileştirmeye kadar geliştirmenin her bölümüyle testi tümleştirmeniz gerekir. Bu olmadan, ciddi sorunlar üretime ulaşana kadar algılanmayabilir.
Bu düzeyde, teknik borç gerçek bir endişe haline gelir. İdeal olmayan uygulamalar devreye alınabilir, bu yüzden bakım karmaşık hale gelebilir. Ekipler bakım yükünü analiz etmeli ve azaltmaya odaklanmalıdır.
Temel stratejiler
✓ Güvenli dağıtım uygulamalarını kullanma
Üretimden sonra, üç önemli değişiklik türü genellikle rutin güncelleştirmeleri, yeni özellik güncelleştirmelerini ve acil durum güncelleştirmelerini içerir. Bu değişiklikler sırasında sistemi kararlı tutmak için güvenli dağıtım uygulamalarını kullanın. Değişikliğin türü ne olursa olsun, her değişikliği iş yükünün kullanıcıları için olası bir hata noktası olarak değerlendirin.
Aşağıdaki stratejileri değişiklik denetimi sürecinizle tümleştirin:
Sürekli ve kapsamlı olarak doğrulayın. Geliştirme yaşam döngüsü boyunca ve değişiklikler farklı ortamlarda ilerledikçe erken ve sık sık test edin. İdeal olan, bir yapıtın her değiştiğinde bu değişikliklere odaklanan testler oluşturmaktır. Ardından akışları uçtan uca doğrulamak için tam test paketini çalıştırın. Test sonuçları doğrulama verileri sağlar, ancak iş paydaşlarının bu değişiklikleri onaylaması gerekir.
Taviz: Test paketinin tamamını çalıştırmak dağıtımlarda güven sağlar. Ancak, zaman ve maliyet nedeniyle tüm değişiklikler için pratik olmayabilir. Kapsamlı testlerle maliyetle ilgili dikkat edilmesi gerekenleri dengeleyin. Değişikliklerin etkisine göre onay sürecini uyarlar. Küçük değişikliklerin basitleştirilmiş bir yordamı olmalıdır, ancak yeni özellikler gibi önemli değişiklikler kapsamlı bir inceleme gerektirir.
Bu düzeyde, bölgesel yük devretmeler gibi gelişmiş operasyonel kavramları benimseyebilirsiniz. Amaç, çoğu senaryoda kendi kendini iyileştirmeye odaklanarak bu süreçleri tamamen otomatikleştirmektir. Bu işlemlerin de kapsamlı bir şekilde test edilmesi gerekir.
API'leriniz için sürüm oluşturma uygulayın. Geriye dönük uyumluluk sağlamak için veri modelinizdeki değişiklikleri dikkatle yönetin. API sürüm oluşturma stratejisi, değişiklikler dağıtıldıktan sonra mevcut sistemlerin sorunsuz bir şekilde çalışmaya devam etmelerine yardımcı olur. Geçmişe dönük sürüm oluşturma zor olabilir, bu nedenle erken bir strateji oluşturun.
Artımlı güncelleştirmeleri kullanıma sunma. Düzey 3'e göre dağıtım işlemleri tüm ortamlarda otomatik işlem hatları kullanılarak standart hale getirilir. Düzey 4 olgunluğunda iş yükü üretim aşamasındadır. Odak, sürüm döngülerini yönetme de dahil olmak üzere artımlı güncelleştirmeleri iyileştirmeye kaydırılır.
Küçük bir değişiklik kümesi için doğrulamayı basitleştirmek için küçük ve sık güncelleştirmeler dağıtın. Yük testi, test ortamlarına dağıtım ve A/B testi gibi doğrulama görevlerini otomatikleştirin.
Uyarı
Kanarya ve mavi-yeşil dağıtımlar gibi güvenli dağıtım desenleri, yan yana dağıtımlar aracılığıyla esneklik ve güvenilirlik sağlar. Örneğin, mavi-yeşil dağıtımlarda yeni bir ortam oluşturulur, trafik kaydırılır ve eski ortam kullanımdan çıkarılır. Diğer dağıtım teknikleri arasında özellik bayrakları ve karanlık lansmanlar yer alır. Bu yaklaşımlar, değişikliklerin tüm kullanıcılara dağıtılabilmesi için üretim ortamında test edilmesine olanak sağlar. Bu özellik, dağıtım yuvaları arasında aşamalı olarak değiştirilerek güncelleştirmelerin dağıtılabildiği Azure App Service gibi belirli Azure hizmetlerinde kullanılabilir.
Dağıtım hatalarından geri alın. Bazı güncelleştirmelerin başarısız olmasını bekleyebilirsiniz. Artımlı güncelleştirmelerle, sorun oluştuğunda sorun giderme daha hızlı hale gelir. Bir hata oluşursa, daha fazla hasar oluşmasını önlemek için sistemi durdurun ve sorunu çözmek için değişiklikleri uygulayın. Yedeklemelerden geri yükleme, sürekliliği korursa kabul edilebilir. Amaç, yalnızca geri alma yordamlarına güvenmek yerine kararlı bir sürüme geçmektir.
✓ Derleme işlemlerini iyileştirme
Düzey 3'te, mimarinin farklı katmanları için değişiklik oranına göre ayrı dağıtım döngüleriniz olmalıdır. Altyapı ve kod işlem hatlarını en azından koruyun.
İş yükü üretimde olduğuna göre katmanlama yaklaşımını yeniden değerlendirin. Mümkünse, daha esnek sürüm döngülerine olanak tanımak için mimari bileşenleri daha fazla ayrıştırın. Bu yaklaşım, tek tek bileşenlerdeki gecikmeleri azaltır ve hataları en aza indirir. Ayrıca zaman kazanmak ve geliştirici üretkenliğini artırmak için testleri ve uzun süre çalışan işlemleri paralel işler olarak çalıştırın.
✓ Olay yanıt süreçlerini doğrulama
Düzey 3'te, olaylara yanıtları tanımlamak için playbook'larla bir çağrı içi destek sistemi oluşturursunuz. Ancak, oyun kitabına sahip olmak yalnızca ilk adımdır. İş yükü üretim aşamasında olduğuna göre olay yönetimi sürecinizin verimliliğini doğrulamanız ve geliştirmeniz ve sağlam bir iletişim planı geliştirmeniz gerekir. Aşağıdaki uygulamaları göz önünde bulundurun:
Olaylara verilen yanıtları test edin. Teknolojiden, kişilerden ve süreçlerden gelen yanıtları birleştirir. Doğrulama çabalarınıza gerçekçilik katmak için oyun günlerini çalıştırmanızı öneririz. Oyun günleri, takımın sorunları algılama ve çözme becerisini test etmek için hataların ortaya çıktığı planlı etkinliklerdir. Bu yaklaşım ekibin doğru araçlara, kaynaklara ve yordamlara sahip olmasını sağlar. Kaos mühendisliği, sonuçları gözlemlemek için kontrollü kesintiler getiren bir diğer değerli tekniktir. Alternatif olarak, genel yük dengeleyicide arka uçları devre dışı bırakma veya veritabanı yük devretmesi gerçekleştirme gibi el ile gerçekleştirilen yöntemler de yanıtı test etmek için kullanılabilir.
İletişim planı geliştirme. İş yükü ekibi, destek ekipleri ve acil durum müdahale personeli genelinde iletişim sorumluluklarını açıkça tanımlayın. İş paydaşlarına iç durum güncelleştirmelerinin temposunun ve biçiminin standartlaştırılması saydamlığı ve güveni teşvik eder. Güvenlik ihlalleri gibi belirli senaryolarda son kullanıcılara sorumlu bir şekilde açıklama yapılması gerekir. Bu dış iletişimlerde uygun tür ve bilgi düzeyinin açıkça tanımlandığından emin olun.
Olay incelemesi gerçekleştirin. Her olayı üretimden öğrenme fırsatı olarak değerlendirin. Dağıtım ve geliştirme süreçlerinizdeki zayıf noktaları belirlemek ve sistem geliştirmeleri yapmayı taahhüt etmek için bu işlemi kullanın.
✓ Üretimden gelen izleme verilerini kullanarak işlemleri iyileştirin
Düzey 4'te gelişmiş izlemenin bir iş bağlamında ölçümleri yayması, ilişkilendirmesi ve analiz etmesi gerekir. Bu düzeyde, üretimden öğrenerek doğruluğunu geliştirin. En iyi tahminler üzerine oluşturulmuş işlemleri geliştirmek için izleme verilerini kullanın. Aşağıdaki önemli örnekleri göz önünde bulundurun:
Düzey 3'te birincil odak, iş yükü için bir sağlık modeli geliştirmektir. Düzey 4'te uyarı sistemine ince ayar yapın ve gerçekçi hedefler ile hizmet düzeyi göstergeleri ayarlayın.
2. gün işlemlerinin bir parçası olarak yapılandırma kayması en aza indirilmesi önemli bir öncelik olmalıdır. Bu odak olmadan, çalışma zamanı ortamı hedeflenen durumundan kademeli olarak farklı olabilir. Bilinen iyi yapılandırmanın anlık görüntüsünü yakalayarak başlayın. Ardından, geçerli davranışı bu taban çizgisiyle karşılaştırmak için üretimden gözlemlenebilirlik ölçümlerinden yararlanın. Bu yaklaşım, hedeflenen sistem durumuyla sürekli hizalama sağlar.
Bu düzey, sistemin belirli stresörler altında nasıl davrandığını daha iyi anlamak ve yeni özelliklerin etkisini tahmin etmek için geri bildirim döngüleri eklemek için idealdir. Sistem telemetrisi, iş yükü değişikliklerini tahmin etmeye ve olası sorunlara yönelik proaktif çözümleri şekillendirmeye yardımcı olan önemli içgörüler sağlayarak bu geri bildirim döngülerine yol gösterir. Bu verileri teknik borcu önceliklendirmenize yardımcı olması için de kullanabilirsiniz.
Genel bir uygulama olarak, üretimdeki gözlemlenebilirlik verilerine ve desenlerine göre izleme yığınında ince ayar yapın. Aşağıdaki uygulamaları göz önünde bulundurun:
Kritik süreçlerdeki etkinlikleri yakalamak için, görünürlük ile gürültü arasındaki dengeyi sağlamak amacıyla günlük düzeylerini ayarlayın.
İlgisiz uyarıları bastırırken önemli uyarıları da büyütün.
✓ Bakımı otomatikleştirme
Düzey 3'te otomasyon çalışmaları öncelikli olarak üretime dağıtmaya odaklanır. Düzey 4'e göre ekipler sürekli tümleştirme ve sürekli teslim işlem hatlarını kullanarak derleme, test ve dağıtım süreçlerini otomatikleştirerek el ile çalışmayı önemli ölçüde azaltmıştır. Kalite geçitlerinde olduğu gibi, belirli onaylar da otomatik iş akışları aracılığıyla yönetilebilir.
4. Düzeyde operasyonel otomasyon gerçek dünya üretim deneyimiyle yönlendirilmeli ve teknik borcun giderilmesine odaklanmalıdır.
Aşağıdaki 2. gün otomasyon örneklerini göz önünde bulundurun.
| İşlem |
Fayda |
| Sertifikaların, API anahtarlarının ve diğer gizli dizilerin rotasyonunu otomatikleştirin. |
Otomasyon, zamanında dönüşleri garanti ederek el ile müdahale gereksinimini ortadan kaldırarak zamandan tasarruf sağlar ve insan hatası olasılığını azaltır. |
| Altyapının rutin bakımını otomatikleştirin. |
Rutin altyapı bakımı kapsamlı test ve koordinasyon gerektirir. Otomasyon bu görevleri hızlandırarak el ile harcanan çabayı azaltabilir ve riskleri en aza indirir. |
| Acil durum yanıt sürecini otomatikleştirin. |
Düzgün otomasyon olmadan, insanlar acil durum sürümü sırasında aceleci ve koordine edilmemiş eylemlere başvurabilir ve bu da daha fazla soruna yol açabilecektir. |
| Yük ani artışları ve düşüşlerinde kaynakların ölçeklendirmesini otomatikleştirin. |
Otomatik ölçeklendirme, kaynakların isteğe bağlı olarak dinamik olarak ayrılmasını sağlar. Bu ayırma, talep azaldığında kaynaklar aşırı işlem yükü olmadan serbest bırakıldığından kaynakların daha verimli kullanılmasına neden olur. |
| Veri alma ve teslimi otomatikleştirme. |
Bu yaklaşım, kullanıcılar tarafından gönderilen veri isteklerini yerine getirmek için gereken süreyi ve çabayı azaltır. Veritabanlarına el ile erişmek yerine, veritabanına erişmek, ilgili verileri almak ve kullanıcıya göndermek için betikler tetiklenir. |
| Belirli ölçütlere göre geliştirici ortamları oluşturmayı otomatikleştirin. |
Bu yaklaşım, ekibin 2. gün işlemlerinin bir parçası olarak iş yükündeki güvenli değişiklikleri kolaylaştırmak için ortamların tutarlı bir şekilde oluşturulmasını sağlar. |
Uyarı
Dağıtım otomasyonu stratejisi geliştirirken bilinen ve öngörülebilir görevlerle başlayın. Hata noktalarını hesaba katın. Bu noktalar otomatikleştirildikten sonra, bazıları el ile müdahale gerektirebilecek öngörülemeyen sorunları çözmek için kapsamı genişletin. Örneğin, altyapı güncelleştirmeleri gibi rutin görevleri otomatikleştirerek başlayın çünkü bunlar daha yönetilebilir. Ardından, bilinmeyen hata senaryoları içerebileceğinden acil durum yamaları ile ilgilenin.
Örneğin, bir ekip tüm coğrafyalardaki kullanıcılara denetimli maruz kalma özelliğini kullanarak düzenli olarak bir iş yükü dağıtabilir. Bu işlemin tamamlanması birkaç gün sürebilir. Aynı zamanda, belirli adımları atlayarak acil düzeltmeleri daha erken dağıtabilmeleri için ihtiyaçları vardır. Otomasyon işlemi bu hızlandırılmış dağıtımları hesaba eklemelidir.
Birincil hedef, son tarihler nedeniyle önceki aşamalarda gözden kaçmış olabilecek insan odaklı, yinelenen görevleri tanımlamaktır. Ancak her şeyi otomatikleştirmemelisiniz. Yatırım getirisi otomasyona yol göstermelidir. Tamamen yeni araçlarla başlamak yerine mevcut teknolojileri ve bilgileri kullanmayı tercih edin. Hafif araçlar gerekiyorsa yaşam döngüsünü ve bakım gereksinimlerini değerlendirin.
Düzey 4 olgunluğunda, mühendislik varlıklarını ve süreçlerini değerlendirerek operasyonel verimlilik kazanmaya odaklanın. Hangi varlıkların işletmeniz için temel öneme sahip olduğunu ancak temel olmadığını belirleyin.
Bu varlıklar için aşağıdaki noktaları göz önünde bulundurun:
Önceden oluşturulmuş varlıklar destek kanallarıyla birlikte gelir ve özel çözümlerin yerini alabilir. Bu yaklaşım, ekip tarafından oluşturulan çözümlerinizin operasyonel yükünü azaltır. Bu kaynakların gereksinimlerinizi ne kadar iyi karşıladını değerlendirin ve kalan boşlukları belirleyin.
İş yükünün aşağıdaki alanlarını keşfedin:
Özel kodunuzu değerlendirin. Ayrıştırma gibi görevler için özel kod yazmak yerine endüstri standardı olarak kabul edilen açık kaynak çözümleri değerlendirin. Bu araçların kullanılması, kod bakımı gereksinimini azaltabilir ve daha küçük bir kod tabanına neden olabilir. Kuruluşunuzda zaten mevcut olan seçenekleri keşfedin. Kimlik doğrulaması gibi rutin görevleri işlemek için iş yükünüzle tümleştirebileceğiniz mevcut kitaplıklar olabilir.
Araç zincirinizi değerlendirin. Benzer araçları kullanan diğer takımlara güvenebileceğiniz alanları değerlendirin. Kitaplık, şablon ve modül kullanımınızı uygun şekilde ayarlayın. İşlemleri kolaylaştırmak için kod olarak altyapı araçlarını kuruluş genelinde uyumlu hale getirme.
İşlemlerinizi değerlendirin. Güvenlik taraması gibi kendi uygulaymış olabileceğiniz görevleri gerçekleştirebilen merkezi işlemleri belirleyin. NuGet paketleri için kendi karantina sürecinizi yönetmek yerine, kuruluşun mevcut güvenlik ekibinin sürecini iş yükünüzde kullanılan modüller hakkında bilgilendirerek kullanın.
Desteklenebilirlik de bir diğer önemli alandır. Başlarda, geliştirme ekipleri genellikle ölçümleri izleyerek ve canlı sorunları çözerek destekle kendileri ilgilenir. Bu aşamada, nöbetçi mühendisler gibi özel roller ayarlamayı göz önünde bulundurun. Kuruluşunuzun paylaşılan bir destek ekibi varsa, geliştiriciler üzerindeki destek yükünü azaltmak için bu ekibi kullanın.
Uyarı
Mümkünse, günlük desteği dış satıcılara geçirin. Satıcıların geliştirme ekibi veya iş yükünü üretime getiren mimarlar gibi derin bağlamları yoktur. Görevleri bir satıcıya vermeden önce, sistemin üretimde kararlı olduğundan ve yönetim görevlerini açıkça tanımladığınızdan emin olun. Satıcıların başarılı olması için önemli öğelere ihtiyacı vardır. Sistem durumu modelinde sağlıklı, iyi durumda olmayan ve Düşürülmüş durumları temsil eden eşikler tanımlayın. Satıcıları kılavuzlar, araçlar ve diğer sorun giderme kaynakları konusunda eğitin. Nedenleri belirleyemezse, sorunları iş yükü ekibine iletme ve yönlendirme için iyi tanımlanmış yollar ayarlayın.
✓ Düzenli bir tempoda teknik borcu yönetme
Teknik borç, geliştirme sırasında son tarihleri karşılamak için kullandığınız kısayolların sonucudur ve bu da idealden daha az uygulamayla sonuçlanabilir. Ekipler, bakım karmaşıklığını ve süresini analiz ederek bu borcu azaltmak için çalışmalıdır. Teknik borç giderilemediyse sistemlerin bakımı veya ölçeği daha karmaşık hale gelebilir. Geliştiriciler yeni özellikler üzerinde çalışmak yerine sorunları çözmek için daha fazla zaman harcadıklarından bu karmaşıklık yenilikleri yavaşlatıyor.
Teknik borcun işlenmesi için aşağıdaki taktiksel önerileri göz önünde bulundurun:
Özellik çalışmalarının yanı sıra teknik borcu da takip edin.
Özellik geliştirmeden ayrı olarak teknik borcu gidermek için her sprint'te kapasite ayırın. Bazen tüm sprint'leri teknik borcu gidermeye ayır.
Yeni özellikler için yeni teknik yük oluşturmayı planlıyorsanız önerilen çözümü hemen geri beslemeye ekleyin.
Teknik borç, gelişimin normal bir parçasıdır ve gelişme fırsatıdır. Yeni özellikler eklendikçe borç birikiyor. Eski borcu ödeme çabasını yeni özellikler geliştirmenin yeni borcuyla dengeleyin.
İyileştirmeye ve uyarlamaya devam edin, ancak bitirdiğiniz varsaymayın.
Düzey 1 ile 4 arasında ilerledikçe Azure'da iyi tasarlanmış bir iş yükü oluşturursunuz. Tasarımınız, sistemi üretime hazırlayan izleme, test, dağıtım ve otomasyon gibi operasyonel uygulamaları ayarlar. Sistem üretime geçtikten sonra, kullanıcı deneyimini korumak için işlemleri dengelemeye ve değişiklikleri yönetmeye odaklanırsınız.
Son aşamada olgunluk, iş yükünü büyük ölçekte çalıştırmak anlamına gelir ve bu da iş yükünü güvenilir ve up-togüncel tutar. Ayrıca, mevcut tasarımın sınırlarına ulaştığı alanları belirleme ve iş gereksinimlerindeki değişikliklere hazırlanma konusunda yetkinlik gerektirir. Ekosistem geliştikçe kısıtlamalarla ilgili varsayımlar eskiye gidebilir. Ortamlar, uygulamalar ve araçlar gelişmeye devam ettiğinden statik kalmak regresyona neden olabilir. Düzey 5 yaklaşımlarına yatırım yapılmazsa iş yükünüz geride kalır.
Düzey 5 bir bitiş hedefi veya teknik denetim noktası değildir. Kültürü, süreçleri, araçları ve teknolojiyi modernleştirmeye odaklanan bir fikir değişikliğidir. İşlemler, iş yükü uygulamasının aldığı aynı titizlik, yatırım ve yenilikle muamele görüyor.
Temel stratejiler
✓ Gözlemlenen büyüme ve gelecekteki potansiyele dayalı yeniden dikte fırsatlarını tespit edin
İş yükü mimarileri kasıtlı olarak kısıtlamalarla tasarlanmıştır ve kullanım ömrü sınırlıdır. Düzey 4'e kadar mimariniz büyük olasılıkla iş gereksinimlerini etkili bir şekilde karşılar. Bu düzeyde sistemin yeni kullanım düzenlerini, teknolojileri, büyümeyi ve operasyonel zorlukları nasıl ele alacağını değerlendirin.
Örneğin, binlerce kullanıcı için çalışan bir çözüm, on binlere ölçeklendirildiğinde başarısız olabilir. Veri hacminin artması bölünmezlik sorunlarına yol açabilirken, performans ve uyumluluk için daha fazla talep mimarinizi sınırlarına itebilir. Bu baskılar yeni özelliklerin sunulmasını engelleyebilir ve ölçeklendirme performans sorunlarına neden olabilir.
Bu düzeyde, kritik eşikleri tanıyıp yeniden tasarlamanız gerekebilecek alanları belirleyin. Aşağıdaki alanları göz önünde bulundurun:
İlk araç, çerçeve ve platform hizmetleri seçiminiz iş gereksinimlerinize uygun olabilir. Ancak sisteminiz geliştikçe bu araçlar katı veya sıkı bir şekilde birbirine bağlı hale gelebilir, kitaplıklarda genişletilebilirlik eksik olabilir ve platform hizmetleri kullanım ömrü sonuna ulaşarak mevcut bağımlılıkları bozabilir.
Güçlü destek ve yaygın topluluk benimsemesi sağlayan daha geniş bir ekosistem içindeki araçları ve hizmetleri keşfedin. Daha kolay değiştirme veya yükseltme için modüler, gevşek bir şekilde bağlanmış bir mimari seçin.
Önceki düzeylerde iş yükü ekibi teknik yığının tamamını yönetebilir. Bu yaklaşım başlangıçta etkili olabilir, ancak genellikle sistem ölçeklendikçe artan basınç ve operasyonel ek yükle sonuçlanabilir. Bu yükü hafifletmek için sorumlulukları ağ, güvenlik veya gözlemlenebilirliğe odaklanan ekiplere devretmeyi göz önünde bulundurun. Uzmanlıkları, temel iş yükü ekibinin ürün değeri sunmaya odaklanmasını sağlar.
Müşteri tarafından ayrılmış (veya tek kiracılı) örneklerin yönetilmesi hem maliyeti hem de operasyonel ek yükü artırabilir. Bu zorluk genellikle çok kiracılı bir mimari benimseme gereksinimini gösterir. Bu değişiklik, kiracı ekleme ve veri erişimi yalıtımı gibi daha geniş mimari ve operasyonel yatırımlar gerektirir.
Dağıtım stratejinizi yeniden gözden geçirerek tahmin edilebilir bir şekilde ölçeklendirin ve büyük ölçekte hata izolasyonu ile performansı yönetin. Deployment Stamps deseni gibi kanıtlanmış uygulamaları keşfedin.
Ölçek birimi , bağımsız olarak izlenirken artan yükü işlemek için birlikte ölçeklendirilen mantıksal bir kaynak grubudur. Bu birimler, tanımlanan eşiklere göre otomatik olarak yinelenebilir bloklar olarak dağıtılır ve gerektiğinde çoğaltılabilir.
Ancak, bu yaklaşım belirli hizmetlerin ölçeğini artırmaya neden olabilir ve bu da ek maliyetlerle sonuçlanabilir.
Daha fazla bilgi için bkz . Ölçek birimi mimarisi.
Sabit ortamlar , dağıtımdan sonra sistemlerin hiçbir zaman değiştirilmediği dağıtım kurulumlarıdır. Dağıtım damgasını yerinde güncelleştirmek yerine eski damgayı söküp gerekli değişikliklerle yeniden dağıtın. Bu yaklaşım için mavi-yeşil dağıtımlar gibi yan yana dağıtım modelleri gerekir. Bu uygulamayı benimsemek için işlem hatlarının hiper ölçeklendirmeyi işlemek veya iyi durumda olmayan birimleri değiştirmek için otomatik olarak yeni bir damga dağıtmaya hazır olması gerekir.
Düzey 4 güvenli dağıtım uygulamalarınız sizi bu geçişe hazırlamalıdır. Regresyon olmamalıdır ve kullanıcılar yeni damgaya sorunsuz bir şekilde geçiş yapmalıdır.
✓ Sürtünmeyi daha da azaltmak için otomasyonu kullanın
Düzey 4'ten Düzey 5'e geçiş yapmak yalnızca otomasyonu artırmakla ilgili değildir. Ayrıca, bu görevlerin ne zaman çalıştırılması gerektiğine karar vermek ve uyuşma durumlarını azaltmak için otomasyonu kullanmakla da ilgili.
Aşağıdaki örnekleri göz önünde bulundurun:
Yerel geliştirici ortamlarının otomatik olarak oluşturulması: Her geliştirici iş istasyonunu aynı araç kümesi, kitaplık sürümleri ve diğer geliştirme varlıklarıyla yapılandırarak standartlaştırılmış bir deneyim sağlayın. Bu tutarlılık, tüm geliştiricilerin deneyim düzeyinden bağımsız olarak tekdüzen bir ortama erişmesini sağlar. Ayrıca daha iyi işbirliği, bilgi paylaşımı ve ekleme işlemlerini kolaylaştırır. Bu işlemi basitleştirmek için sanallaştırılmış geliştirme ortamlarını kullanın.
Otomatik uyarı önceliklendirme ve çözüm iş akışları: Önceden tanımlanmış kurallara göre uyarıları kategorilere ayırmak ve önceliklendirmek ve çözümleme iş akışlarını tetiklemek için otomasyonu kullanın. Yüksek öncelikli uyarılar için sistem ilgili ekiliğe bildirimde bulunabilir ve yanıt sürelerini hızlandırmak için çözüm sürecini başlatabilir.
Otomatik olay düzeltme: Otomatik olarak hizmetleri yeniden başlatan veya sorunlar algılandığında iş yüklerini değiştiren kendi kendine düzeltme betikleri uygulayın. Örneğin, bir web sunucusu kilitlenirse, bir betik hizmeti yeniden başlatabilir veya trafiği kesinti süresini en aza indirmek için yedek sunucuya yönlendirebilir.
Otomatik kaynak kullanımı: Diğer yapılardaki olgunluk ilerledikçe, hedeflerini desteklemek için otomasyon eklemeniz gerekebilir. Örneğin, maliyetleri azaltmak ve kaynak kullanımını iyileştirmek için yoğun olmayan saatlerde kritik olmayan kaynaklar ve ortamlar zamanlayabilirsiniz.
Otomatik kiracı yönetimi: Çok kiracılı ortamlarda kiracı ekleme ve çıkarma süreçlerini kolaylaştırın. Yeni bir kiracı kaydolduğunda otomasyon kullanıcı hesapları oluşturabilir, kaynakları sağlayabilir ve ayarları yapılandırabilir.
✓ Her özellik veya değişiklik için geliştirici ortamları oluşturma
2. gün işlemleri, güvenli değişikliklerin uygulanmasına odaklanır. Her değişiklik geliştirme, test ve güvenlik gibi belirli amaçlar için ayarlanan farklı ortamlardan geçer. Düzey 4 yönergelerini izleyerek, bu ortamların oluşturulmasını otomatik hale getirdiğiniz varsayılır.
Üretime hazır olma ve iş yükü değişikliğini yönetme konularına odaklanan Düzey 1-4'ten farklı olarak Düzey 5, iş yükü ekibinin tasarımlarını, başarılarını ve hatalarını kuruluş genelindeki diğer iş yükleriyle paylaşması için bir fırsattır. İş yüküne sahip ekiplerin, geçmişte bu yoldan geçen başkalarından önceden öğrenebilirlerse, bundan nasıl kaçınacaklarını öğrenmek için başarısızlık yaşamalarına gerek yoktur.
✓ Bilgileri paylaşın ve kurumsal olgunluğa katkıda bulunun
Düzey 1 ile 4 arasında iç hazırlık ve iş yükü değişikliğini yönetmeye odaklanın. Düzey 5 farklıdır çünkü iş yükü ekiplerinin tasarımlarını, başarılarını ve başarısızlıklarını kuruluş genelindeki diğer ekiplerle paylaşması için bir fırsat oluşturur. Benzer zorluklarla karşılaşan diğer kişilerden bilgi edinebilen bir ekibin hatayla ilk elden karşılaşması gerekmez.
Bu değişiklik, bireysel iş yükü düzeyinde operasyonel mükemmellik ilkelerinden merkezi operasyonlara yatırım yapan kuruluşa geçişi içerir. Bu merkezi ekipler, dağıtım araçları oluşturan, güvenlik önlemleri, otomasyon, gözlemlenebilirlik ve test ile donatılmış özel mühendislik gruplarından oluşur.
İş yükü ekibiniz eş ekiplerle etkili olan teknikleri, araçları ve içgörüleri paylaşmalıdır. İş yükünüzün bağlı olduğu ekiplerle etkileşime geçerek başlayın. Ardından iş yükünüze bağlı ekiplerle bağlantı kurun. Deneyimleri ve sonuçları paylaşırken bu ekiplerden bilgi edinin. Paylaşılan platformlar, belgeler ve topluluk etkileşimi aracılığıyla daha fazla bilgi paylaşımı görmeniz gerekir.
✓ İş yükünüzün çeşitli iş işlevleri için self servis özelliklerini etkinleştirin
İş yükünün rutin geliştirme sorumlulukları içinde yinelenen, planlanmamış görevlerle karşılaştığınızda, ekip üyelerinin gerektiğinde sorumlu bir şekilde uygulayabileceği betiklenmiş çözümler olarak teslim edilip edilmemeleri gerektiğini değerlendirin. Ekip çevikliğini ve özerkliğini geliştirmek için bu planlanmamış görevler için self servis özellikleri oluşturun ve koruyun.
İş yükü ekibine self servis bir çözüm olarak ulaştırmanın uygun maliyetli olduğu, zaman alıcı ve hataya açık, planlanmamış görevlerle başlayın. Çözümün ekip üyelerinin zamanını iyileştirmesi ve bu görevlere tutarlılık katması gerekir. Bu yaklaşım, self servis çözümünün kullanım ömrü boyunca yatırım getirisi elde eder.
Platform mühendisliği yolculuğunuzu başlatma başlığında açıklanan yaklaşımı ve özellikleri izleyin.
Yapay zeka fırsatları