Reorg: Kutu Çizmek Değil, İletişim Yolu Seçmek

Sahadan: 140 çağrı ve boş bir kanal

Reorg’u 6 Ekim Pazartesi duyurduk, 13 Ekim’de yürürlüğe girdi. 22 mühendis, katmana göre bölünmüş dört ekipten akışa göre bölünmüş dört ekibe geçti. Eski yapı: Backend Çekirdek (7), Web (5), Mobil (6), Veri (4). Yeni yapı: Hesap Açılış (5), Emir (6), Para Transferi (6), Raporlama ve Destek (5).

1 Kasım Cumartesi, gece 02:00’de aylık ekstre işi çalıştı ve bir bağımlılığın zaman aşımıyla yarıda kaldı. Alarm çaldı, #backend-cekirdek-alarm kanalına düştü. Kanal arşivlenmemişti, ama içinde iki kişi kalmıştı; ikisi de artık Emir ekibindeydi ve kanalı sessize almıştı. Cumartesi ve Pazar kimse bakmadı. Pazartesi sabahı destek ekibi 140 çağrıyla geldi. Ekstreler 18.400 müşteriye aynı gün 16:20’de gitti, yaklaşık 62 saat gecikmeyle. Uyum ekibinin ilk sorusu “süre aşıldı mı?” oldu. Aşılmamıştı. Ama bunu planla değil, şansla başardık.

Sabah iki ekibe sordum: “Ekstre işi kimin?” Hesap Açılış ekibi “rapor olduğu için Raporlama’nın” dedi. Raporlama ekibi “hesaba ait olduğu için Hesap’ın” dedi. İkisi de makul bir cevaptı. İş, eski Backend Çekirdek ekibinin cekirdek-batch reposunda duran altı işten biriydi. Yeni yapıyı çizerken repoları “ana servislerine” göre dağıtmıştık; o repo hiçbir ana servise ait değildi, o yüzden kimseye düşmedi.

Hata benimdi. Reorg’u bir insan dağıtımı olarak planlamıştım: kim hangi ekibe gidiyor, kim kime bağlı. Bir iş dağıtımı olarak planlamamıştım. Organizasyon şemasında 22 isim vardı ve hepsi bir kutudaydı. Kutuların dışında kalan tek şey, gece 02:00’de çalışan bir işti.

Reorg neyi değiştiriyor: Conway’in öbür yüzü

Conway yasası kısaca şunu söylüyor: sistemler, onları üreten organizasyonun iletişim yapısını taklit eder. Bu yasa genelde ekip kurarken anılıyor. Mevcut bir yapıyı değiştirirken ise öbür yüzü önemli hâle geliyor: kod, eski iletişim yapısını hatırlıyor. Dört yıl boyunca katmana göre çalışan bir ekip, katmana göre bölünmüş bir kod bırakıyor. İnsanları bir gecede yeniden dağıtabilirsin; kodu dağıtamazsın.

Neden reorg yaptığımızı da buradan anlatmak gerek. Son çeyrekte biten 30 işin 21’i en az iki ekibe dokunuyordu, 9’u üçüne birden. “Para çekme ekranına bir alan ekle” gibi bir iş Web, Mobil ve Backend Çekirdek arasında dolaşıyordu. Ekipler arası ortalama bekleme 4,5 gündü. Sorun kimsenin yavaşlığı değildi; her iş üç ekibin takvimine aynı anda sığmak zorundaydı.

Reorg’un asıl yaptığı şey şu: hangi konuşmanın ucuz, hangisinin pahalı olacağını seçiyor. Aynı ekibin içindeki konuşma ucuzdur; daily’de, masada, bir mesajla olur. Ekipler arasındaki konuşma pahalıdır; toplantı, ticket, bekleme ister. Kutuları çizerken aslında şu soruyu cevaplıyorsun: önümüzdeki iki yıl boyunca hangi insanlar birbirini beklemeden çalışabilsin?

Bizim cevabımız “bir müşteri akışını baştan sona değiştiren insanlar” oldu. Bunun bedeli de hemen ortaya çıktı: cekirdek-api. Eski yapıda tek ekibin servisiydi; yeni yapıda dört ekip de ona yazıyordu. İlk ayda üç çakışan sürüm ve bir geri alma yaşadık. Çözüm servisi bölmek değildi, en azından henüz değil: tek bir sahip (Emir ekibi) koyduk, diğer ekipler PR açıyor, sahip ekip inceliyor ve sürümü o çıkarıyor. Ortak kod, ortak sahiplik demek değil.

Sahiplik haritası: şemadan önce

Olaydan sonraki iki gün, dört kişi sadece bir liste çıkardı: şirkette çalışan her şey ve sahibi. Servisler, zamanlanmış işler, kuyruklar, dashboard’lar, dış entegrasyonlar. Toplam 41 bileşen. 9’unun sahibi yoktu, 5’inin iki sahibi vardı. Sahipsiz 9’un 6’sı zamanlanmış işti. Bu tesadüf değil: cron işi kimseyle konuşmaz, sadece çalışır, o yüzden kimse onu hatırlamaz.

Organizasyon şemasında görünen ile sahiplik haritasında görünen arasındaki fark şöyle:

Haritayı bir wiki sayfasına değil, repoya koyduk. Her bileşen bir kayıt, CI her PR’da kontrol ediyor. İki kural var: sahibi olmayan bileşen deploy edilemez, ve alarm kanalında sahip ekipten kimse yoksa CI uyarı veriyor. Ekstre işinin bugünkü kaydı şöyle:

