Platform Ekibi: Altyapı Değil, İç Ürün

Sahadan: 63 ticket ve 41 gün

Platform ekibini Mart’ta kurduk. Üç kişi: iki kıdemli backend mühendisi ve SRE geçmişi olan bir arkadaş. Görev tanımı tek cümleydi: “Altyapıyı onlar halletsin, ürün ekipleri ürüne baksın.” Kulağa mantıklı geliyordu. Dört ürün ekibinin her biri kendi pipeline’ını, kendi log formatını, kendi alarm kurallarını tutuyordu. Yeni bir servisi ilk kez canlıya çıkarmak ortalama 6 gün sürüyordu.

Altı ay sonra o sayı 11 gündü. Ürün ekiplerinin altyapıya harcadığı zaman %18’den yalnızca %15’e inmişti. İki ekip, beklemek yerine kendi pipeline’ını yeniden yazmıştı. Platform ekibi ise şirketin en yoğun ekibiydi: haftada 30 ticket kapatıyor, akşamları da çalışıyordu.

Kimse tembel değildi. Sorun tanımdaydı ve tanımı ben yazmıştım. Ekibi sahip olduğu şeylerle tanımlamıştım: Kubernetes, pipeline, log altyapısı. Kime hizmet ettiğiyle tanımlamamıştım. Sahip olduğu şeylerle tanımlanan ekip, o şeylere dokunmak isteyen herkesin kapısında sıraya girdiği bir gişeye dönüşüyor.

Ne zaman kurulur?

“Kaç ekipte platform ekibi kurulur?” sorusunun tek başına cevabı yok. Ekip sayısı bir işaret, ama asıl ölçü tekrar eden acı. Geriye dönüp baktığımda kuruluş kararı doğruydu; yanlış olan, kurduktan sonra yaptıklarımızdı. Karar anında baktığımız üç sinyal şunlardı:

Üçüncü satırı tahminle değil, ölçümle doldurduk: iki hafta boyunca herkes işini “ürün” ya da “altyapı” diye etiketledi. %18 çıktı. Yani dört kişilik bir iş, dört ekibe dağılmış hâlde ve dört farklı biçimde yapılıyordu. Üç kişilik bir ekip kurmak bu hesapta ucuzdu.

Erken kurmanın da bir bedeli var. İki ekipte platform ekibi kurmak, iki ekibin ortak bir kütüphaneyle çözebileceği işe yönetim katmanı eklemek demek. Bir de şu tuzak var: platform ekibini ürün ekiplerine “uymayan” insanları koyacak bir yer olarak görmek. O ekip, ürün ekiplerini en iyi tanıyan insanlardan kurulmalı. Tersi değil.

İç müşteri: kim, ne istiyor?

Eylül’deki tabloyu görünce ilk yaptığımız şey, platform ekibinin müşterisini adıyla yazmak oldu: ürün ekiplerindeki 22 mühendis. Bir iç müşterinin dış müşteriden tek farkı var: fatura ödemiyor. Bir benzerliği daha var ve genelde unutuluyor: seni seçmek zorunda değil. İki ekibin kendi pipeline’ını yeniden yazması, müşterinin rakip ürüne geçmesiydi.

Sonra müşteriyle konuştuk. 22 kişiyle yirmişer dakika, üç sabit soru:

1. Son bir ayda altyapı yüzünden seni en çok ne bekletti?
2. Her yeni serviste hangi işi baştan yapıyorsun?
3. Platform ekibine en son ne için yazdın?

Cevapları ticket kuyruğuyla yan yana koyduk. 63 ticket’ın 44’ü, yani %70’i üç türdendi: yeni servis iskeleti (pipeline, dashboard, alarm), secret ve erişim talebi, log ve izleme ayarı. Kuyruk kaotik görünüyordu. Aslında üç ürünün eksikliğiydi.

Buradan tek bir kural çıkardık ve ekibin çalışma biçimini bu kural değiştirdi: aynı ticket üçüncü kez gelirse ürün olur. İlk ikisi elle çözülür. Üçüncüsü geldiğinde o iş kuyruğa değil, platform ekibinin yol haritasına girer: self-servis bir komut, bir şablon ya da bir form. Böylece ekip her gelen isteği tek tek karşılamak yerine, isteği gereksiz kılacak şeyi inşa etmeye başladı.

Golden path: tek yol değil, en kolay yol

Golden path, bir servisi açmanın ve çalıştırmanın önerilen ve desteklenen yolu. Tek komutla repo, pipeline, dashboard, temel alarmlar, ortak log formatı ve secret erişimi hazır geliyor. Ürün ekibinin dokunması gereken tek şey kendi kodu. Bizdeki hâli şöyle:

$ platform yeni-servis --ad emir-bildirim --ekip emir
[1/6] repo olusturuldu          : emir-bildirim
[2/6] pipeline sablonu baglandi : build, test, staging, prod
[3/6] log formati + trace       : ortak paket v2
[4/6] dashboard + 3 temel alarm : p95, hata orani, kuyruk lag
[5/6] secret erisimi            : kasa/emir-bildirim (sadece ekip)
[6/6] sahiplik kaydi            : ekip=emir, nobet=emir-nobet
sure: 38 dk
# ilk deploy icin kalan tek adim: kodun kendisi ve review

