Canlıya çıktıktan sonra ilk otuz gün: hazır altyapıda operasyon

Sabah 08.40’ta dizüstü bilgisayarımı açtığımda gelen kutusunda kırk yedi uyarı vardı. Üç tanesi ödeme sağlayıcısı webhook hatası, dört tanesi düşük bakiye bildirimi, geri kalanı ise canlı bahis motorundan gelen gecikme uyarılarıydı. Platform dün gece canlıya alınmıştı ve ben o sabah operasyon yöneticisi olarak koltuğa oturmuştum. Ne bir kontrol listem, ne bir nöbet planım, ne de “sorun çıkarsa kimi arayacağım” sorusunun cevabı vardı. Elimde sadece çalışan bir altyapı ve onu ayakta tutma sorumluluğu vardı. Bu yazı, Betco altyapılı site kurma sürecini tamamlayıp yayına geçmiş bir platformun devralınmasından sonraki ilk otuz günü, hafta hafta ve gerçekçi bir dille anlatıyor. Amaç teori değil; ilk ayda hangi rutinlerin kurulması gerektiğini, hangi risklerin geç fark edildiğini ve hangi alışkanlıkların sonradan pahalıya mal olduğunu göstermek.

Birinci hafta: envanter, erişim ve gerçek durum tespiti

İlk haftanın tek bir amacı olmalı: neye sahip olduğunuzu tam olarak bilmek. Hazır altyapıyla kurulmuş bir platform devraldığınızda en büyük yanılgı, “her şey zaten kurulu” varsayımıdır. Kurulu olan şey koddur; kurulu olmayan şey ise süreçtir. Bu yüzden ilk üç günü üç envanter çıkarmaya ayırdım: teknik envanter (sunucular, servisler, veritabanları, üçüncü taraf entegrasyonlar), erişim envanteri (hangi panelde kimin hangi yetkisi var, hangi API anahtarı kimin elinde) ve süreç envanteri (ödeme onayı, bahis iptali, bonus tanımı, şikâyet çözümü gibi tekrarlayan işlerin şu an nasıl yapıldığı).

Bu envanter çalışması sırasında en çok zaman kaybettiren şey, “bunu kim ayarladı?” sorusunun cevapsız kalmasıydı. Hazır altyapı sağlayıcınız size çalışan bir sistem teslim eder, ancak o sistemin içindeki parametrelerin neden o değere ayarlandığını genellikle kimse yazılı olarak bırakmaz. Örneğin maksimum bahis limitinin neden o seviyede olduğunu, hangi oran sağlayıcısının neden birincil seçildiğini veya otomatik ödeme onayının hangi eşikte devreye girdiğini bilmeden müdahale etmek risklidir. İlk hafta boyunca her kritik parametre için tek satırlık bir gerekçe notu yazdım. Bu notlar sonradan ekip eğitiminin temeli oldu.

Birinci haftanın en kritik riski, erişim dağınıklığıdır. Yayına yeni girmiş platformlarda sıklıkla aynı API anahtarı birden fazla kişide bulunur, eski test hesapları hâlâ aktiftir ve yönetici panelinde gereğinden fazla yetkili kullanıcı vardır. Hafta sonuna doğru tüm yönetici hesaplarını gözden geçirdim, kullanılmayanları kapattım ve her kritik erişim için iki kişilik bir sorumluluk tanımı yazdım. Bu, ilk bakışta bürokrasi gibi görünür; ama ilk gerçek krizde kimin neye erişimi olduğunu bilmemek, dakikalar değil saatler kaybettirir.

İkinci hafta: nöbet düzeni, alarm yorgunluğu ve öncelik sıralaması

İkinci haftaya girdiğimde hâlâ her uyarıyı okuyordum ve bu sürdürülemezdi. Alarm yorgunluğu, yeni kurulmuş platformların en sinsi operasyonel hastalığıdır: çok fazla uyarı gelir, hepsi aynı sesle çalar, sonunda hiçbirini ciddiye almazsınız. Bu haftanın işi, uyarıları sınıflandırmak ve bir nöbet düzeni kurmaktı.

