Ana sayfa/Hizmetler/DevOps & Cloud
Hizmet · Modernleştirme & işletme

Sürüm hafta sonlarından rutin devreye almalara.

CI/CD, kod olarak altyapı, gözlemlenebilirlik ve SRE pratiği — kendi ürünlerimizin altında işlettiğimiz operasyonel omurganın kurumunuza kurulmuş hâli.

DevOps & CloudNeler yapıyoruz
01CI/CD hatları
02Kod olarak altyapı
03Gözlemlenebilirlik
04SRE pratiği
Nasıl ilerler
  1. Başlangıç ölçümü
  2. Hat & IaC
  3. Gözlemlenebilirlik & SLO’lar
  4. İşletme & devir
Neden var

Bir devreye alma, günün en az ilgi çeken olayı olmalıdır.

Kurumlar hızını, “staging’de çalışıyor” ile “canlı ortamda sorunsuz çalışıyor” arasındaki boşlukta kaybeder. Bu boşluk; bir sürüm hafta sonu, salı günleri toplanan bir değişiklik kurulu, ortak sürücüde duran ve bugüne dek yalnızca bir kişinin uyguladığı bir runbook ve dört kişinin sessizce izlediği bir devreye alma olarak görünür. Bunların hiçbiri bir araç sorunu değildir. Sorun; yazıya dökülmüş, her seferinde aynı şekilde yürütülen ve işler ters gittiğinde geri alınabilen bir canlıya çıkış yolunun olmamasıdır.

Bu boşluğu, kendi ürünlerimizin üzerinde çalıştığı platform disipliniyle kapatıyoruz: her şey kod olarak, her şey gözlemlenebilir, her arıza önceden prova edilmiş. Kurumunuza kurduğumuz CI hatları, Terraform modülleri, panolar ve nöbet tasarımı; ObelusLabs platformlarımızı sözleşmeli çalışma süresi hedefiyle işletirken kullandıklarımızın aynısıdır — bir sunum için çizilmiş referans mimari değil. İşe, teslimatınızın bugün gerçekte ne yaptığını ölçerek başlıyoruz; çünkü “genelde iki haftada bir devreye alıyoruz” iyileştirme yapabileceğiniz bir başlangıç noktası değildir.

Devreye almalar rutin olduğunda ekipler küçük ve sık sürüm çıkarır — küçük değişiklikler güvenli değişikliklerdir; çünkü bir saatlik işin etki alanı, gecenin ikisinde bir insanın hâlâ kafasında canlandırabileceği bir şeydir.

Nasıl çalışırız

Kurduğumuz dört şey, bu sırayla.

Her biri, kendinden öncekiler olmadan işe yaramaz. Kimsenin güvenmediği bir hattın üzerine kurulan gözlemlenebilirlik, kimsenin okumadığı panolar üretir; geri alma yolu olmayan SRE pratiği ise kahramanlık üretir.

01

CI/CD hatları

Otomatik testler, güvenlik taramaları ve önizleme ortamlarıyla trunk tabanlı akışlar — birleştirmeden canlıya, güvenle. Her pull request bir kez derlenir, kendi geçici ortamını alır ve ürettiği artefaktı canlı ortama kadar taşır; böylece test ettiğiniz şey ile yayına giden şey aynı olur. En yavaş ve en korkutucu manuel adım ilk sırada otomatikleştirilir; çünkü parti büyüklüğünü büyük tutan adım odur.

02

Kod olarak altyapı

Terraform ile yönetilen, incelenebilir, yeniden üretilebilir ve tek kullanımlık ortamlar. Tek örnek sunucular yok, kimsenin kayda geçirmediği konsol tıklamaları yok, canlı ortamdan tam da önemli olan tek ayarda sessizce ayrılan bir staging yok. Koruma kuralları — şifreleme, etiketleme, ağ çıkışı, en az ayrıcalıklı IAM — aynı depoda politika olarak durur ve bir denetimde keşfedilmek yerine plan üzerinde zorunlu kılınır.

03

Gözlemlenebilirlik

