Робочі фейли, помилки, факапи. Діліться 👻

Усі статті, обговорення, новини для початківців — в одному місці. Підписуйтеся на телеграм-канал!

Привіт, спільното! Вам сподобалось обговорювати співбесіди та відмови роботодавців. А як щодо робочих фейлів та помилок? Джуніорських й не дуже, вагомих та мінорних, а може тих, про які досі ніхто не знає? 😉

Розповідайте, як факапили та який досвід з цього винесли!

👍ПодобаєтьсяСподобалось3
До обраногоВ обраному1
LinkedIn

Найкращі коментарі пропустити

Поклав на 40 хвилин залізничні каси львівської УЗ коли замість стейджинг серверу вимкнув прод і пішов на обід.

Намагаєтеся зʼясувати, хто двічи поклав моно?

Багато років тому під час демо на всю команду мені прийшло повідомлення від менеджера про звільнення частини команди і перелік людей, яких будуть звільняти. Проблема в тому, що команда була не в курсі звільнень, а я в той момент робила демо і шаріла увесь екран на всіх. Тепер вимикаю усі месенджери під час будь яких мітингів.

Поклав мережу банкоматів Привату день на годинку

Залишив десь 10000 абонентiв без iнтернета на вихiднi зробивши shutdown не в тому термiналi. Тех.пiдтримка(я) по вихiдних не працювала.

Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Видалив табличку з коментами і пішов на обід. А шо такова?)
Але мене бистро знайшли.
Давно було.

Не мій фейл, але причетний був. Бази прода і стейджинга були на одному nas, і через мої експерименти з перфоманс тестами на стейджі прод база стала працювати в 20 разів повільніше, бо місце майже закінчилося.

Було це десь наприкінці 2000-х.
На сервері віртуального хостінгу здох головний винт. Бекапи були на тій же машині, тож, нічого не передвіщало довгих проблем. Специ ДЦ Воля швидко замінили дохлий вінт, втикнули флешку із потрібним дістром Лінукса і надали мені віддалений доступ. Я швиденько поставив туди ОС, хоча, гм. Чомусь все-таки швидкіст роботи нового вінта була якась замала... Ну і бог із ним, треба швидше! Відновив всіх клієнтів із бекапа (теж чогось якось повільненько було, ну да то таке — треба швидше запустити сервер в роботу!), стартанув весь хостінг, весело повідомив клієнтам, що все ок, все знову працює і пішов спатки...

Але буквально одразу посипались скарги: трошки, потім більше, ще більше, всі клієнти цього сервера почали скаржиться, що сайти відкривають дуже повільно і не витримують навантаження навіть в декілька відвідувачів...

Тут вже поліз розбиратись. І вияснив, що швидкість передачі 7200rpm sata-вінта — всього на рівні 1-2 Мбпс, і при цьому іо зжирає 100% процесора. Що відбувається? Як так? Нарешті настав час читати документацію. Подивився модель вінта, читав його характиристики і шукав відмінності від попередьного. І ось воно! Нова модель вінта — сучасна і новомодна! У неї крутий новий контролер! У цього контролера крутий новомодний хардвер сектор 4096 байт замість старих і немодних 512!

Тут я почав щось підозрювати і призвав на допомогу гугл. Як і очікувалось, ця проблема була не тільки у мене: виявляється, якщо розбити диск без вирівнювання на 8192, тоді кожна операція читання застосовуються мінімум для двох сусідніх блоків, окремо рахуються контрольні суми кожного з них і потім конкатенуються дані частково з першого і з другого. Це в рази підвищувало навантаження і на контролер диска, і на саму систему.

Ух ти! Де мій fdisk? Точно! 5-а чи 6-а CentOSь мала старий fdisk, який по замовчуванню починав перший розділ з... 63-го 512-байтного сектора!

Що ж, довелось знову зупиняти сервер, переформатувати диск, почавши розділ з сектора, кратного 16-и і знову відновити хостинг із останніх бекапів.

