Jeff Smith ile Çarpıcı Podcast Bölüm 42: DevOps Nedir?

Bu bölümde DevOps'tan bahsediyoruz. Nedir ve web geliştirme yayınınıza eklenecek bir dize midir? Drew McLellan öğrenmek için uzman Jeff Smith ile görüşür.

Notları göster

• Twitter'da Jeff
• Jeff'in kitabı Operasyon Anti-Patterns, DevOps Solutions
• Ulaşılabilir DevOps

Haftalık güncelleme

• Matthew Talebi tarafından yazılan Tasarımcılar ve Geliştiriciler Arasındaki Boşluğu Kapatmak
• Gaurav Khanna tarafından yazılan TypeScript ile Esnek Bileşenler Oluşturmak İçin Kullanışlı React API'leri
• Cosima Mielke tarafından yazılan Ortak UI Zorlukları için Akıllı CSS Çözümleri
• Nataliya Sambir tarafından yazılan UX/UI Tasarımcılarını Değerlendirmek İçin İpuçları ve Püf Noktaları
• Arijit Mondal tarafından yazılan Next.js Destekli E-Ticaret Web Sitesinde CLS Sorunlarını Çözme

Transcript

Drew McLellan: Yolculuğunuzun neresinde olursanız olun, erişilebilir DevOps uygulamaları seviyelerine odaklanan bir DevOps uygulayıcısıdır. Dijital reklam platformu Centro'da prodüksiyon operasyonları direktörü ve aynı zamanda halka açık bir konuşmacı olarak DevOps bilgisini dünyanın her yerindeki izleyicilerle paylaşıyor. Çoğu geliştiricinin çalıştığı kusurlu ortamlarda DevOps tekniklerinin nasıl uygulanacağını gösteren Operations Anti-Patterns, DevOps Solutions for Manning Publishing adlı kitabın yazarıdır. Dolayısıyla onun DevOps uzmanı olduğunu biliyoruz, ancak George'u tanıyor muydunuz? Clooney onu bir neslin en iyi kağıt uçak üreticisi olarak mı görüyor? Smashing arkadaşlarım, lütfen Jeff Smith'e hoş geldiniz. Merhaba Jeff. Nasılsınız?

Jeff Smith: Harikayım Drew, nasılsın?

Duru: İyiyim. Teşekkür ederim. Bunu duymak güzel. Bu yüzden bugün sizinle ana kilit alanlarınızdan biri olan DevOps konusunda konuşmak istedim. Dinleyicilerimizin çoğu, web ve uygulama geliştirme ile ilgilenecek, ancak belki de işlerin operasyon tarafında neler olduğuna dair yalnızca gevşek bir aşinalığı var. Daha büyük şirketlerde çalışabilecek olanlarımızın operasyon yapan tüm meslektaşlarından oluşan ekiplere sahip olacağını biliyorum. Her ne yapıyorlarsa, iyi yaptıkları için minnettarız. Ancak DevOps'tan daha fazla bahsedildiğini duyuyoruz ve geliştiriciler olarak gerçekten anlamamız gereken şeylerden biri gibi geliyor. Jeff, DevOps nedir?

Jeff: Yani 20 kişiye DevOps'un ne olduğunu sorarsanız, 20 farklı cevap alabilirsiniz. Bu yüzden sana benim fikrimi söyleyeceğim, tamam ve bil ki bir konferanstaysanız ve bundan bahsederseniz, birisiyle yumruk yumruğa kavga edebilirsiniz. Ama benim için DevOps, gerçekten aralarındaki ilişkiyle ilgili ve biz geliştirme ve operasyonlara odaklanıyoruz, ama gerçekten ekipler arası ilişkiye ve işimizi nasıl yapılandırdığımıza ve daha da önemlisi, hedeflerimizi ve teşviklerimizi yapılandırdıklarından emin olmak için yapılandırıyoruz. ortak bir amaç için çalışıyoruz. DevOps'un temel fikir ve kavramlarının çoğu, geliştiricilerin ve operasyonların her zaman düşman olduğu, bu sürekli çatışmanın olduğu eski dünyadan geliyor. Ve bunu düşündüğünüzde, bu iki takımın teşvik edilme şekli yüzünden. Bir takım değişiklikleri zorlamak için teşvik edilir. Başka bir ekip, daha az değişiklik anlamına gelen istikrarı korumak için teşvik edilir.

Jeff: Bunu yaptığınızda, bu doğal çatışmayı yaratırsınız ve her şey oradan dışarı taşar. Yani DevOps gerçekten bu ekipleri ve hedefleri hizalamakla ilgilidir, böylece ortak bir strateji üzerinde çalışıyoruz, ancak daha sonra her iki taraftan da uygulamaları benimsiyoruz, böylece dev operasyonlar hakkında daha fazla şey anlıyor ve operasyonlar kazanç ve paylaşmanın bir yolu olarak geliştirme hakkında daha fazla bilgi sahibi oluyor. Diğer kişinin nereden geldiğinin perspektifini anlamamız için birbirimizle empati kurun.

Jeff: Ama sonra da işimizi geliştirmek için. Çünkü yine, bakış açınızı anlarsam ve çalışmamda bunu dikkate alırsam, her birimiz için çok daha faydalı olacak. Operasyonların, otomasyon ve kolayca yeniden üretilebilir olmaları için şeylere nasıl yaklaştığımız konusunda geliştiricilerden öğrenebilecekleri çok şey var. Yani bu harmanlama ve beceriler. Ve şu anda gördüğünüz, bunun farklı grup kombinasyonları için geçerli olduğu, dolayısıyla DevSecOps, DevSecFinOps, DevSecFinHROps gibi şeyler duyuyorsunuz. Sadece büyümeye, büyümeye ve büyümeye devam edecek. Yani bu gerçekten tüm organizasyona damgasını vurabileceğimiz bir ders.

Drew: Yani geliştiriciler olarak anladığımız bazı kavramları alıp fikirlerimizi organizasyona daha da yaymak ve aynı zamanda operasyonlardan herkesi ileriye taşımak için neler yapabileceğimizi öğrenmek.

Jeff: Kesinlikle, evet. Operasyonların başka bir yönü ve girişte biraz bahsetmiştiniz, bunun sadece özel operasyon ekipleri olan bu büyük organizasyonlar ve bunun gibi şeyler için olduğunu düşünüyoruz, ancak düşünülmesi gereken bir şey, organizasyonunuzda operasyonlar oluyor, boyutu ne olursa olsun. Bu sadece sizin yapmanız veya bunu yapan ayrı bir ekip olup olmaması meselesi, ancak bir şekilde kodu dağıtıyorsunuz. Her nasılsa dışarıda bir yerde çalışan bir sunucunuz var. Yani operasyonlar, büyüklüğü ne olursa olsun, kuruluşunuzun bir yerinde bulunur. Soru şu ki, bunu kim yapıyor? Ve tek bir kişi veya tek bir grupsa, ops'un yaptığı şeylerin türlerini anlamanız gerektiğinden DevOps sizin için daha da belirgin olabilir.

