DevOps Nedir?

Zamanın Kısa Tarihi

DevOps'u anlamak için zamanda geriye, programcılardan başka hiçbir şeyin olmadığı eski çağa gitmemiz gerekiyor.

Tao'nun bize öğrettiği gibi:

Eski programcılar gizemli ve derindi. Düşüncelerini anlayamayız, bu yüzden tek yaptığımız görünüşlerini tanımlamak:

• Suyu geçen bir tilki gibi farkındayım
• Savaş alanında bir general gibi uyarı
• Nazik, misafirlerini karşılayan bir hostes gibi
• Basit, oyulmamış ahşap bloklar gibi
• Opak, karanlık mağaralardaki siyah havuzlar gibi

Programcı makine dilini doğurdu. Makine dili, montajcıyı doğurdu. Montajcı, derleyiciyi doğurdu. Şimdi binlerce dil var. Ne kadar mütevazı olursa olsun, her dilin bir amacı vardır. Her dil, yazılımın Yin ve Yang'ını ifade eder. Her dilin yazılım içinde yeri vardır.

O zamanlar, yazılım geliştirme ofislerine çoğunlukla laboratuvar deniyordu ve programcılar bilim insanıydı. İyi bir uygulama oluşturmak için programcıların, uygulamanın çözdüğü sorunu tam olarak anlamaları gerekiyordu. Uygulamanın nerede kullanılacağını ve ne tür bir sistem çalıştıracağını bilmek zorundaydılar. Özünde, programcılar, spesifikasyondan geliştirmeye, dağıtıma ve desteğe kadar uygulamaları hakkında her şeyi biliyorlardı.

Sonra insan doğası devreye girdi ve daha fazlasını istemeye başladık. Daha fazla hız, daha fazla özellik, daha fazla kullanıcı, daha fazla her şey.

Mütevazı, alçakgönüllü ve barışçıl yaratıklar olan programcıların, her zaman daha fazlasını isteyen bu kadar muhtaç kullanıcı patlamasından kurtulma şansı çok azdı. Hakim olmak için en iyi şans, farklı yönlerde gelişmeye başlamak ve kastlar yaratmaktı. Kısa süre sonra programcılar, geliştiriciler, yazılım mühendisleri, ağ yöneticileri, veritabanı geliştiricileri, web geliştiricileri, sistem mimarları, kalite güvence mühendisleri ve daha pek çok şey olarak adlandırılan yeni türlerin ataları olarak soyu tükendi. Hızla gelişmek ve dış dünyadaki zorluklara uyum sağlamak onların DNA'sının bir parçası oldu. Yeni kast birkaç hafta içinde gelişebilir. Web geliştiricileri arka uç geliştiriciler, ön uç geliştiriciler, PHP geliştiricileri, Ruby geliştiricileri, Angular geliştiricileri oldular… hepsi cehenneme gidiyordu.

Kısa süre sonra hepsi aynı babadan, bir Programcıdan geldiklerini unuttular. Sadece dünyayı daha iyi bir yer haline getirmek isteyen basit ve barışçıl bir bilim adamı. Her birinin “Programcı”nın gerçek torunları olduğunu ve kanlarının diğerlerinden daha saf olduğunu iddia ederek birbirleriyle kavga etmeye başladılar.

Zaman geçtikçe etkileşimlerini en aza indirdiler ve birbirleriyle sadece gerçekten zorunda olduklarında konuştular. Uzaktaki aile üyelerinin başarısını kutlamayı bıraktılar ve sonunda arada bir kartpostal göndermeyi bile bıraktılar.

Sadece duygularını araştırsalar, Programcı'nın kıvılcımının kalplerinde parlamayı ve galaksiye barış getirmeyi beklediğini keşfedeceklerdi.

Dünyayı fethetmek için bencil ve benmerkezci yarışlarında, programcıların torunları işlerinin amacını unuttular - müşterileri için problem çözme. Projeler geciktiği, çok pahalı olduğu ve hatta başarısız olduğu için müşteriler bu tür davranışların acısını hissetmeye başladılar.

Arada bir, parlak bir yıldız parlayacak ve birileri The Descendants arasında barış yapmaya çalışmak için ilham alacaktı. Şelale ile geldiler. Bu parlak bir fikirdi, çünkü farklı geliştirici gruplarının yalnızca gerektiğinde iletişim kurduğu gerçeğini kullandı. Bir grup işin kendi bölümünü bitirdiğinde, süreç boyunca işi göndermek için bir sonraki grupla iletişim kurdu ve bir daha dönüp bakmadı.

Bu bir süre işe yaradı, ancak her zamanki gibi insanlar (Müşteriler) yine daha fazlasını istedi. Yazılım oluşturma sürecinin tamamında daha aktif rol almak, daha sık fikir vermek ve çok geç olsa bile değişiklik istemek istediler.

