Sysadmin ve DevOps Engineer arasındaki fark nedir?

Bir işe başvururken, genellikle iki benzer iş türü bulabilirsiniz: Sysadmin Mühendisi ve DevOps Mühendisi .

Her ikisi de sunucu yapılandırması ile ilgilenir ve bilgisayar sistemlerinin güvenilir şekilde çalışmasını sağlar. İkisi arasındaki farkı söylemek zor olabilir. Aralarındaki temel farklar nelerdir?

Temelde DevOps bir rol değildir (böyle kullanıldığında gerçek bir rolden ziyade bir terimdir).

DevOps, kabaca geliştiriciler ve sistem yöneticileri arasındaki siloları kırmayı amaçlayan bir organizasyon modelidir.
Asıl amaç, tanımından, mimarlık kararlarından bu ürünün çalıştırılmasına kadar bakıma kadar bir üründen (uygulamadan) sorumlu olan devs ve sysadmins ekiplerini (genellikle test ekipleriyle birlikte) oluşturmaktır.
Ekibin her bir üyesi, ürünün tüm yaşam döngüsü konusundaki kararın bir parçası olacak, bir dev, üretimde bazı sysadmin işleri yapacak ve altyapı perspektifinden kaçınmak için ürünün tasarım aşamasına bir sysadmin katılacak. Örneğin.

İdeal olarak, bir sysadmin aynı zamanda ürün için geliştirme ekibinin bir parçası olacaktı, gerçek dünyadaki sysadmin kodunda daha fazla ürün etrafındaki konfigürasyon ve izleme çözümleri hakkında, ancak ekibin diğer üyelerine endişelerini dile getirme çok fazla yanlış anlamadan kaçınabilir. dağıtım sürecinde.

Kısa versiyon

DevOps, bir örgüt kültürü, Çevik / Yalın çalışma ve yazılım otomasyonu yöntemlerini, Sistem Yönetimine ve Operasyonlara uygulandığında bu işlevlerin Çevik veya Yalın Gelişim Ekipleri ile aynı Çeviklik düzeyinde çalışmasına izin veren bir kombinasyonunu bir araya getirir.

Uzun versiyon

DevOps'un ardındaki fikirler Sistem Yönetimi, Operasyonlar ve Çevik topluluklardan geldi, özellikle Patrick Debois , Agile2008'de , bir organizasyon içindeki üç işlevin işleyişi arasındaki farkın altını çizdiği 'Çevik Altyapı' başlıklı bir sunum yaptı :

1. Çevik Geliştirme Ekipleri - Çevik ekipler kod yazıyor.
2. Sistem Yönetimi Ekipleri - Yazılımı çalıştırmak için altyapı oluşturma.
3. Operasyon Ekipleri - Üretim / Live'daki uygulamaları ve altyapıyı desteklemek.

Debois'in önerisi, özellikle birlikte çalışan Sistem Yönetimi ekiplerini ve Operasyon ekiplerini bir Şelale Modelinden Çevik bir Modele taşımanın üç yolunu birleştirmekti . Bu amaçla, Debois'in kurulum Ghent 2009 DevOpsDays, Belçika yanlışlıkla ifade coining DevOps .

DevOps fikri, VisibleOps kitap serisinin Yazarları ile rezonansa girdi: Gene Kim, George Spafford ve Kevin Behr; Phoenix Projesi ve DevOps El Kitabı'nı yazmaya devam etti . Her iki kitap da Çevik ve Yalın'ın Sistem Yönetimi ve Operasyon ekiplerini nasıl olumlu yönde etkileyebileceğini araştırıyor.

Bir itibariyle DevOps bir Operasyonlar arka plandan gelen Mühendisi, oluşturmakta ve sunucularını ve yazılımların dağıtılması taşınmış olacak manuel için komut dosyası Bir süre sonra vb BASH, PowerShell, Python gibilerle Sunucularınıza yazılımın kurulumunu, ne fark eder harika bir komut dosyasıdır ve dağıtımı otomatikleştirmek için daha karmaşık yöntemler keşfetmeye başlar .

