Bu yazıdan kurulum olarak hem Zookeeper’lı Kafka kurulumu hem de Kafka 2.8 versiyonu itibariyle Zookeeper’a alternatif olarak Kafka’ya dahil ettiği KRaft’lı kurulum yönergelerinide paylaşacağım. Bunların kurulum adımları haricinde Kafka’nın kapasite planlaması, Kafka kümesinin kurulması, performans testleri, güvenlik ayarları ve farklı Kafka kümeleri arasında veri transferi konularında ciddi bir değişiklik olmamaktadır.

Senaryo:

Senaryo olarak iki farklı veri merkezine 3’er adet Kafka broker kurup veri merkezleri arasında senkronizasyonu sağlamaycağız. Tabii bunu yaparken Kafka’ların hem kendi veri merkezleri içerisinde yedekli olmasını garanti altına almak istiyor hem de Kafka üzerinde ACL, SSL gibi güvenlik önlemlerini almak istiyoruz.

Bu yazıda Kafka’nın kurulumunu tamamlayıp bir sonraki adımdaysa SSL kurulumu, SCRAM ayarları, MirrorMaker 2 ve performans testlerine odaklanıyor olacağım.

Son olarak Kafka’yı 3 adet Zookeeper ve sadece 2 adet Broker ile kurmak mümkün ama daha gerçekci bir senaryo oluşturabilmek için 3 adet Broker kurulumu yapıyor olacağım. Bunun iki sebebi var birincisi kümeleri planlarken birden fazla node’un devre dışı kalma ihtimaline göre planlama yapmak öbürüyse min-ISR değerini 2 yaptığınız taktirde tek bir node’u kaybettiğinizde kümeniz duracak, min-ISR 1 yaptığınız taktirde de veri yedekliliğini kullanamayacaksınız.

Kapasite Planlaması:

Her kurulumun ilk adımı kapasite planlaması olmalıdır. Kafka ve Zookeeper sunucularını kuracağımız sistemlerin CPU, Memory, Disk ve network ihtiyaçlarını önceden hesaplamak ve ona göre kurulumlarımızı yapmamız her zaman operasyonlarımız için daha sağlıklı olacaktır.

CPU: Kafka çok fazla CPU tüketen ve performans dar boğazlarına genelde sebep olan bileşen değildir. Buna rağmen CPU ihtiyaçlarını planlarken dikkat edilmesi gereken bir kaç kritik nokta var.

• Kafka’nın bileşenleri multi-threaded çalışmasından dolayı genel sistem performansı CPU’nun hızından çok core sayısına bağlıdır.
• Eğer consumer’larınızı max.fetch.wait=0 olarak ayarlarsanız bu CPU tüketimine olumsuz olarak yansıyacaktır. Eğer uygulamanız izin veriyorsan consumer ve producer’ların işlemlerini batch olarak yapmasını tercih edebilirsiniz.
• Kafka mesajları şifrelemek(encryption) veya sıkıştırma(compression) özelliğine sahiptir. Eğer bunları kullanacaksanız mutlaka ek CPU tüketimini göz önüne alınız.

CPU olarak orta yoğunlukta bir Kafka kümesi için Broker’lara minimum 4 CPU ve Zookeeper’lar için min 2 CPU önermekteyim.

Memory: Tüm Kafka ve zookeeper bileşenleri JVM kullanmaktadır, minimum 4GB’lık bir heap size hem Zookeeper hem de Kafka Broker’ları için yeterlidir. Bunun altında bir heap size; çok fazla garbace collection’a sebep olacağından dolayı CPU kullanımını artırır.

Başka önemli noktaysa Kafka’ya yazılan tüm veriler eş zamanlı olarak partition’lara(disk) yazılsada aynı zamanda memory’de yer olduğu müddetçe OS Page Cache’de de tutulur, bu sayede mesaj çağrıldığında diske gitmek yerine direk memory’den çağrılabilir. Bu genel sistem performansını etkileyen bir parametredir. Memory ihtiyacını kabaca aşağıda bulunan formülü kullanarak hesaplayabilirsiniz. 

(avg-msg size) * (Saat) * (Saatlik mesaj sayısı)*(toplam kopya sayısı) / Broker sayısı

Mesela 3 broker’lı saatte 1.000.000 mesaj yazan ve ortalama mesaj büyüklüğü 10KB olan bir kümede mesajları 2 saat kadar Page’de tutmak istiyoruz ve replication factor’ün 2(leader ve follower) olması durumunda formülümüzü uyarladığımızda;

(10kb)*2*(1000000)*2 /3 = 12.8 GB

13GB civarı Broker başına bir memory ihtiyaçı çıkacaktır. Buna heap size ve OS ihtiyaçlarını da eklediğiniz zaman kabaca memory ihtiyacınız çıkacaktır.

Storage: Disklerin performansı hem Zookeeper hem de Kafka Broker’ların performansını doğrudan etkileyen bileşenlerdir. Zookeeper veya yerine gelen Kraft sürekli bir metadata transferi yapacağından dolayı ve loğları çok hızlı şekilde yazmak zorundadır; bu bileşenler disk kapasitesinden çok yüksek performans ihtiyacına sahiptir ve genelde SSD/Flash diskler tercih edilmelidir.

Broker tarafındaysa hem kapasite hem de hız önemli faktörlerdir. İyi uygulama örneği olarak Kafka Broker’lara mümkün olduğu kadar hızlı diskler verilmelidir, bu sayede log(mesaj) geldiğinde page’de tutulmasının yanında commit edebilmek için Partition’a yazması gerekmektedir, bu işlemi ne kadar hızlı yaparsa producer bir sonraki mesajını yollamaya başlayabilir, bu da genel sistem performansını ciddi şekilde etkilemektedir. Aynı zamanda yoğun sistemlerde memory hızla dolabilir ve consumer loğlara erişebileceği zaman disklerden okunması gereklidir.

Peki disk kapasite ihtiyacını neye göre karar veriyoruz; kapasite aşağıdaki parametrelere bağımlıdır

• Ortalama mesaj büyüklüğü
• Günlük mesaj sayısı
• Retention süresi(gün cinsinden)
• Replication sayısı

Kabaca formülü;

(ortalama mesaj büyüklüğü) * (günlük mesaj sayısı) * (retention süresi) * (replication sayısı)

Örnek olarak: 10KB’lık mesajımızı 3 gün süreyle tutmak istiyoruz ve günde 1000000 kadar mesaj gelsin. Replication factorümüz 3

10KB * 3 * 3 * 1000000 = 85GB’lık bir disk ihtiyacımız ortaya çıkacaktır.

Kafka Kurulumu

Kurulum adımlarını yazarken hem Kraft’lı versiyona hem de Zookeeper’lı versiyona uygun olmasına özen gösterdim. Kraft kafka için metadata yönetimini yapan ve Zookeeper’ın yerine 3.0 versiyonu itibariyle geçen bir araçtır. Kafka’nın tüm ihtiyaç duyduğu metadataları internal bir topic üzerinde tutmaktadır, çalışma mekanizması olarak __consumer_offtopics ile benzerlik gösterir.

Kafka 3.0 hala içerisinde Zookeeper binary ve konfigurasyon dosyaları ile gelmektedir, yani istediğinizi kullanabilirsiniz.

Genel kurulum önerileri:

Kafka ve zookeeper servislerini çalıştırmak için ayrı bir kullanıcı yaratmanızı güvenlik sebebiyle öneririm, her iki servis için tek kullanıcı yeterlidir. Aynı zamanda Kafka ve Zookeeper’ın verilerini yazabilmesi için ayrı bir disk ekleyip bunu EXT4 veya XFS ile formatlamanızı öneririm.

Son olarak Kafka ve Zookeeper; Scala ve Java tabanlı uygulamalar olduğundan JVM kurulu olması gereklidir.

Kafka Download:

Kafka tar.gz olarak gelmekte ve tek yapmanız gereken dosyayı istediğiniz bir alana açmaktır. Kafka içerisinde aynı zamanda Zookeeper veya Kraft içinde tüm binary ve configurasyon dosyaları bulunmaktadır.

Ben örnek boyunca binary’ler için /opt/kafka klasörünü ama verinin yazılacağı alanlar için /datadisk dosyasını kullanacağım.

Zookeeper kurulumu:

1)/datadisk içerisinde zookeeper isimli bir klasör oluşturun, bu klasörü zookeeper’in kendi log(mesajları) ve veri tabanı için kullanacağız.

2)Her sunucu için Zookeeper ID yaratılması gerekmektedir, ID sadece sayılardan oluşabilir. Aşağıdaki komutu çalıştırarak ID ve dosyayı yaratalım. ID her sunucu için ayrı olmalıdır.
echo “1” > /datadisk/zookeeper/myid

3) /opt/kafka altında bulunan “config” klasörü altındaki zookeeper.properties dosyasını açalım ve içindeki bilgileri şu şekilde dolduralım.

# Zookeeper loğları ve snapshotları nereye saklanacak aynı zamanda myid’i hangi klasörde arayacak

dataDir=/datadisk/zookeeper

# Zookeeper Client portu

clientPort=2181

# Eş zamanlı bağlantı sayısını sınırlamak için kullanılır “0” sınırsız için kullanılır

maxClientCnxns=0

# MS cinsinden heatbeat

tickTime=2000

# Senkronizasyon için ne kadar süre ayrıldığı(ms), bu süre içerisinde sync sağlanamazsa bağlantı timeout oluyor

initLimit=10

# Timeout olmadan önce(küme dışına çıkmadan önce) kaç kere ulaşamayacağını belirler.

syncLimit=5

# Zookeeper kümesinde olan sunucuların FQDN olarak domain adları ve portları.

server.1=zookeeper1:2888:3888

server.2=zookeeper2:2888:3888

server.3=zookeeper3:2888:3888

En son satırlarda bulunan server.1, server.2, server.3 olan kısma dikkatinizi çekmek isterim. server.<id> kısmında ki id numarası ile FQDN’i girilmiş zookeeper sunucusunun myid dosyasında yazan id numaraları aynı olmalıdır.

Bu adımlardan sonra Zookeeper’ın çalışıp çalışmadığını ve diğer node’lara bağlanıp bağlanmadığını test edebiliriz. Aşağıda ki komut ile sunucuları başlatalım.

/opt/kafka/zookeeper-server-start.sh –deamon /opt/kafka/config/zookeeper.properties

Loglar içerisinde Leader’ın seçildiğini görürseniz ve kümede election işlemleri sorunsuz biterse Zookeeper’ı kapatıp Kafka kurulumuna geçebiliriz.

Kafka Kurulumu:

Kafka kurulumunu Zookeeper’lı ve Zookeeper’sız olarak ayrı ayrı anlatacağım. En başta Zookeeper’lı anlatım.

/opt/kafka/config altında bulunan server.properties dosyasını açalım. Burada bulunan tüm ayarlardan bahsetmek yerine sadece kritik olanlardan bahsedeceğim.

1)Broker.id = 1; Broker ID her bir broker için eşsiz olmalıdır, sunucularınızın id’lerini sırayla 1,2,3,4 veya 10,15,20 şeklinde verebilirsiniz. Sadece numaraları kabul etmektedir ve her kafka broker’ı için eşsiz olmalıdır.

2)listeners=PLAINTEXT://:9092
Listeners Kafka’nın hangi porttan hangi protokol ile trafiği dinleyeceğini belirtmektedir. Kafka an itibariyle aşağıdaki 4 protokolü destekliyor;

• PLAINTEXT: Consumer ve Producer’ların kafka’yla yaptığı trafik clear text’dir ve Topic’ler için herhangi bir kullanıcı adı şifreye zorlanmaz
• SSL: Consumer ve Producer’ların kafka’yla yaptığı trafik SSL ile şifrelenir ve Topic’ler için herhangi bir kullanıcı adı şifreye zorlanmaz
• SASL_PLAINTEXT: Consumer ve Producer’ların kafka’yla yaptığı trafik clear text’dir ama Topic’ler için kullanıcı adı ve şifre ile gelinmesini zorumlu kılar
• SASL_SSL: Consumer ve Producer’ların kafka’yla yaptığı trafik SSL ile şifrelenir ve Topic’ler için kullanıcı adı ve şifre ile gelinmesini zorumlu kılar

Canlı ortamlarda SASL_SSL kullanılmasını öneririm ama ilk kurulum için şimdilik sadece PLAINTEXT olarak ayarlayabilirsiniz.

3)log.dirs =/dataDisk/kafka
Logların hangi fiziksel alana yazılacağını belirler, partitionlar burada oluşturulur.

4)num.partitions: Topic’ler için varsayılan otomatik oluşturulan partition sayısını belirler, minimum broker sayısı kadar oluşturmanız performans açısından en iyi sonucu verecektir.

5) offsets.topic.replication.factor, transaction.state.log.replication.factor ve transaction.state.log.min.isr parametrelerini bir bütün olarak ele almak lazım. Kafka her partition için hangi offset’te kalındığını ve küme içinde metadata transferini _consumer_offsets ve __transaction_state isimli iç topic’leriyle yönetir.

Kafka’yı ilk çalıştırdığınızda bunları yaratır ve yaratırken bu topiclerin kaç partition olacağını belirleyen parametrelerdir.

Önerilen sayı minimum 3 olmasıdır ama benim önerim broker sayısına eşit yapılmasıdır. Eğer bu sayıyı 1 olarak ayarladığınız durumda offsets bilgisi sadece bir adet broker’da kalacaktır. Bu broker’ın devre dışı kalması durumunda tüm consumer trafiği duracaktır.

6) log.retention.hours=24 ve log.retention.bytes=1073741824; Kafka’ya gelen mesajların ne kadar süre saklanacağını belirleyen parametrelerdir. Saat veya büyüklük cinsindendir, hangi kondisyon önce karşılanırsa ona göre retention politikası devreye girer.

7) zookeeper.connect=zookeeper1:2181,zookeeper2:2181,zookeeper3:2181
Kafka’nın kümede bulunan node, partition, topic ve ACLs bilgilerini takip edebilmek ve kontrol edebilmesi için kullandığı zookeeper’ların FQDN olarak girilmesi gereklidir.

Bu adımları takip ettiğimiz taktirde; SSL ve SASL desteği olmadan Kafka kümesini çalıştırabilirsiniz ve aşağıdaki komutu her bir broker sunucusu için çalıştırmanız yeterlidir.

/opt/kafka/kafka-server-start.sh –deamon /opt/kafka/config/server.properties

Kraft’lı kurulum:

