Knightmare: Bir DevOps ibret hikâyesi (2014)

 (dougseven.com)
1 puan yazan GN⁺ 2023-09-11 | 1 yorum | WhatsApp'ta paylaş
  • ABD hisse senedi işlemlerinin büyük oyuncularından Knight Capital Group, 1 Ağustos 2012'deki SMARS dağıtım hatası nedeniyle 45 dakika içinde 460 milyon dolar kaybederek iflasın eşiğine geldi
  • NYSE Retail Liquidity Program uyarlaması sırasında, 8 yıldır kullanılmayan Power Peg kodunun bayrağının yeni özellik için yeniden kullanılması olayın başlangıç noktası oldu
  • Yeni kod 8 sunucunun yalnızca 7'sine dağıtıldı; kalan tek sunucu yeni RLP emrini alınca devre dışı kalmış Power Peg işlevi yeniden çalıştı
  • Power Peg, üst emrin gerçekleşen miktarını takip etmeden alt emirleri yönlendirmeyi sürdürdü ve Knight, kill switch ile belgelenmiş bir müdahale prosedürü olmadan üretim ortamında nedenini bulmak zorunda kaldı
  • Dağıtım, kod yazımı ve test kadar önemlidir; manuel prosedürlere dayanan dağıtım, otomasyon·tekrarlanabilirlik·doğrulama olmadan ölümcül bir operasyonel riske dönüşür

45 dakikada çöken yüksek frekanslı işlem şirketi

  • Knight Capital Group, piyasa yapıcılığı, elektronik yürütme ve kurumsal satış-ticaret alanlarında faaliyet gösteren bir ABD finansal hizmetler şirketiydi
  • 2012'de Knight, ABD hisselerinde NYSE ve NASDAQ'ta ayrı ayrı yaklaşık %17 pazar payına sahip en büyük trader'dı
  • Knight'ın Electronic Trading Group'u (ETG), günde ortalama 3,3 milyardan fazla işlem hacmini yönetiyor ve günde 21 milyar doların üzerinde işlem yapıyordu
  • 31 Temmuz 2012 itibarıyla Knight'ın elinde yaklaşık 365 milyon dolar nakit ve nakde eşdeğer varlık bulunuyordu

RLP desteği için SMARS güncellemesi

  • NYSE, 1 Ağustos 2012'de Retail Liquidity Program'ı başlatmayı planlıyordu
  • Knight buna uygun olarak emirleri piyasaya gönderen otomatik yüksek hızlı algoritmik yönlendirici SMARS'ı güncelledi
  • SMARS, işlem platformundaki “üst emir”i alıp bunu bir veya daha fazla “alt emir”e bölerek gerçekleştiren bir sistemdi
    • Üst emir ne kadar büyükse o kadar fazla alt emir oluşturuluyordu
  • Bu güncelleme, 8 yıldır kullanılmayan Power Peg kodunu devre dışı bırakmak için yapılan bir çalışmaydı
  • Yeni kod, Power Peg'i etkinleştiren mevcut bayrağı yeni işlev için yeniden kullandı
  • Kodun kendisi yeterince test edilmişti ve normal çalıştığı doğrulanmıştı

Manuel dağıtımda atlanan tek sunucu

  • Knight, 27 Temmuz 2012'den 31 Temmuz'a kadar yeni yazılımı günde sınırlı sayıda sunucuya manuel olarak dağıttı; toplam hedef 8 sunucuydu
  • SEC belgelerine göre bir teknisyen, 8 SMARS sunucusundan birine yeni kodu kopyalamadı
  • Bu dağıtımı ikinci bir teknisyenin gözden geçirdiği bir süreç yoktu ve böyle bir incelemeyi zorunlu kılan belgelenmiş bir prosedür de bulunmuyordu
  • Sonuç olarak 8. sunucuda Power Peg kodu kaldırılmadı ve yeni RLP kodu da eklenmedi

