مطالعه موردی 4: خطای نرم افزاری 440 میلیون دلاری در Knight Capital

نایت سرمایه گروه یک شرکت خدمات مالی جهانی آمریکایی بود که مشغول ساخت بازار ، اجرای الکترونیکی و فروش و تجارت نهادی بود. در سال 2012 نایت بزرگترین معامله گر در سهام ایالات متحده با سهم بازار حدود 17 درصد در بورس اوراق بهادار نیویورک (NYSE) و همچنین در بازار سهام NASDAQ بود. گروه معاملاتی الکترونیکی نایت (ETG) متوسط حجم معاملات روزانه بیش از 3. 3 میلیارد معاملات را مدیریت کرد و روزانه بیش از 21 میلیارد دلار معامله کرد.

17 سال کار اختصاصی برای ساخت گروه Knight Capital در یکی از خانه های تجاری پیشرو در وال استریت طول کشید. و همه اینها تقریباً در کمتر از یک ساعت به پایان رسید.

آنچه در صبح روز اول اوت 2012 برای نایت اتفاق افتاد ، کابوس هر مدیرعامل است: یک خطای ساده انسانی ، که به راحتی با عقب نشینی مشاهده می شود اما پیش بینی پیش بینی تقریباً غیرممکن است و تهدید به پایان دادن به این شرکت می کند.

در نایت ، برخی از نرم افزارهای جدید تجارت حاوی نقصی بودند که تنها پس از فعال شدن این نرم افزار هنگام افتتاح بورس نیویورک (NYSE) آن روز ، آشکار شد. نرم افزار Errant Knight را با یک خرید و فروش خریداری کرد و 150 سهام مختلف را با هزینه کل حدود 7 میلیارد دلار جمع کرد ، همه در ساعت اول تجارت.

طبق قوانین بورس اوراق بهادار ، نایت ملزم به پرداخت سه روز بعد برای آن سهام بود. با این حال ، هیچ راهی برای پرداخت آن وجود ندارد ، زیرا معاملات غیر عمدی بودند و هیچ منبع بودجه ای در پشت سر آنها نداشتند. تنها گزینه دیگر تلاش برای لغو معاملات یا فروش سهام تازه خریداری شده در همان روز بود.

نایت سعی کرد معاملات را لغو کند. ماری شاپیرو ، رئیس کمیسیون بورس و اوراق بهادار (SEC) از اجازه این کار برای بیشتر سهام مورد نظر خودداری کرد و به نظر می رسد این تصمیم صحیح بوده است. قوانینی پس از "سقوط فلش" در ماه مه 2010 تأسیس شد تا در هنگام لغو معاملات اداره شود. خرید نایت از قیمت سهام خریداری شده بیش از 30 درصد ، آستانه لغو ، به جز شش سهام ، قیمت سهام خریداری شده را بیش از 30 درصد افزایش نداد. آن معاملات معکوس شد. در موارد دیگر ، معاملات ایستادند.

این خبر بسیار بدی برای نایت بود اما فقط با شرکای تجاری خود ، که سهام خود را با حسن نیت به رایانه های نایت فروختند ، عادلانه بود. معاملات نایت مانند موارد سقوط فلش نبود ، هنگامی که سهام برخی از بزرگترین شرکت های جهان ناگهان شروع به تجارت با حداقل یک پنی کرد و هیچ خریدار نمی تواند ادعا کند قیمت معاملات منعکس کننده ارزش صحیح بازار است.

هنگامی که مشخص شد که معاملات ایستاده اند ، نایت چاره ای جز فروش سهام خریداری شده خود ندارد. درست همانطور که قیمت خرید صبح باعث افزایش قیمت آن سهام شده بود ، احتمالاً فروش گسترده به بازار باعث کاهش قیمت می شد ، احتمالاً تا جایی که نایت نتوانسته است ضررها را تأمین کند.

گلدمن ساکس برای خرید کل موقعیت ناخواسته نایت با قیمتی که نایت 440 میلیون دلار هزینه دارد - یک ضربه حیرت انگیز - اما یک شرکت ممکن است بتواند جذب کند. و اگر نایت ناکام ماند ، تنها طرف مصدوم ، جدا از سهامداران نایت (از جمله گلدمن) ، خود گلدمن بود.

