Bir günlük kısa bir devops zirvesinden sonra, zirve konuşmacılarından ve Educore firmasından katılan Erman Taşkın’ın DevOps enstitüsü eğitimine katıldım. Daha önce online olarak aldığım Microsoft’un eğitimi ile bu eğitimin notlarını aşağıda birleştirdim.

İlk olarak neden DevOps‘u konuşalım.

Bu sorunun cevabı basit. Dev sürekli değişiklik isterken, Ops sürekli stabilite istiyor.

Operasyon her sorun için yazılımcıyı hedef gösterirken, yazılımcı ise her sorunda diagnose’un zorlukları, operasyonun eksikliklerini hedef gösteriyor.

Yazılımcı ben hemen düzeltirim dediğinde, operasyon uzun süreli sürüm pencereleri ile reddediyor. yine sistem stabilitesi ana sebep.

Bir şirketin neden DevOps yapmalıyım sorusunu kendisine sorduğunda da oncelikle aşağıdaki iki soruya cevap bulması gerekiyor.

1. Development için Operasyon ne anlama gelir?
2. Operasyon için development ne anlama gelir?

Bu sorular sonucunda aslında neden DevOps yapmanız gerektiğini kolaylıkla anlayabiliyorsunuz.

Şu anki mevcut yapı Dev’in Agile olması Ops kısmının ise Dev’in arkasını toplaması Business’ın ise bunların hiçbirinden haberi olmamasıdır. Olması  gereken Business’ın ipi göğüslemesi Dev ve Opsun onunla beraber koşması gerektiğidir.

Bir IT’nin hedefi, businessla kesinlikle aynı doğrultuda, ya da direkt aynı olmalıdır.

İkinci konu ‘DevOps’un amacı nedir?’

DevOps un başlangıç noktası Waterfall projeleri Agile ve Lean Development’a çevirmektir. (Waterfall her zaman ezilmesi gereken bir şey değildir. Waterfall’ın zaten hızlı ve sorunsuz çalıştığı yerde bu dönüşüme geçmek gerekmeyebilir.)

Burada business odaklılık hep ön planda tutulmalıdır. Business’ın ihtiyaçlarını hızlıca karşılayabilen daha iyi bir IT düzeni yani, küçük ama sık sürümleri üretebilen, efor ve riski minimize etmiş, yazılım geçiş geliştirme ve operasyonda eforu azaltmış, kaliteli kodu çıkaran, kaliteli yaygınlaştırmayı sağlayan, üretimi arttıran, ve en başta söylediğim gibi bunların hepsini business için yapan bir düzen kurgulanmalıdır.

Mevcut bir diğer sorun ve devops’un çıkış sebeplerinden biri, Dev ve Ops’un her ikisinin de silolarla kendi Configuration Management süreçleri, Change Management ve Release Management süreçlerinin olması ve bunların birbirlerinden haberdar olmamasıdır. Dev’in bir paketi duvarın arkasından Ops’a atması, Ops’un bu paketin arkasının toplaması ve Business’ın bundan olumsuz etkilenmesidir.

DevOps’un amacı bu kafa karışıklığı duvarlarını ortadan kaldırmaktır.

DevOps’un amacı yalnızca Dev ile Ops arasındaki duvarları değil Business ile bunların arasındaki duvarları da kaldırmaktır. Business, Development ve Operation aynı frekansta titreşmeli, aynı yöne gitmelidir ve aynı hızda çalışmalıdır.

Business tarafına verilen servis yalnızca yazılımdan ibaret değil yalnızca sunuculardan ibaret değildir, önemli olan büyük resmi görmektir. Büyük resim sunulan servisin bütünüdür.

Puppet’ın raporunda geçen IT performansına yönelik bir çıktısını da yorumunuza sunuyorum. DevOps bunların en az 3 ‘ünde iyileştirme vadediyor.

Win-Win ilişkisi en güzeli.

Peki birgün tam anlamıyla içimize sine sine DevOps yapıyoruz dediğimizde, başarıyı nasıl ölçmeliyiz ile ilgili birkaç olmazsa olmaz metrik var.

• Deployment frequency- Yaygınlaştırmalar arası geçen zaman
• Change lead time – gelen iş geliştirme isteğinin üretime geçene kadar geçen süre
• Cycle time – Yazılımcının bilgisayarın başına oturduğu andan dağıtıma hazır hale gelene kadar geçen süre (CI)
• Change Failure rate
• Mean time to detect incidents (ITSM)
• Mean time to recover
• Mean time to restore services (backup/rollback)

