Otomasyonun doğuşu ve iş başarısı için bir formül vaadi

Video: DevOps hakkında bilmeniz gereken 3 şey

O zamanlar Yahoo'nun fotoğraf sitesi Flickr'da teknik operasyonlar başkanı olan John Allspaw, "Operasyonların işinin siteyi istikrarlı ve hızlı tutmak olduğunu düşünmüyorum" dedi. "Bu onların işi değil. Bu bazılarınız için flaş bir haber olabilir. Operasyonların görevi işi mümkün kılmaktır."

O'Reilly'nin 2009 Velocity konferansının sahnesi Allspaw'dan, Flickr'daki meslektaşı Paul Hammond'dan ya da başka birinden bu özel açıklamayı duyan ilk yer burası değildi. Ancak dinleyiciler arasındaki birçok BT operasyon uzmanı bu mesajı sanki tamamen yeniymiş gibi duydu. Ancak bu, aksi takdirde bariz olan matematiğin zekice bir örneğinin ilk örneklerinden biriydi: Eğer operasyon personeli iş kolaylaştırıcılar ve yazılım geliştiriciler iş kolaylaştırıcılardı, daha sonra iki departmanı ayırmak buna karşı çalıştı amaç.

Allspaw bir noktada şöyle başladı: "Bu konuda gerçekten yardımcı olan şey, geliştiriciler gibi düşünen operasyon insanlarının olması." O dönemde Flickr'ın mühendislik ekibini yöneten ve Slack'te platform direktörü olan Hammond, "Ve operasyon insanları gibi düşünen geliştiriciler" diye tamamladı.

"Benim için her zaman Velocity'de John Allspaw ve Paul ile yaptığımız ilk sunuma geri dönüyoruz. Sürekli entegrasyon platformu sağlayıcısı Chef'in teknolojiden sorumlu başkanı Adam Jacob, "Hammond" dedi. ile konuşmak ZDNet Ölçeği, "Flickr'da günde on konuşlandırmayı nasıl yaptıklarını konuşuyorlardı.

Ayrıca okuyun: Agile plus DevOps yavaş ama istikrarlı bir şekilde kurumsal ölçeğe ulaşıyor

"Bu değişim, bu değişim - ki bu çok derin ve kulağa basit geliyor - operasyon personeliniz ile yazılımı geliştiren kişilerin aynı kişiler olduğu fikridir" diye devam etti. "Onların görevi, sistemin çalışmasını ve ilerlemesini sağlamak için birlikte çalışmaktır. Bunun DevOps işine başlayan herkesin ortak amacı ve hedefi olduğunu düşünüyorum. Buna istediğiniz adı verebilirsiniz ve biz de o zamandan beri bunu yapmanın ticari faydalarını ölçmeye başladık.. Ancak sattığınız şey DevOps veya DevOps'u gerçekleştiren bir şeyse, sonunda insanlara sattığınız şey, bu işbirliğini gerçeğe dönüştüren yazılımdır."

DevOps olabilecek bir şey mi? Kurulmuş, yazılım mı, eklenti mi yoksa motor mu? Daha da önemlisi, aralarında Chef'in de bulunduğu, giderek artan sayıda kuruluşun abone olduğu ardışık otomasyon platformları var. DevOps ideali için garantili teslimat araçları - ideale bağlanmanın ve onun büyüsünü kendi başına gerçekleştirmesine izin vermenin bir yolu, otomatik olarak? Görünüşe göre Jacob, DevOps'un pazarlanabilir unsurunun bir yazılım ürünü kadar ideal olmadığını öne sürüyor.