Sonunda, sistem filonuzun durumunu yönetmenize yardımcı olacak bir Şef, Kukla, Ansible veya başka bir konfigürasyon yönetimi aracına karar verdiniz . Uygulama dağıtımı ve sistem yönetimi otomasyonu konusundaki becerileriniz arttıkça, araçlarınızla birlikte, daha yakın zamanda ' Kod Olarak Altyapı ' alanına geçtiniz ve bunu yalnızca yazılım dağıtımını değil, gerekli altyapı ve ortamları da otomatikleştirmek için kullandınız. İşletmenin Bulut'a geçişi sırasında yazılımı sürmek için.

Şimdi gazla yemek pişiriyorsun. Zamanla , dağıtım ve yönetim araçlarınızın cephaneliğini oluşturan modülleri, tarifleri ve şablonları yönetmek için kaynak kontrolü gibi geliştirici merkezli takım kullanmanın avantajları ile tanıştınız .

Eğer içine kaydırılır zaman DevOps ekibi yazılım geliştirme yaşam döngüsü ve kavramına maruz bırakıldı sürekli entegrasyon . Evlat, bu geliştiriciler hızlı bir şekilde değişiklikleri serbest bırakıyorlardı. Geliştirme ekibine, “ kırılmadıysa, tamir etmeyin ” eski operasyonel paradigmasına karşı çıkan ALL-THE-TIME zamanını değiştirmek için aciliyet yaşadınız . Artık sistem çalışma süresi hakkında övünmek yok, tek kullanımlık altyapınız var.

Sen hiç hareket fark DevOps fazla çalışmak daha oldu devs veya kullanan yeni araçlar ve teknikler , ama ayrı bir oldu kültürel geniş organizasyon sayesinde nüfuz takımda kayması, bir. Paylaşılan sorumluluklara , paylaşılan takımlara ve paylaşılan hedeflere sahip sıkı bir ekip olarak çalışıyordunuz .

Otomatik dağıtım konusundaki becerilerinizi aldınız ve onları Jenkins , Bamboo veya Code Pipeline gibi bir " sürekli entegrasyon sunucusu " tarafından düzenlenen " CICD " boru hattına aldınız . Şimdi, geliştiriciler yeni kodlar koyduklarında, komut dosyalarınız, araçlarınız ve şablonlarınız talep üzerine yeni ortamlar oluşturur, taleplerini yerine getirmek için test çerçevelerini tetikler ve yeşil ışıklar açıklandıktan sonra üretim ortamlarını parçalara ayırır. " sürekli teslimat " fikirleri .

Yeni kod CICD aşamaları boyunca yoluna girerken, siz, geliştiriciler ve iş, güncellemenin üretime girdiğinde kırılmayacağına dair güven kazanırsınız. Ekip " sürekli konuşlandırma " almadan önce ilerlemenin bir yolu var, yine de mavi / yeşil dağıtım yeteneğini otomatikleştirmenin daha ince noktalarına karar vermeniz gerekiyor ve karar çoğunlukla bir iş. Şimdilik, saat 03: 00’deki arama sayısının azaldığı ve sev-1’lerin ve sev-2’lerin azaldığı için siz mutlusunuz.

Sev-1 elde etseniz bile, yöneticileri arkanızdan aşağı çekerken artık tüm insanları çekmiyorsunuz - önceki sürümü CICD boru hattı üzerinden kolayca serbest bırakıp sistemi kısa sürede tekrar çevrimiçi hale getirebilirsiniz. İş olduğunu fark etti istikrar BT sistemlerinin rağmen iyileşmiştir değişikliklerin hızı .

İşinizde yazılımı yönlendirmek için gereken kaynakları yönetme biçiminize, özellikle de eski haline döndüğünü ve veri merkezindeki raylarda bıraktığınız kan miktarını düşündüğünüzde ...

Sysadmin vs. DevOps (kişisel görünüm)

