Neden bir 'DevOps Mühendisi' tutmaya çalışmamalıyım?

Bir DevOps Mühendisi olma fikri son zamanlarda oldukça popüler hale geldi ve Kukla blogunda açıklandığı gibi DevOps'un avantajlarından faydalanabilecek ve içeri girebilecek birisinin olması çekici görünüyor :

DevOps uygulamalarını kullanan kuruluşlar son derece yüksek düzeyde işlev görüyor: 2015'teki DevOps Eyalet Raporumuza göre, kodları rakiplerinden 30 kat daha sık kullanıyorlar ve dağıtımlarının yüzde 50'si başarısız oluyor.

Bununla birlikte, bu geliştirmeleri denemek ve yapmak için bir DevOps Mühendisi fikrine çok fazla sesli muhalefet fark ettim:

Çekirdek DevOps özellikleriyle ilgili geniş kapsamlı bir anlaşmaya rağmen, tartışma, “DevOps mühendisi” terimini çevreliyor. Bazıları, terimin kendisinin DevOps değerleriyle çeliştiğini söylüyor. Continuous Delivery'nin ortak yazarı olan Jez Humble, sadece birisine DevOps mühendisi olarak adlandırmanın, dev ve op'lara ek olarak üçüncü bir silo yaratabileceğine işaret ediyor - "... açıkça bu sorunları denemek ve çözmek için zayıf (ve ironik) bir yol ."

Bir işletme için böyle bir blog tarafından savunulan örgütsel değişimin aksine, DevOps'u denemek ve 'DevOps'u uygulamak' için bir DevOps Mühendisi kiralamak neden bu kadar iyi bir fikir olmayabilir ? Yararları sadece izole edilmiş bir DevOps rolü oynayarak ihmal edilebilir mi?

TL; DR : Asla bir DevOps Ekibi tutmaya çalışmamalısınız

Aslında kiralanması gereken en yaygın üç rol vardır:

1. DevOps Mimar / Evangelist
2. DevOps Mühendisi
3. CI / CD Mühendisi

Bu roller, geleneksel olarak yazılım mühendisliği organizasyonunu oluşturan 6 temel yazılım geliştirme rolünüzden farklıdır:

1. Ürün Yönetimi
2. Yazılım geliştirme
3. Araçlar Geliştirme
4. Güvenlik ve Uyum
5. Kalite ve Test
6. Sistem İşlemleri (SRE)

Üç rolü birer birer izleyelim ve nasıl sığacaklarını görelim

DevOps Mimar veya Evangelist

• Neden : Eğer kaybedilirseniz, yavaş, kırılmış ve ne yapacağınızı bilmiyorsunuz.
• Ne zaman : Planlamanın aşamalarında sürecin başlangıcında.
• Ne : Yazılım Mühendisliği bölümündeki tüm yöneticileri ve liderleri yönlendirmek için yönetim düzeyinde rol. Bu kişi, mühendislik organizasyonunuzun tüm fonksiyonlarını yüksek işleyen bir duruma planlayacaktır.
• Kim : Danışman üyeliği teori, yönetim uygulamaları, kültür konuları ve doğrudan Yazılım Mühendisliği Başkan Vekiline rapor veren operasyonlarda uzmandır.

Bazı durumlarda ve daha küçük ve orta ölçekli şirketler için, sürece DORA gibi bir danışmanlık kuruluşunu işe almak yerine başlayabilirsiniz.

DevOps Mühendisi

• Neden :
  1. Çapraz fonksiyonel düzeyde işbirliğini sağlamak için yukarıda belirtilen fonksiyonel roller boyunca örgütlenirlerse, ekipler arasındaki boşlukları doldurmak.
  2. Takımda yer alan 6 geleneksel rolün her birine sahip ürün odaklı ekipleri yerleştirmek, bilgi boşluklarını kapatmaya yardımcı olmak ve yeni uygulamaların ve araçların uygulanması ve benimsenmesine yardımcı olmak.