Kraft ile kurulumda bir önceki kısımda ki adımlardan 7. adım hariç hepsi bire bir aynıdır sadece bu sefer işlemleri /opt/kafka/config/Kraft/server.properties dosyasında yapmamız gerekli.

1)process.roles=broker, controller
Kafka node’un rolünü belirliyoruz, 2.8 itibariyle bir kafka node’u broker ve/veya controller olabiliyor. Eğer yukardaki örnekte olduğu gibi her ikisini de yazarsak node her iki role’de aynı anda sahip olabilir.

2)listeners= PLAINTEXT://:9092,CONTROLLER://:19092
Yukarda belirtilen listener protokollerine ek olarak Controller isimli yeni bir protokolde eklenmiştir, bunu tüm controller rolüne sahip node’lara eklememiz gerekli.

3)controller.quorum.voters=1@kcontroller1:19092,2@kcontroller2:19092,3@kcontroller3:19092

Zookeeper connect parametresinin çalışmasına benzer şekilde Kraft controller’larının bulunduğu sunucuları FQDN olarak ve port bilgileriyle beraber giriyoruz.

4)Kraft’da quorum olarak üzerinde bulunduğu sunucuların disklerini kullandığından ve Zookeeper yerine küme id’sini belirleyeeğinden dolayı. Kafka küme ID’sini yaratmamız gereklidir.
/opt/kafka/bin/kafka-storage.sh random-uuid
Çıkan ID’yi bir yere kopyalayın.

5)Son olarak yarattığımız ID ve kafka-storage’ı kullanarak kafka’nın kullanacağı disk alanını formatlamamız lazım. Burada formatlanacak alan logs.dir parametresiyle aynıdır.

./bin/kafka-storage.sh format -t <id> -c /opt/kafka/config/kraft/server.properties

Bu adımlardan sonra kafka servislerinizi başlatabilirsiniz. Kraft’ın kurulumu ve detayları hakkında config altında bulunan Readme.md dosyasının içeriğine bakmanızı öneririm.

Kafka’yı test etmek:

Kafka’nın sorunsuz çalıştığını test etmenin en iyi yöntemi bir topic yaratıp içerisine mesaj yazmaktan geçer.

1)Topic yaratmak için herhangi bir kafka broker sunucusuna girip aşağıdaki komutu giriniz;

 ./bin/kafka-topics.sh --create --topic kafka-test --partitions 3 --replication-factor 3 --bootstrap-server localhost:9092

Bu komut kafka-test isimli 3 partitiondan oluşan ve her partition’nın 3 kopyası olan bir topic yaratacaktır.

2)Kafka üzerindeki tüm topic’leri listelemek için aşağıdaki komutu kullanabilirsiniz, bunun çıktısı olarak kafka-topic’i göreceksiniz.
bin/kafka-topics.sh --bootstrap-server localhost:9093 --list

3)Eğer topic hakkında detaylı bilgi istersek;

bin/kafka-topics.sh --bootstrap-server localhost:9093 --describe --topic kafka-test

Bu komutun çıktısı sonucunda her partition’nın liderinin(aktif) hangi broker üzerinde olduğu, replication’larının hangi broker’larda olduğu ve senkronizasyon durumunu görebiliriz.

Bir sonraki yazımda Kafka için güvenlik ayarlarını yapacağız, performans testleri ve opensource arayüzlerden bahsedeceğim.

Okudunuz için teşekkür ederim.

The post Zookeeper’lı ve KRaft’lı Kafka Kurulumu first appeared on EMRE BOZLAK.

The post Zookeeper’lı ve KRaft’lı Kafka Kurulumu appeared first on EMRE BOZLAK.

Aralarındaki farkı iyicene anlayabilmek için her birine detaylı bakalım.

Service mesh; servislerin bir birleriyle konuşmasını sağlayan mikroservislerin kendi aralarındaki iç trafiğini(east-west) yöneten bir alt yapı bileşenidir, network seviyesinde L4 ve L7’de çalışmaktadır.

Service mesh’in başlıca özellikleri:

• Servisler arasında ki trafiğin yönlendirilmesi; mikroservis aynı platform(k8 gibi) üzerinde bulunan başka bir mikroservisi çağırmak istediğinde bu servisin hangi pod üzerinde bulunduğu, pod içerisinde kendisine en yakın container’ın hangi node üzerinde bulunduğunu ve trafiğin container’lar arasında dağıtılmasından sorumludur.
• Rate limiting; bir birini çağıran servislerin eş zamanlı kaç adet çağrıda bulunabileceğini ve/veya requestin büyüklüğünü belirleyebilir.
• Retry; birbirini çağıran servislerde, yanıt alamama durumunda iletişimi tekrar deneme sayısını, bu sayıyı aştığında ise circuit breaker sürecini ayarlayabilirsiniz
• A/B testing için servis çağrılarının mesela %90’ını v1’e yönlendirirken geri kalanların v2’e yönlendirilmesini sağlayabiliriz; eski sürümün trafiği yavaş yavaş azaltılırken, gelen request’ler yeni sürüme yönlendirilir (Strangler Pattern). Özellikle 7/24 trafik alan finans uygulamaları, e-ticaret siteleri için çok değerli bir özelliktir.
• Servisler arası network seviyesinde iletişimi kontrol ettiğinden dolayı service mesh bize oldukça detaylı metrikler sunabilmektedir, bu metrikleri hem performans analizi için hem de servislerin health check’i için kullanabiliriz.
• Güvenlik tarafındaysa iki önemli rol üstlenmektedir; birincisi servisler arasında ACL’ler ile erişim yetkilerini tanımlanması ve mutual TLS kullanarak ek bir güvenlik oluşturulması.

Yukarda yazdığım tüm özellikleri servis mesh kullanmak yerine uygulama içerisine mantığı gömerek gerçekleştirmekte mümkün ancak hem sürdürmesi zordur hem de yapılar çok büyüdükçe yönetilmesi imkânsızlaşır, bunun yanında uygulamamız içerisinde temel fonksiyonuyla alakasız işlevleri de gömerek mikroservisin felsefesinden de uzaklaşmış oluruz.

Service mesh ise sidecar denilen bir yapı sayesinde kendini pod’un içerisine dâhil ediyor ve pod içerisindeki tüm içeri ve dışarı doğru olan trafiği kontrol ederek yukarıdaki fonksiyonları sağlayabiliyor. Bunun en büyük artısıysa kodumuzda herhangi bir değişiklik yapmamıza gerek olmaması.

API Gateway fonksiyonuna gelirsek aslında mikroservis yapılarından daha öncede var olan ama mikroservisler ile beraber popülerliği artan başka bir yapı taşıdır. Service mesh’den farklı olarak API GW kuzey-güney trafiğini tek bir noktadan yönetmek için kullanılır veya veri merkeziniz içerisinde iki farklı teknolojiye sahip servislerin konuşması için de kullanılabilir.

API GW kullanmanın faydaları;

• Soyutlama(Abstraction): API GW başka servisler ve istemciler için tek bir çağrı ve cevap noktası olduğundan dolayı arka taraftaki karmaşık yapıdan sizi soyutlar ve daha bütüncül bir deneyim sunar. Bir kredi kartı hesap özeti ödeme servisiniz olduğunu düşünün; bu servis aracılığıyla hesabınızdaki paranın bir kısmıyla ödeme yapmak istediniz de arka tarafta sırayla şu servisler kullanılacaktır;
  • Müşterinin bu işlemi yapma yetkisi kontrolü
  • Hesap durumu ve bakiyesi uygunluğu kontrolü
  • Ödeme yapılan kuruma para transferinin gerçekleştirilmesi
  • Bakiye güncellemesi
  • Ara yüzde işleme ait dekontun gösterilmesi veya adımlardan herhangi birinde hata varsa tüm yapılan işlemlerin geri alınması.

Yukarıda özetlediğim işlem adımlarının her biri farklı bir veya daha fazla servise denk gelmektedir; her biri için client farklı farklı çağrılar yapabilir veya API GW üzerinden tek bir çağrının yapılmasını sağlayıp arkadaki orkestrasyon/çoklu işlemi saklayabilir. Bunun hem performansa hem de geliştirme süreçlerinin yalınlığına katkısı pozitiftir.

• Kimlik doğrulama(Authentication): API GW arkasında bulunan servislere ulaşabilmek için gerekli tokenların olup olmadığını kontrol eder veya authentication için gerekli servisleri arka tarafta çağırabilir.
• Trafik Kontrolü: Yapılan çağrıların belli IP’lerden gelmesi, belli bir büyüklüğü geçememesi veya belirli bir süre içerisinde yapılabilecek maksimum çağrı sayısını belirleyebiliriz. Özellikle servislerimizi DDoS gibi saldırılara veya gereğinden fazla çağrılarak sistemi yormasına karşı korumak için ek bir önlem olarak kullanılabilir.
• API’lerin izlenmesi ve ücretlendirilmesi: Bu iki fonksiyon bir birinin tamamlayıcısıdır, API çağrıları üzerinden metrik toplayarak hem ileride problemlerin çözümü için veri biriktirirken, ileride dışarıya açtığımız servisleri ücretlendirebilir veya en çok/az kullanılan servisleri kolayca bulabiliriz.
• Dönüşüm(Transformations): API GW’in kullanım avantajlarından biri de eski veya farklı protokol kullanan uygulamaları bir biriyle konuşabilmesi için gerekli dönüşümü yapabilmesidir. Hem eski legacy uygulamaların yeni yapıyla entegre çalışabilmesi için kritik bir özelliktir, hem de bu tür dönüşüm fonksiyonlarını uygulama içerisine gömmeyerek uygulamanın taşınabilirliğini ciddi oranda artırmış oluyoruz.
• Önbellek(Cache): API GW istenirse önbellek görevi de görerek response time’ı azaltabilir, pek tercih edilen bir özelliği olmamakla beraber sık çağrılan ve görece az güncellenen API’lar için ideal olabilir.
• Güvenlik: Kimlik doğrulama ve trafik kontrolü’nün yanında aynı zamanda TLS, mTLS veya header kontrolleri bu katman üzerinde yapılabilir, böylece uygulamalar güvenlik sorumluluğunun bir kısmını API GW’e devretmiş olur.

API GW’in tam işlevini pekiştirmek için sıkça kullanılan bir senaryoyu konuşmak istiyorum. Birincisi, istemci(client) backend servislerinin karmaşıklığından soyutlamak ve çoklu servis çağrılarında verileri tek bir noktada toparlayıp o şekilde cevap vermek.

Mesela aşağıdaki örnek uygulamada istemci son yapılan para transfer işleminin dekontunu gösterebilmek için 3 farklı servisin verilerine ihtiyaç duyuyor. İstemci 3 servisi de tek tek çağırıp onlardan topladığı verileri daha sonra kendi üstünde birleştirmek zorunda; burada ki problem istemcinin aslında aynı kaynağa 3 kere farklı çağrı yapması ve aralarındaki en yavaş çağrı süresi kadar başlayıp kendi üzerinde birleştirme işlemini yapıyor olması. Bu hem kaynak hem de ileride bu servislerden birinde yapılacak değişiklikte tüm istemcileri de güncelleme zorunluluğuna sebep olabileceğinden dolayı çok istenen bir durum değildir.

Bunun yerine araya bir API GW koyduğumuzda istemci sadece tek bir çağrı yaparak API GW’in gerekli API’ları çağırması veriyi toparlayıp tek bir cevap olarak dönüş yapmasını sağlayabiliriz. Bunun en büyük avantajları yavaş network(internet) üzerinden tek çağrı yapılırken, hızlı network üzerinden(internal) 3 çağrı yapıldığından toplam cevap süresi uygulama için azalacaktır; aynı zamanda API GW yapılan çağrıda hali hazırda güvenlik tokenlarının olduğunu görüp “Kimlik Doğrulama Servisini” hiç çağırmayabilir veya dekontun template’i zaten önbellekte olabileceğinden dolayı minimum çağrıyla istemciye cevap verilecektir.

Burada birçok yazılım mimari arkadaşım microservice tasarım modellerinden olan “service aggregator’u” neden tercih etmediğimi soruyorlar. Birincisi fonksiyon olarak benzer işleri yapabilseler de her bu tür servis için ayrı bir aggregator geliştirmek, bunun yaşam döngüsünü ve sürdürülebilirliğini yönetmek ek bir iş yükü getirecektir; bunun yanında API GW daha çok uç noktaya konulan ve istemcileri/3. Parti entegrasyonları karşılama görevini de üstleneceğinden dolayı dönüşüm, güvenlik, trafik yönetimi gibi rolleri de üstlenebilecek bir ürünün kullanılmasını daha doğru buluyorum.  Tabii sıkça service aggregator ve API GW’in beraber kullanıldığı tasarımlar görüyor olabilirsiniz, özellikle servisiniz için özel bir aggregation akışına ihtiyacınız varsa ve istemcilerin içerisine gömmek istemiyorsanız tercih edilmesi doğru bir yaklaşımdır.

Servicemesh ve API GW’in ne olduğunu açıkladığıma göre; en sık karşılaştığım soruya cevap vermeye çalışayım. ServiceMesh ve API GW bir birinin yerine geçebilir mi?

Hayır; birçok ortak özellikleri olmakla beraber ve birçok firmanın API GW ve service mesh ürünlerini tek bir marka altında sunmaya başlamasına rağmen rolleri farklıdır.

API GW; servislerimizi dışarıya nasıl sunacağımız, hangi güvenlik mekanizmasından geçireceğimiz ve farklı protokollerin bir biriyle konuşmasını düzenlerken; service mesh içerideki servislerin bir biriyle nasıl konuşması gerektiğini düzenler.

Aşağıda bir tabloyla özeti bulabilirsiniz;

Vakit ayırıp okuduğunuz için teşekkürler.

The post Service Mesh ve API GW nedir? first appeared on EMRE BOZLAK.

The post Service Mesh ve API GW nedir? appeared first on EMRE BOZLAK.

Kafka dağıtık, kolay ölçeklenebilir, hataya dayanıklı ve sürdürülebilirliği yüksek bir veri/olay akış aracıdır. Çok büyük miktarda veriyi eş zamanlı karşılamasının yanında veriyi üreten kaynaktan okuyup arkada tüketecek sisteme 10ms’nin altında aktarabilecek bir kapasiteye sahiptir. Peki, Kafka ne gibi senaryolarda kullanılmaktadır;