SLO tabanlı uyarılarla OpenTelemetry izleri, metrikleri ve logları — gürültü için değil, kullanıcının hissettiği belirtiler için çağrı. Tek bir istek, edge’den başlayarak dokunduğu her servis ve kuyruk boyunca izlenebilir; bu da “uygulama yavaş” cümlesini adı olan bir span’e dönüştürür. Uyarılar hata bütçelerine bağlıdır; böylece nöbetteki kişiyi yalnızca bütçeyi tüketen şeyler uyandırır, başka hiçbir şey değil.

04

SRE pratiği

Hata bütçeleri, olay müdahalesi, suçlayıcı olmayan olay sonrası incelemeler — kesintileri iyileştirmeye dönüştüren alışkanlıklar. SLO’ları servisi sahiplenen kişilerle birlikte tanımlıyor, arızayı gerçekte yaşanmadan önce game day’lerde prova ediyor ve runbook’u hafıza tazeyken yazıyoruz. Başarının ölçüsü, çağrı cihazını bizim değil, sizin mühendislerinizin güvenle taşımasıdır.

Uygulamada

İş günlük olarak nasıl yürür?

01

Canlıya tek bir yol, etrafından dolaşmak yok.

Sürümlerin seyrek olduğu yerlerde canlıya giden genellikle üç yol vardır: hat, acil durum betiği ve işi elle yapmayı bilen kişi. Biz bunları tek yola indiriyoruz. Bir commit tek ve değiştirilemez bir artefakt üretir; bu artefakt test, tarama, önizleme ve canary aşamalarından geçer; canlı ortam ayrı bir prosedür değil, son kapıdır. Bir sonraki aşamaya geçiş, depoya kaydedilen imzalı bir karardır ve her aşama reddedebilir — başarısız bir sözleşme testi, kritik bir CVE, aşılan bir performans bütçesi ya da onaylanmamış bir altyapı değişikliği hattı aynı şekilde durdurur. Geri alma, aynı mekanizmanın tersten çalışmasıdır; ilk gerçek sürümden önce prova edilir, böylece kimsenin bir olay sırasında onu icat etmesi gerekmez.

  • Bir kez derleyin, aynı artefaktı ilerletin — staging ile canlı ortam arasında yeniden derleme yok
  • Her pull request için otomatik kaldırılan önizleme ortamları; böylece inceleme çalışan yazılım üzerinde yapılır
  • Kademeli teslimat: bir insanın fark etmesine değil, SLO tüketimine bağlı otomatik geri almayla canary veya blue-green
  • Acil değişiklikler de aynı hattı kullanır; kısaltılmış kapı listesi ve kayda geçmiş bir onaylayan ile
  1. 01Commit
  2. 02Derle & test
  3. 03Tara
  4. 04Önizleme
  5. 05Canary
  6. 06Canlı

Canlıya giden yol

02

Denetçi sormadan yanıt veren koruma kuralları.

Kod olarak altyapı çoğu zaman yeniden üretilebilirlik olarak anlatılır. Asıl kazanç, politikanın incelenebilir hâle gelmesidir. Hesaplar, ağlar, kimlik ve veri depoları bir depoda Terraform olduğunda, bir kontrol artık bir belgedeki paragraf değil, her planda çalışan bir kuraldır. Bir bucket herkese açık olarak oluşturulamaz. Bir veritabanı, veri yerleşimi yükümlülüklerinizin izin verdiği bölgenin dışında oluşturulamaz. Canlı ortam rolü, onay izi olmadan bir kişiye verilemez. Sonuçta bir uyum görüşmesi bir vaatten değil, kanıttan başlar — bir plan çıktısı, bir politika çalışması, bir commit geçmişi. Altyapının daha derin bir güvence gerektirdiği yerlerde bunu Siber Güvenlik hizmetimizle birlikte kullanın.

  • Gerçekten işlettiğiniz ortamlar için modüller; kopyalanmak yerine sürümlenip yeniden kullanılır
  • Her planda kod olarak politika: şifreleme, etiketleme, dış trafik, herkese açıklık, bölge sabitleme
  • Sapma tespit edilip raporlanır; böylece gece yarısı konsoldan yapılan değişiklik sessizce ayakta kalmaz
  • Ortamlar tek kullanımlıktır — yeni bir bölge ya da baştan kurulum bir proje değil, bir hat çalıştırmasıdır
