DevOps

menu icon

DevOps

DevOps, yazılım geliştirme ve BT operasyonları ekiplerinin işlerini birleştirip otomatikleştirerek daha yüksek kaliteli yazılım sağlanmasını hızlandırır.

DevOps nedir?

Tanımı gereği DevOps, genellikle birbirinden ayrı veya silolar halinde gerçekleştirilen geliştirme ve BT operasyonları ekiplerinin gayretlerini otomatikleştirerek ve bütünleştirerek, daha yüksek kaliteli yazılımların sağlanmasını hızlandıran bir yazılım geliştirme süreci ve organizasyonel kültür geçişini ana hatlarıyla belirler.

Pratikte, en iyi DevOps süreçleri ve kültürleri; tüm uygulama paydaşlarından gelen girdileri yazılım geliştirme yaşam döngüsüne dahil etmek için geliştirme ve operasyonun ötesine geçer. Paydaşlar; platform ve altyapı mühendisliği, güvenlik, uygunluk, yönetişim, risk yönetimi, iş kolu, son kullanıcılar ve müşterileri içerir.

Birkaç ayda, hatta yılda bir gerçekleşen, devasa uygulama geneli kod yayınlarından; her gün veya günde birkaç kez olacak kadar sık yayınlanan yinelemeli, daha küçük özellik ya da işlev güncellemelerine kadar, son 20 yıldan fazla bir süre boyunca yazılım sağlama döngülerinin yaşadığı değişimin şu anki durumu, DevOps tarafından temsil edilir.

Nihayetinde DevOps, yazılım kullanıcılarının sık, inovatif yeni özelliklere ve kesintisiz performans ve kullanılabilirliğe yönelik sürekli artan taleplerini karşılamakla ilgilidir.

DevOps'a giden yolculuk

2000'den hemen önce çoğu yazılım, büyük ölçekli geliştirme projelerine yönelik doğrusal bir yaklaşım olan şelale metodolojisi kullanılarak geliştirilip güncellenirdi. Yazılım geliştirme ekipleri, uygulamanın büyük bir kısmını ya da tamamını etkileyen büyük miktarda yeni kod geliştirmek için aylar harcardı. Değişiklikler çok kapsamlı olduğu için, yeni kodları kod tabanına entegre etmek için birkaç ay daha harcanırdı.

Sonrasında; kalite güvence (QA), güvenlik ve operasyon ekiplerinin kodu test etmeleri için daha da fazla ay gerekirdi. Bunun sonucu olarak; yazılım yayınlamaları arasında aylar ya da hatta yıllar geçerdi ve genellikle yayınların yanı sıra çok sayıda önemli yama ya da hata düzeltmesi yayınlanırdı. Ve özellik sağlamaya yönelik bu "büyük patlama" yaklaşımı, genellikle karmaşık ve riskli devreye alma planlarıyla, yukarı akım ve aşağı akım sistemlerle kenetlenmenin zor olmasıyla ve BT'nin, üretimin "canlıya geçişi" öncesindeki aylarda iş gerekliliklerinin önemli ölçüde değişmediğine dair "büyük umutları" ile bilinirdi.

Gelişimi hızlandırmak ve kaliteyi iyileştirmek adına, geliştirme ekipleri doğrusaldan ziyade yenilemeli olan ve uygulama kod tabanına yönelik daha küçük, daha sık güncellemeler yapmaya odaklanan çevik yazılım geliştirme metdolojilerini benimsemeye başladı. Sürekli entegrasyon ve sürekli teslim ya da CI/CD, bu metodolojilerin başında geliyor. CI/CD'de daha küçük yeni kod parçaları, her bir ya da iki haftada bir kod tabanı içinde birleştirilir ve daha sonra üretim ortamında devreye alınmak üzere otomatik olarak entegre edilir, test edilir ve hazırlanır. Çevik yaklaşım, "büyük patlama" yaklaşımını, aynı zamanda riskleri bölümlere ayıran bir dizi "daha küçük patlamalara" dönüştürdü.