# repo kokunde durur; CI her PR'da dogrular
- bilesen    : ekstre-isi
  tur        : cron (her ayin 1'i, 02:00)
  ekip       : raporlama-destek          # tek ekip, iki ekip yazilamaz
  nobet      : raporlama-nobet
  alarm      : "#raporlama-alarm"        # CI: kanalda ekipten biri var mi?
  eski_sahip : backend-cekirdek          # ikinci hat, 30 gun
  ikinci_hat : 2025-12-05'e kadar
  dis_temas  : yok
  not        : "bagimli servis zaman asimi 30 sn; ayin 1'i yuk 3 kat"

O dönemde golden path’ten açılan yeni servislerin zaten bir sahiplik kaydı vardı (platform ekibi yazısında anlattığım altıncı adım). Sorun çıkaranlar, o adım yokken açılmış eski bileşenlerdi. Haritanın asıl işi yeni şeyleri değil, eskileri kayda geçirmek.

Duyuru: slayt değil, harita

Duyuruyu 6 Ekim’de 45 dakikalık bir toplantıyla yaptık. Tek slayt: dört kutu, içlerinde isimler. Sorulara 15 dakika ayırdık. Gelen sorular kutularla ilgili değildi: “Benim yazdığım ödeme entegrasyonu ne olacak?” “Mobil sürüm çıkışını artık kim yapıyor?” “ekstre-isi kimin?” Son soru aynı öğleden sonra Slack’te de soruldu ve iki gün cevapsız kaldı. Üç hafta sonra cevabını 140 çağrıyla aldık.

İnsanlar reorg duyurusunda “hangi kutudayım?”dan çok “işim ne olacak?” sorusunu soruyor. Bugün aynı işi yapsam sıra şöyle olurdu:

1. Harita önce. Duyurudan önce her bileşenin yeni sahibi yazılı.
2. En çok etkilenenlerle önce birebir. İşi en çok değişen kişiler kutuyu slayttan öğrenmemeli.
3. Duyuruda harita da var. Slaytta kutular, ekte “senin servislerin nereye gidiyor” tablosu.
4. Neden, rakamla. “30 işin 21’i iki ekibe dokunuyor” cümlesi, “daha çevik olacağız” cümlesinden daha çok ikna ediyor.

Geçiş dönemi: takvime yazılır

“13 Ekim itibarıyla yeni yapıdayız” cümlesi bir tarih söylüyor, bir süreç söylemiyor. Oysa bilgi insanların kafasında taşınıyor ve kafalar bir günde boşalmıyor. Olaydan sonra geçiş dönemini yazılı hâle getirdik:

“İlk bağımsız deploy” kuralı en çok işe yarayanı oldu. Devir oturumu bir konuşma; yeni ekip “anladık” diyor ama anlayıp anlamadığını kimse bilmiyor. Bir değişikliği eski sahibe sormadan canlıya çıkardığında ise biliyorsun. 41 bileşenin 36’sı ilk 30 günde bu eşiği geçti. Kalan 5’in ikinci hattını 15 gün uzattık.

Nasıl bozulur

• Sadece insanlar taşınır. Kutular değişir, kod sahipliği, nöbet listesi ve alarm yönlendirmesi eski yerinde kalır. Kâğıtta yeni yapı, sahada eski yapı çalışır.
• “Ortak” bileşenler. İki ekibin ortak sahip olduğu şey, pratikte ikisinin de sonraya bıraktığı şeydir. Sahiplik tek ekibe yazılır; katkı herkese açık olabilir.
• Geçiş dönemi olmadan geçiş. Eski sahip ertesi gün yeni işine gömülür; sorulara “artık bizim değil” diye bakar. Kötü niyet değil, önceliklerin doğal sonucu.
• Reorg’u reorg ile düzeltmek. İlk yapıdaki sorun sahiplikse, yeni kutular çizmek sorunu taşır, çözmez. İki reorg arasında en az bir yıl olmadan kimse yeni yapının iyi mi kötü mü olduğunu bilemez.

Ne izlemeli?

Bir şey de kötüleşti ve bunu yazmadan tablo eksik kalır. Beş web geliştiricisi dört ekibe dağılınca arayüz tutarlılığı bozuldu: altı hafta içinde iki farklı tarih seçici canlıya çıktı. Ortak bileşen kütüphanesine tek bir sahip (Raporlama ve Destek) ve web geliştiricilerine haftalık yarım saatlik bir buluşma koyduk. Katmana göre bölünmenin tek iyi yanı buydu; reorg onu da götürdü ve geri getirmek için ayrıca iş yapmak gerekti.

Kontrol listesi

Sonuç

O Pazartesi sabahı kimse işini kötü yapmamıştı. Alarm çalıştı, destek ekibi aradı, iki ekip de makul bir cevap verdi. Eksik olan tek şey, ekstre işinin herhangi birinin listesinde olmasıydı. Reorg’u kutularla planladığım için, kutuya girmeyen şey de planın dışında kaldı.

Bir reorg’da çizdiğin şey kutular değil, iletişim yolları. Kimin kiminle ucuza konuşacağını seçiyorsun; kod da zamanla o konuşmaların şeklini alıyor. O yüzden önce işleri dağıtmak, sonra insanları dağıtmak gerekiyor.

Reorg bittiğinde herkesin yeni bir ekibi olur. Asıl soru, her şeyin yeni bir sahibi olup olmadığıdır.