Her Oracle Database Kullanan Kurumun Ödediği Görünmez Vergi

Kritik sistemlerinizde "ne olduğunu kimse tam bilmiyor" demenin gerçek bedeli ve bu bedelin neden hiçbir bütçe kaleminde doğrudan görünmediği.

Seri · Yazı 1/?

Öncelikle zihninizde bir kriz sahnesini imajine etmeye çalışalım.

7/24 çalışan bir uygulamada yavaşlık var; hizmet masası kayıtları doluyor ya da 7/24 ekibi fark etti, APM tool dashboard ekranlarındaki yeşil renk tek tek sarıya kayıyor, problem alert sayısı artıyor, erken müdahale gelmezse kırmızıya dönecek her şey çok belli... On beş dakika içinde bir kriz masası kuruluyor: hizmet masası sorumlusu, uygulama ekibi, veritabanı ekibi, middleware ekibi ... Her ekip kendi bulgularını sırayla ayrı ayrı ekranlar share ederek paylaşıyor, screenshotlar atılıyor. Uygulama ekibi "bizim taraf temiz, kod değişmedi gecikme şu serviste olabilir mi?" diyor. Sorun yaşandığı şüphesi ile o diğer pas atılan uygulama sahibi de kriz masasına alınıyor. "O da bizim taraf temiz sorun veritabanı olabilir mi? " diyor. Veritabanı ekibi "sorgular normal sürüyor, sorun bizde değil" diyor. Altyapı ekibi "ağda kayıp yok" diyor. Her ekip haklı ama sorun hâlâ devam ediyor.

Bu sahneyi okurken muhtemelen spesifik bir anı hatırlamadınız, çünkü farklı frekanslarda sürekli olan bir vaka bu. Oracle Database üzerinde çalışan yani çok kritik sistemleri olan hemen her kurumda, yılda birkaç kez, bazen ayda birkaç kez tekrarlayan bir pattern bu. Bankada gün sonu mutabakatı, sigortada hasar dosyası akışı, telekomda faturalama penceresi... isimler değişiyor, koreografi aynı kalıyor.

Bizim çıkış noktamız da tam burası. Bu kriz masalarında biz de çok bulunduk; üstelik çoğu zaman masanın "suçlanan" tarafında, kendimizi; sorumlu olduğumuz uygulamadan kaynaklandığını/kaynaklanmadığını ispat edecek ortak doneler ararken bulduk. Bizden kaynaklandığına emin olduğumuz durumlarda ise, onca harcanan vakit tamamen bize atanmış oldu. Ne büyük bir stres...

Yıllar içinde tek bir şeyi fark ettik: bu kriz masalarının asıl maliyeti, herkesin konuştuğu kesinti süresi değil. En büyük maliyet, kimsenin faturasını kesemediği bir vergi.

Görünmeyen kalem

Bir kesinti bittiğinde geriye dönüp baktığımızda genelde tek bir sayı konuşulur: "Sistem kırk dakika yavaştı/durdu." Oysa o kırk dakikanın içinde gerçekte harcanan şey çok daha pahalı bir şeydi.

O kriz anında masada bulunan 3 senior developer, ertesi gün yapacakları işi yapmadılar. O ekip, sorunun çözümüne değil, teşhisine zaman harcadı -ki kritik olaylarda harcanan sürenin büyük kısmı, düzeltmek değil, "ne olduğunu anlamaktır." Çözüm çoğu zaman çok kısadır; ondan önceki üç saat, hangi katmanın suçlu olduğunu bulmaya gider.

Bu sürenin üstüne, her tekrarda biraz daha aşınan birkaç şey daha eklenir: ekipler arası güven... Hele bir de turnkey bir proje sahibi olarak oradaysanız, dış kaynak firmaya olan güveni de aşındırmış olur. Uygulama, Middleware, Veritabanı ve Network ekibinin birbirini varsayılan olarak suçladığı bir kurumda, bir sonraki olayda teşhis daha da yavaşlar, çünkü artık herkes önce kendini savunmak, sonra problemi çözmek zorundadır. Bu, bilançoda görünmez. Ama her kriz masası çağrısında oradadır.