• Büyük ölçekte IoT metriklerinin veya uygulama loğlarının toplanacağı, yüzlerce hatta yüz binlerce kaynaktan eş zamanlı gelen verilerin yazılması, saklanması ve ilgili uygulamaların kullanabilmesi için verilerin sunulabilmesi.
•  Farklı sistemlerin bir birleriyle konuşabilmesi için ortak ara yüz sunması; bir uygulama eğer birden fazla uygulamayla iletişime geçmesi gerekiyorsa her biriyle olan iletişimi için tek tek entegrasyon yazılması gerekmektedir. Bu hem iş yükü olarak hem de mimari olarak çok tercih edilmediği gibi, değişiklikler veya sorunlar esnasında ciddi darboğaza sebep olmaktadır. Bunun yerine uygulamalar mesajlarını Kafka’ya yazıp, bu mesajı tüketecek uygulamaların da direk Kafka’dan bu mesajları okuması, hem karmaşıklığı oradan kaldıracak hem asenkron bağlantı sayesinde uygulamaların genel performansı olumlu olarak artacak hem de geliştirilecek entegrasyon sayısı ciddi anlamda azalacaktır.
• Canlı veri akışının toplanması ve analiz edilmesi; mesela bir web sitesinde kullanıcıların gezinti verilerinin toplanıp anlık önerilerin yaratılması için tüm gezinti metriklerinin kafka’da toplanıp kafka üstünde analiz edilmesi.

Kafka’nın ne olduğu ve amacını anlattığımıza göre terminolojisinden ve mimarisinden bahsetmeye başlayabiliriz. En başta biraz karışık gelse de Kafka oldukça basit bir yapıya sahiptir, özellikle daha önceden bir MQ veya benzer bir Event-streaming servisiyle çalıştıysanız ilişki kurmanız kısa zaman alacaktır.

Broker: Kafka sistemlerinin en temel bileşenidir, Kafka kümesinde çalışan her bir sunucu/servise broker denir. Broker’lar fiziksel olarak kurulu oldukları sunucuya bağlıdırlar ama bir broker kendi üstünde olmasa bile kümede ki tüm topic ve partition’lardan haberdardır. Broker’lar hem producer hem de consumer’lar için bağlantı noktası olarak görev alırlar. Broker’ların her biri eşsiz bir sayı ile temsil edilir(Örnek: 101,102,103 gibi).

Broker discovery/bootstrap server: Consumer veya Producer’lar sadece bir broker üzerindeki bootstrap servisine bağlanarak tüm kümede bulunan diğer broker’lar, topic’ler ve partition’ların durumunu ve bağlantı noktalarını öğrenebilirlerler. Bu bilgileri bootstrap server metadata olarak istemcilere sunmaktadır.

Topic: Verilerin yazıldığı, yaratıldığı anda tüm brokerlar tarafından erişilebilir olan, kafka’nın veri tabanları veya MQ’larda bulunan kuyruklara benzeyen yapısıdır. Topic’ler istendiği kadar yaratılabilir ve mantıksak bir kavramdır. Topic isimleri harf, rakam ve bazı özel karakterlerden oluşabilir.

Partition: Verilerin yazıldı, her broker’ın kendisine özel olan ve bir topic’e bağlı fiziksel disk üzerindeki alanı temsil eder. Bir topic’e ait birden fazla partition olabilir, her partition’nın 20Mb/s’lık okuma ve yazma limiti bulunmaktadır ve partition bağlı olduğu topic’e özel 0,1,2,3… gibi rakamlar şeklinde temsil edilir.

Veri Partition’a bir kere yazılır ve belli bir süre boyunca saklanır, Partition’a yazılan veri silinemez. Topic’ler yaratılırken kaç adet partition ile yaratılacağını belirleyebiliriz. Kafka broker sayısına göre partition’ları küme içerisinde dağıtır. Bu konuda ki iyi uygulamalardan biri broker sayısı veya onun katları kadar partition yaratılması yönündedir.

Replication: Yukarda da bahsettiğim üzere Partition’lar tüm küme tarafından erişilebilseler bile (Broker Discovery/bootsrap server maddesine bakınız.)üzerlerinde bulundukları fiziksel diske bağımlıdırlar eğer broker bir sebepten dolayı devre dışı kalırsa üzerinde bulunan partition’lara erişilemez. Bu da veri kaybına sebep olabilir. Bunu önlemek için Kafka, replication mekanizmasını kullanır. Bir topic yaratılırken her partition’nın kaç adet kopyası olacağını belirleyebiliriz.

Mesela 3 partition ve 2 replication factore sahip bir topic yapısı aşağıdaki gibi gözükmektedir.

Son önemli bir noktaysa partition’ların kopyalarını yarattığımız zaman sadece bir tanesi producer’lar tarafından yazılabilir, t anında yazılabilir olan partition’a leader diğerlerine ISR(in-sync-replication) denmektedir.

Bir partition’nın birden fazla replication’ı olabilir ama sadece bir adet aktif leader’ı vardır.

Offset: Partition ve topic konularını kapatmadan önce önemli bir kavramdan daha bahsetmek gerekli, offset’ler partition özelinde olup, veriler her partition’a yazılırken bir identity number atanır, bu sayede veriler hem partition’a yazıldığı sırayla okunabilir hem de consumer’lar bir partition’da okuma yaparken hangi mesajda kaldıklarını hatırlayabilirler.

Offset sayısı 0’dan başlar ver sonsuza dek devam edebilir, her mesaj yazıldığında yeni mesaja bir sonraki numara atanır.

Offset’ler partition özelinde olduğundan dolayı bir topic’e sahip tüm partition’ların offset sayıları farkılır sadece bir partition’nın leader ve onun replica’ları aynı offset’e sahiptir.

Producer: Kafka terminolojisine göre mesaj(log) yaratan ve ilgili topic’e yazan uygulama/sistemlere verilen isimdir. Producer’lar bootstrap server sayesinde tüm broker, topic ve partition’ların listesine erişebilirler bu sayede mesajı nereye yazacağını ve nasıl yükü dağıtacağını kendisi karar verebilir.

Producer’lar her mesajı yazarken yazılım işleminden sonra onay(ACK) talep edebilirler. Kafka şu anda 3 tip ACK desteklemektedir, bunlar;

• ACK = 0; yani mesajı yazdıktan sonra cevap beklememesi, bunun handikabı veriyi producer’ı broker’a bıraktıktan sonra bir aksilik olur ve yazamazsa producer bundan haberdar olmayacak ve veri kaybına sebep olabilir.
• ACK = 1; Producer leader partition’a mesaj yazıldığında ACK cevabını alır. Veri kaybı riski görece olarak düşük olsa da leader’in ISR partitionlara kopyalaması bitmeden ACK verildiği için eğer tam bu esnada leader partition bulunduğu broker devre dışı kalırsa veri kaybı olabilir.
• ACK = all; Producer hem leader hem de tüm ISR’e yazma işlemi bitmeden ACK cevabını almaz bu sebepten dolayı veri kaybı riski en düşük olan model ama Producer tarafı için cevabı beklemesi gerektiğinden performansı en düşük olan seçenektir.

Uygulamanızın kritikliği, mesaj zincirinin bozulması durumundaki etkisi gibi konuları göz önüne alınarak karar verilmesi gerekmektedir.

Message Key: Uygulamaların(Producer) Kafka’ya yazdığı mesajlar 3 parçadan oluşmaktadır; zaman damgası, mesajın içeriği ve message key. Message key her mesaj için ayrı oluşturur ve aynı key’e sahip mesajlar aynı partition’lara yazılırlar. Bunu Producer eğer belirtmezse, kafka kendisi her mesaj için yaratıp kendisi bir partition’a atayabilir veya alternatif olarak belli tip bir mesajın aynı partition’a yazılmasını istiyorsak özelliklede okuma sırasının her zaman doğru olmasını bekliyorsak message key’i elle de atayabiliriz.

Consumer: Kafka’dan verileri okuyan sistemlere verilen isimdir, aynı producer’lar gibi bootstrap serverüzerinden tüm Kafka kümesine erişebilir ve kendi load balance’ını yapma yetisine sahiptir. Consumer’lar partitionlardan verileri sırayla okur, burada dikkat edilmesi gereken nokta Kafka’ya mesajlar yazılırken birden fazla partition’a yazıldığından dolayı Consumer’lar aynı sırayla partitionlara erişmediklerinden dolayı Kafka’ya yazılma sırasından farklı olarak okunabilir. Mesajlar sadece partition’lar içerisinde sıralıdır, partition’lar bir birinden farklı sırada okunabilir.

Consumer Group: Aynı Topic’i okuyan birden fazla consumer’ın olması durumunda aynı mesajın tekrar tekrar okunmasının önüne geçmek için Consumer Group kullanılır. Consumer group içerisinde bulunan tüm consumer’lar en az bir partition’a atılır ve aynı grup içerisindeki diğer consumer aynı partitiona atanmaz. Böylelikle tekrarlı okumaların önüne geçilir.

Consumer Group içerisinde hangi consumer’ın hangi partition’la eşleştiğini, gruba yeni consumer geldiğinde veya çıktığında partition’ların tekrar dağıtılması işlemini Consumer coordinatör denilen, Kafka’nın broker’larından birini bu rol için leader seçtiği bir node üzerinde olur.

Consumer Group kullanımıyla ilgili iyi uygulamalardan biri de Consumer sayısının asla Partition sayısını geçmemesidir. Consumer group her bir partition’ı sadece bir consumer’a atayacağından dolayı fazla consumerlar boşta kalacaktır.

Consumer group konusunu bitirirken __consumer_offset isimli topic’den bahsetmem gerekir. Bu topic kafka tarafından yaratılan ve yönetilen bir topictir ve consumer’lar bir partition’dan her okuma yaptıklarında hangi offset’te kaldıklarını burada tutuluyor. Consumer group’a yeni bir üye katıldığında veya bir consumer kesinti yaşayıp tekrar kafka’ya bağlandığında buradan nerede kaldığını hatırlayarak devam ediyor. Kafka kümesini ilk kurduğunuzda __consumer_offset’in mutlaka minimum 3 node’a replice edilmesini ayarlamanız gerekmektedir, aksi durumda __consumer_offset’in leader partition’larını tutan broker’ı kaybetmeniz durumunda servisiniz duracaktır.

Consumer delivery semantics: Consumer’ın ne zaman offset’i commit ettiğini belirler.

• At most once: Offset consumer tarafından okunur okunmaz commit edilir, eğer consumer tarafında mesaj okunduktan sonra işlemlerde sorun oluşursa veri kaybı oluşabilir
• At least once: Offset’in commit edilmesi consumer okuduğu mesajı işledikten sonra yapılır, veri kaybı riski az olmasına rağmen mesaj birden fazla kere okunabilir.
• Exactly once: Daha çok Kafka’dan kafka’ya mirrormaker gibi süreçlerde kullanılır.

Kafka terminolojisinden bahsederken fark etmiş olduğunuz üzere kafka ciddi bir metadata yönetimi yapmakta, tüm bileşenlerinin bilgilerini ve yetkileri bir yerde saklamalı aynı zamanda küme içerisinde ki leader/follower yapısını bir şekilde takip edip devre dışı kalan veya yeni eklenen broker’lara göre kümeyi dinamik olarak ayarlayabilmelidir. Kafka mevcut versiyonu itibariyle bu rolleri Zookeeper ile yapmakta ama yakın gelecekte planlanan versiyonlarında Zookeeper yerine kendi iç metadata veri tabanını kullanması planlanmaktadır.

Zookeeper; özellikle büyük veri projeleri başta olmak üzere birçok açık kaynak projesinde kullanılan, dağıtık, key-value veri saklama yeteneğine sahip açık kaynaklı bir servistir. Zookeeper kafka için aşağıdaki rolleri üstlenir;

• Kafka kümesinin takibi; Zookeeper kümede bulunan tüm broker’ları heartbeat servisleriyle izler ve bir tanesine erişilememe durumunda broker listesinden çıkartır. Böylelikle bootstrap servisi üzerinden producer ve consumer’lar bu broker’ı göremezler. Aynı şekilde yeni bir broker’ın eklmesi durumunda tüm kümeye bildirimini yapar.
• Controller seçimi: Kafka broker’larından biri kümedeki tüm partitionların leader/follower ilişkini controller yönetir. Bir broker devre dışı kaldığında onun üzerindeki leader partitionlara sahip hangi replicaların leader olacağını seçer. Bu role sahip broker’ın cevap verememe durumunda Zookeeper yeni bir controller seçer
• Topic konfigürasyonlarının ve ACLs’lerin tutulması: Kümede hangi topic’ler, kaç adet partitiona sahip, partition durumları, replicationların durumu ve yerlerinin bulunduğu metadataları tutar ve yönetir. Aynı zamanda kullanıcıların broker’lar ve topic’ler üzerindeki yetkileride burada tutulmaktadır.
• Kotalar: Topic’ler ve partitionlar ile kullanıcıların yazma/okuma kota bilgilerini burada tutar.

Zookeeper Kafka’dan ayrı bir servistir ve ayrı olarak konumlandırılması ve planlanması gerekmektedir. Zookeeper leader follower mekanizmasıyla çalışmaktadır, yani zookeeper kümesindeki bir sistem tüm işlemleri, değişiklikleri ve koordinasyonu üstleniyor diğer nodelarsa onu takip ediyorlar. Kümede lider seçimi çoğunluk oyuna göre yapılmaktadır, bu sebepten dolayı Zookeeper kümesinin node sayısının 1,3,5,7… gibi tek sayılardan oluşması gerekmektedir.

Yukarda konuştuklarımızı özetlerse Kafka yapısı aşağı yukarı aşağıdaki gibidir.

The post Kafka Terminolojisi ve Mimarisi first appeared on EMRE BOZLAK.

The post Kafka Terminolojisi ve Mimarisi appeared first on EMRE BOZLAK.

Health Check servisleri; uygulamanın sağlık durumunun kendisi tarafından ölçülebilmesini ve bunu dışarıyla paylaşmasını sağlayan, uygulamanın iç metriklerini kontrol eden bir servistir. Son yıllarda AWS, Azure gibi Public Cloud firmalarının sunduğu PaaS yapıları üzerinde uygulama barındırmanın yaygınlaşması ve microservislerin günlük operasyonlarımızı daha fazla işgal etmeye başlanmasıyla beraber sıcak bir konu haline gelmiş olsa da aslında uzun zamandır var olan; bir uygulama izleme ve performans ölçme yöntemidir.

