DevOps ve IaC konusu oldukça popüler ve hızla gelişiyor. Ancak çoğu yazar bu yolda tamamen teknik sorunlarla uğraşmaktadır. Büyük bir şirketin karakteristik sorunlarını anlatacağım. Bir çözümüm yok - genel olarak sorunlar ölümcül ve bürokrasi, denetim ve "sosyal beceriler" alanında yatıyor.
Yazının başlığı bu şekilde olduğundan Atılgan tarafına geçen Daenerys kedi rolünü üstlenecek.
Şüphesiz artık eski ile yeninin çarpışması söz konusudur. Ve çoğu zaman bu çarpışmalarda ne doğru ne de yanlış vardır. Sadece bu şekilde oldu. Ancak asılsız olmamak adına bu ekranla başlayacağız:
Buna Değişim Talebi denir. Çeşitli dizinlerden doldurulması gereken alanların yaklaşık üçte birini görüyorsunuz, geri kalan alanlar diğer yer imlerinde. Komut dosyasını üretim sunucusuna uygulamak, yeni dosyalar yüklemek veya genel olarak herhangi bir şeyi değiştirmek için böyle bir belgenin doldurulması gerekir.
Alan sayısı o kadar fazla ki bu alanları doldurmak için kendi küçük otomasyonumu yazdım. Üstelik bu sayfa, hiçbir otomasyon aracının alanlarını göremeyeceği şekilde yazılmıştır ve mümkün olan tek çözüm, fareyle koordinatlara aptalca tıklamak için AutoIt'i kullanmaktı. Bunu yapmak için çaresizlik düzeyinizi değerlendirin:
Yani, jenkins, şef, terraform, nexus vb.'yi alırsınız ve hepsini memnuniyetle geliştiricinize dağıtırsınız. Ancak bunu QA, UAT ve PROD'a göndermenin zamanı geldi. Bir Nexus eseriniz var ve DBA'dan şunun gibi bir mektup alıyorsunuz:
Sevgili,
Öncelikle kendin için sahip olabileceğin bağlantı noktası Nexus'una erişimim yok
İkinci olarak, tüm değişikliklerin Değişiklik Talebi olarak yayınlanması gerekir.
SQL komut dosyalarını Nexus'tan çıkarmanız ve bunları Değişiklik İsteğine eklemeniz gerekir.
Değişiklik Acil değilse, bu işlem yayınlanmadan 7 gün önce yapılmalıdır (münhasıran Hafta Sonu)
Değişiklik Talebiniz bir grup kişi tarafından onaylandığında, DBA betiğinizi yürütecek ve hatta sonucun ekran görüntüsünü postayla gönderecektir.Saygılarımızla, ana bilgisayar günlerinden beri burada çalışan DBA'nız.
Bu bana neyi hatırlatıyor biliyor musun? Yarı otomasyon: Robot çerçeveyi tutar ve işçi ona balyozla vurur. Peki, gerçekten, eğer her şey tamamen manuel olarak yapılıyorsa, bu Nexus'un anlamı nedir?
Ancak bunun için Enterprise suçlanmamalı! Elbette kanlı ama Değişiklik Talepli tüm bu bürokrasi zorlamadır ve denetçilerden kaynaklanmaktadır. İşletmenin bu şekilde çalışması gerekiyor, nokta. Bunu başka türlü yapamaz. Ve denetim çok muhafazakar bir şeydir. Örneğin uzun, sözde karmaşık ve sık değiştirilen şifrelerin kötü olduğu ne kadar çok söylendi ama bunun değiştirileceği son yer işletmeler olacak. Ayrıca dağıtımlar ve diğer her şeyle birlikte.
Bu arada, bir keresinde terraform için bir dosya oluşturmaya çalıştım ama işe yaramadı. Hiçbir zaman öğrenemediğim 'Proje Muhasebesi Faturalama Kodu' etiketinin anlamını buldum; yeterince sosyal becerim yoktu.
Pasif Luddizm konusunu ele almıyorum bile - ah, otomasyonunuz iş güvenliğimi tehdit ediyor, yeni bir şey öğrenmek istemiyorum, bu yüzden onu sessizce sabote edeceğim.
Peki prensipte çözüm ne olabilir? ITSM sistemi, belgeleri otomatik olarak oluşturmak için son derece ilkel bir API'ye sahiptir. Ve genel olarak bu sistemlerin çoğu ana bilgisayarların zamanından geliyor. Gerçekten modern ITSM sistemlerini bilen var mı? Modern DevOps ile bürokrasiyi entegre etme konusunda başarılı deneyimi olan var mı? Tabii ki, aslında her gün bir dağıtımın olabileceği salt satış sitelerinden değil, örneğin denetçilerin kontrolü altında olan ve daha yüksek ortamlarda çok güçlü izolasyona sahip olan bankacılık sektöründen bahsediyoruz.
Ancak tüm fantezilerinizin denetimle sınırlı olduğunu unutmayın. Ve bu her şeyi değiştirir. Yorumlara bekliyorum!
Kaynak: habr.com