Yazılım projeleri başarısızlığa o kadar meyilli hale geldi ki, bir endüstri standardı olarak kabul edildi. İstatistikler projelerin %50'den fazlasının başarısız olduğunu gösterdi ve bu konuda yapılacak hiçbir şey yok gibi görünüyor (ZDNet, CNet)

Her nesilde, tüm bu geliştirici gruplarının birlikte çalışmanın, iletişim kurmanın ve müşterilerinin mümkün olan en iyi çözümü almasını sağlamak için esnek olmanın bir yolunu bulması gerektiğini bilen birkaç açık fikirli birey vardı. Büyük John Von Neumann'ın meslektaşları tarafından 1957'de bile bu girişimlerin izleri var. Ancak devrimi başlatmak için 2001 başlarına kadar beklemek zorunda kaldık, o sırada kirli bir düzine Çevik Manifesto yarattı.

Çevik Manifesto on iki ilkeye dayanmaktadır:

1. Değerli yazılımların erken ve sürekli teslimi ile müşteri memnuniyeti
2. Geç geliştirmede bile değişen gereksinimleri memnuniyetle karşılayın
3. Çalışan yazılım sıklıkla teslim edilir (aylar yerine haftalar)
4. İş adamları ve geliştiriciler arasında yakın, günlük işbirliği
5. Projeler, güvenilmesi gereken motive olmuş bireyler etrafında inşa edilir.
6. Yüz yüze görüşme en iyi iletişim şeklidir (birlikte konum)
7. Çalışan yazılım, ilerlemenin başlıca ölçüsüdür
8. Sürdürülebilir kalkınma, sabit bir tempoyu koruyabilme
9. Teknik mükemmelliğe ve iyi tasarıma sürekli dikkat
10. Sadelik - yapılmayan iş miktarını en üst düzeye çıkarma sanatı - esastır
11. Kendi kendini organize eden ekipler
12. Değişen koşullara düzenli uyum

Çevik manifesto, Galaksiye barış getirmenin ve Güç'e dengeyi geri getirmenin ilk büyük adımıydı. Çok uzun bir süre sonra ilk kez, yazılım geliştirme sürecinde tüm paydaşları bir araya getirmek, prosedürel ve mekanize olduğu kadar kültürel ve “insan” yolu da temel aldı. İnsanlar birbirleriyle konuşmaya, düzenli olarak buluşmaya, fikir ve yorum alışverişinde bulunmaya başladılar. Düşündüklerinden çok daha fazla ortak noktaları olduğunu fark ettiler ve müşteriler, yalnızca parayı göndermesi ve soru sormaması beklenen bir dış faktör değil, ekibin bir parçası oldular.

Hâlâ üstesinden gelinmesi gereken birkaç engel vardı, ancak gelecek her zamankinden daha parlak görünüyordu. Çevik olmak, açık ve sürekli değişikliklere uyum sağlamaya istekli olmak demektir. Bununla birlikte, çok fazla değişiklikle, nihai hedefe ve teslimata odaklanmak zordur. Yalın Yazılım Geliştirme de bu şekilde hayat buldu.

LSD'ye bağlı (cinas amaçlı) ve sürgün edilme ve dışlanma riskiyle, soyundan gelenlerin bazıları kastlarının ve yazılım endüstrisinin dışında çözümler aradı. Büyük bir otomobil üreticisinin eserlerinde kurtuluş buldular. Toyota Üretim Sistemi, sadeliği açısından şaşırtıcıydı ve yalın üretiminin yazılım geliştirmeye kolaylıkla uygulanabileceği o kadar açıktı ki.

Yalınlığın 7 ilkesi vardır:

1. Atıkları Ortadan Kaldırın
2. Kaliteyi İnşa Edin
3. Bilgi Yaratın (Öğrenmeyi güçlendirin)
4. Taahhüdü Erteleyin (Mümkün olduğunca geç karar verin)
5. Mümkün olduğunca hızlı teslim edin
6. İnsanlara Saygı Duyun (Ekibi güçlendirin)
7. Bütünü Optimize Edin

Çevikliğin üzerine eklenen Yalın ilkeler, tüm süreç boyunca esnek olurken, zihniyeti ve doğru şeyleri yapmaya odaklanmayı destekledi.

Çevik ve Yalın yazılım geliştirme ekipleri tarafından benimsendikten sonra, tüm ilkeleri bir Bütün olarak BT'ye uygulamak için yalnızca bir adım kaldı - bu da bizi sonunda DevOps'a getirdi!

DevOps'a girin - Üç şeritli otoyol