Bu çevik geliştirme pratikleri, yazılım geliştirme ve teslimini ne kadar etkili bir şekilde hızlandırdıysa, sistem tahsisi, yapılandırma, kabul testi, yönetim, izleme gibi hala silo halindeki BT operasyonlarını da yazılım teslimi yaşam döngüsündeki darboğaz olarak o kadar çok ortaya çıkardı.

Bu şekilde, çevik yaklaşımdan DevOps'a gelindi. DevOps, yazılım teslimi yaşam döngüsünün geri kalanına CI/CD'nin sürekli yinelemesini ve otomatikleştirmesini genişleten yeni süreçler ve araçlar ekledi. Ve süreçteki her adımda, geliştirme ve operasyonlar arasında yakın işbirliğini hayata geçirdi.

DevOps nasıl çalışır: DevOps yaşam döngüsü

DevOps yaşam döngüsünün yolunu gösteren grafik

Şekil 1: DevOps Yaşam Döngüsü

DevOps yaşam döngüsü (bazen, doğrusal bir şekilde tanımlandığında, sürekli teslim hattı olarak da adlandırılır); yüksek kalite yazılımların hızlı sağlanmasını optimize etmek için tasarlanmış, daha geniş, otomatik ve yinelemeli bir geliştirme yaşam döngüsü dahilinde yürütülen bir dizi yinelemeli, otomatik geliştirme süreci veya iş akışıdır. İş akışlarının adları ve sayısı, sorduğunuz kişiye göre değişebilir; ancak genellikle şu altı maddede özetlenebilir:

  • Planlama (ya da ideasyon). Bu iş akışında ekipler, öncelikli son kullanıcı geri bildirimi ve vaka çalışmalarının yanı sıra tüm dahili paydaşlardan gelen girdilerden faydalanarak, sonraki yayındaki yeni özellikleri ve işlevselliği planlar. Planlama aşamasının amacı, sağlandıklarında değer sunan istenen bir sonucu üreten ve birikmiş özellikleri üreterek ürünün iş değerini en üst seviyeye taşımaktır.
  • Geliştirme. Bu adım, geliştiricilerin kullanıcı öykülerine ve biriken iş öğelerine dayanarak yeni ve geliştirilmiş özellikleri test ettiği, kodladığı ve oluşturduğu programlama adımıdır. Diğerlerinin yanı sıra test odaklı geliştirme (TDD), eşli programlama ve uzman kod incelemeleri gibi pratiklerin kombinasyonu da yaygındır. Geliştiriciler, kodu sürekli teslim hattına göndermeden önce kodu yazmayı ve test etmeyi içeren "içerideki döngüyü" gerçekleştirmek için sık sık kendi yerel çalışma istasyonlarını kullanırlar.
  • Entegrasyon (ya da oluşturma ya da sürekli entegrasyon ve sürekli teslim (CI/CD). Yukarıda belirtildiği üzere, bu iş akışında yeni kod var olan kod tabanına bütünleştirilir, sonrasında test edilir ve devreye alınmak üzere yürütülür bir dosya şeklinde paketlenir. Ortak otomasyon faaliyetleri arasında, kod değişikliklerinin "ana" bir kopyada birleştirilmesi, kaynak kod havuzundan gelen kodun kontrol edilmesi ve derlemenin, birim testinin ve paketlemenin yürütülebilir bir şekilde otomatikleştirilmesi yer alır. En iyi uygulama, bir sonraki aşama için Sürekli Entegrasyon aşamasını ikili bir havuzda depolamaktır.
  • Devreye alma (genellikle sürekli devreye alma olarak anılır). Burada, çalıştırma zamanı derlemesi çıktısı (entegrasyondan gelen), genellikle çalıştırma testlerinin kalite, uyumluluk ve güvenlik için yürütüldüğü bir geliştirme ortamı olan bir çalıştırma ortamında devreye alınır. Geliştiricilerin, hata veya kusurların bulunması durumunda, son kullanıcılar görmeden önce sorunlara müdahale etme ve düzeltme şansı vardır. Genellikle geliştirme, test ve üretim ortamları vardır ve her ortam aşamalı olarak "daha sıkı" kalite geçitlerini gerektirir. Bir üretim ortamında devreye almaya yönelik iyi pratiklerden biri, genellikle ilk olarak son kullanıcılardan oluşan bir alt kümede devreye alma, ardından da son olarak, durağanlığa ulaşıldığında tüm kullanıcılarda devreye almaktır.
  • Operasyon. Özelliklerin bir üretim ortamına taşınması "1. Gün" olarak nitelendirilirse, özellikler çalışmaya başladığında, "2. Gün" operasyonları gerçekleşir. Özellik performansının, davranışının ve kullanılabilirliğinin izlenmesi, özelliklerin kullanıcılara ek değer sunmasını sağlar. Operasyonlar; ağ, depolama, platform, bilgi işlem ve güvenlik duruşunun sağlıklı olmasını sağlayarak, özelliklerin sorunsuz bir şekilde çalışmasını ve hizmette kesinti olmamasını sağlar! Eğer bir şeyler yanlış giderse, operasyonlar olayların tanımlanmasını, doğru personelin uyarılmasını, sorunların belirlenmesini ve düzeltmelerin uygulanmasını sağlar.
  • Öğrenme (bazen sürekli geri bildirim olarak adlandırılır). Bu aşama, son kullanıcıların ve müşterilerin özellikler, işlevsellik, performans ve iş değerine ilişkin geri bildirimlerinin, bir sonraki yayına ilişkin geliştirmeler ve özelliklerin planlanmasında kullanılmak üzere toplandığı aşamadır. Bu ayrıca, geliştiricileri proaktif olarak geçmişte yaşanmış ve gelecekte tekrar yaşanabilecek olaylardan kaçınmaları konusunda güçlendirebilecek, operasyon faaliyetlerinden gelen tüm öğrenmeyi ve birikmiş öğeleri de içerecektir. Bu, Planlama aşamasının "toparlandığı" ve "sürekli olarak geliştiğimiz!" noktadır.

Bu iş akışları arasında önemli diğer üç sürekli iş akışı gerçekleşir:

Sürekli test: Klasik DevOps yaşam döngüleri, entegrasyon ve devreye alma arasında ortaya çıkan ayrı bir "test" aşamasını içerir. Ancak DevOps; planlama (davranış odaklı geliştirme), geliştirme (birim testi, sözleşme testi), entegrasyon (statik kod taramaları, CVE taramaları, Lint yazılımı ile kontrol), geliştirme (duman testi, sızma testi, yapılandırma testi), operasyonlar (kaos testi, uyumluluk testi) ve öğrenme (A/B testi) aşamalarında bazı test öğelerinin gerçekleşebileceği şekilde gelişti. Test, güçlü bir risk ve güvenlik açığı belirleme biçimidir ve BT'nin riskleri kabul etmesi, azaltması veya iyileştirmesi için bir fırsat sunar.

Güvenlik: Şelale metodolojileri ve çevik uygulamalar; güvenlik iş akışlarını teslim veya devreye almadan sonra 'gelişigüzel olarak eklerken', DevOps güvenliği en baştan (Planlama) - güvenlik sorunlarını ele almanın en kolay ve en ucuz olduğu aşamada, ve geliştirme döngüsünün geri kalanı boyunca sürekli olarak dahil etmeye çabalar. Güvenliğe ilişkin bu yaklaşım, sola kaydırma (shift left) olarak adlandırılır (Şekil 1'e bakıldığında daha kolay anlaşılır). Bazı kuruluşlar sola kaydırma konusunda daha az başarı yakaladı, bu da DevSecOps'un yükselişine yol açtı (aşağı bakın).

Uyumluluk: Yasal düzenlemelere uyumluluk (yönetişim ve risk) konuları da en iyi erkenden ve geliştirme yaşam döngüsü boyunca ele alınır. Yasal düzenlemeye tabi sektörlerin, genellikle belirli bir seviyede gözlenebilirlik, izlenebilirlik sağlaması ve özelliklerin, çalıştırma zamanı operasyonel ortamlarında nasıl sağlanıp yönetildiğine erişim vermesi zorunludur. Bu, sürekli teslim hattında ve çalıştırma ortamında planlama, geliştirme, test ve ilkelerin uygulanmasını gerektirir. Uyumluluk önlemlerinin denetlenebilirliği, uyumluluğun üçüncü kişi denetçilere kanıtlanması açısından son derece önemlidir.

DevOps kültürü

Genel olarak DevOps yöntemlerinin, DevOps kültürüne bağlılık olmadan işlemeyeceği kabul edilir. Bu kültür, yazılım geliştirmeye yönelik farklı bir kurumsal ve teknik yaklaşım olarak özetlenebilir.

DevOps, kuruluş düzeyinde tüm yazılım teslimi paydaşları genelinde - öncelikle yazılım geliştirme ve BT operasyonu ekipleri, ayrıca güvenlik, uyumluluk, yönetişim, risk ve iş kolu ekipleri - hızlı ve sürekli olarak inovasyan yapmak ve en başından itibaren yazılıma kalite katmak için sürekli iletişim, işbirliği ve sorumluluk paylaşımını gerektirir.

Çoğu durumda, bunu başarmanın en iyi yolu bu siloları birbirinden ayırmak ve onları çapraz işlevli, özerk DevOps ekipleri şeklinde yeniden düzenlemektir. Bu ekipler kod projelerinde başlangıcından sonuna kadar - planlamadan geri bildirime - diğer ekiplere iş devretmeden ya da bu ekiplerden onay beklemeden çalışabilirler. Çevik geliştirme bağlamında düşünülürse, paylaşılan hesap verebilirlik ve işbirliği, değerli bir sonuca sahip, paylaşılan bir ürün odağına sahip olmanın temelini oluşturur.

Teknik düzeyde DevOps, projeleri, iş akışları içinde ve arasında taşıyan otomasyona ve ekiplerin sürekli bir şekilde döngüleri hızlandırmasına ve yazılım kalitesini ve performansını iyileştirmesine olanak tanıyan geri bildirim ve ölçüm konularında kararlılık gerektirir.

DevOps araçları: Bir DevOps araç zinciri oluşturma

DevOps ve DevOps kültürünün talepleri, zamanuyumsuz işbirliğini destekleyen, DevOps iş akışlarını sorunsuz bir şekilde bütünleştiren ve tüm DevOps yaşam döngüsünü mümkün olduğu kadar otomatikleştiren araçlara büyük önem atfeder. DevOps araçlarının kategorileri şunlardır:

  • Proje yönetimi araçları - ekiplerin, kodlama projeleri oluşturan, bunları daha küçük görevlere ayıran ve görevleri tamamlanıncaya kadar izleyen kullanıcı öykülerinden (gereksinimler) birikmiş işler oluşturmasına olanak tanıyan araçlardır. Çoğu, geliştiricilerin DevOps'a getirdiği Scrum, Lean ve Kanban gibi çevik proje yönetimi pratiklerini destekler. Popüler açık kaynak seçeneklerinin arasında GitHub Issues ve Jira yer alır.
  • İşbirliğine dayalı kaynak kod havuzları - Birçok geliştiricinin aynı kod tabanı üzerinde çalışmasına olanak veren sürüm denetimli kodlama ortamlarıdır. Kod havuzları; CI/CD, test ve güvenlik araçlarıyla bütünleşmelidir; bu şekilde kod havuza sunulduğunda, otomatik olarak sonraki adıma geçebilir. GiHub ve GitLab, açık kaynak kod havuzlarından bazılarıdır.
  • CI/CD hatları - Kodu dışarı aktarma, oluşturma, test etme ve devreye alma işlemlerini otomatikleştiren araçlardır. Jenkins, bu kategorinin en popüler açık kaynak aracıdır; CircleCI gibi daha önceki açık kaynak alternatifleri artık yalnızca ticari sürümlerde mevcuttur. Sürekli devreye alma (CD) araçları söz konusu olduğunda, Spinnaker, kod katmanları olarak uygulama ile altyapı arasında yer alır. ArgoCD, yerel Kubernetes CI/CD için bir başka popüler açık kaynak seçeneğidir.
  • Test otomasyonu çerçeveleri - Bunlar arasında, birim, sözleşme, işlev, performans, kullanılabilirlik, sızma ve güvenlik testlerinin otomatikleştirilmesine yönelik yazılım araçları, kitaplıklar ve en iyi uygulamalar bulunmaktadır. Bu araçlardan en iyi olanlar birden fazla dili destekler; bazıları kod değişikliklerine yanıt olarak testleri otomatik olarak yeniden yapılandırmak üzere yapay zeka (AI) kullanırlar. Test araçlarının ve çerçevelerinin yelpazesi oldukça geniş! Popüler açık kaynak test otomasyonu çerçeveleri arasında Selenium, Appium, Katalon, Robot Framework ve Serenity (eski adıyla Thucydides) yer alır.
  • Yapılandırma yönetimi (kod olarak altyapı) araçları - Bunlar, DevOps mühendislerinin, bir komut dosyası yürüterek tam olarak sürümlendirilen ve tam olarak belgelenen bir altyapıyı yapılandırıp tahsis etmelerine olanak tanır. Açık kaynak seçenekleri arasında Ansible (Red Hat), Chef, Puppet ve Terraform yer alır. Kubernetes, konteynerleştirilmiş uygulamalar için aynı işlevi gerçekleştirir (aşağıda bkz. 'DevOps ve bulut tabanlı geliştirme').
  • İzleme araçları - Bunlar, DevOps ekiplerinin sistem sorunlarını belirleyip çözmelerine yardımcı olmanın yanı sıra, kod değişikliklerinin uygulama performansını nasıl etkilediğini ortaya koymak amacıyla verileri gerçek zamanda toplayıp analiz ederler. Açık kaynak izleme araçları arasında Datadog, Nagios, Prometheus ve Splunk yer alır.
  • Sürekli geri bildirim araçları - Isı haritaları (kullanıcının ekranda eylemlerini kaydetme), anketler veya self-servis sorun kaydı açma yoluyla kullanıcılardan geri bildirim toplayan araçlardır.

DevOps ve bulut tabanlı geliştirme

Bulut tabanlı yaklaşım, temel bulut bilgi işlem teknolojilerinden faydalanan uygulamalar oluşturmaya yönelik bir yaklaşımdır. Bulut tabanlı yaklaşımın amacı, genel, özel ve çoklu bulut ortamlarda tutarlı ve optimal bir uygulama geliştirme, devreye alma, yönetim ve performans sağlamaktır.

Bugün, bulut tabanlı uygulamalar genellikle

  • kendine yeten bir yazılım demetine sahip olan gevşek bağlı, bağımsız devreye alınabilen ve birbirleriyle REST API'leri, olay akışı ve mesaj aracıları ile iletişim kuran bileşenler olan mikro hizmetler ile oluşturulur.
  • Uygulamayı çalıştırmak için gerekli olan tüm kodu, çalışma zamanlarını ve işletim sistemi bağımlılıklarını içeren, yürütülebilir kod birimleri olan konteynerlerde devreye alınırlar. (Çoğu kuruluş için 'konteynerler' Docker konteynerlerle eşanlamlıdır; ancak başka konteyner türleri de mevcuttur.)
  • Konteynerleştirilmiş uygulamaların devreye alınmasını, yönetimini ve ölçeklenmesini planlayıp otomatikleştirmeye yönelik açık kaynaklı bir konteyner orkestrasyon platformu olan Kubernetes kullanılarak (ölçekli olarak) çalıştırılır.

Birçok açıdan, bulut tabanlı geliştirme ve DevOps birbirleri için yaratılmıştır.

Örneğin, mikro hizmetlerin - küçük kod birimlerinin küçük bir kod tabanına yinelemeli olarak teslimi - geliştirilip güncellenmesi, DevOps'un hızlı yayın ve yönetim döngüleriyle mükemmel bir uyum gösterir. Ve DevOps devreye alımı ve operasyonu olmadan, bir mikro hizmet mimarisinin karmaşıklığıyla başa çıkmak zor olacaktır. Yakın zamanda geliştiriciler ve BT yöneticileriyle yapılan bir IBM anketine göre, şu andaki mikro hizmet kullanıcılarının %78'i, mimariye yatırım yaptıkları zaman, para ve çabayı artırmayı bekliyor; kullanıcı olmayanların %56'sının ise, sonraki iki yıl içerisinde mikro hizmetleri benimseme ihtimali yüksek. Belirli mikro hizmetlerin avantajlarını ve zorluklarını keşfetmek için aşağıdaki interaktif aracı kullanın:

(Kaynak: 'Microservices in the enterprise 2021: Real benefits, worth the challenges'.)

Tüm işletim sistemi bağımlılıklarını paketleyerek ve kalıcı olarak sabitleyerek, konteynerler hızlı CI/CD ve geliştirme döngülerine olanak tanır, çünkü tüm entegrasyon, test ve devreye alma işlemleri, aynı ortamda gerçekleşir. Ve Kubernetes orkestrasyonu, Ansible, Puppet ve Chef'in konteynerleştirilmemiş uygulamalar için yerine getirdiği aynı sürekli yapılandırma görevlerini konteynerleştirilmiş uygulamalar için yerine getirir.

En önde gelen bulut bilgi işlem sağlayıcıları - aWS, Google, Microsoft Azure ve IBM Cloud dahil - bir tür yönetilen DevOps hattı çözümü sunarlar.

DevSecOps nedir?

DevSecOps, güvenliği DevOps yaşam döngüsü boyunca - başlangıçtan sona, planlamadan geri bildirime, ardından tekrar planlamaya kadar - sürekli olarak bütünleştiren ve otomatikleştiren DevOps'tur.

Başka bir şekilde ifade edilirse, DevSecOps, DevOps'un en başta olması gereken şeydir. Ancak DevOps'un benimsenmesine ilişkin ilk zamanlardaki iki önemli (ve bir süre boyunca aşılamayan) zorluk, güvenlik uzmanlığının çapraz işlevsel ekiplerle bütünleştirilmesi (kültürel bir sorun) ve güvenlik otomasyonunun DevOps yaşam döngüsüne uygulanmasıydı (teknik bir sorun). Güvenlik, "Hayır Diyenler Ekibi" ve çoğu DevOps pratiği için pahalı bir darboğaz olarak algılanmaya başlamıştı.

DevSecOps, güvenliği başlangıçta amaçlanan şekilde bütünleştirmek ve otomatikleştirmek için özel bir çaba olarak ortaya çıktı. DevSecOps'ta güvenlik; geliştirme ve Operasyonlarla birlikte "birinci sınıf" bir vatandaştır ve ürünü odak noktası haline getirerek, güvenliği geliştirme sürecine taşır.

DevSecOps ilkeleri, avantajları ve kullanım senaryoları hakkında daha fazla bilgi edinmek için 'DevSecOps nedir?' adlı videoyu izleyin:

DevOps ve saha güvenilirliği mühendisliği (SRE)

Saha güvenilirliği mühendisliği (SRE), başka durumlarda sistem yöneticileri tarafından elle gerçekleştirilebilecek - örneğin üretim sistemi yönetimi, değişiklik yönetimi, olaylara müdahale, hatta acil durumlara müdahale gibi - BT operasyonu görevlerini otomatikleştirmek amacıyla, yazılım mühendisliği tekniklerini kullanır. SRE, klasik sistem yöneticisini bir mühendise dönüştürmeyi amaçlar.

Saha güvenilirliği mühendisliğinin nihai hedefi, DevOps'un hedefine benzerdir, ancak daha belirlidir. SRE, müşterilerin ve son kullanıcıların hizmet seviyesi sözleşmelerinde (SLA) belirtilen performans ve kullanılabilirlik seviyelerini karşılama gereksinimi ile bir kuruluşun hızlı uygulama geliştirme isteğini dengelemeyi amaçlar.

Saha güvenilirliği mühendisleri, bu dengeyi elde etmek için uygulamaların yol açtığı kabul edilebilir bir operasyonel risk düzeyi belirler - 'hata bütçesi' denir - ve bu düzeyin karşılanması için operasyonları otomatikleştirir.

Çapraz işlevli bir DevOps ekibinde, SRE, geliştirme ve operasyonlar arasında bir köprü görevi üstlenerek, ekibin kod değişikliklerini ve yeni özellikleri DevOps hattına olabildiğince hızlı bir şekilde, kuruluşların Hizmet Seviyesi Sözleşmelerinin (SLA) koşullarını 'ihlal etmeden' göndermesi için gerek duyduğu metrikleri ve otomasyonu sağlar.

Saha güvenilirliği mühendisliği hakkında daha fazla bilgi edinin

DevOps ve IBM Cloud

DevOps; hızlı bir şekilde güvenilir yazılım sağlamak ve çalıştırmak için iş, geliştirme ve operasyon payladaşları genelinde işbirliği gerektirir. Kendi kültürlerini dönüştürürken DevOps araçlarını ve uygulamalarını kullanan kuruluşlar, dijital dönüşüm için ve otomasyon ihtiyacı iş ve BT operasyonları genelinde büyürken, uygulamalarını modernleştirmek için önemli bir temel inşa ediyor.

Otomasyonun artırılmasına yönelik bir girişim küçük, ölçülebilir düzeyde başarılı projelerle başlamalıdır; bu projeleri daha sonra diğer süreçler için ve kuruluşunuzun diğer bölümlerinde de ölçekleyebilir ve optimize edebilirsiniz.

IBM ile birlikte çalışarak, önceden oluşturulmuş iş akışları dahil olmak üzere gücünü yapay zekadan alan otomasyon özelliklerine erişim sağlayacaksınız ve her BT hizmeti sürecini daha akıllı hale getirerek, ekiplerin iş yükünü, daha önemli BT sorunlarına odaklanmaları ve inovasyonu hızlandırmaları için azaltacaksınız.

Bir sonraki adımı atın:

Bir IBM Cloud hesabıyla hemen başlangıç yapın.

IBM Cloud Pak for Watson AIOps, gizli içgörüleri ortaya çıkarmak ve kök nedenleri daha hızlı tespit etmeye yardımcı olmak amacıyla, yapılandırılmış ve yapılandırılmamış verileri operasyon araç zinciriniz genelinde ilişkilendirmek için makine öğrenmesini ve doğal dil anlayışını kullanır. Watson AIOps, birden fazla gösterge panosuna olan ihtiyacı ortadan kaldırarak olay çözümünü hızlandırmak için içgörüleri ve önerileri doğrudan ekip iş akışlarınıza gönderir.

Yazar hakkında

Andrea C. Crawford, klasik ve modern DevOps alanında uzmanlığa ve IBM Distinguished Engineer ünvanına sahip bir mühendistir. Müşterilerin uygulama teslim sürecini insanlar, süreç ve araç modernleştirme yoluyla dönüştürmelerine yardımcı olma konusunda tutkuludur. Andrea, bahçe işleri ve motorsiklet kullanmak gibi taktiksel "aykırılıkları" keşfetmekten hoşlanıyor.

https://twitter.com/acmthinks (bağlantı IBM dışındadır)

https://medium.com/@acmThinks (bağlantı IBM dışındadır)