Otomasyonda 45 Dakikada 440 Milyon Dolar Nasıl Kaybedilir?

1 Ağustos 2012 sabahı, ABD'nin en büyük piyasa yapıcılarından Knight Capital Group yeni bir yazılım sürümünü canlıya aldı. Borsa açıldıktan sonraki yaklaşık 45 dakika içinde şirket 440 milyon dolar kaybetti. Bu, bir yazılım hatasının yol açtığı en pahalı olaylardan biri olarak kayıtlara geçti.

Ne oldu?

Şirketin emir yönlendirme sistemi sekiz sunucu üzerinde çalışıyordu. Yeni sürüm bu sunuculardan yedisine kuruldu, birine kurulmadı. Güncellenmeyen sunucuda 2003'ten kalma, yıllardır kullanılmayan eski bir kod parçası hâlâ duruyordu. Yeni sürümde tekrar kullanılan bir bayrak, o uyuyan kodu farkında olmadan uyandırdı.

Sonuç: sistem 154 farklı hissede yaklaşık 4 milyon işlem gerçekleştirdi ve 397 milyon hisseden fazlasını alıp sattı. Şirket olayın ardından bağımsızlığını koruyamadı ve bir başka firmayla birleşti.

Buradan çıkan asıl ders

Bu hikâye genellikle "dağıtım süreçlerinizi otomatikleştirin" dersiyle anlatılır ve bu doğrudur. Ama daha temel bir gerçeği gösteriyor: otomasyon hata yapmaz, tutarlı davranır. Bir insan yüz işlemden birini yanlış yapar; otomasyon ya hepsini doğru yapar ya da hepsini yanlış. Hız avantajı, hata anında dezavantaja dönüşür.

Otomasyonun değeri hızda değil tutarlılıkta. Hız bunun yan ürünü — ve aynı zamanda riskin kaynağı.

— VektorSoft ekibi

Devretmeden önce üç soru

1. Süreç gerçekten tekrar ediyor mu?

Ayda üç kez yapılan bir iş, ne kadar sıkıcı olursa olsun otomasyon adayı değildir. Kaba bir eşik olarak: haftada en az beş kez tekrarlanmayan bir süreç kurulum maliyetini genellikle çıkaramaz. Burada dikkat edilmesi gereken, tekrar sayısını hissetmek yerine bir hafta boyunca saymaktır.

2. Kurallar yazıya dökülebiliyor mu?

Süreci yapan kişi "duruma bakarım" diyorsa, o durumları önce yazıya dökmek gerekir. Yazıya dökülemeyen bir kural otomatikleştirilemez — sadece gizlenir ve ilk istisnada ortaya çıkar. Pratik yöntem şu:

• Süreci yapan kişiyle oturup adımları tek tek yazın.
• Her adımda "peki ya şu olursa?" diye sorun ve cevapları not edin.
• İstisnaları ayrı bir listeye alın.
• İstisna listesi ana listeden uzunsa, o süreç henüz otomasyona hazır değildir.

3. Yanlış gittiğinde ne olacak?

Knight Capital'ın asıl eksiği buydu. Sistem yanlış çalışmaya başladığında, bunu fark edip durduran bir mekanizma yoktu. Her otomasyonda üç şeyin baştan tasarlanması gerekir:

1. Durdurma düğmesi — sistemi tek hamlede kapatabilmek.
2. Sınır kontrolü — beklenen aralığın dışına çıkıldığında kendiliğinden durmak.
3. Geri alma yolu — yapılan işlemi tersine çevirebilmek ya da en azından tam olarak listeleyebilmek.

Dağıtım sürecinin kendisi de bir süreçtir

Knight Capital vakasının en öğretici yanı, hatanın kodda değil kurulum sürecinde olması. Yazılımın kendisi test edilmişti; sekiz sunucudan birine kurulmadığını fark eden bir mekanizma yoktu. Olayın ardından ABD Menkul Kıymetler ve Borsa Komisyonu şirkete idari yaptırım uyguladı ve gerekçede piyasa erişim kontrollerinin yetersizliğine dikkat çekti.

Kendi projelerimizde bu dersi üç kuralla uyguluyoruz. Üçü de sıradan görünür; sıradan oldukları için de en çok atlanan kurallardır.

1. Kurulum elle yapılmaz. İnsan sekiz sunucudan birini atlar; betik atlamaz. Atlarsa da hata verir.
2. Ölü kod silinir, bayrakla kapatılmaz. Kullanılmayan kodu "belki lazım olur" diye bırakmak, onu bir gün yanlışlıkla çalıştırma riskini taşımaktır.
3. Kurulum sonrası doğrulama zorunludur. Sürümün gerçekten her sunucuya gittiğini kontrol eden otomatik bir adım olmadan kurulum tamamlanmış sayılmaz.

Küçük ölçekte de aynı ilkeler geçerli

Bu örnek finans sektöründen ve devasa bir ölçekten geliyor; "bizim işimiz böyle değil" demek kolay. Ama aynı hata deseni her ölçekte tekrarlanıyor: fatura kesen bir betik yanlış müşteri listesiyle çalışır, stok güncelleyen bir görev iki kez tetiklenir, e-posta gönderen bir akış test verisiyle canlıya çıkar.

Fark yalnızca sıfırların sayısında. Durdurma düğmesi, sınır kontrolü ve geri alma yolu — bu üçü, ölçekten bağımsız olarak her otomasyonun asgari donanımıdır.

Üç soruya da net cevap verebiliyorsanız süreç otomasyona hazırdır. Veremiyorsanız sorun otomasyonda değil, sürecin kendisindedir — ve önce onu düzeltmek gerekir. Otomasyon, belirsiz bir süreci netleştirmez; belirsizliği ölçekler.