Bazı şirketler Dev, Ops ve Test hakkında konuşur. Bir şeyin test edilmesi gerekiyorsa, derler ki: "Test bunu yapmalı". Bir şeyin geliştirilmesi gerekiyorsa, Dev bunu yapacak ve yazılımın dağıtılması gerekiyorsa, Ops bunu yapacak.

Bence ve birkaç şirkette yaşadığım deneyimler, bunun insanlar ve takımlar arasında sürtünmeyle sonuçlanan "duvardan atma" zihniyetiyle sonuçlandığı yönünde. Şahsen, bazen insanların bireysel olarak çalıştığını hissediyorum ve yaptığım şeyin bu olduğunu söylüyor, ekip olarak çalışmak yerine yapacak hiçbir şeyim yok.

Bana göre DevOps, bir takımdaki herkesin geliştirme, test etme ve işlemlerden sorumlu ve meşgul olduğu anlamına geliyor. Takımda ben yok, ayrı bölümler yok. Herkes serbest bırakmalı. Tabii ki uzmanlıklar var, ama bence herkes her alanda bazı çalışmaların en az% 25'ini yapabilmelidir. Örneğin, eğer birisi bir gün içerisinde Geliştirici ise, biri şef ve yazılım dağıtımı gibi bazı yapılandırma yönetim kodlarını değiştirebilmelidir.

Referanslar

sistem yöneticisi

Wikipedia'ya göre :

Sistem yöneticisi veya sysadmin, bilgisayar sistemlerinin bakımı, yapılandırılması ve güvenilir şekilde işletilmesinden sorumlu olan kişidir; özellikle sunucular gibi çok kullanıcılı bilgisayarlar.

Sistem yöneticisi, yönettiği bilgisayarların çalışma süresi, performansı, kaynakları ve güvenliğinin bütçeyi aşmadan kullanıcıların ihtiyaçlarını karşılamasını sağlamayı amaçlamaktadır.

Bu ihtiyaçları karşılamak için, bir sistem yöneticisi bilgisayar bileşenlerini ve yazılımını alabilir, kurabilir veya yükseltebilir; rutin otomasyon sağlamak; güvenlik politikalarını korumak; gidermek; personeli eğitmek veya denetlemek; veya projeler için teknik destek sunmak.

DevOps

Wikipedia'ya göre :

DevOps ("geliştirme" ve "işlemler" nin kırpılmış bir bileşiği), ürün yönetimi, yazılım geliştirme ve operasyon uzmanları arasındaki iletişimi ve işbirliğini vurgulayan bir yazılım geliştirme ve dağıtım sürecidir. Bunu, yazılım oluşturma, test etme ve piyasaya sürmenin hızlı, sık ve daha güvenilir bir şekilde olabileceği bir kültür ve ortam oluşturarak yazılım entegrasyonu, test etme, dağıtım ve altyapı değişikliklerini otomatik hale getirip izleyerek desteklemektedir.

DevOps

DevOps Alet Zinciri

Bir sistem yöneticisi sunucuları korumak ve yapılandırmaktan sorumludur ve sorumlulukları kullanıcının aradıkları performans, çalışma süresi ve güvenliği ile sağlamaktır. Bir DevOps mühendisinin rolünü tanımlamak biraz daha zordur, çünkü resmi bir kariyer yolu yoktur ve DevOps'un kendisi birçok biçime sahip olabilir.

Bir DevOps mühendisi, örneğin, ağ ve dağıtım işlemleriyle ilgilenen bir geliştirici veya kodlama ve komut dosyası çalıştırma tutkusu olan bir sistem yöneticisi olabilir. Sistem yöneticisinden DevOps mühendisine geçiş çok zor değil, aslında, bu makale süreci anlatan çok iyi bir iş çıkarıyor.

Pek çok kişi, sistem yöneticisinden DevOps mühendisine bu geçişin, sistem yöneticisinin pozisyonu gelecekte kullanılmayacağından önemli olduğunu savunuyorlardı. Bakıma ihtiyaç duyan pek çok eski sunucu olsa da ve sistem yöneticileri çok sayıda "kabile bilgisine" sahip olsa da, sysadmin pozisyonu gelecekte daha az olacak.