Drew: Profesyonel geliştiriciler olarak, DevOps'un ne olduğunu ve uygulamanın ne anlama geldiğini iyi kavramanın bizim için ne kadar önemli olduğunu düşünüyorsunuz?

Jeff: Bunun özellikle DevOps yolculuğunun bu aşamasında çok önemli olduğunu düşünüyorum. Ve bunun önemli olduğunu düşünmemin nedeni şu ki, meslektaşlarımızın ne yaptığını anladığımızda her zaman daha verimli olduğumuzu düşünüyorum. Ancak diğer şey, tasarım geliştirmeniz ve herhangi bir teknolojinin uygulanması sırasında operasyonel endişeleri dikkate alabilmektir. Kariyerimde öğrendiğim bir şey var ki, geliştiricilerin evrenin efendileri olduğunu düşünmeme ve bilgisayarlarla ilgili her şeyi anlamama rağmen, aslında durumun böyle olmadığı ortaya çıktı. Anlaşılan o ki, anlama açısından operasyonlara dış kaynak sağladıkları pek çok şey var ve bazen bu, bir üretim dağıtımı için optimal olmayabilecek belirli tasarım seçenekleri veya uygulama seçenekleriyle sonuçlanıyor.

Jeff: Geliştirme, test etme ve bunun gibi şeylerde iyi olabilirler, ancak bir kez üretime geçtiğinizde, biraz farklı bir oyun oluyor. Bu nedenle, tüm bu uzmanlığa sahip olmaları gerektiğini söylememekle birlikte, en azından neyi bilmediklerini bilecek kadar bilgiye ihtiyaçları vardır. Bu nedenle, operasyonları ne zaman erken devreye alacaklarını biliyorlar, çünkü bu, geliştirmenin bir seçim yaptığını gördüğümüz yaygın bir kalıptır. Bir seçim yapın bile demeyeceğim çünkü bunun bir seçim olduğunun farkında değiller, ancak operasyonlar için optimal olmayan bir karara yol açan bir şey var ve geliştirme tamamen habersizdi. Bu yüzden operasyonlar hakkında biraz daha fazla bilgiye sahip olmak, ilerlemeye devam etmeden önce belki de operasyonları onların bakış açısını elde etmek için buraya getirmeliyiz demek yeterli olsa da. Bu, piyasaya sürdüğünüz ürünlerle ilgili olduğu için çok fazla zaman, enerji ve istikrar tasarrufu sağlayabilir.

Drew: Geliştirme ve operasyonlar arasındaki ilişki hakkında konuşma şeklinle, bizim tasarım ve geliştirme arasındaki ilişkiden bahsetme şeklinle pek çok paralellik görüyorum, tasarımcıların belki bir arayüzün nasıl çalıştığı ve göründüğü ve iyi bir anlayışa sahip olduğu üzerinde çalıştığı yer. Bunun geliştirme rolünde gerçekte nasıl oluşturulacağına dair ve geliştiricileri danışmaya getirmek, yalnızca bu net iletişime sahip olarak ve birbirlerinin ne yaptığını anlayarak genel çözümü gerçekten iyileştirebilir. DevOps'ta da aynı prensip geçerli gibi görünüyor ve bunu duymak gerçekten çok güzel.

Drew: DevOps hakkında duyduğum şeyleri düşündüğümde Kubernetes, Docker, Jenkins, CircleCI gibi terimler duyuyorum. Yıllardır Kubernetes hakkında bir şeyler duyuyorum. Hala ne olduğu hakkında hiçbir fikrim yok, ama söylediklerinize bakılırsa DevOps sadece... Burada sadece araçlardan bahsetmiyoruz, değil mi? Ama daha çok süreçler ve iş akışları üzerinde iletişim kurma yolları hakkında, değil mi?

Jeff: Kesinlikle. Bu yüzden son 20 yıldır mantram her zaman insan işleme araçları olmuştur. İnsanların vizyona katılmasını sağlarsınız. Oradan, bu vizyona ulaşmak için sürecinizin nasıl görüneceğini tanımlarsınız. Ardından, süreciniz ne olursa olsun modelleyecek araçları getiriyorsunuz. Bu nedenle, araçları DevOps görüşmesinin sonuna her zaman koyarım, çünkü esas olarak bu katılımınız yoksa, bunun bir önemi yoktur. Şimdiye kadarki en büyük sürekli dağıtım hattını bulabilirdim, ancak insanlar her değişikliği doğrudan üretime gönderme fikrine kapılmazlarsa, önemli değil, değil mi? Alet ne işe yarar? Dolayısıyla bu araçlar, yalnızca tanımladığımız bazı ortak hedeflere ulaşmanın standartlaştırılmış bir yolu oldukları için kesinlikle konuşmanın bir parçasıdır.

Jeff: Ancak, tanımlanan hedeflerin kuruluşunuz için anlamlı olduğundan emin olmalısınız. Belki sürekli dağıtım sizin için bir anlam ifade etmeyebilir. Belki her değişikliği çıktığı anda göndermek istemezsiniz. Ve bunu yapmak istememeniz için birçok şirket ve kuruluş ve neden var. Bu nedenle, sürekli dağıtım hattı gibi bir şey sizin için mantıklı olmayabilir. Bu nedenle araçlar önemli olsa da, kuruluşunuz için değer sağlayacak şeyin ne olduğuna odaklanmak ve ardından bunu başarmak için gerekli araçları modellemek ve uygulamak daha önemlidir.

Jeff: Ama internete girip herkesin ne yaptığını öğrenip, ah, şey, eğer DevOps yapacaksak Docker ve Kubernetes'e geçmeliyiz çünkü alet zinciri bu. Hayır bu o değil. Bu şeylere ihtiyacınız olmayabilir. Herkes Google değil. Herkes Netflix değil. Netflix ve Google'dan gelen gönderileri okumayı bırakın. Lütfen onları okumayı bırak. Çünkü bu insanları heyecanlandırıyor ve onlar da, yapmamız gereken şey bu. Ve sanki, şey, sizin sahip olduğunuz problemlerden çok farklı problemleri çözüyorlar.

Drew: Yani yeni bir projeye başlıyorum dersek, belki bir hizmet ürünü olarak yazılım üreten bir başlangıç ​​işiyim. Üç geliştiricim var, boş bir Git depom var ve halka arz hayallerim var. Bu ürünü oluştururken bir DevOps yaklaşımına tamamen dahil olmak için, insanlar ve süreçler açısından yerleştirmem gereken yapı taşlarının adları nelerdir ve nereden başlamalıyım?

Jeff: Özel örneğinde, başlayacağım ilk yer, mümkün olduğu kadar çoğuna bahis yapmak ve Heroku gibi bir şey veya buna benzer bir şey kullanmak. Çünkü tüm bu AWS işleri, Docker işleri ve gerçekte sadece başarılı bir ürün oluşturmak çok zor. DevOps kısmına odaklandığınız fikri, aslında bir acı noktası haline gelene kadar bu şeylerin mümkün olduğunca çoğunu dış kaynak olarak söyleyebilirim. Ama tamam dediğin noktadaysan, bu şeyleri evde almaya hazırız ve bir sonraki aşamaya geçmeye hazırız. Başlamak için ilk yerin, ağrı noktalarınız nerede olduğunu söyleyebilirim. size sorun çıkaran şeyler nelerdir?