DevOps Nasıl Olur? dediğimizde her kaynakta hep yalın pratiklerden, yalın temellerden bahsedilir. Peki nedir bu ‘Lean’, hangi yöntemlerdir?

En meşhurlarını aşağıda yazalım.

• A3 Thinking (problem solving)
• Continuous Flow (eliminates waste)
• Kaizen ( continuous improvement)
• Kanban (pull system)
• KPI ( key performance indicator)
• Plan – do – check – act
• Root cause analysis.
• SMART goals (specific,measurable,achiveable,relevant,time-bound)
• Value stream maping (depict flow)

Bu yöntemler sadece DevOps , sadece IT için değil, herhangi bir iş için göz önünde bulundurulması gereken yalın yöntemler. Bu yöntemlerin odağı her zaman ‘value’ olmalı.

Bir diğer konu ise DevOps kültürü. Kültürünüzde muhtemel aşağıdaki düşünce ve davranışları (from), sağındaki yeni düşünce ve davranışlara (to) evirmeniz gerekiyor.

Eğer DevOps dönüşümü sırasında ‘Ogrenme’ kültürünü organizasyonun geneline yaymazsak, DevOps’un gün geçtikçe kendini yiyerek bitireceği bir dönüşüm olacağını kabul etmemiz gerekir.

Çoğu kurum için zor olsa da, öğrenmesi uğruna çalışanın hata yapmasına göz yummak da önerilen tutumlar arasında. Bu yüzden test ortamları var 🙂

Peki yukarda bahsettiğim ‘from-to’ dönüşümlerini yaptık, kültür değişir mi? Hayır. Kültürü değiştirmek için önce davranışları değiştirmek gerekir. Eğer bugün şirketinizde devops kültürünü aşılamak istiyorsanız, davranışları değiştirme yönünde destekleyici birkaç etkinlik, devops days, hackathons, ortak bir sözlük gibi nokta atış şeyler yapmanız gerekebilir. DevOps sadece ekip içerisinde bir kişinin bilmesi ve uygulamak istemesi ile uygulanabilecek bir kültür değil. Herkesin içine sinmesi gerekiyor.

En temelde Strateji olarak doğru iş , doğru ürün, doğru yapı seçilmeli ki en iyileştirme bunun üzerinde yapılmalıdır.

Puppet’ın anketini her yıl takip etmemiz bizim için önemli. Orada, devops yapmak isteyen şirketin, öncelikle kazanması gereken yeteneğin  ‘Coding or scripting’ olduğu söyleniyor. Toplam çalışan sayısının en az %85’inde olmalı vurgusu yapılıyor. Dev’de zaten bu yetenek olmazsa olmaz. Ama Ops’da bu yeteneğiniz yoksa, bu işe hiç girmeden önce, ops ‘daki bireylerin ateş duvarı ile karşılaşmamak uğruna, ‘abi bu iş olmaz yaa’ cümlesini duymamak uğruna, eğitim vererek bu yeteneği kazandırmanız gerekebilir.

HPE’nin “DevOps’un en güzel hali, ‘Everything as Code’ olduğu halidir” cümlesi, fikir itibariyle çok uzak görünse de gerçekten hayali bile güzel bir şey.

Tamam yetenekler hazır, tıkır tıkır kod yazıyoruz, nasıl bir organizasyon yapısıyla Devops yapmalıyız? sorusunun cevabı tabiki tek değil.

Bazı şirketler, dev takımlarının içine ops’cu yerleştirirken bazıları cross-functional takımlar oluşturuyor. Bazıları business odaklı domainlerin içerisine ops ve dev’i businessla beraber çalıştırırken bazıları merkezi bir devops ekibi kurup, onların hazırladığı api’lerle bu işi yapıyor.

Ne yaparsak yapalım, unutmamamız gereken şey şu. Ne agile, ne de ondan beslenen devops, hiyerarşik örgütlenmeye kocaman bir hayır diyor.

Gel gelelim devops prensiplerine.

Nedir bu devops pratikleri, prensipleri?

DevOps prensipleri konusunda, daha önce okumuş olduğum Phoenix Project kitabı direkt yol gösterici.

Bu işin üç yaklaşımı, yolu var.

