Tabii ki bahsediyoruz . Ayrıntılara girmezseniz 30 Eylül ve 1 Ekim'de geliştirme, test etme ve işletme süreçlerini birleştirme konusunda bir konferans düzenleyeceğiz ve ayrıntılara girerseniz lütfen kedi altında.
DevOps yaklaşımında projenin teknolojik gelişiminin tüm parçaları iç içedir, paralel olarak gerçekleşir ve birbirini etkiler. Burada özellikle önemli olan, gerçek zamanlı olarak değiştirilebilen, simüle edilebilen ve test edilebilen otomatikleştirilmiş geliştirme süreçlerinin oluşturulmasıdır. Bu, pazardaki değişikliklere anında yanıt vermenize yardımcı olur.
Konferansta bu yaklaşımın ürün geliştirmeyi nasıl etkilediğini göstermek istiyoruz. Müşteri için sistemin güvenilirliği ve uyarlanabilirliği nasıl sağlanır? DevOps, bir şirketin iş sürecini düzenlemeye yönelik yapısını ve yaklaşımını nasıl değiştiriyor?
kamera ARKASI
DevOps yaklaşımı çerçevesinde sadece farklı şirketlerin neler yaptığını bilmek değil, tüm bunların neden yapıldığını anlamak da bizim için önemli. Bu nedenle Program Komitesine yalnızca uzmanları değil, DevOps söylemini farklı konumlardan gören uzmanları da davet ettik:
- kıdemli mühendisler;
- geliştiriciler;
- takım liderleri;
- CTO.
Bu durum bir yandan rapor taleplerini tartışırken zorluklara ve çatışmalara neden oluyor. Bir mühendis büyük bir kazayı analiz etmekle ilgileniyorsa, geliştiricinin bulutlarda ve altyapılarda çalışan yazılımın nasıl oluşturulacağını anlaması daha önemlidir. Ancak anlaşarak mühendislerden CTO'ya kadar herkes için değerli ve ilginç olacak bir program yaratıyoruz.
Konferansımızın amacı yalnızca en çok ilgi çeken raporları seçmek değil, aynı zamanda genel resmi sunmaktır: DevOps yaklaşımının pratikte nasıl çalıştığı, yeni süreçlere geçerken ne tür komisyonlarla karşılaşabileceğiniz. Aynı zamanda iş probleminden belirli teknolojilere inerek içerik kısmını da oluşturuyoruz.
Konferans bölümleri öncekiyle aynı kalacaktır. .
- Altyapı platformu.
- Kod olarak altyapı.
- Sürekli teslimat.
- Bize.
- DevOps'ta mimari, CTO için DevOps.
- SRE uygulamaları.
- Eğitim ve bilgi yönetimi.
- Güvenlik, DevSecOps.
- DevOps dönüşümü.
Bildiri Çağrısı: ne tür raporlar arıyoruz
Konferansın potansiyel izleyicilerini şartlı olarak beş gruba ayırdık: mühendisler, geliştiriciler, güvenlik uzmanları, ekip liderleri ve CTO. Her grubun konferansa gelme konusunda kendi motivasyonu vardır. Ve DevOps'a bu konumlardan bakarsanız, konunuza nasıl odaklanacağınızı, nereye vurgu yapmanız gerektiğini anlayabilirsiniz.
Mühendisler için, Altyapı platformu oluşturanlar için mevcut trendleri anlamak, şu anda hangi teknolojilerin en gelişmiş olduğunu anlamak önemlidir. Bu teknolojileri kullanma ve fikir alışverişinde bulunma konusunda gerçek yaşam deneyimlerini öğrenmekle ilgilenecekler. Bir mühendis ciddi bir kazayı analiz eden bir raporu dinlemekten mutluluk duyacaktır ve biz de buna karşılık böyle bir raporu seçip düzeltmeye çalışacağız.
Geliştiriciler için gibi bir kavramı anlamak önemlidir. bulut yerel uygulaması. Yani yazılımların bulutlarda ve çeşitli altyapılarda çalışacak şekilde nasıl geliştirileceği. Geliştiricinin sürekli olarak yazılımdan geri bildirim alması gerekir. Burada şirketlerin bu süreci nasıl oluşturdukları, yazılım performansının nasıl izlendiği ve tüm teslimat sürecinin nasıl çalıştığına dair vakalar duymak istiyoruz.
Siber güvenlik uzmanları Şirket içindeki gelişim ve değişim süreçlerini aksatmayacak şekilde güvenlik sürecinin nasıl kurulacağını anlamak önemlidir. DevOps'un bu tür uzmanlara yüklediği gereksinimlerle ilgili konular da ilginç olacaktır.
Ekip liderleri bilmek istiyor, diğer şirketlerde sürekli teslimat sürecinin nasıl işlediğini. Şirketler bunu başarmak için nasıl bir yol izledi, DevOps bünyesinde geliştirme ve kalite güvence süreçlerini nasıl kurguladılar? Ekip liderleri de Bulut yereliyle ilgileniyor. Ayrıca ekip içindeki ve geliştirme ve mühendislik ekipleri arasındaki etkileşimle ilgili sorular.
için CTO en önemli şey, tüm bu süreçleri nasıl birbirine bağlayacağınızı ve bunları iş ihtiyaçlarına göre nasıl ayarlayacağınızı bulmaktır. Uygulamanın hem işletme hem de müşteri açısından güvenilir olmasını sağlar. Ve burada hangi teknolojilerin hangi iş görevlerinde işe yarayacağını, tüm sürecin nasıl inşa edileceğini vb. anlamanız gerekir. CTO aynı zamanda bütçelemeden de sorumludur. Örneğin, DevOps'ta çalışabilmeleri için uzmanların yeniden eğitilmesine ne kadar para harcanması gerektiğini anlaması gerekiyor.
Bu konularda söyleyecekleriniz varsa sessiz kalmayın, . Bildiri çağrısı için son tarih 20 Ağustos'tur. Ne kadar erken kayıt olursanız raporunuzu sonuçlandırmak ve sunumunuza hazırlanmak için o kadar fazla zamanınız olur. O yüzden gecikmeyin.
Eğer topluluk önünde konuşmaya ihtiyacınız yoksa, sadece ve meslektaşlarınızla iletişim kurmak için 30 Eylül ve 1 Ekim'de gelin. İlginç ve ilham verici olacağına söz veriyoruz.
DevOps'u nasıl görüyoruz?
DevOps derken tam olarak neyi kastettiğimizi anlamak için raporumu okumanızı (ya da yeniden okumanızı) öneririm”" Pazarın dalgaları arasında yürürken, DevOps fikrinin küçük bir startup'tan çok uluslu şirketlere kadar farklı büyüklükteki şirketlerde nasıl dönüştüğünü gözlemledim. Rapor bir dizi soru üzerine kuruludur; bunları yanıtlayarak şirketinizin DevOps'a doğru ilerleyip ilerlemediğini veya bir yerlerde sorun olup olmadığını anlayabilirsiniz.
DevOps karmaşık bir sistemdir ve şunları içermelidir:
- 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ı.
Raporun sonunda şirketteki DevOps sistemi hakkında fikir veren bir diyagram yer alıyor. Şirketinizdeki hangi süreçlerin halihazırda kolaylaştırıldığını ve hangilerinin henüz oluşturulmadığını görmenizi sağlayacaktır.
Raporun videosunu izleyebilirsiniz .
Ve şimdi bir bonus olacak: RIT++ 2019'dan DevOps dönüşümünün en genel sorunlarına değinen birkaç video.
Ürün olarak şirket altyapısı
Artyom Naumenko, Skyeng'deki DevOps ekibine liderlik ediyor ve şirketinin altyapısının geliştirilmesiyle ilgileniyor. Altyapının SkyEng'deki iş süreçlerini nasıl etkilediğini anlattı: yatırım getirisinin nasıl hesaplanacağını, hesaplama için hangi ölçümlerin seçilmesi gerektiğini ve bunları iyileştirmek için nasıl çalışılacağını anlattı.
Mikro hizmetlere giden yolda
Nixys şirketi yoğun web projeleri ve dağıtılmış sistemler için destek sağlar. Teknik direktörü Boris Ershov, geliştirilmesine 5 yıl önce (veya daha fazla) başlayan yazılım ürünlerinin modern bir platforma nasıl çevrileceğini anlattı.
Kural olarak, bu tür projeler, altyapının o kadar karanlık ve eski köşelerinin mevcut mühendislerin bilmediği özel bir dünyadır. Ve bir zamanlar seçilen mimari ve geliştirme yaklaşımları güncelliğini kaybetmiş durumda ve işletmeye aynı hızda geliştirme ve yeni sürümlerin yayınlanmasını sağlayamıyor. Sonuç olarak, her ürünün piyasaya sürülmesi, bir şeyin sürekli olarak ve en beklenmedik yerde düştüğü inanılmaz bir maceraya dönüşüyor.
Bu tür projelerin yöneticileri kaçınılmaz olarak tüm teknolojik süreçleri dönüştürme ihtiyacıyla karşı karşıya kalıyor. Boris raporunda şunları söyledi:
- proje için doğru mimarinin nasıl seçileceği ve altyapının nasıl düzenleneceği;
- dönüşüm yolunda hangi araçların kullanılacağı ve hangi tuzaklarla karşılaşılacağı;
- Sonra ne yapacağız.
Sürümlerin otomasyonu veya hızlı ve sorunsuz bir şekilde nasıl teslim edileceği
Alexander Korotkov, CIAN'da CI/CD sisteminin önde gelen geliştiricilerinden biridir. Kaliteyi artırmayı ve kodun üretime teslim süresini 5 kat azaltmayı mümkün kılan otomasyon araçlarından bahsetti. Ancak bu tür sonuçlara yalnızca otomasyonla ulaşılamayacağından Alexander, geliştirme süreçlerindeki değişikliklere de dikkat etti.
Kazalar öğrenmenize nasıl yardımcı olur?
Alexey Kirpichnikov, 5 yıldır SKB Kontur'da DevOps ve altyapı uyguluyor. Üç yıl boyunca, şirketinde farklı derecelerde destansı yaklaşık 1000 sahte olay meydana geldi. Örneğin bunların %36'sı düşük kaliteli bir sürümün üretime sunulmasından, %14'ü ise veri merkezindeki donanım bakım çalışmalarından kaynaklandı.
Şirketin mühendislerinin birkaç yıldır arka arkaya muhafaza ettiği bir rapor arşivi (post-mortem) kazalar hakkında bu kadar doğru bilgi edinmeyi mümkün kılıyor. Otopsi, acil durum sinyaline ilk yanıt veren ve her şeyi düzeltmeye başlayan görevli mühendis tarafından yazılmıştır. Neden geceleri facap'lerle boğuşan mühendislere rapor yazarak eziyet edesiniz ki? Bu veriler, resmin tamamını görmenize ve altyapı gelişimini doğru yönde ilerletmenize olanak tanır.
Alexey konuşmasında gerçekten yararlı bir otopsi nasıl yazılacağını ve bu tür raporların büyük bir şirkette nasıl uygulanacağını paylaştı. Birinin nasıl işleri berbat ettiğiyle ilgili hikayeleri seviyorsanız performansın videosunu izleyin.
DevOps vizyonunuzun bizimkiyle eşleşmeyebileceğinin farkındayız. DevOps dönüşümünü nasıl gördüğünüzü bilmek ilginç olacak. Bu konuyla ilgili deneyiminizi ve vizyonunuzu yorumlarda paylaşın.
Programa halihazırda hangi raporları kabul ettik?
Bu hafta Program Komitesi 4 raporu kabul etti: güvenlik, altyapı ve SRE uygulamaları hakkında.
DevOps dönüşümünün belki de en sancılı konusu: bilgi güvenliği departmanındaki adamların geliştirme, operasyon ve yönetim arasında halihazırda kurulmuş olan bağlantıları bozmamalarından nasıl emin olunacağı. Bazı şirketler bilgi güvenliği departmanı olmadan yönetir. Bu durumda bilgi güvenliği nasıl sağlanır? Bu konuda Sudo.su'dan Mona Arkhipova. Raporundan şunu öğreniyoruz:
- neyin korunması gerektiği ve kimden korunması gerektiği;
- rutin güvenlik süreçleri nelerdir;
- BT ve bilgi güvenliği süreçlerinin nasıl kesiştiği;
- CIS CSC nedir ve nasıl uygulanır;
- Düzenli bilgi güvenliği kontrollerinin nasıl ve hangi göstergelerle gerçekleştirileceği.
Bir sonraki rapor, altyapının kod olarak geliştirilmesiyle ilgilidir. Manuel rutin miktarını azaltın ve tüm projeyi kaosa çevirmeyin, bu mümkün mü? Bu soruya Ixtens'ten Maxim Kostrikin. Şirketi kullanıyor Terraform AWS altyapısıyla çalışmak için. Araç kullanışlıdır ancak sorun, onu kullanırken büyük bir kod bloğu oluşturmaktan nasıl kaçınılacağıdır. Böyle bir mirasın bakımı her yıl giderek daha pahalı hale gelecektir.
Maxim, otomasyonu ve geliştirmeyi basitleştirmeyi amaçlayan kod yerleştirme modellerinin nasıl çalıştığını gösterecek.
Bir tane daha altyapıyı duyacağız Playkey'den Vladimir Ryabov. Burada altyapı platformundan bahsedeceğiz ve şunları öğreneceğiz:
- depolama alanının etkili bir şekilde kullanılıp kullanılmadığının nasıl anlaşılacağı;
- yalnızca 10 TB depolama alanı kullanıldığında birkaç yüz kullanıcının nasıl 20 TB içerik alabileceği;
- verilerin 5 kez sıkıştırılıp kullanıcılara gerçek zamanlı olarak nasıl sunulacağı;
- birden fazla veri merkezi arasında verilerin anında nasıl senkronize edileceği;
- bir sanal makineyi sırayla kullanırken kullanıcıların birbirleri üzerindeki etkisinin nasıl ortadan kaldırılacağı.
Bu büyünün sırrı teknoloji FreeBSD için ZFS ve taze çatalı Linux'ta ZFS. Vladimir, Playkey'den vakaları paylaşacak.
Amixr.IO'dan Matvey Kukuy hayattan örneklerle hazır , ne İBBS ve güvenilir sistemler oluşturmaya nasıl yardımcı olduğunu. Amixr.IO, müşteri olaylarını arka uç aracılığıyla aktarıyor; dünya çapında düzinelerce görev başındaki ekip halihazırda 150 bin vakayla ilgilendi. Konferansta Matvey, şirketinin müşteri sorunlarını çözerek ve arızaları analiz ederek biriktirdiği istatistik ve öngörüleri paylaşacak.
Bir kez daha açgözlü olmamanızı ve bir DevOps samurayı olarak deneyiminizi paylaşmanızı tavsiye ediyorum. Sert bir rapor için, sen ve benim mükemmel bir konuşma hazırlamak için 2,5 ayımız olacak. Dinleyici olmak istiyorsanız program güncellemelerini içeren haber bültenine gidin ve biletleri önceden ayırtmayı ciddi olarak düşünün, çünkü konferans tarihlerine yaklaştıkça biletler daha pahalı hale gelecektir.
Kaynak: habr.com