دفع سهام به طور تصادفی تنها اولین قدم در نبرد توماس جویس ، مدیرعامل نایت برای نجات شرکت خود بود. این معاملات سرمایه این شرکت را کاهش داده بود ، که این امر را مجبور می کرد تا تجارت خود را به شدت کاهش دهد ، یا شاید به طور کلی متوقف شود ، بدون تزریق پول نقد. و با گسترش کلمه در مورد دفع نرم افزار ، مشتریان اگر به ظرفیت های مالی و عملیاتی آن اعتماد نداشته باشند ، می توانند شرکت را رها کنند.

یک هفته بعد ، نایت 400 میلیون دلار تزریق نقدی از گروهی از سرمایه گذاران دریافت کرد و تا تابستان آینده ، توسط یک رقیب به نام Getco LLC به دست آمد. این مطالعه موردی در مورد وقایع منتهی به این فاجعه ، آنچه اشتباه پیش آمد و چگونه می توان از این امر جلوگیری کرد ، بحث خواهد کرد.

اگر می خواهید اطمینان حاصل کنید که پروژه مهم کسب و کار شما به جای اینکه در لیست من با شکست پروژه قرار بگیرد ، شروع خوبی ندارد؟سپس حسابرسی پروژه جدید همان چیزی است که شما به دنبال آن هستید.

اگر می خواهید بدانید که با آن پروژه بزرگ ، چند ساله و استراتژیک در کجا ایستاده اید؟یا فکر می کنید یکی از پروژه های اصلی شما دچار مشکل شده است؟سپس یک بررسی پروژه همان چیزی است که شما به دنبال آن هستید.

اگر فقط می خواهید مطالعات موردی را در مورد عدم موفقیت پروژه بخوانید؟سپس نگاهی به نمای کلی از تمام مطالعات موردی که در اینجا نوشتم ، نگاهی بیندازید.

جدول زمانی وقایع

برخی از بزرگترین مشتریان نایت کارگزاران تخفیف و کارگزاری های آنلاین مانند TD Ameritrade ، E*Trade ، Scottrade و Vanguard بودند. نایت همچنین برای تجارت با غول های خدمات مالی مانند Citigroup ، UBS و Citadel به رقابت پرداخت. با این حال ، این رقبای بزرگتر می توانند به طور فزاینده ای از تجارت به دور از چشم عمومی در بازارهای اختصاصی خود یا بازارهای خصوصی مشترک ، به اصطلاح استخرهای تاریک درونی شوند. از سال 2008 ، بخشی از کلیه معاملات سهام در ایالات متحده که از بازارهای عمومی خارج می شود از 15 درصد به بیش از 40 درصد افزایش یافته است.

در اکتبر 2011 ، NYSE استخر تاریک خود را به نام برنامه نقدینگی خرده فروشی (RLP) پیشنهاد کرد. RLP می تواند یک بازار خصوصی از معامله گران در NYSE ایجاد کند که می تواند به طور ناشناس سهام را برای کسری از سکه ها بیشتر یا کمتر از پیشنهاد نمایش داده شده و قیمت ها به ترتیب ارائه دهد. RLP حتی در NYSE Euronext ، شرکت مادر NYSE بحث برانگیز بود. مدیرعامل آن ، دانکن نیدروئر ، نامه ای عمومی را در Financial Times با انتقاد از استخرهای تاریک به دلیل تغییر "اطلاعات بیشتر و بیشتر ... خارج از دیدگاه عمومی" نوشته بود و از روند کشف قیمت مستثنی بود. "

