DevOps nedir ve bir DevOps mühendisinin yaptığı görevler
DevOps terimi (Geliştirme Operasyonları veya içindeki operasyonlar)
Zengin bir uygulama cephaneliği DevOps'u diğerlerine yaklaştırırAgile yöntemini kullanarak BT alanında popüler. Değişen gereksinimlere uyum sağlamanıza izin veren yinelemeli bir tasarım yaklaşımıdır. Buna göre DevOps uzmanı, ürünü daha iyi ve iş süreçlerini daha öngörülebilir ve daha şeffaf hale getirmeye çalışır. Ayrıca, Pazara Çıkma Süresinin kısaltılması gibi iş ölçümlerini de iyileştirir. Bu, ürün geliştirmenin başlangıcından pazara sunulmasına kadar geçen süredir. Yazılım oluşturma süresini uzatan faktörlere ilişkin bilgi ve sistem yaklaşımı, DevOps mühendisinin üretimi sürekli ve hızlı hale getirmesine olanak tanır. Daha net hale getirmek için, arabaları monte etmek için bir taşıma bandı ile bir benzetme yapabilirsiniz. Tüm parçalar, montaj sırasında mükemmel bir şekilde birbirine uyacak şekilde önceden tasarlanmıştır. Bir motor tasarlayan mühendisler, tekerlekler, frenler vb. İle birlikte nasıl çalıştığını düşünür. DevOps da aynısını yapar: Ürünün geliştiriciden daha fazla sorumluluğunu alır, tüm ekiplerin işbirliği yapmasını sağlar.
Pink Pony World: Moda Felsefesi Yarışı
Ancak, tüm şirketlerin DevOps'a ihtiyacı yoktur. Örneğin, dijital bir ürünün üretimine dahil olmayan önceden var olan BT departmanları olmayan ekiplerde DevOps felsefesi hiç geçerli değildir. Bu alanlar, kârları müşterilerin etkileşimde bulundukları BT ürününden ne kadar memnun olduğuna doğrudan bağlı olmayan şirketleri içerir. Ek olarak, genellikle küçük işletmeler için uygun değildir. Metodoloji, birçok yerleşik iş sürecinde ve hatta kurumsal kültürde değişiklik yapılmasını gerektirir. Küçük şirketler, proje ekonomisi açısından bu tür değişikliklere müsamaha göstermeyebilir.
Dijital dönüşümün moda hastalığı genelliklebu tür şirketlerin başkanlarıyla ilgilidir. Sonsuz optimizasyon arayışında, işi etkileyen diğer faktörleri unuturlar. Sonuç olarak, şirketler para, verimlilik ve en kötü durumda yıllar içinde oluşturulmuş iş süreçlerini kaybeder.Bilişim devleri, bankalar, büyük ticaret ve endüstriyel olaylar başka bir konudur. Onlar için DevOps çok faydalı olabilir. Böylece Alfa-Bank'ın 2017 yıllık raporuna göre metodolojinin tanıtılması, geliştirme ve uygulamayı 60 kat hızlandırmamızı sağladı.
Çalışanların atölyesi yerine Stakhanovite-mnogostanochnik
Tabii ki, bu kadar kapsamlı işlevsellik zordurçalışan başına, bu nedenle ideal olarak DevOps'a tam bir işlevler arası ekip katılır. Rollerde ve süreçte ve ürün yöneticilerinde, altyapı kod geliştiricisinde, mühendisinde ve diğer birçok rolde profesyoneller içerir. Bununla birlikte, Rus uygulamasında, bir DevOps uzmanı genellikle ürün oluşturmada tasarruf etmenin moda bir yolu olabilir. Tipik olarak bu durum, şirketin üst düzey yöneticisinin dijital dönüşüm zamanının geldiğine karar vermesinden sonra ortaya çıkar. Şirket acilen yeni uzmanları işe alıyor veya mevcut geliştiricilerin ve sistem yöneticilerinin sorumluluk listesini genişletiyor. Sonuç olarak, işe alma hizmetleri DevOps mühendisleri için değil, çok istasyonlu çalışanlar için boş pozisyonlar yaratır.
Böyle bir çalışan bireysel olarak yükümlü olabilirsunucuları kurabilir, kabloları döşeyebilir ve ardından hataları takip edebilir, veritabanları kurabilir, projeleri barındırabilir ve benzeri. Bu örnek aşırı ama gerçektir. Sonuç olarak, çalışanlar hızla tükenir ve metodolojinin şirket çalışmalarına uygulanması başarısız olur. Bir DevOps uzmanına aynı anda çok sayıda görevi yerine getirebilen bir sihirbaz gibi davranmak ve tüm sistemin işleyişini izlemek, işletmeye kar getirmeyecektir.
Diğer bir yaygın sorun şunlarla ilgilidir:takımı birbiriyle anlaşamayan iki gruba ayırmak. Bir BT şirketinin, olağan çalışma prosedürlerini değiştirmesine izin verilen bir DevOps departmanına sahip olduğunu hayal edin. Ancak bu kurallar diğer geliştiriciler için bağlayıcı olmaya devam etmektedir. Elbette bu durumda işbirliğinden ve işin "kusursuzluğundan" bahsetmeye gerek yok. İki takım çatışmaya başlar ve verimlilik düşer.
Ambarda bir varil barut: DevOps sadece beceriler değildir
DevOps departmanının görevlerinden biri,şirketin farklı BT uzmanları arasındaki iletişim. DevOps mühendisleri yalnızca teknolojileri ve hata ayıklama süreçlerini uygulamakla kalmamalı, aynı zamanda geliştirme ekibini işin gidişatına dahil etmelidir - sorumlulukları paylaşın, yetkinliklerin artırılmasına yardımcı olun. Bununla birlikte, bu tür uzmanlar genellikle hem kendileri hem de yetkinliklerinin artırılması gerekenler için sıradan zaman eksikliğinden dolayı, tamamen teknik görevlerle ilgilenirler.
Sonuç olarak, tanıtılan modaya uygun olması nedeniyleHerkes teknolojileri kullanır ve bilgi ve beceriler bir departmanda yoğunlaşır, felaket olanlar da dahil olmak üzere sorunlu durumlar ortaya çıkar. DevOps mühendisleri tarafından, farklı departmanların koordineli çalışması olmadan yaratılan yeni çözümler, başlangıçta çözmeleri gereken kadar çok sorunu getirebilir; bu, DevOps uzmanlarının, yerli olanlar sık sık düşündüğü gibi, sıfırdan bir kurumsal kültür oluşturması gerektiği anlamına gelmez. liderler. Dijital üretim hattının birliği ve yeni becerilerin ve iletişimin aktarılmasının teşvik edilmesi şirket liderlerinden gelmelidir. Bu olmadan, DevOps ekibi bile zayıf bir şekilde gelişecek ve bilgileri ekiple paylaşmayacaktır.
Ne DevOps dış kaynak kullanımı ne dedışarıdan bir uzmana danışmak. İlk durumda, dış ekip, müşteri şirketin ihtiyaçları tarafından değil, piyasada belirtilen standart teknoloji setiyle yönlendirilir. Müşteri için bu bir piyangodur: dış kaynaklı çalışanlar piyasadaki DevOps konusunda belirsiz bir anlayış kullanıyor. Sonuç olarak, iş süreçleri giderek daha karmaşık hale gelir, ancak bu işletmeye herhangi bir fayda sağlamaz. Çoğu zaman, şirketlerin kendileri bu yaklaşımı teşvik ederler - örneğin, geliştirme süreçlerini değiştirmemelerini isterler. Bunun DevOps kavramına aykırı olduğu açıktır.
Uzun, pahalı, sorunlu: Rusça'da sert DevOps
DevOps felsefesini uygulamak yerinetüm iş süreçlerinde yerli şirketler genellikle işin hızını etkilemeyecek araçlar üzerinde çalışmayı tercih ediyor. Sonuçlardan biri, örneğin, "tuğla duvar" - Operasyonlar, yani sistem yöneticilerinden oluşan ekip tecritte kalır ve geliştiriciler uygulamaları onlara fırlatır. Tabii ki, araç kutusu sonuç olarak hala gelişiyor. Bununla birlikte, temel değişiklikler gerçekleşmiyor, şeffaflık artmıyor ve BT ekip işbirliği gelişmiyor.
Karşılaştıkları başka bir engelDevOps'u uygularken yöneticiler - kurumsal bilgi tabanlarının eksikliği. 2019 DORA raporuna göre şirket içi bilgi kaynaklarını kullanan ekipler diğerlerine göre 1,73 kat daha etkili oldu. Bu sorun yine birçok Rus şirketinin ekibin bilgi paylaşmadığı kapalı kültüründen kaynaklanıyor. Bu kapalı yapı nedeniyle şirketler teknik borç biriktirmeye başlıyor. Araçlar güncelliğini yitiriyor, yapılar kaldırılmıyor, belgeler güncellenmiyor.
Üretim istikrarına ve dolayısıyla kâra yönelik nesnel iş ihtiyacı, eski bir teknoloji tabanı ve teknik borçla birleştiğinde DevOps'un başarısız kullanımına yol açmaktadır.
Tüm bunlar, genellikle uzun süren ıstıraplardan sonra DevOps ekibi tarafından sunulan yeni çözümlerin basitçe bir kenara atılmasına ve süreçlerin "geri alınmasına" yol açar.
Her şirketin kendi dijital dönüşüm yolu vardır.Çoğu durumda, kodunuzun geliştirilme ve daha iyi hale getirilme şeklini gerçekten değiştirir. Bu, DevOps'un Rusya'da hala var olduğu anlamına geliyor: her ay bu metodolojiyle ilgili birçok boş pozisyon piyasada görünüyor. Diğer bir şey de, uzmanlığın farklı tanımları ve bunların arkasında pratik görevler olmasıdır. Bununla birlikte, şirketler hayaletimsi ideal BT sistemlerini takip etmeyi bırakmalı ve kendi ihtiyaçlarına öncelik vererek, modaya uygun ancak mutlaka kârlı olmayan bir felsefeyi benimsemeye eleştirel yaklaşmalıdır.
Ayrıca bakınız:
Kara deliklerde evrenler olabilir. Size yeni keşfi anlatıyoruz
Hastalığın 3. gününde, COVID-19 hastalarının çoğu koku alma duyusunu kaybeder ve sıklıkla burun akıntısı çekerler
Araştırma: Okyanus tabanında 15 milyon ton mikroplastik bulundu