Jeff: Yani bazı insanlar için otomatik test kadar basit. Birisi taahhütte bulunduğunda testler yapmamız gerektiği fikri, çünkü bazen daha önce yazdığımız birim testlerine yakalanan şeyler gönderiyoruz. O zaman belki de sürekli entegrasyonla başlarsınız. Belki dağıtımlarınızın tamamlanması saatler alıyor ve bunlar çok manuel, o zaman odaklandığınız yer burası ve diyorsunuz ki, tamam, bunu tek tuşla bir iş haline getirebilmek için hangi otomasyona ihtiyacımız var? Ama bir general yazmaktan nefret ediyorum, işte burada başlıyorsunuz, çünkü özel durumunuz ve özel acı noktalarınız farklı olacak. Ve mesele şu ki, eğer bu bir acı noktasıysa, size bağırıyor olmalı. Kesinlikle sana bağırıyor olmalı.

Jeff: Birisinin, ah, organizasyonunuzda ne berbat? dediği şeylerden biri olmalı. Ve şöyle olmalı, oh, bunun tam olarak ne olduğunu biliyorum. Dolayısıyla, konuya bu perspektiften yaklaştığınızda, DevOps araç kutusunda paketi açmanız ve çalışmaya başlamanız gereken şeyler açısından sonraki adımların sizin için oldukça belirgin hale geldiğini düşünüyorum. Ve sonra, gelmeye devam eden bu minimal artımlı değişiklikler olur ve yeni yetenekler kazandıkça, standart altı şeylere olan iştahınızın çok azaldığını fark edersiniz. Yani, evet, konuşlandırmalar üç saat sürüyor ve sorun değil. Bunun için biraz çaba harcarsın ve bildiğin bir sonraki şey, üç hafta içinde şöyle olursun, dostum, konuşlandırmanın hala 30 dakika sürdüğüne inanamıyorum. Bunu 30 dakikadan nasıl indirebiliriz? İştahınız gelişme için doyumsuz hale gelir. Yani işler bir şekilde oradan dışarı dökülüyor.

Drew: Son kitabınızı okuyordum ve bu, DevOps'un dört sütunu dediğiniz şeyin altını çiziyor. Ve bunların hiçbiri, belirtildiği gibi araç değildir, ancak isterseniz DevOps için bu dört ana odak alanı vardır. Bunlardan ilkinin kültür olduğunu fark ettim, buna çok şaşırdım, öncelikle aletlerden daha çok bahsetmenizi bekliyordum ve şimdi nedenini anlıyoruz ama kültüre gelince, bu biraz garip geliyor. başında olması gereken şey. Teknik bir yaklaşım için bir temel var. Kültür, bir kuruluş içinde DevOps uygulamasının ne kadar başarılı olabileceğini nasıl etkiler?

Drew: … DevOps uygulamasının bir kuruluş içinde ne kadar başarılı olabileceği.

Jeff: Kültür, düşündüğünüzde gerçekten her şeyin temelidir. Ve bu önemlidir çünkü kültür ve biz buna kitapta biraz daha derine iniyoruz, ancak kültür gerçekten organizasyon içindeki normlar için zemin hazırlıyor. Doğru. Muhtemelen, otomatik test olmadan bir Halkla İlişkiler gönderdiyseniz, bunun büyük bir şey olmadığı bir şirkette bulundunuz. İnsanlar bunu kabul eder ve yoluna devam eder.

Jeff: Ama bunun en büyük günah olduğu başka örgütler de var. Doğru. Bunu nerede yaptıysanız, “Vay canına, sen deli misin? Ne yapıyorsun? Burada test vakası yok.” Doğru. Kültür bu ama. Bu, normu "Bizim yaptığımız bu değil" demeye zorlayan kültürdür.

Jeff: Herkes otomatik test senaryolarına sahip olacağımızı söyleyen bir belge yazabilir, ancak organizasyonun kültürü bu mekanizmayı insanlar arasında zorlayan şeydir. Bu, kültürün neden bu kadar önemli olduğuna dair küçük bir örnek. Kültürün bir korku kültürü, bir intikam kültürü olduğu bir organizasyonunuz varsa. Sanki bir hata yaparsan, doğru, bu saygısızlıktır. Doğru. Bu ihanetle eş anlamlıdır. Doğru.

Jeff: Bu organizasyonda, riskli veya potansiyel olarak başarısız olabilecek her şeye ters olan davranışlar yaratırsınız. Bu da masada pek çok fırsat bırakarak sona eriyor. Oysa başarısızlıktan öğrenmeyi kucaklayan bir kültür yaratırsanız, insanların deney yapabileceği bu psikolojik güvenlik fikrini benimser. Ve eğer yanılıyorlarsa, nasıl güvenli bir şekilde başarısız olacaklarını anlayabilir ve tekrar deneyebilirler. Bir deney kültürü elde edersiniz. İnsanların yeni fikirlere açık olduğu bir organizasyona sahip olursunuz.

Jeff: Sanırım hepimiz şu şirketlerde bulunduk, "Pekala, bu iş böyle yapılır. Ve bunu kimse değiştiremez.” Doğru. Bunu istemiyorsunuz çünkü dünya sürekli değişiyor. Bu nedenle kültürü öne ve merkeze koyarız, çünkü bir organizasyondaki davranışların çoğu var olan kültür nedeniyle vardır.

Jeff: Ve mesele şu ki, kültürel aktörler iyi ya da kötü olabilir. Doğru. İronik olan ve kitapta bundan da bahsediyoruz, organizasyon kültürünü değiştirmek için düşündüğünüz kadar çok insan gerekmiyor. Doğru. Çünkü çoğu insan, kötüleyenler var ve sonra destekçiler var ve sonra herhangi bir değişiklik söz konusu olduğunda çit bakıcıları var. Ve çoğu insan çit bakıcısıdır. Doğru. Teraziyi gerçekten devirmek için sadece bir avuç destekçi gerekir. Ama aynı anlamda, teraziyi devirmek için gerçekten sadece bir avuç kötüleyici gerekiyor.

Jeff: Sanki kültürü daha iyiye doğru değiştirmek çok fazla zaman almıyor. Ve bu enerjiyi, kıdemli bir lider olmadan bile içine koyarsanız, ekibinizin kültürünü gerçekten etkileyebilirsiniz, bu da daha sonra bölümünüzün kültürünü etkilemekle sonuçlanır ve bu da daha sonra organizasyonun kültürünü etkiler.