У підсумку, цей хостінг-сервер «валявся» майже добу і втратив порядка 20% клієнтів :(

Вирішив що дуже треба мені прямо зараз оновити ядро на сервері зі слейвом Редісу, кажу «та ребутай, це ж слейв». Мастер замість відповідей почав казати «де мій слейв». Прод валявся 10 хвилин.

На чорну пʼятницю сидів дивився шо б таке закешувати ще, щоб пережити хвилю о 8 вечора, надивився що головна забагато навантаження робить і закешував її. З відповіддю з кукою сессії конкретного користувача (дякую джанга за те як ти працюєш). Всі користувачі стали Анатоліями, а через 20 хв, коли ми зрозуміли і почали чистити кеш, зачистили забагато і прод вмер на три години. Дивним чином мене не звільнили і я пропрацював ще майже 7 років. 😁

Написав нескінчений цикл і сервера іноді вмирали 3 місяці поспіль поки зрозумів що відбувається.

Придумав кльову схему БД яка поставила купц апдейтів в конфліктне становище і загалом в дедлоки. Здохли буквально на 15 хв, поки відкочувалися. :)

Всього і не згадаєш, кароч. 🤣

Налаштував інстанс якось, в крон додав джобів різних щоб вночі щось робили. Тайм зону не перевірив. Просто забив. Поклав прод майже на дві години. Дуже гарний урок, тепер завжди перевіряю годинник на віртуалці

Колись давно ще працював на руснявому проекті, rabota.ru
Там був жахливий лайно-код, що за нього ніхто братися не хотів. Взяли мене з маленьким досвідом, ну і я теж ще зверху навалив.
Епік фейл був, коли я тестив Firebase push notifications і відправив на прод всім нотифікацію з заголовком та текстом Test :)
Зараз жалкую, що не написав про пуйла😄

Якось тестив команду яку хотів на проді (й добре що то був тест k8s) запустити ansible-playbook -i inventory.ini -e NODE=node3 remove-node.yaml, все наче норм, але якщо написати NODE то його взагалі не сприймає і видаляться всі голи в кластері, бо ліміту немає, потрібно писати node

За те, що ансібль, знайшовшb невідомий параметр, продовжує виконання деструктивної команди, розробників ансібля треба довго бити головою об стіну.

Працював в одній конторі на три роки довше, ніж було варто.

Сказал что делать неделю, а сам справился за 4 часа.

Так факап це коли навпаки — сказав що до вечора буде готово, а потім трахався всі вихідні :)

Добре, що тема не англійською. Це був би потужний удар по українському аутсорсу.
Переїжджав датацентр. Не стартонув зібраний у новому ДЦ дата сторедж з розділами прод серверів.

1995 чи біля того, я ще просто юзер.
Була така читалка Usenetʼа WinVN. Ось відправив листа... і щось вікно «відправляю» не закривалось хвилину чи більше.
Програма зависла. Вбив, перезапустив.
Через пів-дня мені розказують, що «завалив» мережу.
Зʼясувалось:
— Відправляв з опцією «копія на email».
— Локальний SMTP сервер щось задумався, чи мережу проглючило.
— Код відправки по SMTP був у WinVN в окремому процесі. Вбивство головного процеса де GUI не зупинило його (і я не знав назву цеї частини). Не памʼятаю, але потім чи бутнув машину, чи помітив його і вбив окремо.
— Цей окремий процес, втративши батька, відправляв листа знову і знову поки не вбили.
— На сервері був sendmail, якому керувати навантаженням було треба ще настроїти, і він просто пригнітив весь сервер, що і помітили. (Мабуть, це на краще, бо декілька тисяч однакових листів отримувачу це було б не добре.)

Email взагалі легко перетворюється на бомбу з саморозвитком. Наприклад, 3 сервери. Колега ставить форвард з A на B і C, з B — на A і C, з C — на A і B. З першого листа на staff@ пошта впадає. Ліміт для відсічення — 25 хопів — 32 міліони копій — витримати було неможливо.

Цикли баунсів я на своїй памʼяті зупиняв, мабуть, разів 50. І є проти цього цілий RFC, але хто ж його читає...