"DevOps'la ilgili birden fazla düşünce ekolü var ve bence insanların kafasını karıştıran şey de bu" dedi. JP Morgenthal, teknoloji hizmet sağlayıcısı DXC Technology'nin Uygulama Hizmetleri CTO'su (geçen yıl the HPE'nin kurumsal hizmetler bölümünün birleşmesi uzun süredir BT kanalı sağlayıcısı CSC ile birlikte). EMC'nin emektarlarından biri olan Morgenthal, DevOps konseptinin bir pazarlama mesajının amaçlarına uygun hemen hemen her şeye dönüştürülmeye açık olduğuna inandığı biliniyor. Başlığı olarak 2016 kişisel blog yazısı "Her şey DevOps ise, o zaman hiçbir şey DevOps değildir" diye itiraf ediyor.

Ayrıca okuyun:Yöneticiler DevOps'un olgunluğunu abartıyor

Karanlıkta bir yolculuk

Tek Gerçek DevOps Arayışında, kuruluştaki teknolojinin Orta Noktasındaki yolculuğumuzun dört ayağından ikincisindeyiz. Yolculuğumuzun 1. Bölümü, yaratıcılar ve operatörler arasındaki iş bölümünün orijinal kaynağını sundu: iki departmanı yeniden birleştirmeye yönelik orijinal girişime ilham kaynağı oldu - belki işbirlikçi olarak, belki de aynı kişi olarak birim.

"Yetiştirme Çiftliği" ürünlerinin Otomasyon Boru Hattının başıyla buluştuğu yer olan "Kaynak"tan başlıyoruz. "Sahneleme Alanı"ndan geçerek vadi boyunca açık bir rota gibi görünen bir yere doğru ilerliyoruz. Ve ilk büyük engelimize yaklaşmak üzereyiz.

Jacob, "Alanda bulunan ve bu ürünleri satan satıcılar için, sattıkları şeyin bu işbirliğinin araçları olduğunu düşünüyorum" dedi. "İşte bu yüzden otomasyona, kod olarak altyapıya ve sürekli dağıtım hatlarına ve görselleştirmeye benzeme eğiliminde. İşte bu yüzden DevOps meselesi bu; çünkü insanların gerçekten bir araya gelip işlerini yapmasına olanak sağlayan şey bu."

Chef'in başlıca araçlarından birine Habitat denir. İlk olarak 2016 yazında piyasaya sürülen bu sistem, bireysel uygulamalara yönelik bir altyapı konfigürasyon sistemidir. Bulut genelinde uygulamaya eşlik eden ve üzerinde çalıştığı platforma - her ne olursa olsun - muhtemelen ihtiyaç duyacağı kaynaklar hakkında talimat veren bir tür manifest içerir. Daha sonra bildirimin isteklerini karşılamak ve uygulama için kaynakları mümkün olan en iyi şekilde sağlamak platforma kalmıştır. Görünüşte bu, yetmiş yıllık sosyo-teknik teori ve insan sistemlerinin doruk noktası gibi görünmeyebilir. Ancak şunu düşünün: Eğer bir geliştirici bu manifestoyu oluşturabilecek bir operatör kadar yetenekli olsaydı ve sistem bunu yapabilirdi. uygulanmasını otomatik hale getirirseniz, Dev'i Ops'tan ayıran iş ayrımının büyük bir kısmı sağlanmış olur gereksiz.

Ayrıca okuyun:DevOps hızlanarak yeni liderlik tarzları gerektiriyor

Başka bir deyişle, Geliştirme ve Operasyon departmanlarını birleştirmenin gerçekten iyi bir nedeni, teknolojinin Operasyonların çoğunu geçersiz hale getirmesi olabilir.

Sürekli teslimat ve otomasyon alanında Chef ile rekabet etmek Kukla (eski adıyla Puppet Labs). Mühendisleri ve savunucuları, DevOps'un büyük ölçüde otomasyonla, yani Yazılımın oluşturulması, hazırlanması ve teslim edilmesinde yer alan tekrarlanabilir adımlar ve bunların olabildiğince kodlanması olası. Yakın geçmişte Puppet, otomasyonun DevOps ile ilişkili BT personeline veya belki de BT personeline uygulanabileceğini öne sürmüştü. "AppOps" adı verilen, yeni ortaya çıkan bir profesyoneller sınıfı veya bir kuruluş içinde uygulamaların üretilmesi konusunda operasyonel yetkiye sahip kişiler.

Bizimle konuşan Puppet Baş Teknik Stratejisti Nigel Kersten, DevOps'u "gevşek ve gelişen bir mühendislik koleksiyonu" olarak tanımladı. Fikirden müşteriye veya işe hızlı, güvenli ve sürdürülebilir bir şekilde gitmeye odaklanan davranışsal ve organizasyonel uygulamalar değer."

Bu, haritaların metafor olarak kullanıldığı bir seriye özel olarak uyan bir tanımdır, çünkü haritanın tamamı kesinlikle kapsanmaktadır.

Kersten, "DevOps'un tanımı açısından bu seviyede oldukça iyi bir anlaşmaya vardığımızı düşünüyorum" diye devam etti. "Ama aslında insanların şunu sormasını görüyoruz: 'Peki, nasıl başlayacağım? Devam etmek için aslında ne yapıyorum?'" İncelenen DevOps tanımlarının çoğunun otomasyonu yüksek düzeyde içereceğine inanıyor. Ancak bize, "DevOps yolculuğuna" çıktıklarından emin olmalarına rağmen henüz otomasyona başlamamış daha fazla müşteri kuruluşuyla karşılaştığını söyledi.

Ayrıca okuyun: DevOps'un önümüzdeki yıl önemli olmasının 5 nedeni

Yani DevOps uygulamalarının uygulanmasında hepsi kritik olarak gösterilen çok sayıda unsur var: "Kod olarak altyapı" var. Kaynak uygulamalarının yalnızca çalışması için değil aynı zamanda gelişmesi için de ihtiyaç duyduğu kaynaklar, bildirimler veya sözleşmeler olarak belirtilir, böylece sanal makineler etrafında oluşturulabilir. onlara. Ayrıca, çeşitli departmanların kendi aralarında benzer sözleşmeler oluşturmak için ihtiyaç duyabileceği araçlar da var. Kersten, otomatik test ve sürekli entegrasyonu örnek olarak gösteriyor.

"Tüm bunlar DevOps olarak gördüğüm şeyin tam ortasına uyuyor" dedi. "Fakat bence pek çok insanın uğraştığını gördüğümüz en önemli konu, takımlarınızı bu şekilde organize etmek. operasyonel sıkıntının paylaşıldığını ve darboğazları tespit edip çözüme kavuşturmak için bütünsel bir sistem yaklaşımını benimseyebileceğinizi onlara."

Görünüşe göre Kersten, DevOps'u şu şekilde tanımlıyor: hangi araç ve uygulama olursa olsun, İş fonksiyonlarını departmanlar arasında dağıtmayı ve departmanlar arasındaki iletişimi kolaylaştırmayı amaçlıyoruz. onlara. Tamamen bütünsel bir perspektiften bakıldığında, bu aslında yalnızca Geliştirme ve Operasyonları değil, iş dünyası ile iş arasında genel bir uyum sağlayabilecek her şeyi içerir. birimler. Ancak Kersten açıkça hizalamanın başlı başına bir amaç olmadığını belirtti; bu gibi klasik bir Michael Porter değer zinciriNihai hedef tipik olarak müşteri tarafından algılanan belirsiz değer kavramıdır.

Şef CTO Adam Jacob şöyle konuştu: "Eğer boru hatlarını sizin için çizecek yeterli sayıda insan bulursanız, zamanla hepsi gerçekten birbirine benzemeye başlar. Ancak onları tanımlamak için çok farklı kelimeler kullanıyorlar. Biri 'serbest bırakma treninden' bahsediyor, diğeri 'talep üzerine serbest bırakma'dan bahsediyor, ancak bunların boru hatları aynı. Bu sadece ne zaman tetiklenecekleri meselesi. Ancak farklı aşamalar için farklı isimler kullanıyorlar. Ve bence bu, 'Ne istersen o, dolayısıyla hiçbir anlamı yok' demenin çok kötü bir örneği. O kadar karmaşık ve o kadar çok değişken var ki asla çözemezsiniz.' Bunun doğru olduğunu düşünmüyorum. Aslında oldukça fazla ortak nokta ve gerçekten görebileceğiniz birkaç ortak model olduğunu düşünüyorum. İnsanları kendi yönlerine doğru itebilirsiniz ve işe yarayacaklardır."

Her şey DevOps ise

DXC'den JP Morgenthal, "Bana göre DevOps'a yatırım yapmak istemenizin nedeni riski azaltmaktır" dedi. "Diğer her şey, diğer tüm şeyler - kültür, ölçüm - sonuçta bundan kaynaklanıyor. Neyin riskini azaltıyorsunuz? Bir şeyi üretime soktuktan sonra başarısızlık riski. Yol boyunca basitleştiriyorsunuz, dahil ettiğiniz tekrarlanabilirlik ve otomasyonun maliyetini azaltıyorsunuz. İnsan emeğini bulmacanın dışına çıkarıyorsunuz ve ortaya çıkardığınız emek genellikle onların ortaya çıkardığı sorunu çözmeye çalışıyor."

Artık BT altyapı hizmetleri kategorisinin en büyük başarılarından biri sürekli entegrasyon ve sürekli teslimat (CI/CD, son kısım sıklıkla şu şekilde değiştirilir: sürekli dağıtım) yazılım geliştiricilerine çalışmalarını uygun bir ortamda oluşturma ve test etme araçlarını sunmasıdır. sonunda teslim edileceği veya dağıtılacağı üretim ortamlarıyla aynı veya neredeyse aynı. CI/CD, kamuoyunda çoğunlukla DevOps ile eş tutulan yazılım kategorisidir ve bundan sorumlu olabilecek yazılım markası, maskotu bir uşak olan açık kaynak projesi Jenkins'tir. 2016'daki bir teknoloji konferansında öğle yemeği sırasında katılımcılarla konuşmanın öyküsünü sık sık anlattım ve onlara bir gruba şunu sordum: kuruluşları DevOps uyguluyor ve bir kişinin şöyle yanıt verdiğini duyuyor: "Evet, DevOps'umuz var -- bu küçük uşak adamın olduğu şey, Sağ? Ayrıca SharePoint, Workday ve [Ofis] 365."

Jenkins'in ayırt edici özelliği aslında uşak değil boru hattıdır. Her ne kadar deneyimli yazılım mühendisi Martin Fowler'ın itibarı yerinde olsa da CI/CD'ye dağıtım hattı metaforunun tanıtılmasıDünya çapındaki işletmelerde bu tür boru hatlarının inşasından şüphesiz Jenkins sorumludur. Bir boru hattının her bir bölümü, başlangıçtan teste, aşamalandırma ve teslimattan üretime kadar yazılım geliştirme sürecinin kontrollü bir aşamasını temsil eder.

Forrester'ın baş analisti Robert Stroud, "Çoğu kuruluş için değişen parça, başladıkları yerdir" dedi.

Stroud, tipik bir Forrester müşterisinin firmaya yaklaşarak geliştiricilerinin Agile ilkelerini tamamen benimsediğini açıklayacağını söyledi. geliştirme (tamamen farklı bir yolculuğun konusu), ancak geliştiricilerinin süreçlerinin BT süreçleriyle uyumlu olmadığını keşfettiler operatörler. "Çoğu zaman, müşteriyi son sonuca ulaştırmak için izleyeceğimiz belirli, tanımlanmış bir strateji vardır; bu da son derece hızlı ve kaliteli bir sürümdür. Aslında daha küçük değişim parçalarını, yeni özellikleri, yeni fikirleri, net yeni fikirleri gerçekten tutarlı ve sürekli bir temelde dağıtmak istiyorlar.

Ayrıca okuyun: DevOps nedir? Çevik geliştirme ve BT operasyonlarına yönelik yönetici kılavuzu

Stroud, "Gerçek baskının geldiğini gördüğümüz yer burası" diye devam etti. "Çoğu BT kuruluşu, 'Ürün ve hizmetlerimizi değiştirebilmek istiyoruz' şeklinde işlerinden aşırı baskı görüyor Gerçekten düzenli olarak ve pazar analizimiz ve yeni özellikler açısından ortaya çıkardığımız yeni yeteneklerden yararlanın fırsatlar. Ve bu fırsatlardan bazıları işe yaramayacak, dolayısıyla muhtemelen bu yolda ilerlemeyeceğiz.'"

Forrester analisti bize müşteri firmalarının güvenilirlik ve kaliteye odaklandıklarına inandıklarını söyledi. Ancak "odaklanma" olarak geçen şey, sürece nadiren değer katan manuel kontrol ve dengelerden oluşuyordu. Stroud, "Bu manuel kontrol ve dengeleri takip etmekle o kadar meşguldüler ki, operasyon organizasyonları bunu gerçekten yapmadılar" dedi. tutarlı ortamlar ve altyapı için otomatikleştirilmiş iyi uygulamalar, böylece tekrarlanabilir, ölçeklenebilir bir temelde yapılabilir. Ayrıca yaygın bir otomasyon uygulamadılar."

Bariyerler ve korkuluklar

Splunk Baş Teknoloji Savunucusu Andi Mann, DevOps'u benimsemek isteyen şirketlerin otomasyon kısmına balıklama daldığı tam tersi bir olguyu görüyor. Kendisi buna karşı tavsiyede bulunmasına rağmen bize "Otomasyon, birçok insanın DevOps'a giriş noktası olarak geldiği yerdir" dedi. Bir şirketin yalnızca boru hatları inşa edip sonuçları göremediğini savundu; bunun yerine şirketin, birçok kişinin yabancı temsilci olarak değerlendireceği bir şeyin tanıtılmasıyla başa çıkabilmek için gerekli iç kültürel hazırlıkları yapması gerekiyor.

Ancak otomasyon "insanların daha iyi işbirliği yapmasını sağlamanın önemli bir parçasıdır; daha fazla şeyi otomatikleştirirseniz, bir takım çıktılar meydana gelir," diye devam etti, daha önce CA'da çalışmış olan Mann Teknoloji. "Birincisi, süreciniz üzerinde denetim ve kontrole sahip olmanızdır. Bu, insanları kendi kararlarını verme konusunda özgürleştirebileceğiniz anlamına gelir. Yapmaları gerekenleri bir grup korkuluk içerisinde yapabiliyorlar çünkü otomasyon bu korkulukları kurmuştur."

Bu noktada, Mann'ın tanımının gerçekten çok tanıdık bir yanı var. Bu fikir, bilimin bir çalışma sürecinin spesifik unsurlarını belirledikten sonra bu sürecin Verimlilik için kodlanabilir ve güvenilirliği sağlamak ve maliyetleri azaltmak için uzmanlar yetiştirilebilir. risk. Bu, Enid Mumford'un ilk kez 1949 gibi erken bir tarihte tanık olduğu ve verimsizliğin katalizörü olduğu anlaşılan Taylorizm'dir.

Ancak Mann'ın kendini kurtardığı yer burası: Süreçler otomatikleştirildiğinde, bu süreçleri yönetmek için gereken insan çabası miktarı da azalıyor. "İnsanların işleri kendileri için yapmalarına ve daha hızlı ilerlemelerine olanak tanıyor" diye açıkladı. "Kaliteyi artırıyor çünkü test etme, kalite kontrol ve yayınlama otomasyonunu gerçekleştiriyorsunuz. Ve belirli kalite engellerini karşılamıyorsa otomasyon onu yayınlamanıza izin vermez."

"Bu kurumsal şirketlerden birinde çalıştığınızda size işbirliği yapmamanız söylenir" dedi Chef'in kurucusu ve CTO'su Adam Jacob, "ya da size işbirliği yapmanın yolunun organizasyondan geçtiği söyleniyor çizelge. Yani yapmanız gerekenlerin bir kısmı [DevOps] iş, takımlarda yapılan bir değişikliktir. Bu işbirliği olmadan gayet iyi çalışan bir kuruluşunuz var. Siz devsiniz, küresel bir banka veya sigorta şirketisiniz, devasa bir perakendecisiniz; büyüdünüz çünkü tanımı gereği yaptığınız işte oldukça iyisiniz. 'Şu anda bunu yapma şeklimiz, bunu yapmanın en iyi yoludur' diyen önyargıyı aşmak ve bunun işe yarayacağını biliyorsunuz, yalnızca felsefede ve işbirliği yapmak isteyen insanların ruhunda değil, aynı zamanda insanların gerçekte çalışma biçiminde de bir değişiklik gerektirir. iş. Günlük işlerin eskisinden farklı olması gerekiyor. Aletlerin devreye girdiği yer burası."

Ayrıca okuyun: DevOps'u daha etkili hale getirmek için yapay zekadan faydalanma

Başka bir deyişle, işletmeler daha köklü, süreçle ilgili değişikliklerin gerçekte gerekli olduğu gerçeğini anlamalarını sağlamak için daha iyi sensörlere ve daha ilgili verilere ihtiyaç duyabilir. Yazılım ve hizmet satıcıları için bu argümanın biraz kendi çıkarlarına hizmet etme tehlikesi var: yalnızca ilk yeni araç setine olan ihtiyacı değil aynı zamanda daha sonraki setlere olan ihtiyacı anlamalarına yardımcı olacak yeni araçlar Peki. Bu arada Chef, Puppet ve DORA gibi DevOps uygulayıcıları da bunu kabul ettikleri işletmelere yanıt veriyor. Panzehirin herhangi bir sayıda kendini gösterebileceği vaadiyle önlerindeki tehlikeleri göremiyorlar. yollar. Dolayısıyla bazı firmaların neden hala şüpheci olabileceğini anlamak kolaydır.

Jacob şu umut mesajını verdi: "Başarılı modellerin sayısının sonsuz olmadığını savunuyorum. Belirli bir iş süreci için kaç tane kararlı, yüksek hızlı şekil olduğunu düşünürseniz sonsuz sayıda yoktur.

"Tam şu anda, dünyanın her yerindeki her endüstri, bu yüksek hızdaki teknoloji ilerlemesini ve Ar-Ge'yi mevcut iş süreçlerine nasıl dahil edeceklerini anlamaya çalışıyor. Zamanla bu endüstrilerin her biri istikrarlı şekilleri bulacak. Bir, iki veya üç olarak ortaya çıkabilirler. Yarım düzine olsaydı şok olurdum. Dolayısıyla burada istikrar sağlanacak."

Orta Zemin'e doğru yolculuğumuzda Kültür Uçurumunu geçmemizi sağlayan da bu uzlaşmadır.

Ayrıca okuyun:Danışmanlar ayrıldıktan sonra DevOps sürdürülebilir mi?

Keşifçi

Yolculuğumuzun bir sonraki aşamasında sadeleştirme bilimiyle ilgili olduğunu iddia eden herhangi bir teknolojinin faydalı olabilmesi için bir felsefeye ihtiyaç duyup duymadığını araştıracağız. Ve son olarak Bölüm IV'te, sizi DevOps topluluğunda önemli bir etki sahibi olan ve DevOps'un sınırlarını CIO'nun alanının ötesine taşımak için kendine meydan okuyan bir kişiyle tanıştıracağım. O zamana kadar sıkı tutun.

Tek Gerçek DevOps Arayışı

• Birinci bölüm: Yazılım geliştiricileri ve BT operatörleri için arkadaşlık hayali

Daha İleriye Yolculuk - CBS Interactive Network'ten

• "Splunk, amiral gemisi paketlerine makine öğrenimi güncellemeleri getiriyor"Natalie Gagliordi, Satır Arasında
• "Yazılım tanımlı veri merkezleri: Akıllı kişinin kılavuzu" Yazan: James Sanders, TechRepublic
• "DevOps nedir? Çevik geliştirme ve BT operasyonlarına yönelik yönetici kılavuzu"Steven J. Vaughan-Nichols, Linux ve Açık Kaynak

Başka yerde

• "Ne Kadar DevOps Verisi Toplama Yeterlidir?" Scott Fulton'ın Splunk'tan Andi Mann ve nClouds CEO'su JT Giri ile The New Stack Makers podcast'i için yaptığı röportaj.
• "Mikro Hizmetler ve Yazılım Tasarımının Yeniden Doğuşu" Yazan: JP Morgenthal, XebiaLabs Blogu
• "Cisco'nun Veri Merkezi Analitik Güncellemesi Gerçekten Sıfır Güveni Etkinleştiriyor mu?"Scott M. Fulton, III, Veri Merkezi Bilgisi

İlgili Öyküler

• Bulut güvenliğinde çevreyi aramak: Mikro hizmetlerden kaosa
• Her yerde mikro kaleler: Bulut güvenlik modeli ve yazılım tanımlı çevre
• Mikro hizmetler ve kimlik varlıklarının istilası
• Makine öğrenimi ve yanlış çözüm hayaleti

Bu Ölçek serisinin Orta Zemin haritası Katerina Fulton tarafından çizildi.