Incident sırasında “kim bakıyor?” sorusunun yanıtı dakikalarca aranıyorsa, teknik ekip aslında zaman kaybediyordur. Bu kayıp genelde kimsenin kötü niyetinden değil; servis sınırlarının, sahipliğin ve karar akışının net olmamasından doğar.
Bu yazıda, sahada işe yarayan pratik bir yaklaşımı anlatıyorum: servis sahipliği haritası + RACI. Hedef “bürokrasi” değil; on-call, değişiklik ve erişim kararlarını hızlandıran bir operasyonel netlik.
Problem: Sahiplik belirsizliği teknik borç kadar pahalıdır
Belirsizlik şu semptomlarla kendini belli eder:
- Alert geliyor ama “owner” yok; triage uzuyor
- Değişiklikler “herkesi bilgilendirdik” diye geçiyor, ama kim onayladı belirsiz
- Güvenlik istisnası isteniyor, “kim risk alacak?” ortada kalıyor
- Runbook var ama “güncelleme sorumlusu” yok
RACI nedir ve neden pratik?
RACI dört rol tanımlar:
- R (Responsible): işi yapan (uygulayan)
- A (Accountable): sonuçtan sorumlu olan (son karar)
- C (Consulted): danışılan (girdi veren)
- I (Informed): bilgilendirilen
Bu modelin değeri, tek bir cümleye indirgenebilir:
Aynı işte “Responsible” çok olabilir, ama “Accountable” tek olmalı.
Servis sahipliği haritası: Minimum alan seti
Ben servis kataloğunu şöyle başlatırım (en yalın hali):
- Servis adı + kısa tanım
- Owner takım (A)
- On-call rotası / pager (R)
- SLO + kritik kullanıcı yolculuğu
- Bağımlılıklar (DB, queue, upstream/downstream)
- Runbook ve dashboard linkleri
- Değişiklik onay modeli (kim, hangi riskte?)
Bu bilgiler wiki’de kalırsa ölür. Daha iyi çözüm: repo içinde yaşayan bir dosya (örn. service.yaml) ve PR ile güncellenen standart.
RACI’yi nereye uygularım? (3 kritik akış)
1) Incident akışı
- R: nöbetçi mühendis + ilgili servis ekibi
- A: incident commander (seviyeye göre değişebilir)
- C: platform/network/security (ihtiyaca göre)
- I: iş paydaşları + destek ekipleri
Burada hedef “çok kişi” değil; doğru kişiyi hızlı bulmak.
2) Değişiklik (change) akışı
Değişiklikte en sık hata “review var ama risk sahibi yok”tur. RACI ile:
- R: değişikliği uygulayan ekip
- A: servis owner (riskin sahibi)
- C: bağımlılık sahibi ekipler (DB/network)
- I: operasyon paydaşları (destek, NOC)
3) Erişim ve istisna akışı
“Temporary access” bile olsa:
- R: erişimi sağlayan (IAM/PAM)
- A: servis owner (neden ve süre)
- C: security
- I: audit/log owner
Başlama stratejisi: “Top 20 servis” ile başla
Bu işi tüm kuruma bir günde yaymaya çalışmayın. Pratik yol:
- En çok incident üreten 20 servisi seç
- Her servise bir “Accountable” atayın
- Runbook + dashboard linklerini zorunlu kılın
- On-call ve escalation rota bilgisi ekleyin
- 4 hafta boyunca “ownership review” ritmi kurun
Başarı ölçümü: Süreç değil, sonuç
RACI’nin işe yarayıp yaramadığını şu metriklerden anlarsınız:
- Alert’ten doğru owner’a atanma süresi
- Incident’ta “owner arama” konuşmalarının oranı
- Değişiklik sonrası rollback / hotfix oranı
- “Bilinmeyen sahiplik” nedeniyle uzayan MTTR vakaları
Sonuç
Servis sahipliği haritası ve RACI, ekiplerin hızını kesen bir süreç değil; hızın güvenli hale gelmesi için bir çerçevedir. Sahipliği netleştirdiğinizde; on-call daha sürdürülebilir olur, değişiklikler daha kontrollü akar, incident’lar daha hızlı toparlanır. En önemlisi: tartışma değil, karar üretirsiniz.