Видалили один каталог на сервері.
На наступний день сервер опинився в нерабочому стані, видалені майже всі файли.
Пішли дивитись... нічого не знайшли. Лише за бекапом конфігу і згадками колег вираховували, що було.
Раз на добу запускався скрипт на зразок

cd dir1
find . -mtime +20 -delete
cd
cd dir2
find . -mtime +30 -atime +30 -delete
cd /
Виконання команд cd dir1, dir2... не було перевірено (чи set -e чи if). dir2 був видалений вручну. `find ... -delete` вбив майже все на FS, включаючи і той скрипт. Якщо це не був би факап, вирішили, що маємо ідеальний злочин:))

Був на тестовому сервері в терміналі рутової директорії, потрібно було видалити декілька папочок, прописав команду , але неправильно і видалив вест тестовий сервер під нуль)) за трохи більше тиждень вдалось все відновити)

Не моё, из соседнего отдела (но вообще классика, чуть ли не в каждом интернет-провайдере повторялось).
Глобальный раутинг делается через BGP, там на тот момент было около 50 тысяч записей, насколько помню. Локальный по OSPF, больше сотни — редко. Есть система передачи раутов между ними, иногда полезна, но надо тщательно ограничивать набор поступающих записей. Внутренний раутинг держится в памяти большинства раутеров у которых более аплинка или пира. При этом были в наличии даже маломощные зверьки вроде Cisco 2511 с 8MB оперативки и 20МГц MIPS процессором — Cisco обожала экономить на ресурсах.
На центральном раутере был настроен redistribute BGP->OSPF прикрытый access list’ом с «deny any any». Однажды админ решил удалить список, не заметив, что он используется. Пустой список становится открытым (permit any any), все 50k записей побежали в OSPF.
В прошивке у цисок всё крутилось в одном процессе без должного контроля по переполнениям. Половина, начав всасывать такой поток, просто зависла. Но часть дала более странные эффекты, снеся куски своего конфига.
Это было в обед, и до конца дня канальщики ездили по всему городу, где просто нажимая Reset, а где вводя по телефону команды восстановить IP-доступ.

Python. Код телефонной станции. Написал в заголовке класса: legacy_accounting = []
Закоммитил. Подумал, что что-то не то. Перенёс инициализацию пустого списка в конструктор, как и должно быть. Закоммитил.
Оказалось, между этими коммитами код отфоркнули для релиза. При трансфере список добавлялся к целевому звонку, а в старом не чистится — зачем, оно само уйдёт при завершении звонка.
После первого же трансфера список (общий между всеми объектами) начинал копироваться, и скоро станция падала сразу по двум причинам — список разбухал до миллионов элементов, а биллинг сходил с ума под копиями стопов.
Правка была тривиальна, но раздать всем клиентам было не очень просто.

Колись у нас заглючив на проді скрипт який відсилає імейли юзерам, і деяким юзерам він пару днів слав імейли кожні 30хвилин.
Один з тих юзерів потім розлютився і налаштував якісь свої скрипти щоб вони спамили імейлами з еротикою нашому керівництву ще довго)))

Ну і з чужих фейлів це фермери, які обірвали оптоволокно в полі і Житомир залишився без інтернету нашого

Сидячи в Києві такі випадки чули 1-2 рази на тиждень:) Страна велика, бульдозерів безліч...

Працював у інтернет провайдера у підтримці ще у 2013, на той час компанія ще надавала послуги в Севастополі.
Зазвичай були свічі на 24 порти, якщо не помиляюсь, останні були транкові, які обʼєднували мережу в кільце. Був абонент ніби як на 12 порті — вирішив ребутнути і поклав половину району.
Виявилось, що там було інше обладнання і 12 порт зʼєднався з іншими свічами :(
На щастя, інженер був неподалік і за годину зміг перезапустити залізо локально, оськільки конфіг не був збережений, то мережа піднялась

В перший робочий день відправив PO не тільки public ssh key, але й випадково private. Було дуже соромно, але він поставився з розумінням: «Bro, you owe me a beer».

Ще вклала прод одного німецького банку на 3 години у бізнес час. Бекап розвертався якраз 3 години. Заодно і протестувала час розгортання бекапу прода
Тестували платіжні системи на проді, втратили кілька шт уо через неправильно налаштовані ліміти на реальній картці клієнта
Тих фейлів за 15 років стільки вже було

Колись на одній зі старих робіт декілька сайтів «сінканув» по FTP з пустими папками. Добре що бекапи були ранкові. Але з тих пір не довіряю автоматизації процесів на проді.

А, ще згадав, що колись запушив фікс без тестів, просто на «я знаю що роблю», і тим самим зробив інший баг, ще більш критичний. Слово «quickfix» повністю зникло з мого словника)