Altıncı adımı sonradan ekledik ve en az dikkat çeken ama en çok işe yarayan adım o oldu: servis doğduğu anda bir sahibi, bir nöbet listesi ve bir alarm kanalı oluyor. Sahipsiz servis, bu komuttan çıkamıyor.

Asıl ders ise ilk sürümden geldi. Temmuz’da şablonun ilk hâlini yayınladık ve kural koyduk: yeni servisler şablonla açılır. Şablon sadece HTTP servislerini destekliyordu; batch işleri ve kuyruk tüketicileri için bir karşılığı yoktu. İki ekip şablonla açıyormuş gibi yapıp içini boşalttı. Üç hafta sonra bir alarm yanlış kanala düşünce fark ettik. Kimse kuralı çiğnemek istememişti; kural, işlerini yapmalarına engel oluyordu.

Zorunluluğu kaldırdık, yerine iki destek seviyesi koyduk. Yoldan çıkmak serbest, ama bedelini çıkan öder:

Golden path’in işe yarayıp yaramadığını anlamanın tek yolu bu: zorunlu değilken insanlar onu seçiyor mu? Seçiyorsa ürün iyidir. Seçmiyorsa sorun kullanıcıda değil, üründedir.

Nasıl bozulur: ticket kuyruğuna dönüşen platform

Bizim Eylül tablomuz tek bir kötü kararın değil, birbirini besleyen birkaç alışkanlığın sonucuydu. Geriye bakınca işaretler ortadaydı:

• Başarıyı kapatılan ticket ile ölçtük. Haftada 30 ticket iyi bir sayı gibi görünüyordu. Oysa her kapatılan ticket, bir sonraki ekibin aynı ticket’ı açacağı anlamına geliyordu. Metrik kuyruğu ödüllendiriyordu, kuyruğu yok etmeyi değil.
• Kapsam sessizce büyüdü. Veritabanı yedekleri, maliyet raporları, güvenlik taramaları, “şu dashboard’a bir panel ekler misiniz”. “Altyapıyla ilgili” olan her şey platform ekibinin sayıldı. Üç kişilik ekip, kimsenin istemediği her işin adresi oldu.
• Sahiplik sınırı kaydı. Platform ekibi yolun sahibiydi, ama zamanla servislerin de sahibi gibi davranılmaya başlandı: “Pod yeniden başlıyor, platform baksın.” Ürün ekibi kendi servisinin nöbetini tutmazsa, platform ekibi bütün şirketin nöbetçisine dönüşür.
• Yol haritası kuyruğun arkasında kaldı. “Kuyruk bitince şablonu düzeltiriz.” Kuyruk hiç bitmedi, çünkü kuyruğu bitirecek olan şey tam da o şablondu.

Sınırı sonunda tek cümleyle yazdık: platform ekibi yolun sahibidir, üzerinde giden servislerin değil. Servis, nöbetiyle, alarmıyla ve olaylarıyla ürün ekibinindir.

Ne izlemeli?

Platform ekibini bir ürün ekibi gibi ölçmeye başladığımızda baktığımız sayılar değişti. Eylül’den Aralık başına, üç ayın tablosu:

Golden path dışında kalan üç servisin peşine düşmedik. Biri eski bir batch işi, ikisinin gerçekten farklı ihtiyaçları var. 14’te 14 hedeflemek, zorunluluğu arka kapıdan geri getirmek olurdu. Bu tabloyu bir karne gibi kullanmamaya da dikkat ettik; amaç ekibi puanlamak değil, nereye bakacağını bilmek.

Bende işe yaramayanlar

• Ticket için SLA koymak. “Her ticket 3 günde kapanır” dedik. Kuyruk hızlandı ama küçülmedi; ekip daha hızlı bir gişe oldu, o kadar.
• Ürün ekiplerinden rotasyonla insan almak. İki haftalığına bir ürün mühendisinin platform ekibine geçmesi fikri kâğıtta güzeldi. İki hafta bir şey öğrenmeye yetmedi, altı hafta sonra bıraktık. Ürün ekiplerini tanıyan insanlar kalıcı olarak platform ekibinde olmalı.
• Şablonu yazıp duyurmak. Temmuz’daki duyurudan sonra benimsenme 3 servisti ve öyle kaldı. Sayı, platform ekibinden biri her yeni servisin ilk gününde ürün ekibinin yanına oturmaya başlayınca arttı.

Kontrol listesi

Sonuç

O Salı sabahı 63 ticket’a bakarken ilk düşüncem ekibe bir kişi daha eklemekti. Eklesem kuyruk biraz daha hızlı erirdi ve altı ay sonra aynı tabloya daha büyük bir ekiple bakıyor olurdum. Eksik olan kapasite değildi; ekibin kime hizmet ettiğini bilmesiydi.

Platform ekibi, ürün ekiplerinin her hafta tekrar ettiği işi bir kez, iyi ve seçilebilir biçimde yapan ekiptir. Bunu yapınca kuyruk kendiliğinden küçülüyor, çünkü insanlar artık istemek yerine kendileri yapabiliyor.

Test basit: yarın platform ekibine ticket açmak yasaklansa, ürün ekiplerin işini yapabilir mi? Yapabiliyorsa bir ürünün var. Yapamıyorsa bir gişen var.