Tesadüfler rastgeledir ve gerçekten de başka bir gezegendeydi...
Bir arka uç geliştiricinin yöneticilerle bir ekipte nasıl çalıştığına dair üç başarı ve başarısızlık öyküsünü paylaşmak istiyorum.
İlk hikaye.
Web stüdyosunda çalışan sayısı tek elle sayılabilir. Bugün bir düzen tasarımcısısınız, yarın bir destekçisiniz, yarından sonraki gün bir yöneticisiniz. Bir yandan muazzam bir deneyim kazanabilirsiniz. Öte yandan her alanda yeterlilik eksikliği var. İşe girdiğim ilk günü hâlâ hatırlıyorum, hâlâ yeşilim, patron diyor ki: “Macun açık” ama ne olduğunu bilmiyorum. Yöneticilerle iletişim hariçtir, çünkü siz kendiniz bir yöneticisiniz. Bu durumun artılarını ve eksilerini ele alalım.
+ Tüm güç senin elinde.
+ Sunucuya erişim için kimseye yalvarmanıza gerek yoktur.
+ Her yöne hızlı reaksiyon süresi.
+ Becerileri iyi geliştirir.
+ Ürün mimarisini tam olarak anlayın.
- Büyük sorumluluk.
— Üretimin kesintiye uğrama riski.
— Her alanda iyi bir uzman olmak zordur.
İlgilenmiyorum, devam edelim
İkinci hikaye.
Büyük şirket, büyük proje. 5-7 çalışanı olan bir yönetim departmanı ve çeşitli geliştirme grupları bulunmaktadır. Böyle bir şirkete çalışmaya geldiğinizde her yönetici buraya bir ürün üzerinde çalışmaya değil, bir şeyleri kırmaya geldiğinizi düşünüyor. Ne imzalanan gizlilik sözleşmesi ne de görüşmedeki seçim aksini göstermemektedir. Hayır, bu adam buraya kirli küçük elleriyle öpüşme sahnemizi mahvetmek için geldi. Bu nedenle böyle bir kişiyle minimum düzeyde iletişime ihtiyacınız var, en azından yanıt olarak bir çıkartma atabilirsiniz. Proje mimarisi ile ilgili soruları yanıtlamayın. Ekip lideri sorana kadar erişim izni verilmemesi tavsiye edilir. Ve sorduğunda, istediklerinden daha az ayrıcalıkla onu geri verecektir. Bu tür yöneticilerle olan neredeyse tüm iletişim, geliştirme departmanı ile yönetim departmanı arasındaki kara delik tarafından emilmektedir. Sorunları anında çözmek mümkün değil. Ancak şahsen gelemezsiniz; yöneticiler 24/7 çok meşgul. (Her zaman ne yapıyorsunuz?) Bazı performans özellikleri:
- Üretime kadar ortalama dağıtım süresi 4-5 saattir
- Üretimde maksimum dağıtım süresi 9 saat
- Bir geliştirici için üretimdeki bir uygulama, tıpkı üretim sunucusunun kendisi gibi bir kara kutudur. Toplamda kaç tane var?
- Düşük kaliteli yayınlar, sık hatalar
- Geliştirici sürüm sürecine katılmıyor
Peki ne bekliyordum ki tabii ki yeni insanların üretime girmesine izin verilmiyor. Tamam, sabır kazandıktan sonra başkalarının güvenini kazanmaya başlarız. Ancak bazı nedenlerden dolayı yöneticiler için işler o kadar basit değil.
Eylem 1. Yönetici görünmez.
Yayın günü, geliştirici ve yönetici iletişim kurmuyor. Yöneticinin hiçbir sorusu yok. Ama nedenini daha sonra anlıyorsunuz. Yönetici ilkeli bir kişidir, mesajlaşma uygulaması yoktur, telefon numarasını kimseye vermez ve sosyal ağlarda profili yoktur. Hiçbir yerde fotoğrafı bile yok, neye benziyorsun dostum? Sorumlu yöneticiyle yaklaşık 15 dakika şaşkınlık içinde oturup bu Voyager 1 ile iletişim kurmaya çalışıyoruz, ardından kurumsal e-postada işi bitirdiğine dair bir mesaj beliriyor. Postayla mı yazışacağız? Neden? Uygun, değil mi? Tamam, hadi sakinleşelim. Süreç zaten devam ediyor, geri dönüş yok. Mesajı tekrar okuyun. "Bitirdim". Neyi bitirdin? Nerede? Seni nerede aramalıyım? Burada salıverilme için 4 saatin neden normal olduğunu anlıyorsunuz. Bir gelişme şoku yaşıyoruz ama sürümü bitiriyoruz. Artık salıverme arzusu yok.
2. Perde. Bu versiyon değil.
Bir sonraki sürüm. Deneyim kazandıktan sonra, yöneticiler için sunucu için gerekli yazılım ve kitaplıkların listelerini, bazılarının sürümlerini belirterek oluşturmaya başlıyoruz. Her zaman olduğu gibi, yöneticinin orada bir işi bitirdiğine dair zayıf bir radyo sinyali alıyoruz. Yaklaşık bir saat süren regresyon testi başlar. Her şey çalışıyor gibi görünüyor ancak kritik bir hata var. Önemli işlevsellik çalışmıyor. Sonraki birkaç saat, teflerle dans etmek, kahve telvesi üzerinde fal bakmak ve her bir kod parçasının ayrıntılı olarak incelenmesiyle geçti. Yönetici her şeyi yaptığını söylüyor. Sahtekar geliştiricilerin yazdığı uygulama çalışmıyor ama sunucu çalışıyor. Ona sorunuz var mı? Bir saatin sonunda yöneticinin üretim sunucusundaki kitaplığın sürümünü sohbete ve bingoya göndermesini sağlıyoruz - ihtiyacımız olan bu değil. Yöneticiden gerekli sürümü kurmasını istiyoruz, ancak yanıt olarak işletim sistemi paket yöneticisinde bu sürümün bulunmaması nedeniyle bunu yapamayacağını alıyoruz. Yönetici burada, hafızasının derinliklerinden, başka bir yöneticinin bu sorunu zaten gerekli sürümü elle birleştirerek çözdüğünü hatırlıyor. Ama hayır, bizimki bunu yapmayacak. Yönetmelik yasaklıyor. Karl, birkaç saattir burada oturuyoruz, süre sınırı nedir?! Bir şok daha yaşıyoruz ve bir şekilde tahliyeyi tamamlıyoruz.
Perde 3, kısa
Acil bilet, temel işlevler üretimdeki kullanıcılardan biri için çalışmıyor. Birkaç saatimizi araştırıp kontrol ederek geçiriyoruz. Bir geliştirme ortamında her şey çalışır. Php-fpm günlüklerine bakmanın iyi bir fikir olacağı konusunda net bir anlayış var. O dönemde projede ELK ya da Prometheus gibi log sistemleri yoktu. Sunucudaki php-fpm loglarına erişim vermeleri için yönetim departmanına bir bilet açıyoruz. Burada şunu anlamalısınız ki erişim iznini bir sebeple istiyoruz, kara deliğin ve yöneticilerin 24/7 meşgul olduğunu hatırlamıyor musunuz? Günlüklere kendilerinin bakmalarını isterseniz bu, “bu hayatta değil” önceliği olan bir görevdir. Bilet oluşturuldu, yönetim departmanı başkanından anında yanıt aldık: "Üretim günlüklerine erişmenize gerek yok, hatasız yazın." Perde.
4. Perde ve sonrası
Kitaplıkların farklı sürümleri, yapılandırılmamış yazılımlar, hazırlıksız sunucu yüklemeleri ve diğer sorunlar nedeniyle üretimde hala onlarca sorun biriktiriyoruz. Elbette kod hataları da var, tüm günahlar için yöneticileri suçlamayacağız, sadece o proje için tipik bir operasyondan daha bahsedeceğiz. Süpervizör aracılığıyla başlatılan çok sayıda arka plan çalışanımız vardı ve bazı komut dosyalarının cron'a eklenmesi gerekiyordu. Bazen aynı işçiler çalışmayı bıraktı. Kuyruk sunucusundaki yük ışık hızında arttı ve üzgün kullanıcılar dönen yükleyiciye baktı. Bu tür çalışanları hızlı bir şekilde düzeltmek için onları yeniden başlatmak yeterliydi, ancak yine de bunu yalnızca bir yönetici yapabilirdi. Bu kadar basit bir operasyon yapılırken bütün bir gün geçebilirdi. Burada elbette çarpık programcıların çökmemeleri için işçi yazmaları gerektiğini belirtmekte fayda var, ancak düştüklerinde, üretime erişim eksikliği nedeniyle bazen imkansız olan neden düştüğünü anlamak güzel olurdu. elbette ve bunun sonucunda geliştiriciden gelen günlüklerin eksikliği.
Başkalaşım.
Bütün bunlara uzun süre katlandıktan sonra ekiple birlikte bizim için daha başarılı olan bir yöne doğru ilerlemeye başladık. Özetlemek gerekirse ne gibi sorunlarla karşılaştık?
- Geliştiriciler ve yönetim departmanı arasında kaliteli iletişim eksikliği
- Görünüşe göre yöneticiler(!), uygulamanın nasıl yapılandırıldığını, hangi bağımlılıklara sahip olduğunu ve nasıl çalıştığını hiç anlamıyorlar.
- Geliştiriciler üretim ortamının nasıl çalıştığını anlamıyorlar ve sonuç olarak sorunlara etkili bir şekilde yanıt veremiyorlar.
- Dağıtım süreci çok uzun sürüyor.
- Kararsız sürümler.
Ne yaptık?
Her sürüm için, bir sonraki sürümün çalışması için sunucuda yapılması gereken işlerin listesini içeren bir Sürüm Notları listesi oluşturuldu. Listede yönetici, sürümden sorumlu kişi ve geliştirici tarafından yapılması gereken çalışmalar içeren birkaç bölüm yer alıyordu. Geliştiriciler, tüm üretim sunucularına root dışı erişim elde etti; bu, genel olarak geliştirmeyi ve özel olarak problem çözmeyi hızlandırdı. Geliştiriciler ayrıca üretimin nasıl çalıştığı, hangi hizmetlere bölündüğü, kopyaların nerede ve ne kadara mal olduğu konusunda da bilgi sahibidir. Bazı savaş yükleri daha net hale geldi ve bu da şüphesiz kodun kalitesini etkiliyor. Yayınlanma sürecinde iletişim, anlık mesajlaşma programlarından birinin sohbetinde gerçekleşti. Birincisi, tüm eylemlerin kaydı vardı ve ikincisi iletişim daha yakın bir ortamda gerçekleşti. Eylem geçmişine sahip olmak, yeni çalışanların sorunları daha hızlı çözmesine birçok kez olanak tanıdı. Bu bir paradoks, ancak bu genellikle yöneticilerin kendilerine yardımcı oldu. Kesin olarak söylemeyi taahhüt etmeyeceğim ama bana öyle geliyor ki yöneticiler projenin nasıl çalıştığını ve nasıl yazıldığını daha iyi anlamaya başladı. Hatta bazen bazı detayları birbirimizle paylaştık. Ortalama yayınlanma süresi bir saate düşürüldü. Bazen 30-40 dakikada işimiz bitiyordu. Hataların sayısı on kat olmasa da önemli ölçüde azaldı. Elbette, otomatik testler gibi başka faktörler de yayın süresinin kısaltılmasını etkiledi. Her sürümden sonra retrospektif çalışmalar yapmaya başladık. Böylece tüm ekip nelerin yeni olduğu, nelerin değiştiği ve nelerin kaldırıldığı konusunda fikir sahibi olur. Ne yazık ki adminler her zaman onlara gelmiyordu, yani adminler meşgul... Bir geliştirici olarak iş tatminim şüphesiz arttı. Yetkinlik alanınızdaki hemen hemen her sorunu hızlı bir şekilde çözebildiğinizde kendinizi zirvede hissedersiniz. Daha sonra devops kültürünü bir dereceye kadar tanıttığımızı, tamamen olmasa da, dönüşümün başlangıcının bile etkileyici olduğunu anlayacağım.
Üçüncü hikaye
Bir startup. Bir yönetici, küçük bir geliştirme ekibi. İlk katıldığımda, e-postam dışında hiçbir şeye erişimim olmadığı için tamamen sıfırdım. Yöneticiye erişim izni istemek için yazdık. O da yeni çalışandan ve giriş bilgileri ile şifre verme ihtiyacından haberdardı. Bana depoya erişim izni verdiler ve vpnWiki, TeamCity ve RunDesk'e neden erişim izni veriliyor? Tüm arka uç yazılımını yazmak için işe alınan biri için işe yaramaz. Ancak zamanla bazı araçlara erişim kazanıyoruz. Doğal olarak, gelişim güvensizlikle karşılanıyor. Sohbetler ve yönlendirici sorular aracılığıyla projenin altyapısını yavaş yavaş anlamaya çalışıyorum. Çoğunlukla hiçbir şey öğrenmiyorum. Üretim ortamı her zamanki gibi kara kutu gibi. Ama test için kullanılan aşama sunucuları bile burada kara kutu. Git'ten dalları dağıtmaktan başka bir şey yapamıyoruz. Ayrıca .env dosyaları gibi uygulamamızı yapılandıramıyoruz. Bu tür işlemler için erişime izin verilmiyor. Test sunucusunda uygulamanızın yapılandırma dosyasında bir satırın değiştirilmesi için yalvarmanız gerekiyor. (Yöneticilerin projedeki en önemli kişiler gibi hissetmeleri gerektiğine dair bir teori var; eğer yapılandırma satırlarını değiştirmeleri istenmezse, onlara ihtiyaç duyulmayacak.) Her zaman olduğu gibi, ne kadar da uygun, değil mi? Bu durum hızla sıkıcı hale geliyor. Yöneticiyle doğrudan bir görüşmenin ardından, geliştiricilerin kötü kod yazmaya doğuştan yatkın olduklarını, doğaları gereği yetersiz olduklarını ve üretim ortamından uzak tutulmalarının en iyisi olduğunu keşfediyoruz. Bir de test ortamı meselesi var. sunucular Her ihtimale karşı. Çatışma hızla tırmanıyor. Yöneticiyle iletişim yok. Durum, yalnız olması gerçeğiyle daha da kötüleşiyor. Sonra tipik senaryo geliyor. Yayın. Belirli bir özellik çalışmıyor. Geliştiriciler sohbete çeşitli fikirler atarak ne olup bittiğini anlamaya çalışarak uzun zaman geçiriyoruz, ancak yönetici genellikle geliştiricilerin suçlu olduğunu varsayıyor. Sonra sohbete "Bekleyin, düzelttim" diye yazıyor. Sorun hakkında bilgi içeren bir geçmiş kaydı bırakmak istediğimizde, zehirli bahanelerle karşılaşıyoruz. "Burnunuzu ait olmadığı yere sokmayın" diyorlar. Geliştiriciler kod yazmalı. Birçok proje sürecinin tek bir kişiden geçtiği ve sadece o kişinin herkesin ihtiyaç duyduğu işlemleri gerçekleştirme yetkisine sahip olduğu bir durum son derece üzücü. Böyle bir kişi korkunç bir darboğazdır. Eğer DevOps fikirleri pazara sunma süresini azaltmayı hedefliyorsa, bu tür insanlar DevOps fikirlerinin en büyük düşmanıdır. Ne yazık ki, perde burada kapanıyor.
Not: İnsanlarla yaptığımız sohbetlerde geliştiriciler ve yöneticiler hakkında biraz konuştuktan sonra acımı paylaşan insanlarla tanıştım. Ama hiç böyle bir şeyle karşılaşmadığını söyleyenler de vardı. Bir devops konferansında Anton Isanin'e (Alfa Bank) yöneticilerdeki darboğaz sorununu nasıl çözdüklerini sordum ve o şöyle dedi: "Onları düğmelerle değiştirdik." Bu arada onun katılımıyla. Düşmanlardan çok daha iyi yöneticilerin olduğuna inanmak isterim. Ve evet, başlangıçtaki resim gerçek bir yazışmadır.
Kaynak: www.habr.com