Birçok izleme aracından/yönteminden farklı olarak tamamen bizim kendi uygulamamız için kendimizin geliştirdiği ve metriklerini belirlediği bir endpoint/servis olma özelliğini taşımaktadır. Kafanızda biraz daha canlandırmam gerekirse uygulama üzerindeki ki HC endpoint’i çağrıldığında (Örnek http://uygulalam/health) uygulamanın düzgün çalıştığını işaret eden bir ifade dönmektedir. Bu ifade kimi zaman basit bir “http 200“olabilirken, karmaşık bir iş süreci çalıştırarak dönen sonucu diğer sistemlerle karşılaştırarak sapma olup olmadığının sonucu olabilir. Buradaki kritik performans ve risk kriterleri tamamen size ve uygulamanızın türüne göre değişebilir.

Neden HC servisine ihtiyacım var?

Birçok çalışma arkadaşımla bu servislerin kullanımı üzerine tartışırken zaten hali hazırda farklı alt yapı, OS ve APM izleme araçlarının kullanıldığını; ekstra çaba harcayarak böyle endpoint yazmanın mantığını sorguluyorlar. Öncelikle HC diğer tüm izleme servislerinden farklı olarak uygulamanın içerisinden bir görüş sunmaktadır, bunun haricinde uygulamanın nasıl çalışması gerektiğini ve iç mantığını en iyi yazılım geliştiricinin kendisi bilmektedir. Bu yüzden kendi yazdığı servis ile uygulama mantığında ki sapmalar, thread leak, deadlock, hatalı konfigürasyonları daha kolay tespit edebilir üstelik uygulamaya her yeni sürüm geçerken HC servisini de buna göre güncelleyerek izlenen parametrelerin güncel kalmasını sağlayabilir. Burada şunun da altını çizmek istiyorum HC diğer izleme araçlarının yerine gecen değil onların tamamlayıcısıdır.

Health Checklerin Yapısı

Health Check servislerinin yapısına baktığımızda bir uygulama (monolitik veya microservice) üzerinde barınan, dışarıdan çağrılabilen ve çağrıldığında anlamlı bir cevap dönebilen bir servis ile sürekli bu servisler üzerinden uygulamaların sağlıklarını kontrol edip gerekli aksiyonları tetikleyen bir koordinatörden oluşmaktadır.

Koordinatör; herhangi bir load balancer, Konteyner orkestrasyonu yapabilen K8, Openshift gibi platformalar veya mikroservisler için kullanılan service discovery araçları olabilir (Consul gibi). Koordinatörler Health Check servisinin döndüğü sonuca göre sistemin kararlı olmadığına karar verdiğinde çok farklı aksiyonları tetikleyebilmektedir.

Mesela;

• Load balancer http 200 cevabı alamadığında uygulamaya giden trafiği kesip başka bir yere yönlendirebilir
• Openshift üzerinde çalışan bazı POD’ların latencylerinin istenen değerin üzerine çıktığını yakalayıp o servis için container sayısını artırabilir
• Kendi yazdığınız bir koodinatör ile uygulamanın veritabanına erişemediğini yakalarsa uygulama sunucusunu yeniden başlatacak ansible playbook’unu çağırabilir.

Burada alınabilecek aksiyonların türü ve sayısı tamamen size kalmış durumdadır. Koordinatör olarak kullanılan araçların genellikle yetkinlikleri farklı olsa da hemen hemen hepsi aşağıdaki aksiyonları yapabilir.

• Uyarı oluşturma
• Trafik yönlendirme/kesme
• Sunucuyu yeniden başlatma
• Yeni sunucu/konteyner kurulmasını başlatma; burada K8, Openshift, cloud foundry gibi ürünler out-of-box bu özelliğe sahipken diğer koordinatör tiplerini farklı api’lar veya araçlarla kombine ederek yapabilirsiniz.

Konumlandırma:

Microservisler, hayatımıza birçok rahatlık getirmesinin yanında yeni riskler ve yönetim zorluklarını da beraberinde getirmektedir. Arka tarafta artık Ops ekibinin kontrolüne ihtiyaç duymadan uygulamalar gerekli durumlarda container/node sayısını artırabiliyor, azaltabiliyor veya bir anda eski sürümleri öldürüp yenilerini servis kesintisine sebep olmadan devreye alabiliyor. Doğal olarak monolitik uygulamaları microservise dönüştürürken birkaç sunucudan onlarca, yüzlerce hatta binlerce container’a bölünmüş olabilir, bu kadar geniş bir havuz içerisinde tek bir microservisin doğru çalışmaması ve bunu doğru zamanda tespit edilememesi çok ciddi sorunlara sebep olmaktadır.

Kullanıcılarınızın bir ödeme sisteminde para transferi yapmaya çalıştığını hayal edin ve sadece bir grup kullanıcı ödeme yapmak istediklerinde hata alıyorlar ve tekrar denediklerinde sorun olmuyor. Tüm süreçte sorunlu adımı bulmak ve bu adım içerisindeki tüm container’ları tek tek kontrol etmek canlı sistemlerde her zaman mümkün olmuyor. Öte yandan container’ların ayak izini küçük tutabilmek için daha geleneksel dünyadan alışkın olduğumuz ajan bazlı izleme araçlarından da kaçınmak istenmektedir.

Health Check endpoint’inin yaratılması ve doğru metriklerin kurgulanması burada çok kritik bir adım olmaktadır. Çok fazla metrik belirlenip veya sürekli endpointe sorgulama yaparak sistem üzerinde de ek yük yaratılmamasına dikkat etmek gerekiyor. Benim önerim şu metriklerin mutlaka takip edilmesi yönündedir;

• Servisin bağımlı olduğu API’lara erişip erişemediği; burada karşı tarafın varsa health check servisini çağırıp ona göre kontrolü yapabilir
• Basit OS seviyesinde kontroller; disk doluluğu veya kritik bir path’deki dosyaların büyüklüğü olabilir
• Kritik servislere erişip erişemediği; mesela SQL sunucusuna bağlantı açabiliyor mu? MQ sunucusuna erişebiliyor mu gibi?
• Uygulama üzerinde açılmış threat sayısı; bazen uygulama üzerinde çok fazla veya çok az threat’in açık olması bir anormaliye işaret ediyor olabilir.

Bu 4 tip metrik haricinde her zaman performans veya iş süreçleri üzerinde de metrikler koyabilirsiniz ama burada bahsettiğimiz metrikler uygulamanız ne olursa olsun platform seviyesindeki çoğu hatayı yakalamanızı sağlar.

Bu tip bir endpoint’i sadece microservislerde değil monolitik uygulamalarınızda da kullanabilirsiniz, bu servis sayesinde farklı bir bakış açısı yakalar hem de kök sebebi bulma konusunda ciddi kolaylık sağlanır.

Son olarak mutlaka standart bir JSON çıktısı belirleyip tüm uygulamalarınızda bunu kullanmanızdır, böylelikle bir birine bağımlı uygulamalarda bağlı oldukları uygulamaların hc endpointlerini çağırarak gerekirse kontrolleri yapabilir ve sorun anında ona göre bir aksiyon alabilirler.

The post Health Check servisleri nedir? first appeared on EMRE BOZLAK.

The post Health Check servisleri nedir? appeared first on EMRE BOZLAK.

Operasyon Model tasarımı:

Yeni bir şirkete BT departmanının yöneticisi olarak katıldınız ve üst yönetimle yaptığınız ilk toplantıda sizden ve BT’den önümüzdeki yıl için beklentilerini aşağıdaki gibi sıraladılar.

• Şirket ciddi bir dönüşüm geçirmektedir; müşteri ihtiyaçlarına ve piyasaya daha hızlı cevap verebilmek için portföyündeki ana ürün ailelerine göre iş birimlerini tekrardan organize etmiş ve BT’den de bunu destekleyecek bir organizasyon beklenmektedir.
• İş modelinde köklü değişime gitme hedefleri bulunmakta ve bunun sonucu olarak IoT, Mobil ve VR/AR teknolojilerini kullanarak yeni ürünler/servisler çıkartmak istiyorlar. BT’nin onları bu konuda nasıl ve ne kadar destekleyebileceğini bilmek istiyorlar.
• Öteki yandan şirketin CFO’su bir anda artan BT bütçesine anlam verememekte ve harcanan paraya karşılık şirketin gerçekten ne kadarlık bir kazancı olduğunu ölçememekten şikayetçi. Bu sebepten dolayı ürün bazında BT’nin katkısını ve maliyetlerini görebilmeyi mümkünse bunu ürünün ciroya olan katkısına göre yorumlamak istediğinden bahsediyor.
• COO ise BT’nin bir anda fazla büyüdüğünden şikayetçi ve mümkün olduğunca çalışan sayısını limitlemek istiyor; siz bunun operasyonel olarak sorunları olacağını söylesenize rağmen bu konuda çok ısrarcı olduğundan geri adım atıyorsunuz.

Operasyon model tasarımına nasıl başlanacağına dair net bir yönlendirme olmamakla beraber ben genelde organizasyon, çalışma yöntemleri ve karar hakkı bileşenleriyle başlayıp daha sonra diğer bileşenlerle devam etmeyi tercih ediyorum. Bunun en büyük sebebi en başta ideal organizasyonu ve nasıl çalışması gerektiğini gördükten sonra aşağıya doğru diğer bileşenleri bunlara bağla noktasının daha kolay olduğunu düşünmem. Yukarıdaki maddeleri birbirleriyle çelişen noktaları olsa da aslında dünya genelinde bir gerçeği yansıtmakta.

İlk önce yeni organizasyon şemasına bakarak kaç adet ürün grubu olduğunu, her grup için hangi BT yetkinliklerine ihtiyacımız olduğunu tespit etmeliyiz. Misal bir ürün grubu e-ticarete yoğunlaşacaksa bu grubu desteklemesi beklenen BT ekibinin bu tür bir dijital kanal geliştirme ve destekleme konusunda yetkinlikleri ne durumda ve ne tür bir yetkinlik ağacına ihtiyaçları bulunmaktadır. Bu analizin sonucunda şu çıktıları elde edeceğiz;

• Mevcut insan kapasitem bu şekilde bir organizasyonu desteklemeye uygun mu?
• Ne tip yeni yetenekler ve teknolojilere ihtiyaç duyacağım.
• BT kabiliyetlerini (Mobil geliştirme, Alt yapı, yönetişim gibi) bu yeni organizasyonda nasıl dağıtmam gerekli. Hangi servisleri uzmanlık merkezi (CoE) olarak tutarken hangilerini ürün grupları içerisinde eritmem lazım.

Organizasyon yapısını çıkardıktan sonra yetenek, konum ile partnerlik ve dış kaynak kullanımı bileşenlerinde karar verebilecek duruma gelebilirsiniz.

Örnek; bir tekstil fabrikası giyilebilir elektronik konusunda ürünler çıkartmak istiyor ve bu tür ürünleri geliştirmesi için bir ürün grubu oluşturuyor ve BT olarak sizin de bu ürün grubu içerisine gerekli yetkinleri koyabilmenizi bekliyorlar. Analizi yaptığınızda proje yöneticisi, yazılım geliştiricileri ve analitik uzmanlarını ürün grubuna yerleştirebilirken, kritik olan IoT konusunda bir yetkinliğinizin olmadığınızı görebilirsiniz. IoT ile ilgili birçok konu için (sensör tasarımı, devre tasarımı gibi) içerde bir yetkinlik oluşturmak yerine partner arayarak organizasyonu bu şekilde tanımlayabilirsiniz veya finans sektöründesiniz ve tüm ürünlerinizi mobil/web üzerinden sunmaya karar verdiniz ve sizin için en önemli konu değişen son kullanıcı deneyimine hızla uyum sağlayabilmek. Bu durumda analizi yaptığınızda organizasyonda UI/UX yeteneğini katmanız hatta stratejik önemi olacağından da dolayı iç kaynak olarak alınması gerekeceğini daha net görebileceksiniz.

Artık BT organizasyonunun neye benzemesi gerektiğini ve mevcut durumda hangi yetkinliklerin/yeteneklerin eksik olduğunu görebilmekteyiz. Bir sonraki adımdaysa eksik yetkinlik ve yetenekleri nasıl temin edeceğinize karar vermemiz gerekmektedir. Burada sorulması gereken kritik sorular, hangi yetkinlikleri içeride tutmalıyım(insource) ve hangi yetkinlikleri dışardan temin etmeliyim. Burada unutulmaması gereken önemli bir noktaysa yetkinliğe sadece insan kaynağı olarak bakmamak aynı zamanda teknoloji partneri olarak da bakmamız gerektiğidir. Mesela veri merkezi hizmetini Azure/Aws gibi bir bulut servis sağlayıcısı üzerinden almak onları teknoloji konusunda stratejik partneriniz halini getirirken fabrikanızın enerji kullanımını optimize etmek için geliştirmek istediğimiz ML algoritmasını, kendi ekipleriniz yerine dışarıda bu konuda uzman bir ekibe geliştirme gibi çeşitli perspektiflerden de bakabilmeliyiz.

İnsan kaynağı üzerine söyleyebileceğim en önemli noktalardan biriyse mümkün olduğu kadar yeteneği tek bir insan olarak kurumunuza katmamanız yönünde olacaktır. Bu durum sürdürülebilir olmaktan uzak ve sorunlara açıktır; kişinin organizasyondan ayrılması durumunda birçok proje ve süreç ciddi olarak sekteye uğrayacaktır. Benim önerim eğer kadro veya bütçe sıkıntısı sebebiyle tek kişiyle devam etmeniz gerekliyse bu kişiyi destekleyecek bir partner bulmanız veya mutlaka kişinin yetkinliğinin içeride başka kişilere de dağılabilmesi için eğitim programlarınızı da operasyon modelinize eklemenizin gerekliliğidir.

Hatırlarsanız örneğimizde COO sizden kişi sayısını mümkün olduğunca sınırlamanızı istemişti; bu tür bir yetkinlik, yetenek ve partner haritası çıkarttıktan sonra kritik yeteneklere göre insan gücü anlamında yalın bir organizasyon kurabilir. Sizin için en kritik yetenek ve bilgileri içeride tutarken partnerlerinize diğer operasyonlarınızı yaptırabilirsiniz.

Artık yapımızın neye benzeyeceğini, kimlerle çalışacağımızı ve hangi BT kabiliyetlerine sahip olacağımızdan eminiz. Bir sonra ki adımda nasıl çalışmamız gerektiğine ve karar mekanizmalarının kurulmasına sıra geldi. Zaten organizasyon haritasına(iş ve BT) ve şirketin stratejik hedeflerine baktığımız zaman iş birimleriyle nasıl çalışmamız gerektiğine göre bir temeli rahatlıkla görebilirsiniz.
Şirketin ürün bazlı bir yapılanmaya gittiğinden bahsetmiştik; bunun BT üzerinde ki en büyük etkisi bir birinden bağımsız hala gelen grupların ürünleriyle ilgili daha sık güncelleme/yenilik talebi olacak ve daha agresif şekilde ürünlerini büyütmeye yönelebileceklerdir. Bu duruma ayak uydurabilmek için öncelikle proje/talep kabul ve backlog’unuza alma süreçlerinizle başlayıp iş birimleriyle projeleri nasıl yöneteceğiniz(Scrum, XP, gibi) temellerde anlaştığınız noktada çalışma şeklinin yarısını tamamlamış olacaksınız. Öteki yarısıysa fikirden proje/talep haline gelmiş uygulamaların nasıl geliştirileceği, daha alt yapısal ve güvenlik gibi görece statik sistemlerin nasıl yönetileceği gibi konulara karar verilmesidir.

Örneğimizden devam edersek; iş birimlerinin yeni yapısına en iyi şekilde Çevik (Agile) çalışma yöntemleriyle cevap verebileceğinizi düşünüp iç tarafta uygulama geliştirme döngünüzü sprintler halinde yönetmek mantıklı gözükmekte, ama bildiğiniz gibi BT bir birine bağlı bir sürü küçük hücreden oluşmaktadır, geliştirme döngünüz otomatik olarak daha esnek ve hızlı bir canlıya alma süreci ihtiyacı doğuracaktır. Bunu destekleyebilmesi için değişiklik süreçlerimizin yeniden yazılması ve hızlı sürüm çıkartmayı destekleyecek CI/CD yapılarının alt yapıda da kurulması gerekecektir. Tüm bunların üzerinde de bilgi güvenliğinin engelleyen, durduran ve yasaklayan metotlardan çıkıp; yol gösteren, kural koyan ve denetleyen bir yapıya dönüşmesi gerekecektir. Çalışma metotlarımızı planlarken yapılan en büyük hatalardan biride aslında budur, genelde sadece iş birimiyle veya projeler üzerine çalışan ekiplerin çalışma yöntemlerini değiştirirken onun destek aldığı alt katmanlara çok dokunulmamasıdır. Unutulmamalı ki en yavaş, katı ve kapalı ekibimiz kadar hızlanabiliriz.

Şu ana kadar yaptığımız planlama sonucunda çalışan bir organizasyon oluşturmayı başardık, talepler gelmeye başladı ve ekipler bunları hedeflenen zaman aralıklarında geliştirip hızlı bir şekilde sürümler çıkmaya başladılar. Peki, BT’yi de etkileyen birçok kararı kimler nasıl almalı, bunu konuyu hala tam olarak netleştirmedik.

Mesela ürünle ilgili bir geliştirme talebi geldi ama bunun için BT mimarisinde ciddi bir değişiklik gerekiyor, bunun onayını kim vermelidir? Ürünlerin ne zaman yeni sürümünün çıkacağına veya hangi taleplerin ne koşullarda kabul edilmesi gerektiğine karar verilebilmesi gerekiyor. Kararlar hakkında örnekler çoğaltılabilir, burada sınırları net olarak çizmek çok zor ve gri bölgeler çok fazla. Tepeden inme birçok sert kuralın uzun vadede işe yaramadığı sonuç itibariyle insanlar bir şekilde bu kuralların çevresinden dolanarak iş yapmaya başlıyorlar. Aksi durumda çok genel geçer bir yönerge çizilirse de bu sefer BT mimarisini, projeleri ve maliyetleri yönetmek imkânsız duruma gelebiliyor.  

Eğer en başında doğru bir BT kabiliyet (capability) haritası çıkartabilirsek mevcut durumda ve ileride ihtiyaç duyabileceğiniz birçok yetkinlik konusunda bir fikriniz oluşmuş olmalı, aynı zamanda insan kaynağı olarak ya bünyenizde ya da partnerleriniz üzerinden yetkinliğinizi doğru şekilde konumlandırdıysanız önceden iş birimlerinden gelecek her türlü teknik ihtiyaca cevap verebilir durumda olacağınız için her türlü mimari karar, teknoloji partnerinin seçimi ve teknik ürün seçimi konusunda önceden kural setlerini belirleyebilir veya onları doğru kanallara yönlendirebilirsiniz. Bunu anlatmamın sebebi eğer önceden bunları belirlemezseniz iş birimi bu konuda ki boşluğu kendisi doldurarak bir karar verecektir, benim önerdiğim yöntemle çalışmanızın avantajı önceden belli temellerde onlarla anlaşabilir ve onlara da vakit kaybettirmeden tüm teknik tarafta kararların sahibi olabilirsiniz.

Ürünle ilgili her türlü UI/UX, yeni sürüm sıklığı ve neleri geliştirmeye dâhil edilmesi gerektiği gibi konularda yol gösterici olabilir ama asla karar merkezi olamaya çalışmanızı önermem. İş birimine hayır demek yerine onlara seçenek sunan ama onlarında bizim teknik kararlarımıza aykırı ilerlememeleri için karar mekanizmasını bu şekilde kurmanızı öneririm.

Son olarak Finansalların ve performansın nasıl yönetilmesi konusuna değineceğim. Hatırlarsanız CFO BT’nin artan maliyetlerine bir türlü anlam veremediğini söylemişti. Gerçekte BT’nin bir maliyeti bulunmamaktadır, her iş birimi talebinin, projenin veya iş için eklenen sistemin bir maliyeti vardır. Doğal olarak finansal bir model oluştururken kataloğumuzda olan tüm servislerin bir parasal değeri olmalı ve bu değer karşılığında iş birimlerinin nasıl bir parasal değer yarattığının karşılaştırılabiliyor olması önemlidir. Mesela sizden bir BI raporu oluşturmanız istendi bu rapor için gereken iş gücü ve lisans maliyetinin 300$ olduğunu varsayalım ama raporu isteyen arkadaş bunu 1 gün ekstradan oluşturup kendisi oluştursa şirkete maliyeti 100$; sırf talebi yapan kişi daha az çalışacak diye bu raporu oluşturmalı mısınız? Bunu gösterebilmeniz ve anlatabilmeniz önemli. Başka bir örnekse mevcut e-ticaret sitenize gerçek zamanlı satış modülü eklenmesi istendi ve siz bunun için ciddi bir yatırımla beraber geliştirme süresi harcandınız. Yılsonu bilançosunda e-ticaret sitesinin ciroya oranla karlılık oranının düştüğü ve buna en büyük sebebin BT maliyeti olduğu düşünüldüğünden dolayı sizin üzerinizde maliyetleri azaltmanıza yönelik baskı hissediyorsunuz. Raporlara baktığınızdaysa talep edilen yeni özellik için harcanan maliyete karşılık iş birimi hedeflenen başarıyı elde edememiş olduğunu görüyorsunuz, bu sayede hem sonucun bu şekilde olmasının sebebinin BT olmadığını kanıtlıyor hem de üzerinizde ki maliyet baskısını bir nebze azaltabilme imkânınız oluşabilir.

Finansal model aslında BT’nin bir savunma mekanizması değildir, iş birimlerinin BT harcamalarını en yüksek fayda sağlayacak noktaya kaydırabilecekleri bir araçtır. Bu sebepten dolayı basit gözüken ama etkisinin gayet yüksek olduğu, her servis için charge-back mekanizmasının oluşturulması ve talep bazında finansal bir değere bağlayabilmek BT olgunluğunuzu çok ilerletmektedir.

Son bileşenimizse BT’nin performansını nasıl ölçmemiz gerektiği üzerinedir; şu ana kadar yaptığınız her şey aslında performans ölçümünü destekleyen aksiyonlardı. Her çalışma yönteminin kendine has bir performans ölçüm yöntemini kullanabilir, finansal gözlükle bakıp aslında t kaynak ile ne kadarlık fayda yarattığınızı ölçebilir veya iş birimlerinin taleplerine verdiğiniz tepki süresi arasında ki süreye göre(sürüm sıklığı olabilir) birçok işe dokunan KPI seçebilirsiniz. Ben genelde mimari olgunluk yani standartlara ne kadar uyuluyor, sürdürülebilir ve genişleyebilir sistemlerin sağlığı için bir KPI grubu, süreçler(Cobit olabilir) bir KPI grubu ve en önemli yaratılan değer için bir KPI grubu öneriyorum.

İlk ikisi bizim kendimizi iyileştirmemiz için önemliyken son grup iş birimlerinin bizi ölçebilmesi içindir bu KPI’ların finansal ve değer(geliştirilen yazılım sayısı olabilir) cinsinden olması gereklidir.

Araçlar ve Yer konusundaysa benim tercih ettiğim bir yaklaşım bulunmamakta, genelde yukarıda ki bileşenlere karar verdikten sonra bir şekilde doğal süreci içerisinde çözülmektedirler. Yine de operasyonunuzu yönetirken hangi araçları kullanacağınızın net bir şekilde belirlenmesi ve yaygınlaştırılması gereklidir.

Kurumsal Mimari ile Operasyon Modeli arasında ki ilişki:

Bu yazı serisinin asıl yazılma ve en kısa kısmına geldik Kurumsal Mimari yeni operasyon modelini (Target operating model) oluşturmada hem destekleyici bir öğe hem de girdi olarak kullanılabilir.

Kurumsal mimari, operasyon modeli özelinde size iki önemli bilgi sağlar öncelikle kurumunuzun şu andaki iş kabiliyetlerinden (Business capability),süreçler, veri ve teknoloji alt yapısına kuş bakışı tek ve yalın bir görünüm sunar. Bu görünüm mevcut durumu anlamanız, hangi iş kabiliyetlerine ne seviyede destek verebildiğinizi ve sistemleriniz arasında ki ilişkiyi görmenizi sağlar. Bu sayede mevcut operasyon modelimizde neleri geliştirmemiz gerektiğini görebilirsiniz. Gelecek mimarisi ile de aslında BT’nin değişen iş stratejisi ve ona bağlı işin operasyon modeliyle beraber ne tür kabiliyet, yetkinlik ve yeteneklere ihtiyaç duyacağını ön görüp. Mimari ve teknoloji standartlarını belirleyerek; bunun BT’nin mevcut yapısına nasıl bir etkisi olacağının analizini yapabiliriz. Bu çalışma özellikle Partner, Karar mekanizması, Araç, Yetenek ve Performans konusundaki modelin oluşmasında size ciddi bir girdi sağlar.

Yukarda anlattığım yaklaşım kurumsal mimarinin klasik yaklaşımıdır. Daha modern yaklaşımsa BT operasyon modelinin işin operasyon modeli tarafından tetiklenerek değişmesi yerine kurumsal mimarların bir iç danışman gibi iş birimlerine teknolojiyle nasıl fark yaratabileceklerini göstererek, stratejilerini oluşturmada onlara destek olarak, önceden doğru öngörülerle BT’ye yeni servisler katarak BT’nin sunduğu değerin işin operasyon modelini değiştirmesini sağlamaktır. Peki kurumsal mimarlar bunu nasıl yapabilir.

Operasyon modelinin hem BT hem de iş için ana girdisinin strateji olduğundan bahsetmiştik, genelde üst seviye strateji planlaması belli çerçeveler tarafından yapılır ve genelde BT stratejinin oluşturulurken her zaman bir parçası olmamaktadır. Şirket stratejisinin oluşturulması veya sadece uygulaması tarafında olsanız da proaktif davranarak tüm şirketin operasyon modelini etkilemeniz mümkündür.

Genelde şirketin stratejileri sayfalarca süren dokümanlar yerine birkaç ana maddeden oluşan hatta tek sayfaya sığdırılabilen sadece yönümüzü belirlemeye yardımcı olan hedeflerden oluşur. Mesela bir şirketin 2020 stratejisi sadece aşağıdaki maddelerden oluşabilir.

• Bu yıl maliyetleri %10 azaltacağız
• Mevcut müşterilerde derinleşmek ve yeni satış kanalları yaratmak
• Her zaman her yerden müşteriler tarafından erişilebilir servisler sunmak

Şimdi iki farklı senaryo inceleyelim. Birinci senaryoda kurumsal mimari daha geleneksel bir pozisyon almakta sadece BT içerisiyle sınırlı kalmış ve iş birimlerinin bu stratejiyi nasıl uygulayacağına dair bir oyun planı hazırlamamış/desteklememiş olsun.

Bu durumda iş birimleri yeni operasyon planlarını yaparken masraf merkezi olarak görülen BT üzerinde maliyet baskısında bulunacaklardır, bunun etkisi BT için daha az insan ve kaynakla aynı işleri düşen bir kalite ile yapmaya zorlanması demektir. BT, iş birimlerine yeteri kadar destek verememeye başlayacak ve gittikçe değerini kaybedeceği için bütçesi kısılmaya başlayacak ve sonsuz bir döngüye girecek.

Öbür taraftan iş birimlerinin yeni kanalları yaratırken dış tedarikçilere mobil/web/e-ticaret veya yeni nesil Iot, AR/VR gibi çözümleri geliştirip entegrasyon noktasında hatta bazen onda bile BT’ye gelinmeden devreye alınabilir. Özetle ne mimari ne de tedarikçi seçiminde asla BT’ye danışılmaması durumu oluşabilir. Bunun sürdürülebilirlik, güvenlik ve ileri yönelik büyümede nasıl problemler yarattığını anlatmaya başlasam sanırım ayrı birkaç yazı dizisi çıkabilir.

Müşterilerin veya çalışanların her zaman her yerden şirket kaynaklarına erişebilmesi bence harika bir yaklaşım ama genelde pratikte bu iki türlü çalışmakta. Ya işin baskısı sebebiyle birçok kritik servis dış dünyaya yeteri kadar kontrolü bir şekilde açılmaz ve ciddi bir bilgi güvenliği riski yaratır veya BT bu taleplere “hayır” demek zorunda kalırsa da, BT şirketin sevilmeyen iş yapılmasını engelleyen birimi pozisyonuna düşmüş olur. Başka bir problemse birçok servis aslında arka tarafta bulunan “system of record” katmanına bağımlı olarak çalışmaktadır ve genelde “system of record” katmanı en yeni teknolojilerden oluşmaz hatta mümkünse pek dokunmakta istemeyiz. Bu katmanlar her zaman modern entegrasyonları desteklemeyebileceğinden dolayı ya veriyi bir şekilde mobil/web servislerinin kullanabilmesi kopyalıyor veya teknik borcumuzu(technical debt) artıracak çözümlere gidiyoruz. Her iki yaklaşımının da kendine göre sorunları bulunmakta ve mümkün olduğunca kaçınılması gereken yaklaşımlardır.

Peki, bizim rolümüz burada ne olmalıdır? Hayır demek veya bu talepleri engellemek hem iş açısından hem de BT’nin varlık amacı açısından doğru bir yaklaşım değildir. BT mimarisinin, yapısının ve hedeflerininse dış etmenler tarafından bir tarafa doğru savrulması da aslında kendi içinde kısır bir döngüde olan, sınırlı değer yaratabilen, sürekli yangın söndürmeye odaklı organizasyona dönmemize sebep olmaktadır.

Kurumsal mimari tam bu noktada bizim reaktif bir yaklaşımdan çıkıp proaktif bir yaklaşıma geçmemizi sağlayarak doğru bir BT konumlandırması yapmamıza hatta iş birimlerinin çalışma şeklini etkilememizi sağlar.

Bir kurumsal mimarın oyun planı BT’nin şirket içindeki algısı ve pozisyonlamasına göre değişmekle beraber temel yaklaşımları aynıdır. Kurumsal mimarinin BT fonksiyonları haricinde ekosistemi tarayarak şirkete değer yaratacak teknoloji ve partnerlik fırsatlarını bulma, iyi uygulamaları şirket içine tanıtma, mevcut teknolojilerin/yöntemlerin iş birimlerine nasıl değer katabileceğine dair şirket içi danışmanlık faaliyetlerini yürütme gibi aksiyonlardan oluşabilir.

Mesela yukarıdaki strateji örneğine bu gözle bakıp bunu operasyon modelimize bağlayalım. İlk hedefimiz kurumsal mimari olarak şirketin maliyetlerini azaltmaksa klasik portföy rasyonelleşmesinin ve tedarikçi optimizasyonun haricinde iş birimlerinin kendi dijitalleşmesini sağlayacak servisler sunmakla başlayabiliriz, örnek vermek gerekirse son zamanlarda sıkça konuştuğumuz RPA’lerin devreye alınarak iş gücünden kazanç veya BPM servislerinin daha iyi kullanılarak şirkete kazandırabileceğimiz hızın genel giderlere etkisi olacaktır. Başka bir yaklaşımsa iş birimlerinin en çok sıkıntı yaşadığı noktalara odaklanmaktır(Pain points); mesela üretim yapan bir şirketteyseniz depo alanının optimize edilmesi, forkliftlerin minimum mesafede maksimum iş yapabilmesi veya enerji kaybının azaltılması için gerekli çözümleri bulunması, iyi uygulamaların şirketi getirilmesi önem kazanacaktır. Bu problemlerin çoğu artık bilişim teknolojileri sayesinde dijital platformlarda çözülebilir ve iş birimlerinin kendi çözümünü bulmasından önce proaktif olarak onlara alternatifleri gösterip beraber bir çözümün oluşturulmasına liderlik edilebilir.

Benzer yaklaşım diğer maddeler içinde geçerlidir, strateji maddelerine bakıldığında 3 noktayı çok iyi görebilmeniz gereklidir.

• Şirket stratejisinin doğal bir sonucu olarak birçok yeni uygulama ve dış bağlantıya ihtiyaç duyacağımızı çok rahat ön görebiliriz. Bu durumu yönetmek ve esnekliği sağlamak için bir API katmanı oluşturulması, içerde geliştirilen uygulamaların ve tedarikçilerin geliştirecekleri uygulamaları bu katman üzerinden diğer katmanlarla iletişim kurmasını sağlayabiliriz.
  API katmanı sayesinde hem sürekli değişen uygulama ihtiyaçlarına hızla cevap verebilir, dış firmalarla entegrasyonunuz kolaylaşırken bir yandan da en değerli sistemlerimiz olan “system of record” katmanına olan etkiyi ciddi anlamda azaltabiliyoruz.

• Stratejiye göre BT’nin yeni satış kanallarını destekleyecek kabiliyetlere sahip olması gerekmektedir, öncelikle genel bir kapsamda ekosistem ve endüstride ki örneklere bakıp ne tür kabiliyetlere ihtiyaç olunması gerektiğinin tespiti. Bu kabiliyetlerde ne durumda olduğumuzun analizini ve nasıl bir şekilde bu kabiliyetleri iş birimlerine sunacağınızın planlamasının daha iş birimleri tarafından projeler gelmeden önce başlanması gerekmektedir. Özellikle bu kabiliyetlerin belirlenmesi iş birimlerini doğru yönlendirmemizi sağlayacak doğru partnerler ile onları aynı masaya oturtabilir ve BT alt yapımızın istenmeyen bir noktaya sürüklenmesinin önüne geçilebilir.

• Mevcut müşteriyi daha iyi anlamak için farklı iş birimleri ve partnerlerinizde bulunan verinin konsolide edilmesi, analizi ve doğru zamanda doğruluğundan emin sonuçların üretilmesi gerekecektir. Veri yapısının değişmesi hem iş birimlerinin tepki süresini değiştirecek hem de şirketin veri odaklı bir yapıya doğru evirilmesini sağlayacaktır. Maalesef bu yazıldığı kadar kolay bir senaryo değildir, etkili bir analitik katmanının oluşturulabilmesi için öncelikle veri stratejisinin olması, veri kataloğu, veri sözlüğü, metadata/refdata gibi kavramların çalışır duruma getirilmesi gereklidir. Farklı sistemler arasında ki verinin entegrasyonundan sonra ancak bu tür bir yapı geliştirilebilir. Eğer bu tür bir iş stratejisi önünüze geldiğinizde yukardaki konularda hazırlıklı değilseniz hedefinizi tutturmanızda mümkün olmayacaktır. Bu sebepten dolayı iyi bir kurumsal mimarın iş ve teknolojideki eğilimi sürekli takip edip, hem iş birimlerini bu konuda eğitilmesine destek olmalı hem de teknik alt yapıyı sunmak için gerekli yol haritalarını yaratmalıdır.

Bu noktada hala şu soruyu sorabilirsiniz; kurumsal mimari hakkında konuştuklarımızın operasyon modeliyle ilişkisi nedir diye? Operasyon modeli bir değerin nasıl oluşturulacağının ve hedefe varmak için gerekli hayatı düzenler; Kurumsal mimarların hedefleri, iş birimlerinin isteklerini ve içlerinde bulundukları politik ortamı iyi okuyarak iş birimlerinin çalışma şekillini nasıl değiştirebileceğine odaklanması, BT’nin sürekli rekabetçi kalabilmesi için değişimini planlaması gerekmektedir.

Doğal olarak bu yaklaşım hem BT’nin pozisyonlanması hem de çalışma şeklini değiştirirken, BT’den iş birimlerine doğru değişen değer önerisi ve yeni servislerde iş birimlerini değişime doğru itecektir.

Klasik BT ile sınırlı kalmış kurumsal mimari tamamen ölmüş bunun yerine değer odaklı, değişimi kontrol eden değil tam tersine aşağıdan yukarı doğru tetikleyen bir kurumsal mimari yerini almıştır.

Okuduğunuz için teşekkür ederim.

The post BT Operasyon Modeli ve Kurumsal Mimari – Bölüm 2 first appeared on EMRE BOZLAK.

The post BT Operasyon Modeli ve Kurumsal Mimari – Bölüm 2 appeared first on EMRE BOZLAK.

Birçok şirket ve organizasyon hem teknolojinin hem de rekabetin gittikçe sertleşmesi sebebiyle, konfor alanlarından çıkıp yeni servisleri sunmakta ve iş modellerinde köklü değişikliklere gitmektedirler. Bu değişime paralel bir şekilde, şirketlerin BT organizasyonları da şirket hedeflerine varması için en uygun şekilde organize olmalı, şirket içinde doğru şekilde konumlandırılmalı ve servislerini tam zamanında ihtiyaç duyulan değere göre sunmalıdır.

Bu sebeplerden dolayı her BT organizasyonun şirket hedeflerine göre yaşayan, sürekli değişim gösteren ve en önemlisi anlaşılır bir şekilde kurgulanmış operasyon modeli olmalıdır. Genelde BT’ler operasyon modelini oluşturan bileşenleri içgüdüsel olarak veya zorunluluktan dolayı bir şekilde tanımlamaktadırlar ama bu sürecin planlanmasından hayata alınmasına kadar geçen evreleri bir disiplin çerçevesinde yürütmemektedirler.

Operasyon Modeli Nedir:

Operasyon modeli adından da anlaşıldığı üzere bir organizasyonun değer yaratmak için neler yaptığı ve neleri kullandığını gösteren bir modeldir. Aşağıdaki şekilde de inceleyeceğiniz üzere, Operasyon Modeli, stratejimiz ile işleri nasıl hallettiğimiz yani gerçek hayat arasındaki köprüdür ve stratejinin belirlediği aksiyonların nasıl yürütüleceğini belirlemede kullandığımız araçlardan biridir.

Maalesef, günümüzde birçok şirketin BT organizasyonları yeni teknoloji ve servisleri devreye alırken veya organizasyon yapılarında köklü değişikliklere gidip yeni rolleri eklerken çalışma şekillerini doğru şekilde değiştirmedikleri veya ihtiyaç duyulduğu anda gerekli kabiliyetlere sahip olamadıkları için iş birimlerine hedeflenen katkıyı sağlayamıyor, değer üreten bir birim olarak kendini konumlandıramıyor.

BT Operasyon Modelimi neden değiştirmeliyim?

Dijitalleşmenin getirdiği yeni BT kabiliyetlerinin (IT Capability) nasıl kazanılması gerektiği konusu, BT ve operasyonel teknolojilerin artık hiç olmadığı kadar iç içe geçmesi, çevik ve çoklu disiplinlere sahip organizasyonlara doğru everilmemiz sebebiyle klasik operasyon modelleri artık sürdürülebilir olmaktan çıkmıştır. Artık kontrolden çok karar vermeyi destekleyecek, maliyet ölçümünden çok yaratılan değerin ölçüldüğü ve her şeyi kendi başına halletmek yerine doğru zamanda doğru kaynaklara erişebilecek bir modele ihtiyaç duyulmaktadır.

Birçok BT organizasyonunu incelediğimizde olması gereken ile (mevcut OM’de olan) gerçekte olan çalışma şeklinin birbiriyle örtüşmediği veya BT’nin değer önerisi ve ortaya koyduğu yetkinliklerle işin ihtiyaçlarını karşılayacak esneklik ve yetkinlikler arasında bir fark olduğu görülmektedir.

Bunlara ek olarak, kişisel gözlemlerimde de gördüğüm mevcut BT modelleri, BT dışındaki grupları yani iş birimlerini çok fazla kapsamamakta bu da özellikle yeteneğin kazanılması yani insan kaynağı, karar noktaları ve finansın yönetilmesi gibi konularda sıkıntı yaratmaktadır. Mevcut rekabet koşullarında iş birimleri mümkün olduğunda yeni kabiliyetleri elde etmek hatta birçok konuda BT’den otonom şekilde hareket edebilmek arzusundalar. Bu anlaşılabilir bir refleks olsa da uzun vadede yarattığı “Shadow IT – Gölge BT” şirkete daha büyük zarar getirmektedir. Bu sebepten dolayı BT operasyon modelini tüm şirketi kapsayacak şekilde planlayıp hangi kontrollü bir otonomluk sağlanması veya hangi noktalarda nasıl davranılacağının keskin hatlarının çizilmesini de sağlamaktadır.

Birkaç örnek üzerinden devam edelim.

• Bu senaryomuzda, satış departmanlarından biri yeni satış kanalları oluşturabilmek için mobil uygulama geliştirmek istiyor ve bunu bir dijital ajansa yaptırma planları olduğunu varsayalım.
• Başka bir senaryoda; müşteri yönetim ekibi müşteri eğilimlerini daha iyi analiz yapabilmek önceden piyasayı tahmin ederek doğru aksiyonları olabilmek için ekiplerine birkaç tane veri bilimcisi (data scientist) alıyor veya mevcut kullandıkları CRM’i bulut bazlı bir CRM ile değiştirmeğe karar verdiler.

Mesela bu senaryolarda ajansın nasıl seçileceği, mimarinin nasıl olacağı, hangi teknolojilerin kullanılacağı gibi kritik kararların verilmesinde BT ne kadar etkin veya sizin önünüze proje bittikten sonra mı geliyor? Her ne kadar veri bilimcileri iş birimleri içerisinde olsa da BT kaynaklarına (web servisleri, API, veri tabanları gibi) erişecekler ve geliştirdikleri uygulamaların bir yaşam döngüsü olacaktır. BT’nin dışında olsalar bile BT ile bu kadar içli dışlıyken sizin bu kişilerin seçimi, uygulama geliştirme standartlarının belirlenmesi veya kaynakların nasıl kullanılacağı konusunda sınırlamalar belirlemeniz gerekmiyor mu?

Artık bu sebeplerden dolayı operasyon modeli, sadece BT içerisinde sınırlı kalamaz ve bu nedenle de tüm şirketi kapsayacak şekilde genişletilmelidir. Tüm organizasyonda hedeflenen inovasyon, esneklik ve rekabet gücünü sağlayacak şekilde tekrardan konumlanmalıdır.

BT Operasyon Modelinin yapısı nasıl olmalıdır?

Operasyon modelinin oluşturulması, gösterilmesi ve ölçümüyle ilgili endüstride kabul edilmiş birçok farklı yöntem bulunmaktadır. Hangi modelle çalışırsanız çalışın temelde aynı bileşenlere sahiptirler. Ben bu yazı dizisinde kendimin de en çok hâkim olduğu ve daha önce çalıştığım Gartner’ın yapısını baz alarak bazı noktaları anlatacağım. Gartner’a göre bir BT operasyon modeli aşağıdaki bileşenlere sahip olmalıdır.

• Finansallar (Financials): BT bütçesinin ne kadar ve kimin kontrolünde olması gerektiği, yatırım kararlarının nasıl verileceği, bütçenin nasıl izleneceği ve şirket hedefleriyle uyumlu finansal yatırımların nasıl yapılması gerektiğine dair kurallar bütünüdür. Bu konu aynı zamanda BT’nin sunduğu hizmeti nasıl ücretlendirmesi (Chargeback mekanizması) gerektiğini planlayabilmesi içinde önemlidir.
  Birçok BT organizasyonu aşağıdan yukarı doğru toplama yöntemiyle yıl başında bir bütçe belirliyor ve bu bütçe içerisinde kalmaya çalışarak hem iş birimlerine destek olmak hem de sürekli değişen bir ortamda gemilerini yürütmeye çalışıyorlar. Buradaki temel sorun iş biriminin bütçeye katkısı veya stratejik önemiyle aynı oranda bir efor harcıyor muyum veya iş birimi BT’ye harcattığı efor karşılığında ne kadarlık bir değer yaratabiliyor sorularının net bir şekilde cevaplanamamasıdır. Düzgün bir Chargeback mekanizmasının kurulmasıyla beraber BT’ler doğrudan iş birimleri hatta proje ve operasyonel işleri için bile ne kadarlık bir maliyet yaratmışlar gösterebilme yeteneğini kazanırlar.
  Bu sayede aşağıdaki kazanımlar ortaya çıkmaktadır;
  • BT’nin harcadığı efora karşılık iş biriminin ne kadarlık bir değer yarattığının ölçümü
  • Kaynakların doğru inisiyatiflere, teknolojilere ve birimlere aktarılması
  • BT’nin bir masraf merkezi olduğu algısının kırılması ve değer odaklı bir merkeze doğru evirilmesi.
  • İş birimlerinin yeni proje veya taleplerde bulunurken doğru bir maliyet/fayda analizi yapabilmesinin sağlanması.

• Karar hakkı (Decision Rights): Organizasyon içerisinde kim, neye ve nasıl karar vereceğinin belirlenmesidir. Mesela BT mimarisiyle ilgili bir karar alınması gerektiğinde bunu uygulama ekipleri kendileri alabilir mi yoksa merkezi mimari ekibe mi danışılmalı, iş birimleri kendi ihtiyaçlarına uygun “3rd party” bir uygulama satın alabilir mi? Dağıtık bir şirket yapısındaysanız bir hizmete ihtiyacınız olduğunda bunu merkezden mi sağlamalısınız yoksa kendiniz yaratabilir misiniz? Bu tür soruların cevaplarını verebilmek ve bu kritik kararlarda kimin yetkili olduğunun belirlenmesini sağlar. Bu kural setinin belirlenmesi hem işlerin daha hızlı akmasını sağlar hem de ileride oluşabilecek çeşitli yanlış anlaşılmalarla sürtüşmelerinde önüne geçebilmektedir.
  Mesela şirketinizin çevik (agile) dönüşüm geçirdiğini ve ürünler bazında chapter’lara böldüğünü varsayalım; her chapter’ın kendi teknik lideri nelere karar verebilmeli, mesela kendisi uygulamada bir fırsat gördü ve daha önce şirket içinde kullanılmamış bir teknolojiyi kullanmak istiyor buna izni var mı? API’ların döndüğü cevapları standarttın dışında bir çıktı kullanabilir mi? Product owner’lar istedikleri tedarikçi çalışmayı tercih edebilir mi veya ürünün özellikleriyle ilgili gerçekte ne kadar karar sahibi olmalılar.
  Eğer büyük bir kurumsal yapı içerisinde, otonom çevik ekipler kullanmak istiyor bir yandan da hedefe doğru mimari ve ürünlerle gidebilmek istiyorsak bu kural setlerinin belirlenmesi hayati önem taşımaktadır.
  
• Performans (Performance): Adından da anlaşıldığı üzere BT organizasyonunun performansının nasıl ölçüleceğinin belirlenmesidir. Burada en önemli nokta şirket stratejisine uygun KPI’ların belirlenmesidir mesela iş birimlerinin dijitalleşmesine destek verilmesi beklenirken bütçe/süreç optimizasyonuyla ilgili KPI’ların ağırlıkta olması çok anlamlı olmayacaktır. Aynı zamanda BT’nin siloları için ayrı ayrı KPI’lar belirlemenin yanında bir bütün olarak yarattığı değeri ölçebileceğiniz KPI’ların olması önerilir.
  Örneğin;
  • Yeni Ürün/sürüm çıkartma sıklığı
  • Dijital kanalların rakiplere göre olan performansı ve teknik üstünlüğü
  • Kullanıcı deneyiminin iş performansına etkisi ve son kullanıcı mutluluğu
  • İş birimlerinin yeni kanal ve iş modelleri yaratabilmeleri için sunulan yeni teknolojiler ve süreçlerin dijitalleşmesi (Self-service portal, RPA, Chatbot, VR/AR araçları gibi). Bunların doğrudan ciroya olan etkisi.

• Organizasyon yapısı (Organizational structure): BT organizasyon yapısı nasıl olmalı, iş birliği nasıl sağlanmalı ve kritik kaynaklar arasındaki ilişki nasıl kurulmasıyla ilgili tüm bileşenler bu başlık altında toparlanır. Yukarıda değindiğim çevik organizasyon ile ilgili örneğinden devam edersem; şirketi ürünler bazında böldüğümüz durumda BT’de kendini ürünler bazında çalışma gruplarına bölmesi beklenmektedir. Peki her grup içerisinde kimler bulunmalı, bunlar normal şartlarda hiyerarşik olarak kime bağlı olmalı, gruplar içerisinde dağıtılamayan alt yapı, güvenlik ve yönetişim ekipleriyle bu yapıların ilişkisi nasıl olmalıdır gibi soruların cevabını verdiğimiz kısımdır.
  
• Çalışma yöntemleri (Ways of working): Aslında BT’nin ve doğal olarak onunla çalışan partner ve iş birimlerinin nasıl çalışacağının belirlendiği katman. Burada şirketinizin kendi metotları/süreçleri olabileceği gibi endüstri tarafından kabul edilmiş standartlarda kullanılıyor olabilir. Mesela fikirlerin kabul edilip projeye dönüştürülmesi için gerekli kabul ve geçiş süreçlerini içeride geliştirirken, BT’nin performansını Cobit’e göre ölçüyor olabilirsiniz. Projenizi sprintler halinde yönetip, CI/CD sayesinde hızla yeni sürümlere geçiyor olabilirsiniz. Burada önemli olan işin ihtiyaçlarına göre doğru yöntemi belirleyebilmenizdir. Her ihtiyaç düşünülenin aksine çok sık yeni uygulama özelliklerine ihtiyaç duymazken, fikirden proje aşamasına geçişte her şirketin kendi kabul koşulları birbirinden farklılık gösterecektir. İşin ihtiyacını net olarak anlayarak ona göre bir yöntemler belirlenmeli, paydaşlarla el sıkışılmalıdır.
  
• Konum (Places): BT, iş birimleri ve partnerler fiziksel olarak nerede konumlanacak. BT ve iş birimi ayrı ofislerde/binalarda çalışıp birbirlerinden izole mi çalışacak yoksa iş birimi ve ona hizmet eden BT fonksiyonları aynı ofiste mi bulunmalı? Outsource ettiğiniz hizmetlerin veya dışarıdan aldığını danışmanlık hizmeti nasıl ve nerede bulunmalı gibi konuların netleştiği yerdir. Artık iş birimleriyle onlara doğrudan hizmet veren ürün grubunun yazılım geliştiricileri, proje yöneticileri gibi BT fonksiyonlarını bir arada tutma eğitimi bulunmakta ama genelde alt yapı, UI/UX tasarımcıları, güvenlik veya test ekipleri gibi paylaşımlı kaynakların nasıl konumlanacağı gibi sorular yeni modellerde sıklıkla atlanmaktadır.
  
• Yetenek (Talent): İnsan kaynağı, ihtiyaç duyulan insan kaynağını organizasyonun nasıl ve ne şekilde bulabileceği, çekeceği ve bünyesine alabileceği gibi konulara eğilir. Bu insanların ne tür bilgi ve birikime sahip olması beklenmektedir, şirket içerisinde nasıl konumlandırılmalıdır gibi sorulara da cevap verebilmelidir
  .
• Partnerlik ve dış kaynak kullanımı (Sourcing and alliances): BT organizasyonlarının ihtiyaç duyduğu hem teknoloji hem de dış insan kaynağını nasıl tedarik ettiği, neleri dışarıdan alıp ne tür kaynakları içeride bulunduracağı/geliştireceği konularının değerlendirilmesidir. Tedarikçi yönetimi, yeni partner ve tedarikçilerin seçim yöntemine dair prensipler ve yönlendirmeler bütünüdür. Benim özellikle çok önem verdiğim bir konu olduğunu söylemek isterim. BT’ler her fonksiyonu kendi içinde bulundurup tek bir insan veya yetersiz kaynaklarla departmanları döndürmek yerine asıl fark yaratacakları konulara yönelip, temel yeteneklerine odaklanmalı; gerekli dönüşüm ve teknoloji desteği için doğru partnerleri kullanmayı öğrenmelidir.
  
• Araçlar (Tools): BT’nin hedeflediği değer önerisini sağlayabilmesi ne gibi araçlara ihtiyacı bulunuyor sorusunun irdelenmesidir. Bunu şu anda kullandığımız servis masası uygulamasından tutunda, CMDB ve proje yönetim araçlarına kadar genişletebilirsiniz. Bazı firmaların ihtiyaçlarına göre bu uygulamalar RPA’ler, test uygulamaları veya container teknolojisi de olabilmektedir. Buradaki liste tamamen sizin hedeflerinize göre değişmektedir.

Gartner’ın modeli haricinde başka modellerde bulunmakla beraber içerik olarak birçoğu hemen hemen aynıdır.

Bir Operasyon Modelinin nasıl tasarlanması gerektiği ve kurumsal mimariyle olan ilişkisine bir sonraki yazımda değineceğim.

Okuduğunuz için teşekkür ederim.

The post BT Operasyon Modeli ve Kurumsal Mimari – Bölüm 1 first appeared on EMRE BOZLAK.

The post BT Operasyon Modeli ve Kurumsal Mimari – Bölüm 1 appeared first on EMRE BOZLAK.

Öteki önemli değişimse vRA 7 ortamının kurulum adımlarıdır, vCAC 5.x’dan beri kullanmaktayım ve her zaman kurulumu tam bir sinir harbi olmaktaydı. vRA 7’inin kurulumuna başlarken ürünün beta olmasından kaynaklı çok ciddi sorunlar yaşayacağımı sanırken inanılmaz kolay ve hiç sorunsuz bir kurulum gerçekleştirdim. Açıkcası şaşkınlığımı hala atlatabilmiş değişim

Gözüme batan son önemli değişiklikse Application Services(directory) farklı bir appliance olarak kurulmamakta tam tersine gömülü olarak appliance ile gelmektedir.

Eminim ürün GA olarak yayınlandığında daha bir çok özelliğini öğrenebileceğiz. Bu yazıda vRA 7’nın bir beta versiyonunu kuruyor olacağım, ürünün sizde ki beta versiyonu veya GA versiyonunda bazı adımları farklı olabilir ama genel hatlarının değişeceğini sanmıyorum. Kurulumu minimum tutmak için bir adet IaaS olarak kullandığım Windows 2012 R2 sunucusu ve aynı sunucu üzerinde MsSQL 2014 kullandım. IaaS ile ilgili yapmanız gereken en önemli ayar ntp’lerin tanımlanmış olması ve MsSQL sunucusunda(bizim senaryomuz için IaaS) MSDTC ayarlarının mutlaka yapılmış olmasıdır. MSDTC ayarları aşağıda ki gibi olmalıdır. Ms DTS için ekran görüntüsünde gördüğünüz üzere Component Services üzerinden Local DTC’nin özelliklerine girerek ayarları kontrol edebilirsiniz.

İlk adımda tüm Vmware ürünlerinde olduğu gibi OVF’i uygun bir yere yüklüyor; gerekli DNS ve network ayarlarını yapıyoruz, burada önemli bir tüyo vermem gerekirse mutlaka verdiğiniz ip ve hostname için DNS’de bir kayıt oluşturmayı unutmayınız.

OVF’nin yüklenmesi bitince ve vRA(vCAC)’nın daha önce ki versiyonlarında olduğu gibi Appliance Control paneline root kullanıcısıyla girip ilk kurulumu yapmanız gerekiyor.

Appliance Control paneli için

https://<vRA ip adres>:5480

Giriş yaptığımızda ise bir popup açılarak size kurulumu nasıl yapmak istediğinizi soracaktır. Buradan sonrasıysa yeni kurulum ekranıyla devam etmekte.

Bir sonraki adımdaysa minimum kurulum mu yapacağınızı yoksa daha kompleks yapılara uygun olarak servisleri dağıtık ve HA olarak mı kurmak istediğinize karar vermemizi istiyor. Ben bu kurulumu “minimal” olarak yaptım. Minimal kurulumda tüm IaaS servislerini(IaaS Web services,DEM,MMD..gibi) tek bir sunucuya kuruyor ve vRA appliance’ını single mode olarak çalıştırıyor.

Enterprise deployment’ta vRA appliance’ı isterseniz HA kurabileceğiniz gibi servisleri de farklı sunuculara kurabilirsiniz.

Bir sonraki adıma geçtiğinizde devam etmeden önce IaaS’ımıza vRA 7 agent’ını kurmamız gerekmektedir. Bu agent sayesinde vRA appliance IaaS üzerinde ki tüm kurulumları ve ayarlamaları kendisi yapabilecektir. Kurumu oldukça basit ve eski versiyonlarda ki DEM ve Agent kurulumuna benzemektedir.

İkinci adımda vRA appliance’ın FQDN’ini yazmamız ve portunu eklememiz gerekmektedir.

Bir sonraki adımda Management Agent’in çalışacağı kullanıcıyı belirliyoruz, agent bir Windows servisi olarak çalışacaktır, bu sebepten dolayı Administrator grubuna ekli bir kullanıcıyla servisi çalıştırmayı öneririm.

Agent’i kurduktan sonra Windows servislerinden çalışıp çalışmadığını kontrol ediniz. Kurulum ekranına geri döndüğünüzde aşağıda ki gibi bir ekranın sizi karşılaması gerekmektedir. IaaS Hostname kısmında biraz önce agent’ı kurduğunuz sunucunun hostname’i bulunmalı. Burada önemli nokta Time offset’in çok fazla olmaması, ben resmi bir sayı bulamadım ama Windows sunucuları için genelde 300 saniye gibi bir değerdir. Eğer offset çok fazlaysa hem appliance için hem de Windows sunucu için seçili ntp’leri kontrol ediniz.

Başka bir önerimse Appliance için “Time sync” seçeneğini “time server” olarak seçmenizdir.

Bir sonraki adımsa vRA 6.x versiyonlarından hatırlayacağınız Prerequisite checker aracıyla ama bu sefer güzel bir özellikle beraber gelmektedir. Gerekli kontrolleri yaptıktan sonra eğer sorun bulursa sizin için gerekli düzenlemeleri yapmaktadır. Önce Run diyerek sistemi taramasını sağlayalım bu işlem 5-10 dk kadar sürebilir.

Daha sonra bulduğu sıkıntıları fix tuşuna basarak onarmasını sağlayalım, bu esnada IaaS’ı birkaç kere yeniden başlatabilir.

Sonra ki adım vRA appliance’ının hostname’ini ayarlamak. Buraya FQDN’i yazmanızı öneririm. Resolve Automatically derseniz DNS kayıtlarında ne geçerliyse onu yazar.

SSO administrator hesabını yaratalım.

Bu adımlardan sonra IaaS component’lerinin ayarlarını yapmamızı isteyecek, sırayla MsSQL

DEM servisi, burada agent’ı kurarken kullandığımız kullanıcı adını girmemiz gerekmektedir.

Aynı şekilde Agent için de bilgileri girelim. Tekrar tekrar hatırlatmam gerekmektedir ki hala Agent adı olarak ne koyarsanız vRA endpoint yaratırken aynı isimle yaratmanızı istemektedir. Bu sebepten dolayı asla Agent’ın adını unutmayınız

SSL’lerimizi yaratalım.

Artık son adım da ayarlarımızı “Valide” edelim ve her şey yerli yerindeyse kuruluma başlayalım.

Kurulum tamamen otomatiktir ve Validation kısmında bir sorun çıkmamışsa kurulumu sorunsuz tamamlayacaktır.

Tüm işlemler bu kadardır, eski kurulumlarla karşılaştırdığımda açıkçası çok başarılı bir iş yapıldığını söyleyebilirim.

Okuduğunuz için teşekkür ederim.

The post vRealize Automation 7 first appeared on EMRE BOZLAK.

The post vRealize Automation 7 appeared first on EMRE BOZLAK.

vRealize Automation Center herhangi bir kaynağa(vsphere,hyper-v,aws,orchestrator….gibi) endpointler üzerinden ulaşmaktadır. Siz bir talepte bulunduğunuz zaman IaaS server ilgili kaynağın proxy’si üzerinden bağlanır. Her kaynak farklı bir proxy’e sahiptir.Proxy’ler IaaS üzerinde veya başka bir sunucuda olabileceği gibi bir sunucuda birden fazlada Proxy bulunabilir. İlk önce proxy’i kuracağımız sunucu üzerine “IaaS installer’ı” indirelim ve Administrator olarak çalıştıralım.

İlk ekranda vRA appliance’ı için daha önce belirtmiş olduğumuz root kullanıcısı ve şifreyle giriş yapalım. Sonra ki ekranda sırayla “Custom Install” ve aşağıda açılan panelde “Proxy Agents” seçeneğiyle devam edelim.

Bir sonra ki ekransa kendini gayet açıklamaktadır. Agent type olarak kullanmak istediğiniz kaynak türünü seçiniz. Agent name ise Windows service altında hangi isimle görüneceğidir, sonraki iki satıdaysa IaaS sunucunuz ve Model manager’ın adreslerini vermeniz gerekmektedir eğer benim yaptığım gibi IaaS rollerinin hepsini tek bir sunucuya kurduysanız her ikisi de aynı olacaktır.

Endpoint kısmıysa en önemli seçenek, Endpoint’e verdiğiniz isimle vRA portali içerisinden yaratacağınız endpoint’in ismi aynı olmalıdır aksi takdirde kesinlikle çalışmayacaktır. Tüm bilgileri doldurduktan sonra kurulumu gerçekleştirebilirsiniz.

Tüm bu işlemleri yaptıktan sonra son adımda portal üzerinden yeni bir endpoint tanımlamak ve ulaşmak istediğiniz kaynağın adresini yazmaktan ibarettir

The post vRA Ek Endpoint Tanımlamak first appeared on EMRE BOZLAK.

The post vRA Ek Endpoint Tanımlamak appeared first on EMRE BOZLAK.

Big data, Advanced analytics, Cloud computing, IoT, augmented reality veya 3d printer gibi kavramlar artık sadece B2C veya dijital işletmeleri değil görece olarak daha muhafazakar olan üretim, madencilik ve enerji gibi sektörleri de dönüştürmeye başladılar. Bu dönüşümü başta Alman hükumeti olmak üzere bir çok kaynak Endüstri (Industry) 4.0 olarak adlandırmaktadır.

Eğer ağır sanayi veya madencilik sektöründeyseniz ham maddenin en verimli şekilde kullanılmanın önemini ve hatalı üretimi azaltacak yöntemleri her zaman arıyorsunuzdur. Bu noktada IoT, big data ve advanced analytics size fazlasıyla yardımcı olacaktır.

Birçok fabrika ve maden; üretim süreçlerinin her safhasına IoT cihazlarını dahil ederek gerçek zamanlı verileri toplamakta ve analiz etmektedirler. Arka taraftaki big data ve analiz uygulamaları tüm anormalileri, insanların fark edemediği malzeme ve ortam değişimlerini veya üretim hatalarını anında fark ederek bir sonraki safhaya geçilmeden düzeltilmesini sağlıyor veya süreçlerini tekrardan düzenleyerek zamandan/malzemeden tasarrufu sağlıyorlar. Örnek olarak bu yapı sayesinde bir madencilik firması çıkartılan ürünün işlenmesi sırasında sistemin gereğinden fazla oksijen aldığını fark etmiş ve bu hatayı düzelterek malzeme kaybını azaltmayı başararak, yıllık 20 milyon dolara yakın bir kazanç elde etmektedirler. Başka bir ilaç üretim tesisiyse malzemelerinin saflık derecelerini sürekli yakından izleyerek müşterilere hatalı mal gönderimini azaltmakta ve bu sayede hem müşteri memnuniyetini artırırken müşteriden daha az ürünün geri dönmesinden dolayı karlılık oranları da artmaktadır.

Bu yapıyı kurarken üretim planlama veya kalite kontrol birimlerinin kendilerini köklü olarak değiştirmelerine bile gerek yoktur. Eğer organizasyonunuz lean veya six sigma kullanıyorsa bu yapı onların alışkın oldukları yöntemi değiştirmek yerine tam tersine desteklemektedir, daha çok veri, daha iyi işlenmiş bilgi ve görselleştirme daha doğru sonuçlar elde edilmesini sağlamaktadır.

Başka bir yaklaşımsa üretim bantlarının bulut bilişimdeki gibi kısa süreli olarak başka firmalara kiralanması ve müşteri için özelleştirilmiş ürünlerin üretilmesidir. Bu fikirler yeni olmamakla beraber güncel teknolojilerle uygulanabilirliği kolaylaşmıştır. Üreticiler direk müşteri veya 3. parti firmaların sipariş sistemleriyle entegre olarak istek anında üretime başlayabilecekleri gibi ekosistemlerinde bulunan başka bir üreticiye veya müşteriye en yakın üreticiye otomatik olarak yönlenmesini sağlayabilirler. Başka bir artısıda müşterinin kendi ihtiyaçları doğrultusunda özelleştirdiği tasarımın 3D printerlar sayesinde artık üretim bandında ciddi değişikler yapılmadan üretimine başlanmasıdır.

Bir üretici artık merkezi bir fabrika bulunmanın yanında müşterilerine yakın küçük tesisler bulundurarak talep anında otomatik üretime başlayabilir. Bu sayede üreticiler lojistik ve depolama maliyetlerini düşürürken müşteriye daha hızlı bir şekilde ürünlerini teslim edebilirler.

Son olarak Augmented reality değinmek istiyorum. Augmented reality ve giyilebilir elektronik ürünleri üretim sektöründe kalite kontrolü,envanter, montaj ve iş makinelerinin bakımı gibi görevlerde kullanılabilirler. Mesela bir motor parçasının onarımı esnasında motorla ilgili teknik bilgilerin canlı olarak görüntü üzerinde gösterilmesi, sorunlu parçaların işaretlenmesi veya bir depoda aranan parçanın nerede olduğunun işaretlenmesi gibi kullanım yerleri bulunmaktadır.

Endüstri 4.0 akımı bu yazıya sığdırılamayacak kadar geniş ve kompleks bir konudur. Teknolojinin sadece IT ile olan kısımları haricinde bir çok dalını ve yeni iş modellerini de kapsamaktadır. Artık yeni nesil endüstride üretim kapasiteleri ve kalite standartları kadar sahip olunan veri ve veriden elde edilen bilginin ne kadar iyi olduğunda önem kazanmıştır. Mevcut kaynakların daha iyi kullanımından tutun, müşteride derinleşme ve yeni hizmetlerin yaratılmasına kadar tüm ihtiyaçlarımız bilgiden geçmektedir. Bu sebepten dolayı daha geleneksel yapımızdan çıkıp bilgi şirketlerine doğru kaymamız şarttır.

Okuduğunuz için teşekkürler.

The post Endüstri 4.0 first appeared on EMRE BOZLAK.

The post Endüstri 4.0 appeared first on EMRE BOZLAK.

Bunun sebebi SRM servisinin state’i ile veritabanı statelerinin tutmamasından veya SRM’in belli state tablolarını değiştirip ötekileri değiştirememesinden kaynaklanmaktadır. Semptomlar arasında Protection Groupların state’inin “Test complete” veya “Test in progress” gözükmesi, Recovery Planlardan hiçbirinin çalışıyor gözükmemesine rağmen tüm planların inaktif olması bulunmaktadır.

Aşağıdaki çözüm SRM 5.5 ve vCenter 5.5 için denenmiştir başka versiyonlarda nasıl tepki vereceği bilinmiyor. Bu işlemleri gerçekleştirebilmek için SRM ve vCenter sunucularında admin olmak aynı servislerin DB’lerinde değişiklik ve kayıt silme işlemlerinin yapılabilmesi gerekmektedir.

Böyle bir durumla karşılaşıldığında yapılabilecek adımlar aşağıdaki gibidir:

Servisleri yeniden başlatmak

Bu adımları aşağıdaki sırayla yapmanız önemlidir.

1)Protection ve Recovery site’da bulunan SRM servislerini kapatın.
2)Her iki taraftaki vCenter servislerini yeniden başlatın
3)Her iki taraftaki SRM servislerini yeniden açın.

