1066, lebih dari 200 tahun telah berlalu sejak awal invasi Viking ke Inggris. Raja Harold, mengumpulkan detasemen ksatria, berbaris ke Sungai Derwent untuk pertempuran yang menentukan dengan pasukan senama - raja Norwegia Harald. Para pembuat senjata bekerja selama satu bulan untuk menempa baju besi generasi baru yang cukup yang dapat melindungi ksatria agar tidak terkena kapak Skandinavia. Dan berapa banyak percobaan dan uji coba dalam turnamen sebelumnya! Tapi harapan itu seharusnya bisa dibenarkan sendiri - peralatan yang ringan, tetapi dapat diandalkan, bahkan dengan berjalan kaki, tanpa kerugian besar, untuk membubarkan Viking hird. Dan akhirnya, mereka bertemu di Stamford Bridge. Detasemen utama para ksatria, yang dipimpin oleh seorang komandan berbaju zirah, bentrok di tengah jembatan dengan musuh. Ya, baja master podgorny menahan pukulan!
Perlahan tapi pasti, orang-orang Viking bergerak ke pertahanan round-robin. Kemenangan tampaknya sudah dekat. Dan akhirnya, di medan perang, komandan ksatria dan jarl Norwegia menemukan satu sama lain.
Kapak jarl dua tangan sudah rusak dan dia terpaksa membela diri dengan Saxon biasa, yang tidak bisa dibandingkan dengan seorang ksatria dan setengah pedang. Gelombang dengan belati - untuk baju besi komandan itu seperti pisau lipat, tetapi melewati baju besi dan ... tampaknya sihir telah ikut berperan - baju besi dari para ksatria tetangga tersebar! Gelombang lain, lagi tepat sasaran, dan sekarang di ksatria di sisi kiri baju zirah itu tiba-tiba menyala merah-panas. Pukulan ketiga - para ksatria berenang di depan mata mereka, mereka tersandung, jatuh, dan tidak pernah bangkit lagi.
"*** ** **** ****!" Teriak Petrovich, bangun jam 5 pagi pada hari Senin dalam keringat dingin. Segalanya berjalan salah: pada jam 11 malam ia naik ke Wikipedia untuk mencari bahan-bahan untuk laporan anak tentang sifat tundra, tetapi pada malam hari ia entah bagaimana menemukan dirinya dalam deskripsi invasi Viking di Inggris. Dan juga, pada akhir pekan mereka mengadakan pertempuran rilis berikutnya, yang harus dimulai hari ini. Seperti biasa, kami mengujinya untuk waktu yang lama dan tuntas, mengendarainya melalui sistem integrasi berkelanjutan jutaan kali, apakah semuanya berjalan lancar ...
Untungnya bagi sebagian orang, tetapi sayangnya bagi para korban, selalu ada kesempatan untuk belajar dari kesalahan orang lain, untuk memperbaiki sesuatu di rumah dan mendapatkan porsi ekstra kepercayaan diri. Dengan artikel yang diterjemahkan ini kami ingin sekali lagi, secara lebih rinci, mengingat salah satu kasus di industri "kami".
Tahun lalu di konferensi saya berbicara tentang DevOps, konfigurasi sebagai kode, dan pengiriman berkelanjutan. Menggunakan kisah di bawah ini, saya menjelaskan pentingnya menciptakan penyebaran yang sepenuhnya otomatis dan dapat direproduksi sebagai bagian dari inisiatif DevOps / Continuous Delivery. Setelah konferensi, beberapa orang meminta saya untuk berbagi cerita di blog. Ini adalah kisah yang benar-benar benar. Ini menceritakan kembali apa yang saya baca, saya sendiri tidak berpartisipasi dalam ini.
Jadi, kisah tentang bagaimana sebuah perusahaan dengan aset hampir $ 400 juta bangkrut dalam 45 menit karena penyebaran yang tidak berhasil.
Sedikit latar belakang
Knight Capital Group ("Knight" dalam bahasa Inggris berarti "knight") adalah perusahaan keuangan global Amerika yang bergerak di bidang pembuatan pasar, eksekusi elektronik, penjualan institusi, dan perdagangan. Pada 2012, Knight adalah pedagang saham AS terbesar dengan pangsa pasar sekitar 17% di NYSE dan NASDAQ. Grup Perdagangan Elektronik Knight (ETG) mengelola volume perdagangan harian rata-rata lebih dari 3,3 miliar transaksi per hari, diperdagangkan di atas $ 21 miliar ... per hari. Ini bukan lelucon!
Pada tanggal 31 Juli 2012, Knight memiliki sekitar $ 365 juta dalam bentuk tunai dan setara kas.
Pada 1 Agustus 2012, NYSE berencana untuk meluncurkan program likuiditas ritel baru, Program Liquidity Ritel (program yang dirancang untuk meningkatkan harga bagi investor ritel melalui broker ritel seperti Knight). Dalam persiapan untuk acara ini, Knight memperbarui SMARS router algoritmik mereka yang otomatis dan berkecepatan tinggi, yang mengirimkan aplikasi ke pasar untuk dieksekusi. Salah satu fungsi utama SMARS adalah untuk menerima aplikasi dari komponen lain dari platform perdagangan Knights (aplikasi "induk"), diikuti dengan mengirim satu atau lebih aplikasi "anak" untuk dieksekusi. Dengan kata lain, SMARS akan menerima pesanan dalam jumlah besar dari platform perdagangan dan memecahnya menjadi beberapa yang kecil untuk menemukan pembeli / penjual untuk saham. Semakin besar aplikasi induk, semakin banyak aplikasi anak akan dibuat.
Pembaruan SMARS seharusnya menggantikan kode lama yang tidak terpakai yang disebut "Power Peg" - fungsi yang sudah tidak digunakan Knight selama 8 tahun (mengapa kode yang mati begitu lama masih dalam basis kode adalah sebuah misteri, tetapi ini bukan yang utama). Kode yang diperbarui menetapkan ulang flag lama yang digunakan untuk mengaktifkan fungsionalitas Power Peg. Kode diuji secara menyeluruh, bekerja dengan benar, dan dapat diandalkan. Apa yang salah?
Apa yang salah? Dan sungguh!
Antara 27 Juli 2012 dan 31 Juli 2012, Knight secara manual menggunakan perangkat lunak baru pada sejumlah server per hari - total delapan (8) server. Inilah yang dikatakan
dokumen SEC tentang penyebaran manual (SEC adalah Komisi Sekuritas dan Pertukaran, regulator pasar saham Amerika).
“Selama penyebaran kode baru, salah satu karyawan Knight tidak menyalin kode baru ke salah satu dari delapan server SMARS. Knight tidak melakukan tinjauan teknis kedua dari penyebaran ini, jadi kode Power Peg tidak dihapus dari server kedelapan, dan kode RLP baru tidak ditambahkan. Perusahaan tidak memiliki prosedur yang memerlukan pemeriksaan ulang. ” Rilis No. 70694, 16 Oktober 2013
Pada 1 Agustus 2012 pukul 9:30 EST, pasar dibuka, dan Knight mulai memproses permintaan dari pialang-dealer atas nama pelanggannya dalam Program Liquidity Ritel yang baru. Tujuh (7) server yang digunakan dengan benar mulai memproses aplikasi dengan benar. Dan aplikasi yang masuk ke server kedelapan mungkin mengaktifkan bendera yang diubah dan membangkitkan Power Peg.
Serangan Zombie: Kode Pembunuh
Di sini Anda perlu menjelaskan mengapa kode Power Peg "mati" diperlukan. Fungsi ini dimaksudkan untuk menghitung saham yang dibeli / dijual berdasarkan permintaan orang tua saat pesanan anak selesai. Setelah aplikasi induk dijalankan, Power Peg melarang pengajuan aplikasi anak. Pada prinsipnya, Power Peg akan melacak pesanan anak dan menghentikan eksekusi setelah pemrosesan aplikasi induk. Pada tahun 2005, Knight mengembalikan fungsionalitas pelacakan kumulatif ini ke tahap awal eksekusi kode (sehingga menghapus pelacakan kuantitas dari Power Peg).
Ketika bendera Power Peg di server kedelapan diaktifkan, Power Peg mulai merutekan pesanan anak untuk dieksekusi, tetapi tidak menghubungkannya dengan jumlah saham dalam urutan induk - semacam loop tertutup muncul
Infernal 45 menit
Bayangkan: Anda memiliki sistem yang dapat mengirim aplikasi kecepatan tinggi otomatis ke pasar tanpa pelacakan dan kemampuan untuk melihat apakah cukup banyak aplikasi telah selesai. Ya, semuanya ternyata sangat buruk.
Ketika pasar dibuka pada jam 9:30 pagi, orang dengan cepat menyadari bahwa ada sesuatu yang salah. Pada jam 9:31 pagi, banyak orang di Wall Street menyadari bahwa sesuatu yang serius sedang terjadi. Pasar dibanjiri tawaran dengan yang tidak biasa, dibandingkan dengan situasi normal, volume perdagangan untuk saham tertentu. Pada pukul 9:32 di Wall Street, mereka bertanya-tanya mengapa aib ini tidak berhenti. Hampir selamanya dalam perdagangan kecepatan tinggi. Mengapa seseorang tidak mengklik tombol kill pada sistem yang melakukannya? Ternyata, tidak ada saklar. Selama 45 menit pertama perdagangan, pelaksanaan transaksi dari Knight berjumlah lebih dari 50% dari volume perdagangan, meningkatkan saham tertentu hingga lebih dari 10% dari nilainya. Akibatnya, saham lain jatuh nilainya karena transaksi yang salah.
Dan untuk memperburuk keadaan, sistem Knight mulai mengirim e-mail otomatis bahkan sebelum peristiwa ini - sudah pukul 8:01 pagi (ketika SMARS memproses pesanan yang cocok untuk perdagangan pra-pasar). Dalam pesan, sistem merujuk ke SMARS dan menunjukkan kesalahan "Power Peg tidak tersedia." Antara pukul 8:01 pagi dan 9:30 pagi, 97 surat dikirimkan kepada karyawan Knight. Tentu saja, surat-surat ini tidak tampak seperti peringatan sistem, jadi tidak ada yang langsung melihatnya. Aduh
Selama 45 menit, Knight mencoba untuk menghentikan transaksi yang salah. Itu tidak mungkin untuk mematikan sistem (karena tidak ada prosedur yang terdokumentasi untuk menanggapi situasi seperti itu), oleh karena itu, mencoba mengatasi masalah dalam kondisi perdagangan langsung, mereka tetap berada di pasar, di mana 8 juta saham dijual setiap menit. Karena karyawan perusahaan tidak dapat menentukan dari mana aplikasi yang salah berasal, mereka menghapus kode baru dari server di mana ia digunakan dengan benar. Dengan kata lain, mereka menghapus kode kerja dan dibiarkan rusak. Ini hanya memperburuk masalah yang menyebabkan permintaan orang tua tambahan untuk mengaktifkan kode Power Peg pada semua server, dan bukan hanya di mana kode itu awalnya digunakan secara tidak benar. Pada akhirnya, saya berhasil menghentikan sistem - setelah 45 menit perdagangan.
Sementara perdagangan sedang berlangsung, kode Power Peg menerima dan memproses 212 permintaan orang tua. Akibatnya, SMARS mengirim jutaan anak perusahaan ke pasar, menyelesaikan 4 juta transaksi dalam 154 transaksi dengan lebih dari 397 juta saham. Untuk para penikmat pasar saham, ini berarti bahwa Knight membeli saham dari 80 perusahaan yang berbeda dengan $ 3,5 miliar dan menjual saham dari 74 perusahaan dengan $ 3,15 miliar. Dari sudut pandang non-profesional, Knight Capital Group kehilangan $ 460 juta dalam 45 menit. Tetapi Knight hanya memiliki $ 365 juta dalam bentuk tunai dan setara kas. Dalam 45 menit, Knight telah berubah dari pedagang terbesar saham Amerika dan pembuat pasar utama di NYSE dan NASDAQ menjadi bangkrut. Mereka punya 48 jam untuk mengumpulkan jumlah yang diperlukan untuk menutupi kerugian (yang dapat mereka lakukan berkat investasi $ 400 juta dari sekitar setengah lusin investor). Pada akhirnya, Knight Capital Group diakuisisi oleh Getco LLC (pada Desember 2012), dan sekarang perusahaan gabungan itu disebut KCG Holdings.
Kesimpulan apa yang Anda butuhkan untuk menggambar
Peristiwa 1 Agustus 2012 harus menjadi pelajaran bagi semua tim pengembangan dan tim proyek. Tidak cukup membuat perangkat lunak hebat dan mengujinya; Anda juga perlu memastikan bahwa itu dikirim dengan benar ke pasar sehingga pelanggan Anda menerima persis nilai yang Anda berikan (dan bahwa Anda tidak membuat perusahaan Anda bangkrut). Insinyur yang menggunakan SMARS tidak hanya dapat disalahkan karena fakta bahwa prosedur yang diikuti di Knight tidak memperhitungkan risiko. Prosedur (atau ketidakhadirannya) jelas salah. Setiap kali proses penyebaran tergantung pada bagaimana orang membaca dan mengikuti instruksi, Anda menempatkan diri Anda dalam risiko. Orang membuat kesalahan. Kesalahan bisa dalam instruksi, dalam interpretasi instruksi atau dalam implementasinya.
Tata letaknya harus otomatis, dapat direproduksi, dan bebas dari kemungkinan kesalahan manusia. Jika Knight menerapkan sistem penyebaran otomatis - satu set konfigurasi, penyebaran otomatis, dan pengujian - maka kesalahan yang berubah menjadi mimpi buruk Knight bisa dihindari.
Berikut adalah beberapa prinsip pengiriman kontinu (bahkan jika Anda tidak menerapkan proses pengiriman kontinu yang lengkap):
- Rilis perangkat lunak harus merupakan proses yang berulang dan dapat diandalkan.
- Otomatisasi semua yang Anda bisa.