DevOps iş akışını durdurmanın artıları / eksileri?

Bir devops tarzı iş akışından geleneksel dev-then-ops (buna ne dediğinizden emin değilim) hareket etmenin iyi bir fikir olup olmadığını değerlendirmeye çalışıyorum.

Biz 4000 çalışanı geleneksel medya (örneğin yazılım olmayan) bir şirket içinde sıkışmış küçük bir 5 kişilik departmanı vardır. İki yıl önce departmanımızın üretimimizi önemli ölçüde büyütmesine izin vermek için yazılım geliştirmeye başladık. Oldukça başarılı olduk ve büyük şirket fark etmeye başlıyor. Bugüne kadar, ~ 10 hizmet AWS mikro hizmet platformu haline gelen şeyin tasarımından, geliştirilmesinden ve dağıtımından sadece biz sorumluyuz. Ekibimiz DevOps olarak tanımlamıyor, ancak şüphesiz DevOps yaşamını yaşıyoruz, her geliştirici hem kodu hem de üzerinde çalıştığı sistemi yakından biliyor.

Kısaca karşılaşacağımız sorulardan biri, ana şirketimizin BT departmanı ile aramızda paylaştığı "verimliliklerin" ne olduğudur. Proje sahibimiz genellikle kurum içi öğrenmeye göre dış kaynak kullanmayı tercih eder, bu nedenle bizim durumumuzda bu verimlilikler muhtemelen mümkün olduğunca çok sayıda "plakadan" BT çalışması almak anlamına gelir. Şu anda ekibimizin kodlama ve altyapı deneyimleri arasında% 70/30 oranında bir bölünme olduğunu söyleyebilirim. BT departmanı, yazılım geliştirmede gözle görülür bir geçiş olmadan, kesinlikle IT alanındadır.

Proje sahibimiz (teknik olmayan bir birey) BT ekibine mümkün olduğunca fazla iş dağıtarak, attığımız her bir saatlik çalışma için verimlilikte ~ 1: 1 artış göreceğimizi umuyor. Yine de bu konuda kuşkuluyum. Ürünümüz hala beta öncesi (zaten önemli bir ticari varlık olmasına rağmen) ve BT departmanı ile sınırlı deneyimimizde, dosya sistemi izin değişiklikleri kadar basit şeyler için genellikle önemli gecikmeler var.

Şu anda ideal çözümüm, BT departmanının bizi "benimsemesi" ve kendi ofisimizi konuşlandırmaya devam etmemize izin verirken, BT ofisinin standartlarını ve gereksinimlerini karşılamamızı sağlayacaktır. Bunun ne kadar gerçekçi olduğundan emin değilim. Ayrıca, kısa vadede ek operasyonlar ekleyeceğinden proje sahibimizin savunduğu yaklaşım neredeyse tam tersidir.

Bizim durumumuzda, DevOps yaklaşımı ile BT'yi teslim etmenin karşılaştırması gibi avantajlar ve dezavantajlar nelerdir?

İyi bir fikir değil.

Deneyimlerime göre, her ikisinin dezavantajlarını kazanacaksınız, ancak öngörülen avantajlar bir şekilde gerçekleşmeyecek.

maddeler halinde:

1. Hız kaybedeceksiniz.
   BT kendi standartlarına uyacaktır. Yeni görev (onlar için) şimdi tüm çalışmalarının sahip olduğu aynı 'durgun' şablonu izleyecek. Hazırlanmaları zorlayıcı bulacaktır - standart basit eylemlerden bile daha az hız.
2. Boşaltma başarısız olacak.
   Her bir anomali için size güvenecek. Bir adamı hızlandırmak için çaba göstereceksiniz - ve şimdi bir sonraki şey kendinizi tekrarlayacaksınız çünkü aşağıdaki görev / sorun / gün yine yeni bir adam olacak.
3. Dokümantasyon gerekli olacak, ancak yardımcı olmayacak.
   Yine şablon davranışı, kısa kılavuzların her anormalliği yakalayamayacağı ve ayrıntılı metinlerin çok uzun olduğu için okunamayacağıdır. Bu nedenle, buradaki herhangi bir yatırım, aynı şekilde, araçlarınızı 'küçültülmüş' kaliteye getirmek için iyileştirmeler uygulamak için gereken muazzam çaba olacaktır.

Son olarak, herhangi bir sorun size yansıyacaktır. Katran, tarbrush prensibi.