PowerCLI ile SRM Recovery Plan Cleanup komutunu çalıştırmak

Yukarıdaki adımlar işe yaramazsa SRM API’si üzerinden SRM’e cleanup sinyali yollanabilir. SRM API’sine powercli ile bağlanmak için gerekli olan minimum powercli versiyonu 5.5 r2’dir.

İlk önce SRM sunucunun bağlı olduğu vCenter’a daha sonrada SRM sunucusuna bağlanalım.

Connect-VIServer “vcenterhost” –User “Emre” –Password “Pa$$W0rd”
$srmServer=Connect-SRMServer –SrmServerAddress ”srmServer1” –User “DRuser” –Password “Drpass”

Burada önemli olan SRM bağlantısını bir değişkene atanmasıdır. Daha sonra bu connection string içerisinden methodlar çağrabilmemiz için aşağıda ki komutu giriyoruz.

$srmMan = $srmServer.ExtensionData

Bu komutun çıktısı recovery planların moef id’sini verecektir eğer hangi recovery planı olduğunu bilmiyorsanız “GetInfo()” method’duyla tek tek bakabilirsiniz.

$srmMan.Recovery.ListPlans()[0].GetInf0()

Bu komut hem daha kullanıcı dostu bir çıktı verecektir hem de Recovery planın durumu hakkında sizi bilgilendirecektir. Şu anda tüm Recovery planların durumu “Error” olarak gözükmektedir. İndeks sayısını değiştirerek doğru recovery planı bulalım.

