surfup

Lojistik SaaS

Gece elle dağıtım yerine 15 dakikada dağıtım

Lojistik · DevOps · Kubernetes · CI/CD · İzleme
Proje bağlamı

Müşteri, günde on binlerce sipariş işleyen bir lojistik hizmetidir; akşam ve kampanya dönemlerinde trafik zirve yapar, mağaza ortaklarına karşı katı SLA’ler vardır. Altyapı plansız büyümüştü: dağınık VPS’ler, sunucular üzerinde tutulan yapılandırmalar ve wiki’deki talimata göre elle yapılan dağıtımlar. Her sürüm kesintiyle sonuçlanan gece dağıtımıydı, her yoğun dönem de sipariş kaybı riski yaratıyordu. Projeye başvurmalarına neden olan olay, yılbaşı öncesi kampanyada platformun dört saat çalışmaması ve hizmetin ortaklarına tazminat ödemesi oldu.

01 · Zorluk

İşletmeyi durdurmadan platformu yönetilebilir altyapıya taşımak:

altyapıyı kod olarak tanımlama, otomatik dağıtım, konteynerleştirme ve orkestrasyon, gözlemlenebilirlik ve arızalardan öngörülebilir biçimde kurtarma. Kurucu başarı ölçütünü şöyle ifade etti: “mesai saatlerinde, kesinti olmadan ve SSH erişimi olan biri olmadan dağıtım.”

02 · Tamamlanan çalışmalar

Kanıtlanmış sırayı izledik: önce konteynerler ve yeniden üretilebilir ortamlar, sonra dağıtımın otomasyonu, en son otomatik ölçeklendirmeli orkestrasyon.

  • Altyapıyı denetledik: servis ve bağımlılık haritası, yoğun yük profilinin ölçümleri ve en sık kesintiye yol açan manuel işlemlerin kaydı.
  • Servisleri konteynerleştirdik: derleme sürecini standartlaştırdık, yapılandırmayı koddan çıkarıp ortam değişkenlerine taşıdık ve birbirinin aynısı dev/stage/prod ortamları kurduk.
  • Altyapıyı Terraform ile kod olarak tanımladık: ortamlar depodan oluşturuluyor, bulut sağlayıcısının konsolundaki elle değişiklikler yasak.
  • GitLab CI hattı kurduk: testler ve imaj derlemeleri otomatik; stage’e hemen, prod’a incelemeden sonra düğmeyle dağıtım; geri alma tek işlemle.
  • Platformu otomatik ölçeklendirmeli Kubernetes’e taşıdık: akşam ve kampanya zirvelerinde ek örnekler devreye giriyor; ekiplerin acil elle müdahalesi gerekmiyor.
  • Monitoring ve uyarı sistemi kurduk: gecikme, hata, trafik ve doygunluk gibi dört temel sinyalin metrikleri; vardiya ve planlı eskalasyonla birlikte.
  • Yedekleme ve felaket kurtarma düzenini kurduk: geri yükleme prosedürü ve stage ortamında yapılan arıza provasında gerçek MTTR ölçümü.

Projenin en değerli yanı teknolojiler değil, sorumluluğun değişmesiydi: altyapı artık “SSH erişimi olan kişiye” bağlı değil. Her dağıtım yeniden üretilebilir, her ortam koddan geri kurulabilir ve ilk müşteri yazmadan önce arızalar panolarda görünür. Böylece kesintiler felaketten, açık çalışma talimatı ve ölçülebilir kurtarma süresi olan rutin olaylara dönüşür.

03 · Sonuç

Projenin ekonomik faydası üç bölümden oluşuyor: otomatik ölçeklendirme ve sürekli açık tutulan “zirve” kapasitesinden vazgeçilmesi sayesinde altyapıda doğrudan %32 tasarruf; önceden gece dağıtımlarına giden ekip saatlerinden tasarruf; en önemlisi de artık arızasız geçen yoğun dönemlerde gelirin korunması. Büyük bir mağaza zinciri olan müşteri, yeni altyapıdaki ilk kampanyadan sonra sözleşmesini uzattı.

04 · Öne çıkan sonuçlar
GöstergeSonuç
Sürüm dağıtımıElle 3–4 saat → Otomatik 15 dakika
Sürüm sıklığıAyda 2–3 → Neredeyse her gün
Platform kullanılabilirliği97,8% → 99,95%
Yoğun yüklerKesinti riski → İnsan müdahalesi olmadan otomatik ölçeklendirme

Göstergeler vaka çalışmasının kaynak materyallerinden aktarılmıştır. Süre, kaynakta belirtildiği yerlerde verilmiştir.

Beş ay sonra
sürüm dağıtımı (önce elle 3–4 saat)
15 dk
platform kullanılabilirliği (önce %97,8)
99,95%
kesinti sonrası kurtarma (önce 2–4 saat)
20–30 dk
altyapı maliyeti
−32%
Önce ve sonra
Sürüm dağıtımı, dakika
Önce3–4 saat
Sonra15 dk.
Daha düşük olması daha iyi
Kurtarma (MTTR), dakika
Önce2–4 saat
Sonra20–30 dk.
Daha düşük olması daha iyi
Platform kesinti süresi
Önce2,2%
Sonra0,05%
Daha düşük olması daha iyi

Aralıkların üst sınırları gösterilir (4 saat, 30 dakika). Kesinti süresi = 100% − kullanılabilirlik.

Teslimat hattı
  1. 01Commit
  2. 02Testler
  3. 03İmaj derleme
  4. 04Stagehemen
  5. 05Prodincelemeden sonra düğmeyle
Sonraki adımlar

Bir sonraki döngü için altyapı geliştirme alanları:

  • Maliyet anormalliklerine yönelik uyarılar ve takım bazında maliyet görünürlüğü sunan FinOps uygulaması.
  • GitOps yaklaşımı: prod durumu depoda tanımlı olur, değişiklikler yalnızca pull request ile yapılır.
  • Sağlayıcı arızalarına dayanıklılık için kritik servislerin çoğaltıldığı çok bölgeli yapı.
Alıntı
Eskiden sürüm demek gece, kahve ve dua demekti. Şimdi bir düğme ve on beş dakika. İlk olaysız kampanyayı bütün şirket olarak kutladık.

— Lojistik hizmetinin teknik direktörü

En yeni içerikler

Tüm içerikler

SurfUp’tan uygulamalı makaleler ve rehberler.

Rehber · 10 dk.

“Nedir?” sayfaları ve AI yanıtları: tıklama kaybı mı, talep düşüşü mü?

Bankanın bilgi bölümünde ziyaretler talep −%13 iken %24 düştü. AI bloğundan kaynaklanan tıklama kaybını talep düşüşünden ayırmayı ve kendi verilerinizde ölçmeyi öğrenin.

Oku
Rehber · 8 dk.

Google güncellemesinden sonra trafik düştü

Trafik düşüşünün Google güncellemesinden mi, mevsimsellikten mi yoksa teknik arızadan mı kaynaklandığını anlayın. 2026 güncelleme çizelgesi, altı soruluk kontrol ve ilk 14 günün planı.

Oku
Rehber · 9 dk.

Talep mi düştü, site mi kayıp yaşadı: trafiği Wordstat ile nasıl karşılaştırırsınız?

Mevduat talebi %75, trafik %37 düştü; kartlarda talep −%35, trafik −%63. Trafiği taleple karşılaştırıp piyasa hareketini site sorunu sanmayın.

Oku