Страшные истории от украинских IT-шников: о багах, дедлайнах и факапах
Хэллоуин — это не только корпоративы с тыквами и гримом, а и время для страшных историй. Предупреждаем: джуниорам и слабонервным специалистам лучше не читать!
Итак, в одном черном-черном городе, на одной черной-черной улице, в одном душном-тесном черном-черном опенспейсе...
Александр Марголин, Developer в Evergreen
Чего я боялся в своей работе, когда был Junior-ом? Прод положить, как и все :)
Есть у нас один проект крупной компании с большим трафиком. Не знаю, почему так сложилось, но его частенько дают джунам, которые только пришли в компанию. Не миновала и меня эта доля. Естественно, таски там не сложные, но...
Помню, пришёл на меня таск с мелкой ошибкой на сайте. Актуального разработчика под этот проект не было, и ошибка возникала только на проде. Что ж, я по долгу своей юности и запала полез дебажить прямо на проде. Модуль, который я дебажил, был сквозной и отображался на всём сайте, так что я решил выводить дебаг комментариями прямо в коде (типа, непалевно). Никто в компании, естественно, не знает о моём лихачестве.
Проходит 40 минут моих изнурительных поисков песчинки в груде кода, и вдруг... загорается
Так, на пару минут сайт приболел, а я получил здоровенную дозу адреналина и отличный урок. Но никто ничего не выкупил, и больше я так не косячил. В общем, «шалость удалась»!
P. S. А ещё я кофемашину боялся поломать :)
Николай Живац, QA Team Lead в HYS Enterprise
Было это в прошлом году. Под радостный перезвон Skype я увидел на экране имя заказчика... Где-то в ветвях надо мной каркнула ворона, а в чаще — завыли волки. После робкого «Хэллоу, хау ар ю?» я был весьма категорично озадачен: «В спринте сейчас тридцать тикетов — их надо закрыть до праздников. Ю кэн ду ит, гайз, ю ар грэйт!». Надеясь, что ослышался, я глянул на календарь: 29 декабря. Пятница. 9:25 утра.
Ворона в ветвях каркнула снова.
Трясущимися руками я набираю номер напарника и слышу: «Я заболел, беру сегодня выходной».
Ворона в ветвях ехидно захохотала.
Клиенты уже ушли на каникулы, почти весь состав девелоперов на их стороне. Единственный работающий разработчик, в ответ на мои слёзы, тоже попытался заболеть, но спасать нас было больше некому. И понеслось.
Jenkins из continuous integration превратился в everlasting integration. Баги и таски проверялись и переоткрывались, новые версии билдились примерно раз в двадцать минут. Как и положено, нашлось ещё с пяток багов, о которых пришлось доложить, потом чинить, проверять, мерджить, билдить, проверять, перепроверять, крыть матом, переоткрывать.
К девяти вечера, когда жена уже даже не спрашивала «когда?», а нежно интересовалась буду ли я дома вообще, в спринте оставалось четыре тикета. Волевым решением они были переведены в статус «blocked in testing» и подарены болеющему напарнику.
Ворона, кстати, охрипла от ехидного карканья.
Антон Пархоменко, Product Designer в Daxx
На самом деле страшных историй, леденящих душу ужасом, таких, чтобы аж ухх, я считаю, в аутсорсе не бывает. За тебя отдувается компания, и худшее, что может случиться, — тебя уволят. Другое дело — фриланс, там весь экшн, причем в любых жанрах.
Дело было в
Проходит месяц, мне звонит клиент и жалуется. По-своему, как это было принято в его молодости в
Узнаю у ребят, как дела. Говорят: «Есть немного багов, но сайт почти готов». Показывают мне код, волосы встают дыбом. Они построили сайт с кастомными полями, которые были сгенерированы плагином, пообещав многоязычность. А это еще один плагин, который, конечно же, не знает о существовании первого, и естественно, не работает. Половина текстов захардкожено внутри шаблона, там же картинки с абсолютными путями в файлах темы, плюс все остальные баги. Ну и, естественно, никакого контроля версий, заливается все ручками по FTP.
В итоге убедительная просьба клиента сработала, сайт мы в понедельник сдали, но с такой скоростью я еще никогда не работал. Клиент остался доволен, но за код стыдно до сих пор.
Константин Кичеглов, Back-end разработчик в KeepSolid
Back-end в компании — это одна из самых важных и критичных артерий по доставке конечного продукта пользователю. Именно поэтому тут самые высокие риски и, конечно же, страхи. Прием платежей, email-рассылки, нотификации, конфиги клиентских приложений — все это заставляет просыпаться среди ночи в холодном поту с мыслями о багах и их будущих фиксах.
Конечно, у страха есть и положительная сторона: начинаешь делать все, чтобы испытывать его как можно реже. Автотесты, версионирование, CI/CD, документация проектов — залог крепкого сна.
Расскажу историю суровых будней о массовой рассылке писем пользователям по подписке. Специализированная тематическая рассылка должна была отправиться определенной группе пользователей в определенное время. И вот, в момент проверки и подготовки этого процесса рассылка была запущена легким движением руки всей базе пользователей раньше, чем нужно. Сервис, созданный «попередниками», мягко говоря не предусматривал аварийную остановку рассылки, документация отсутствовала. Очередь писем наполнили — и на отправку.
Долго пытались найти, как остановить рассылку, вырывая волосы на груди. С тех пор сервис отправки писем был приведен в должное состояние и слегка сменил свою реализацию, но страх работы с ним все равно остался, где-то на уровне рефлексов.
Алена Дрозд, QA Engineer в B2B Soft
Чего боится обычный тестировщик в своей профессиональной жизни? Что закончится кофе на кухне, в офисе появится человек-заглядывальщик в чужие мониторы и докладывальщик всего этого безобразия начальству или что в Украине заблокируют YouTube. А если серьёзно, то очень боюсь попасть в команду, где у людей нет чувства юмора. Казалось бы, ну и что тут такого? Но в этом дедлайновом мире, где количество напряжения накапливается быстрее, чем люди на станции метро «Золотые ворота» в 9 утра, смех просто необходим. А кислые лица, поговаривают, полезны только при закваске капусты на зиму.
Боюсь стать невостребованной как специалист. Всё вокруг слишком быстро движется. Отвлечёшься на что-то другое — и всё: нужно догонять, учиться и развиваться вдвойне быстрее. А вокруг столько всего интересного!
Некоторое время назад моим самым большим страхом было проведение демо на английском языке. Говорить я, в общем, люблю. С английском у меня не всё так плохо. Но во время каждого демо у меня случались паника и «Хочу шоколадку и под пледик, а не вот это вот всё». Но тут спас тот же юмор: пара уместных шуток, и ты начинаешь понимать, что на той стороне сидят и слушают такие же обычные люди со своими слабостями и недостатками.
Ну и ещё один секретный (но уже не очень) страх — выгореть профессионально и потерять тот драйв и вдохновение, которые заставляют просыпаться утром и идти на работу. В моей жизни было такое однажды. Решила, что работать 8 часов день — для слабаков, как и хороший сон. В тот период я на митингах очень часто засыпала, пока однажды не проснулась с табличкой «Работник года» в руках.
Наверное, у каждого есть такая история. Жаль, что жизненному балансу не учат в школе (а это, кстати, хороший вброс для министерства образования). Или нужен пропеллер, как у Карлсона, который можно завести и получить порцию энергии, креативных идей и варенья.
Михайло Себало, Ruby on Rails Engineer в JetThoughts
Врятувати рядового «Відпустка»
У розробці, як і в будь-якій іншій роботі, курйозні ситуації трапляються постійно: від непорозумінь із великими і страшними клієнтами до грандіозних поломок у святому продакшені, від чого страждають наші милі користувачі.
Та мені великою мірою псує настрій і холодить кров перспектива зіпсованої відпустки. Я, і, напевно, ще багато хто, заздалегідь планує свій відпочинок і вже ж точно не планує в цей час доводити хвости і закривати спринт. Або, боронь Боже, ліпити хотфікси! Та життя бентежне...
Одного разу ми з невеликою командою завершували розробку продукту. І так склалося, що його випуск тісно збігався з моїми планами піти у відпустку. У результаті на одну прекрасну п’ятницю було призначено реліз, а мій літак був у неділю.
Проблем додавало те, що у нас була тісна інтеграція зі стороннім API, яке грало ключову роль у продукті. Проте це API видавало тестові/безтолкові дані протягом усього циклу розробки та ще й ломалось кожні два дні (як по годиннику). Його мав налаштувати розробник зі сторони API, але з ним було важко вийти на контакт і ще важче добитись результатів. Та не можна було підводити клієнта і залишати команду з головним болем!
Усе закінчилось тим, що в п’ятницю ми випустили продукт, який мав захисні механізми на випадок проблем з API. Усю суботу і частково неділю я провів у переписках з клієнтом та розробником API. І в понеділок, на щастя, все уже запрацювало без мене і команда впевнилась, що сайт почав працювати з першими користувачами.
Роман Киригетов, сооснователь и руководитель Kabanchik.ua
Это история о том, как мы два месяца теряли клиентов из-за мелкого бага. Который не нашли сразу, потому что думали «дело в пользователях, а не в нас».
Сперва небольшая предыстория: в 2015 году мы работали над «Кабанчиком» вдвоем с Сашей Юрьевым. Сайт выглядел иначе, чем сейчас. Чтобы быть одновременно и мастером, и заказчиком, пользователю приходилось регистрироваться дважды.
Как-то после очередного обновления в саппорт посыпались обращения: «Хочу заказать услугу, но не могу найти кнопку «Создать задание». Это писали люди, которые просто пришли найти помощника, но случайно зарегистрировались как исполнители. Мы первым делом подумали, что они, скорее всего, путают кнопки регистрации. Решили быстро им помочь.
Первое время вручную переделывали «проблемные» профили. Параллельно колдовали над UX-ом сайта, перекрашивали кнопки, чтобы они стали заметнее, добавляли подсказки. Потом переписывали эти подсказки несколько раз. Что-то меняли, тестили, получали фидбэк, и снова переделывали. Прошло два месяца, а проблема осталась.
Решили копнуть глубже: просмотрели с помощью Вебвизора путь пользователя, который обратился с этой проблемой. И ужаснулись, как все оказалось просто.
У нас была громадная форма регистрации для заказчиков. В ней просили написать имя, фамилию, отчество, пол, количество детей и другую ненужную информацию. И если человек не заполнял хоть одно из этих полей, он автоматически регистрировался как исполнитель.
Мы, когда проверяли все ли в порядке на этом этапе, конечно же, заполняли все поля. И сайт работал как надо. Остается только догадываться, сколько седых волос нам это добавило и сколько клиентов мы потеряли.
Антон Маруха, Business Development Manager в Sigma Software
История произошла два года назад. Мне пришла ответственная задача от руководителей компании выслать на ревью предложение для одного из наших ключевых заказчиков. Максимум к 9 утра следующего дня письмо должно было быть в почте у директоров.
На тот момент я совмещал должности Senior Project Manager и Account Manager, в подчинении было 80+ человек, работы всегда было много. Перед этим у меня выдалось несколько очень напряженных недель с командировками за границу, стартом новых проектов, сложными переговорами и поздними ужинами с заказчиками. Так что на момент начала работы над задачей я был уже уставшим. В то же время нужно отметить, что мой рост в компании происходил довольно быстро, что было сопряжено с повышенной загрузкой, так что к напряженному графику я привык.
В результате незапланированных отвлечений, к вечеру накануне дедлайна задача была еще не полностью готова. Времени на выполнение оставалось немного, но я решил, что справлюсь вовремя — концепт предложения у меня уже был готов. В тот вечер мне нужно было уйти из офиса около
Проснулся я в 8 утра следующего дня, проспав около 10 часов из-за накопленной усталости. Осознав, что мало того, что задача недоделана, так я еще и не предупредил о возможной задержке, я поспешил проверить почту, где нашел сообщение от руководителя о том, что она очень ждет письмо.
Я предупредил, что могу опоздать с дедлайном на час, быстро закончил и отослал предложение. Задача была сделана, но результат был смазанным из-за задержки и поздней нотификации о ней, а такие ситуации никто не любит, тем более топ-менеджмент.
Lessons learned:
- Еще раз убедился, что если ваш план предполагает работу в овертайм изначально, то он с большой вероятностью уже нерелевантен.
- После
30-ти организму все же сложнее справляться с нагрузками, чем в 22, и с этим надо считаться. Не стоит рассчитывать на спортивность и выносливость. Считайте всегда, что у вас есть максимум 8 рабочих часов в сутках. - Делегируйте все, что можете, чтобы освобождать себя от отвлечений и фокусироваться на приоритетных задачах.
- Когда вы занимаетесь критической задачей с близким дедлайном — не отвлекайтесь. Я даже иногда выключаю мессенджеры и перестаю читать почту, иногда не беру трубку, unless absolutely required.
- Если есть возможность, то лучше закончить задачу утром на свежую голову, чем поздно вечером в уставшем и сонном состоянии.
Дарья Бирюкова, Senior QA Engineer в DataArt
По закону Мерфи, худшее, что может случиться, обязательно случится. C QA. Особенно если спешить и бояться налажать, к чему часто склонна команда, накрученная обстоятельствами или заказчиком. Тем более, в интенсивный период проекта.
Причин может быть много, схема может варьироваться. Например, в определенный момент винт вентилятора, на который потихоньку набрасывали, просто срывает. Все разлетается ой как далеко и оставляет следы, оттирать которые придется долго. Бывает и иначе: ничто не предвещало беды, шло гладко и в срок, релиз выкатился, домой все ушли вовремя, но внезапно спустя час или два появляется откуда-то из недр такое багло, что невольно задаешься вопросом: «А не выйти ли нам всем коллективом в окно?».
Однажды в масштабном проекте готовился большой релиз, к которому в последний день безотлагательно решили внести одно ма-а-аленькое дополнение (уже чувствуете, как нагревается паяльник, да?). Риски учтены, команда на коне, всё доделано, релиз стартовал, код где надо, все ушли домой. Как сейчас помню, был четверг. А за ним наступила черная пятница — утром весь релиз пришлось откатывать из-за достаточно очевидного и очень неприятного бага, который проскочил мимо всех возможных глаз. СТО после конца рабочего дня один за другим начали поступать звонки от разъяренных клиентов. Дело кончилось тем, что он, поддавшись их настроениям, продемонстрировал команде Майкла Майерса в лучшие годы.
Прошло уже несколько лет, участники действа живы и здоровы, но нежелание попасть в подобную ситуацию всё еще вызывает электрические импульсы в мозгу каждый раз, когда начинается спешка. Именно поэтому конец этой истории можно назвать счастливым, ведь теперь каждый из выживших обладает этим мегаполезным анти-rush-детектором.
Вывод: да, всё плохое обязательно случается, но выходить в окно не стоит, бояться тоже. Если чувствуем, что опасно ускоряемся — останавливаемся и пробуем посмотреть на проект под другим углом. Не успели — слушаем песню Синатры «That’s life» и делаем выводы. Без эмоций, без обвинений, настолько конструктивно, насколько это возможно. И никогда не падаем духом, ведь монстры это чуют!