تصمیم SEC از سرمایه گذاران بزرگ نهادی بهره می برد که هم اکنون می توانند بلوک های بزرگی از سهام را با ناشناس بودن نسبی و بدون حرکت به بازارهای عمومی خریداری یا بفروشند. با این حال ، دوباره با هزینه سازندگان بازار آمد. در طی ماه های بحث ، جویس به RLP فرصت زیادی برای تأیید داده بود و در یک مصاحبه گفت: "صادقانه بگویم ، من نمی بینم که چگونه SEC می تواند خوب باشد."در اوایل ژوئن 2012 ، NYSE تأیید SEC از RLP خود را دریافت کرد ، و به سرعت اعلام کرد RLP در تاریخ 1 اوت 2012 به صورت زنده می رود و به سازندگان بازار تقریباً بیش از 30 روز آماده می شود. جویس اصرار داشت که در RLP شرکت کند زیرا تسلیم جریان سفارش بدون دعوا می تواند سود بیشتری را در بهترین خط تجارت خود بدست آورد.

چه چیزی اشتباه پیش رفت

با تنها یک ماه بین تأیید RLP و Go-Live ، تیم توسعه نرم افزار Knight با تب و تاب کار کرد تا تغییرات لازم را در سیستم های اجرای تجارت خود ایجاد کند-از جمله SMARS ، روتر الگوریتمی و با سرعت بالا. Smars مخفف سیستم مسیریابی دسترسی به بازار هوشمند است.

Smars قادر به اجرای هزاران سفارش در هر ثانیه بود و می تواند قیمت ها را بین ده ها مکان مختلف معاملاتی در کسری از ثانیه مقایسه کند.

یکی از ویژگی های اصلی Smars دریافت سفارشات از سایر مؤلفه های بالادست در بستر معاملاتی نایت (سفارشات "والدین") است و سپس ، در صورت نیاز بر اساس نقدینگی و قیمت موجود ، یک یا چند سفارش نماینده ("کودک") را به پایین دست می فرستد ،اماکن خارجی برای اعدام.

کد جدید RLP در Smars جایگزین برخی از کد های بلااستفاده در بخش مربوط به روتر سفارش شد. کد قدیمی قبلاً برای یک الگوریتم سفارش به نام "Power Peg" استفاده شده بود ، که نایت از سال 2003 استفاده از آن را متوقف کرده بود. Power Peg یک برنامه آزمایشی بود که بسیار زیاد و فروخته شده بود. این به طور خاص برای تأیید رفتار سایر الگوریتم های تجاری اختصاصی آن در یک محیط کنترل شده ، به منظور انتقال قیمت سهام بالاتر و پایین تر طراحی شده است. این در محیط تولید زنده و تولیدی مورد استفاده قرار نمی گرفت.

در زمینه فعلی مشکلات جدی با Power Peg وجود داشت. اول ، کد Power Peg با وجود عدم استفاده از آن ، در زمان استقرار RLP در زمان استقرار RLP حضور داشت. نگه داشتن چنین "کد مرده" عمل بدی است ، اما در سیستم های بزرگ نرم افزاری که سالها نگهداری می شود رایج است. دوم ، کد جدید RLP پرچمی را که قبلاً برای فعال کردن کد POWER PEG استفاده می شد ، مجدداً مجدداً مجدداً بازسازی کرده بود. هدف این بود که وقتی پرچم به "بله" تنظیم شد ، مؤلفه جدید RLP - نه Power Peg - فعال می شود. چنین تکرار مجدد اغلب باعث سردرگمی می شود ، فواید قابل توجهی نداشت و یک اشتباه بزرگ بود ، همانطور که به زودی خواهیم دید.

اصلاح مجدد کد

در طی سالها بدون آزمایش رگرسیون کامل ، اصلاحات قابل توجهی در Smars وجود داشته است. در سال 2005 ، نایت عملکرد کمیت تجمعی را که تعداد سهام سفارش والدین را که اجرا شده و پر شده بود ، تغییر داد تا تصمیم بگیرد که آیا دستور کودک دیگری را طی می کند. عملکرد کمیت تجمعی در حال حاضر در جریان کار Smars مورد استفاده قرار گرفت ، که در تئوری ایده خوبی برای جلوگیری از فعالیت بیش از حد سیستم بود. در عمل ، اکنون از Power Peg جدا شده است (که قبلاً آن را مستقیماً صدا می کرد) ، دیگر نمی توانست الگوریتم را هنگام پر کردن سفارشات ، دریچه کند و نایت هرگز پس از این تغییر ، Peer Peg را دوباره تکرار نکرد.