Jeff: Bu kültürel değişiklikleri, yalnızca bu fikirleri ve bu davranışları yüksek sesle benimseyerek ve "Bundan elde ettiğimiz faydalar bunlar" diyerek, bireysel katkı sağlayan biri olarak yapabilirsiniz. Bu yüzden kültürün ön planda olması gerektiğini düşünüyorum çünkü herkesin bu fikre katılmasını sağlamalısınız ve bir organizasyon olarak bunun değerli olacağını ve onu destekleyeceğini anlamaları gerekiyor.

Duru: Evet. Bu bir yaşam tarzı olmalı, sanırım.

Jeff: Aynen.

Duru: Evet. Otomasyon alanıyla gerçekten ilgileniyorum çünkü kariyerim boyunca, hiçbir otomasyonun devreye sokulmuş ve faydasız olduğunu hiç görmedim. Doğru. Yani, bir şeylerin otomatikleşmesi ve ters gitmesi gibi tuhaf bir durum dışında. Genel olarak, oturup manuel olarak yaptığınız bir şeyi otomatikleştirmek için zaman ayırdığınızda, size her zaman zaman kazandırır ve kafa boşluğundan tasarruf etmenizi sağlar ve bu sadece omuzlarınızdan bir yüktür.

Drew: Bir DevOps yaklaşımı benimserken, iş akışlarınızda ne tür şeyleri otomatikleştirmek istersiniz? Ve işleri manuel olarak tamamlamanın bundan ne gibi kazançlar elde etmesini beklersiniz?

Jeff: Otomasyon söz konusu olduğunda, sizin açınızdan, otomasyonun hayatı daha iyi hale getirmediği bir zaman çok nadirdir. Doğru. İnsanların karşılaştığı zorluk, bu otomasyonu oluşturmak için zaman bulmaktır. Doğru. Ve genellikle, şu anki işimde, bizim için aslında talebin amacı bu. Doğru. Çünkü bir noktada, “Bunu manuel olarak yapmayı bırakacağım ve otomatikleştireceğim” demeniz gerekiyor.

Jeff: Ve "Biliyor musun? Bu iki hafta sürecek. Normalde bunu birkaç saat içinde tersine çevirdiğimizi biliyorum, ancak otomatik hale gelen istek bu olduğu için iki hafta sürecek." Neyi otomatikleştirdiğinizi belirleme açısından. Central'da, temel olarak, diyelim ki dört haftalık bir süre içinde gelen tüm farklı talep türlerini örnekleyeceğim süreci kullanıyorum. Bunları planlı çalışma, plansız çalışma, katma değerli çalışma, zahmetli çalışma olarak sınıflandırırdım. Zahmet etmek gerçekten yararlı olmayan bir iş, ama nedense benim organizasyonum bunu yapmak zorunda.

Jeff: Ve sonra, "Tamam, bunu otomatikleştirecek olursak kurtulabileceğimiz düşük asılı meyve nedir? Bunu basitleştirmek için ne yapabiliriz?” Ve bazı kriterler sürecin riskiydi. Doğru. Otomatik veritabanı yük devretme işlemleri biraz korkutucu çünkü bunları çok sık yapmıyorsunuz. Ve altyapı değişiklikleri. Doğru. “Bunu ne sıklıkla yapıyoruz?” diyoruz. Yılda bir kez yapıyorsak, otomatikleştirmeye değmeyebilir çünkü çok az değeri vardır. Ama ayda iki, üç kez aldığımız şeylerden biriyse, tamam, şuna bir bakalım. Tamam.

Jeff: Şimdi, bunu hızlandırmak için yapabileceğimiz şeyler nelerdir? Ve olay şu ki, otomasyon hakkında konuştuğumuzda, anında "Bir düğmeye basacağım ve bu şey sihirli bir şekilde yapılacak" a atladık. Doğru. Ancak, eğer mideniz bulanıyorsa, otomasyonda yapabileceğiniz pek çok farklı adım var. Doğru. Örneğin, normalde çalıştıracağınız 10 farklı CLI komutuyla 10 adımınız olduğunu varsayalım. İlk otomasyon adımınız, o komutu çalıştırmak veya en azından o komutu göstermek kadar basit olabilir. Doğru. De ki, “Hey, bunu uygulayacağım. Sence tamam mı?" "Evet." "Peki. Aldığım sonuç bu. Devam etmem uygun mu?" "Evet." "Peki. Aldığım sonuç bu." Doğru.

Jeff: Bu şekilde hala biraz kontrolünüz var. Rahat hissediyorsun. Ve 20 infazdan sonra, sadece evet, evet, evet, evet, evet, evet'e vurduğunuzu fark ediyorsunuz. "Pekala. Bütün bunları birbirine zincirleyelim ve hepsini bir yapalım.” Derinlere atlamanız, tıklamanız ve yırtıp hemen unutmanız gerekmiyor. Kendinizi rahat hissedene kadar buna adım atabilirsiniz.

Jeff: Bunlar, otomasyon çabamızın bir parçası olarak yaptığımız şeylerdi, bunun geri dönüş süresini nasıl hızlandırırız ve kendi tarafımızdaki çaba seviyesini nasıl azaltırız? İlk gün %100 olmayabilir, ancak hedef her zaman %100'e ulaşmaktır. Kendimizi rahat hissettiğimiz kısımlarını otomatikleştireceğimiz küçük parçalarla başlayacağız. Evet. Bunun işe yarayacağından son derece eminiz. Bu kısımda biraz şüpheliyiz, bu yüzden devam etmeden önce belki biraz insan doğrulaması alırız.

Jeff: Otomasyon hakkında konuştuğumuz diğer bir şey de, belirli bir sürece kattığımız değer nedir? Ve bu, operasyonlar için özellikle dikkat çekicidir. Çünkü çoğu zaman operasyonlar bir süreç için aracı görevi görür. O zaman onların katılımı, bir erişim meselesinden başka bir şey değildir. Doğru. Sanki, operasyonlar bunu yapmak zorunda çünkü operasyonlar erişimi olan tek kişi.

Jeff: Şey, insanların bunu yapabilmesi için bu erişimi nasıl dışarıdan temin ederiz? Gerçek şu ki, geliştiricilerin üretim erişimine sahip olması konusunda endişelenmiyoruz. Doğru. Geliştiricilerin sınırsız üretim erişimine sahip olması konusunda endişeliyiz. Ve bu gerçekten bir güvenlik meselesi. Doğru. Alet kutumda sadece keskin bıçaklar varsa, bunu kime vereceğim konusunda çok dikkatli olacağım gibi. Ama eğer alet kutusunu bir kaşık ve bir çekiçle karıştırabilirsem, insanların bu iş için doğru aleti seçmelerini sağlayabilirsem, o zaman onu ödünç vermek çok daha kolay olur.

Jeff: Örneğin, insanların herhangi bir nedenle üretimde geçici Ruby betikleri çalıştırması gereken bir sürecimiz vardı. Doğru. Verileri temizlemeniz gerekiyor, bazı kötü kayıtları düzeltmeniz gerekiyor, her neyse. Ve bu her zaman ekibimden gelirdi. Ve sanki, bu bileti onaylayamadığım için buna herhangi bir değer katmıyoruz. Doğru. Hiç bir fikrim yok. Yazılımı sen yazdın, o halde omzunun üzerine oturup "Eh, bence bu güvenli" dememin ne faydası var? Doğru. Yazmaya herhangi bir değer katmadım çünkü tam olarak yazmamı söylediğin şeyi yazıyorum. Doğru.