Ölü kodun yeniden canlanma biçimi

  • 1 Ağustos 2012 saat 09:30'da (ABD Doğu Saati) piyasa açıldığında Knight, broker-dealer müşteri emirlerini Retail Liquidity Program için işlemeye başladı
  • Doğru şekilde dağıtılmış 7 sunucu emirleri normal biçimde işledi
    1. sunucuya giden emirler, yeniden kullanılan bayrak üzerinden eski Power Peg kodunu tekrar çalıştırdı
  • Power Peg'in asıl görevi, alt emirler gerçekleştikçe üst emre göre kaç hissenin alınıp satıldığını saymak ve üst emir karşılandığında alt emir yönlendirmesini durdurmaktı
  • Knight, 2005'te kümülatif izleme işlevini kod çalışmasının daha erken bir aşamasına taşımıştı ve Power Peg içindeki toplu izleme kaldırılmış durumdaydı
    1. sunucuda Power Peg bayrağı etkinleşince Power Peg alt emirleri yürütme piyasasına yönlendirdi, ancak üst emre göre hisse sayısını takip etmediği için fiilen sonsuz döngü gibi davrandı

Açılış öncesi sinyaller ve 09:30 sonrası kontrolden çıkış

  • Knight sistemi aynı gün sabah 08:01'den itibaren otomatik e-postalar göndermeye başladı
    • Bu, SMARS seans öncesi işlem hedefli emirleri işlediğinde oluşuyordu
    • E-postalarda SMARS'tan bahsediliyor ve hata “Power Peg disabled” olarak tanımlanıyordu
    • 08:01 ile 09:30 arasında Knight çalışanlarına bu tür 97 e-posta gönderildi
  • Bu e-postalar sistem alarmı olarak tasarlanmadığı için hemen fark edilmedi
  • 09:30'daki piyasa açılışından hemen sonra Wall Street'teki birçok kişi olağandışı durumu fark etti
  • 09:31'de ciddi bir şey olduğu açıktı, 09:32'de ise neden durmadığı sorusu büyüdü
  • İlk 45 dakika boyunca Knight'ın işlemleri bazı hisselerde hacmin %50'sinden fazlasını oluşturdu ve belirli hisse fiyatlarını %10'dan fazla yukarı çekti
  • Hatalı işlemlere tepki olarak diğer hisselerin değeri düştü

Kill switch eksikliği ve yanlış müdahale

  • Knight'ın sorunlu sistemi anında durduracak bir kill switch'i yoktu
  • Belgelenmiş bir müdahale prosedürü de olmadığından, dakikada 8 milyon hisse işlem gören üretim ortamında neden teşhis edilmek zorunda kaldı
  • Nedeni bulamayan Knight, doğru şekilde dağıtılmış sunuculardan yeni kodu kaldırdı
  • Bu adım, çalışan kodun kaldırılıp sorunlu kodun yerinde bırakılmasıyla sonuçlandı
  • Ardından ek üst emirler, yalnızca bir sunucuda değil tüm sunucularda Power Peg kodunu etkinleştirerek sorunu daha da büyüttü
  • Knight sistemi ancak 45 dakika sonra durdurabildi

Kayıp boyutu ve şirketin sonu

  • Piyasa açılışından sonraki ilk 45 dakikada Power Peg kodu 212 üst emri alıp işledi
  • SMARS piyasaya milyonlarca alt emir gönderdi; sonuçta 154 menkul kıymette 4 milyon işlem ve 397 milyondan fazla hisse işlemi gerçekleşti
  • Knight, 80 menkul kıymette yaklaşık 3,5 milyar dolarlık net uzun pozisyon, 74 menkul kıymette ise yaklaşık 3,15 milyar dolarlık net kısa pozisyon taşımak zorunda kaldı
  • Knight Capital Group, 45 dakika içinde 460 milyon dolar zarar yazdı
  • O tarihte elindeki nakit ve nakde eşdeğer varlıklar 365 milyon dolar olduğundan, Knight ABD hisselerindeki en büyük trader ve önemli bir piyasa yapıcı konumundan iflas noktasına düştü
  • Zararı kapatmak için 48 saat içinde sermaye bulması gerekiyordu ve Knight yaklaşık 6 yatırımcıdan 400 milyon dolarlık yatırım almayı başardı
  • Ardından Knight Capital Group, Aralık 2012'de Getco LLC tarafından satın alındı ve birleşen şirket KCG Holdings oldu