استقرار دستی

در هفته قبل از Go-Live ، یک مهندس شوالیه به طور دستی کد جدید RLP را در Smars به هشت سرور خود مستقر کرد. با این حال ، مهندس اشتباه کرد و کد جدید را در یکی از سرورها کپی نکرد. نایت یک مهندس دوم را در مورد استقرار بررسی نکرد و هیچ یک از سیستم های خودکار وجود نداشت که کسی را به این اختلاف هشدار دهد. نایت همچنین هیچ روش کتبی که نیاز به بررسی نظارتی داشته باشد ، تمام حقایقی که بعداً به آنها باز می گردیم.

در تاریخ 1 اوت ، ساعت 8:01 بعد از ظهر EST ، یک سیستم داخلی به نام BNET 97 پیام ایمیل ایجاد کرد که به SMARS مراجعه می کرد و خطایی را که به عنوان "Power Peg غیرفعال" توصیف شده است ، شناسایی کرد. این پیام های داخلی مبهم و داخلی به پرسنل نایت ارسال شد ، اما کانال آنها برای هشدارهای اولویت بالا تعیین نشده بود و کارکنان به طور کلی آنها را در زمان واقعی بررسی نکردند. با این حال ، آنها دود ضرب المثل کد ذوب شده و بیت های استقرار در مورد سوزاندن بودند ، و این فرصتی از دست رفته برای شناسایی و رفع مسئله DevOps قبل از باز شدن بازار بود.

ساعت 9:30 بامداد EST ، شوالیه شروع به دریافت سفارشات RLP از دلالان دلال کرد و Smars کار ورودی را به سرورهای خود توزیع کرد. هفت سرور که دارای کد RLP جدید بودند ، سفارشات را به درستی پردازش کردند. با این حال ، سفارشات ارسال شده به سرور هشتم با کد Peg Peg Peg که توسط پرچم بازسازی شده فعال شده است ، به زودی خط گسل یک صفحه تکتونیکی مالی را ایجاد می کند. این سرور بدون توجه به تعداد اعدام های تأیید شده که نایت قبلاً از سایر مکانهای تجاری دریافت کرده بود ، به طور مداوم سفارشات کودک را برای هر دستور والدین دریافت می کند.

نتایج بلافاصله فاجعه بار بود. برای 212 سفارش والدین ورودی که توسط کد POW POWER POWER پردازش شده است ، Smars هزاران سفارش کودک را در هر ثانیه ارسال می کند که می تواند زیاد بخرد و کم فروش کند و در نتیجه 4 میلیون اعدام در 154 سهام برای بیش از 397 میلیون سهم در حدود 45 دقیقه انجام شود. برای 75 مورد از این سهام ، اعدام های نایت بیش از 5 ٪ قیمت ها را افزایش داد و بیش از 20 ٪ از حجم معاملات را تشکیل می داد. برای 37 سهام ، قیمت ها بیش از 10 ٪ کاهش یافته و اعدام های نایت بیش از 50 ٪ از حجم معاملات را تشکیل می دهند.

پس از سقوط فلش در تاریخ 6 مه 2010 ، که در آن میانگین صنعتی داو جونز (DJIA) بیش از 1000 امتیاز در دقیقه از دست داد ، SEC چندین قانون جدید را برای تنظیم معاملات اوراق بهادار اعلام کرد.

1) اگر بازار آنچه را که به عنوان "نوسانات قابل توجه قیمت" بیش از 10 درصد در طی یک دوره پنج دقیقه ای شناخته شده بود ، از تجارت استفاده کنند.

2) SEC به شرایط خاص تری نیاز داشت که حاکم بر لغو معاملات باشد. برای وقایع بین پنج تا 20 سهام ، اگر حداقل 10 درصد از "قیمت مرجع" فاصله داشته باشند ، می توان معاملات را لغو کرد ، آخرین فروش قبل از قیمت گذاری مختل شد. در صورت انحراف بیش از 30 درصد از قیمت مرجع ، برای وقایع بیش از 20 سهام ، می توان معاملات را لغو کرد.

