Ekibimdeki geliştiricileri “Siz inşa edin, koşun” u benimsemeye nasıl ikna edebilirim?

Ekibimdeki geliştiricileri "İnşa et, yönet" diyene nasıl ikna edebilirim? Bununla aklıma gelen Werner Vogels'tan şu alıntıyı aldım :

Geliştiricilere operasyonel sorumluluklar vermek, hem müşteriden hem de teknoloji açısından hizmetlerin kalitesini büyük ölçüde artırmıştır. Geleneksel model, yazılımınızı geliştirme ve işlemleri ayıran duvara götürmeniz, üstünüze atmanız ve sonra unutmanızdır. Amazon'da değil. Sen inşa et, sen işlet. Bu, geliştiricilerin yazılımlarının günlük kullanımıyla temasa geçmelerini sağlar. Ayrıca, müşteriyle günlük iletişim içinde olmalarını sağlar. Bu müşteri geri bildirim döngüsü, hizmetin kalitesini artırmak için esastır.

Özellikle şunu yapan bir dizi geliştiriciyi düşünüyorum:

• OP ile ilgili görevlerden çok az / hiç söz etmeden geliştirici rolüne alınmıştı.
• Geleneksel olarak bir ops ekibine "duvarın üstüne kod atılmış".
• Geleneksel olarak 9-5 çalışma zaman çizelgesine sahiptir ve felaket kurtarma çalışmalarına katılan, özellikle normal çalışma saatleri dışında , postportem sonrası yazma vb . (Not: Bunun için yalnızca çok az kesinti olduğunu düşünüyorum; bu ekibin iş yüküne mesai sonrası müşteri desteği eklememizi önermiyorum.)
• Şu anda uygulamalarını izlemekten veya uyarmadan yazmaktan / desteklemekten sorumlu değiliz.

Diyelim ki, bu hizmetleri bir ops ekibine vermeyecek bir profille hızlı bir şekilde yeni bulut mikro hizmetleri geliştiren bir ekip olduğunu varsayalım. Etkin bir şekilde yönetmek ve izlemek için gereken hizmetler. "Oluşturursun, koşarsın" bu takım için daha iyi çalışır, çünkü görevler her sorumlu ekip üyesine devredilebilirdi. Bu yüzden bu ekip altyapı tasarlamada, hizmetler için izleme araçlarında / uyarı araçlarında ve (nadiren) kesinti olaylarına yanıt vermeye başlayacaktır.

Özellikle gerçek dünya örnekleri ile desteklenen metodolojilerle ilgileniyorum. Bunun diğer işyerlerinde nasıl başarıyla uygulandığı ve bunu uygularken izlenmesi gereken kanonik adımlar varsa? Cevapları destekleyebilecek yazılara bağlantılar çok yardımcı olacaktır.

Bence en kolay yol, performans hedeflerini değiştirmek, böylece kodlamanın yanı sıra güvenilirlikten de kaynaklanmak olduğunu düşünüyorum. Şirket her ikisine de sahip olamadan başarılı olamayacağından ötürü satmak, bu nedenle geliştiriciler neden yalnızca birinde ölçülmeli? Onlara göre performans hedeflerine ulaşmanın en iyi yolu operasyonlara katılmaktır.

Nihayetinde onları ikna etmeniz gerekir, bu da şirketin başarılı olması ve dolayısıyla başarılı olmaları için en iyi yoldur. Bu zor ve baştan itibaren onların gemide olmasını bekleyemezsiniz. Değerinde de satılmaları gerekiyor.

İş kültürünü etkilemeye gelince, en iyi yol muhtemelen bilinen "kurbağayı kaynat" yöntemidir. Bu görevleri geliştiricilere yavaşça tanıtmak zorundasınız, çünkü kendimin (bir dev olarak) tüm bu yeni sorumluluğa aynı anda varacağımı biliyorum.