• Ne zaman : Planlarınızı belirledikten ve organizasyonel dönüşüm başladığında ve tüm yönetim ekibi gemidedir.
• Ne : Çapraz işlev işbirliğini mümkün kılın, ekip sınırlarının bozulmasını sağlayın, ekiplerin içindeki yerel optimizasyonların, müşteri isteklerinden müşteri teslimatlarına kadar tüm değer zincirleri boyunca yüksek iş hacmi için bir engel oluşturmaması.
• Kim : Hem yazılım geliştirme hem de sistem operasyonlarında tecrübeli mühendis. DevOps dönüşümüyle ilgili en iyi uygulamalarda, süreçte ve kültür değişikliklerinde uzman olmalıdır.

CI / CD Mühendisi

• Neden : CI / CD boru hatlarının uygulanmasına yardımcı olmak için, takım zincirinizi entegre edin, şirketin daha iyi çalışmasını sağlayacak araçları getirin.
• Ne zaman : Büyük organizasyonda geçiş sırasında, yukarıdaki roller zaten doldurulmuşken.
• Ne : Temel olarak CI / CD boru hatlarını ayarlayabilecek ve sürtünmeyi iş akışından kaldıracak şekilde iç sistemleri entegre etmeye başlayacak araçlar ekibinin bir parçası olan Mühendis.
• Kim : Mühendis Araçlar, Entegrasyon süreci, Yayın Yönetimi ve DevOps uygulamaları ile deneyimli. Otomasyonla bırakma işleminde insan kapısını değiştirdiklerini anlayan biri.

Devops Mühendisi'nin, soru bağlantınızda tanımlandığı gibi , esasen bir sysadmin rolü olduğunu savunuyorum . Bu cevabın özü için buradaki becerileri aktarma:

Tırmanma teçhizatınız.

• Kukla, Aşçı veya benzeri bir kişi kullanan Linux / Unix Yönetim deneyimindeki otomasyon / konfigürasyon yönetimi konusundaki güçlü geçmiş
• Çok çeşitli açık kaynaklı teknolojiler ve bulut hizmetlerini kullanabilme (AWS deneyimine ihtiyaç vardır)
• SQL ve MySQL ile güçlü bir deneyim (NoSQL deneyimi de bir artı, çünkü biz de Redis kullanıyoruz)
• Bir kod ve senaryo çalışması (PHP, Python, Perl ve / veya Ruby)
• Her zaman açık, her zaman kullanılabilir bir hizmette en iyi uygulamalar ve BT işlemleri hakkında bilgi

Bu örnek iş tanımında DevOps Engineer, bulut tabanlı altyapısı, otomasyonu, tanılamaya yardımcı olacak kodları okuyabilen ve yüksek kullanılabilirlik uygulamalarının ve çözümlerinin farkında olan bir sysadmin için sadece sesli bir kelimedir.

Bu, DevOps uygulamaları ve bu soruda görüldüğü gibi dev ve op arasındaki silo kırma kültürü ile gevşek bir şekilde ilişkilidir. Sysadmin ve DevOps Mühendisi arasındaki fark nedir?

Bu iyi bir fikir olmayacak çünkü bir sysadmin, dürüst uygulama ve kültürle ne kadar rahat olabileceğini, bir şirket dönüşümü için doğru kişi değil. Bu kişiyi aklınıza gelen bir kültür değişikliği ile işe almayacaksınız ancak süreçleri kırmaya gerçekten yardımcı olmayacak bir araç konfigürasyon görünümüyle. Bu, meslektaşları tarafından da kötü bir şekilde karşılanabilir ve önceden planlanmış bir kültür değişikliği yoksa, değişime direnç göstereceksiniz.

Adananların kazançlarına doğru başarılı bir model için, @ Jiri Klouda'nın cevabı, kabul edilebilir bir DevOps Mühendisi rolüne büyük bir genel bakış ve değere yol açacağı değişim ile birlikte başarıya yardımcı olacaktır.

Bu cevabın sizin için mükemmel bir seçim olmayabilir, ama yaptığım işte