Jeff: Ve en kötüsü, ve sonunda, gerçekten senin için bir barikatım çünkü bir bilet gönderiyorsun, sonra da benim öğle yemeğinden dönmemi bekliyorsun. Öğle yemeğinden döndüm, ama üzerinde çalışmam gereken başka şeyler var. "Bunu nasıl otomatikleştirebiliriz ki, bunu geliştiricilerin eline verirken aynı zamanda sahip olabileceğimiz bu denetim endişelerinden herhangi birini ele alabiliriz?" dedik.

Jeff: Bunu bir JIRA iş akışına yerleştirdik, burada JIRA biletinde belirtilen komutları yürütmeyi otomatikleştirecek bir botumuz vardı. Ve sonra JIRA biletinde birkaç üst düzey mühendisten birinin onayını gerektirdiğini belirtebiliriz. Doğru.

Jeff: Bir mühendisin başka bir mühendisin çalışmasını onaylaması, bağlamı olduğu için daha mantıklı. Doğru. Operasyonları beklemek zorunda değiller. Denetim parçası yanıtlanmıştır, çünkü JIRA'da tanımlanmış ve birisinin talep ettiği gibi biri onayladıkça belgelenen net bir iş akışına sahibiz. Ve bu komutu çeken ve bu komutu aynen terminalde yürüten otomasyonumuz var. Doğru.

Jeff: Yanlış yazmam konusunda endişelenmene gerek yok. Yanlış bileti kapacağım diye endişelenmene gerek yok. Bu, biletlerin geri dönüş süresini on kat artırdı. Doğru. Geliştiricilerin engellemesi kaldırılmıştır. Ekibim bunu yapmakla meşgul değil. Ve gerçekten tek gereken, otomasyonu gerçekten geliştirmek için bir veya iki haftalık bir yatırımdı ve onların buna erişmelerini sağlamak için gerekli izinleri aldı.

Jeff: Şimdi bundan tamamen uzaklaştık. Ve geliştirme, aslında bu işlevselliğin bir kısmını organizasyonun alt bölümlerine dış kaynak sağlayabilir. Müşteri hizmetlerine yönlendirdiler. Müşteri hizmetleri, bu kaydın her ne olursa olsun güncellenmesi gerektiğini bildiğinde, geliştirmeye ihtiyaçları yoktur. Bu işlev için onayladığımız standart komut dosyalarını gönderebilirler. Ve bunu, geliştirmenin yaptığı iş akışıyla tamamen aynı şekilde çalıştırabilirler. Gerçekten her yerde bir nimet.

Jeff: Ve sonra, işi organizasyon genelinde alçaltmamıza izin veriyor. Çünkü biz bunu yaptıkça iş daha ucuz ve daha ucuz hale geliyor çünkü bunu çalıştıran süslü, pahalı bir geliştiricim olabilir. Doğru. Veya doğrudan müşteriyle çalışan bir müşteri hizmetleri görevlisine, bir sorunu düzelten bir müşteriyle telefonda konuşurken kendilerinin yönetmesini sağlayabilirim.

Jeff: Otomasyon, bence, herhangi bir organizasyonun anahtarıdır. Ve bu konuda söyleyeceğim son nokta, uzmanlık ihraç etmenize de olanak tanıyor. Doğru. Şimdi, komut satırında bir sürü komut yapmam gerekirse, bunu nasıl yapacağımı bilen tek kişi olabilirim. Ama bunu otomasyona koyarsam, bunu herkese verebilirim. Ve insanlar nihai sonucun ne olduğunu biliyorlar, ancak tüm ara adımları bilmeleri gerekmiyor. Değerimi organizasyona aktararak ve uzmanlığımı alıp ihraç edilebilir bir şeye kodlayarak on kat arttırdım.

Drew: Sık sık meydana gelen görevleri otomatikleştirmekten bahsettiniz. Bir geliştiricinin nasıl çalışması gerektiği konusunda yeniden hız kazanması oldukça uzun zaman alacak kadar seyrek gerçekleşen görevleri otomatikleştirmek için bir argüman var mı? Çünkü herkes unutulmuştur. Çok uzun zaman oldu. Bir yıl oldu, belki daha önce kimse yapmamıştır. Bu tür şeyleri de otomatikleştirmek için bir argüman var mı?

Jeff: Bu zor bir dengeleme eylemi. Doğru. Ve her zaman duruma göre ele alın derim. Ve bunu söylememin nedeni, DevOps'taki mantralardan biri, eğer acı verici bir şey varsa, bunu daha sık yapmaktır. Doğru. Çünkü bunu ne kadar sık ​​yaparsanız, o kadar fazla kas hafızası olur ve bu bükülmeleri çözer ve giderirsiniz.

Jeff: Çok seyrek görevleri otomatikleştirirken gördüğümüz sorun, çevre manzarasının bu otomasyonun yürütülmesi arasında değişme eğiliminde olmasıdır. Doğru. Sonunda, kodunuz çevre hakkında belirli varsayımlar yapar ve bu varsayımlar artık geçerli değildir. Böylece otomasyon her halükarda bozulur.

Drew: Ve sonra iki problemin var.

Jeff: Doğru. Doğru. Kesinlikle. Kesinlikle. Ve siz, “Yanlış mı yazdım? Yoksa bu mu? Hayır, bu şey aslında bozuk." Böyle-

Jeff: Yanlış mı yazıyor yoksa bu hayır mı, bu şey gerçekten bozuk. Bu nedenle, sık görülmeyen görevleri otomatikleştirme söz konusu olduğunda, bu işe yaramazsa riskin ne olduğunu anlamak için gerçekten vaka bazında ele alıyoruz, değil mi? Yanlış anlarsak, kötü bir durumda mıyız yoksa sadece bu görevi tamamlamamış mıyız? Bu nedenle, bunun zarif bir şekilde başarısız olacağından ve olumsuz bir etkisi olmayacağından emin olabilirseniz, otomatikleştirmeye bir şans vermeye değer. Çünkü en azından, o zaman ne olması gerektiğine dair bir anlayış çerçevesine sahipsiniz çünkü en azından birisi kodu okuyabilecek ve anlayabilecek, tamam, yaptığımız şey buydu. Ve bunun neden artık işe yaramadığını anlamıyorum, ama en azından bunun yazıldığı tasarım zamanında ne olması gerektiğine dair net bir anlayışa sahibim.