Uyarıları üç kategoriye ayırdım. Birinci kategori, anında müdahale gerektirenlerdi: ödeme sağlayıcı kesintisi, veritabanı bağlantı kopması, canlı oran akışının durması. İkinci kategori, aynı gün içinde çözülmesi gerekenlerdi: düşük bakiye, yavaş yanıt süresi, tekrarlayan kullanıcı hataları. Üçüncü kategori ise haftalık raporlamaya bırakılabileceklerdi: kapasite kullanım eğilimleri, kanal bazlı dönüşüm farkları, oyun bazlı performans sapmaları. Bu ayrımı yaptıktan sonra yalnızca birinci kategori için gerçek zamanlı bildirim bıraktım; diğerlerini özet raporlara taşıdım.

Nöbet düzeni konusunda öğrendiğim en önemli ders, “her zaman ulaşılabilir olma” tuzağıydı. İlk hafta telefonumu gece kapatmadım ve bu beni üçüncü günde tüketti. Sürdürülebilir bir model, açık bir devir teslim ritmi gerektirir: kimin hangi saat aralığında birincil sorumlu olduğu, kimin yedek olduğu ve bir sorun çıktığında hangi eşikte ikinci kişinin devreye gireceği yazılı olmalı. Bu ritmi kurduktan sonra hem tepki süremiz kısaldı hem de ekip yorgunluğu belirgin şekilde azaldı. Hazır altyapının sağladığı en büyük avantaj burada ortaya çıkıyor: sistem tarafında istikrar olduğu için, siz enerjinizi süreç tasarımına harcayabiliyorsunuz.

Üçüncü hafta: finans akışı, mutabakat ve gerçek sayıların doğrulanması

Üçüncü hafta, operasyonun en az heyecan verici ama en belirleyici kısmına ayrılmalı: para akışının doğrulanması. Yeni kurulmuş bir platformda ilk ayın sonunda en sık ortaya çıkan sorun teknik arıza değil, mutabakat farkıdır. Yatırım kayıtları ile sağlayıcı raporları arasında küçük farklar birikir; çekim talepleri ile ödeme çıktıları arasında zamanlama uyuşmazlıkları oluşur; bonus maliyetleri beklenenden farklı yansır.

Bu hafta boyunca günlük kapanış rutini kurmaya karar verdim. Her gün aynı saatte üç şey karşılaştırılıyor: platform içi işlem kayıtları, ödeme sağlayıcısı raporu ve banka hareketleri. Fark çıktığında nedenini aynı gün not ediyoruz. İlk birkaç gün bu iş yavaş ilerledi, çünkü hangi raporun hangi alanının hangi kayda karşılık geldiğini öğrenmek zaman aldı. Ancak haftanın sonunda artık on beş dakikada tamamlanan bir kontrol haline gelmişti.

Finans tarafında bir diğer kritik konu, ödeme sağlayıcı çeşitliliğidir. Tek sağlayıcıya bağlı kalmak, o sağlayıcıda yaşanan bir kesintide tüm yatırım ve çekim akışını durdurur. Bu hafta ikinci bir sağlayıcıyı yedek olarak devreye alma testi yaptık; amaç sürekli kullanmak değil, kesinti anında bir saat içinde geçiş yapabileceğimizi doğrulamaktı. Bu tür bir yedeklilik, hazır altyapıyla kurulmuş platformlarda genellikle teknik olarak mümkündür; eksik olan kısım çoğu zaman prosedürdür. Test sırasında öğrendiğimiz her adımı yazılı hale getirdik, çünkü kriz anında hafızaya güvenilmez.

Dördüncü hafta: raporlama ritmi, ekip eğitimi ve ilk otuz günün kapanışı

Son hafta, öğrendiklerimizi kalıcı hale getirme haftasıdır. Bu noktada artık günlük işler belli bir düzene girmiş olur; asıl soru şudur: bu düzen, siz olmadığınızda da çalışır mı? Bu soruya dürüst cevap veremiyorsanız ilk otuz gün tamamlanmamış demektir.