İlk önce, yalnızca normal mesai saatleri içerisinde gerçekleştirilecek bir veya iki yeni görev getirerek başlayın. Sadece (sadece bu noktada) kod yazacak bir öğrenme süreci olan ve bazı denetimler gerektirebilecek olan saptamayı nasıl yapacaklarını öğrenmeleri gerekir. Ayrıca 9-5 yaşlarına alıştıklarını söylediğiniz için iş-yaşam dengesini değiştirme fikrine düşmanca davranacaklar. Bu noktada, daha sonra kullanılmak üzere yeni işlemler hakkındaki verileri kaydedin (bu kodu yazmalarını sağlayın, veriler her zaman yararlıdır).

Daha sonra tanıtmak için yeni devops-y görevlerini bitirdikten sonra (ilk, ikinci ve dördüncü kurşun noktaları neredeyse tamamlandı), aday olarak başlattığınız ilk görevleri standart çalışma saatleri dışında gerçekleştirin . Bu konuda biraz tepki görebilirsiniz ve hatta bunu ne kadar güçlü bir şekilde bastırdığınıza ve beşinci çalışmadaki çalışma kültürünün ne kadar yoğunlaştığına bağlı olarak bir miktar yıpranma bile görebilirsiniz. Buna karşı savunmak için, verilerinizin standart saatlerin ötesinde çalışmanın nadir olacağını, yalnızca aşırı durumlarda ortaya çıkacağını ve hem işletmeye hem de müşteriye büyük yarar sağlayacağı fikrini desteklediğini umarım. Verileriniz bunu desteklemiyorsa, bu seçimin sonuçlarıyla ilgilenmeye hazır olsanız iyi olur.

Hatta verilerle, hala geliştiricilerin kod uyarı / izleme bilgileri (bunlar haline var daha kolay olabilir dev ops ama yine ağırlıklı dev) ve cephe desteği gibi alternatif operasyonları ekibinizi tutmak (birkaç diğerleri gibi ileri sürmüşlerdir). Dediğim gibi, küçük değişiklikler geri tepmeyi önlemek için önemlidir. Devs için çalışmayı standart saatlerin ötesine entegre etmek zor olacaktır, çünkü devs piyasası şu anda, özellikle zaten yetkin yeteneklere sahiplerse güçlü olduğu için, eğer beğenmezlerse başka bir yerde iş arayabilirler. Uyarıcı emptor!

Özellikle DevOps'un dışına bakmak, büyük (ish) kurumsal ortamlardan söz ediyorsanız , SAFe metodolojisinin bu tür davranışları teşvik etmenin oldukça iyi bir yolu vardır.

Temelde birkaç önemli aşamaya kadar kaynar:

• projeler serbest bırakma trenleri olarak başlar. Niyeti (ve kimin finanse edeceği beklentisi) uzun sürecek olmasıdır. Yıllar boyu konuşuyorum, hiçbiri "3 ay boyunca bir takımı ayağa kaldır, sonra onları yere indir" meselesi.

• Bir proje boyunca, serbest bırakma treni kaçınılmaz olarak, yeni gerçekleşen iş fırsatlarına ve devam eden bakım tarzı çalışma vergisine dayanan yeni proje gerekliliklerinin çoğundan daha fazla insanı toplayacaktır.

• Neredeyse her zaman trenlerin ilk artışını% 100 proje / değişim ekibi olarak çalıştırdığını, 2. artışının ise Çalışma çalışmasına ayrılan süreyi yüzde ayırdığını görüyorum. 3. artış yönetimi, bir sorun yaşamaya başlayacaklarının farkına vardıklarını ve şu an deneyimli olan geliştiricilere ve mühendislere yeni gereksinimler üzerinde çalışmaya devam etmeleri için zaman aşımını denemek ve idare etmek için ekipler eklemeye başlamanın farkındalar.

• Eğer doğru denge, proje ekiplerinin bakım çalışmalarında sıkıntıya düşmeden proje sonuçlarını sunmaya devam edebilmesi ve trene katılan yeni ekiplerin hemen% 100 destek ekibi olması beklenmez, bunun yerine İşe yarayacak olan değişim çalışmasının adil kısmı, daha sonra varsayılan olarak inşa ettikleri ürünlere sahip olan teslimat ekiplerine sahip olursunuz, bir anda hepsinin bir Koşma ekibi olduğu, hepsine gelmesi gerekmez. bunun yerine, yavaş yavaş günlük aktivitelerine entegre olur.