3) قانون مبادله اوراق بهادار قانون C. F. R 240. 15C3-5 ("قانون") به مرحله اجرا درآمد ، و به مبادلات و دلالان دلالان نیاز داشت تا کنترل های مدیریت ریسک را برای اطمینان از یکپارچگی سیستم های خود و همچنین بررسی اجرایی و صدور گواهینامه کنترل ها انجام دهند.

از آنجا که قوانین سقوط فلش برای نوسانات قیمت طراحی شده بود ، نه حجم معاملات ، آنها به عنوان در نظر گرفته شده و تجارت را متوقف نکردند و تجارت را متوقف کردند زیرا تعداد کمی از سهام که توسط نایت در آن روز سرنوشت ساز معامله می شدند از آستانه تغییر قیمت 10 درصد فراتر رفت.

تا ساعت 9:34 دقیقه بعد از ظهر ، تحلیلگران رایانه NYSE متوجه شدند که حجم بازار دو برابر سطح عادی است و سنبله حجم را به شوالیه ردیابی می کند. Niederauer سعی کرد با جویس تماس بگیرد ، اما جویس هنوز در خانه از جراحی زانو در حال بهبودی بود.

NYSE سپس به مدیر ارشد اطلاعات نایت هشدار داد ، که افراد برتر فناوری اطلاعات این شرکت را جمع کرد. بیشتر مغازه های تجاری می توانستند در الگوریتم های خود سوئیچ قتل را بچرخانند یا به سادگی سیستم های خاموش را خاموش کنند. با این حال ، شوالیه هیچ روش مستند برای پاسخ به حادثه نداشت ، دوباره واقعیت دیگری که بعداً به آن باز خواهیم گشت. بنابراین ، 20 دقیقه دیگر در تاریکی ادامه داد و تصمیم گرفت که مشکل کد جدید باشد.

از آنجا که گفته می شود نسخه "قدیمی" کار کرده است ، نایت دوباره به کد قدیمی بازگردد که هنوز روی سرور هشتم کار می کند و دوباره آن را دوباره نصب کرد. همانطور که معلوم شد ، این بدترین تصمیم ممکن بود زیرا در حال حاضر هر هشت سرور کد POW POWER PEG را با پرچم RLP سوء استفاده شده و بدون دریچه گاز اجرا می کردند.

تا ساعت 9:58 دقیقه بعد از ظهر بود که مهندسان شوالیه علت اصلی را شناسایی کردند و بر روی همه سرورها اسمز را خاموش کردند. با این حال ، این خسارت انجام شده است. نایت بیش از 4 میلیون معاملات را در 154 سهام در مجموع بیش از 397 میلیون سهم اجرا کرده بود. این موقعیت یک موقعیت طولانی خالص در 80 سهام تقریبی 3. 5 میلیارد دلار و همچنین موقعیت کوتاه خالص در 74 سهام تقریبی 3. 15 میلیارد دلار را به عهده گرفت.

چگونه Knight Capital می توانست کارها را متفاوت انجام دهد

این مطالعه موردی شامل چندین درس مفید برای مدیران پروژه ، متخصصان فناوری اطلاعات و رهبران تجارت است. نایت می توانست از خرابی جلوگیری کند و با انواع توسعه نرم افزار مدرن و شیوه های عملیاتی (DEVOPS) آسیب ها را به حداقل برساند. در زیر ، من هشت مورد از این اقدامات را شرح می دهم و چگونه آنها می توانند برای Knight Capital تفاوت ایجاد کنند.

استفاده از کنترل نسخه

کد مرده را اجرا نکنید. در عوض، همیشه کدهای مرده را هرس کنید و از سیستم های کنترل نسخه برای ردیابی تغییرات استفاده کنید. شما نباید پرچم های پیکربندی را دوباره هدف قرار دهید. در عوض، ویژگی های جدید را با پرچم های جدید فعال کنید.