Jeff: Ama eğer bir hatanın veri değişikliklerine ya da buna benzer bir şeye yol açabileceği bir durumla karşılaşırsan, genellikle dikkatli olmakta ve manuel olarak tutuyorum çünkü eğer bir otomasyon betiğim varsa, eğer bir izdiham belgesi bulursam bu senaryoyu çalıştır diyen üç yaşında, bu senaryoya yüzde yüz güveniyorum ve onu yürütüyorum. Doğru. Dört yıl önce belgelenmiş bir dizi manuel adımsa, burada biraz doğrulama yapmam gerekiyor gibi olacağım. Doğru? Bu konuyu biraz açayım ve birkaç kişiyle konuşayım. Ve bazen süreçleri tasarladığımızda, bu düşünce sürecini zorlamaya değer, değil mi? Ve insan bileşenini ve nasıl davranacaklarını düşünmelisiniz. Ve bazen insanları bunu şimdi yapmalı mıyım diye düşünmeye zorlamak için süreci biraz daha hantal hale getirmeye değer mi?

Drew: Sistemlerinizi izleyerek ve bir şeyleri ölçerek neyin otomatikleştirilmesi gerektiğini belirlemenin başka yolları var mı? Demek istediğim, DevOps'u düşünüyorum ve panoları güzel grafiklerden biri olarak düşünüyorum. Ve eminim bu panolarda güzel görünmekten çok daha fazlası vardır, ancak güzel görünen panolara sahip olmak her zaman güzeldir. Bu tür kararları vermenize yardımcı olmak için bir sistemin ne yaptığını ölçmenin yolları var mı?

Jeff: Kesinlikle. Ve bu tür kameraların metrik kısmına girer, değil mi, verimli çalıştıklarını bilmek için sistemlerimizde izlediğimiz şeyler nelerdir? Ve metriklerin yaygın tuzaklarından biri, başarıyı doğrulamak yerine hataları aramamızdır. Ve bunlar çok farklı iki uygulama, değil mi? Bu nedenle, bir şey sistemden akabilir ve mutlaka hata vermeyebilir, ancak tüm süreçten olması gerektiği gibi gitmeyebilir. Yani bir mesaj kuyruğuna bir mesaj bırakırsak, "Ve bu mesaj alındı ​​​​ve işlendi" diyen karşılık gelen bir ölçüm olmalı, değil mi? Değilse, doğru, hızla bir dengesizliğe sahip olacaksınız ve sistem olması gerektiği gibi çalışmıyor. Bu kötü durumlara girerken otomatikleştirilmesi gereken farklı şeyleri anlamanın bir yolu olarak metrikleri kullanabileceğimizi düşünüyorum.

Jeff: Değil mi? Çünkü çoğu zaman bir şeyleri temizlemek için atılması gereken çok basit bir adımdır, değil mi? Bir süredir operasyonda olan insanlar için, doğru, disk alanı uyarısı, bunu herkes biliyor. Oh, diskle doluyuz. Oh, ay sonunu unuttuk ve faturalandırma çalıştı ve faturalandırma her zaman günlükleri doldurur. Ve sonra VAR günlüğü tüm disk alanını tüketiyor, bu yüzden bir günlük döndürme çalıştırmamız gerekiyor. Doğru? Tercihin buysa, bunun için sabahın üçünde uyanabilirsin. Ancak davranışın bu olduğunu biliyorsak, ölçümlerimiz bize bunun için bir ipucu verebilir. Ve log döndürme komutunu basitçe otomatikleştirebiliriz, değil mi? Oh, bu eşiğe ulaştık, log döndürme komutunu çalıştırın. Bakalım uyarı temizlenecek mi? Eğer öyleyse, hayata devam edin. Olmazsa, belki birilerini uyandırırız, değil mi?

Jeff: Bunu altyapı otomasyonunda da çok daha fazla görüyorsunuz, doğru, "Hey, saniyedeki taleplerimiz teorik maksimumumuza ulaşıyor mu? Belki kümeyi ölçeklendirmemiz gerekir. Belki de yük dengeleyici havuzuna üç veya dört düğüm eklememiz gerekiyor.” Ve bunu, birinin müdahale etmesini gerektirmeden yapabiliriz. Sadece bu metriklere bakabilir ve bu eylemi gerçekleştirebilir ve ardından belirli bir eşiğin altına düştüğünde bu altyapıyı daraltabiliriz, ancak bu ölçümlere sahip olmanız ve bunu yapabilmek için bu kancaları izleme ortamınıza almanız gerekir. Ve konuşmanın tüm ölçümler bölümünün geldiği yer burasıdır.

Jeff: Ayrıca bu bilgiyi başkalarıyla paylaşabilmek de güzel çünkü bir kez veriye sahip olduğunuzda, ortak bir gerçeklikteki şeyler hakkında konuşmaya başlayabilirsiniz, değil mi, çünkü meşgul genel bir terimdir, ancak saniyede 5,200 istek çok fazla bir şeydir. hakkında akıl yürütebileceğimiz daha somut. Ve sanırım kapasite veya herhangi bir şey hakkında konuştuğumuzda, bu elle dalgalı terimleri kullanıyoruz, bunun yerine bir gösterge panosuna bakıyor ve çok özel değerler veriyor ve herkesin bu gösterge panolarına erişebildiğinden emin oluyoruz. they're not hidden behind some ops wall that only we have access to for some unknown reason.

Drew: So while sort of monitoring and using metrics as a decision-making tool for the businesses is one aspect of it, it sounds like the primary aspect is having the system monitor itself, perhaps, and to respond maybe with some of these automations as the system as a whole gives itself feedback on onto what's happening.

Jeff: Absolutely. Feedback loops are a key part of any real system design, right, and understanding the state of the system at any one time. So while it's easy in the world where everything is working fine, the minute something goes bad, those sorts of dashboards and metrics are invaluable to have, and you'll quickly be able to identify things that you have not instrumented appropriately. Doğru. So one of the things that we always talk about in incident management is what questions did you have for the system that couldn't be answered, right. So what is it, or you're like, “Oh man, if we only knew how many queries per second were going on right now.” Doğru.

Jeff: Well, okay. How do we get that for next time? How do we make sure that that's radiated somewhere? And a lot of times it's hard when you're thinking green field to sit down and think of all the data that you might want at any one time. But when you have an incident, it becomes readily apparent what data you wish you had. So it's important to sort of leverage those incidents and failures and get a better understanding of information that's missing so that you can improve your incident management process and your metrics and dashboarding.

Drew: One of the problems we sometimes face in development is that teammate members, individual team members hold a lot of knowledge about how a system works and if they leave the company or if they're out sick or on vacation, that knowledge isn't accessible to the rest of the team. It seems like the sort of DevOps approach to things is good at capturing a lot of that operational knowledge and building it into systems. So that sort of scenario where an individual has got all the information in their head that doesn't happen so much. Bu adil bir değerlendirme mi?

Jeff: It is. I think we've probably, I think as an industry we might have overstated its efficacy. And the only reason I say that is when our systems are getting so complicated, right? Gone are the days where someone has the entire system in their head and can understand it from beginning to end. Typically, there's two insidious parts of it. One, people typically focus on one specific area and someone doesn't have the whole picture, but what's even more insidious is that we think we understand how the system works. Doğru. And it's not until an incident happens that the mental model that we have of the system and the reality of the system come into conflict. And we realize that there's a divergence, right? So I think it's important that we continuously share knowledge in whatever form is efficient for folks, whether it be lunch and learns, documentation, I don't know, presentations, anything like that to sort of share and radiate that knowledge.