Багато років тому під час демо на всю команду мені прийшло повідомлення від менеджера про звільнення частини команди і перелік людей, яких будуть звільняти. Проблема в тому, що команда була не в курсі звільнень, а я в той момент робила демо і шаріла увесь екран на всіх. Тепер вимикаю усі месенджери під час будь яких мітингів.

В 2013 під час майдану, працював на росіян та нічого їм не зламав. Щоправда про золотий унітаз я тоді ще нічого не знав, хоч і здогадувався.

Перед початком коллу поки всі збирались передражнювали зарубіжного скрам мастера, який з сильним акцентом завжди казав коли хтось приєднується на колл «hello, who just joined» — а мікрофон виявився не зам’ютаним :D

Сподіваюсь він не образився :D

Працюючи в мережі маркетів підключився віддалено на роутер і за логікою мав перевірити параметри 3г підключення, оскільки основна лінія лягла, намагався зрозуміти що завантажує канал і випадково задізейблив інтерфейс 3г то магазин добу був без інету і як наслідок без оновлених цін, без звітів і без зв’язку з зовнішнім світом. Це була п’ятниця... тож наступний день був днем відрядження)) сам накосячив, сам виправив)

Розробляв рек’юринг фічу й чи то при ребейзі чи то через рукожопство інше зник рядок коду, котрий сетає новий due_date. В підсумку, код «залупився» й створив 1.8 млн рекордсів + на кожну 2 асоціації та відправив 25к мейлів. Добре, що хоч на стейджі то помітив. Добу вже то видаляю.

Розробляв рек’юринг фічу й чи то при ребейзі чи то через рукожопство інше зник рядок коду, котрий сетає новий due_date. В підсумку, код «залупився» й створив 1.8 млн рекордсів + 2 асоціації на кожну та відправив 25к мейлів. Добре, що хоч на стейджі то помітив. Добу вже то видаляю.

Колись працював на одному німецькому банку. Тоді була проблема, що пару тижнів не проходили рекуринг платежі, тому мені доручили найти людей які мали в цей період заплановані платежі і провести їх (написати скрипт) і це було терміново, бо може хтось пропустив якийсь важливий платіж. Це була п’ятниця :) Зробив я цей скрипт, скинув тім лідці своїй, вона каже все гуд рань на проді. Я кажу ну це вечір п’ятниці, а мені ще за годину на поїзд йти, може в понеділок зранку, ще раз все переглянемо. Ні-ні, це дуже критично, давай. Ну відчуваючи, що там точно щось не так (бо це вечір п’ятниці) я то заранив і пішов на поїзд. В понеділок на моє здивування все було ок. Пройшло декілька тижнів, і появилась проблема, що в деяких людей рекуринг платіж в одному місяці пройшов двічі :) Виявилось, що мій скрипт не враховував вихідні і свята :) Але там не дуже багато людей заафектилось, бо в більшості не було грошей достатньо на рахунку, вони їм ті гроші повернули і сказали бути обережнішим мені на другий раз.

Ще якось вже на іншому проекті писали код, аби відправляти СМС нагадування про візит до лікаря. Ми той код написали, поставили під фіча тогл і забули за нього на рік. Потім прийшлось включити його, перед тим QA щось тестували, крутили, там насправді була трохи склада логіка відсилань тих нотіфікейшенів і була проблема, що для цього треба мати номер у США і ці номери важко діставались. Ну ніби все ок, включили і побачили, що всі СМС на один номер ідуть, виключили. Виявилось, що клас, який відсилав СМС спочатку відсилав це для одного номера, а потім його переробили, що він перебирав всіх кому треба відіслати, але мемоїзація в методі який витягував номер телефону залишилась, тому перший номер у списку кешувався і його всі смс йшли.