کنترل نسخه هر نوع تمرینی است که تغییرات کد منبع را ردیابی و کنترل می کند. تیم ها می توانند از نرم افزار کنترل نسخه برای نگهداری اسناد و فایل های پیکربندی و همچنین کد منبع استفاده کنند.

از آنجایی که تیم ها نرم افزار را طراحی، توسعه و استقرار می دهند، معمولاً چندین نسخه از یک نرم افزار در سایت های مختلف مستقر می شوند و توسعه دهندگان نرم افزار به طور همزمان روی به روزرسانی ها کار می کنند. اشکالات یا ویژگی های نرم افزار اغلب فقط در نسخه های خاصی وجود دارد (به دلیل رفع برخی از مشکلات و معرفی برخی دیگر با توسعه برنامه).

بنابراین، برای اهداف مکان یابی و رفع اشکالات، بسیار مهم است که بتوان نسخه های مختلف نرم افزار را بازیابی و اجرا کرد تا مشخص شود مشکل در کدام نسخه(ها) رخ می دهد. همچنین ممکن است لازم باشد که دو نسخه از نرم افزار را همزمان توسعه دهید: به عنوان مثال، جایی که یک نسخه دارای اشکالات رفع شده است، اما ویژگی های جدیدی وجود ندارد (شاخه)، در حالی که نسخه دیگر جایی است که روی ویژگی های جدید کار می شود (ترانک).

تست های واحد نوشتاری

هدف از تست واحد یافتن اشکال نیست. این یک مشخصات برای رفتار مورد انتظار کد تحت آزمایش است. کد مورد آزمایش پیاده سازی برای آن رفتارهای مورد انتظار است. بنابراین از تست های واحد و کد مورد آزمایش برای بررسی صحت یکدیگر و محافظت از یکدیگر استفاده می شود. بعداً، وقتی کسی کد تحت آزمایش را تغییر می دهد و رفتار مورد انتظار نویسنده اصلی را تغییر می دهد، آزمایش با شکست مواجه می شود. اگر کد شما توسط تعداد معقولی از تست های واحد پوشش داده شده است، می توانید کد را بدون شکستن ویژگی موجود حفظ کنید. به همین دلیل است که مایکل فیرز در کتاب اصلی خود "کار به طور موثر با کد قدیمی" به عنوان کد بدون آزمون واحد تعریف می کند. بدون تست واحد، هر بار که کد قدیمی خود را تغییر می دهید، تلاش های توسعه شما یک خطر بزرگ خواهد بود.

بررسی کد

بررسی کد یک بررسی سیستماتیک (گاهی اوقات به عنوان بررسی همتا از آن یاد می شود) کد منبع است. هدف آن یافتن اشتباهات نادیده گرفته شده در توسعه نرم افزار و بهبود کیفیت کلی نرم افزار است. بررسی ها به اشکال مختلفی مانند برنامه نویسی زوجی، بررسی های غیررسمی و بازرسی های رسمی انجام می شود.

تست های خودکار و تست اتوماسیون

در دنیای آزمایش به طور کلی و به ویژه ادغام و تحویل مداوم ، دو نوع اتوماسیون وجود دارد:

1) تست های خودکار 2) اتوماسیون تست

در حالی که ممکن است فقط دو روش متفاوت برای گفتن یکسان به نظر برسد ، این اصطلاحات در واقع معانی بسیار متفاوتی دارند.

تست های خودکار تست هایی هستند که می توانند به صورت خودکار اجرا شوند ، که اغلب به زبان برنامه نویسی توسعه می یابد. در این حالت ، ما در مورد موارد آزمون فردی ، یا آزمون های واحد ، ادغام/خدمات ، تست های عملکرد ، تست های پایان 2 یا آزمون پذیرش صحبت می کنیم. مورد دوم همچنین به عنوان مشخصات به عنوان مثال شناخته می شود.