Bu hafta üç şey yaptım. Birincisi, haftalık operasyon raporu şablonu oluşturdum: haftalık işlem hacmi, ortalama yanıt süresi, açık destek talebi sayısı, ödeme başarı oranı, kesinti süresi ve öne çıkan üç risk. Rapor kısa tutulmalı; amaç kapsamlı bir belge üretmek değil, her hafta aynı sorulara aynı disiplinle cevap vermek. İkincisi, ekip için kısa bir eğitim oturumu düzenledim. Envanter notları, nöbet düzeni ve mutabakat prosedürü bu oturumun ana malzemesiydi. Üçüncüsü, ilk ayın olay kaydını yazdım: hangi sorun ne zaman çıktı, nasıl çözüldü, ne kadar sürdü ve bir daha olmaması için ne değişti.

Bu olay kaydı, sonraki aylarda en çok başvurduğum belge oldu. Çünkü operasyonda tekrarlayan sorunların çoğu, ilk seferinde yanlış çözüldüğü için geri gelir. Kayıt tutmak, aynı hatayı iki kez yapmayı engeller. Aynı şekilde, ekip eğitimi de tek seferlik bir etkinlik değil, sürekli bir alışkanlık olmalı. Yeni bir özellik devreye girdiğinde, yeni bir ödeme yöntemi eklendiğinde veya yeni bir pazar açıldığında bu eğitimin kısa bir güncellemesi yapılmalı.

İlk ayda en sık yapılan üç operasyonel hata

Devraldığım süreçte ve benzer platformlarda gözlemlediğim hataların ortak bir paydası var: hepsi aceleci iyimserlikten kaynaklanıyor. Birincisi, ölçüm olmadan iyileştirme yapmak. “Sistem yavaş” hissi ile hareket edip sunucu kaynağı artırmak, sorunun aslında bir sorgu verimliliği veya önbellek yapılandırması olduğunu görmenizi engeller. İkincisi, tüm kararları tek kişiye bağlamak. İlk ayda hızlı karar almak caziptir, ancak bu kararların gerekçesi yazılı değilse ekip öğrenmez ve siz izinli olduğunuzda süreç durur. Üçüncüsü, kullanıcı tarafındaki geri bildirimi teknik ekibe ham haliyle aktarmak. “Para yatırdım gelmedi” cümlesi bir belirtidir, kök neden değildir; hangi saatte, hangi yöntemle, hangi cihazdan yapıldığı bilinmeden çözüm üretmek zaman kaybıdır.

Bu hataların üçü de aslında aynı çözüme çıkıyor: yazılı ritim. Günlük kontrol, haftalık rapor, olay kaydı ve düzenli eğitim. Hazır altyapıyla kurulmuş bir platformda teknik temel zaten atılmış olduğu için, ilk otuz günün gerçek değeri bu ritimlerin kurulmasında yatar. Yazılı olmayan hiçbir süreç, ekip büyüdüğünde ayakta kalmaz.

Otuzuncu günün sonunda elde kalanlar

Otuzuncu günün sabahı gelen kutusuna baktığımda on bir uyarı vardı; üçü gerçek müdahale gerektiriyordu, geri kalanı rutin raporlara düşmüştü. İlk günkü kırk yedi uyarıdan bu noktaya gelmek, sistemin değişmesinden değil, bizim sistemle ilişkimizin değişmesinden kaynaklandı. Artık hangi sinyalin ne anlama geldiğini biliyorduk, kimin neyden sorumlu olduğu yazılıydı ve bir sorun çıktığında ilk refleksimiz panik değil, prosedüre bakmaktı.

İlk otuz günün en önemli çıktısı mükemmel bir operasyon değil, sürdürülebilir bir operasyon iskeletidir. Envanter, nöbet düzeni, mutabakat rutini, raporlama şablonu ve olay kaydı. Bu beş unsur oturduğunda, sonraki aylarda karşılaşacağınız büyüme, yeni pazar, yeni ödeme yöntemi veya kampanya yoğunluğu gibi konular panik yaratmaz; çünkü onları karşılayacak bir düzen zaten vardır. Yeni canlıya alınmış bir platformu devralan her operasyon yöneticisine tavsiyem şu olur: ilk ayın sonunda kendinize tek bir soru sorun. Ben bir hafta ortadan kaybolsam bu sistem çalışmaya devam eder mi? Cevap evetse, otuz günü doğru geçirmişsiniz demektir.