Вирішив не працювати багато у той день. Змінив одну цифру в коді, коміт, пуш, прод. Наступний ранок дзвінок від боса — компанія втратила $120К

Уявляю собі що б було якби вирішив працювати більше ;\

Пульнув в PlayMarket/AppStore білд зібраний без префіксу «--prod», в результаті апка стартувала дуже довго (20 секунд десь) та мала непотрібний код (дебаг і т.п).
Юзайте CI/CD, хоча б локальний (Fastlane і т.п)

Це ще й ризик що хакери розколупають аппку і вкрадуть все — бо дебаг білд це майже як сорси.

Трохи класики:
При виконанні DELETE запиту в SQL додав, але забув виділити WHERE і натиснув F5 🤪

У всіх таке було, слава Rollback;

Взявся за проект який не знав наполовину як робити, дедлайн було провалено звичайно, але хард-скіл тоді за кілька місяців підріс як за рік

Років 13-15 тому, дропнув данні с проду.
Зробив копіювання данних с prod бази на dev через sql script і додав delete не для того сорсу, люди вийшли на обід, а зайти вже не змогли, бо їх не було в системі.
Добре що було 300 чоловік і данні можна було скопіювати с dev.
Замовник був технарь і мене не звільнили :))))

Деякі з моїх наймів були тими фейлами, яких би я хотів уникнути. Але досвід є досвід, вже не переграти.

Ну коротше я NDA, а прикиньте, в них NDA, я кажу, може давайте NDA, а вони нє, тільки по суботах і краще NDA

Коментар порушує правила спільноти і видалений модераторами.

Перед міграцією БД зробив бекап у папку з налаштованим клінапом. Через 5 днів бекап видалився, а через тиждень знадобився (та було пізно)

Запускав скрипт синхронізації працівників. І замість стейджа запустив на проді. Сам скрипт нічого поганого не робив, але в іншому мікросервісі на проді був шматок коду з багом і для всіх працівників поле active в базі стало false. Проблема в тому, що воно йшло через rabbitMQ.і за хвилину десь 250 івентів оброблялось (а черга була одна і чистити її не можна було), то приходилось кожну хвилину запускати кверю update employee SET active = true.
Ну і за законом Мерфі — запустив команду і пішов на обід, прийшлось швидко вертатись з обіду.

Потім прийшлось ще раз сінкати дані, щоб звільнені працівники знову стали неактивними.

Колись давно запустив fdisk не на тому диску де потрібно було. Запустив NDD з завантажувальної дискети і все відновив за декілька годин. І теперь саме страшне — інтернету і StackOverflow ще не було.

fdisk

аж пустив сльозу ностальгії. Це були часи, коли для того, щоби встановити Windows 98SE спершу треба було розбити диск на розділи із загрузочної дискети (яку треба було мати з MS-DOS 6.22 і потрібними утилітами типу згаданого fdisk і для зручності ще можна було на дискеті тримати NC/VC, кому який подобався більше), а штатний установщик вінди ще не мав такого функціоналу.

NDD

— це Norton Disk Diagnostic чи Doctor здається

Norton Disk Doctor, мене врятувало те, що до цього вже мав досвід відновлення даних з дисків. Тож більше часу займало сканування диску в пошуку необхідних сигнатур розділів.

Я на першій роботі запустив DOS оптимізатор диску з під Windows 3.11, а вінда ж попереджала, що може бути боляче... Базу Clipper бухгалтерії збирали по шматках...

Поклав production в ніч з пʼятниці на суботу. Через багу апі слало в базу ‘select * from users’ і падало по ООМ, бо поверталось багато даних. Сервер сам оживав, але через хвилину запит повторювався і знову «вбивав» його. Ранок суботи був веселий 🤩