اتوماسیون تست یک مفهوم گسترده تر است و شامل تست های خودکار است. از دیدگاه من ، باید در مورد اتوماسیون کامل چرخه های آزمون ، از ورود به سیستم تا استقرار-که به آن آزمایش مداوم نیز گفته می شود ، باشد. هر دو تست خودکار و اتوماسیون تست برای زایمان مداوم از اهمیت بالایی برخوردار هستند ، اما این دومی است که باعث می شود تحویل مداوم از کیفیت بالا حتی امکان پذیر باشد.

اگر نایت تست های خودکار و اتوماسیون تست را برای عملکردهای جدید و موجود SMARS انجام داده بود ، آنها قبل از استقرار آن در تولید ، خطا را به خود جلب می کردند.

فرآیند استقرار خودکار

برای ساختن نرم افزار عالی و آزمایش آن کافی نیست. شما همچنین باید اطمینان حاصل کنید که آن را به درستی به بازار عرضه شده است تا مشتریان شما از ارزش شما تحویل بگیرند (و بنابراین شرکت خود را ورشکسته نمی کنید). مهندس (بازدید کنندگان) که Smars را مستقر کرده اند ، فقط در اینجا مقصر نیستند - فرایندی که شوالیه تنظیم کرده بود برای ریسکی که در معرض آن قرار داشتند مناسب نبود. علاوه بر این ، روند آنها (یا فقدان آن) ذاتاً مستعد خطا بود. هر زمان که روند استقرار شما به خواندن انسان و دستورالعمل های زیر متکی است ، خود را در معرض خطر قرار می دهید. انسان اشتباه می کند. اشتباهات می تواند در دستورالعمل ها ، در تفسیر دستورالعمل ها یا اجرای دستورالعمل ها باشد.

استقرار باید به صورت خودکار و قابل تکرار و عاری از خطای بالقوه انسانی باشد. اگر نایت یک سیستم استقرار خودکار را اجرا کرد - کامل با پیکربندی ، استقرار و اتوماسیون تست - از خطایی که باعث کابوس شد ، اجتناب می شد.

راهنمای فرآیند استقرار گام به گام

هر کسی (حتی کسی که معمولاً این کار را نمی کند) باید بتواند با این راهنما روی میز ، تولید را مستقر کند. البته هرچه بیشتر به سمت استقرار خودکار بروید ، این راهنما کوچکتر می شود ، زیرا تمام مستندات این فرآیند در فرآیندهای خودکار شما کدگذاری می شود. احتمال انجام کار اشتباهی در یک راهنمای گام به گام (یا یک لیست چک) ، تعداد کمی از افراد کوچکتر است. این بارها در فضای پزشکی ثابت شده است.

جدول زمانی دلیل دیگری بود که نایت نتوانست راه حل RLP را ارائه دهد. مدیران پروژه IT Knight و CIO باید به برنامه تحویل بیش از حد تهاجمی بازگردند و رهبران تجارت خود را با یک برنامه فاز جایگزین به جای Big Bang-Pun در نظر گرفته شده مخالفت کنند. سی روز برای اجرای ، آزمایش و استقرار تغییرات اساسی در یک سیستم معاملاتی الگوریتمی که برای ساختن روزانه به ارزش میلیاردها دلار استفاده می شود ، تحریک آمیز ، ساده لوح و بی پروا است.

مدیریت ریسک

مدیریت ریسک یک توانایی حیاتی برای یک سازمان مدرن ، به ویژه برای شرکت های خدمات مالی است. گزارش SEC (به منابع مراجعه کنید) نتیجه گرفت: "اگرچه فناوری خودکار مزایایی را برای سرمایه گذاران ، از جمله افزایش سرعت اجرای و برخی کاهش هزینه ها به ارمغان می آورد ، اما معاملات خودکار نیز خطرات خاصی را تقویت می کند. از آنجا که شرکت کنندگان در بازار به طور فزاینده ای به رایانه ها برای تصمیم گیری در مورد مسیریابی و تصمیم گیری در مورد سفارشات متکی هستند ، ضروری است که عملکردهای انطباق و مدیریت ریسک در کارگزاران یا نمایندگی ها سرعت خود را حفظ کنند ... شیوه های مدیریت ریسک خوب فناوری شامل تضمین کیفیت ، بهبود مداوم ، آزمایش پذیرش کاربر کنترل شده ، اندازه گیری فرآیند، مدیریت و کنترل ، بررسی منظم و دقیق برای رعایت قوانین و مقررات قابل اجرا ، یک فرآیند حسابرسی مستقل ، حاکمیت فناوری که از نقص نرم افزار ، خطاهای سیستم و خرابی ، قطع خدمات و هنگام بروز چنین مواردی جلوگیری می کند ، سریع ، مؤثر و ریسکپاس خ-پاسخ. "