Jeff: But we also have to prepare and we have to prepare and define a reality where people may not completely understand how the system works. Doğru. And the reason I think it's important that we acknowledge that is because you can make a lot of bad decisions thinking you know how the system behaves and being 100% wrong. Doğru. So having the wherewithal to understand, okay, we think this is how the system works. We should take an extra second to verify that somehow. Doğru. I think that's super important in these complicated environments in these sprawling complex microservice environments. Whereas it can be very, it's easy to be cavalier if you think, oh yeah, this is definitely how it works. And I'm going to go ahead and shut the service down because everything's going to be fine. And then everything topples over. So just even being aware of the idea that, you know what, we may not know a hundred percent how this thing works.

Jeff: So let's take that into account with every decision that we make. I think that's key. And I think it's important for management to understand the reality of that as well because for management, it's easy for us to sit down and say, “Why didn't we know exactly how this thing was going to fail?” And it's like, because it's complicated, right, because there's 500 touch points, right, where these things are interacting. And if you change one of them, it changes the entire communication pattern. So it's hard and it's not getting any easier because we're getting excited about things like microservices. We're getting excited about things like Kubernetes. We're giving people more autonomy and these are just creating more and more complicated interfaces into these systems that we're managing. And it's becoming harder and harder for anyone to truly understand them in their entirety.

Drew: We've talked a lot about a professional context, big organizations and small organizations too. But I know many of us work on smaller side projects or maybe we volunteer on projects and maybe you're helping out someone in the community or a church or those sorts of things. Can a DevOps approach benefit those smaller projects or is it just really best left to big organizations to implement?

Jeff: I think DevOps can absolutely benefit those smaller projects. And specifically, because I think sort of some of the benefits that we've talked about get amplified in those smaller projects. Doğru? So exporting of expertise with automation is a big one, right? If I am… Take your church example, I think is a great one, right? If I can build a bunch of automated tests suites to verify that a change to some HTML doesn't break the entire website, right, I can export that expertise so that I can give it to a content creator who has no technical knowledge whatsoever. Doğru. They're a theologian or whatever, and they just want to update a new Bible verse or something, right. But I can export that expertise so that they know that I know when I make this content change, I'm supposed to run this build button.

Jeff: And if it's green, then I'm okay. And if it's red, then I know I screwed something up. Doğru. So you could be doing any manner of testing in there that is extremely complicated. Doğru. It might even be something as simple as like, hey, there's a new version of this plugin. And when you deploy, it's going to break this thing. Doğru. So it has nothing to do with the content, but it's at least a red mark for this content creator to say “Oh, something bad happened. I shouldn't continue. Doğru. Let me get Drew on the phone and see what's going on.” Doğru. And Drew can say, “Oh right. This plugin is upgraded, but it's not compatible with our current version of WordPress or whatever.” Doğru. So that's the sort of value that we can add with some of these DevOps practices, even in a small context, I would say specifically around automation and specifically around some of the cultural aspects too.

Jeff: Right? So I've been impressed with the number of organizations that are not technical that are using get to make changes to everything. Doğru. And they don't really know what they're doing. They just know, well, this is what we do. This is the culture. And I add this really detailed commit message here. And then I push it. They are no better than us developers. They know three get commands, but it's the ones they use over and over and over again. But it's been embedded culturally and that's how things are done. So everyone sort of rallies around that and the people that are technical can take that pattern.

Jeff: … around that and the people that are technical can take that pattern and leverage it into more beneficial things that might even be behind the scenes that they don't necessarily see. So I think there's some value, definitely. It's a matter of how deep you want to go, even with the operations piece, right? Like being able to recreate a WordPress environment locally very easily, with something like Docker. They may not understand the technology or anything, but if they run Docker Compose Up or whatever, and suddenly they're working on their local environment, that's hugely beneficial for them and they don't really need to understand all the stuff behind it. In that case, it's worthwhile, because again, you're exporting that expertise.

Drew: We mentioned right at the beginning, sort of putting off as much sort of DevOps as possible. You mentioned using tools like Heroku. And I guess that sort of approach would really apply here on getting started with, with a small project. What sort things can platforms like Heroku offer? I mean, obviously, I know you're not a Heroku expert or representative or anything, but those sorts of platforms, what sort of tools are they offering that would help in this context?

Jeff: So for one, they're basically taking that operational context for you and they're really boiling it down into a handful of knobs and levers, right? So I think what it offers is one, it offers a very clear set of what we call the yellow brick road path, where it's like, “If you go this route, all of this stuff is going to be handled for you and it's going to make your life easier. If you want to go another route, you can, but then you got to solve for all this stuff yourself.” So following the yellow brick road route helps because one, they're probably identifying a bunch of things that you hadn't even thought of. So if you're using their database container or technology, guess what? You're going to get a bunch of their metrics for free. You're going to get a lot of their alerting for free. You didn't do anything. You didn't think anything. It's just when you need it, it's there. And it's like, “Oh wow, that's super are helpful.”

Jeff: Two, when it comes to performance sizing and flexibility, this becomes very easy to sort of manage because the goal is, you're a startup that's going to become wildly successful. You're going to have hockey stick growth. And the last thing you necessarily really want to be doing is figuring out how to optimize your code for performance, while at the same time delivering new features. So maybe you spend your way out of it. You say, “Well, we're going to go up to the next tier. I could optimize my query code, but it's much more efficient for me to be spending time building this next feature that's going to bring in this new batch of users, so let's just go up to the next tier,” and you click button and you move on.

Jeff: So being able to sort of spend your way out of certain problems, I think it's hugely beneficial because tech debt gets a bad rap, but tech debt is no different than any debt. It's the trade off of acquiring something now and dealing with the pain later. And that's a strategic decision that you have to make in every organization. So unchecked tech debt is bad, right? But tech debt generally, I think, is a business choice and Heroku and platforms like that enable you to make that choice when it comes to infrastructure and performance.

Drew: You've written a book, Operations, Anti-Patterns, DevOps Solutions, for Manning. I can tell it's packed with years of hard-earned experience. The knowledge sort of just leaps out from the page. And I can tell it's been a real labor of love. It's packed full of information. Who's your sort of intended audience for that book? Is it mostly those who are already working in DevOps, or is it got a broader-

Jeff: It's got a broader… So one of the motivations for the book was that there were plenty of books for people that we're already doing DevOps. You know what I mean? So we were kind of talking to ourselves and high-fiving each other, like, “Yeah, we're so advanced. Awesome.” But what I really wanted to write the book for were people that were sort of stuck in these organizations. I don't want to use the term stuck. That's unfair, but are in these organizations that maybe aren't adopting DevOps practices or aren't at the forefront of technology, or aren't necessarily cavalier about blowing up the way they do work today, and changing things.