DevOps ve Continuous Delivery dersleri

  • İyi yazılım üretmek ve bunu test etmek tek başına yeterli değildir
  • Müşteriye değer sunmak için yazılımın piyasaya doğru şekilde dağıtılması gerekir
  • Olayın nedeni yalnızca SMARS'ı dağıtan tek bir mühendiste değil, Knight'ın süreçlerinin maruz kaldığı riski taşıyamamasındaydı
  • İnsanların talimat okuyup uygulamasına dayanan dağıtım süreçleri hata olasılığını içinde barındırır
    • Hata talimatın kendisinde, talimatın yorumlanmasında veya uygulanmasında ortaya çıkabilir
  • Dağıtım mümkün olduğunca otomatikleştirilmeli ve tekrarlanabilir olmalı, insan hatası olasılığı azaltılmalıdır
  • Otomatik bir dağıtım sistemi yapılandırma, dağıtım ve test otomasyonunu içerseydi, Knightmare'e yol açan hata önlenebilirdi
  • Continuous Delivery ilkeleri içinde bu vakaya uygulanan iki ilke var
    • Yazılım sürümü tekrarlanabilir ve güvenilir bir süreç olmalıdır
    • Makul sınırlar içinde mümkün olan en çok şey otomatikleştirilmelidir

İlgili okumalar