در حالی که نایت در سایر سیستم ها کنترل سفارش داشت ، اما سفارشات خروج از Smars را با مواردی که وارد آن شده بودند مقایسه نمی کرد. ابزار اصلی نظارت بر ریسک نایت ، معروف به "PMON" ، یک سیستم نظارت بر موقعیت پس از انتشار است. در افتتاح بازار ، پرسنل ارشد شوالیه حجم زیادی از موقعیت ها را در یک حساب ویژه به نام 33 مشاهده کردند که به طور موقت انواع مختلفی از موقعیت ها را در اختیار داشتند ، از جمله موقعیت هایی که ناشی از اعدام هایی است که نایت از بازارهایی دریافت می کند که سیستم های آن نمی توانند با ناپدید شده مطابقت داشته باشند. مقدار سفارش والدین. حد ناخالص 2 میلیون دلاری به حساب 33 وجود داشت ، اما به هیچگونه کنترل خودکار در مورد قرار گرفتن در معرض مالی کلی نایت مرتبط نبود.

علاوه بر این ، PMON کاملاً به نظارت انسان اعتماد داشت ، هشدارهای خودکار ایجاد نکرد و نمایش قرار گرفتن در معرض حساب را بر اساس اینکه آیا از حد مجاز فراتر رفته است ، برجسته نمی کند. علاوه بر این ، نایت همچنین هیچ مدرک مداری نداشت ، که این یک الگوی استاندارد و عمل برای شرکت های خدمات مالی است.

افکار پایانی

اگرچه نایت در آن زمان یکی از با تجربه ترین شرکت ها در تجارت خودکار بود (و نرم افزاری که با آن همراه است) ، نتوانست بسیاری از بهترین روشهای استاندارد DevOps را اجرا کند که می تواند در هر تعداد فواصل از این فاجعه جلوگیری کند.

Holdings Group Knight Capital سرانجام در ژوئیه سال 2017 با قیمت 1. 4 میلیارد دلار توسط یک رقیب دیگر ساخت Rival ، Virtu LLC به دست آمد. پوشش نقره ای به داستان این بود که نایت برای شکست خیلی بزرگ نبود و بازار با یک نجات نسبتاً سازمان یافته بدون کمک مالیات دهندگان ، شکست را انجام داد. با این حال ، یک ابر تاریک باقی مانده است: داده های بازار نشان می دهد که 70 درصد از تجارت سهام ایالات متحده اکنون توسط بنگاه های تجاری با فرکانس بالا اجرا شده است و فقط می توان تعجب کرد که چه زمانی ، نه ، سقوط بعدی فلش رخ خواهد داد.

اگر می خواهید اطمینان حاصل کنید که پروژه مهم کسب و کار شما به جای اینکه در لیست من با شکست پروژه قرار بگیرد ، شروع خوبی ندارد؟سپس حسابرسی پروژه جدید همان چیزی است که شما به دنبال آن هستید.

اگر می خواهید بدانید که با آن پروژه بزرگ ، چند ساله و استراتژیک در کجا ایستاده اید؟یا فکر می کنید یکی از پروژه های اصلی شما دچار مشکل شده است؟سپس یک بررسی پروژه همان چیزی است که شما به دنبال آن هستید.

اگر فقط می خواهید مطالعات موردی را در مورد عدم موفقیت پروژه بخوانید؟سپس نگاهی به نمای کلی از تمام مطالعات موردی که در اینجا نوشتم ، نگاهی بیندازید.