Bir Recovery planın 5 durumu olabilir bu durumların neler olduğu ve nasıl kullanıldığı hakkında ilgili yazıyı okuyabilirsiniz. Biz aşağıda Cleanup state için “2” kullanıyoruz.

$failover = New-Object VMware.VimAutomation.Srm.Views.SrmRecoveryPlanRecoveryMode
$failover.Value__ = 2

Ve bulduğumuz recovery planın cleanup state’ini çalıştırıyoruz.

$srmMan.Recovery.ListPlans()[0].Start($failover)

vCenter üzerinden baktığımızda cleanup görevinin çalıştığını görmemiz gerekiyor eğer göremiyor veya başka bir görev tarafından kullanıldığına dair bir uyarı görürseniz vCenter ve SRM veri tabanlarından stateleri elle değiştirmeniz gerekmektedir.

SRM ve vCenter veri tabanlarından taskların silinmesi

Bu işlemleri vCenter için her iki tarafta SRM için sadece bir yerde yapmanız yeterlidir.

Önemli not: Aşağıda ki adımları yerine getirmeden önce mutlaka veritabanlarının yedeklerini alınız

vCenter veri tabanına girelim. “VPX_Task” tablosu içerisinde “DescriptionID” değer “com.vmware.vcDr.dr.recovery.RecoveryManager” olan ve “Complete_state” değeri “running” olan değerleri sorgulayalım.