Для таких випадків існує спеціальний сайт: isitreadonlyfriday.com

Не моє особисте, але свіже.
На цьому тижні мігрували з AWS серверів на своє залізо в ніч з понеділка на вівторок. У вівторок-середу мали купу проблем на проді. В четвер зранку виявилось, що кілька адмінів звільнені через це за прискореною процедурою: в середу ввечері я ще спілкувалась з людиною, в четвер зранку дізнаюсь, що він в компанії вже не працює(

это не факапы, это сокращение расходов ))

А що саме вони зробили не так?

Там, мабуть, багато чого було не так. Фішка в тому, що до цієї міграції було дві репетиції. На останній репетиції все було ок, а от на основній міграції щось пішло не так. Крім того, через день вилізла глобальна проблема з айпі для load balancers та інших компонентів інфраструктури. Було схоже на те, що хтось щось змінив в конфігурації, але не хотів зізнаватись.

Будь які зміни до конфігураціх мають іти через сорс контрол. Інакше вічний бардак, і ніхто нічого не зізнається.

Намагаєтеся зʼясувати, хто двічи поклав моно?

для усіх сумнівних `delete` є `begin;` та ро доступ до проду, дуже дуже багато, але я намагаюсь ремонтувати що є, та більш помилок не повторювати, вчитися як краще, як робити надіїни системи які не крихки та не потребують бебисіттінга, в цьому мені подобається философія Ерланг

а, нещодавно було, треба було дані вичіщати, там був запит на вході складний, та крони накладалісь друг на дружку, коли накладалісь, локали один одного, видалення не було зайви дані накопичувались

ще була цікава бага, глобальний хттп конекшн пул забівался, конекшени не релізілісь в одному місті, тому все зовнішні коли вмирали через деякій час, треба було рестартувати, це складно було локалізувати та пофіксіти

ще пам ятаю пару років тому, мені здавалось що це норм ідея поллінг з фронта зробити, а на беке складний ще запит був та без кешу, воно трохі поклало базу, бо вкладок багато, люди іх не закривают

Зайшла на сервак по ssh і звідти випадково відключила мережу (eth0 якщо правильно пам‘ятаю). Як потім на серваку, який не в мережі, включити все обратно — задача з зірочкою 😂

Да яка там зірочка, неуважний адмін просто частіше їздить на маршрутці. Уважний адмін залишає крон з ролбеком файрвола/етс

Уважний адмін

Скорiше досвiчений)

Найбільші фейли були повʼязани з тим, що не відстоював свою позицію викинути код попередників та написати з нуля, врешті решт воно все одно переписувалось, але ресурсів було витрачено значно більше

Що як у бізнеса нема ресурсів (грошей, часу) щоб прям зараз все переписати? Я статтю писала, вибачаюсь за російську dou.ua/...​ta/articles/rewrite-code

Переписати це класно. Але чи не забуваєте ви про ціну цього, та ризики?

має сенс спілкуватись тільки на конкретних кейсах, які під нда, тому відповім просто:
ні, не забуваю

-

На колі з кастомером домовились дропнути тестові дані — даних виявилось забагато і сервер пішов в рекавірі мод ( ніхто не підказав про транкейт) — біля 20хв прод був офлайн.

цікаво що тестовий прод та не тестовий на одном залізе

Така організація процесу — на прод енвайроменті є можливість тестувати функціонал окремо від робочого, щоб його не імпактити

ну, так в вас же імпакт случился :)

тому що є залежности там, де іх не мало б бути

У рамках одного патчу оновив купу outdated dependencies, у тому числі OkHttp.

Патчноти за 3+ роки, для десятків ліб детально вичитувати не хотілось.

Коли зробив усі необхідні міграції і швиденько пройшовся мануальним тестом по апці — не довго думаючи змержив MR.

Через неділю, після чергового релізу отримав чудовий результат — 100% крашів у юзерів на 4му Андроїді, станом на 2021 для тієї апки то було декілька сотень юзерів.