Bu modelin belli ki bazı zayıf yanlarının olduğu bir iş için fiyatlandırmada. Genel olarak, bir değişim kaynağına, işletme kaynağından çok daha fazla ödeme yapmayı umuyorum, genellikle büyük satıcılarla yapılan sözleşmeler sabit fiyat ve amaç, sürekli iyileştirme ve dolayısıyla maliyet tasarrufları için para kazanmaları.

Söylendiğine göre, değişim ekiplerinin bir serbest bırakma treninin parçası olarak ayağa kalkarak sürekli iyileştirmeler yapmak olduğunu düşünmek o kadar da zor değil. Yeni proje teslimatlarına odaklanma yeteneklerini geliştirebilecekleri ve yapabilecekleri veya yapabilecekleri bir şey varsa ve "her zamanki iş" işiyle daha az ilgileniyorlarsa, o zaman parasını elinde tutan kişi tarafından algılanan faydalara dayanarak geri alınmalı ve önceliklendirilmelidir. treni serbest bırak.

IMHO You build it, you run ittam anlamıyla alınmamalıdır. Başlamak için - neredeyse bir ceza gibi geliyor;)

Hiçbir kişi, hatta küçük geliştirici ekibi , yazılım geliştirme sürecinde (yani üretimde!) Uzun süre boyunca kullanılan bir aleti veya araç setini makul bir şekilde destekleyemez. Orada bulundum :)

Destek görevleri, araç (set) müşteri tabanı büyüdükçe genişleme eğilimindedir. Yalnızca bu görevleri üstlenirse, geliştirme ekibi daha çok destek vererek sonuçlanabilir; Etkili bir çıkmaz - kaç tane geliştirici bu tür çevrede kalmayı tercih ederdi?

Profesyonel bir ilk destek ekibine sahip olmak, geliştirici ekip üyeleriniz üzerindeki görevlerinizi desteklemek için hayal kırıklığı, stres ve uzun süreli maruz kalmanın diğer etkilerini önlemek için çok önemlidir.

Birinci basamak destek ekibi, elbette, doğrudan karşılayamayacakları sorunlar için geliştirici ekibine geri döner (yine, tek kişilik değil ekip!). Evet, ilk başta zor olabilir, ama her şey daha iyi olacak. Bir işbirliği olmalı - bu DevOps'un ne anlama geldiğinin bir parçası.

Bu sonuçta şirketin büyüklüğüne ve yapısına bağlıdır. Şirketinizin içinde olabileceği üç aşama var:

1. Başlangıç ​​aşaması (150 mühendisin altında). Elbette, geliştiricilerin kendi yazılımlarını çalıştırmaları gerekir. Bunu herkes başlangıçta yapar. Başlamak için operasyon ekibiniz bile olmayabilir, ancak başlasanız bile, küçüktür ve ilerleme hızı o kadar hızlıdır ki, başarılı bir şekilde çalıştırmak için gereken bilgiyi başarılı bir şekilde başka bir takımda çalıştırmak için yeterli yolu yoktur. başarılı ol.