1 yorum

 
GN⁺ 2023-09-11
Hacker News yorumları

  • Otomatik dağıtımın bu sorunu nasıl çözeceğinden pek emin değilim. Aksine sorunun etkisini ve sonrasındaki hasarı daha da büyütmüş olma ihtimali yüksek
    “Bir geliştirici kodu bir sunucuya yüklemeyi unuttu”yu, “dağıtım ajanı sunucuya yeni binary/kodu indirirken hata aldı ve ajandaki bir bug yüzünden bu hata ortaya çıkmadı” diye değiştirseniz de aynı hata modu olur. Etki muhtemelen daha hızlı yayılırdı
    Burada sorumluluk geliştiricide. Çünkü kodu geriye dönük uyumluluğu olmayan bir şekilde yazmış

    • Sorumluluk tamamen risk yönetimi ekibinde
      Hem piyasa hem de Knight ciddi bir sorun olduğunu biliyordu, ama işlemleri durdurana kadar geçen 45 dakika boyunca çeşitli hotfix’ler denediler. Bir kill switch yoktu ya da yanlış zamanda basılırsa fırsat maliyeti yaklaşık 500 bin dolar olur diye basma yetkisi olan kimse yoktu muhtemelen
      O dönemde Knight’ın rakiplerinden birinde çalışıyordum; biz de korkunç bug’ları sık sık production ortamına çıkarıyorduk, ama postmortem sırasında aynı şeyin bizim başımıza gelebileceğini hayal etmek zordu. Tekil işlemleri engelleyen birkaç otomatik sistemimiz vardı; kıdemli bir trader ya da operasyon sorumlusu 60 saniyelik bir konuşmayla kill switch’i çektirebiliyordu ve bunun sonuçlarından korkmak zorunda değildi
      Aslında Knight’ın 400 milyon dolarlık kaybından daha fazla para kazanabilirdik, ama risk sistemimiz bunu “gerçek olamayacak kadar iyi” diye değerlendirip stratejiyi sürekli kapattığı için kârımız azaldı
    • CI/CD olsaydı bu sorunu %100 çözerdi
      “Knight’ın teknisyenlerinden biri yeni kodu 8 SMARS sunucusundan birine kopyalamadı” kısmına tekrar bakmak gerekiyor. Elbette bir CI/CD pipeline’ı da ortasında başarısız olup yalnızca bazı sunuculara dağıtım yapabilir, ama bunun olasılığının düşük olduğunu düşünüyorum
      Öyle olsa bile, bir Ansible Playbook ilgili aktarım hatası anında durur ve tüm Playbook başarısız olurdu; son adım olan servisi yeniden başlatmaya kadar ulaşamazdı
      Bu bir insan hatasıydı ve otomasyon tam da bu yüzden var
      Ayrıca “ikinci teknisyen dağıtımı gözden geçirmedi ve 8. sunucuda Power Peg kodunun kaldırılmadığını, yeni RLP kodunun da eklenmediğini kimse fark etmedi” kısmını da CI/CD önleyebilirdi. Ansible kod deposu için bir “Pull Request”, ilk teknisyenin inceleme olmadan master/main’e merge etmesini engellerdi. Çünkü master/main korumalı olmalı
      CI/CD’ye dayalı DevOps’un bu sorunu %100 çözeceğinden eminim
    • Mevcut flag’i yeniden kullanma kararını veren kişi sorumlu olabilir. Yazılım geliştirmiş olanlar bilir; böyle bir karar mutlaka, hatta çoğu zaman geliştirici tarafından alınmış bir karar değildir
    • Bunu dağıtım sürecine yeterince yatırım yapılmaması sorunu olarak görüyorum. Bu arada ben açık kaynak dağıtım araçlarının bakımını yaparak geçimini sağlayan biriyim
      Charity Majors Euruko’da bununla ilgili çok şey anlattı. Dağıtım aracı, üzerine palto geçirilmiş bir bash script’i seviyesinde olmamalı; yeterli insan gücü ve testle desteklenmeli ve mümkün olduğunca uçtan uca otomatikleştirilmiş olmalı
      Immutable mimariye yakın bir dağıtım süreci, başarısız/durmuş/tamamlanmamış rollout’ları izleyen araçlar ve önceki sağlıklı duruma hızla geri dönme yeteneği; savunma katmanları oluşturur ve işler ters gittiğinde izlenecek yolu kolaylaştırır. Bu sorun imkânsız hale gelmezdi, ama yaşanması daha zor olurdu
    • Otomasyonun amacı, zaman geçtikçe tanımlanmamış uç durumları azaltmaktır
      Elle yürütülen prosedürler, sunucu üzerinde her işlem yaptığınızda “12. adımı yaptım, sanırım 13. adımı da yaptım; sırada 14. adım var” diye tahmin yürüttüğünüz bir oyuna dönüşür. İnsan beyni, milyon kez yaptığı bir iş yarıda kesildiğinde, bu çalıştırmayla önceki seferin anısından türeyen sahte anıyı çoğu zaman güvenilir biçimde ayırt edemez
      Adım atlamayı engelleyen interlock’lar yoksa her seferinde kumar oynarsınız. Üstelik interlock oluşturma çabası, otomasyon maliyetinin zaten önemli bir kısmını oluşturur

  • “8 yıl boyunca ölü kalmış kodun neden kod tabanında kaldığı bir muamma, ama mesele bu değil” denmiş; bence mesele tam da bu gibi görünüyor
    8 yıl boyunca kullanılmayan kodu olduğu gibi bırakıp, ancak bayrağı yeniden kullanmaya çalışınca kaldırmaya niyetlenmişler gibi. 8 yıl önce doğru olanı yapıp kullanılmayan kodu silselerdi hikâye tamamen farklı olurdu. Ne eski rutin yeniden canlanırdı ne de kafasına göre takılan sunucular olurdu
    Knight Capital sürüm kontrolü kullanmadığı için kodu “ne olur ne olmaz” diye elde tutmuş olabilir. Ama tamamen sürüm kontrollü depolarda bile kod silmek istemeyen geliştiriciler gördüm; gerçekten şaşırtıcı. Tekrar gerekirse sürüm kontrolünden geri getirirsin. Tekrar gerektiğinde orada olduğunu unutacaksan, ölü kod yolunu da aynı şekilde bulamayacaktın. Kaynak ağacında bırakmak saf borçtur
    Kevlin Henney, GOTO’da yazılım güvenilirliği üzerine harika bir sunum yaptı ve Knight Capital’i örnek vererek bu noktaya değindi. Hatta bu blog yazısından da alıntı yapıyor https://youtu.be/IiGXq3yY70o?si=hZ9HB2dlfj0vHvNK&t=463
    “Gerçekten ölü kod diye bir şey yoktur. Küçük bir varsayım, varsayımda küçük bir değişiklik yeter; bir anda ölü kod olmaktan çıkıp zombi koda dönüşür. Yeniden dirilen zombi kıyameti para kaybettirir”

    • Birçok geliştirici git’in yalnızca temellerini biliyor gibi. Değişiklikleri commit etmek, git log ile geçmişe bakmak, belki git blame kullanabilmek kadar
      git geçmişini filtrelemeyi çoğu zaman bilmiyorlar. git pickaxe ya da hariç tutma kalıplarını da bilmiyorlar; belirli bir dizini hariç tutup git log içinde foo aramak için git log -G'int.*foo\(' -- ':(exclude)directory' gibi bir şey yapılabileceğini akıllarına bile getirmiyorlar
      Bunun yerine mevcut kod ağacında grep yapmayı biliyorlar. Bu yüzden silinmezse uygun bir grep ile tekrar bulabileceklerini düşünüyorlar. Silinirse git geçmişinde nasıl bulacaklarını bilmiyor olabilirler
      Bir yere kadar anlaşılır. git log içindeki kod birçok araçta görünmez. Örneğin editör otomatik tamamlamada önermeyecek, kütüphane dokümantasyonunda da görünmeyecektir
      O kodun gerçekten tekrar kullanılacağına inanıyorsan, refactoring’i takip etmesi ve gerektiğinde bulunabilmesi için ağaçta bırakmak bir ölçüde savunulabilir. Ama Knight Capital’de olduğu gibi açıkça tekrar kullanılmayacak durumlarda savunması zor
    • “Çalışıyorsa dokunma” lafını çok duydum; özellikle ne dediğini bilmeyen yöneticiler sık söyler
      Sadece “eski kodu kaldıran” bir güncelleme bile, her değişikliği arıza riski olarak gören birine zor gelebilir. Adil olmak gerekirse her değişiklik risktir, ama eski kodu bırakmak da risktir
      En azından artık bu olayı somut bir risk örneği olarak gösterebiliyoruz
    • Ölü kodun bırakılmış olması tek başına daha az şaşırtıcı. Çalıştığım neredeyse her şirkette böyle şeyler oldu
      Bu hikâyeye her baktığımda gerçekten anlamadığım şey, yeni bir bayrak yaratmak yerine mevcut bayrağı yeniden kullanmaları. Neden böyle yaptılar ki
    • Sürüm kontrolü de kusursuz değildir. Kod geçmişinin tamamı tek bir git rebase ile sonsuza dek yok olabilir
      Çoğu organizasyonun ana branch çevresinde bunun olmaması için süreçleri olduğunu umarım. Ama ben de küçük bir organizasyonda prodüksiyon veritabanı tablosunu yanlışlıkla bozmuş biri olarak, kazara git rebase yapılmasını da imkânsız görmüyorum
    • Arızanın hemen ardından Knight’ta çalışmış olma deneyimimi başka bir kardeş thread’de yazdım
      256 sütunla sınırlı bir veritabanı kullanmaları gibi başka bir sorun daha vardı. Yeni bir sütun gerektiğinde, “o sırada kullanılmayan” eski bir sütunu öylece yeniden kullanırlardı
      Doğru hatırlıyorsam içeride de bunun genelde “kötü fikir” olduğu kabul ediliyordu; ama eski kodu temizlemeyi ya da daha iyi iyi uygulamalar oluşturmayı kimse önceliklendirmedi

  • Karşılaştığım hiçbir sürekli dağıtım sistemi bu belirli hatayı engellemezdi
    Kademeli bir rollout yapılıyordu, ama kodda bu kademeli rollout sırasında tek bir kurulum başarısız olursa şirketi batıracak bir mantık hatası vardı
    Bunu engellemek için çalışma zamanında yazılım sürümünün, örneğin git SHA’nın eşleştiğini kontrol etmeyi ve yazılım rollout altyapısını çağıran testlere hata enjeksiyonu eklemeyi de düşünürdüm

    • Düzgün bir sürekli dağıtım sistemi, ayarların ve kodun birbirinden sapmasına izin vermez. Eskiden Power Peg’i açan ama artık başka bir şeyi açan bayrak için bir ayar değişikliği vardı; ayrıca o bayrağı farklı yorumlayan bir kod değişikliği de vardı

  • Tam bir Vahşi Batı dönemiydi. O zamandan beri alım satım sistemlerinin çok değiştiğini vurgulamak da önemli
    Bu alanda çalışmaya başladığım 2009’da bankalar, brokerlar ve borsaların sistem güvenilirliği oldukça berbattı. Gerçekleşen miktarın ne kadar olduğunu telefonla teyit etmek sık yaşanan bir şeydi
    İtalyan borsasının sistem rollout yaptığı zamanı hatırlıyorum. Bir noktada prodüksiyon ile UAT’nin karıştığı bir yerde “test” yapıyorlardı; yanlış hatırlamıyorsam kapanıştan sonra bir sonraki sürümü denemek için yalnızca emir gönderim bağlantısının IP’sini değiştiriyorlardı. UAT ortamı o kadar çok bug’lıydı ve çoğu kısmı yarı ölüydü ki orada test yapamıyorlardı
    Yanında bir sürü sıfır olan işlem hacmine sahip ürünleri fiyatlayan, ChatGPT’nin bile söveceği VBA kodu içeren Excel tabloları konusuna hiç girmeyelim
    Bugün durum çok farklı. Biraz da bu tür olaylar sayesinde. Çoğu şey otomatikleşti ve kovboyvari tavır çok daha azaldı
    Zorunlu kill switch’ler, katman katman risk/alım satım faaliyeti gözetimi, borsa tarafı gözetimleri var; zor yoldan öğrenilen derslerin çok büyük kısmı sistemlere gerçekten yansımış durumda. İnsanların iyi bir alım satım sistemi yapmanın zorluğunu safça hafife almasının nedeni de bu. Stratejinin akıllılaşması da var, ama asıl mesele genellikle normal koşullar dışındaki bir şey yüzünden ölmemeyi başarmak

  • Kantitatif finans alanındaki kelimenin tam anlamıyla herkes Knight Capital’i bilir. “pulling a knight capital” diye bir ifade de var. Yani şirketi bir anda iflasa sürükleyebilecek mission-critical sistemlerde bile kestirme yola sapıp bedelini ödemek anlamına gelir

    • Hatta bizim şirketin onboarding materyallerinde de kullanılıyor

  • Ekibimizin sistemi, günde yüz milyonlarca dolarlık gelirde kritik rol oynuyor. Sistem yeterince uzun süre kapalı kalırsa bu gelir kaybolur. Burada “yeterince uzun” en az birkaç saat demek; o süre içinde genellikle dış etki çok büyümeden normal duruma döndürebiliyoruz.
    Bizim de manuel süreçlerimiz var, ama herhangi bir manuel süreç başlamadan önce geri alma prosedürünü belgeliyor ve dağıtımı izliyoruz. Kod dağıtımı ile özellik dağıtımını da ayırıyoruz; özellik dağıtımını ise özellik bayraklarının arkasından kademeli yapıyoruz.
    Yeni özellikler veya kod değişiklikleri için yeni bir özellik bayrağı istiyoruz. Acı verici ve yavaş, ama tehlikeli durumlardan ve panikten kaçınmamızı sağladı; operasyon ve nöbet yükünü de ciddi ölçüde azalttı.
    Gerçekten fena şekilde batırmak için birden fazla “kusur filtresinden” geçmek gerekir. Kod incelemesinde özellik bayrağı olmayan davranış değişikliğinin kaçması, manuel/geliştirme ortamı testlerinde kaçması, dağıtımın başarısız olması, geri almanın başarısız olması ya da yanlış yapılması, sorunun hâlâ düzelmediğine dair uyarı verecek izlemenin olmaması, zamanında üst seviyeye eskale edilememesi ve yeterince zaman geçip SLA’i karşılama kabiliyetinin kaybedilmesi gibi.
    Daha riskli manuel değişikliklerde iki kişinin birlikte değişiklik yapmasını da isteyebilirsiniz. Biri görüntülü aramada neyin değiştirildiğini işaret eder, diğeri doğrular.
    SLA’iniz dakika seviyesindeyse ve geri alınamaz değişiklikler içeren bir sistemle uğraşıyorsanız, birkaç dakika içinde izleme ve geri alma yapmanın gerçekçi bir yolunu bilmelisiniz. Yeni ve manuel bir işse dört kez kontrol etmeli, başka birinin yanınızda izlediğinden emin olmalısınız. Aksi hâlde birden fazla sorunun peş peşe birikip artık düzeltilemeyecek ana gelmesi sadece zaman meselesidir. Ne kadar yetenekli ve zeki olursanız olun, insanlar manuel değişiklik yaptığında ya da değişikliği başlatmak zorunda kaldığında hata her zaman olur; bu hata olasılığı değişiklik yönetimi sürecine yerleştirilmelidir.

    • O gelir gerçekten kaybolur mu? Yoksa sadece daha sonra mı gerçekleşir?
      Genel ticarette ya da B2B’de çoğu durumda müşteri aynı satın almayı biraz sonra yeniden deneyebilir. “Şimdi olmazsa asla olmaz” değildir.
      Ben de satıcı kapalıyken, yeni bir duyuru ve büyük talep yüzünden sunucular çökmüşken ya da banka bakım sorunu varken almak istediğim şeyi tekrar denemişliğim var.

  • İlgili yazılar:
    Knightmare: A DevOps Cautionary Tale (2014) - https://news.ycombinator.com/item?id=22250847 - Şubat 2020, 33 yorum
    Knightmare: A DevOps Cautionary Tale (2014) - https://news.ycombinator.com/item?id=8994701 - Şubat 2015, 85 yorum
    Knightmare: A DevOps Cautionary Tale - https://news.ycombinator.com/item?id=7652036 - Nisan 2014, 60 yorum
    Ek olarak:
    The $440M software error at Knight Capital (2019) - https://news.ycombinator.com/item?id=31239033 - Mayıs 2022, 172 yorum
    Bugs in trading software cost Knight Capital $440M - https://news.ycombinator.com/item?id=4329495 - Ağustos 2012, 1 yorum
    Knight Capital Says Trading Glitch Cost It $440 Million - https://news.ycombinator.com/item?id=4329101 - Ağustos 2012, 90 yorum
    Başka var mı?

  • Asıl sorun, “gerçek İskoçyalı” türü ifadeyi mazur görürseniz, test edilmemiş bir konfigürasyon ve ikili sürüm kombinasyonu kullanmalarıydı.
    Konfigürasyon ve ikili dosyalar aynı anda eşleştirilerek rollout edilebilir; bu da bu tür sorunları engeller. Elbette başka hatalar da vardı, ama bu koşul olmasaydı bu sorun ortaya çıkamazdı.

  • “8 yıldır ölü olan kodun neden kod tabanında kaldığı bir muamma, ama mesele bu değil” kısmı hikâyedeki en kötü hata değil; ama mesele değil de denemez.
    Ölü özellik proaktif olarak kesilip atılsaydı, daha basit ve daha iyi anlaşılan bir yazılım olurdu; kontrolden çıkma olasılığı da azalırdı. Böyle bir bakım olmadan sürekli sadece ileri gitmek, hesaplanmış olsun ya da olmasın, risktir.

  • İnsan müdahalesi olmadan milyonlarca doları otomatik yönlendiren kod yazmadığım için gerçekten mutluyum.
    Jumbo jet uçuran kod yazmak gibi. Kim böyle bir sorumluluk almak ister ki?

    • Bu sorumluluğun kendisi sorun değil, ama gerçekten benim sorumluluğum olmalı. Yani patron yarın çıkarmak istese bile, XYZ’yi yapmak 2 yıl daha sürecek olsa da “XYZ düzeltilene kadar yayınlamıyoruz” deme yetkim olmalı.
    • Doğru yapıldığında korkutucu değildir. Ve doğru yapmak, inanılmaz derecede sıkıcı bir iş gibi görünebilir.
      Süreçleri, testleri, simülatörleri ve yedekliliği seven belirli bir insan tipine uygun bir iş olduğunu düşünüyorum. Uçağı uçuran kodun kendisinin mühendisliğin yalnızca %1’i olduğu bir yer.
    • Başta kaygı yaratır, ama iyi kontroller ve izleme varsa gündelik hâle gelir.
      Doğal olarak akla gelen endişeleri tek tek çözmeniz yeterlidir; makul ölçüde kaygılı olmak iş için daha iyidir. Finans sektöründeki deneyimime göre Knight’ın sorunu %10 teknik, %90 da CTO benzeri birinin gözü karalığı cesaret sanmasıydı. Sadece o gün ya da o hafta değil, genel olarak.
    • Her şirket böyle mi bilmiyorum, ama genellikle yazılım borsaya emir gönderdiğinde birçok kişi neler olduğunu yakından izler.
      Bu olayın da bunda bir ölçüde payı olduğunu düşünüyorum.
    • Finans sektöründe çalışarak hayatımı boşa harcamadığım için gerçekten mutluyum