Çok yoğun bir e-ticaret başlangıcında çalışan ve yoğun trafik çeken ilk geliştiriciydim. Şirketin hala genç olduğunu farkettim ve bir süre için, kurum içi tek teknik kaynak olacağım.

Bunu bilerek, altyapımı bu şekilde yapılandırmaya karar verdim, SIFIR sistem yönetimi yapmak zorunda kalacağım.

Bulutta barındırmaya karar verdim, çünkü bunu yapmak beni sistemlerin bakımından kurtardı. Kukla tecrübesi olan bir AWS mühendisi aradım. Birlikte, bulutformasyonda kod olarak yazılmış otomatik ölçeklendirilebilir bir altyapı tasarladık. Tüm konfigürasyon dosyaları kukla içerisinde versiyonlandı.

Bu, bir geliştirici olarak, bu sapkın rolü üstlenmemi sağladı. Python, code kod açma araçları inşa ettim. Aynı betiği uygulamamı otomatik ölçeklendirilen yeni sunuculara önyüklemek için kullandım.

Bu çok işe yaradı ve bugün 3 yıl sonra hala sistem bakımı yapmıyorum. Ayda 10 saat boyunca bir sistem yöneticimiz (aynı AWS mühendisi) var ve onun sprintlerini onun için bir sıkıntı haline gelmeyecek şekilde yapılandırmaya çalışıyorum. Bu şekilde zamanına saygı duyuyorum ve sprintlerini mümkün olan en iyi şekilde yönetiyorum.

Eğer bir sistemin performansı düşmüşse, onu basitçe sonlandırırım ve onun yerine bir tane daha döner.

Umarım bu cevap bir şekilde size yarar sağlayabilir

Bir DevOps mühendisi kiralamamalısınız, çünkü DevOps bir diskin bu disiplinlerin her alanında uzman olamayacağı kadar çok çeşitli disiplinleri kapsar. Tüm esnaf bir jack işe alarak, hiçbiri bir usta işe olurdu.

DevOps, mutlaka takım bazlı bir çabadır ve bir bireyin tüm takımın beklentilerini desteklemesini beklemeniz beklenemez . DevOps'un kapsamını düşünün. Bir kişi muhtemelen yapamaz:

• [Dilde] bir rockstar geliştiricisi olun
• Tüm gerekli RFC'leri bilen bir ağ oluşturma gurusu olun
• Uzman bir Sistem Yöneticisi olun
• Uzman bir KG testcisi olun
• Veritabanı Yöneticisi Olun
• Depolama ve yedekleme konusunda uzmanım
• Site Güvenilirlik Mühendisliğini bilir
• Potansiyel olarak diğer disiplinler de

Yukarıdakilerin bir kısmı, Windows Systems Admin ve Linux / Unix System admin gibi alt disiplinlere sahip olabilir veya belki de birden fazla kodlama dili kullanabilirsiniz.

Hiç kimse, bu konuda uzman olamaz ki bu bir DevOps mühendisi için ilan veriyorsanız, DevOps ekibinizdeki en zayıf alan Networking olduğunda, bir network uzmanı için ihtiyaç duyduğunuz reklam işini çok iyi yapmıyorsunuz demektir. DevOps ekibiniz için . Hiçbir kişi DevOps ekibinde belirli bir rol için güvercin deliği olmamasına rağmen, DevOps kapsamında uzman veya konu uzmanı (KOBİ) yokmuş gibi davranarak ekibinize bir kötülük yapacaksınız. Sarkaçı bir uçtan diğerine sallamak - siloingden DevOps ekibinizdeki her rol gibi rol oynamak aynıdır - birçok soruna neden olabilir.

Ekip üyelerinin birden fazla disiplinde çapraz eğitime sahip olmaları - özellikle üst üste binen alanlarda iyi olmakla birlikte, bu kadar geniş bir bilgi birikiminde yetkin olmalarını beklemek pratik değildir.