1. Yol – Akış
   1.  DevOps’a uygun yeni sürecini anla ve hızı sağa doğru (üretim) kaydır.
      1. Continuous Integration, Delivery, Deployment.
      2. Timeline, Waste Anaysis.
      3. Less ‘Work in progress’ more ‘Done’ vs..
2. Yol – Geri Besleme
   1. Çok hızlı ve kısa geri beslemelerle, sürekli gelişmeyi sağla. Yani testi ve kaliteyi sola kaydır.
      1. Dashboards, Logs, Live Monitoring
      2. Continuous AUTOMATED Testing
      3. Change/Incident/Problem/Knowledge Management vs..
3. Yol – Sürekli deneyimleme ve ogrenme
   1. Deneyim kazanma, risk alma ve ogrenme üzerine yeni bir kültür oluştur.
      1. The deming cycle (PDCA)
      2. KATA vs..

ITSM, Developer’ın duymaktan en çok çekindiği kısaltma. DevOps ve ITSM nasıl yürümeli?

Örneğin ITIL kullanıyorsan, ITIL’ın anahtar süreçleriyle, DevOps pratiklerini karşılaştırmalı, bunlar arasında ITIL’ın meşhur kelimesi ile ‘Transition’ yapmalısın.

ITIL terimlerinden biri olan deeğişiklik yönetimi konusunda, örneğin değişiklik bir bariyer, bottleneck’tir bakış açısı yerine, ilerideki risk’i minimize etmeye yönelik bir girişimdir’i kabullenmek gerekiyor. CAB ‘i otomatize etmek, değişiklik sonucunda, değişiklik sahibini suçlamak yerine, 3.yol’da denildiği gibi, sürekli ogrenme ve deneyimleme yönünde çalışanları teşvik etmek gerekiyor.

Bir diğer ITIL processi olan Sürüm ve Yaygınlaştırma yönetimi konusunda, örneğin aylık haftalık sürüm pencereleri yerine, businessin karar verdiği, risklerini öğrendiği, konuşarak iş birliğiyle mutabık kalınan, anlık sürümleri değerlendirmek gerekiyor. Ortamın hazır olmadığı için stage’ler arası, uygulama yaygınlaştırmanın kaybettiği zamanı azaltmak, gerekirse sanallaştırmak, gerekirse cross-functional takımlarla paralel çalışarak ortamı çok daha öncesinde hazırlamak, tüm altyapıyı kod haline getirerek, hızlı bir şekilde provizyon edebilmek gerekiyor.

Problem yönetimi konusunda, reaktif bir yaklaşım yerine, problemi tüm devops lifecycle’ında öncesinde doğurtmak, problemi de yine sürekli öğrenme ve deneyimleme ile entegre etmek gerekiyor. Problemi incelerken sürekli beyin fırtınası yapmak yerine, bilinen yalın tekniklerle üstüne giderek ogrenmek ve tekrarlanmamasını sağlamak gerekiyor.

DevOps evet bir tool değil ama çeşitli toollarla, otomasyonu arttırarak hızlı başarı elde edebilirsiniz. ITSM ve Devops için aşağıdaki başlıklı toollar sizi bu ITSM’i ITIL’ı devre dışı bırakmadan devops yapma konusunda yardımcı oluyor.

Enterprise-wide suites, Risk  process tax specific tools, Service Portfolio, Service Catalog, Service Knowledge Management system, Configuration Management System.

Communication ve Collaboration’da bu işin olmazsa olmazı. Onları da enable edebilmek için wikiler, chatOps’lar, dashboardlar, kanban boardlar, workflowlu project management toolları kullanılabilir.

Kısacası bugun karar verdim, ben şirketimde devops yapacağım diyorsanız, oncesinde neden demeniz, ardından siz gibi neden diyebilen doğru kişileri bir arada bulundurarak bir daha daha neden demeniz, sonrasında o ekiple neden konusunda hem fikir olup, tüm devops terimlerinde mutabık kalmanız, değişmesi gereken ve devops’un olmazsa olmaz dediği kritik davranışlara odaklanmanız, deneyimleyerek ve ogrenerek değiştirmeniz, sürekli öğrenmeye teşvik ederek bu ekip içerisinde yaygınlaşmanız,ardından da ekibe ve kuruma katılacak her yeni bireye bu kültürü aşılamanız gerekiyor.

Sıra çok basit,soldan sağa, People+ Process + Technology = Culture

Culture V2= Devops.Ve son söz,

“DevOps is not only possible, it is necessary in the new world of business technology.” – Forrester Research.