Select * from [VCDB].[VMW].[VPX_Task] where [DESCRIPTIONID] LIKE ‘com.vmware.vcDr.dr.recovery.RecoveryManager%’ and where [Complete_state] = ‘Running’

Şu anda vCenter’a SRM tarafından gönderilen ve hala çalışan görevleri göreceksiniz. Bunların vCenter tarafından gerçekten kullanılmadığına emin olun ve her iki taraftanda silin.

Delete  FROM [VCDB].[dbo].[VPX_TASK] where [TASK_ID] = '<taskid>'

SRM’in veri tabanına girin ve “pdr_protectiongroup” tablosunu açalım, bu tablo tüm protection gruplarının ve durumlarının tutulduğu yerdir. Burada “state” kolonunun “6” olması gerekmektedir eğer farklı bir değerse değiştiriniz.

SRM ve vCenter’ı yeniden başlatıp biraz bekleyiniz. Her iki taraftaki DB eşitlendikten sonra tekrar SRM plugin ile giriş yaptığınızda herşeyin düzelmiş olduğunu göreceksiniz.

Umarım yardımcı olabilmişimdir

The post SRM – Recovery Test/Cleanup/Cancel Tuşunun Gelmemesi first appeared on EMRE BOZLAK.

The post SRM – Recovery Test/Cleanup/Cancel Tuşunun Gelmemesi appeared first on EMRE BOZLAK.