Bu, size DevOps'un tüm yönlerini bildiğini söyleyenlerin muhtemelen size yalan söylediği anlamına gelir. Bir "DevOps Mühendisi" değil, bir DevOps ekibinde en çok çalıştığınız alanda bir uzman bulun.

ASOS'ta uygularken bu kesin zorluğu yaşadım. Bizim için amaç, kendi kendine yeten ekiplere sahip olmak ve bu nedenle özel bir role sahip olmak bir anti-patern olabilir, ancak gerçek dünyada yaşıyoruz ve iyi DevOps uygulamalarını düşünen birçok geliştirici için, temel ihtiyaçlarından değil, yardıma ihtiyaçları var. oraya gitmek.

Yaptığımız şey:

• DevOps mühendislerinin görevlerini yitirir, DevOps iş yapmamız gereken şeyler değil, hepimizin yapması gereken bir şeydir.

• Onları takımlara çıkardı, ancak sadece 3/1, bu onların yapamayacağı, ancak takımların kendilerini daha iyi hale getirmelerine ve kendi sorunlarını çözmelerine yardımcı olacak bir yetkinlik olarak görülmeleri gerektiği anlamına geliyordu (rehberlikle)

• Yetkinlik merkezi olarak hareket etmenin ve işletme ile ilgili hususları ele almanın yanı sıra tüm ekipleri etkileyen her şeyden önce merkezi bir işlevi sürdürdü.

Geliştikçe bu modeli gözden geçiririz, ancak bizim için şu ana kadar etkili bir şekilde çalışıyor.

Bunun için kesin bir cevap alabileceğinizi sanmıyorum, çünkü bir çok şey faktörü gibi görünüyor.

• DevOps uygulaması ile şirket nasıl kurulur
• Şirketin ne tür bir uygulama veya hizmet sağladığı
• Şirketinizin yapısı

Görevler için görüşme yaptım ve bir DevOps mühendisi unvanı aldım, ancak yaptığım işlerden bazıları Sys Admin çalışması. Bu, şirketin büyüklüğü ve uygulamanın akıllıca yönetildiği şeyin doğası nedeniyle sadece zorunluluktur. Görüştüğüm bazı pozisyonlarda benzer bir ünvan vardı ve daha akıllıca olan olayların gelişiminden birini arıyorlardı. Daha fazla kod yazmayı ve otomasyon yapan bir sys yöneticisini beklemiyorlardı. SRE popülerlik kazanıyor bir başlık gibi görünüyor, bu yüzden gitmek için bir yol olabilir. Son işimde Sistem Yöneticisi ve Otomasyon Mühendisi olarak kendim oldum çünkü zamanın birçoğunda amerikan ve şef yığınları yazıyordum. Şirket, herkesin uçakta olduğu ve dev'lerin operasyon boyunca çalıştığı oldukça iyi bir sapkınlık modelini takip ediyordu ama sanırım gelecekleri gelmedi.

Şimdi bu pozisyonda olduğum için, bazı otomasyonlarda kornayı giymeye çalışıyorum ve çözmemiz gereken bazı insan problemleri var. İnsanlar gelir ve gider ve iş akışlarının bazıları tasarlanmıştır, çünkü başkaları bu şekilde tasarladı, çünkü insanların nasıl çalıştığını değil.

Bu yüzden, temel olarak, iş tanımını çözmeniz ve bir şekilde ödemek zorunda olmadıkça veya bir başkasının doğru tür insanları çekeceğini düşünmemeniz durumunda, unvan için çok endişelenmemelisiniz.

DevOps'un anlamı ile ilgileniyorsanız ve "bir gerçek yolu" izliyorsanız. Bir DevOps Mühendisi kiralamamalısın. Bir Otomasyon Mühendisi veya Bir Dağıtım mühendisi veya Platform Mimarı veya ihtiyacınız olanı yapan başka roller üstlenmelisiniz.

Gerçek bir DevOps pratisyeni olmak sizin için önemli değilse, ne istersen onu çağırabilirsin.