Коли баг мінорний і його можна спокійно пофіксити, то це, зазвичай, не викликає занепокоєння. Страшно стає тоді, коли баг кладе половину проду і тягне за собою фінансові втрати, розміром в десятки, сотні, а то й мільйони доларів.
Чи траплялися у вас подібні кейси? Якого найбільшого розміру збитків вони сягали?
Планировалось обновить версию базы, составили план, как это сделать ночью при минимуме нагрузки и без простоя сервисов, теоретически данные должны были накапливаться в кафке, которые потом бы выгрузились в постгрес. Но что-то пошло не так или неправильно потушили некоторые сервисы и база не могла нормально перестроить индекс на куче таблиц, так как он постоянно пересоздавался, итог 2 суток простоя, пока руками тупо не заскейлили все сервисы в 0 инстансов. Затем каскадом начали отваливаться сервисы, масса злых клиентов и утраченный полностью доход. Потом прислали аудиторов и выгнали тупого СТО, и еще некоторых галерных любимчиков, которые были всунуты руководством по знакомству на хорошие места, а заодно и пару топ-менеджеров, которые пропихивали кадры по принципу кумовства, а не квалификации
Непонятна связь между любимчиками и конкретным решением, которое прошло не так...
Что именно они не так сделали?
Страшно стає тоді, коли баг кладе половину проду і тягне за собою фінансові втрати, розміром в десятки, сотні, а то й мільйони доларів.
це реальні збитки, чи ілюзії ?
і чиї? ваші?
як ви взагалі потрапили у таку відповідальну ситуацію?
(мені от складно розбити чийсь мерс... бо не сідаю за кермо)
Не дорогий, але смішний (і трохи моторошний) баг.
Ми працюємо із CRM, наш клієнт надає ритуальні послуги. Багато такого в штатах продається наперед, бо входить у страхівку.
Ми робили геть невеликий шматок, який би забезпечив можливість продажникам ініціювати саме такі переговори, завершені безрезультатно більше як пів року тому. Клієнт доя цього найняв зовнішній колцентр і забезпечив скриптами на продзвін.
Через те, що клієнт нам не повідомив про ще одну автоматизацію, наша логіка працювала і для клієнтів з явною потребою (ну тобто кому послуги потрібні прям вже).
Поки ми відкотили оновлені дані і пофіксили логіку (десь години 2), порядка 100 клієнтів отримали дзвінки, яких явно не очікували, від компанії, котра пеаний час тому ховала чи кремувала їх рідних.
Якось працював на анті-спам проекті великої міжнародної компанії. На нас, окрім інженерних задач, був ще «emergency support» — це коли треба було негайно реагувати на якийсь свіжий
І ось, в черговий outrbreak SPAM-у, ми пишемо правило, яке його блокує, перевіряємо його локально, все супер, комітимо його в прод, проходить 5 хвилин і... ми бачимо, як в світі стримко зростає кількість повідомлень, відмічених, як СПАМ. Дивимось ближче і бачимо, що ВСЯ пошта, яка проходить через наші девайси бв світі помічається, як СПАМ.
Ми дістаємо свій джедайський регексп, що мав пофіксити новий СПАМ, дивимось, що там, де мало бути &&, стоїть ||, дивуємось, якого лисого тести цього не помітили, швиденько фіксим правило, заливаємо свіжу базу, запускаємо retrain всього СПАМу у всіх СПАМ-скриньках девайсів по світу і видихаємо.
Здається, ніхто із клієнтів не помітив цього фейлу, а команда навіть отримала подяку від замовників за швидке гасіння свіжого СПАМу.
Відстань від початку SPAM outbreak до завершення фіксу на девайсах — півгодини і декілька тисяч сивих волосин команди.
Був один, не дорогий, але забавний баг:
В системі для усіх онлайн кастомерів із беку по вебсокетам розсилалися статуси доступності певних надавачів послуг на платформі, але через баг, ця штука ітеративно самотригерилась і розсилала для кожного онлайн кастомера кратно більше івентів, ніж необхідно. Баг не помітили вчасно через низку причин:
— бек був намастштабований достатньо, щоб доволі довгий час безболісно переносити таке неподобство;
— аудиторія росла не експоненційно, і в моменті, протягом дня, зазвичай не ставалося такого, що х1000 онлайн кастомерів ставало;
— функціонал фронта, який завʼязувався на цей івент довгий час лишався доволі простим;
І от саме через останні два пункти цей баг виліз: почала різко зростати аудиторія та на фронті протягом 1.5 тижні нарелізили купу важкого для фронтових рушіїв функціоналу. Що призводило до т.н. «діскатєкі вєка» на юайці, навіть були стабільні скарги на «девайс починає нагріватися поки я у вас на сайті», ну і на беку графана спайкувала під час масових пушів, коли багато кастомерів заходили на платформу.
Гіпотетично, цьому багу навіть можна приписати якийсь відсоток глобального «вуглецевого сліду» за ті місяці, поки він існував.
Міг бути один баг на незліченну сумму збитків, але наявність бекапів і логу транзакцій усе врятувала )
Бекапи — наше все) Головне вчасно переконатися, що вони підготовлені, а не просто є))
Всім одразу згадується цей кейс, де втрати були $10+ мільярдів
en.wikipedia.org/...Strike-related_IT_outages
Але... ці втрати вони насправді не були такими масштабними, навіть близько. Ну посиділи люди трохи більше в аеропорту, скасували якісь рейси. Та таке регулярно буває і через інші причини.
А ось AI накидав випадків цікавих
1. Knight Capital — $440 млн за 45 хвилин (2012)
Один із найвідоміших кейсів в IT
Компанія розгорнула нову версію trading-софта
Один сервер не оновили
Старий код почав масово виставляти неправильні ордери
$440 млн збитків менш ніж за годину
Компанія фактично збанкрутувала
Пізніше була продана
2. Citibank — $900 млн «помилково відправлені» (2020)
Співробітник хотів відправити відсотки
UI системи був настільки поганий, що відправив повну суму кредиту
$900 млн реально пішли кредиторам
Частину грошей не вдалося повернути
Суд визнав: «так, це була помилка, але банк винен сам»
3. Ariane 5 — $370 млн (1996)
Ракета вибухнула через integer overflow
Виняток → аварійне завершення системи навігації
Ракета самознищилась через 40 секунд
~$370 млн збитків
Одна з найвідоміших катастроф через баг
4. Amazon — десятки мільйонів через pricing-баги
Алгоритмічні баги в ціноутворенні
Товари продавалися нижче закупівельної ціни
Масові замовлення ботами
Частину замовлень виконали
Частину скасували
Загальні втрати — десятки мільйонів $
5. Ethereum DAO hack — ~ $60 млн (2016)
Формально це security-bug, але все одно прод-код
Reentrancy-баг у smart contract
Контракт працював «як написано», але не «як задумано»
~$60 млн в ETH виведено
Ethereum зробив hard fork
Ethereum Classic існує саме через це
Как-то пришлось отзывать и переделывать около 100тыс готовых устройств. Несколько месяцев работы производства.
На одному з попередніх місць роботи мої колеги випадково залили на прод тестові дані, які у вигляді апдейтів розлетілися на сотні тисяч електро-механічних пристроїв. Якби ми не знайшли спосіб це швидко пофіксити, то потенційні витрати за приблизними оцінками були б в районі 10 мільйонів євро. Але, слава богу, все обійшлося, рішення було швидко знайдене та імплементоване і практично ніхто нічого не помітив) Тільки у нас з’явилося декілька додаткових сивих волосин в бороді.
юнит тест
Valentin Nechayev
Юра
Oleksandr Klymenko
Oleksandr Suvorov
Alex Zodov
Михайло Власенко
Pavlo Trepytion
Чорний Список Юджина
Valdis Gerasymiak
Oleksandr Viter
11 коментарів
Додати коментар Підписатись на коментаріВідписатись від коментарів