Kalkınma neden operasyonlara karşı çıkıyor?

Hala öğrenciyim, ancak operasyonlar hakkında bilgim yok ve İngilizcem hala kötü.

Sorum şu: Kalkınma neden operasyonlara karşı çıkıyor ? Gelişme ne zaman operasyonlara karşı çıkıyor?

DevOps noktası, gelişme olduğunu olmamalıdır operasyonları karşı, bunun yerine birbirlerine destek olmalıdır.

Geleneksel olarak, şelale dağıtımları ve büyük ölçekli güncellemeler nedeniyle, geliştirme, yetersiz test, sunucu ortamlarını değiştirme nedeniyle dağıtım sırasında çeşitli sorunlara neden olur, liste uzar. Esasen, güncellemeler operasyon ekibinin süreçte ortaya çıkan bazı problemler olmadan bunları etkin bir şekilde kullanamayacak kadar büyüktü. Bu sorunlar, kalkınmanın operasyonlara karşı olduğuna inanmanızın nedeni olabilir .

Öte yandan DevOps, güncelleme boyutunu azaltmak, katı ortamları azaltmak ve genellikle her yıl devretme sayısını arttırarak geliştirme ve operasyonlar arasındaki uygulamanın iş akışını iyileştirmek için çalışır. Artan konuşlandırma sayısı ile operasyonlar için daha az baş ağrısı gelir, çünkü ürünleri güncellemek için gereken büyük miktarda işi otomatikleştirdiler veya güncellemeleri daha iyi öngörüyorlar ve hazırlıyorlar.

Tldr: DevOps, operasyonların ve geliştirmenin ürünleri sık sık zamanında ve kolayca tekrarlanabilir bir şekilde dağıtmak için birlikte çalıştığı bir zihniyet oluşturarak , kalkınmanın operasyonlara karşı olduğu teorisini geçersiz kılmayı amaçlamaktadır .

Zaten bazı kapsamlı yanıtlarınız olduğunu düşünüyorum, ancak ingilizcenizin harika olmadığını söylediniz, bu yüzden çok kısa ve anlaşılır bir cevap vermeye çalışacağım:

• Gelişimin temel amacı değişiklik yapmaktır.
• Operasyonların temel amacı çevreyi sabit tutmaktır.

Bu iki şey çatışıyor. Bununla birlikte, gelişme ve operasyonlar birbirine karşı olmamalıdır. Her iki hedefe de ulaşılabilmesi için birlikte çalışmalıdırlar. DevOps'un amacı budur.

Geliştirme ve operasyonlar arasındaki gerilim, genellikle ekip içinde teşviklerin ve optimizasyon girişimlerinin yanlış hizalanmasından kaynaklanır.

Geliştiriciler genellikle geçebilecekleri ve kod deposuna birleştirilebilecek sorunların hızı ve miktarı ile değerlendirilir ve ödülleri genellikle bu kodun gerçekten doğru şekilde çalıştığı veya çalıştığıyla bağlantılı değildir. Çok daha az ölçeklendirme, performans ve diğer faktörler.

Operasyonlar genellikle çevrenin istikrarı ve kodun üretimde ne kadar iyi çalıştığı konusunda değerlendirilir, ancak nadiren değişiklikleri hızlı bir şekilde getirme sürecinin kalitesi ile ilgilidir.

Bu, geliştiricilerin çok sayıda kod oluşturmak ve duvarın üzerinden operasyon ekibine atmak için teşvik edildiği ve operasyon ekibinin çevrenin istikrarını sağlamak için mümkün olduğunca az değişikliği kabul etmeye teşvik ettiği bir sorun yaratır.

DevOps bir bakıma bu soruna bir dizi çözümdür:

• Bazıları, ekiplerin süreçlerinin ve teşviklerinin değişebileceği organizasyonel olabilir. Örneğin, geliştiricilerin çalışması yalnızca bir süredir üretimde çalışırken yapılıyor olarak işaretlenirse, herhangi bir sorun yoktu ve operasyon ekibi kodun sahipliğini almayı kabul ediyor. Benzer şekilde, operasyonlar hala kodun kabul edilme hızı konusunda değerlendirilebilirken, ortam hala bazı kararlılık sınırları içindedir.
• Çözümün başka bir kısmı, operasyon insanlarını geliştirme ekibine dahil ettiğiniz iletişim ve çapraz politikada olabilir. Bu ekipler arasındaki duvarı kırıyorsunuz ve DevOps mühendisleri genellikle bu tür köprülemenin sonucudur.
• Sürekli Entegrasyon ve Sürekli Dağıtım gibi süreçleri destekleyen araçlar, çözümün değişikliklerin hızını artırabilen bir diğer parçasıdır ve kodun geri alınması veya hızlı bir düzeltme ilerlemesi ile herhangi bir sorun olması durumunda üretim ortamının yüksek kalitesini ve hızlı bir şekilde geri kazanılmasını sağlar. üretime.

