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
Başlatmak. Bir yönetici, küçük geliştirme departmanı. Varışta tamamen sıfırım çünkü... Mail dışında hiçbir yere erişimim yok. Yöneticiye yazıp erişim istiyoruz. Ayrıca yeni çalışanın farkında olduğu ve kullanıcı adı/şifre vermesi gerektiği bilgisi de mevcuttur. Depodan ve VPN'den erişim sağlarlar. Neden wiki'ye, Teamcity'ye ve Rundesk'e erişim izni veriyorsunuz? Arka uç kısmının tamamını yazması için çağrılan bir kişi için gereksiz şeyler. Ancak zamanla bazı araçlara erişim kazanırız. Tabii ki gelişi güvensizlikle karşılandı. Sohbetler ve yönlendirici sorular aracılığıyla projenin altyapısının nasıl çalıştığına dair yavaş yavaş fikir edinmeye çalışıyorum. Temelde hiçbir şeyi tanımıyorum. Üretim öncekiyle aynı kara kutudur. Ancak bundan da fazlası, test için kullanılan sahne sunucuları bile birer kara kutudur. Oraya Git'ten bir dal dağıtmaktan başka bir şey yapamayız. Ayrıca uygulamamızı .env dosyaları gibi yapılandıramıyoruz. Bu tür işlemlere erişim izni verilmez. Test sunucusundaki uygulamanızın yapılandırmasında bir satırın değiştirilmesi için yalvarmanız gerekir. (Yöneticilerin kendilerini projede önemli hissetmelerinin hayati önem taşıdığına dair bir teori var; eğer yapılandırmalardaki satırları değiştirmeleri istenmezse, onlara ihtiyaç kalmayacaktır). Her zamanki gibi uygun değil mi? Bu durum hızla sıkıcı olmaya başlıyor, yöneticiyle doğrudan görüştükten sonra geliştiricilerin kötü kod yazmak için doğduklarını, doğaları gereği beceriksiz bireyler olduklarını ve onları üretimden uzak tutmanın daha iyi olduğunu öğreniyoruz. Ama her ihtimale karşı burada da test sunucularından. Çatışma hızla tırmanıyor. Yöneticiyle iletişim yok. Yalnız olması durumu daha da kötüleştiriyor. Aşağıdaki tipik bir resimdir. Serbest bırakmak. Belirli işlevler çalışmıyor. Neler olup bittiğini anlamamız uzun zaman alıyor, geliştiricilerin çeşitli fikirleri sohbete atılıyor, ancak böyle bir durumda yönetici genellikle geliştiricilerin suçlu olduğunu varsayar. Sonra sohbette yazıyor, bekleyin, düzelttim. Sorunun ne olduğuna dair bilgi içeren bir hikayeyi arkamızda bırakmamız istendiğinde zehirli mazeretler alıyoruz. Mesela burnunuzu ait olmadığı yere sokmayın. Geliştiricilerin kod yazması gerekir. Bir projede birçok vücut hareketinin tek bir kişiden geçmesi ve herkesin ihtiyaç duyduğu operasyonları yalnızca onun gerçekleştirebilmesi durumu son derece üzücü. Böyle bir insan korkunç bir darboğazdır. Devops fikirleri pazara çıkış süresini kısaltmaya çalışıyorsa, 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