Depolama bucket’ı herkese açık okunabilirPlan reddedildi, inceleyene bildirildi
Kaynakta sahip veya masraf merkezi etiketi yokPlan reddedildi
Veri deposu onaylı bölgenin dışındaPlan reddedildi, yerleşim politikası gerekçe gösterildi
Canlı ortam IAM rolü bir kişiye verildiAdı belirtilmiş onaylayan gerekir, kayda geçer
Commit’lenmiş duruma göre sapma tespit edildiUyarı ve düzeltme görevi oluşturuldu
03

Kullanıcının hissettiği için çağrı, gerisi için sessizlik.

CPU üzerinden çağrı üreten bir uyarı sistemi, nöbetteki ekibe onu görmezden gelmeyi öğretir. Biz belirtileri ölçeriz: kullanıcılarınızın deneyimlediği yüzdelikteki gecikme, para kazandıran akışlardaki hata oranı, geride kalmaması gereken akışlardaki kuyruk gecikmesi. Her servis, kendisini sahiplenen kişilerle mutabık kalınan bir SLO ve ödünleşimi açık hâle getiren bir hata bütçesi alır — bütçe sağlıklıyken sürüm çıkarın, tükeniyorken durup düzeltin. İzler bağlamı servisler ve mesaj konuları boyunca taşır; böylece bir olay, beş mühendisin paralel grep yapmasıyla değil, yavaş olan span ile başlar. Bir olay omurgası üzerinde nasıl iz sürdüğümüz için Kafka & olay tabanlı mimari sayfasına bakın.

  • Servisler, işler ve tüketiciler genelinde OpenTelemetry; bağlam uçtan uca taşınır
  • Servis başına SLO ve hata bütçesi; sabit eşikler yerine tüketim hızı uyarıları
  • Servis başına tek pano: “sağlıklı mı, değilse nerede” sorusunu yanıtlar
  • Kod olarak dışa aktarılan ve diğer her değişiklik gibi incelenen uyarı politikaları
04

Fatura, sahibi olan bir sayıya dönüşür.

Bulut harcaması sıradan nedenlerle yukarı doğru kayar: kimsenin silmeyi hatırlamadığı ortamlar, varsayılanda bırakılmış depolama katmanları, üç yıl önce yapılmış bir lansmana göre boyutlandırılmış sunucular ve maliyetin kime ait olduğunu söyleyen bir etiketin bulunmayışı. Altyapı kod hâline geldiğinde bu ele alınabilir olur. Etiketleme plan aşamasında zorunlu kılınır, böylece her kaynağın bir sahibi olur. Canlı olmayan ortamlar mesai dışında kapanır. Boyutlandırma ve rezerve kapasite kararları, ilk mimari belgesine göre değil, gerçek kullanıma göre verilir.

  • Zorunlu etiketlerden ekip, ürün ve ortam bazında maliyet dağılımı
  • Atıl ve sahipsiz kaynaklar, sahibiyle birlikte, sizinle belirlenen bir düzende raporlanır
  • Ölçülen kullanıma göre boyutlandırma ve taahhüt planlaması
  • Kod olarak bütçeler ve anomali uyarıları; sürpriz fatura zamanında değil, erken yakalanır
Rollere göre

Masanın her tarafı ne kazanıyor.

Mühendislik

Bir değişiklik, rutin bir adımla canlıya çıkar.

Geliştiriciler her pull request’te önizleme ortamı, kimsenin atlamayacağı kadar hızlı bir test paketi ve okuyabilecekleri bir ilerletme yolu elde eder. İlginç karar birleştirme olur; devreye alma rutine döner. Mesele küçük partilerdir — bir öğleden sonra süren bir değişiklik kafada canlandırılabilir, doğru düzgün incelenebilir ve tek hamlede geri alınabilir.

  • Her pull request için önizleme ortamı, birleştirmede silinir
  • Tek hamlede geri alma, ihtiyaç duyulmadan önce prova edilmiş