Çoğu kuruluş, organizasyonlarını işlevsel parçalara ayırarak ve her parçanın kendini nasıl geliştireceğini bulmasını talep ederek karmaşıklıkla uğraşır. Buna genellikle "silo" yaklaşımı denir.

Bu silo yaklaşımının işletmenin başarısını neden engellediğini ve organizasyonu bir bütün olarak geliştiremediğini anlamak önemlidir. Ve sadece geliştirme ve operasyonları etkilemez - kalite güvence ekibi, finans, ürün ve proje yönetimi gibi büyük bir organizasyon içindeki diğer tüm fonksiyonel siloları da etkiler.

Her fonksiyonel silo yöneticisine maliyeti düşürerek veya hızı artırarak iyileştirme komutu verildiğinden, tepkileri genellikle:

• Son iyileştirme çabasından kaynaklanan sorunları gidermekten tamamen bunalmış durumdayım. Beni yalnız bırak.
• Ne yapmamı, sorumluluklarımı yerine getirmemi veya iyileştirme projeleri üzerinde çalışmamı istiyorsun? İkisini de yapacak vaktim yok.
• Tekrar olmasın! İşte ayın başka bir programı geliyor.

Bu tipik reaksiyonlarla, küçük bir iyileştirme çabası başlatan herhangi bir yönetici nadiren coşkuyla karşılanır. Yöneticiler, gelişimlerini gerçekleştirmek için gerekli kaynaklar üzerinde kendilerini diğer fonksiyonel alanlarla sert bir rekabet içinde bulurlar. Yani, iyileştirme komutunun çapraz fonksiyonel savaşları yoğunlaştırmasına şaşmamalı!

Bir yönetici bir geliştirme projesinin parçasını tamamlasa bile, diğer fonksiyonel alanlarla ve işlerini yapmayan diğer kuruluşlarla (tedarikçiler, yükleniciler vb.) Tanışır. Bu sonuçları azaltır veya tamamen ortadan kaldırır.

Bu çapraz fonksiyonel gerilim iyileştirme çabalarıyla sınırlı değildir. Günlük karar verme sürecinin ve bir kurum genelinde yönetimin etkinliğinin yargısının tam kalbindedir. İşte gerçek hayattan bir örnek:

Bir finans yöneticisine "geliştirin" söylendi. Piyasada kabul edilen nominal fiyattan daha pahalı olan işe alım yüklenicilerini engellemeye karar verdi. Yeni politikayı uyguladı ve bu yıl 1 milyon dolar tasarruf ettiğini iddia etti. Geliştiriciler ve BT ile bu yükleniciler pahalı olduğu için konteyner ve konteyner orkestrasyonu kullanmaları için yükleniciler işe alamıyor. Aynı şirketteki BT operasyon yöneticisi, altyapılarında iyileşmenin, şirkete her ay 100.000 doların üzerinde ek masrafa mal olduğunu hesapladı. Bu oranda, yüklenici firmaların yıllık tasarrufları yıl bitmeden yenildi.

Bu iki fonksiyonel alan arasındaki ilişkinin tam olarak sevecenlik olmadığını hayal edebilirsiniz.

Bu çapraz fonksiyonel çatışmalar, örgütün her bir siloyu bağımsız olarak gelişimde ölçtüğü silo yaklaşımı tarafından yönlendirilir. Bir maliyet merkeziyseniz, iyileştirme doğal olarak silonuzda daha fazla verimlilik veya maliyet azalması anlamına gelir.

Bu referans çerçevesinde, maliyetlerin "katkı maddesi" kuralına uyduğu görülmektedir. Her siloya eklenen maliyetler, örgütün toplam maliyetine eşittir. Bu nedenle, yöneticiler, bir bütün olarak şirket için maliyet tasarruflarına doğrudan bir çeviri gördükleri için, alanlarındaki herhangi bir maliyet azalmasını "iyi" olarak görürler. Bu referans çerçevesinde, kuruluş genelinde maliyet ve israfa saldırmak için iyileştirme çabaları her yere yayılmıştır.

Geliştirme ekipleri Agile çalışmaya ve eskiden olduğu gibi her üç ayda bir yerine KG ve Operasyonlara kod göndermeye başladığında harika bir örnek. KG ve Operasyonlar böyle bir değişikliğe hazır değil ve gevşetmekle suçlanıyor. Yine, bu gelişme ve operasyonlardaki insanlar arasındaki sevgiye çok fazla katkıda bulunmaz.