Jeff: Başta bireysel katkı sağlayanlara ve orta düzey yöneticilere, "Bu tür kademeli değişiklikleri yapabilmek için CTO olmanıza gerek yok ve buna sahip olmanıza gerek yok" demek için onlara yazmak istedim. DevOps'un bazı avantajlarından yararlanabilmek için tüm satış devrimi." Bu yüzden onlara "Hey, bunu parçalar halinde yapabilirsiniz. Bunu kendin yapabilirsin. Ve DevOps ile ilgili olduğunu düşünmeyebileceğiniz tüm bu şeyler var çünkü onu araçlar ve Kubernet'ler olarak düşünüyorsunuz.” Her kuruluş değil… Eyalet hükümeti gibi bu New York Eyaletinden yanaysanız, bir gecede gelip Kubernetes'i uygulamayacaksınız. Doğru? Ancak ekiplerin birbirleriyle nasıl konuştuklarını, birlikte nasıl çalıştıklarını, birbirimizin sorunlarını nasıl anladığımızı ve bu sorunları otomasyon yoluyla nasıl çözebileceğimizi uygulayabilirsiniz. Bunlar, günlük yaşamınızı iyileştirebilecek etki alanınızdaki şeylerdir.

Jeff: Yani bu gerçekten o insanlara bir mektuptu, ama bence orada yeterli veri ve bir DevOps organizasyonundaki insanların bir çeşit toplayıp "Hey, bu bizim için hala yararlı. ” Ve bence pek çok insan, kitabı okuyarak bir DevOps organizasyonunda olmadıklarını, sadece bir iş unvanı değişikliği yaptıklarını anlıyorlar. Ve bu biraz oluyor. Yani, "Hey, biz artık DevOps mühendisleriyiz, ama bu kitapta bahsedilen bu tür uygulamaları yapmıyoruz ve oraya nasıl gideceğiz?" derler.

Drew: Kitabınız onlardan biri gibi görünüyor, ancak DevOps'u kullanmaya başlamak isteyen kişilerin başvurabileceği başka kaynaklar var mı? Bu şeyleri öğrenmek için iyi yerler var mı?

Jeff: Evet. Bence Emily Freeman'dan DevOps For Dummies başlamak için harika bir yer. Bazı temel kavram ve fikirleri ve ne için uğraştığımızı ortaya koyma konusunda gerçekten harika bir iş çıkarıyor. Yani bu, bir çeşit arazi elde etmek için başlamak için iyi bir yer olurdu. Bence Phoenix Projesi, Gene Kim'in bir başka harika kaynağı. Ve bu harika, bir DevOps ortamında bulunmamanın yaratabileceği sorun türleri için zemin hazırlıyor. Ve her tür organizasyonda tekrar tekrar gördüğümüz bu kalıpları ve kişilikleri vurgulama konusunda harika bir iş çıkarıyor. Bunları vurgulamak için harika bir iş çıkardığını düşünüyorum. Ve eğer o kitabı okursanız, sanırım sayfalarda “Evet, evet. Bu. Bu." Yani, bu başka bir harika yer.

Jeff: Ve oradan, DevOps el kitaplarından herhangi birine dalın. Bunu söylediğim için kendimi tekmeleyeceğim, ancak Google SRE El Kitabı bakmak için harika bir yerdi. Google olmadığınızı anlayın, bu yüzden her şeyi uygulamak zorundaymış gibi hissetmeyin, ancak fikirlerinin ve stratejilerinin birçoğunun herhangi bir kuruluş için geçerli olduğunu ve bir şeyler alıp alabileceğiniz harika yerler olduğunu düşünüyorum. "Tamam, operasyon ortamımızı biraz daha verimli hale getireceğiz" gibi bir şey söyleyin. Ve bu, operasyon rolü oynayan geliştiriciler için özellikle dikkat çekici olacağını düşünüyorum, çünkü bu sorunların bazılarını çözmek için bir çok programatik yaklaşıma odaklanıyor.

Drew: Yani, DevOps hakkında her şeyi öğreniyorum. Son zamanlarda ne öğreniyorsun Jeff?

Jeff: Kubernet'ler, dostum. Evet. Kubernetes bizim için gerçek bir okuma ve bilgi kaynağı oldu. Bu nedenle, geliştiricileri daha da güçlendirmenin bir yolu olarak şu anda Centro'da bunu uygulamaya çalışıyoruz. İşleri bulunduğumuz yerden bir adım öteye taşımak istiyoruz. Çok fazla otomasyona sahibiz, ancak şu anda, yeni bir hizmetin dahil edilmesi söz konusu olduğunda, hizmetin doğasına bağlı olarak ekibim hala bununla oldukça yoğun bir şekilde ilgileniyor. Ve biz bu iş kolunda olmak istemiyoruz. Geliştiricilerin konseptten koda ve dağıtıma kadar bir fikir alabilmelerini ve bunu operasyonel uzmanlığın sistem içinde kodlandığı yerde yapabilmelerini istiyoruz. Yani siz sistemde ilerledikçe sistem size rehberlik ediyor. Bu yüzden Kubernetes'in bunu yapmamıza yardımcı olacak bir araç olduğunu düşünüyoruz.

Jeff: Bu inanılmaz derecede karmaşık. Ve bir çeşit ısırmak için büyük bir parça. Peki, dağıtımların neye benzediğini bulmak? Bu operatörleri Kubernetes içinde nasıl kullanırız? CICD bu yeni dünyada neye benziyor? Yani çok fazla okuma yapıldı ama bu alanda sürekli öğreniyorsunuz, değil mi? Ne kadar süredir bu işin içinde olursanız olun, ne kadar süredir yapıyor olursanız olun, bu alanın bir yerinde bir aptalsınız. Yani, bu sadece adapte olduğun bir şey

Drew: Pekala, dediğim gibi, bunca yıldan sonra bile, yığının neresinde olduğunu anlamış olsam da, Kubernetes'in ne yaptığına dair hala bir fikrim yok.

Jeff: Bazen benzer hissediyorum. Her şeyden biraz yapıyormuş gibi hissettiriyor, değil mi? 21. yüzyılın DNS'sidir.

Drew: Dinleyici olarak Jeff'ten daha fazlasını duymak istiyorsanız, onu Twitter'da, karanlık ve nerdy'de bulabilir ve kitabını ve geçmiş sunumlarına ve blog yazılarına bağlantılarını kendi sitesinde, ulaşılabilirdevops.com'da bulabilirsiniz. Bugün bize katıldığın için teşekkürler Jeff. Ayrılık sözleriniz oldu mu?

Jeff: Öğrenmeye devam et, dışarı çık, öğrenmeye devam et ve akranlarınla ​​konuş. Konuş, konuş, konuş. Çalıştığınız insanlarla ne kadar çok konuşursanız, o kadar iyi anlar, onlar için daha iyi empati kurarsınız ve kurumda özellikle nefret ettiğiniz biri varsa, önce onlarla konuştuğunuzdan emin olun.