Veri merkezlerinde yayınlanmadığını duymadığınız sunucular olacak. Her şey yazılım olacak. Depolama, ağ, sistemler, güvenlik, veri merkezleri; SDN, güvenlik duvarları, NFV, depolama, sunucular, vb. Yazılım geliştirme altyapısı olmayan Sysadmins, SDLC deneyimi (Perl, Powershell, vb. Komut dosyası yazmak bile istemiyorum) muhtemelen yok olacak. Çoğunlukla bulut olan dağıtılmış, ölçeklenebilir ve sanallaştırılmış ortamlar dikey değil yatay olarak büyür.

Sysadmins'in dikey büyüdüğünü söylemeye cüret ediyorum, DevOps (veya OpsDev) yatay büyüyor. Aynı yöntemi, mikro hizmetlerin monolitlerden nasıl geliştiğini görebilirsiniz. Operasyon / sistem ekibinden değil DevOps mühendisini yazılım ekibinden seçmeyi tercih ederim.

Operasyon / sistem ekibi sadece yazılım ekibinin oluşturduğu şeyi çalıştırır.

• Sysadmins Linux / FreeBSD / Windows çekirdeği gibi derleme / derleme yapmaz, tıpkı yazılım mühendisleri uygulamaları derler / derler.
• Sysadmins, yazılım geliştirme yaşam döngüsünden (SDLC) geçmez.
• Sysadmins üretim hattının bir parçası değildir (CI / CD işlemi).

• Cys / Sürekli Teslimat / Dağıtım sona erdikten sonra Sysadmin çalışmaya başladı.

  Dağıtım / Teslimatı kırarsanız ve atarsanız, bu kırılmış bir boru hattı olabilir
  , yazılım ekibi yaratıcı sistemdir / operasyon ekibi çoğunlukla koşucular / bakıcılardır.

Yönetilecek bir sunucu / sistem yok, sysadmin gerek yok gibi geliyor.

Sunucusuz bilgi işlem, bulut sağlayıcısının sunucu olarak hareket ettiği ve makine kaynaklarının tahsisini dinamik olarak yöneten bir bulut bilgi işlem yürütme modelidir. Ücretlendirme yerine kapasitesi önceden satın alınan ürünlerin üzerinde değil, bir uygulama tarafından tüketilen gerçek kaynak miktarına dayanır serverless işlem

Yazılım ekibinden birisi zaten nasıl kurulacağını, kodlamanın nasıl yapıldığını bile biliyor (SRE - DevOps / OpsDev).

Neden DevOps dendiğini merak ediyorum, ama OpsDev değil mi? ikisi arasındaki yön ile ilgili mi?

Hiçbir yerin ortasında, yazılım tanımlı depolama hakkında yazmaya başlamadım, bu, şimdi hakkında silinmiş bir yorumun tepkisine yol açıyor *

Yazılım tanımlı depolama hakkında

• Yazılım tanımlı depolama (SDS), temel donanımdan bağımsız olarak politika tabanlı sağlama ve veri depolama yönetimi için bilgisayar veri depolama yazılımı için bir pazarlama terimidir. Yazılım tanımlı depolama

• EMC ilk açık kaynaklı ürününü duyurdu: Project CoprHD. CoprHD bir Yazılım Tanımlı Depolama otomasyonu ve yönetim kontrolörüdür ve EMC'nin kaynak açma konusundaki son kararı, büyüme ve aşırı değişim alanına girerken küresel işletmelere daha fazla değer sağlama stratejimizin temelini oluşturmaktadır. Depolama ve bilgi yönetiminde dünyanın lideri olan EMC, Yazılım Tanımlı Depolama (SDS) konusunda öncülük etmeye devam ediyor .

• CoprHD açık kaynaklı bir yazılım tanımlı depolama denetleyicisi ve API platformudur. Blok, nesne ve dosya depolama sağlayıcıları için politika tabanlı yönetim ve depolama kaynaklarının bulut otomasyonu sağlar CoprHD