"Devops'un nasıl uygulanacağı" sorusu yıllardır tartışılıyor ancak pek fazla iyi materyal yok. Bazen ne olursa olsun zamanlarını satmak isteyen pek akıllı olmayan danışmanların reklamlarının kurbanı olursunuz. Bazen bunlar, mega şirketlerin gemilerinin evrenin genişliğini nasıl sürdüğüne dair belirsiz, son derece genel sözlerdir. Şu soru ortaya çıkıyor: Bunun bizim için ne önemi var? Sevgili yazar, fikirlerinizi bir liste halinde açıkça formüle edebilir misiniz?
Bütün bunlar, şirket kültüründeki dönüşümlerin sonuçlarına ilişkin pek fazla gerçek uygulamanın ve anlayışın birikmemiş olmasından kaynaklanmaktadır. Kültürdeki değişiklikler uzun vadeli şeylerdir ve sonuçları bir hafta veya bir ayda ortaya çıkmaz. Şirketlerin yıllar içinde nasıl kurulduğunu ve başarısızlığa uğradığını görecek kadar yaşlı birine ihtiyacımız var.
John Willis - DevOps'un babalarından biri. John'un çok sayıda şirketle çalışma konusunda onlarca yıllık deneyimi var. Son zamanlarda John, her biriyle çalışırken ortaya çıkan belirli kalıpları fark etmeye başladı. John, bu örnekleri kullanarak şirketlere DevOps dönüşümünün gerçek yolunda rehberlik ediyor. Bu arketipler hakkında daha fazlasını DevOops 2018 konferansındaki raporunun çevirisinden okuyabilirsiniz.
Konuşmacı hakkında:
BT yönetiminde 35 yılı aşkın süredir, Canonical'da OpenCloud'un öncülünün oluşturulmasına katıldı, ikisi Dell ve Docker'a satılan 10 startup'ta yer aldı. Halen SJ Technologies'de DevOps ve Dijital Uygulamalardan Sorumlu Başkan Yardımcısıdır.
Sırada John'un bakış açısından hikaye var.
Adım John Willis ve beni bulmanın en kolay yeri Twitter'dır. . Gmail ve GitHub'da aynı takma adı kullanıyorum. A Raporlarımın ve sunumlarımın video kayıtlarını bulabilirsiniz.
Çeşitli büyük şirketlerin CIO'larıyla birçok toplantım var. DevOps'un ne olduğunu anlamadıklarından sıklıkla şikayet ediyorlar ve onlara bunu açıklamaya çalışan herkes farklı bir şeyden bahsediyor. Bir diğer yaygın şikayet ise DevOps'un çalışmamasıdır, ancak yöneticilerin her şeyi kendilerine anlatıldığı gibi yaptığı görülüyor. Yüz yılı aşkın geçmişi olan büyük şirketlerden bahsediyoruz. Onlarla konuştuktan sonra, birçok soruna en uygun olanın yüksek teknoloji değil, nispeten düşük teknolojili çözümler olduğu sonucuna vardım. Haftalarca farklı departmanlardan insanlarla konuştum. Gönderideki ilk resimde gördüğünüz son projem, üç günlük çalışmanın ardından oda bu hale geldi.
DevOps nedir?
Nitekim 10 farklı kişiye sorarsanız 10 farklı cevap verirler. Ancak işin ilginç tarafı şu: Bu cevapların on tanesinin tamamı doğru olacak. Burada yanlış cevap yok. Yaklaşık 10 yıldır DevOps'un oldukça derinlerindeydim ve ilk DevOpsDay'e katılan ilk Amerikalıydım. DevOps'a dahil olan herkesten daha akıllı olduğumu söylemeyeceğim, ancak bu konuda bu kadar çaba harcayan neredeyse hiç kimse yok. DevOps'un insan sermayesi ile teknolojinin bir araya gelmesiyle ortaya çıktığına inanıyorum. Her türlü kültürden çokça bahsetsek de çoğu zaman insan boyutunu unutuyoruz.
Artık elimizde çok fazla veri var; beş yıllık akademik araştırma, teorilerin endüstriyel ölçekte test edilmesi. Bu çalışmaların bize söylediği şey, bir organizasyon kültüründeki bazı davranış kalıplarını birleştirirseniz 2000 kat hızlanma elde edebileceğinizdir. Bu hızlanma, kararlılıktaki eşit bir iyileşmeyle eşleşiyor. Bu, DevOps'un herhangi bir şirkete sağlayabileceği faydanın niceliksel bir ölçümüdür. Birkaç yıl önce bir Fortune 5000 şirketinin CEO'suna DevOps hakkında konuşuyordum, sunuma hazırlanırken çok gergindim çünkü yılların deneyimini 5 dakikada özetlemem gerekiyordu.
Sonunda şunu verdim DevOps'un tanımı: İnsan sermayesinin yüksek performanslı organizasyonel sermayeye dönüşmesini sağlayan bir dizi uygulama ve kalıptır. Bunun bir örneği Toyota'nın son 50 veya 60 yıldır çalışma şeklidir.
(Bundan sonra bu tür diyagramlar referans olarak değil, illüstrasyon olarak verilmiştir. İçerikleri her yeni şirket için farklılık gösterecektir. Ancak resim ayrı ayrı görüntülenebilir ve büyütülebilir.)
Bu tür uygulamaların en başarılılarından biri değer akışı haritalama. Bu konuda birçok güzel kitap yazıldı ve bunların en başarılısı Karen Martin'e ait. Ancak geçen yıl bu yaklaşımın bile fazla ileri teknoloji olduğu sonucuna vardım. Kesinlikle birçok avantajı var ve ben bunu çok kullandım. Ancak CEO size şirketinin neden yeni raylara geçemediğini sorduğunda değer akışı haritalaması hakkında konuşmak için henüz çok erken. Öncelikle cevaplanması gereken çok daha temel sorular var.
Bence meslektaşlarımın çoğunun yaptığı hata, şirkete beş maddelik bir rehber verip altı ay sonra geri gelip ne olduğunu görmeleriydi. Değer akışı haritalaması gibi iyi bir planın bile kör noktaları olduğunu varsayalım. Çeşitli şirketlerin yöneticileriyle yaptığım yüzlerce görüşmeden sonra sorunu bileşenlerine ayırmamıza olanak tanıyan belirli bir model geliştirdim ve şimdi bu bileşenlerin her birini sırayla tartışacağız. Herhangi bir teknolojik çözümü uygulamadan önce bu modeli kullanıyorum ve sonuç olarak tüm duvarlarım diyagramlarla kaplanıyor. Son zamanlarda bir yatırım fonuyla çalışıyordum ve bu tür 100-150 planla karşılaştım.
Kötü kültür kahvaltıda iyi yaklaşımları yer
Ana fikir şudur: Kuruluşun kültürünün kendisi kötüyse Yalın, Çevik, SAFE ve DevOps'un hiçbir miktarı yardımcı olmaz. Bu, tüplü dalış ekipmanı olmadan derinlere dalmak veya röntgen olmadan çalışmaya benzer. Başka bir deyişle, Drucker ve Deming'in sözlerini aktaracak olursak: Kötü bir organizasyon kültürü, her türlü iyi sistemi boğmadan yutacaktır.
Bu ana sorunu çözmek için aşağıdaki adımları uygulamanız gerekir:
- Tüm Çalışmaları Görünür Hale Getirin: tüm çalışmayı görünür hale getirmeniz gerekiyor. Mutlaka bir ekranda görüntülenmesi gerektiği anlamında değil, gözlemlenebilir olması gerektiği anlamında.
- Konsolide İş Yönetim Sistemleri: yönetim sistemlerinin konsolide edilmesi gerekmektedir. “Kabile” bilgisi ve kurumsal bilgi sorununda, 9 vakadan 10'unda darboğaz insanlardır. Kitapta Sorun, projenin programın üç yıl gerisinde kalmasına neden olan tek bir kişi olan Brent'teydi. Ve her yerde bu "Brent'lerle" karşılaşıyorum. Bu darboğazları çözmek için listemizdeki sonraki iki öğeyi kullanıyorum.
- Kısıtlamalar Teorisi Metodolojisi: kısıtlar teorisi.
- İşbirliği hileleri: işbirliği hileleri.
- Toyota Kata'sı (): Toyota Kata hakkında fazla konuşmayacağım. İlgilenirseniz github'ımda bu konuların neredeyse her birinde.
- Pazar Odaklı Organizasyon: Pazar odaklı organizasyon.
- Sol kaydırmalı denetçiler: Döngünün erken aşamalarında denetim.
Bir organizasyonda çalışmaya çok basit bir şekilde başlıyorum: Şirkete gidiyorum ve çalışanlarla konuşuyorum. Gördüğünüz gibi yüksek teknoloji yok. Tek ihtiyacınız olan üzerine yazacak bir şey. Birkaç ekibi bir odada toplayıp bana söylediklerini 7 arketip perspektifinden analiz ediyorum. Daha sonra onlara bir kalem veriyorum ve şu ana kadar yüksek sesle söyledikleri her şeyi tahtaya yazmalarını istiyorum. Genellikle bu tür toplantılarda her şeyi yazan bir kişi vardır ve o da tartışmanın en iyi ihtimalle %10'unu yazabilir. Benim yöntemim ile bu rakam yaklaşık %40'a kadar çıkarılabilir.
(Bu çizim ayrı olarak görüntülenebilir )
Benim yaklaşımım William Schneider'in çalışmasına dayanıyor. ). Yaklaşım, herhangi bir organizasyonun dört kareye bölünebileceği fikrine dayanmaktadır. Benim için bu şema genellikle bir organizasyonu analiz ederken ortaya çıkan yüzlerce başka şemayla çalışmanın sonucudur. Diyelim ki yüksek düzeyde kontrole sahip ancak düşük yetkinliğe sahip bir organizasyonumuz var. Bu son derece istenmeyen bir seçenektir: Herkes çizgiyi takip ederken kimse ne yapacağını bilemediğinde.
Biraz daha iyi bir seçenek, hem kontrol hem de yeterliliğin yüksek düzeyde olduğu seçenektir. Eğer böyle bir şirket kârlıysa DevOps'a ihtiyacı olmayabilir. Yüksek düzeyde kontrole, düşük yetkinliğe ve işbirliğine sahip, ancak aynı zamanda yüksek düzeyde kültüre (yetiştirme) sahip bir şirketle çalışmak çok ilginçtir. Bu, şirkette çalışmaktan hoşlanan çok sayıda insanın olduğu ve iş gücü devir hızının düşük olduğu anlamına gelir.
(Bu çizim ayrı olarak görüntülenebilir )
Bana öyle geliyor ki, katı kuralları olan yöntemler, gerçeğe ulaşmanın yolunu tıkıyor. Özellikle değer akışı haritalamasında bilginin nasıl yapılandırılması gerektiğine ilişkin birçok kural vardır. Şu anda bahsettiğim işin ilk aşamalarında kimsenin bu kurallara ihtiyacı yok. Elinde kalem olan bir kişi, şirketteki gerçek durumu yönetim kurulunda anlatırsa, bu, durumu anlamanın en iyi yoludur. Bu tür bilgiler yöneticilere ulaşmaz. Şu anda kişinin sözünü kesip bir tür oku yanlış çizdiğini söylemek aptalca. Bu aşamada basit kuralları kullanmak daha iyidir, örneğin: çok seviyeli soyutlama, çok renkli işaretleyiciler kullanılarak kolayca oluşturulabilir.
Tekrar ediyorum, yüksek teknoloji yok. Siyah kalem, her şeyin nasıl çalıştığının nesnel gerçekliğini tasvir ediyor. İnsanlar mevcut durumla ilgili hoşlanmadıkları şeyleri kırmızı bir kalemle işaretlerler. Bunu benim değil onların yazması önemli. Bir toplantıdan sonra CIO'ya gittiğimde düzeltilmesi gereken 10 şeyin listesini sunmuyorum. Şirketteki insanların söyledikleriyle mevcut kanıtlanmış kalıplar arasında bağlantılar bulmaya çalışıyorum. Son olarak mavi bir işaret soruna olası çözümler önerir.
(Bu çizim ayrı olarak görüntülenebilir )
Bu yaklaşımın bir örneği yukarıda gösterilmektedir. Bu yılın başında bir bankayla çalıştım. Oradaki güvenlik görevlileri tasarım ve gereksinim incelemelerine gelmemeleri gerektiğine ikna olmuşlardı.
(Bu çizim ayrı olarak görüntülenebilir )
Daha sonra diğer departmanlardan insanlarla konuştuk ve ortaya çıktı ki yaklaşık 8 yıl önce yazılım geliştiricileri işleri yavaşlattıkları için güvenlik çalışanlarını kovdular. Daha sonra bu, doğal karşılanan bir yasağa dönüştü. Gerçekte yasak olmamasına rağmen.
Toplantımız son derece kafa karıştırıcı bir şekilde ilerledi: Yaklaşık üç saat boyunca beş farklı ekip bana kod ile montaj arasında neler olduğunu açıklayamadı. Ve bu en basit şey gibi görünüyor. Çoğu DevOps danışmanı, herkesin bunu zaten bildiğini varsayar.
Daha sonra dört saat boyunca sessiz kalan BT yönetiminden sorumlu kişi, konusuna geldiğimizde birden canlandı ve bizi uzun süre meşgul etti. Sonunda kendisine toplantı hakkında ne düşündüğünü sordum ve cevabını asla unutmayacağım. Şöyle dedi: "Bankamızın yazılım sağlamanın yalnızca iki yolu olduğunu düşünürdüm, ancak şimdi bunların beşi olduğunu biliyorum ve üçünü bile bilmiyordum."
(Bu çizim ayrı olarak görüntülenebilir )
Bu bankadaki son toplantı yatırım yazılımı ekibiyle yapıldı. Bir kağıda kalemle diyagram yazmanın tahtadan ve hatta akıllı tahtadan daha iyi olduğu onunla birlikte ortaya çıktı.
Gördüğünüz fotoğraflar, toplantımızın dördüncü gününde otelin konferans salonunun nasıl göründüğünü gösteriyor. Ve bu şemaları kalıpları, yani arketipleri aramak için kullandık.
Bu yüzden işçilere sorular soruyorum, onlar da cevapları üç renkli (siyah, kırmızı ve mavi) kalemlerle yazıyorlar. Arketiplere yönelik cevaplarını analiz ediyorum. Şimdi tüm arketipleri sırasıyla tartışalım.
1. Tüm Çalışmaları Görünür Hale Getirin: Çalışmaları görünür kılın
Çalıştığım çoğu şirkette çok yüksek oranda bilinmeyen iş var. Örneğin bu, bir çalışanın diğerine gelip sadece bir şey yapmasını istemesidir. Büyük organizasyonlarda %60 oranında plansız işler olabiliyor. Ve işin %40'a kadarı hiçbir şekilde belgelenmiyor. Eğer Boeing olsaydı hayatımda bir daha asla onların uçağına binmezdim. Eğer işin sadece yarısı belgelenmişse bu işin doğru yapılıp yapılmadığı bilinemez. Diğer tüm yöntemlerin işe yaramaz olduğu ortaya çıkıyor - herhangi bir şeyi otomatikleştirmeye çalışmanın bir anlamı yok, çünkü bilinen% 50, otomasyonu harika sonuçlar vermeyecek ve en kötüsü işin en tutarlı ve net kısmı olabilir. işler görünmez yarıdadır. Belgelerin yokluğunda, her türlü hack'i ve gizli işi bulmak, darboğazları, daha önce bahsettiğim "Brent'leri" bulmamak imkansızdır. Dominica DeGrandis'in harika bir kitabı var . O ortaya koyuyor beş farklı "zaman sızıntısı" (zaman hırsızları):
- Devam Eden Çok Fazla Çalışma (WIP)
- Bilinmeyen Bağımlılıklar
- Plansız Çalışma
- Çakışan öncelikler
- İhmal Edilen İş
Bu çok değerli bir analiz ve kitap harika, ancak verilerin yalnızca %50'si görünürse tüm bu tavsiyeler işe yaramaz. %90'ın üzerinde bir doğruluk elde edilmesi durumunda Dominika'nın önerdiği yöntemler kullanılabilir. Bir patronun astına 15 dakikalık bir görev verdiği, ancak bunun üç gün sürdüğü durumlardan bahsediyorum; ancak patron, bu astın dört veya beş kişiye daha bağımlı olduğunu gerçekten bilmiyor.
Phoenix Projesi, üç yıl geç kalmış bir projeyle ilgili harika bir hikaye. Karakterlerden biri bu yüzden işten çıkarılma tehlikesiyle karşı karşıya kalır ve bir nevi Sokrates olarak sunulan başka bir karakterle tanışır. Tam olarak neyin yanlış gittiğini anlamaya yardımcı oluyor. Şirketin Brent adında bir sistem yöneticisi olduğu ve tüm işlerin bir şekilde onun üzerinden yürüdüğü ortaya çıktı. Toplantılardan birinde astlardan birine şu soru soruldu: Neden her yarım saatlik görev bir hafta sürüyor? Cevap, kuyruk teorisinin ve Little yasasının çok basitleştirilmiş bir sunumudur ve bu sunumda %90 doluluk durumunda her saatlik çalışma 9 saat sürmektedir. Her görevin diğer yedi kişiye gönderilmesi gerekiyor, böylece saat 63 saat, 7 çarpı 9 olur. Söylediğim şu ki, Little Yasasını veya herhangi bir karmaşık kuyruk teorisini kullanmak için en azından veriye sahip olmanız gerekir.
Yani görünürlükten bahsettiğimde, her şeyin ekranda olduğunu değil, en azından verilere sahip olduğunuzu kastediyorum. Bunu yaptıklarında, genellikle çok büyük miktarda planlanmamış işin, hiç ihtiyaç olmadığı halde bir şekilde Brent'e gönderildiği ortaya çıkıyor. Ve Brent harika bir adam, asla hayır demez ama işini nasıl yaptığını kimseye anlatmaz.
Çalışma görünür olduğunda veriler düzgün bir şekilde sınıflandırılabilir (Dominique'in fotoğrafta yaptığı da budur), beş zaman sızıntısının soyutlaması uygulanabilir ve otomasyon uygulanabilir.
2. İş Yönetim Sistemlerini Birleştirin: Görev Yönetimi
Bahsettiğim arketipler bir tür piramittir. Birincisi doğru yapılırsa ikincisi zaten bir nevi eklentidir. Bunların çoğu yeni kurulan şirketler için işe yaramıyor, Fortune 5000 gibi daha büyük şirketler için akılda tutulması gerekiyor. Son çalıştığım şirketin 10 biletleme sistemi vardı. Bir takımın Remedy'si vardı, bir diğeri kendi sistemini yazdı, üçüncüsü Jira'yı kullandı ve bazıları da e-postayla yetindi. Şirketin 30 farklı boru hattı varsa da aynı sorun ortaya çıkıyor, ancak bu tür durumların hepsini tartışacak zamanım yok.
İnsanlarla biletlerin tam olarak nasıl oluşturulduğunu, onlara daha sonra ne olacağını ve nasıl atlatıldıklarını tartışıyorum. En ilginci toplantılarımızdaki insanların oldukça samimi konuşmaları. Aslında "büyük etki" verilmesi gereken biletlere kaç kişinin "küçük / etkisi yok" ifadesini koyduğunu sordum. Neredeyse herkesin bunu yaptığı ortaya çıktı. İhbarda bulunmuyorum ve mümkün olan her şekilde insanları tanımlamamaya çalışıyorum. Bana içtenlikle bir şey itiraf ettiklerinde o kişiyi ele vermiyorum. Ancak neredeyse herkes sistemi atladığında, bu, tüm güvenliğin aslında vitrin süslemesinden ibaret olduğu anlamına gelir. Bu nedenle bu sistemin verilerinden herhangi bir sonuç çıkarılamaz.
Bilet problemini çözmek için bir ana sistem seçmeniz gerekiyor. Jira kullanıyorsanız Jira'yı koruyun. Alternatif varsa tek olsun. Sonuç olarak, biletlerin geliştirme sürecinde başka bir adım olarak görülmesi gerektiğidir. Her eylemin, geliştirme iş akışı boyunca akması gereken bir bileti olması gerekir. Biletler ekibe gönderilir, ekip onları storyboard'a koyar ve ardından sorumluluk alır.
Bu, altyapı ve operasyonlar da dahil olmak üzere tüm departmanlar için geçerlidir. Bu durumda, durum hakkında en azından makul bir fikir oluşturmak mümkündür. Bu süreç oluşturulduktan sonra, her başvurudan kimin sorumlu olduğunu belirlemek birdenbire kolaylaşır. Çünkü artık yeni hizmetlerin %50'sini değil %98'ini alıyoruz. Bu temel süreç işe yararsa sistem genelinde doğruluk artar.
Hizmetler hattı
Bu yine sadece büyük şirketler için geçerlidir. Yeni bir alanda yeni bir şirketseniz kolları sıvayın ve Travis CI veya CircleCI ile çalışın. Fortune 5000 şirketlerine gelince, bunun bir örneği çalıştığım bankada yaşandı. Google onlara geldi ve onlara eski IBM sistemlerinin şemaları gösterildi. Google'daki adamlar şaşkınlıkla sordular; bunun kaynak kodu nerede? Ancak kaynak kodu yok, GUI bile yok. Büyük kuruluşların uğraşmak zorunda olduğu gerçek budur: Eski bir ana bilgisayardaki 40 yıllık banka kayıtları. Müşterilerimden biri KeyBank uygulaması için Circuit Breaker modellerine ek olarak Chaos Monkey içeren Kubernetes konteynerlerini kullanıyor. Ancak bu konteynerler sonuçta bir COBOL uygulamasına bağlanır.
Google'daki adamlar müşterimin tüm sorunlarını çözeceklerinden tamamen emindiler ve sonra şu soruları sormaya başladılar: IBM datapipe nedir? Onlara bunun bir bağlayıcı olduğu söylendi. Neye bağlanıyor? Sperry sistemine. Peki bu nedir? Ve benzeri. İlk bakışta şöyle görünüyor: Ne tür DevOps olabilir? Ama aslında bu mümkün. İş akışını teslimat ekiplerine devretmenize olanak tanıyan dağıtım sistemleri vardır.
3. Kısıtlamalar Teorisi: Kısıtlamalar Teorisi
Üçüncü arketipe geçelim: kurumsal/"kabilesel" bilgi. Kural olarak, herhangi bir organizasyonda her şeyi bilen ve her şeyi yöneten birkaç kişi vardır. Bunlar organizasyonda en uzun süre kalan ve tüm geçici çözümleri bilen kişilerdir.
Diyagramda bu ortaya çıktığında, bu tür insanları özellikle bir işaretleyiciyle daire içine alıyorum: örneğin, belirli bir Lou'nun tüm toplantılarda mevcut olduğu ortaya çıkıyor. Ve benim için açık: bu yerel Brent. CIO ben tişörtlü ve spor ayakkabılı adamla IBM'den takım elbiseli adam arasında seçim yaptığında ben seçilirim çünkü yönetmene diğer adamın söylemeyeceği ve yönetmenin duymaktan hoşlanmayabileceği şeyler söyleyebilirim . Onlara şirketlerindeki darboğazın Fred adında biri ve Lou adında biri olduğunu söylüyorum. Bu darboğazın çözülmesi gerekiyor, öyle ya da böyle onlardan bilgi alınması gerekiyor.
Bu tür bir sorunu çözmek için örneğin Slack'i kullanmanızı önerebilirim. Akıllı bir yönetmen şunu soracaktır: neden? Tipik olarak bu gibi durumlarda DevOps danışmanları şu yanıtı verir: çünkü bunu herkes yapıyor. Yönetmen gerçekten akıllıysa şöyle diyecek: ne olmuş yani. Ve diyalog burada bitiyor. Buna cevabım şu: çünkü şirkette dört darboğaz var; Fred, Lou, Susie ve Jane. Bilgilerini kurumsallaştırmak için öncelikle Slack'i tanıtmak gerekiyor. Tüm wiki'leriniz tamamen saçmalık çünkü kimse onların varlığından haberdar değil. Mühendislik ekibi ön uç ve arka uç geliştirmede yer alıyorsa ve herkesin soruları için ön uç geliştirme ekibi veya altyapı ekibiyle iletişime geçebileceğini bilmesi gerekir. İşte o zaman Lou veya Fred'in muhtemelen wiki'ye katılmak için zamanı olacak. Ve sonra Slack'te birisi örneğin 5. adımın neden işe yaramadığını sorabilir ve ardından Lou veya Fred wiki'deki talimatları düzeltir. Bu süreci kurarsanız pek çok şey kendiliğinden yerine oturacaktır.
Benim asıl söylemek istediğim şu: Herhangi bir yüksek teknolojiyi tavsiye etmek için öncelikle onların temelini düzene koymalısınız ve bu, az önce anlatılan düşük teknolojili çözümlerle yapılabilir. Yüksek teknolojilerle başlarsanız ve bunlara neden ihtiyaç duyulduğunu açıklamazsanız, kural olarak bunun sonu iyi olmaz. Müşterilerimizden biri çok ucuz ve basit bir çözüm olan Azure ML'yi kullanıyor. Sorularının yaklaşık %30'u kendi kendine öğrenen makinenin kendisi tarafından yanıtlandı. Ve bu şey veri bilimi, istatistik veya matematikle ilgisi olmayan operatörler tarafından yazılmıştı. Bu çok önemli. Böyle bir çözümün maliyeti minimumdur.
4. İşbirliği tüyoları: İşbirliği tüyoları
Dördüncü arketip izolasyonla mücadele etme ihtiyacıdır. Çoğu insan bunu zaten biliyor: Tecrit, düşmanlığı besler. Her bölüm kendi katındaysa ve insanlar asansör dışında hiçbir şekilde birbirleriyle kesişmiyorsa aralarında düşmanlık çok kolay ortaya çıkar. Ama tam tersine insanlar birbirleriyle aynı odadaysa hemen ayrılır. Birisi genel bir suçlama ortaya attığında, örneğin falan filan arayüz asla çalışmıyorsa, böyle bir suçlamayı yapısöküme uğratmaktan daha kolay bir şey yoktur. Arayüzü yazan programcıların yalnızca belirli sorular sormaya başlaması gerekir ve örneğin kullanıcının aracı yanlış kullandığı kısa sürede anlaşılacaktır.
İzolasyonun üstesinden gelmenin birçok yolu vardır. Bir keresinde benden Avustralya'da bir bankaya danışmanlık yapmam istenmişti ama iki çocuğum ve bir karım olduğu için bunu yapmayı reddettim. Onlara yardım etmek için yapabileceğim tek şey grafiksel hikaye anlatımı önermekti. Bu işe yaradığı kanıtlanmış bir şey. Bir başka ilginç yol ise yağsız kahve toplantılarıdır. Büyük bir kuruluşta bu, bilginin yayılması için mükemmel bir seçenektir. Ayrıca dahili devopsday'ler, hackathon'lar vb. düzenleyebilirsiniz.
5. Kata Koçluğu
En başta da uyardığım gibi bugün bu konuyu konuşmayacağım. İlginizi çekerse göz atabilirsiniz .
Bu konuyla ilgili Mike Rother'ın da güzel bir konuşması var:
6. Pazar Odaklı: Pazar odaklı organizasyon
Burada farklı sorunlar var. Örneğin, "Ben" insanları, "T" insanları ve "E" insanları. “Ben” insanlar tek bir şey yapanlardır. Tipik olarak izole departmanlara sahip organizasyonlarda bulunurlar. "T", bir kişinin bir konuda iyi olmasının yanı sıra başka bazı konularda da iyi olması anlamına gelir. "E" ve hatta "tarak", bir kişinin birçok beceriye sahip olduğu zamandır.
Conway yasası burada çalışır (), en basitleştirilmiş haliyle şu şekilde ifade edilebilir: derleyici üzerinde üç ekip çalışırsa, sonuç üç bölümden oluşan bir derleyici olacaktır. Dolayısıyla bir kuruluş içinde izolasyon yüksek düzeydeyse, bu kuruluştaki Kubernetes, Devre kesici, API genişletilebilirliği ve diğer süslü şeyler bile kuruluşun kendisiyle aynı şekilde düzenlenecektir. Kesinlikle Conway'e göre ve siz genç ineklere kızmak için.
Bu sorunun çözümü defalarca anlatıldı. Örneğin Fernando Fernandez'in tanımladığı organizasyonel arketipler var. Az önce bahsettiğim sorunlu mimari izolasyonla birlikte işlev odaklı bir mimaridir. İkinci tip ise en kötüsüdür, matris mimarisi, diğer ikisinin karışımıdır. Üçüncüsü çoğu startupta görülen bir durum ve büyük şirketler de bu tipe uymaya çalışıyor. Pazar odaklı bir organizasyondur. Burada müşteri taleplerine en hızlı yanıtı elde etmek için optimizasyon yapıyoruz. Buna bazen düz organizasyon denir.
Birçok kişi bu yapıyı farklı şekillerde tanımlıyor, ifadeleri beğendim ekipleri oluştur/yönetAmazon'da buna diyorlar iki pizza takımı. Bu yapıda tüm “I” tipi insanlar tek bir hizmet etrafında toplanıyor ve giderek “T” tipine yaklaşıyorlar, hatta doğru yönetim sağlanırsa “E” tipine bile dönüşebiliyorlar. Buradaki ilk karşı argüman, böyle bir yapının gereksiz unsurlara sahip olmasıdır. Özel bir test uzmanı departmanınız varsa neden her departmanda bir test uzmanına ihtiyacınız var? Buna cevap veriyorum: Bu durumda ekstra maliyetler, tüm organizasyonun gelecekte “E” tipi haline gelmesinin bedelidir. Bu yapıda, testçi yavaş yavaş ağlar, mimari, tasarım vb. hakkında bilgi edinir. Sonuç olarak organizasyona katılan her katılımcı, organizasyonda olup biten her şeyin tamamen farkındadır. Bu planın endüstride nasıl çalıştığını bilmek istiyorsanız, okuyun .
7. Sol vardiya denetçileri: döngünün başında denetim yapın. Ekrandaki güvenlik kurallarına uygunluk
Bu, tabiri caizse, eylemlerinizin koku testini geçemediği zamandır. Sizin için çalışan insanlar aptal değil. Yukarıdaki örnekte olduğu gibi her yerde az etki yaratıyorsa/hiç etki yapmıyorsa, bu üç yıl sürdüyse ve kimse bir şey fark etmediyse, sistemin çalışmadığını herkes çok iyi biliyor demektir. Veya başka bir örnek; raporların her çarşamba günü sunulması gereken bir değişim danışma kurulu. Orada çalışan (bu arada çok iyi maaş almıyorlar) teorik olarak sistemin bir bütün olarak nasıl çalıştığını bilmesi gereken bir grup insan var. Ve son beş yılda muhtemelen sistemlerimizin inanılmaz derecede karmaşık olduğunu fark etmişsinizdir. Ve XNUMX-XNUMX kişi yapmadıkları ve hakkında hiçbir şey bilmedikleri bir değişiklik hakkında karar vermek zorunda kalıyorlar.
Elbette bu yaklaşım işe yaramıyor. Bu tür şeylerden kurtulmam gerekiyor çünkü bu insanlar sistemi korumuyor. Karar ekibin kendisi tarafından verilmelidir çünkü ekip bundan sorumlu olmalıdır. Aksi takdirde hayatında hiç kod yazmamış bir yöneticinin programcıya kod yazmasının ne kadar sürmesi gerektiğini söylemesi paradoksal bir durum ortaya çıkar. Çalıştığım bir şirketin mimari kurulu, ürün kurulu vb. dahil olmak üzere her değişikliği gözden geçiren 7 farklı kurulu vardı. Zorunlu bir bekleme süresi bile vardı, ancak bir çalışan bana on yıllık çalışmam boyunca bu kişinin bu zorunlu süre boyunca yaptığı bir değişikliği hiç kimsenin reddetmediğini söyledi.
Denetçilerin bize katılmaya davet edilmesi gerekiyor, onlardan kurtulmaları değil. Onlara, eğer tüm testleri geçerlerse sonsuza kadar değişmez kalacak, değişmez ikili kaplar yazdığınızı söyleyin. Onlara kod olarak bir boru hattınız olduğunu söyleyin ve bunun ne anlama geldiğini açıklayın. Onlara şu şemayı gösterin: tüm güvenlik açığı testlerini geçen bir kaptaki değişmez, salt okunur bir ikili dosya; ve o zaman kimse ona dokunmamakla kalmıyor, aynı zamanda dinamik olarak oluşturulduğu için boru hattını oluşturan sisteme bile dokunmuyorlar. Vault'u blockchain gibi bir şey oluşturmak için kullanan Capital One adında müşterilerim var. Denetçinin Chef'in "tariflerini" göstermesine gerek yoktur; üretim sırasında Jira biletine ne olduğunun ve bundan kimin sorumlu olduğunun açık olduğu blockchain'i göstermesi yeterlidir.
Göre 2018 yılında Sonatype tarafından oluşturulan OSS indirme talebi 2017 yılında 87 milyar oldu.
Güvenlik açıklarından kaynaklanan kayıplar caydırıcıdır. Üstelik yukarıda gördüğünüz rakamlara fırsat maliyetleri dahil değil. Kısaca DevSecOps nedir? Hemen belirteyim ki bu ismin ne kadar başarılı olduğundan bahsetmek istemiyorum. Önemli olan şu ki, DevOps bu kadar başarılı olduğundan bu boru hattına güvenlik eklemeye çalışmalıyız.
Bu diziye bir örnek:
Her ne kadar hepsini beğensem de bu belirli ürünler için bir öneri değil. Başlangıçta endüstrideki organizasyonel paradigmayı temel alan DevOps'un, bir ürün üzerindeki çalışmanın her aşamasını otomatikleştirmenize olanak sağladığını göstermek için bunları örnek olarak gösterdim.
Güvenlik konusunda da aynı yaklaşımı benimsemememiz için hiçbir neden yok.
sonuç
Sonuç olarak DevSecOps için bazı ipuçları vereceğim. Denetçileri sistemlerinizi oluşturma sürecine dahil etmeniz ve onları eğitmek için zaman ayırmanız gerekir. Denetçiler ile işbirliği yapmalısınız. Daha sonra, yanlış pozitiflere karşı kesinlikle acımasız bir mücadele vermeniz gerekiyor. En pahalı güvenlik açığı tarama aracını bile kullanarak, sinyal-gürültü oranınızın ne olduğunu bilmiyorsanız, geliştiricileriniz arasında son derece kötü alışkanlıklar yaratabilirsiniz. Geliştiriciler olaylardan bunalacak ve bunları kolayca silecekler. Equifax'ın hikayesini duymuşsanız, en yüksek uyarı seviyesinin göz ardı edildiği yerde yaşananların hemen hemen aynısı olduğunu görürsünüz. Ayrıca güvenlik açıklarının işi nasıl etkilediğini açıkça ortaya koyacak şekilde açıklanması gerekir. Örneğin bunun Equifax hikayesindeki güvenlik açığının aynısı olduğunu söyleyebilirsiniz. Güvenlik açıkları diğer yazılım sorunlarıyla aynı şekilde ele alınmalı, yani genel DevOps sürecine dahil edilmelidir. Onlarla Jira, Kanban vb. aracılığıyla çalışmanız gerekir. Geliştiriciler bunu başkasının yapacağını düşünmemeli, aksine bunu herkes yapmalıdır. Son olarak, insanları eğitmek için enerji harcamanız gerekiyor.
Faydalı linkler
DevOops konferansında faydalı bulabileceğiniz birkaç konuşma:
- Sergey Berdnikov, Artyom Kalichkin - Başarı öyküsü veya “Dev+DevOps+Ops” (, )
- Baruch Sadogursky, Leonid Igolnik - DevOps ölçeğinde: Üç perdede bir Yunan trajedisi (, )
- Alexander Titov, Kirill Tolkachev -
- Timothy Lister-
içine bak DevOops 2020 Moskova - orada da pek çok ilginç şey var.
Kaynak: habr.com