Yazılım geliştirme ekiplerinin eski tarz görüşü, iş analistlerini, sistem mimarlarını, ön uç geliştiricileri, arka uç geliştiricileri, testçileri vb. içeriyordu. Çevik ve yalın ilkeleri içeren yazılım geliştirme sürecini optimize etmek, çoğunlukla bunlara odaklandı. Uygulama "üretime hazır" olduğunda, sistem mühendisleri, sürüm mühendisleri, DBA'lar, ağ mühendisleri, güvenlik uzmanları vb. dahil olmak üzere "Operasyonlara" gönderildi. Dev ve Ops arasındaki büyük duvarı kaldırmak DevOps'un ana itici gücüdür.

DevOps, yalın ilkelerin tüm BT değer akışına uygulanmasının sonucudur. BT değer akışı, orijinal Programcıdan gelen tüm 'uzak akrabaları' birleştirerek geliştirmeyi üretime yayar.

DevOps çözümlerinin en iyi açıklaması Gene Kim tarafından verilmiştir ve Phoenix Projesi'ni okumadıysanız biraz zaman ayırıp yapmanızı öneririm.

Bir DevOps mühendisi işe almamalısınız ve DevOps, BT'nizde yeni bir departman olmamalıdır. DevOps bir kültürdür, zihniyettir ve Bütün olarak BT'nin bir parçasıdır. BT'nizi bir DevOps organizasyonu haline getirecek hiçbir araç yoktur ve hiçbir otomasyon düzeyi, ekiplerinize müşterilerinize maksimum değer sunma yetkisi vermez.

DevOps'a genellikle üç yol yöntemi denir, ancak ben onları aynı otoyolun üç şeridi olarak görüyorum. Birinci şeritte başlıyorsunuz, sonra hızlanıyorsunuz ve ikinci şeride geçiyorsunuz ve sonunda üçüncü şeritte hızla ilerliyorsunuz.

• Birinci şerit - Sistemin bir bütün olarak performansı ana odak noktasıdır ve sistemin herhangi bir bireysel öğesinin performansı üzerinde vurgulanır

• İkinci şerit - Yukarı akışa gönderilen sabit bir geri bildirim döngüsü olduğundan ve göz ardı edilmediğinden emin olun

• Üçüncü kulvar - Deneyleri besleyin, sürekli iyileştirme yapın ve hızla başarısız olun

Birinci şerit - Hızlanmak

Bir BT organizasyonunun DevOps ilkelerini benimserken öğrenmesi gereken ilk şey, tüm sistemin önemini anlamak ve iş öğelerine uygun şekilde öncelik vermektir. BT değer akışındaki hiç kimsenin bir darboğaz yaratmasına ve iş akışını azaltmasına izin verilmez.

Kesintisiz iş akışının sağlanması, sürece dahil olan herkes için nihai hedeftir. Bir kişinin veya ekibin rolü ne olursa olsun, sistemin derinlemesine anlaşılmasını sağlamaya çalışmaları zorunludur. Bu düşünce tarzını benimsemek, kalite üzerinde doğrudan bir etkiye sahiptir, çünkü kusurlar, darboğazlara neden olacağından asla akışa gönderilmez.

İşin durmadığından emin olmak yeterli değildir. Üretken bir organizasyon her zaman akışı arttırmaya çalışmalıdır. Akışı artırmak için çok sayıda metodoloji vardır. Kısıtlar Teorisi, Altı Sigma, Yalın veya Toyota Üretim Sisteminde bir çözüm bulabilirsiniz. Bunlardan herhangi birini seçmekten çekinmeyin, kendinizinkini bulun veya birleştirin.

Sistem Mimarı, DBA, QA veya ağ yöneticisi iseniz DevOps ilkeleri hangi ekibe ait olduğunuzla ilgilenmez. Aynı kurallar herkes için geçerlidir ve herkesin iki basit ilkeye uyması beklenir:

• Sistem akışını kesintisiz tutun
• İş akışını her zaman artırın ve optimize edin

İkinci şerit - Hazırlanın

Kesintisiz sistem akışı tek yönlüdür ve geliştirmeden operasyona geçmesi beklenir. İdeal bir dünyada bu, yazılımın hızlı bir şekilde yüksek kalitede oluşturulması, üretime dağıtılması ve müşterilere değer sağlanması anlamına gelir.

Ancak DevOps, Utopia değildir ve tek yönlü teslimat mümkün olsaydı şelale yöntemi yeterli olurdu. Çıktıları değerlendirmek ve akışı iletmek kaliteyi sağlamak için çok önemlidir. Uygulanması gereken ilk "yukarı akış" iletişim kanalı Ops to Dev'dir.

Kendinize bir beşlik çakmak kolaydır, ancak geri bildirim istemek ve geri bildirim vermek gerçek resmi görmenin yoludur. Aşağı yöndeki her küçük adımı, anında yukarı yönde bir onayın takip etmesi zorunludur.

