DevOps'un tanımı çok karmaşık, dolayısıyla bu konudaki tartışmayı her seferinde yeniden başlatmamız gerekiyor. Sadece Habré'de bu konuyla ilgili binlerce yayın var. Ancak bunu okuyorsanız muhtemelen DevOps'un ne olduğunu biliyorsunuzdur. Çünkü değilim. Merhaba benim adım Alexander Titov (@) ve sadece DevOps hakkında konuşacağız, ben de deneyimlerimi paylaşacağım.
Uzun zamandır hikayemi nasıl faydalı hale getirebileceğimi düşünüyordum, bu yüzden burada kendime sorduğum ve şirketimizin müşterilerine sorduğum pek çok soru olacak. Bu soruları yanıtlayarak anlayış daha iyi hale gelir. Benim açımdan DevOps'a neden ihtiyaç duyulduğunu, yine benim açımdan ne olduğunu ve benim bakış açımdan tekrar DevOps'a doğru ilerlediğinizi nasıl anlayacağınızı anlatacağım. Son nokta sorular üzerinden olacaktır. Bunları kendiniz cevaplayarak şirketinizin DevOps'a doğru ilerlediğini veya bir şekilde sorun olup olmadığını anlayabilirsiniz.
Bir zamanlar birleşme ve satın alma dalgalarının içindeydim. İlk önce Qik adında küçük bir girişimde çalıştım, sonra Skype adında biraz daha büyük bir şirket tarafından satın alındı, daha sonra Microsoft adında biraz daha büyük bir şirket tarafından satın alındı. O anda DevOps fikrinin farklı büyüklükteki şirketlerde nasıl dönüştüğünü görmeye başladım. Bundan sonra DevOps'a pazar açısından bakmaya ilgi duymaya başladım ve meslektaşlarımla birlikte Express 42 şirketini kurduk. 6 yıldır pazarın dalgaları boyunca ilerliyoruz.
Diğer şeylerin yanı sıra, DevOps Moskova topluluğunun organizatörlerinden biriyim ve DevOps-Days 2017'nin organizatörlerinden biriyim, ancak 2018'i ben organize etmedim. Express 42 birçok firmayla çalışmaktadır. Orada DevOps'u büyütüyoruz, nasıl gerçekleştiğini izliyoruz, sonuçlar çıkarıyoruz, analiz ediyoruz, sonuçlarımızı herkese anlatıyoruz ve insanları DevOps uygulamaları konusunda eğitiyoruz. Genel olarak bu konuda deneyim ve uzmanlığımızı artırmak için elimizden geleni yapıyoruz.
Neden DevOps
Herkesin aklını kurcalayan ve her zaman aklını kurcalayan ilk soru şu: Neden? Birçok kişi DevOps'un sadece otomasyon veya her şirketin zaten sahip olduğu benzer bir şey olduğunu düşünüyor.
— Sürekli Entegrasyonumuz vardı; bu, zaten DevOps'a sahip olduğumuz anlamına geliyor ve tüm bunlara neden ihtiyaç duyuluyor? Yurt dışında eğleniyorlar ama bizi çalışmaktan alıkoyuyorlar!
Topluluğun ve metodolojinin 9 yıldan fazla süren gelişimi, bunun hala pazarlama parıltısı olmadığı açıkça ortaya çıktı, ancak buna neden ihtiyaç duyulduğu hala tam olarak belli değil. Her araç ve süreç gibi DevOps'un da sonuçta ulaştığı belirli hedefler vardır.
Bütün bunlar dünyanın değişmesinden kaynaklanıyor. Şirketler, St. Petersburg klasiğimizin söylediği gibi, belli bir stratejiye göre, belli bir yapıyla, A noktasından B noktasına doğru bir hayale doğru ilerlediğinde, kurumsal yaklaşımdan uzaklaşıyor.
Prensip olarak BT'deki her şey bu yaklaşıma göre inşa edilmelidir. Burada BT yalnızca süreçleri otomatikleştirmek için kullanılıyor.
Otomasyon sık sık değişmez, çünkü bir şirket alışılmış bir yola girdiğinde değişecek ne var? Çalışıyor; dokunmayın. Artık dünyada yaklaşımlar değişiyor ve Agile denilen yaklaşım, B uç noktasının hemen görünür olmadığını öne sürüyor.
Bir şirket pazara girdiğinde, bir müşteriyle çalıştığında, sürekli olarak pazarı araştırır ve B son noktasını değiştirir. Üstelik şirket ne kadar sık yön değiştirirse sonuçta o kadar başarılı olur çünkü daha fazla pazar seçer. nişler.
Strateji, yakın zamanda öğrendiğim ilginç bir şirket tarafından gösteriliyor. One Box Shave, tıraş makineleri ve tıraş aksesuarlarının bir kutuda teslim edildiği abonelikli bir teslimat hizmetidir. Farklı müşteriler için “kutularını” nasıl özelleştireceklerini biliyorlar. Bu, siparişi ürünleri üreten Kore fabrikasına gönderen belirli bir yazılım tarafından yapılır.
Bu ürün Unilever tarafından 1 milyar dolara satın alındı. Artık Gillette ile rekabet ediyor ve Amerika pazarındaki tüketicilerin önemli bir payını elinden alıyor. Tek Kutu Tıraş şunu söylüyor:
— 4 bıçak mı? Ciddi misin? Buna neden ihtiyacınız var? Tıraşın kalitesini artırmaz. Özel olarak seçilmiş bir krem, koku ve iki bıçaklı yüksek kaliteli bir tıraş makinesi, o aptal 4 Gillette bıçağından çok daha fazla sorunu çözüyor! Yakında 10'a ulaşacak mıyız?
Dünya böyle değişiyor. Unilever, bunu yapmanıza olanak tanıyan harika bir BT sistemine sahip olduklarını iddia ediyor. Sonuçta bir konsepte benziyor Market zamanıdaha önce kimsenin bahsetmediği bir konu.
Pazara çıkış süresinin amacı ne sıklıkta dağıtım yaptığımız değildir. Sık sık konuşlandırabilirsiniz ancak sürüm döngüleri uzun olacaktır. Üç aylık sürüm döngüleri üst üste bindirilirse ve bunları bir hafta kaydırılırsa şirketin haftada bir dağıtım yaptığı ortaya çıkıyor. Fikirden nihai uygulamaya kadar geçen süre ise 3 ay sürüyor.
Pazara çıkış süresi, fikirden nihai uygulamaya kadar geçen sürenin en aza indirilmesiyle ilgilidir.
Bu durumda yazılım pazarla etkileşime girer. One Box Shave web sitesi müşteriyle bu şekilde etkileşime girer. Satış görevlileri yok; yalnızca ziyaretçilerin tıklayıp dileklerini bıraktıkları bir web sitesi var. Buna göre sitede sürekli olarak yeni bir şeyler yayınlanmalı ve istekler doğrultusunda güncellenmelidir. Örneğin Güney Kore'de Rusya'dakinden farklı tıraş oluyorlar ve çam kokusunu değil, örneğin havuç ve vanilya kokusunu seviyorlar.
Site içeriğinin hızlı bir şekilde değiştirilmesi gerektiğinden yazılım geliştirme büyük ölçüde değişmektedir. Yazılım aracılığıyla müşterinin ne istediğini bulmalıyız. Daha önce bunu bazı dolambaçlı yollarla, örneğin işletme yönetimi yoluyla öğrenmiştik. Daha sonra onu tasarladık, gereksinimleri BT sistemine koyduk ve her şey yolunda gitti. Artık durum farklı; yazılım, mühendisler de dahil olmak üzere sürece dahil olan herkes tarafından tasarlanıyor çünkü teknik spesifikasyonlar aracılığıyla piyasanın nasıl çalıştığını öğreniyorlar ve aynı zamanda içgörülerini işletmeyle paylaşıyorlar.
Örneğin, Qik'te aniden insanların kişi listelerini sunucuya yüklemeyi gerçekten sevdiklerini öğrendik ve bize bir uygulama sağladılar. Başlangıçta bunu düşünmedik. Klasik bir şirkette herkes bunun bir hata olduğuna karar verirdi, teknik özellikler bunun harika çalışması gerektiğini söylemediği ve genellikle diz üzerinde uygulandığı için özelliği kapatır ve şöyle derlerdi: "Kimsenin buna ihtiyacı yok, en önemli şey ana işlevselliğin çalışmasıdır.” . Teknoloji şirketi de bunu bir fırsat olarak görüyor ve yazılımı buna göre değiştirmeye başlıyor.
1968'de ileri görüşlü bir adam olan Melvin Conway aşağıdaki fikri formüle etti.
Sistemi oluşturan organizasyon, o organizasyonun iletişim yapısını kopyalayan bir tasarımla sınırlandırılmıştır.
Daha detaylı olarak farklı tipte sistemler üretebilmek için farklı tipte bir firma bünyesinde de iletişim yapısının olması gerekir. İletişim yapınız üst hiyerarşik ise, bu durum çok yüksek Pazara Çıkış Süresi göstergesi sağlayabilecek sistemler oluşturmanıza izin vermeyecektir.
Okumak kimse yapamaz . DevOps kültürünü veya felsefesini anlamak önemlidir çünkü DevOps'ta temel olarak değişen tek şey ekipler arasındaki iletişimin yapısıdır.
Süreç açısından bakıldığında DevOps'tan önce tüm aşamalar: analiz, geliştirme, test etme, operasyon doğrusaldı.
DevOps söz konusu olduğunda tüm bu süreçler aynı anda gerçekleşir.
Pazara çıkış süresi bunu yapmanın tek yoludur. Eski süreçte çalışan insanlar için bu biraz kozmik görünüyor ve genel olarak öyle.
Peki neden DevOps'a ihtiyacınız var?
Dijital ürün geliştirme için. Şirketinizin dijital bir ürünü yoksa DevOps'a gerek yoktur, çok önemlidir.
DevOps, sıralı yazılım üretiminin hız sınırlamalarının üstesinden gelir. İçinde tüm süreçler aynı anda gerçekleşir.
Zorluk artar. DevOps misyonerleri size bunun yazılımı yayınlamanızı kolaylaştıracağını söylediğinde bu saçmalıktır.
DevOps ile işler daha da karmaşıklaşacak.
Avito standındaki konferansta, Docker konteynerini dağıtmanın nasıl bir şey olduğunu görebiliyordunuz; bu gerçekçi olmayan bir görevdi. Karmaşıklık engelleyici hale gelir; aynı anda birçok topla hokkabazlık yapmak zorunda kalırsınız.
DevOps şirketteki süreci ve organizasyonu tamamen değiştiriyor — daha doğrusu değişen DevOps değil, dijital üründür. DevOps'a gelmek için yine de bu süreci tamamen değiştirmeniz gerekiyor.
Bir uzmana sorular
Neye sahipsin? Bir şirkette çalışırken ve uzman olarak gelişirken kendinize sorabileceğiniz sorular.
Dijital ürün yaratma stratejiniz var mı? Varsa bu zaten iyidir. Bu, şirketinizin DevOps'a doğru ilerlediği anlamına gelir.
Şirketiniz halihazırda dijital bir ürün yaratıyor mu? Bu, yine DevOps açısından bakıldığında bir seviye daha yükselebileceğiniz ve işleri daha ilginç bir şekilde yapabileceğiniz anlamına gelir. Sadece bu bakış açısıyla konuşuyorum.
Şirketiniz dijital ürün alanında pazar liderlerinden biri mi? Spotify, Yandex, Uber şu anda teknolojik ilerlemenin zirvesinde olan şirketlerdir.
Kendinize bu soruları sorun ve tüm yanıtlar hayırsa o zaman belki de bu şirkette DevOps yapmamalısınız. DevOps konusu gerçekten ilginizi çekiyorsa belki... başka bir şirkete geçmelisiniz? Şirketiniz DevOps'a girmek istiyorsa ancak tüm sorulara "Hayır" yanıtı verdiyseniz, o zaman bu hiç değişmeyecek olan o güzel gergedan gibidir.
Organizasyon
Dediğim gibi Conway Yasasına göre bir şirketin organizasyonu değişir. Organizasyonel bakış açısından DevOps'un şirket içine sızmasını engelleyen şeyle başlayacağım.
"Kuyular" sorunu
İngilizce "Silo" kelimesi burada Rusçaya "well" olarak çevrilmiştir. Bu sorunun asıl amacı şu Ekipler arasında bilgi alışverişi yok. Her ekip, gezinmek için ortak bir harita oluşturmadan uzmanlığının derinliklerine iner.
Bu bana bazı açılardan Moskova'ya yeni gelmiş ve metro haritasında nasıl gezineceğini henüz bilmeyen birini hatırlatıyor. Moskovalılar genellikle bölgelerini çok iyi tanıyorlar ve Moskova'nın her yerinde metro haritasını kullanarak gezinebiliyorlar. Moskova'ya ilk kez geldiğinizde bu beceriye sahip değilsiniz ve sadece yönünüz bozuluyor.
DevOps, bu yönelim bozukluğu anını atlatmayı ve tüm departmanların ortak bir etkileşim haritası oluşturmak için birlikte çalışmasını öneriyor.
Bunu engelleyen iki faktör var.
Kurumsal yönetim sisteminin sonucu. Ayrı hiyerarşik “kuyularda” inşa edilmiştir. Mesela bu sistemi destekleyen firmalarda belli KPI’lar var. Öte yandan uzmanlık sınırlarının dışına çıkıp tüm sistemi yönlendirmede zorlanan bir kişinin beyni buna engel olur. Sadece rahatsız edici. Bangkok havaalanında olduğunuzu düşünün; yolunuzu hemen bulamazsınız. DevOps'ta gezinmek de zordur ve bu nedenle insanlar oraya ulaşmak için bir rehber bulmanız gerektiğini söylüyor.
Ancak en önemli şey, DevOps ruhuyla aşılanmış, Fowler ve diğer birçok kitabı okumuş bir mühendis için "kuyular" sorununun şu şekilde ifade edilmesidir: "kuyular" "bariz" şeyler yapmanıza izin vermez. DevOps Moskova'dan sonra sık sık bir araya geliyoruz, birbirimizle konuşuyoruz ve insanlar şikayet ediyor:
— Biz sadece CI'yi başlatmak istiyorduk ancak yönetimin buna ihtiyacı olmadığı ortaya çıktı.
Bu tam olarak oluyor çünkü CI и Sürekli Teslimat süreci birçok sınavın eşiğindedir. Basitçe organizasyonel düzeyde “kuyular” sorununu aşmadan, ne yaparsanız yapın ve ne kadar üzücü olursa olsun ilerleyemezsiniz.
Şirketteki süreçteki her katılımcı: arka uç ve ön uç geliştiricileri, test, DBA, operasyon, ağ, kendi yönünde kazı yapar ve onları bir şekilde izleyen ve "bölme" yöntemini kullanarak yöneten yönetici dışında kimsenin ortak bir haritası yoktur. ve fethet” yöntemini kullanın.
İnsanlar bazı yıldızlar veya bayraklar için savaşıyor, herkes kendi uzmanlığını araştırıyor.
Sonuç olarak, tüm bunları birbirine bağlama ve ortak bir boru hattı inşa etme görevi ortaya çıktığında ve artık yıldızlar ve bayraklar için savaşmaya gerek kalmadığında şu soru ortaya çıkıyor: yine de ne yapmalı? Bir şekilde anlaşmaya varmamız lazım ama okulda kimse bize bunun nasıl yapılacağını öğretmedi. Okuldan beri bize öğretiliyor: sekizinci sınıftan - vay be! - yedinci sınıfa kıyasla! Burada da durum aynı.
Sizin şirketinizde de durum aynı mı?
Bunu kontrol etmek için kendinize aşağıdaki soruları sorabilirsiniz.
Ekipler ortak araçlar kullanıyor mu ve bu ortak araçlardaki değişikliklere katkıda bulunuyor mu?
Ekipler ne sıklıkta yeniden organize oluyor; bir ekipteki bazı uzmanlar başka bir ekibe geçiyor? DevOps ortamında bu normal hale gelir, çünkü bazen kişi başka bir uzmanlık alanının ne yaptığını anlayamaz. Başka bir departmana geçiyor, iki hafta boyunca orada çalışıyor ve kendisi için bu departmanla etkileşim ve yönelim haritasını oluşturuyor.
Bir değişim komitesi oluşturup bir şeyleri değiştirmek mümkün mü? Yoksa en yüksek yönetimin ve yönlendirmenin güçlü elini mi gerektiriyor? Geçenlerde Facebook'ta az bilinen bir bankanın siparişler yoluyla araçları nasıl uyguladığını yazmıştım: bir sipariş yazıyoruz, onu bir yıl boyunca uyguluyoruz ve ne olacağını görüyoruz. Bu elbette uzun ve üzücü.
Yöneticilerin şirketin başarılarını dikkate almadan kişisel başarı elde etmesi ne kadar önemli?
Bu soruların cevabını kendiniz verirseniz şirketinizde böyle bir sorunun olup olmadığı daha net anlaşılacaktır.
Kod olarak altyapı
Bu sorun aşıldıktan sonra DevOps'ta ilerlemenin zor olduğu ilk önemli uygulama şudur: kod olarak altyapı.
Çoğu zaman, kod olarak altyapı şu şekilde algılanır:
— Bash'te her şeyi otomatikleştirelim, yöneticilerin daha az manuel iş yapması için kendimizi komut dosyalarıyla kaplayalım!
Ama bu doğru değil.
Kod olarak altyapı, birlikte çalıştığınız BT sisteminin durumunu sürekli anlamak için kod biçiminde tanımlamanız anlamına gelir.
Diğer ekiplerle birlikte herkesin anlayabileceği ve gezinip gezinebileceği kod biçiminde bir harita oluşturursunuz. Chef, Ansible, Salt veya Kubernetes'te YAML dosyalarının kullanılması gibi ne yapıldığı önemli değil, hiçbir fark yok.
Konferansta 2GIS'ten bir meslektaşım, bireysel sistemlerin yapısını tanımlayan Kubernetes için kendi dahili şeylerini nasıl yaptıklarını anlattı. 500 sistemi tanımlamak için bu açıklamayı oluşturan ayrı bir araca ihtiyaç vardı. Bu açıklama olduğu zaman herkes birbirini kontrol edebilir, değişiklikleri izleyebilir, nasıl değiştirilip iyileştirilebileceğini, nelerin eksik olduğunu görebilir.
Katılıyorum, bireysel bash betikleri genellikle bu anlayışı sağlamaz. Çalıştığım şirketlerden birinde, "salt yazılır" komut dosyası için bir isim bile vardı - komut dosyası yazıldığında, ancak artık onu okumak mümkün değil. Bunun size de tanıdık geldiğini düşünüyorum.
Kod olarak altyapı altyapının mevcut durumunu açıklayan kod. Pek çok ürün, altyapı ve hizmet ekibi bu kod üzerinde birlikte çalışır ve en önemlisi hepsinin bu kodun gerçekte nasıl çalıştığını anlaması gerekir.
Kod, en iyi kod uygulamalarına göre korunur: ortak geliştirme, kod incelemesi, XP programlama, test etme, çekme istekleri, kod altyapıları için CI - bunların hepsi uygundur ve kullanılabilir.
Kod tüm mühendislerin ortak dili haline gelir.
Koddaki altyapıyı değiştirmek fazla zaman almaz. Evet altyapı kodunun da teknik borcu olabilir. Genellikle ekipler, bir dizi komut dosyası veya hatta spagetti kodu gibi yazdıkları Ansible biçiminde "kod olarak altyapıyı" uygulamaya başladıktan bir buçuk yıl sonra bu durumla karşılaşırlar ve karışıma bash komut dosyalarını da eklerler!
Bu çok önemli: Henüz bu şeyleri denemediyseniz şunu unutmayın Ansible bash değil! Belgeleri dikkatlice okuyun, bu konuda yazdıklarını inceleyin.
Kod olarak altyapı, altyapı kodunun ayrı katmanlara ayrılmasıdır.
Şirketimizde oldukça net ve basit olan 3 temel katmanı ayırıyoruz ancak bunların sayıları daha da fazla olabilir. Altyapı kodunuza bakarak bu duruma sahip olup olmadığınızı anlayabilirsiniz. Hiçbir katman vurgulanmazsa, biraz zaman ayırmanız ve biraz yeniden düzenleme yapmanız gerekir.
temel katman - işletim sistemi, yedeklemeler ve diğer düşük seviyeli şeyler bu şekilde yapılandırılır; örneğin Kubernetes'in temel düzeyde nasıl dağıtıldığı.
Servis seviyesi - bunlar geliştiriciye sağladığınız hizmetlerdir: bir hizmet olarak günlüğe kaydetme, bir hizmet olarak izleme, bir hizmet olarak veritabanı, bir hizmet olarak dengeleyici, bir hizmet olarak kuyruk, bir hizmet olarak Sürekli Teslimat - bireysel ekiplerin oluşturduğu bir dizi hizmet gelişmeyi sağlayabilir. Bunların hepsinin konfigürasyon yönetimi sisteminizdeki ayrı modüllerde açıklanması gerekir.
Uygulamaların yapıldığı katman ve önceki iki katmanın üzerinde nasıl ortaya çıkacaklarını açıklıyor.
Kontrol soruları
Şirketinizin ortak bir altyapı deposu var mı? Altyapınızdaki teknik borcu yönetiyor musunuz? Bir altyapı deposundaki geliştirme uygulamalarını kullanıyor musunuz? Altyapınız katmanlara bölünmüş mü? Temel hizmet-APP diyagramını kontrol edebilirsiniz. Bir değişiklik yapmak ne kadar zor?
Değişiklik yapmanın bir buçuk gün sürdüğünü deneyimlediyseniz bu, teknik borcunuz olduğu ve onunla çalışmanız gerektiği anlamına gelir. Altyapı kodunuzda teknik bir borç komisyonuna rastladınız. Bazı CCTL'leri değiştirmek için altyapı kodunun yarısını yeniden yazmanız gerektiğinde bu tür birçok hikayeyi hatırlıyorum, çünkü yaratıcılık ve her şeyi otomatikleştirme arzusu her şeyin her yerde paslanmasına, tüm tutamaçların kaldırılmasına ve yeniden düzenlemek gereklidir.
Sürekli Teslimat
Borçla krediyi karşılaştıralım. İlk önce oldukça basit olabilecek altyapının bir açıklaması geliyor. Her şeyi ayrıntılı olarak açıklamanıza gerek yok, ancak üzerinde çalışabilmeniz için bazı temel açıklamalar gereklidir. Aksi halde sürekli teslimatla bundan sonra ne yapılacağı belli değil. DevOps'a geldiğinizde tüm bu uygulamalar aynı anda ortaya çıkıyor, ancak bu, neye sahip olduğunuzu ve onu nasıl yöneteceğinizi anlamakla başlıyor. Bu tam olarak kod olarak altyapı uygulamasıdır.
Bu koda sahip olduğunuz ve onu nasıl yöneteceğiniz netleştiğinde, geliştirici kodunu mümkün olan en kısa sürede üretime nasıl göndereceğinizi bulmaya başlarsınız. Yani geliştiriciyle birlikte - "kuyular" sorununu hatırlıyoruz, yani bunu tek tek kişiler değil, bir ekip ortaya çıkarıyor.
biz birlikteyken Vanya Evtukhovich ilk kitabı gördüm Jez Mütevazi ve yazar grupları "Sürekli Teslimat"2009 yılında vizyona giren filminin başlığını Rusçaya nasıl çevireceğimizi uzun süre düşündük. “Sürekli teslimat” olarak tercüme etmek istediler ama ne yazık ki “Sürekli teslimat” olarak tercüme edildi. Bana öyle geliyor ki ismimizde baskıyla Rusça bir şeyler var.
Sürekli teslimat anlamına gelir
Ürün deposundaki kod her zaman üretime indirilebilir. Havası sönmüş olmayabilir ama buna her zaman hazırdır. Buna göre, kodu her zaman kuyruk kemiğinizin altında açıklanması zor bir kaygı hissi ile yazarsınız. Genellikle altyapı kodunu kullanıma sunduğunuzda görünür. Bu kaygı hissi mevcut olmalıdır; kodu biraz farklı yazmanıza izin veren beyin süreçlerini tetikler. Bu, geliştirme içindeki kurallara kaydedilmelidir.
Tutarlı bir şekilde teslimat yapmak için bir altyapı platformunda çalışan bir yapıt formatına ihtiyacınız var. Bir altyapı platformuna farklı formatlardaki “can atığını” atarsanız, o zaman birleşik hale gelir, bakımı zorlaşır ve teknik borç sorunu ortaya çıkar. Eserin formatının uyumlu hale getirilmesi gerekiyor - bu aynı zamanda kolektif bir görev: hepimizin bir araya gelmemiz, beynimizi hışırdatmamız ve bu formatı bulmamız gerekiyor.
Yapıt sürekli olarak geliştirilmekte ve teslimat hattında ilerledikçe üretim ortamına uyacak şekilde değişmektedir. Bir yapıt üretim hattı boyunca hareket ettiğinde, sürekli olarak kendisi için uygunsuz şeylerle karşılaşır; bunlar, sizin üretime koyduğunuz yapıtın karşılaştığı şeylere benzer. Klasik geliştirmede bu, devreye almayı yapan bir sistem yöneticisi tarafından yapılıyorsa, DevOps sürecinde bu her zaman olur: burada bunu bazı testlerle test ettiler, burada bunu bir Kubernetes kümesine attılar, bu da aşağı yukarı benzer üretime geçtiler, sonra aniden yük testine başladılar.
Bu biraz Pac-Man oyununu anımsatıyor - eser bir tür hikayeden geçiyor. Aynı zamanda kodun gerçekten hikayenin içinden geçip geçmediğini ve bir şekilde üretiminizle alakalı olup olmadığını da kontrol etmek önemlidir. Üretimden gelen hikayeler Sürekli Teslimat sürecine sürüklenebilir: Bir şey düştüğünde böyleydi, şimdi bu senaryoyu sistem içinde programlayalım. Her seferinde kod da bu senaryodan geçecek ve bir dahaki sefere bu sorunla karşılaşmayacaksınız. Bunu müşterinize ulaşmadan çok daha önce öğreneceksiniz.
Farklı dağıtım stratejileri. Örneğin, kodu farklı istemcilerde farklı şekilde test etmek, kodun nasıl çalıştığı hakkında bilgi almak ve 100 milyon kullanıcıya sunulduğundan çok daha erken bir zamanda AB testini veya kanarya dağıtımlarını kullanırsınız.
"Sürekli teslimat" şuna benzer:
Teslimat süreci Dev, CI, Test, PreProd, Prod ayrı bir ortam değildir, bunlar eserinizin geçtiği yanmaz toplamların olduğu aşamalar veya istasyonlardır.
Temel Hizmet APP olarak tanımlanan altyapı kodunuz varsa yardımcı olur tüm senaryoları unutmave bunları bu yapının kodu olarak yazın, eseri teşvik etmek ve ilerledikçe değiştirin.
Kendi kendine test soruları
Vakaların %95'inde özellik açıklamasından üretime geçilmesine kadar geçen süre bir haftadan az mı? Artefaktın kalitesi boru hattının her aşamasında artıyor mu? İçinden geçen bir hikaye var mı? Farklı dağıtım stratejileri kullanıyor musunuz?
Eğer tüm cevaplarınız evet ise, o zaman inanılmaz derecede havalısınız! Cevaplarınızı yorumlara yazın - memnun olacağım).
Geribesleme
Bu, tüm uygulamalar arasında en zor olanıdır. DevOpsConf konferansında Infobip'ten bir meslektaşım bundan bahsederken biraz kafası karışmıştı çünkü bu, her şeyi izlemeniz gerektiği gerçeğiyle ilgili gerçekten çok karmaşık bir uygulama!
Örneğin uzun zaman önce Qik'te çalışırken her şeyi izlememiz gerektiğini fark ettik. Bunu yaptık ve şu anda Zabbix'te sürekli izlenen 150 ürünümüz var. Korkunçtu, teknik direktör parmağını şakağına doğru büktü:
-Arkadaşlar, neden belirsiz bir şeyle sunucuya tecavüz ediyorsunuz?
Ancak daha sonra bunun gerçekten çok harika bir strateji olduğunu gösteren bir olay meydana geldi.
Hizmetlerden biri sürekli çökmeye başladı. Başlangıçta çökmedi, bu ilginç, kod oraya eklenmedi, çünkü pratikte hiçbir ticari işlevi olmayan temel bir komisyoncuydu - sadece bireysel hizmetler arasında mesajlar gönderiyordu. Servis 4 ay boyunca değişmedi ve bir anda “Segmentasyon hatası” hatasıyla çökmeye başladı.
Şok olduk, Zabbix'teki grafiklerimizi açtık ve bir buçuk hafta önce bu komisyoncunun kullandığı API hizmetindeki isteklerin davranışının büyük ölçüde değiştiği ortaya çıktı. Daha sonra belirli bir tür mesajın gönderilme sıklığının değiştiğini gördük. Daha sonra bunların Android istemcileri olduğunu öğrendik. Biz sorduk:
— Çocuklar, bir buçuk hafta önce size ne oldu?
Yanıt olarak kullanıcı arayüzünü nasıl yeniden tasarladıklarına dair ilginç bir hikaye duyduk. Herhangi birinin hemen HTTP kitaplığını değiştirdiğini söylemesi pek olası değildir. Android istemcileri için bu, banyoda sabun değiştirmek gibidir; sadece hatırlamazlar. Sonuç olarak, 40 dakikalık bir konuşmanın ardından HTTP kütüphanesini değiştirdiklerini ve varsayılan zamanlamalarının değiştiğini öğrendik. Bu, API sunucusundaki trafik davranışının değişmesine yol açtı ve bu da komisyoncu içinde yarışa neden olan bir duruma yol açtı ve çökmeye başladı.
Derin izleme olmadan bunu açmak genellikle imkansızdır.. Eğer örgütte hala “kuyu” sorunu varsa, herkes birbirine para atıyorsa bu durum yıllarca devam edebilir. Sorunu çözmek imkansız olduğundan sunucuyu yeniden başlatmanız yeterlidir. Sahip olduğunuz tüm olayları izlediğinizde, takip ettiğinizde, takip ettiğinizde ve izlemeyi test olarak kullandığınızda - kod yazın ve nasıl izleneceğini hemen belirtin, ayrıca kod biçiminde (kod olarak altyapımız zaten var), her şey nasıl netleşiyor avuç içinde. Bu kadar karmaşık problemler bile kolaylıkla takip edilebilir.
Eserin başına ne geldiğine ilişkin tüm bilgileri üretim aşamasında değil, teslimat sürecinin her aşamasında toplayın.
İzlemeyi CI'ya yüklediğinizde bazı temel şeyler orada zaten görünür olacaktır. Daha sonra bunları Test, PredProd ve yük testinde göreceksiniz. Yalnızca ölçümler, istatistikler değil, aynı zamanda günlükler de dahil olmak üzere tüm aşamalarda bilgi toplayın: uygulamanın nasıl kullanıma sunulduğu, anormallikler - her şeyi toplayın.
Aksi takdirde bunu anlamak zor olacaktır. DevOps'un daha karmaşık olduğunu zaten söylemiştim. Bu karmaşıklığın üstesinden gelmek için normal analizlere sahip olmanız gerekir..
Otokontrol için sorular
İzlemeniz ve günlüğe kaydetmeniz sizin için bir geliştirme aracı mı? Siz de dahil olmak üzere geliştiricileriniz kod yazarken onu nasıl izleyeceklerini düşünüyor mu?
Müşterilerden sorunları duyuyor musunuz? İstemciyi izleme ve günlüğe kaydetme yoluyla daha iyi anlıyor musunuz? Sistemi izleme ve kayıt tutma yoluyla daha iyi anlıyor musunuz? Sırf sistemdeki trendin büyüdüğünü gördüğünüz ve önümüzdeki 3 hafta içinde her şeyin öleceğini anladığınız için mi sistemi değiştiriyorsunuz?
Bu üç bileşene sahip olduğunuzda şirketinizde nasıl bir altyapı platformuna sahip olduğunuzu düşünebilirsiniz.
Altyapı platformu
Önemli olan, bunun her şirketin sahip olduğu bir dizi farklı araç olması değil.
Altyapı platformunun amacı tüm ekiplerin bu araçları kullanması ve birlikte geliştirmesidir.
Altyapı platformunun ayrı ayrı parçalarının geliştirilmesinden sorumlu ayrı ekiplerin olduğu açıktır. Ancak aynı zamanda her mühendis altyapı platformunun geliştirilmesi, performansı ve tanıtımından sorumludur. Dahili düzeyde ortak bir araç haline gelir.
Tüm ekipler altyapı platformunu geliştirir ve ona kendi IDE'leri gibi özenle davranır.. IDE'nizde her şeyi güzel ve hızlı hale getirmek için farklı eklentiler yükler ve kısayol tuşlarını yapılandırırsınız. Sublime, Atom veya Visual Studio Code'u açtığınızda kod hataları yağıyor ve hiçbir şekilde çalışmanın imkansız olduğunu anlıyorsunuz, hemen üzülüyor ve IDE'nizi düzeltmeye koşuyorsunuz.
Altyapı platformunuza da aynı şekilde davranın. Bir sorun olduğunu anlıyorsanız, kendiniz düzeltemiyorsanız bir istek bırakın. Basit bir şey varsa, kendiniz düzenleyin, çekme isteği gönderin, adamlar bunu dikkate alacak ve ekleyecektir. Bu, geliştiricinin kafasındaki mühendislik araçlarına biraz farklı bir yaklaşımdır.
Altyapı platformu, kalitenin sürekli iyileştirilmesiyle eserin geliştirme aşamasından müşteriye aktarılmasını sağlar. IP, üretim sırasında kodun başına gelen bir dizi hikayeyle programlanır. Yıllar geçtikçe bu hikayelerden çok sayıda ortaya çıktı, bazıları benzersiz ve yalnızca sizinle ilgili; Google'da aratılamazlar.
Bu noktada altyapı platformu rekabet avantajınız haline geliyor, çünkü içinde rakibin aracında olmayan bir şey var. IP'niz ne kadar derin olursa, Pazara Çıkış Süresi açısından rekabet avantajınız da o kadar büyük olur. Burada görünür Satıcı kilitleme sorunu: Başka birinin platformunu kullanabilirsiniz, ancak başka birinin deneyimini kullanarak bunun sizinle ne kadar alakalı olduğunu anlayamazsınız. Evet her firma Amazon gibi bir platform kuramaz. Bu, şirketin deneyiminin pazardaki konumuyla ilgili olduğu zor bir çizgidir ve burada satıcı kilidini kullanamazsınız. Bunun da düşünülmesi önemlidir.
düzen
Bu, bir DevOps şirketindeki tüm uygulamaları ve süreçleri kurmanıza yardımcı olacak bir altyapı platformunun temel diyagramıdır.
Nelerden oluştuğuna bir bakalım.
Kaynak düzenleme sistemiuygulamalara ve diğer hizmetlere CPU, bellek, disk sağlar. Bunun üzerinde - düşük seviyeli hizmetler: izleme, günlük kaydı, CI/CD Motoru, yapıt depolama, sistem kodu olarak altyapı.
Daha yüksek düzeyde hizmetler: hizmet olarak veritabanı, hizmet olarak kuyruklar, hizmet olarak Yük Dengesi, hizmet olarak görüntünün yeniden boyutlandırılması, hizmet olarak Büyük Veri fabrikası. Bunun üzerinde - Müşterinize sürekli olarak değiştirilen kodu ileten boru hattı.
Yazılımınızın istemci için nasıl çalıştığına dair bilgi alırsınız, değiştirirsiniz, bu kodu tekrar sağlarsınız, bilgi alırsınız ve böylece hem altyapı platformunu hem de yazılımınızı sürekli geliştirirsiniz.
Diyagramda teslimat hattı birçok aşamadan oluşmaktadır. Ancak bu örnek olarak verilen şematik bir diyagramdır, tek tek tekrarlamaya gerek yoktur. Aşamalar hizmetlerle sanki hizmetmiş gibi etkileşime girer; platformun her bir parçası kendi hikayesini taşır: kaynakların nasıl tahsis edildiği, uygulamanın nasıl başlatıldığı, kaynaklarla nasıl çalıştığı, izlendiği ve değiştiği.
Platformun her parçasının bir hikaye taşıdığını anlayıp kendinize bu tuğlanın hangi hikayeyi taşıdığını sorun, belki de atılmalı ve üçüncü taraf bir hizmetle değiştirilmelidir. Mesela tuğla yerine Okmeter takılabilir mi? Belki de adamlar bu uzmanlığı bizden çok daha fazla geliştirdiler. Ama belki de değil; belki de benzersiz bir uzmanlığa sahibiz, Prometheus'u kurup onu daha da geliştirmemiz gerekiyor.
Platformun oluşturulması
Bu karmaşık bir iletişim sürecidir. Temel uygulamalara sahip olduğunuzda, gereksinimleri ve standartları geliştiren ve bunları sürekli olarak farklı araç ve yaklaşımlara dönüştüren farklı mühendisler ve uzmanlar arasında iletişim kurmaya başlarsınız. DevOps'ta sahip olduğumuz kültür burada önemli.
Kültürle her şey çok basittir - işbirliği ve iletişim ile ilgilidiryani ortak alanda çalışma isteği, bir enstrümanı birlikte kullanma isteği. Burada roket bilimi yok - her şey çok basit, banal. Mesela hepimiz girişte yaşıyoruz ve burayı temiz tutuyoruz - bu nasıl bir kültür.
Neye sahipsin?
Yine kendinize sorabileceğiniz sorular.
Altyapı platformu özel mi? Gelişiminden kim sorumlu? Altyapı platformunuzun rekabet avantajlarını anlıyor musunuz?
Bu soruları kendinize sürekli sormanız gerekiyor. Bir şey üçüncü parti servislere aktarılabilecekse aktarılmalıdır; üçüncü parti bir servis hareketinizi engellemeye başlıyorsa o zaman kendi içinizde bir sistem kurmanız gerekir.
Yani DevOps'u...
... bu karmaşık bir sistemdir ve şunları içermesi gerekir:
- Dijital ürün.
- Bu dijital ürünü geliştiren iş modülleri.
- Kod yazan ürün ekipleri.
- Sürekli Teslimat uygulamaları.
- Hizmet olarak platformlar.
- Altyapı Hizmeti.
- Kod olarak altyapı.
- Güvenilirliği korumaya yönelik DevOps'ta yerleşik ayrı uygulamalar.
- Her şeyi açıklayan bir geri bildirim uygulaması.
Bu diyagramı, şirketinizde halihazırda sahip olduğunuz şeyleri bir biçimde vurgulayarak kullanabilirsiniz: geliştirildi mi veya hala geliştirilmesi gerekiyor.
Birkaç hafta içinde bitecek . RIT++'ın bir parçası olarak. Sürekli teslimat, kod olarak altyapı ve DevOps dönüşümü hakkında birçok harika rapor bulacağınız konferansa gelin. , son fiyat son tarihi 20 Mayıs
Kaynak: habr.com