Operasyon & nöbet

Korkmadan taşınabilen bir nöbet.

Nöbet devralınmaz, tasarlanır: makul bir nöbet listesi büyüklüğü, kullanıcının çektiği sıkıntıya karşılık gelen uyarılar, her uyarı için bir runbook ve ne olduğunu anlatan bir devir. Game day’ler, sizi gerçekten tehdit eden arızaları — bir bölgenin kaybı, zaman aşımına uğrayan bir bağımlılık, biriken bir kuyruk — haber vermeden bir cuma günü yaşanmadan önce prova eder.

  • Her uyarı için bir runbook, game day’de test edilmiş
  • Eskalasyon ve devir hatırlanmaz, yazılıdır
  • Suçlayıcı olmayan olay sonrası incelemeler; aksiyonlar diğer işler gibi takip edilir
Güvenlik & uyum

Kanıtı kendiliğinden üreten kontroller.

Taramalar hatta çalışır: bağımlılıklar, konteynerler, altyapı planları, gizli anahtarlar. Canlı ortama erişim, adı belirtilmiş onaylayanlarla kod olarak tanımlanmış en az ayrıcalıklı IAM’dir; her değişiklik bir commit, bir inceleyen ve bir derleme kaydı taşır. Kontrollerimizi ISO 27001’e göre belgeliyor, GDPR / KVKK’yı tasarım girdisi olarak ele alıyoruz; böylece bir denetçinin istediği çıktılar ziyaret öncesinde toplanmaz, sistem tarafından üretilir.

  • Hat kapıları olarak SAST, bağımlılık, konteyner ve IaC taraması
  • Gizli anahtarlar yönetilen bir kasada; asla bir depoda veya derleme logunda değil
  • Değişiklik geçmişi, onaylayanlar ve politika sonuçları denetim kanıtı olarak saklanır
CTO

Teslimatın iyileşip iyileşmediğini söyleyen dört sayı.

Devreye alma sıklığı, değişiklik süresi, değişiklik hata oranı ve toparlanma süresi bir ankete göre değil, doğrudan hattın kendisinden ölçülür. Bunlar “hızlanıyor muyuz, yoksa yalnızca yoğunlaşıyor muyuz” sorusuna savunulabilir bir yanıt verir ve bir değişiklik dondurmasının maliyetini görünür kılar. Önce başlangıç ölçümünü, ardından eğilimi sizinle belirlenen bir düzende raporluyoruz.

  • Hat ve olay verilerinden otomatik toplanan DORA metrikleri
  • Zorunlu etiketlemeden ortam ve ekip başına maliyet
  • Yönetim kurulunun önüne koyabileceğiniz bir eğilim
Kapsam

Her projede yer alanlar ve altyapınıza bağlı olanlar.

CapabilityEvery engagementDepends on your estate
DORA başlangıç ölçümü ve eğilim—
Önizleme ortamlarıyla trunk tabanlı CI/CD—
Otomatik geri almalı kademeli teslimatServis bazında
Yönetilen ortamlar için Terraform
Planlarda kod olarak politikaSizin kontrol setiniz
OpenTelemetry ölçümlemesiDil ve çalışma ortamına göre
SLO’lar, hata bütçeleri ve tüketim hızı uyarılarıServis bazında mutabık kalınır
Kubernetes platform mühendisliği—Yalnızca ölçek gerektiriyorsa
Maliyet etiketleme, bütçeler ve boyutlandırma
Gizli anahtar yönetimi ve en az ayrıcalıklı IAM
Derin güvenlik testi ve tehdit modelleme—Siber Güvenlik ile
Çağrı cihazını biz taşırız—Opsiyonel, mutabık kalınan SLO’lara göre
Uygulama

Dört aşama, sonrasında sizin ekibiniz devralır.

01

Başlangıç ölçümü