Geri bildirim döngüsünü nasıl kurduğunuz önemli değildir. Geliştiricileri destek ekibi toplantılarına katılmaya davet edebilir veya ağ yöneticisini haftalık sprint planlamasına dahil edebilirsiniz. Geri bildiriminiz yerinde olduğu ve yorumlar toplanıp işlendiği sürece, kuruluşunuz DevOps otoyolunu hızlandırıyor.

Üçüncü kulvar - Warp 10

DevOps hızlı şeridi, zayıf görüşlüler için değildir. DevOps hızlı şeridine girmek için kuruluşunuzun yeterince olgun olması gerekir. Her şey risk almak ve başarısızlıktan öğrenmek, sürekli deney yapmak ve ustalığın ön koşulunun tekrar ve pratik olduğunu kabul etmekle ilgilidir. Oldukça sık Kata terimini duyacaksınız ve bunun bir nedeni var. Sürekli eğitim ve tekrar, karmaşık hareketleri rutin hale getirdiği için ustalığa yol açar.

Ancak hareketleri birleştirmeye başlamadan önce, her bir adımda ustalaşmanız zorunludur.

“Usta için uygun olan, acemi için uygun değildir. Yapıyı aşmadan önce Tao'yu anlamalısınız."

DevOps Üçüncü Yol/Hızlı Şerit, günlük olarak sürekli denemeler için zaman ayırmayı, ekibi risk aldıkları için sürekli olarak ödüllendirmeyi ve esnekliği artırmak için sisteme hatalar eklemeyi içerir.

Bu tür önlemleri uygularken kuruluşunuzun patlamamasını sağlamak için, tüm darboğazların açık olduğundan ve sistem akışının kesintisiz olduğundan emin olarak tüm ekipler arasında sık sık geri bildirim döngüleri oluşturmalısınız.

Bu önlemleri uygulamak, kuruluşunuzun her zaman tetikte olmasını ve zorluklara hızlı ve etkili bir şekilde yanıt vermesini sağlar.

Özet - DevOps kuruluş kontrol listesi

DevOps'un BT organizasyonunuzu nasıl etkinleştirdiğini doğrulamak için kullanabileceğiniz bir kontrol listesi. Lütfen makaleye yorum yapmaktan ve kendi puanlarınızı eklemekten çekinmeyin.

• Geliştirme ekibi ile operasyon ekibi arasında duvar yoktur. İkisi de aynı sürecin parçası
• Bir ekipten diğerine gönderilen işler her zaman doğrulanır ve en yüksek kalitededir.
• İş "birikimi" yoktur ve tüm darboğazlar halledilir
• Dağıtım ve bakım aynı zaman kutusunun parçası olduğu için geliştirme ekibi, faaliyetleri için Operasyon zamanını kullanmıyor
• Geliştirme ekibi, dağıtım kodunu Cuma günleri 17:00'de teslim etmiyor ve operasyonları hafta sonu çalışmalarını temizlemeye bırakıyor
• Geliştirme ortamları standartlaştırılmıştır ve operasyonlar bunları kolayca yeniden üretebilir ve üretime ölçekleyebilir
• Geliştirme ekibi, uygun buldukları yeni sürümleri teslim edebilir ve operasyonlar bunları üretime kolayca dağıtabilir
• Tüm ekipler arasında net iletişim hatları vardır
• Tüm ekip üyelerinin, sistemin iyileştirilmesi üzerinde deney yapmak ve çalışmak için zamanları vardır.
• Hatalar, düzenli olarak sisteme tanıtılır (veya simüle edilir) ve işlenir. Her deneyden öğrenilen dersler belgelenir ve ilgili tüm kişilerle paylaşılır. Olay yönetimi bir rutindir ve çoğunlukla bilinen bir şekilde ele alınır

Çözüm

Chef, Docker, Ansible, Packer, Troposphere, Consul, Jenkins, SonarQube, AWS vb. gibi modern DevOps Araçlarını kullanmak, DevOps ilkelerini uyguladığınız anlamına gelmez. DevOps bir düşünme biçimidir. Hepimiz aynı sürecin parçasıyız, aynı zamanı paylaşıyor ve birlikte değer üretiyoruz. Yazılım teslim sürecinde yer alan her kişi, tüm sistemi hızlandırabilir veya yavaşlatabilir. Geliştirme sırasında oluşturulan bir hata, yanlış güvenlik duvarı yapılandırmasının yanı sıra sistemi de çökertebilir.

Tüm insanlar DevOps'un bir parçasıdır ve kuruluşunuz bunu anladığında, onu yönetmenize yardımcı olacak araçlar ve teknoloji yığını sihirli bir şekilde ortaya çıkacaktır.