DevOps iniş üçlemesi: sorumluluk nasıl empoze edilir? Hangi araçları kullanıyorsun? Nereye gitmeli?
Genel Bakış
Bugün DevOps'u esas olarak iki yönden tartışacağım.Arkadaşlarımın çoğu işletim ve bakım düzeyini daha fazla görmüş olabileceğinden, Dev düzeyine, yani Dev'den çalıştırmaya ve bakıma daha çok odaklandım, çünkü bu bütündür. Tüm süreç burada olduğunda, bazı uygulamaları ve gelecekte bazı fırsatları ve eğilimleri gördük.
1. İş ve sistem geliştirmeden kaynaklanan sorunlara bakmak
İş ve sistemin geliştirilmesinden, o sırada karşılaştığımız sorunlara ve çözümlere bakarız. Tıpkı Cheng Yongxin'in işletme düzeyinde işletme ve bakımda söylediği gibi, gelecek DevOps değildir. Odak noktası, AIOps düzeyinde olabilir. DevOps, ADPaas platformuna daha fazla dikkat etmeli, işletim ve bakım ise daha çok AIOps'a odaklanıyor Tıpkı Google'ın sisteminin otonom olması ve insan müdahalesi gerektirmemesi gibi, işletim ve bakım tarafında da büyük zorluklar yaşanacaktır.
Yukarıdakiler, tüm İnternet şirketlerine veya girişimcilik için risk dönemini geçmiş bazı şirketlere kabaca benzer olan şirketin temel bir organizasyon yapısıdır.Bu, standartlaştırılmış bir sistemdir, yani iş ve Ar-Ge, test, işletme ve bakımın dahil olduğu anlamına gelir. yapı.
Çevik ve sürekli entegrasyon
İlk süreç sadece çevik ve sürekli entegrasyon yapmaktır.Tüm girişimci ekipler gibi, dahili standartlar, hızlı çalışma planları ve düşük kalite yoktur. Yeni kurulan şirketlerde veya bazı orta ölçekli şirketlerde kalan herkes, temelde standartlaştırılmış süreçler aşamasına gelmediklerini bilecek ve temelde aynı sorunlar var olacak, yani İşletme yönetimi ve Ar-Ge kenetlenmesi çok kaotiktir ve nispeten standartlaştırılmış bir süreç yoktur .
Test için gönderilen şeyleri geliştirirken çok fazla sorumluluk duygusu yoktur (psikolojik konumlandırma açısından, test uzmanı kodlama kalitesi için koruyucu bir ağ olarak kabul edilir) ve içinde birçok hata vardır. Ardından testi başlatın, testin oluşturmasına, paketi oluşturmasına izin verin ve son olarak onu çalıştırma ve bakıma devredin ve çevrimiçi işlemden işletme ve bakım sorumludur. Belli bir yayın makinesine kopyalamak, kopyaladıktan, bir klasörle etiketleyip O&M, O&M'ye verdikten sonra çevrimiçi olarak atmak gibi tüm süreç çok dağınıktır, çevrimiçi attıktan sonra biraz zaman alacaktır. Sorun olmadığını görünce eve uyumaya gittim.
Problemler var: Temel sorun, talep tarafındaki proje yönetiminin çok dağınık olması, Ar-Ge'nin teslimat kalitesinin çok düşük olması ve çok fazla yeniden çalışma yapılacak olmasıdır. Proje başlatma döngüsü uzun ve birçok sorun var.
Önce sürekli entegrasyona dayalı iyileştirmeler yapın. Süreç yönetimi açısından Scrum tanıtıldı ve Scrum'da bazı ayarlamalar yapıldı. Aslında, çevik çevrede son zamanlarda çok sayıda tartışma yaşandı. Herkes çeşitli metodolojilerden memnun değil ve hepsi "cennetin iradesini" temsil ettiklerini düşünüyor. Ama işletme perspektifinden, özellikle problem çözme perspektifinden, hangisini kullandığımız önemli değil, problem çözüldü. Bu nedenle Scrum, işletmenin mevcut personel durumuna göre uyarlanır, her şey gerekli değildir ve Scrum ile hangi sorunların yapılması gerektiği açıktır. Scrum sürecini tanıttıktan sonra, gereksinim yönetimi ve zamanlama yapmak için JIRA'yı kullanın ve ardından tüm kodu yönetmek, bir sunucu kurmak ve UT yapmak için dahili olarak GitLab'ı kullanın ve hızlı bir şekilde iyi geri bildirim alabilirsiniz. Bu çok olgun bir rutindir, zorunlu bir şekilde yapılırsa hızlı bir şekilde etkili olur ve 1-2 ay içerisinde düzelebilir.
Problemler var: Şu anda, hala bazı problemler olduğu, yani Ar-Ge'den teste kadar olan çıktıların farklı kaynaklardan olduğu ve tutarlılıkla ilgili problemler olduğu keşfedildi (daha sonra tutarlılık problemlerinden bahsedeceğiz); testin manuel doğrulama döngüsü hala çok uzun, çünkü testi otomatikleştirmiyor, yani Fonksiyonel testler ve performans testleri otomatikleştirilmedi; projenin çevrimiçi olması uzun zaman aldı çünkü operasyon ve bakım tarafına dokunmadı. Yani şu anda yapmamız gereken şey sürekli teslimatın ilk versiyonu, biz buna 1.0 sürekli teslimat diyoruz.
Sürekli Teslimat 1.0
Continuous Delivery 1.0 ne yapar? Şu anda 40 kişiden az olan çoğu küçük takımın yaptığı şey bu- Teslimat hattı Aslında, çoğu takım bunu bir ardışık düzen eklentisi ekleyerek yapar, dağıtım komut dosyası Jenkins'te yazılır ve ardından kaynak koduyla bir araya getirilir. Bu, sürekli teslim şeylerinin çoğu Bir ardışık düzen eklentisi ekleyin .
Önceki CI'nin hala yapılması gerekiyor, ancak Jenkins'in belirli bir oluşturma yeteneği var ve ardışık düzen eklentisi aracılığıyla çoklu ortam dağıtımı yapabiliriz, inşa edildiği sürece adım adım yükseltilecektir (Promosyon), ancak UAT'den üretime manuel işçilik gerektirir. Nihai onay tam otomatik değildir.
Problemler var: sorun nedir? Sürekli teslimat, yalnızca bir kez oluşturulduğu ve daha sonra bir ürün kitaplığının tanıtılmasını gerektiren yerleşik ürün üzerinde doğrulanıp dağıtıldığı anlamına gelir. Bununla birlikte, kod oluşturma ve doğrulama sürecinde, bazıları kodu doğrudan sürüm kitaplığından çeker, sürekli olarak kodu çeker ve ardından çekmeden sonra dinamik olarak paketler, böylece bazı sorunlar olacaktır.
Bu nedenle, ürün kitaplığının tanıtımı, aldığınız şeylerin ilk seferde başarıyla inşa edilenler olduğu ve ardından buna eklemeye devam ettiğiniz anlamına gelir. işlenmemiş veri . Orijinal veriler nedir? Test edilmiş veya test edilmemiş ve kimin doğrulayacağı tek testin yüzdesidir.Bu, ürünle ilgili bazı davranış ve işlem verileridir. Kaydedilmesi gerekir çünkü sonraki faaliyetler bu verilere dayanabilir. karar vermek.
- Ürün kitaplığı: Nexus- > Artifaktör > Bireysel çalışma
Ürün kitaplığı seçim sürecinin tamamı üç aşamadan geçti: İlk projenin tamamı Java'da yapıldı ve Nexus'u ürün yapısını yönetmek için özel bir kitaplık olarak kullanmak doğaldı. Çünkü bağımlılık sorununu çözmek kolaydır ve bağımlılık çok zahmetlidir. Nexus, ürün sürümlerini desteklediğinden, derleme sürümü izlemeyi desteklemez ve orijinal verileri yönetme yeteneğine sahip değildir.
Bu yüzden ikinci adım, daha olgun ve kullanılan ve şu anda Google, Tencent ve Ali tarafından kullanılan Artifactory'yi kullanmayı umarak JFrog ile bağlantı kurmaktır. Ancak sorun şu ki şirket büyük değil ve Artifactory'nin profesyonel versiyonu daha pahalı.Böyle bir maliyete katlanmak biraz ekonomik değil.Herkes gibi biz de açık kaynak sürümünü kullanmak istiyoruz, ancak Artifactory'nin topluluk sürümü çoklu dili desteklemiyor ve bir sürüm oluşturuyor. Destek profesyonel bir versiyon gerektirdiğinden hiçbir yolu yok, araştırmadan sonra kendimiz yapacağız, ne yapmalıyız?
Çok basit, S3'e benzer bir dosya servisini alıp dosya servisine koyabilirsiniz. İkinci olarak, bunu yapmak için bir veritabanı kullanıyoruz.Bazı veritabanları aslında büyük ikili dosyaları depolayabilir ve anahtar-değer meta verilerini kolayca yönetebilir. Ancak, kendi başımıza bir ürün kitaplığı geliştirme sorunu eşzamanlılık ve yüksek Mevcut ve hızlı bir şekilde yayınlanır. Küçük ölçekte bunlar sorun değil.
Faydaları nelerdir? Ürün kitaplığını ekledikten sonra, derleme sürümünün ve meta verilerin işaretlendiğinden emin olabiliriz.Bu durumda, konuşlandırılanların hepsinin aynı kaynaktan olmasını ve meta verilere göre dağıtım mantığında adım adım seçilebilmesini sağlıyoruz, ancak değil Önceki aşamadan sonra veya belirli bir yüzdeye ulaştıktan sonra, sonraki aşamanın bu yapı ürününü görmesine izin vermiyorum.
Şimdi tüm yapı, yani duvar aslında geliştirmeden teste geçti.
Problemler var: Şu anda, işletim ve bakım personelinin, uygulama dağıtımı da dahil olmak üzere çok sayıda ortamı sürdürmesi gerektiğini gördük; ikincisi, derleme ortamı ve üretim ortamının tutarlılığı sorunludur. neden? Örneğin, derleme ortamı Jenkins'e yerleştirilmişse, inşa etmek için kullanılıyorsa, ortamı sabitlenir, örneğin JDK1.8, o zaman tüm şeylerim sadece JDK1.8 üzerinde oluşturulabilir, ancak JDK1'i kurmak istersem. 7? Sonra bunu yapmak için başka bir ortam kurun ki bu daha zahmetlidir. Konuşlandırma mantığı ve Jenkins sıkı sıkıya bağlıdır, çünkü bunlar Jenkins'te yazılmıştır ve hızlı bir geri alma mekanizmasına sahip değildir. Bazen, aslında hızlı bir şekilde geri almak gerekir ve kod sürümünü yeniden çekip yeniden dağıtamazsınız. Son olarak, yarı otomatik test yapmak için hala çok sayıda kişiye ihtiyaç vardır.
Sürekli Teslimat 2.0
- Konfigürasyon yönetim aracı (Ansible) ile ortamı yönetin
2.0'ın sürekli teslimi, aslında, makinelerin çoğu sanal makinelerdir. Şu anda Ansible'ı ekledikten sonra, bu kümelerin ortamını yönetmek için Jenkins'i kullanabilirsiniz.
Problemler var: Şu anda, uygulamanın iş dağıtımının bir kısmını ve ortamın dağıtımının ve yönetiminin bir kısmını tüm sahnede görebilirsiniz, ancak gerçekten uygulamaya gittiğimizde bazı sorunlar bulundu. Birincisi, derleme ortamı ve üretim ortamının sürümünün aynı olması gerektiğidir, yani uygulama paketinin bağlı olduğu sürüm, işletim sistemi dahil aynıdır. İkincisi, oluşturma araçlarının tutarlılığının gerekli olmasıdır, yani yapı örneğin 1.9 inşa edildiğinde, geri alındığında yeniden yapılandırma için 1.9'a geri döndürülmeli ve bu bilgiler kaydedilmelidir.
Google'ın bazel yapı sistemleri hakkındaki makalesini okuduysanız, büyük hedeflerinden birinin başarmak olduğunu göreceksiniz. tutarlılık En önemli deneyim Birleştirilmiş yönetim için tüm yapı bağımlılıklarını koyun ve araçları havuza yerleştirin. Şimdi, ortamı yönetmek için Ansible'ı bu şekilde kullanın ve oluşturmak için Jenkins'i kullanın, hiçbir sorun olmayacaktır. Ancak, uygulama paketinin kaybolduğu ve bir kez yeniden inşa etmek istediğinizde çevreyi oluşturmak için Jenkins'i kullanmanın nispeten zahmetli olduğu tespit edildiğinde, tek bir tıklama ile otomatikleştirmek ve oluşturmak zordur. Nasıl yapılır? Şimdi 3.0'da bunu nasıl yaptığımızdan bahsedeceğiz.
- Test uzmanlarının oryantasyonu ve test çalışması
Testin otomasyonu, test platformu dahil olmak üzere fonksiyonel testtir. Bu durumda, test uzmanlarının konumlandırılması ve test çalışmasının yeniden düşünülmesi gerekir.
Buradaki mantık nedir? İnsanları hayatta tutmaktır.Örneğin, bazı kullanıcıların kullanılabilirlik testi insan gerektirir, ancak bu tür bir araç insanların test etmesini gerektirmez, sadece makineleri kullanın. Yani şu anda, Dev ve Ops'un tüm süreçte hayatta kaldığını göreceksiniz.
- Docker ve değişmez dağıtım
Docker'ı tanıtın ve Docker'a dayalı olarak değişmez dağıtım yapın. Docker, bir yansıtma oluştururken içeriğini açıklamaya göre bildirme ve tüm uygulamayı ve ortamını bir aynaya paketleyebilme avantajına sahiptir.Bu durumda, test aynayı doğruladıktan sonra, bunun sonraki tüm dağıtımları Değiştirmeye gerek yoktur. Değiştirilmesi gereken tek şey konfigürasyondur.Başlattığınızda bu aynaya bazı farklı konfigürasyonlar ekleyebilirsiniz, ancak dahili uygulaması genellikle değişmez. Geri alma ve geri alma çok kolaydır.
Ürün Docker üzerinde çalışabildiğinden, yapı ortamı Docker üzerinde de çalışabilir mi? Kesinlikle. Şu anda, Jenkins Docker ortamında inşa etmek için çekilecek. Bir proje oluşturulduğunda, projeye bazı meta veriler ekleyin: projenin adı, sorumlu ekip, kod tabanı ve oluşturulacak projeyi belirtin Bağımlılık nedir.
Şu anda, JDK 1.7 Docker'ı mı yoksa JDK 1.8 Docker'ı mı seçmek gibi, imajı oluşturmak için oluşturduğumuz temeli dahili olarak seçecek ve gelecekteki yapı Docker üzerinde oluşturulacak, yani Docker, derleme ortamı olarak kullanılacaktır. Bu durumda, çok basit.Geri döndüğünüzde bir Docker çekin.Yönetmesi Jenkins'in kendi yapısından çok daha kolay ve yeniden inşa sürecinin de daha basit olduğunu göreceksiniz.
- İşletme ve bakım personeli ile işletme ve bakım çalışmalarının konumlandırılması
Bu sırada, operasyon ve bakım personelini ve operasyon ve bakım çalışmalarını konumlandırmaya başladık, çünkü test cihazları bizim tarafımızdan düzenlendi ve tüm iş sürecinden çıkarıldı. İşletme ve bakım personeli de tarafımızca kaldırılacak mı? Aslında hayır, yaptığımız şey işletme ve bakım işlerini basitleştirmek ve işletme ve bakımdan sorumlu olmaması gereken şeyleri çıkarmaktı. Uygulama işletimi ve bakımı, işletme ve bakım ekibinin sorumlu olmasını gerektirmez.Sonuçta ürün, talepten koda, koddan üretime, üretimden sonra, üretimden sonra izleme ve sorun oluştuğunda tamir edilir.Bu özel uygulamalar, işletme ve bakım müdahalesi gerektirmez.Ar-Ge yapar. Kimin çalıştığını inşa edin. İşletme ve bakım neyi kontrol eder? Altyapı operasyon ve bakımından sorumlu, hatta alet geliştirmeden sorumlu, Takım geliştirme ekibini operasyon ve bakım ekibine yerleştirin.
Şu anda herkesin gördüğü şey, işletim ve bakım ile sağlanan iki aracı geliştirmek ve kullanmak olan bir yapıdır.Birincisi destek araçlarıdır.Kod yönetimi gibi entegre bir araç olmadan önce birden fazla araca sahip olabiliriz, Proje yönetimi, şube yönetimi, derleme sistemi ve son olarak dağıtım ve yayın sistemi. İşletme ve bakım personelinin yapması gereken altyapı işleri de vardır.
- Jenkins çok fazla sorumluluk alıyor
Şu anda, Jenkins çok fazla iş üstlendi. CI, derleme, ortam ve dağıtımın tümü buraya yerleştirildi, bu nedenle her takım yeni bir dağıtım hattı oluşturduğunda, tüm komut dosyalarının ince ayarını yapmalı ve yeniden yazmalıdır. Bu aslında Bu bir zaman kaybı. Yapılandırma yoluyla, bunları yeniden yazmaya, yani programatik çalışmayı yapılandırma çalışmasına dönüştürmeye gerek olmadığını umuyoruz.
Sürekli Teslimat 3.0
- Anahtar görevlerin sistematik hale getirilmesi
Öncelikle anahtarın ayrı bir sistemde çalışması ve sistematik hale getirilmesi gerekiyor; inşaat için artık Jenkins'in bir eklentisi olarak kullanamıyoruz, onu ayrı bir sistem yapmak için çıkarmamız gerekiyor. Dağıtım ayrıca, yönetilebilmesi ve bazı önemli verilerin elde edilebilmesi için Jenkins'ten ayrı yapılması gereken ayrı bir sistem gerektirir. Böylece, çevre yönetim sistemi, işletim ortamı, dağıtım hattı ve meta veri hizmetinin basit bir yapısı olan böyle bir sisteme dönüştü.
Sonra istiyoruz Programatik çalışmayı yapılandırma çalışmasına dönüştürün Çünkü programcıların çok fazla komut dosyası yazmasını istemiyoruz ve Özel sistemde biraz daha detaylı çalışmalar yapılabilir ,Bunun anlamı ne?
Aslında, bazı katmanlı testler, ortam, trafiğin nasıl yönlendirileceği, bazı kesin testler dahil olmak üzere dağıtım stratejileri gibi her bölümde yapılması gereken birçok uygulama olduğunu ve alarm tarafının aynı olduğunu görebilirsiniz. Tamamı Jenkins'e yerleştirilmişse, belirli uygulama ayrıntılarını yapmak çok zordur.
Bu durumda, yazılım geliştirme ne sağlar? Çalışan bir sistem olmalı , O halde bu sistemi oluşturma süreci Yapılandırılabilir, yeniden oluşturulabilir ve izlenebilir Ve süreci Otomasyon, hizmet ve görselleştirme Evet, tüm süreç bir bakışta görülebilir.
- Kendini geliştirme sistemi
Rapor ve kaza analizi
Kendi kendini geliştiren sistem, bu işletim ve bakıma yönelik önyargılı bir şeydir. İlk arıza raporu ve kaza analizi, sistemimizin iyi çalışıp çalışmadığıdır? İşletmenin performansı nasıl değerlendirilir? En basit olanı verilere göre yargılamaktır. Bunun bir yolu, bir sorun bulduğumuzda, Hızlı bir şekilde keşfetmek, bulmak, takip etmek ve çözmek ve analizi teşvik etmek, iyileştirmeler üretmek, bilgi biriktirmek ve yönetimi desteklemek gerekir.
Tüm yapı yukarıdaki şekilde gösterilmiştir.Akıllı hata raporlama sistemi ve kök neden analiz sistemi vardır.Kök neden analiz sistemi iki şey üretecektir.İlk tip süreç iyileştirme WIKI'deki SOP ve ardından proje geri bildirimi haline gelmiştir. JIRA'da takip, yani yinelemenin sistem aracılığıyla geliştirilmesi gerekiyor. Daha sonra sistem göstergeye (eşik) dayalı bir COE (kaza analizi) oluşturabilir - ister Seviye 3 raporlama hatası veya seviye 2 raporlama olsun Bir COE oluşturmak için, Google ve Amazon tarafından bahsedilen kaza özeti ve analizidir, ancak bazı verileri içerecektir. Analiz ve sunum.
Operasyonel hedefler ve operasyonel veriler açısından, genel SLA trendinin iyileşip iyileşmediğine bakılmaksızın geçmiş verilere ve trendlerine bakabiliriz.
Problem analizi aslında böyle bir yapıdır. SRE'ye bakarsanız, SRE'de kaza analizi için beş yapı vardır. Googledan biraz farklı ama kabaca aynı olan bir dizi Amazon yapısı kullanıyoruz. Aynısı doğrudur.
APM, günlük ve izleme
Herkes işletme ve bakım tarafına aşinadır.Ar-Ge seviyesinin düzgün olduğunu göreceksiniz.Bu zamanda sistemin çalışma durumu dikkat etmemiz gereken şeydir.Bu aslında dikey ve yataydır.Dikey iş tarafında ve yatay sistem mimarisinde. Bu kadar çok makinede önden arkaya ne yanlış gitti? Şu anda üç şeye ihtiyacınız olduğunu göreceksiniz: Birincisi geleneksel APM, ikincisi günlük analizi ve üçüncüsü tam bağlantı izleme yetenekleri gerektiriyor.
Senaryo tabanlı işletim ve bakım: noktaya konumlandırma
Panorama, temelde yukarıdaki şekilde gösterildiği gibidir. Sol tarafın araştırma ve geliştirmeye, sağ tarafın ise işletim ve bakıma kısmi olduğu görülebilir. Dahili işlem için birleşik kimlik doğrulama, güvenlik taraması ve yönetimi ve ağlar gibi birçok araç vardır. İşletme ve bakım tamamlandıktan sonra, tüm işteki birçok şeyin desteklenmesi için araçlara ihtiyacı vardır. Performans yönetimi, organizasyon personeli, posta listeleri, teknik iletişim ve proje yönetiminin hepsinin yöntemleri dikkate alması gerekir.
Özet: Devops'un özü aslında yalnızca iki şeyi dikkate alır.
İlki, işleteni ve bakımını yapanı inşa eden, Ar-Ge her şeyi yapmak zorundadır, çünkü bu sistemi kendisi kurar, bu nedenle bu sistemi çalıştırır ve sürdürür, ancak altyapıyı çalıştırmaz ve bakımını yapmaz, araçları çalıştırmaz ve bakımını yapmaz.
İkincisi liderlik Liderlik, tüm işletmenin temel değeridir. İşe alımdan eğitimden elemeye kadar, hepsi liderlik düşüncelerine dayanır. Burada birkaç liderlik becerisinden bahsediyorum. Biri sorumluluk, ikincisi icra ve üçüncüsü öğrenme yeteneği Ne tür bir kişiyi işe aldığınıza ve onların güvenilir olup olmadığına karar vermelisiniz.Kurumsal değerlerinizle son derece tutarlı ve entegre olması gerekiyor. Çok yetenekli ancak değerlerinizle aynı fikirde olmayan birini işe alırsanız, herkesin birlikte çalışması zor olacaktır.