Yukarıdakiler alaycı geliyorsa, korkarım ki orada bulundum. Defalarca.

Bunun yerine ne yapmalı?

BT departmanında alışveriş yapın, kendinize yararlı bir aday bulun ve iş yükünüzü hafifletmek için bu adamı 'ödünç' tutun.

Ürün sahibinin okumasını istemeniz gereken DevOps anketi sonucunda cevapların çoğunu bulabilirsiniz . Bu, teknik bilgisi az olan iş adamları için özellikle anlaması gereken terimlerle yazılmış bir belgedir.

Ortalama olarak aynı özellik geliştirme düzeyini korumak için her 4 kişi için 1 ekstra geliştiriciye ihtiyacınız olacak (% 38'e karşı yeni işlerde harcanan zaman) Hatadan kurtulmak için ortalama süreniz 25 kata kadar düşecektir. İşiniz% 20 daha az zevkli olacak ve işinizi bir arkadaşınıza tavsiye etme olasılığınız% 40 olacak. Sadece bu üç gerçek yeterli olmalı.

BT organizasyonuna katılarak kaybedeceğiniz şey, küçük DevOps ekibinizin "Dev" kısmıdır. Takımlar NetOps, SysOps ve Dev'in yapay rollerine ayrıldığında, aşağıdaki sorunları ortaya koyarsınız:

1. Gereksiz bürokrasi ve izolasyon - Geliştiricilerin her şeyi yapabilmeleri için BT'ye bir bilet göndermeleri ve bunları uygulamalarını beklemeleri gerekecektir. Artık, hangi altyapıyı kodlayabileceklerini sınırlandıracak Dev ve QA örneklerine kadar ve bunları dahil ederek kendileri uygulayamayacak ve etkileşime giremeyecekler. Tüm yığın üzerinde kodlama yapmak yerine VM bariyerine yapışmışlardır. BT'ye gönderdikleri şey DevOps koduna benziyorsa, kodu işlemek için yetersiz donanıma sahip olacaklar ve manuel dağıtımlara geri dönebilirler.
2. İhmal - Alternatif olarak, sadece olduğu gibi konuşlandırıp daha sonra canavarı ihmal edebilirler çünkü onunla nasıl etkileşime gireceğini bilmiyorlar - ve geliştiriciler değiller, bu yüzden kod onların sorunu değil.
3. Kesintiler - DevOps'un göz ardı edilen faydalarından biri, programatik doğasıdır. Elbette, bu sunucuyu kod olarak ele alarak dağıtmak daha uzun sürebilir, ancak bu insan hatalarını otomatik hale getirir. Geliştiriciye girme şekli KG / Test'e girme yoludur, ürüne girme yoludur, böylece kesintileri azaltır. Geliştiriciler, ağ ekipmanına erişimi kaybettiklerinde, hizmetlerini veya bilgi işlem altyapısını dağıtmaları sadece daha uzun sürmekle kalmaz, aynı zamanda daha fazla kesintiye neden olacak daha yanıltıcı insanlar sunar.
4. Belgeler - Bazı açılardan, DevOps kodu kendi kendini belgelendirmektir. Kodun size söylediği için sunucunun nasıl oluşturulduğunu ve konuşlandırıldığını biliyorsunuz. 5 yıl içinde, CentOS 8'e yükseltme zamanı geldiğinde ya da her neyse, kimse artık ağınızı, depolama, izleme ve yedekleme katmanları dahil olmak üzere uygulamanızı nasıl dağıtacağınızı bilemez.

Kısacası, proje sahibinin okumak için zaman ayırmanızı öneririz gerekir Mythical Man-Ay Bir 1 göreceği onu ya kavramının onu görmesini sağlamak için: verimlilik ve 1 ilişkiyi Phoenix Projesi romanlaşan iyi (ve eğlendirici) teknik olmayan kişiler için teknik olmayan dilde DevOps kullanılarak kazanılan ve kaybedilen şeylerin gösterimi Proje sahibinin herhangi bir işe gidip gelme durumu varsa, Phoenix Project'in Audible sesli kitabı mevcuttur.

Bazı BT ekibini benimsemenizi ve yeni sistem hakkında onlara kapsamlı eğitim vermenizi öneririm.

Sistemi tam olarak anladıktan sonra, onlara boşaltmak mantıklıdır.

Aksi takdirde, BT için bir Destek Merkezi olacaksınız ve yeni sistemin inceliklerini öğrenirken çok fazla yangınla mücadele edeceksiniz.