Виявлялось що новий OkHttp вимагає minsdk на рівні 5го Андроїду, тим часом у апці ми ще мали підтримку 4-го.

Колись був зайчиком
Через свою ж дурість один call повністью наклався на інший...
Довелось одразу — дивитись в обидва монітори, слухати двух людей, раз на 5хв давати відповідь >_<

Ще на 20к долл замовили не той сервер через поганий evaluation який я не доробив, потім замовили вірний і він коштував вже 30к O_o

Один раз за 10хв перед демо випадково вимкнув прод, замість демо-машини, добре що прод був налаштован та швидко вмикався з усіма апками

Залишив десь 10000 абонентiв без iнтернета на вихiднi зробивши shutdown не в тому термiналi. Тех.пiдтримка(я) по вихiдних не працювала.

Сподіваюсь хоча б хтось подякував за цифровий детокс)

Нажаль нi.
В понедiлок зранку телефони розривались, шеф видав премiальних пизд$лин, але не звiльнив :)

Проапдейтив тему у WordPress сайтi, де були стилi змiненi руками у самiй темi

Замість перевіреного twillio, або AWS SNS, обрав дешевшого смс провайдера, не перевіривши підтримку rate-limit-ів в них. На бекенді поставив лише обмеження 1 смс за 30сек з 1 номеру без обмежень по країнам.
В результаті, отримав спам на нігерійську базу телефонів, яка коштувала рахунком за смс 14тис евро за 2 дні.

колись давно тестив кюар коди в рамках нової фічі.
коди генерились стороннім сервісом, а миїх просто юзали.
той сервіс незручно і криво працював, тому я якось нагенерив собі пачку кюар кодів і потім юзав їх довго. так само довго не міг зрозуміти, чому фейлиться (кюар код був обмеженим по часу)

Джуном отримав доступ до прод БД. Виконав запит на апдейт цін, забувши додати умови по категорії у WHERE. Звісно, ніяких лімітів та бекапів. Замість трьох десятків, ціни змінилися на більше ніж тисячі товарах. Вже не пам’ятаю чому, але просто виконати запит, який би зробив зворотну дію, можливості не було. Нащастя, клієнт мав відносно свіжий бекап,який швидко накатили.

У колеги була схожа ситуація, виконав помилково DELETE без WHERE. На щастя даних було не багато і всі вони залишилися в результаті запиту SELECT * у вікні SQL Management Studio. Колега їх звідти скопіював і сгенерував INSERT команду )))

Цікаво, а є СКБД з командою типу «begin transaction ... max_changed_rows 100»?

ну тисяча не милион лол, хоча є і плюси, поки запит виконуєтся можна викупіти що херня

Наводив лад у серверній (підадмінював за сумісництвом) та випадково перерізав оптоволокно ) потім довго не розуміли що з інетом

Поклав мережу банкоматів Привату день на годинку

Створив конфлікт версій бд просто зайшовши глянути мапінг в еластіку з домашнього пк де версія −0.0.x через що ліг аплікейш на пів дня

Поклав на 40 хвилин залізничні каси львівської УЗ коли замість стейджинг серверу вимкнув прод і пішов на обід.

В мене друг праціював на київській УЗ, там «деплой» на прод був через ручне копіювання файлів з компа розробника.
Код зберігався не в гіт, а в rar-архівах 🤯

Ще пару років тому працював на дуже великому проекті, где оновлення відбувалось повністю у ручному режимі : скачати дистрибутив, зупинити всі служби, видалити стару версію — засетапиити нову, запустити служби. ще треба було зберігати окремо (на всяк випадок) купу конфігураційних файлів. Були випадки коли після скачування, департамент розробки ’втихоря підкидав’ нову версію, з якимось виправленнями ,без зміни версії. Завдяки таким маніпуляціям дуже часто було багато збоїв прода після оновлення

Заблокував на декілька годин вкрай важливий бізнес процесс величезної мережі супермаркетів (#1 по Україні) невірним рішенням коли був на посаді архітектора (щоб пояснити що та як треба порушити NDA, але це повірте епічна помилка).

Не ту водку купив...

Підписатись на коментарі