Ve bunların hiçbiri tek bir gider kaleminde toplanmaz. Senior/Engineer saati farklı bir hesaba, SLA cezası başka bir hesaba, müşteri kaybı bambaşka bir yere yazılır. Regülatöre verilecek bir açıklama hiçbir yere yazılmaz ta ki birinin çıkıp artık bir kaydını tutalım ya da çözüm bulalım diyene kadar. İşte bu yüzden görünmez: dağıtık olduğu için kimse toplamını görmez; toplamını gören olmadığı için kimse sahiplenmez; sahiplenen olmadığı için de yıllarca aynı bedel ödenmeye devam eder. Kurumlar buna "kritik sistem işletmenin doğal maliyeti" der ve normalleştirir. Hatta sürekli olan bir vaka olduğu için, kurumlar bütçeye gider kalemi olarak zaten bunu eklemiştir. Tam da bu sebeple artık "kanıksanmış kronik" bir sorun haline gelir. "Kanıksanmış kronik": artık bütün ekiplerce bilinen ve çözülmeyeceğine el sıkışılmış bir problem demektir. Kimsenin artık bu sorunla ilgilenmemesi gerektiğinin, palyatif çözüm olarak ne yapılmışsa sürekli onu uygulamaya devam edelim demenin bir nevi anlaşmasıdır.

Biz bu normalleşmeye/normalleştirmeye, geçiştirmeye, "anlık sorun olmuş" retoriğine ve çözümsüz anlaşmaya ikna olmadık.

Neden arada bir meydana geliyor?

Bu pattern'in tekrar etmesinin nedeni, ekiplerin yetersizliği değil. Çoğu zaman masadaki kişiler kurumun en iyileridir. (Junior engineer de masada vardır, ah ne güzeldir bu problemler onun için... Başka makale konusu yapalım bunu, şimdi arada kaynamasın.) Sorun, herkesin gerçeğin yalnızca kendi dilimine bakıyor olması.

Bir müşteri isteğinin başına ne geldiğini düşünün: istek uygulamaya düşer, uygulama bir veritabanı sorgusu çalıştırır, o sorgu ağ üzerinden Oracle'a gider, Oracle içeride bir şeyler yapar, cevap geri döner, bu arada bir veri değişir, belki bir başka işlem o veriyi bekler. Belki de en görünmez olan kısımlarda, ilgili tablodaki bir constraint'in bağlı olduğu referans tablosunda index olmamasından kaynaklıdır. (Bu teknik detaylar da başka bir makale konumuz olsun) Bu chain'in her halkasını farklı bir ekip, farklı bir araçla, farklı bir zaman damgasıyla izler. Uygulama ekibinin saatiyle veritabanı ekibinin saati birebir tutmaz. Datasource kullanımından dolayı database kullanıcısı başkadır, uygulamada sorun yaşayan müşteri kullanıcısı başkadır. Birinin "yavaş" dediği sorgu, diğerinin ekranında "normal" görünür. Çünkü ikisi aynı olaya iki ayrı pencereden, ortak bir referans noktası olmadan bakmaktadır.

Sonuç: kimsenin yalan söylemediği ama hiç kimsenin de bütünü göremediği bir oda. Siyah bir duvarda niş var; kocaman olsa herkes görür, çok küçük ise nişi kim görebilir? İşte o kriz masasının saatlerce sürmesinin sebebi budur. Her ekip, tarafsız olduğuna inanılan birinin çıkıp "buldum! niş burada" demesini bekler. Bu yapısal nedene serinin ikinci yazısında deep dive dalacağız, didik didik edeceğiz; şimdilik şu kadarını söyleyelim : Bu, bir araç eksikliğinden çok, ortak bir gerçeğin yokluğudur.

Kendi verginizi hesaplayın

Bu vergiyi somutlaştırmanın en sağlam yolu, sektör ortalamalarına bakmak değil; o rakamların çoğu sizin kurumunuza uymaz. En gerçek sayı, kendi tablonuzdan çıkar. Birkaç soru yeterli:

Yılda kaç kez kritik bir sistemde "ne olduğunu anlamak için" bir kriz masası kuruluyor? Her birinde ortalama kaç senior engineer, ne kadar süre masada kalıyor? Bu sürenin yüzde kaçı çözüme, yüzde kaçı teşhise gidiyor? Yani "kimin suçlu olduğunu bulmaya" gidiyor? Bu olayların kaçında müşteriye dokunan bir akış etkilendi? Kaçında bir SLA eşiği aşıldı?

Tabii ki "Incident Management" uygulamaları var ve orada kayıtlı her şey... Başka bir şeyi irdelemeye gayret ediyoruz.

Bu beş soruyu dürüstçe yanıtlayıp çarptığınızda ortaya çıkan sayı, çoğu kurumda sürpriz olur. Üstelik bu, yalnızca doğrudan maliyettir. Asimetrik olanı, tek bir uzun kesintinin müşteriye/insana dokunan bir sistemde yarattığı itibar zararını, ya da tek bir regülatör bulgusunu; bu hesaba henüz katmadık. O kalemler nadirdir; ama bir kez gerçekleştiğinde, yılların görünmez vergisini tek seferde gölgede bırakır.