Devreye alma sıklığı, değişiklik süresi, MTTR, değişiklik hata oranı — tahmin değil, ölçüm. Halihazırdaki hattınızı ve olay kayıtlarınızı ölçülebilir hâle getiriyor, gerçek bir sürümü onu yürüten kişilerle uçtan uca adım adım geçiyor ve zamanın ve güvenin gerçekte nerede kaybedildiğini çıkarıyoruz. Çıktı, yazılı bir başlangıç ölçümü ve bunu en çok iyileştirecek değişikliklerin önceliklendirilmiş listesidir.

02

Hat & IaC

Canlıya giden yol kod olarak yeniden kuruluyor; en yavaş ve en riskli adımlar ilk sırada otomatikleştiriliyor. Ortamlar, teslimatı engelleyenlerden başlayarak modül modül Terraform’a taşınıyor. Diğerleri gelmeden önce bir servis yeni yoldan uçtan uca geçiyor; böylece desen bir belgede mutabık kalınmak yerine gerçek bir şey üzerinde kanıtlanıyor.

03

Gözlemlenebilirlik & SLO’lar

Kullanıcının deneyimlediğine bağlanmış ölçümleme, panolar ve uyarılar. SLO’lar, servisleri sahiplenen ekiplerle servis servis mutabık kalınarak belirleniyor; uyarılar tüketim hızı politikaları olarak yeniden yazılıyor; herkese kanalı görmezden gelmeyi öğreten gürültülü çağrılar siliniyor. Bu aşamanın sonunda bir olay tahminle değil, bir izle başlıyor.

04

İşletme & devir

Game day’ler, runbook’lar ve nöbet tasarımı — sonrasında işi sizin ekibiniz yürütür, biz gerektiğinde kenarda hazır bekleriz. Önemli arızaları prova ediyor, devirler sorunsuz işleyene kadar nöbeti birlikte tutuyor ve depoları, panoları ve prosedürleri sizin elinize bırakıyoruz. İşletmeye devam etmemiz bir seçenektir; asla kurgulayarak yarattığımız bir bağımlılık değil.

Çıktılar

Sonunda elinizde olanlar.

  • Kalite ve güvenlik kapılarına sahip CI/CD hatları
  • Yönetilen tüm ortamlar için Terraform kod tabanı
  • SLO panoları ve uyarı politikalarıyla gözlemlenebilirlik yığını
  • Olay müdahale runbook’ları ve olay sonrası inceleme pratiği
  • DORA metrik başlangıç ölçümü ve eğilim
  • Nöbet tasarımı: nöbet listesi, eskalasyon, devir şablonu ve game day kaydı
  • Etiketlemesi zorunlu bir maliyet modeli; kod olarak bütçeler ve anomali uyarıları
Şunlarla çalışır
AWSAzureGCPKubernetesTerraformGitHub ActionsArgoCDDockerGrafanaOpenTelemetry
Uygunluk

Bu ne zaman doğru karardır.

Doğru tercih

Sürümler rutin değil birer olay hâline geldiyse bunu seçin: bir değişiklik dondurması, bir sürüm hafta sonu, hiçbir şey yayına çıkmadan önce toplanan bir kurul. Olayları uyarılar değil müşteriler buluyorsa, bir ortamda neyin çalıştığını içeri girip bakmadan kimse söyleyemiyorsa, bulut faturası trafikten hızlı büyüyorsa ya da canlıya giden tek yol tek bir kişiyse ve bunu herkes biliyorsa bunu seçin. Altyapı zaten taşınıyorsa Bulut Geçişi ile, devreye almaların yavaş olmasının nedeni testlere kimsenin güvenmemesiyse QA & Test ile doğal biçimde birlikte ilerler.

Başka yere bakın

