Dijital dönüşüm yalnızca bir hız meselesi midir? Dönüşümün genellikle yazılımın, özelliklerin ve hizmetlerin daha hızlı dağıtımına geçişle ilişkilendirildiği göz önüne alındığında, böyle düşünmek kolaydır.
Teoriye göre, bunları ne kadar erken üretime geçirirseniz o kadar erken değer sunmaya başlayabilirsiniz. Ve bundan şu sonuç çıkıyor ki, dağıtımın önündeki engelleri ne kadar çabuk kaldırırsanız, geliştiriciler ve tasarımcılar sihirlerini o kadar çabuk örmeye, yeni işleri hızlandırmaya veya eski, hantal organizasyonları yeniden canlandırmaya başlayabilirler.
Sürekli veya en azından hızlı dağıtıma yönelik bu yönelim, genellikle buluta veya en azından büyük miktarda otomasyona sahip bulut benzeri bir mimariye geçişle birlikte desteklenir. Operasyonlarda insanların yapabileceği en iyi şeyin basitçe yoldan çekilmek olduğu görünebilir.
Ancak, HashiCorp CEO’su Dave McJannet’in tedarikçinin Eylül ayındaki HashiConf etkinliğinde belirttiği gibi, bu çok gidilen bir yol gibi görünse de, çok az kişi bu yolun sonuna ulaştı. Bulutun modernleşmeyi tetikleyebileceğini söylüyor, ancak bazı insanlar bunu gerçekten iyi yaparken çoğu yapmıyor, bazıları ise bunu çok kötü yapıyor.
Gazetecilere ve analistlere, “Yedi veya sekiz yıl boyunca öğrendiklerimiz, insanların bunu nasıl başarılı bir şekilde yaptığının inanılmaz derecede tutarlı olduğudur” dedi. “İnsanlar, süreçler ve araçlar üçlüsünü pek sevmiyorum ama görünen o ki, olması gereken de bu.” Bir veya iki unsuru değiştirmek yeterli değildir. Üçünün de dikkate alınması gerekiyor.
Söylemeye gerek yok, McJannet, başarı tarifinin bir parçası olarak, ideal olarak Terraform araçları biçiminde, kod olarak altyapı etrafında standardizasyonu savunuyor. Ancak şunu söyledi: “Her şeyin işe yaraması için gereken ikinci şey… belirli bir organizasyon yapısına ihtiyacınız var.”
McJannet’e göre bunu kavrayamamak, geleneksel ticari dünyada bulutun benimsenmesinin neden bu kadar yavaş olduğunu açıklıyor: “Dünyanın tüm dijital yerlileri… çok fazla bulut kullanıyor. Ama yüzde kaçı [companies like] Wells Fargo bulutta mı? Goldman Sachs’ın yüzde kaçı bulutta? Hemen hemen hiçbir şey.”
Buluta geçişi “operasyonel hale getirebilmek”, kuruluşların yolculuklarında genellikle görülen – genellikle açık kaynakla desteklenen – herkes için ücretsiz yaklaşımdan, bir bulut ürünü veya platform mühendisliği türü yaklaşıma geçiş anlamına gelir. “Bulut dağıtımını başarıyla gerçekleştiren her iş grubu bu şekilde organize edilmiştir” dedi.
Bu, sonuçta neyin ne kadar hızlı konuşlandırılacağını belirleyen üçüncü unsur olan sürecin yolunu açar. McJannet’in söylediği gibi, dönüşümü yönlendirenler güvenlik ve ağ ekiplerinin bir değişikliğe imza atmadan önce ihtiyaç duyduğu şeyler gibi aynı kısıtlamalarla karşı karşıya olduklarını fark ettikleri için dağıtımlar uzayabilir. Bu politikalar çok mantıklı olabilir, ancak bunların yarı manuel, bilet tabanlı sistemler aracılığıyla uygulanması hızlı dağıtımlar sağlamaz.
Altyapının sağlanmasından önce karşılanması gereken 29 politika varsa cevap, bunları her bir şey sağlandığında çalıştırılan kodlanmış kurallara dönüştürmektir. McJannet, “Belki mimari imzalamayı kodlanmış bir kural olarak yapamam, ancak belki de bu 29 kuraldan 25’ini gerçekten kodlayabilirim” dedi.
Doğru operasyonel süreçlere sahip olmak (geleneksel veya kod olarak ileri düzeyde otomatikleştirilmiş), daha hızlı teslimatla sonuçlanan başarılı bir dönüşüme ulaşmak için hala kritik öneme sahiptir.
Dönüşümün tek amacı hızlı dağıtım mıdır?
Siber güvenlik savunucusu ve yazar Glen Wilson, hedef konusunda net olmanın önemli olduğunu söylüyor. Giderek daha hızlı dağıtım yapmak başlı başına bir amaç mıdır? Örneğin güvenliği hem kalitenin hem de performansın bir “alt bileşeni” olarak ele alarak şöyle diyor: “Çok az gözetimle bu kadar çok araç kullandığınızda, sonuçta kalitenizde, performansınızda bir düşüş olur, Güvenlik açısından.” “Yeniliğin yayılmasının, yeniliğin hızından daha önemli olduğunu” öne sürüyor.
Deneyler için güvenli ve verimli bir ortam oluşturmak ve bunu mümkün kılmak için ekiplere doğru derecede özerklik vermek önemlidir. Bu, bir bütün olarak kuruluşun hedeflerine ve bu hedeflere ulaşmak için kullanacağı araçlara ilişkin tutarlı bir görüşe sahip olmasını gerektirir. “Böylece ekipler, organizasyon tarafından verilen çerçeve dahilinde kaldıkları sürece kendi ürünlerini, araçlarını ve hangi teknolojileri seçebiliyorlarsa seçsinler.”
Bu, McJannet’in savunduğu platform mühendisliği yaklaşımına benziyor. Wilson, bir güvenlik uzmanının her birinde takım oyuncusu olarak birden fazla takımda yer alması gerekebileceğini ekliyor. Bu elbette tüyler ürpertici bir şekilde ITIL’in sevilen T şeklindeki, hatta tarak şeklindeki bireylerine benziyor.
Yenilik ve dönüşümün önündeki (algılanan) operasyonel engeller ne olursa olsun, konu değişim olduğunda, bir süreci değiştirmek yerine iyileştiren anlamlı bir çözüm önermeden önce sorunun kökenini anlamak önemlidir.
Cockroach Labs’ın teknoloji müjdecisi Rob Reid şunları söylüyor: “Süreç kuruluştaki bir kişi tarafından anlaşılırsa, teknik bir çözüm daha fazla kişiye ölçeklenmediği sürece yalnızca tek başarısızlık noktasını daha da kötüleştirecektir. Süreç aşinalığı her zaman benimsemenin önünde bir engeldir.”
Bireylerin, yürüttükleri görevleri soyutlama, kodlama veya iyileştirme çabalarına bilinçaltında da olsa direnebileceklerini de hatırlamakta fayda var. Ve bunun, önerilen herhangi bir çözümü benimseme olasılıkları üzerinde etkisi olacaktır.
“Eğer bir süreç, onu gerçekleştirenlerin ikinci doğası olacak kadar iyi anlaşılıyorsa, teknolojistler olarak bizim görevimiz, onu gerçekleştirenleri anlayışla dinlemektir. Bu şekilde, yalnızca sorunu değil, çözümü kullananların günlük yaşamlarını iyileştirecek şekilde sorunu nasıl çözebileceğimizi de anlayacağız,” diye savunuyor.
“Biz [also] işimizin (ve varoluşumuzun) kuruluşumuzdaki diğer çalışanlar için tehdit oluşturabileceğini kabul etmeliyiz. Bu nedenle meslektaşlarımızın yaşamlarını iyileştirmek ve onlara değer sunmalarına yardımcı olmak için işbirliği içinde çalışmalıyız.”
Ancak çok derinlere inmenin ve bireysel süreçlere takıntılı hale gelmenin tehlikesi de var. Her süreç daha büyük bir bütünün parçasıdır ve bir veya iki tanesini tek başına düzeltmenin daha geniş organizasyon için beklenmedik sonuçları olabilir.
Operasyonları dönüştürmeye ne dersiniz?
GigaOm’un katılımdan sorumlu başkan yardımcısı ve eski teknoloji baş sorumlusu (CTO) Jon Collins, platform mühendisliğinin kesinlikle yazılım ve hizmetlerin sunumunu hızlandırmaya ve aslında bunu sürekli hale getirmeye odaklanan DevOps’un olgunlaşmasını temsil ettiğini söylüyor Temel altyapıyı düşünmenize gerek kalmadan. Platform mühendisliği, geliştiricilerin temel altyapıyı anlaması ve bunun için önceden mimari oluşturması gerektiğinin bilincindedir.
Ancak şöyle devam ediyor: “Dijital dönüşümün sorunu, sonuçta operasyonel modelleri doğrudan etkilemesidir. ‘Hey, sadece değişmemiz gerekiyor’ demek kadar basit değil.”
Collins, bulut tabanlı yaklaşımların tek uygulamalar ve hatta benzer şekilde yapılan birden fazla uygulama için yeterli olabileceğini savunuyor. “Bunlar, 1960’lardan beri var olan, 1990’lardan beri var olan, geçen haftadan beri var olan ancak yanlış inşa edilmiş olan devasa ve karmaşık bir altyapı için yeterli değil.”
Kod olarak politikanın yararlı olduğunu ancak operasyon personelinin kaynak ve zaman eksikliği, beceri eksiklikleri ve bu ekiplerin karşılaştığı diğer tüm zorluklar nedeniyle karşılaştığı sorunları çözmek için tek başına yeterli olmadığını söylüyor. Operasyon ekiplerinin gerçek bir ilerleme kaydedebilmeleri için görselleştirme ve gözlemlenebilirlik, içgörü ve otomasyon konularında ilerlemelere ihtiyaçları olduğunu söylüyor.
“Operasyonel süreçleriniz verimsiz veya hatalıysa, verimsizliği otomatikleştirebilir ve verimsiz bir otomasyonla karşı karşıya kalabilirsiniz. Sadece sorunu ağırlaştırıyorsunuz ya da üzerine yapışkan bir bant yapıştırıyorsunuz”
Jon Collins, GigaOm
“Operasyonel süreçleriniz verimsiz veya hatalıysa, verimsizliği otomatikleştirebilir ve verimsiz bir otomasyonla karşı karşıya kalabilirsiniz. Collins, “Sadece sorunu ağırlaştırıyorsunuz ya da üzerine yapışkan bir bant yapıştırıyorsunuz” diyor.
İşin püf noktası, ilk etapta tüm organizasyon için doğru operasyonel süreçlere ve politikalara sahip olmaktır. Doğru oldukları varsayılarak kodlanabilirler ancak aynı zamanda geliştiricilerin ve tasarımcıların bunları dikkate alması da yardımcı olur.
Collins, geliştiricilerin “kendi temizlikçileri haline gelmelerinin” inovasyon üzerinde gereksiz bir yük oluşturabileceğini söylüyor, ancak “onlardan operasyonlar için tasarım yapmalarını, operasyonların hangi aşamalardan geçeceğine dair gerçekten bir anlayışa ve aşinalığa sahip olmalarını beklerdim ve bu sadece iyi çalışma”.
Operasyonların biraz kendi kendini incelemesi de yanlış gitmeyebilir. Operasyon personelinin “işleri aşırı işleme eğiliminde” olduğunu söylüyor. “Operasyonel mükemmellik, nirvanaya ulaşmaya çalışmakla ilgili değildir. Bu, yaptığınız işte operasyon merkezli olmakla ilgilidir.”
Bu, operasyon fonksiyonunun neyi başarmaya çalıştığını ve dönüşüme nasıl katkıda bulunabileceğini ve dönüşümü mümkün kılabileceğini (bu ister üretimde daha hızlı dağıtım, daha iyi kalite veya daha güvenli yazılım şeklinde olsun) net olması gerektiği anlamına gelir.
Bu, sonuçta “operasyonlara” gerek kalmayacağı anlamına mı geliyor? Tabii ki değil. Sonuçta Collins’in dediği gibi yangınlarla mücadele edilmesi gerekiyor. İşler ters gidiyor. Değişim süreklidir. Ancak dijital ürünler “operasyonlar için tasarlanmışsa”, bu, diğer tüm temel görevler için zaman kazandıracaktır. Ve muhtemelen bunların daha hızlı konuşlandırılmasını da sağlayın.