Kurumun o yılki hedeflerinin zirvesinde "müşteri memnuniyeti'ni" artırmak vardı oysa, çok alakasız gibi görünen yerden bütün departmanların ekstra bu hedef için gayretleri negatif etkilendi. Şimdi bütün departmanlar da artık ayrı ayrı hedefe gidemedikleri için kendilerini aklamak zorunda. Aklanmak için verilmesi gereken ekstra çaba yine...

Görünürde alakasız olan bu departmanlar arası ilişki bağlamını çözmeye gerek var mı gerçekten?

Neden tam da Oracle Database kullanan sistemlerde

Bu vergi her sistemde vardır; ama Oracle Database taşıyan kurumsal sistemlerde özellikle çok yüksek ve pahalıdır. Sebep basit: bunlar genellikle kurumun dokunulmaya en çok korkulan core sistemleridir. Çekirdek defteri, poliçe içeriği, abonelik ve faturalama omurgasını bunlar taşır. Yeni kampanya mı var? data ve table relation artar. Regulatif bir istek mi var? data ve table relation artar...

Yıllar içinde katman katman büyümüşlerdir; çoğu zaman onları baştan sona anlayan son kişi çoktan emekli olmuştur. Artık günümüzde herkes kendi sorumluluğu dışında hiçbir şeyi anlamaya çalışmadığı için ya da şöyle diyelim, mikro sorumluluklar ile uygulamalar yönetildiği için zaten baştan sona anlayana deli gözüyle bakarlar. "Biz buna bu işi vermedik, kafasına göre gitmiş öğrenmiş bak sen şuna! Senin zamanını şu kişi planlıyor, kafana göre öğrenme bizim dediğimizi yap/öğren yeter!" (Bunu da başka bir makalede ele alalım artık. Tabiii ki ajite ettiğimin farkındayım.)

Tam da bu kritiklik, körlüğü en pahalı hale getirir. Önemsiz bir iç servisin neden yavaşladığını bilmemek katlanılabilir. Gün sonunda mutabakatın neden tutmadığını, bir hasar ödemesinin hangi adımda takıldığını bilmemek, bir hastanın hastanede provizyon için onay beklemesi, otomobilini servisten teslim alacak kişinin aracını 1 gün geç alması katlanılamaz. Sistem ne kadar kritikse, "ne olduğunu bilmemenin" bedeli o kadar yükselir ve bu sistemlerin hepsi kritiktir.

Bu seri neden var

Şimdilik şunu bilmenizi isteriz: bu yazıyı, bir ürün satmak için değil, yıllarca ödediğimiz bir vergiyi adıyla koymak için yazıyoruz. O kriz masasında oturduk, hem suçlayan hem suçlanan tarafta. Bir noktada şunu sorgulamaktan vazgeçemedik: bu kriz günlerinin böyle geçmesi gerçekten kaçınılmaz mı, yoksa kabullendiğimiz için mi böyle?

Bu seride önce problemi konuşacağız; dürüstçe, baştan sona. Suçlama savaşının neden yapısal olduğunu, problem tracking'in tam da en kritik yerde neden karardığını, gerçeğin diğer yarısının yani "kim neyi değiştirdi" sorusunun neden hep ayrı bir ambarda kaldığını, problem görmenin/görünülebilirliğin neden bu kadar pahalı bir lükse dönüştüğünü tek tek ele alacağız. Hangi toolların bu problemleri neden çözmediğini de konuşacağız.

Bir kurum bu vergiyi yıllarca ödeyebilir ve hiç fark etmeyebilir. Fark eden kurumlar için ise ilk adım, onu görmek/görünür kılmak. Bu serinin tamamı, o görünmez kalemi masaya koyma çabası.

Sırada ne var

Bir sonraki yazıda en sık duyduğumuz dört cümleyle başlayacağız, aslında içerik aynı ama dile getiren katmanlar farklı: "Middleware değil.", "Veritabanı değil.", "Uygulama değil." ve "Network değil." Dördü de aynı anda doğru olabiliyorsa, suçlu kim? Suçlama savaşının neden bir karakter zafiyeti değil, sistemlerimizi kurma biçimimizin doğrudan bir sonucu olduğunu konuşacağız.

Bu yazı, Oracle üzerinde kritik sistemler işleten kurumlardaki gözlemlenebilirlik ve değişim takibi sorunlarını ele alan bir yazı serisinin ilkidir.