Hybris Bakım ve Destek: AMS Modelinin Doğru Kurulumu

Hybris projesi canlıya çıktı; şimdi kim bakacak?

Kurumsal e-ticaretin en az konuşulan gerçeği şudur: projenin ilk yılı toplam sahiplik maliyetinin küçük parçasıdır — sistem on yıl yaşar ve o on yılın kalitesini bakım modeli belirler. AMS (Application Management Services), bu bakımın sözleşmeli, ölçülebilir ve sürdürülebilir halidir. Bu yazı, Hybris özelinde doğru AMS kurgusunu anlatır: seviyeler, SLA tasarımı, yama ritmi ve en kritik ayrım — 'ayakta tutma' ile 'ileri götürme' bütçelerinin ayrılması.

Destek seviyeleri: kim neye bakar?

Hybris özelinde kritik nokta L2-L3 sınırındadır: cronjob/senkronizasyon arızaları, ImpEx veri düzeltmeleri, Solr yeniden indeksleme ve backoffice yapılandırmaları L2'de hızla çözülebilmelidir — her şeyin L3'e (mühendisliğe) taşındığı model hem pahalı hem yavaştır. Bu yüzden AMS ekibinin platform derinliği, sözleşmedeki en önemli 'gizli' kalitedir.

SLA tasarımı: semptomlara söz, nedenlere hedef

Observability yazımızdaki ilke sözleşme diline çevrilir: SLA'lar kullanıcıyı etkileyen semptomlara verilir — kritik olay (satış duruyor) müdahale ve çözüm hedefleri, yüksek/orta/düşük öncelik merdiveni, kampanya dönemlerinde sıkılaştırılmış rejim. İki tasarım inceliği ayrışmayı önler: öncelik tanımları örneklerle yazılır ('ödeme hatası hangi orandaysa kritik' — yoruma yer bırakmadan) ve çözüm ile geçici çözüm ayrılır (workaround süreyi durdurur mu, kalıcı düzeltme takvimi nasıl işler). SLA panosu iki tarafın da baktığı tek ekran olmalıdır; ay sonu raporda sürpriz, kötü sözleşmenin belirtisidir.

Olay yönetiminden problem yönetimine

Olgun AMS'i vasat AMS'ten ayıran çizgi tekrar eden olaylardadır: aynı cronjob her hafta düşüyorsa her düşüşte müdahale etmek olay yönetimidir; bir daha düşmemesini sağlamak problem yönetimi. Sözleşmede bunun karşılığı vardır: tekrar analizi ritmi (aylık problem incelemesi), kök neden çalışması zorunluluğu (kritik olaylarda yazılı RCA) ve olay sayısını düşürme hedefi — iyi AMS, kendi bilet hacmini küçültmeye teşvikli olmalıdır. Bunun altyapı ön koşulu izlemedir: devraldığımız sistemlerde ilk ay çoğunlukla izleme kurulumuna gider, çünkü görmediğin sistemi yönetemezsin.

Sürüm ve yama ritmi: bakımın ihmal edilen yarısı

Hybris bakımında 'çalışıyorsa dokunma' yaklaşımı, sağlık taraması yazımızda anlattığımız bileşik faize dönüşür: atlanan her yama ve sürüm, gelecekteki yükseltmeyi büyütür. Doğru AMS sözleşmesi bakım ritmini içerir: güvenlik yamalarının tanımlı pencerede uygulanması, platform güncellemelerinin (CCv2'de düzenli gelen) takvimli alınması, bağımlılık taramasının sürekli koşması ve yılda en az bir 'yükseltme provası'. Bu ritmin maliyeti sözleşmede görünür; yokluğunun maliyeti üç yıl sonra 'mini yeniden yazım' faturasında görünür — ikisi arasındaki fark, AMS'in gerçek getirisidir.

İyileştirme bütçesi: ayakta tutmak yetmez

En sağlıklı AMS kurgusu, kapasiteyi ikiye böler: işletme payı (olay, talep, bakım ritmi) ve iyileştirme payı (performans çalışmaları, teknik borç azaltma, küçük özellik geliştirme). İyileştirme payının sabit ve korunmuş olması kritiktir — aksi halde acil işler her ayın tamamını yer ve sistem yerinde sayar. Pratik mekanizma: aylık iyileştirme listesi iş tarafıyla önceliklenir, biten işler ölçülen etkiyle raporlanır (p95 düşüşü, olay azalması). Böylece AMS, maliyet merkezi görünümünden çıkıp ölçülebilir değer üreticisine dönüşür.

Geçiş: devralma disiplini

AMS'in en riskli anı devralmadır — ister iç ekipten, ister önceki tedarikçiden. Disiplinli devralma planı: bilgi transferi oturumları (mimari, özelleştirme envanteri, entegrasyon haritası — sağlık taraması çıktısı burada hazır girdi olur), erişim/ortam envanteri, runbook devri ve gölge dönem (eski sahip yanıt verirken yeni ekibin eşlik ettiği 2-4 hafta). Devralmada kaçınılması gereken kalıp 'belgeler eksik, öğrenerek gideriz' yaklaşımıdır: öğrenme maliyeti olay anında ödenir ve kullanıcı öder.

Sık sorulan sorular

İç ekip mi, AMS mi, karma mı?

Ölçek ve süreklilik sorusudur: 7/24 nöbet, tatil/ayrılma sürekliliği ve platform derinliğini iç kadroyla taşımak çoğu kurumda pahalıdır; iş bilgisi ise içeride değerlidir. Yaygın sağlıklı model karmadır: iş analizi ve ürün sahipliği içeride, operasyon ve mühendislik derinliği AMS'te.

AMS fiyatlaması nasıl kurgulanmalı?

Saf bilet-başı model kaliteyi cezalandırır (az olay = az gelir); saf sabit ücret ise hacim riskini tek tarafa yükler. Dengeli kurgu: taban kapasite (sabit) + hacim bandı + iyileştirme payı — ve olay azaltma hedefine bağlı teşvik.

Kampanya dönemleri sözleşmede nasıl yer almalı?

Ayrı rejim olarak: sıkılaştırılmış SLA, önceden planlı ekip takviyesi, dondurma pencereleri ve kampanya öncesi hazırlık kontrol listesi (flash sale yazımızdaki operasyon defteri) sözleşme ekidir.

Sürüm yükseltme AMS kapsamında mı, ayrı proje mi?

Küçük güncellemeler ve yamalar kapsam içidir; büyük sürüm yükseltmeleri ayrı bütçeli mini proje olarak planlanır — ama yükseltme provası ve hazırlık AMS ritminin parçasıdır, bu yüzden proje küçük ve öngörülebilir kalır.

AMS kurulum kontrol listesi

1. Seviye sınırları (L1/L2/L3) ve sahiplikler yazılı

2. SLA'lar örnekli öncelik tanımlarıyla; pano iki tarafa açık

3. Problem yönetimi ritmi ve RCA zorunluluğu sözleşmede

4. Yama/sürüm ritmi ve yıllık yükseltme provası tanımlı

5. İyileştirme payı korunmuş; etki raporlaması ölçülü

6. Devralma planı: bilgi transferi + gölge dönem + runbook

7. Kampanya rejimi ayrı ek olarak sözleşmede

SSH Yazılım, SAP Commerce (Hybris) sistemleri için devralma, bakım ve sürekli iyileştirmeyi kapsayan AMS hizmetini SLA'lı olarak sunar. Sisteminizin on yılını birlikte güvenceye alalım.