2. Orta ölçekli işletme (150'den fazla mühendis, ancak tek bir operasyon ekibi). Bu aşamada şirkette karmaşa çok yüksek olmaya başlıyor, yazılım üreten mühendisler aynı zamanda onu çalıştırmak için mutlaka uğraşmıyorlar. Artık herkesi tanımıyorsunuz ve herkesin operasyona girmesi için etkili bir şekilde iletişim kurmak zor. Kaosa dönüşmeye başlardı. Bu aşamada, her ekibin yazılımlarını çalıştırması gereken, ancak mutlaka çalıştırması gerekmeyen Google modeline geçmek istiyorsunuz. Başlangıçta kullanacaklar, ancak bina yazılımının büyük bir kısmı, işletim maliyetini, operasyon ekibinin çalıştırırken imzalayabileceği kadar küçük olan bir noktaya düşürmek. Ancak o zaman yapılan kabul edilir.

3. Birden fazla işletme birimine sahip büyük şirketler (her birinin kendi operasyon ekibine sahip olduğu): Bu aşamada, her ekibin temel hizmetlerinin kendi hizmetlerini geliştirip işlettiği Amazon modeline geri dönebilirsiniz. İş birimlerinin her birinin herkesin birbirini tanıması için yeterince küçük olması gerekir, bu nedenle yaklaşık 150 mühendisin altında ve her birini temelde bir başlangıç ​​olarak işletirsiniz. Amazon her AWS servisine daha fazla veya daha az ayrı olarak çalışıyor ve onlar için çalışıyor.

Şirketinizin hangi aşamada olduğunu ve / veya hangi aşamaya girdiğini ve buna göre hareket ettiğini bulmak zorundasınız. "Herkese uyan tek beden" çözümü yok.

Bunu benim almam (böyle bir emirle karşı karşıya kalsaydım, ya da ne diyecekseniz), " What else would you expect?!?!" gibi bir şey olurdu . Çünkü, kazayla:

• Onsuz yaşayamam bile, ve
• Kendi köpek yemeğimi yemeyi seviyorum.

Biraz daha açıklayayım ...

İşim / hobim / tutkum , daha özel anabilgisayar ortamlarında scm . Ve nereye gidersem gideyim (müşterilerin ihtiyaçlarını karşılayacak şeyler ince ayar yapmak için), benim uyguladığım ilk şart (sözleşmeme göre), uyguladığımız sisteme yapılan herhangi bir ayarın aynı sistem üzerinden yapılmasıdır. Ve bunu yaparak (doğru, bu birkaç saat sürer, en fazla yarım gün diyelim), şu avantajlardan yararlanırız (eksik liste):

• Sistemi çalıştırmak için yaptığım hiçbir şeyi belgelemiyorum. Herhangi bir soru sorulursa, sadece sistemi sorgularım (ve müşteriye yardımım olmadan sistemi nasıl sorgulayacağını öğretirim).
• Eğer X ay / yıl içinde çağrılırsam (yeni bir sürüme yükseltmek için?), Daha önce ne yaptığımı bilmek istiyorum (ve hatırladım) (ve güvendiğim tek şey sistemin bana söylediklerini, yani bana hatırlatıyor).
• Müşteriye yalnızca sitelerinde belirli şeylerin nasıl yapılacağını (adlandırma kurallarının hatırlanması zor olan) hakkında bir kez sormam veya onları "sistem" e (bana değil ...) gerekli izinleri vermeye ikna etmem gerekiyor.
• Sen continuouslykendi QA testini yapıyorsun ... üretimde. Muhtemelen kendiniz hatalar, mantıksal hatalar veya eksik özellikler (ve ne olmayan) ile karşılaşacaksınız. Ve bunlar, en kısa sürede ele alınmaları için motive edici ... örneğin daha üretken olmak için.
• ... ve istersen bir sürü sebep daha ekleyebilirim ...

Ancak, bunu evde yapmadan önce, kaçınmak için bazı tehlikelerin farkında olun:

• herkesin partiye katılmasını istiyorsunuz (sistemi kullanın), çünkü sadece 1 "istisna" (yani şirketin yöneticisi / sahibi?) partiyi mahvedebilir (sisteminize güvenebileceğinizi düşünebilirsiniz, ancak birileri bir şeyler yaptı. sormadan / sistemi kullanmadan). Bu dava keşfetmek için günlere mal olabilir ...
• yeni kullanıcılar, bu (yeni) sistemi kullanarak, işlerini yapmaları için daha uzun zaman harcadıklarından şikayet edebilir (daha önce kullandıklarına göre). Mantıklı olduğu her yerde, bunu işlerini tamamlamak için neden geç kaldıklarının bir bahanesi olarak kullanacaklar. Bu noktada, sizi kapsayan üst yönetim daha iyi olsa da, aksi takdirde projeniz / sisteminiz suçlanabilir.
• kendi sisteminizi bildiğinizden ve kendi gereksinimlerinize göre nasıl yapılandıracağınızdan emin olun. Örnek olarak (benim durumumda): sistemi, çalışma ortamını deneysel ortamınıza ulaştırmak için operasyonel ortamı kullanacak şekilde yapılandırmak istiyorsunuz, bunun tersini yapmıştınız ... Geçmişte olduğunu gördüm ... Yüksek güvenlikli ortamlara teslim etmek için test sisteminin kullanılması (kötüye kullanılması).