За останні кілька років я брав участь у не менше ніж 100 випусках нового коду у світ. Більшість разів усе було чотко, але реальність іноді дарувала нам сюрпризи, і зовсім не завжди вони були пов'язані із спеціально навченими індійськими спеціалістами баз і консолей.
Прошу до вашої уваги 3 випадки, що завжди спадають мені на думку при словах "Fucked up release".
Прошу до вашої уваги 3 випадки, що завжди спадають мені на думку при словах "Fucked up release".
1. Відмінність тестового середовища і продакшина
Все було ок. Реліз відбувся успішно о 16:00. Але після імплементації нової версії API для системи оплати, власне оплата перестала працювати!
Виявилося, що на тестовому середовищі оплатної системи один із обов'язкових параметрів не був обов'язковим, і не заповнювався. Програміст не включив цей параметр у запит, оскільки його не вимагали для завершення оплати на тестовому середовищі. Прийшлося виправляти все "на гарячу". Тестити API на продакшині опівночі - те ще задоволення.
Якщо я не помиляюся, той параметр таки був описаний у документації. Тобто, цій ситуації можна було запобігти, якби я відтестував API запити, прочитавши її.
З іншого боку, як той програміст дізнався про те, що запити приймаються і без одного з параметрів? Може він теж документацію не читав? Чи в ній була помилка...
Все було ок. Реліз відбувся успішно о 16:00. Але після імплементації нової версії API для системи оплати, власне оплата перестала працювати!
Виявилося, що на тестовому середовищі оплатної системи один із обов'язкових параметрів не був обов'язковим, і не заповнювався. Програміст не включив цей параметр у запит, оскільки його не вимагали для завершення оплати на тестовому середовищі. Прийшлося виправляти все "на гарячу". Тестити API на продакшині опівночі - те ще задоволення.
Якщо я не помиляюся, той параметр таки був описаний у документації. Тобто, цій ситуації можна було запобігти, якби я відтестував API запити, прочитавши її.
З іншого боку, як той програміст дізнався про те, що запити приймаються і без одного з параметрів? Може він теж документацію не читав? Чи в ній була помилка...
2. "Я лише переклад підправлю!"
За півгодини до викочування коду на прод програміст спитав у нас (вся команда, включаючи ПО, сиділа в одній кімнаті), чи можна домержити його коміт в реліз - якусь дрібницю, переклад назви кнопки "Checkout". Усі погодились, бо кнопка таки важлива. І через 30 хвилин витріщалися то на білий екран продакшина, то один на одного.
Виявилося, що у цей останній коміт випадково потрапив не тільки переклад, а й кореневий JS файл із локальними налаштуваннями.
І поки це з'ясували, ми вже встигли відкотити базу після релізу.
Довелось збирати і викочувати реліз заново.
Реліз не любить поспіху.
За півгодини до викочування коду на прод програміст спитав у нас (вся команда, включаючи ПО, сиділа в одній кімнаті), чи можна домержити його коміт в реліз - якусь дрібницю, переклад назви кнопки "Checkout". Усі погодились, бо кнопка таки важлива. І через 30 хвилин витріщалися то на білий екран продакшина, то один на одного.
Виявилося, що у цей останній коміт випадково потрапив не тільки переклад, а й кореневий JS файл із локальними налаштуваннями.
І поки це з'ясували, ми вже встигли відкотити базу після релізу.
Довелось збирати і викочувати реліз заново.
Реліз не любить поспіху.
3. Додаткові сервери для збільшення пропускної потужності.
Ми збиралися запустити можливість користувачам одночасно бронювати та купляти сидячі квитки на різні події. У менеджменті дуже хвилювалися, тому доручили адмінам забезпечити безвідмовну роботу у піковий час. Ми потестили нашу систему, генеруючи задане навантаження, і лишились задоволеними. Але адмінам було конче потрібно щось зробити, щоб усі бачили їхню роботу. І замість того, щоб, наприклад, провести власні тести чи проаналізувати вузькі місця, вони вирішили просто подвоїти кількість серверів. І воно не мало нічого погіршити (крім, хіба що, процедур релізу, бо тепер викочувати треба було на 4 сервери, а не на 2), але подвоєння відбулося цікавим чином: обидва сервери (master + slave) були просто скопійовані. І вийшло, що ми маємо 2 master-сервери, що раз на кілька хвилин виконували заплановані задачі з очищення невикуплених бронювань. Одночасно. На одних і тих самих даних! Найпідступніше у цьому було те, що результати тестування треба було знову перевіряти через 30-40 хвилин. Бо крон є крон.
Ми, нащастя, швидко здогадалися, в чому проблема, і попросили вимкнути cron job'и на нових серверах.
Але адміни були дуже старанні, і наступний крок був не менш "елеґантним". Щоб було, чим відзвітувати про проведену роботу, вони виключили нові сервери на load balancer'і :)
Ми збиралися запустити можливість користувачам одночасно бронювати та купляти сидячі квитки на різні події. У менеджменті дуже хвилювалися, тому доручили адмінам забезпечити безвідмовну роботу у піковий час. Ми потестили нашу систему, генеруючи задане навантаження, і лишились задоволеними. Але адмінам було конче потрібно щось зробити, щоб усі бачили їхню роботу. І замість того, щоб, наприклад, провести власні тести чи проаналізувати вузькі місця, вони вирішили просто подвоїти кількість серверів. І воно не мало нічого погіршити (крім, хіба що, процедур релізу, бо тепер викочувати треба було на 4 сервери, а не на 2), але подвоєння відбулося цікавим чином: обидва сервери (master + slave) були просто скопійовані. І вийшло, що ми маємо 2 master-сервери, що раз на кілька хвилин виконували заплановані задачі з очищення невикуплених бронювань. Одночасно. На одних і тих самих даних! Найпідступніше у цьому було те, що результати тестування треба було знову перевіряти через 30-40 хвилин. Бо крон є крон.
Ми, нащастя, швидко здогадалися, в чому проблема, і попросили вимкнути cron job'и на нових серверах.
Але адміни були дуже старанні, і наступний крок був не менш "елеґантним". Щоб було, чим відзвітувати про проведену роботу, вони виключили нові сервери на load balancer'і :)
Якщо маєте свої релізні анекдоти - діліться :)
Немає коментарів:
Дописати коментар