Ürünün kendisi henüz netleşmediyse yanlış bir ilk adımdır — hâlâ pazar arayan bir ekibin ihtiyacı hata bütçesi değil, bir MVP’dir. Kurum, pratiği olmadan yalnızca araçları istiyorsa yanlış bir adımdır: değişmemiş bir onay kültürünün üzerine kurulan hatlar ve panolar pahalı bir süse dönüşür. Ayrıca Kubernetes’in yanıt olmadığı durumda bunu size söyleriz. Yükü öngörülebilir tek bir uygulama için çoğu zaman yönetilen konteynerler ya da bir platform servisi daha iyidir; dürüst öneri, ölçek ve uyum ihtiyaçlarınızı karşılayan en basit platformdur.

SSS

Sık sorulan sorular

Bu klasik başlangıç noktasıdır ve izlenecek yol iyi bilinir. Önce en korkutucu alanların çevresindeki testleri otomatikleştirin ki korkunun gidecek bir yeri olsun; parti büyüklüğünü küçültün; gerçekten bir provada kullanılmış bir geri alma ekleyin. Sıklık güvenliği takip eder — hiçbir zaman tersi olmaz. Dondurmanın kendisi genelde en son kalkar: değişiklik hata oranı kimsenin onu gerekçelendiremeyeceği kadar düştüğünde uygulanmayı bırakır.
Belki de yok. Ölçek ve uyum ihtiyaçlarınızı karşılayan en basit platformu öneriyoruz; bu bazen yönetilen konteynerler, bir serverless çalışma ortamı, hatta bir PaaS olur. Kubernetes; farklı ölçeklenme biçimlerine sahip çok sayıda servis işlettiğinizde, iş yüklerinin bulutlar ya da şirket içi ortamlar arasında taşınabilir olması gerektiğinde veya onu sahiplenecek bir platform ekibiniz zaten olduğunda işletme maliyetini hak eder. Bunların hiçbiri geçerli değilse, yetenek eklemeden işletilecek bir sistem eklemiş olursunuz. Doğru yanıt olduğunda onu nasıl işlettiğimiz için Kubernetes sayfasına bakın.
Başlıca kaldıraçlar şunlardır: ölçülen kullanıma göre boyutlandırma, depolama katmanı düzeni, iş yükünün izin verdiği yerlerde spot kapasite, geceleri kapanan canlı dışı ortamlar ve kimsenin hatırlamadığı ortamların silinmesi. Kalıcı olan kısım, plan aşamasında zorunlu kılınan etiketlemedir; böylece her kaynağın bir sahibi olur ve bir sonraki sapma fatura zamanında değil, erkenden görünür.
Nöbeti biz tutabilir, sizinle paylaşabilir ya da ekibinizi eğitebiliriz — amaç her zaman, çağrı cihazını sizin ekibinizin güvenle taşıyabilmesidir. Nöbeti biz işlettiğimizde bu, tanımlı SLO’lara göre ve mühendislerinizin kullandığı panolar ile runbook’lar üzerinden olur; ekibinize devir de sonradan pazarlık edilmez, en baştan planlanır.
Evet: hatta tarama, kod olarak en az ayrıcalıklı IAM, yönetilen bir kasada gizli anahtarlar ve altyapı planlarında zorunlu kılınan politika. Bu, sıradan ihlalleri önleyen sıradan hijyeni kapsar. Tehdit modelleme, sızma testi ve uyum programları daha derin bir iştir; bunu Siber Güvenlik hizmetimizle birleştirin.
İş, ölçümle ve gerçek bir sürümün onu yürüten kişilerle uçtan uca adım adım geçilmesiyle başlar. Ardından yazılı bir başlangıç ölçümünüz, dört DORA sayınız ve yeni hat üzerinden canlıya giden bir servisiniz olur — en az bir kez bilerek yürütülmüş bir geri alma dâhil. Planın hiçbir yanı, bize önceden inanmanıza bağlı değildir.
İlgili

Bu hizmet genellikle nerede konumlanır.

Ne inşa ettiğinizi bize anlatın.

Bugün elinizde ne olduğunu ve neye ihtiyacınız olduğunu anlatın. Bir mühendis okur; nasıl yaklaşacağımızı ve size uyan modeli yazılı olarak iletir.

✓ Satış sunumu yok✓ AI-native bir mühendisten yanıt✓ Yazılı geri dönüş