Я люблю критику. Если вы не заметили, я, как старый дед, всё поливаю грязью и всем недоволен.
Забавно, но в то же время я люблю, когда критикуют меня самого, потому что именно в такие моменты я что-то начинаю понимать, развиваюсь и становлюсь лучше. А в этой статье я решил совместить приятное с забавным и рассказать вам о своих самых идиотских решениях и самых эпичных провалах за свою карьеру программиста - такая вот само-критика. Возможно, кто-то узнает себя, а если нет, то я просто прошу вас: не делайте так же, как делал я.
Sshuttle
Через ssh соединение можно туннелировать траффик - т.н. SSH jump host. Обычно это используют для безопасности - ну, например, подсоединиться к доверенному серверу, а от него уже заходить на целевой сервер.
У нас на работе как раз есть такой сервер за $5, чтобы просто от него прыгать куда надо к особо параноидальным клиентам. А ещё я живу в России, и у нас тут блокируют интернет, иногда по типу "а забаним-ка мы подсетку". Поэтому иногда сайт клиента не работает не из-за моих кривых рук, а из-за рук (или что у них там) Роскомнадзора. VPN мне было лень покупать, и, использовав весь интеллект, дарованный мне природой, я додумался: а почему бы не гнать http трафик через прыжковый сервер компании? Всё равно ж для клиентских сайтов использую.
Я скачал sshuttle - он позволяет в одну команду создавать SSH туннели. И это работало - я создавал туннель, проверял, что заблокированные ресурсы открывались в браузере, и закрывал его.
Работало, пока однажды я не забыл его закрыть.
В тот вечер я поработал, всё закрыл (хе-хе, ну почти), посидел в Ютубе, поставил что-то качаться через торренты и пошёл спать.
На следующее утро я открываю слак, а там огромный тред. Читаю его, как хронологию.
Вчера вечером через SSH доверенного сервера, который используется для безопасного доступа, пошло много траффика.
Это привело к всплеску активности CPU.
Мониторинг хостера офигел и отправил email уведомление нашему CEO.
Тот устроил опрос, кто сейчас пользуется сервером, никто не в курсе (я в оффлайн) - решили, что сервер взломали.
Удалили сервер к хренам, создали новый с более жёсткими правилами доступа.
Все поменяли свои конфиги.
И тут у меня возникла дилемма: можно было не говорить, что это был я. Старый сервер удалён, так что вроде никто не знает, кто это. Это был не первый фейл в этой компании, а нахождение в компании как правило имеет корреляцию с количеством косяков, так что соблазн промолчать был. С другой стороны, нужно брать на себя ответственность за свои косяки, даже если это больно.
Короче, с тяжёлой душой и паршивыми ожиданиями я написал СЕО, что это я тот самый дебил и осознаю это, давай посчитаем, сколько каждый потратил своего времени в денежном эквиваленте, и я это компенсирую. На что он мне сказал: знаешь, я давно хотел удалить к чёрту тот сервер и перенастроить всё нормально, так что спасибо, что предоставил повод.
Кто бы, блин, мог подумать.
Обновляю sentry
Это был вечер.
На каком-то внутреннем проекте случилась ошибка. Обычно у нас прилетает ошибка в sentry - это сервис для логгирования ошибок и сопутствующей отладочной информации. Но в этот раз ошибка не прилетела.
Я зашёл на сервер и убедился, что ошибки не отправляются. Сервер был довольно старый, там был старый код и какая-то 0.x версия sentry-sdk для питона, в то время как актуальная версия уже была что-то вроде 14.x или типа того. Ну вы понимаете масштаб отставания.
Первая мысль была "они дропнули поддержку старых версий, нужно попробовать обновить библиотеку". Ну я открываю терминал, вбиваю pip install --upgrade sentry и жду в надежде, что оно обновится, всё заработает, и я пойду отдыхать. Изи фикс.
Оно что-то скачивает, скачивает, потом начинает что-то компилировать rust'ом... Тут я уже прифигел: это же, блин, библиотека для обработки ошибок, хрен ли там нужна компиляция! Совсем тупые разрабы пошли, нихрена не могут такую простую штуку сделать нормально. Я прерываю процесс при помощи Ctrl+C и в сердцах решаю отложить это на завтра.
На следующий день я, по классике, читаю хронологию событий в слаке.
Короче, sentry-sdk - это библиотека для обработки ошибок в питоне. А sentry - это вообще весь сервис для обработки ошибок, если вы хотите хостить его на своём сервере. Я по ошибке начал ставить последний. Ctrl+C ничего не завершил (хотя визуально казалось, что да), потому что основной процесс успел создать другие процессы, которым сигнал не передался, ха-ха. Началась какая-то адская компиляция на слабой машине с 1 ядром. DigitalOcean продолбал мониторинг и не послал алерт по почте. Всю ночь сервер натужно пытался скомпилировать что-то, обогревал датацентр, но задачу не вывез. Наутро это заметили и с трудом остановили процессы. С трудом - потому что когда убивали одних, порождались другие.
Вот так я победил ещё один внутренний сервер. Изи.
Celery
У нас был скрейпинг. Т.к. у нас синхронная ORM (спасибо, Джанго), мы просто создавали на 8-ядерной машине кучу celery-воркеров (штук 100, потом больше), и они всё параллельно скрапили.
Ну, должны были. Когда их было мало, штук 10 - всё работало быстро. Когда штук 50 - всё тормозило. И я никак не мог отловить, в какой момент оно тормозит. Когда у вас один процесс, то там понятно - замерь время тут, замерь время там, и так как всё линейно, легко понять, какой кусок кода какое время занимает. Когда у вас одновременно 50 процессов, то отладка малость усложняется - может, оно тормозит, а может, оно в IOWAIT. И надо было именно на 50 процессах замерять, потому что иначе тормоза не воспроизводились.
Ну я и замерил. Http запросы через прокси были медленные. Я начал отлаживать прокси, потому что, походу, они не вывозили тру многопоточность - и это ожидаемо, ведь они стоили $25 за 1000 штук. Я попробовал, наверно, всё, что ваше воображение может выдать по запросу "тестировать прокси", даже пробовал создать другой аккаунт с другими проксями и другим планом. Я всё хотел подловить провайдера, что он не может выдержать нашу нагрузку.
Конечно, как и во всех историях в этой статье, идиотом оказался я, но в этот раз я даже превзошёл сам себя: когда мы это обсуждали с СЕО в самом начале, он сказал, в том числе, проверить настройки celery и попробовать ими поиграться, но я был так увлечён тестированием прокси и был на 100% уверен, что ошибка где-то в них, что не обращал внимания на другие возможные варианты.
Дело решилось настройками - точно уже не помню, то ли PREFETCH_MULTIPLIER, то ли BROKER_POOL_LIMIT - но потеряли мы на этом знатно времени, даже пришлось делать скидку заказчику за затягивание сроков. Уже потом, много месяцев спустя, я прочитал 50 оттенков celery и плакал горькими слезами, потому что я всё это уже знал, но по печальному опыту.
Освободил место
Я тогда думал, что индексы - это когда на почтовом конверте пишут 6 циферок. Про индексы в БД я не слышал, или особого значения не придавал. Да, именно настолько тупым я был.
У нас была табличка в базе для "логов" - туда записывался запрос от пользователя, дата, ответ нашего API и ещё какая-то метаинформация, чтобы мы потом могли оценить, насколько всё быстро и хорошо плохо и медленно работает.
А потом эти логи о том, как всё медленно и плохо работает, стали медленно и плохо работать, хех, потому что их стало много, а индекса не было. Этих логов было правда много, мы их тогда редко смотрели, ну я и дропнул их. Меньше данных - быстрее работает. Оно и правда стало быстрее.
На следующий день босс спросил: кстати, а где логи?
Оказывается, я переоценил ненужность логов, и босс имел на них виды. К счастью, я отделался только постоянными шутками типа "у нас есть мастер по логам" и "давай посмотрим это в логах".
Теперь я не удаляю вообще ничего.
MySQL utf8
Как-то я работал с базой и тут вдруг заметил, что кодировка у таблицы была utf8mb4. Опять эти джуны на проекте создали таблицу с какими-то дурацкими параметрами!
Я поменял кодировку на utf8.
Да, блин, оказывается, в MySQL utf8 - это какая-то проприетарная говнокодировка курильщика, которая с классическим utf8 имеет только общие буквы в названии. Так что если нужна utf8 - то нужно ставить utf8mb4, где аббревиатура "mb" означает "mysql bullshit" или что-то типа того.
Умный импорт
Как-то у нас был проект, где были "темпоральные объекты" - ну то есть у них была дата начала и конца. Мне нужно было написать систему импорта, и вроде бы было всё неплохо, кроме одной проблемы: временные промежутки объектов могли пересекаться, и в таком случае нужно было слить два объекта в один, с общим временем. Типа если Петя работал с 10 до 12 и с 11 до 15, то в базе должна быть одна строка со временем "с 10 до 15".
Это не так-то просто, ведь нужно запросить базу, найти пересечение временных промежутков (а могли быть промежутки типа "от сегодня и до бесконечности"). Но не на того напали, я ведь крутой программист, поэтому я написал классную логику, что когда объект сохранялся, всё просчитывалось и автоматически объединялось.
А потом я запустил импорт. Простенький файл импортировался 2 минуты, потому что каждый объект импортировался отдельно, при этом делая сверки с базой данных. До сих пор помню, как клиент ждал, пока это загрузится во время тестовой презентации. Мне стыдно.
Через год я уже знал про bulk_create, постобработку данных и даже про postgres COPY TO / COPY FROM, но время было упущено.
Machine learning
У нас было машинное обучение. Я в этом ничего не понимал (да и сейчас не особо), но по работе приходилось - была куча параметров, по которым нужно было выдать какое-то решение. Кожаный мешок не может охватить все варианты, а вот деревья решений - легко.
И вот я быстренько накидал скрипт для сбора данных, скормил всё модели, и начал её тюнить. Все знают, что самое интересное в машин лёнинге - это играться с методами обучения и их параметрами, фичами и их комбинациями, чтобы выжимать максимальную точность модели. Чем я и занимался.
А потом мы созвонились с боссом (который в ML разбирался намного лучше), я запустил screen share, и он попросил открыть данные для обучения, и мы стали просматривать их вручную. Святые угодники! Там было, наверно, всё: и те данные, которых там быть не должно, и отсутствие данных, которые ващет должны были быть, и неправильные значения... Так-то мои скрипты для генерации данных работали, и на ручных тестах всё было ок, но вот когда они были запущены на больших данных, всплыло много косяков, о которых я и не подозревал.
И вот мы подошли к главному правилу машинного обучения: если ваши данные для обучения - говно, то и вся ваша последующая работа - тоже говно. Именно это со мной и произошло. С тех пор я стал по-другому смотреть на все данные: я их проверяю. Вручную. Вот прям открываю, пробегаю глазами, беру несколько случайных значений и вручную для них считаю фичи или проверяю, что значения более-менее адекватны.
Недавно колесо судьбы сделало оборот, и уже я сам открывал чей-то файл для обучения и говорил: ваши данные говно, сударь, и значит, вся работа тоже. Такие дела.
Декремент значения
У меня был интернет-магазин без БД-транзакций. Конец шутки.
Но было там и кое-что похуже: количество товаров. Количество товаров - это, очевидно, какое-то число, и первая мысль - сделать это числом в базе данных. В те времена я дальше первой мысли, как правило, не заходил, поэтому я так и сделал: вот товар, у него есть int quantity - количество товаров. Пришёл товар - +1. Купили товар - -1. Like a pro!
Но потом наступил пушной зверёк с интересным названием "пересорт". Вкратце: количество товара в базе не совпадало с реальным количеством на складе. Почему? А хрен его знает, есть тыща причин для этого: менеджер ступил и не то значение поставил, или одновременно редактировали товар, или пользователь два раза кликнул, а у нас нет транзакций, да мало ли случаев! Но важнее всего одно: не было никакого способа понять, где и когда что-то пошло не так. Да, у меня было число товаров сейчас, так что я мог просуммировать товары с заказов и понять, что когда-то, на какую-то дату было, кажется, столько-то товаров, но из-за ошибок и эта информация могла быть неправдой. В общем, это полный провал. С такой архитектурой подсчёта товаров можно уничтожить любой магазин, так что берите на заметку.
Потом я плюнул и переписал это, заменив действие (декремент) на объект "перемещение товара" (т.е. строчка в БД). И всё вдруг стало прозрачно: +1 превратилось в перемещение товара от поставщика на склад, а -1 - перемещение со склада к покупателю, и всё это было с датой, временем и другой метаинформацией. Количество товара на складе теперь было не просто числом, а вычисляемым числом - посчитай, сколько пришло, вычти, сколько ушло, и вот тебе ответ. Который можно кэшировать, чтобы не считать каждый раз. Открылись и другие "фишки" - можно добавлять цену товара при поступлении и продаже и смотреть оборот, прикреплять статусы к перемещению товара ("запланировано" / "в процессе" / "завершено" / "хрен знает что происходит"), и всё в том же духе.
Но это была не единственная проблема в магазине, ведь я:
Попытался быть умней пользователей
"Пользователи бывают идиотами, - думал я, - и чтобы обезопасить приложение от их кривых рук, нужно написать валидаторы. Все данные будут строго по ГОСТу. Телефон пусть будет +7xxx-xxx-xx-xx, адрес - индекс, область, город, улица, дом, квартира."
Ну да, ну да. Дебил.
Телефон может быть в другой стране
Телефон может быть с добавочным номером
Человек может хотеть указать несколько телефонов
"Город" вообще-то может быть селом или деревней
У адреса может не быть улицы
А дом может быть корпусом
Иногда квартиры нет, т.к. частный дом
Или потому что это офис
...
И я осознал. Эта битва проиграна, и вы точно не умнее своих пользователей - по крайней мере в вопросах их персональных данных. Я удалил к чертям все валидаторы и позволил пользователям вводить именно то, что они хотят туда ввести. И они это делают. У нас заказывали иностранцы, люди из всяких отдалённых мест и по всяким странным адресам. Им виднее.
Иногда, чтобы победить - нужно отступить.
Задеплой это быстренько
Однажды мне написал босс и сказал, что у него через 30 минут разговор с клиентом и нужно добавить какой-то простой функционал в наш CLI, чтобы прям совсем красавчиками быть. Я добавил, запушил в репу. Уверен, вы знаете, что произошло.
Клиент был какой-то "околотехнический", то есть он мог что-то запустить, но только в режиме удалённого управления, типа "откройте окно, нажмите эти кнопочки, нажмите энтер, прочитайте код ошибки". У нас на то время была только CLI библиотека на питоне. Кое-как босс объяснил клиенту, как запустить консоль, как там поставить последнюю версию либы, и как её запустить со всеми флагами. Это заняло прилично времени. И конечно, в моём коммите был баг. Он сломал всё, вообще нифига не работало. Я пытался в реальном режиме пропатчить, но из-за стресса ничего не получилось. Боссу пришлось объяснять клиенту, как поставить работающую версию. Отличная презентация продукта, мать его!
Спустя полтора года, на другой работе, клиент очень просит нашу компанию выкатить срочный патч, потому что на следующий день пройдёт мероприятие, где этот патч понадобится. Но я уже наученный и знаю, как на это смотреть. Я представляю: вот если я сейчас что-то быстро накидаю и задеплою, есть 2 варианта. Первый - это что патч заработает. Нам скажут "спасибо", а я даже сверхурочные не получу. Второй вариант, более реальный - что всё сгорит нахрен и обвалится. Тогда меня ждут стресс, ужас восстановления проекта и недовольство клиента. То есть либо я не получу ничего, либо всё будет плохо. Отличный выбор! О чём я и сообщил нашему CEO - это не моя битва, иногда нужно позволить страдать кому-то другому. И знаете, клиент как-то выжил без патча!
Точка возврата
Есть такое выражение - "точка невозврата". В IT такое случается, например, когда ты долго что-то не обновлял, а потом настала пора и там изменилось вообще всё. Когда я пользовался убунтой, там каждая новая версия - это точка невозврата, потому что обновляется вся система, и назад уже никак не откатиться (или это сделать сложно). Точки невозврата, как вы уже, наверно, знаете по убунте или какой-нибудь macOS, довольно часто сопровождаются поломкой чего-нибудь. Именно поэтому я и перешёл на arch linux, кстати - там почти всегда можно вернуться. И я очень рекомендую при обнаружении точки невозврата создавать "точку возврата".
У меня был проект, где было легаси окружение, и мы его переводили на более современное. Грубо говоря, была одна структура проекта, стала другая, плюс обновились зависимости. Разумеется, я протестировал новую систему на локалхосте. Потом у нас был staging сервер, где я выкатил новую систему и удостоверился, что она работает. Осталось дело за малым: на проде обновить старую систему. Но это точка невозврата, потому что для отката пришлось бы даунгрейдить все зависимости, откатывать миграции и хз что ещё делать. Нереально.
Поэтому я плюнул и создал клон системы, и уже спокойно обновил его. Клон системы уже нельзя было откатить, но мне и не нужно было - у меня всегда оставался оригинал, так что я просто мог удалить клон и вернуться к старой системе.
Конечно, клон не заработал. Несмотря на все тесты, все проверки, всё равно он не завёлся. Да и хрен с ним! Я опять включил оригинальный сервис и, наверно, пол-дня попивал кофе, отлаживал и пытался понять, в чём дело - но это была отладка в спокойной обстановке, зная, что всё работает. Уже потом я обнаружил, что клон не отвечал на порту 80, а балансировщик нагрузки проверял как раз 80 порт и думал, что сервис мёртв. Я пофиксил это, остановил оригинал, включил клон, и оно заработало, а моя попа осталась цела.
Lint crap
Не знаю, как у вас, а я, когда говорю по-английски, не "перевожу" слова на русский, а как бы сразу "думаю по-английски". Соответственно, иногда я знаю слово на английском, но даже не знаю, как его перевести на русский. Это приводит к курьёзам, потому что у нас в команде периодически проскальзывало слово crap, и один раз даже кто-то назвал коммит "lint crap" - там были просто патчи, чтобы линтер на гитхабе не придирался к пробелам и запятым в коде. И я вроде как на интуитивном уровне понял, что crap - это как garbage, типа мусор какой-то. Ну и стал везде это слово говорить.
А потом я даже сделал коммит, который так и назвал - "lint crap" - в нашу официальную библиотеку. Разумеется, через какое-то время босс это увидел и попросил меня это удалить, а так это было через какое-то время, то там уже были коммиты сверху, и мне не хотелось возиться с историей гита. Я тянул сколько мог, каюсь, пока босс не забыл про это, так что оно там так и осталось - lint crap.
А не хотел я это удалять, потому что однажды закоммитил секретный ключ в репозиторий, и потом имел радость с BFG. Было здорово, но больше не надо.
Вы все делаете неправильно
Очень часто при поступлении на работу новые сотрудники обнаруживают, что рабочие процессы налажены не так, как они привыкли, и у них развивается синдром "вы тут всё делаете не так". Сейчас я уже не настолько эмоциональный и когда вижу какую-то дичь на новом проекте, просто говорю wtf и добавляю туда свой код, лишь изредка уведомляя клиента, если вижу прям совсем опасные вещи.
Но раньше было не так! Это была моя вторая работа во фрилансе, и я зашёл на проект, где фронт делали на стандартных шаблонах Джанго. Я уже писал про них, и если вкратце - они говно. Но никто, кроме меня, этого не знал, и я начал про это рассказывать и что-то доказывать. Я даже убедил всех, что jinja - это тру, поэтому у нас на фронте часть шаблонов стала на Джанго, часть - на jinja, и вот это уже совсем клиника. Пытаясь сделать лучше, я сделал ещё хуже. Уволили меня, правда, не за это, но это не важно.
Уже потом я понял верную тактику для изменений, которая позволила в своё время заменить вообще весь паршивый код у клиента: сначала вы затыкаетесь и пишете код, потом делаете маленькое предложение по улучшению и реализуете его, потом чуть больше, а потом, где-то через полгода, вы можете делать с проектом то, что считаете нужным, вплоть до тотального рефакторинга. Но это игра "в долгую" и имеет смысл только если вам нравится проект, и у вас на него большие планы. Иначе просто сделайте свою работу и не пытайтесь никому ничего доказать.
Stripe
Мне сказали: "будешь пилить приём платежей?" Я подумал, что такой функционал я ещё не ломал, и согласился. К счастью, у нас в компании принято делать код-ревью, если изменения не совсем уж тривиальные, и всё, что могло сломаться, было отловлено. Но есть такие вещи, которые не проходят код ревью.
Секреты.
Секреты не попадают в систему контроля версий, поэтому их нет в репозитории и ревьюер их не видит. Обычно они ставятся вручную где-нибудь в дэшборде облачного сервиса, или в env файлах, или ещё где-то, и ввиду их секретности не каждый сотрудник их знает.
А ещё, как и принято среди джентльменов, у нас были staging и prod сервера. Конечно, мы протестировали на staging и всё работало. Потом мы задеплоили на прод, и всё работало. Ну почти.
В sentry начали сыпаться ошибки типа "платеж не найден". Я потратил некоторое время, чтобы разобраться, какого хрена на сервер приходят уведомления о несуществующих платежах.
Оказывается, я перепутал и записал и в prod, и в staging одинаковые ключи для доступа к платёжной системе.
В итоге на один из серверов приходили платежи от другого. Деталей уже не помню, но, к счастью, это удалось вовремя отловить, и меня не сожгли заживо. Не успели.
В заключение
Мне нравится, что в каждой истории есть какая-то мораль - но я намеренно опустил её в части историй и предоставлю вам право поразмышлять самостоятельно. Но главная идея, как мне кажется, такая:
Чтобы стать хорошим спецом, не нужно бояться облажаться. Нужно бояться не вырасти после этого.
Если вам нравятся мои статьи, то приглашаю вас в то место, где я планирую постить интересные вещи, а Паша Дуров - рекламу: мой телеграм-канал "Блог погромиста".
И традиционно опрос, напрямую связанный со статьёй:
Комментарии (153)
ivankudryavtsev
19.01.2022 09:22+1Поправьте markup пожалуйста, отображается некорректно в тизере.
kesn Автор
19.01.2022 09:28+87Спасибо. Надо было добавить в список провалов "я подумал, что победил форму редактирования на Хабре".
elisoff
19.01.2022 10:04+23Я на своем опыте прекрасно знаю что существует немалая категория специалистов "сначала делаю, а потом разбираюсь что наделал" . Но чтобы вот так хвалится таким талантом , это новенькое.
drWhy
19.01.2022 11:10+44За что и хочется поблагодарить автора. Задним умом все крепки, при этом бокопорят даже команды грандов индустрии, далеко не всегда публикуя анализ инцидентов после разбора.
iyzoer
19.01.2022 11:48+10Задним умом все крепки
Так то да, но у автора есть уж совсем спорные решения. Например с кодировкой, можно было бы все таки и погуглить, прежде чем менять.
elisoff
19.01.2022 12:00+4А еще лучше - погуглить что-же таки произойдет в БД после смены кодировки c индексами и collation.
elisoff
19.01.2022 12:02+5Всякое бывает, но простое беспричинное изменение ключевых параметров без обсуждения это явно не норма. Хотя на хабре своеобразная своя атмосфера.
klvov
19.01.2022 21:16+8Вспомнился лайфхак от старых электриков: после того, как выключил в щитке рубильник, повесил на него табличку "Не включать! Работают люди!", запер щиток на ключ, надо еще принять дополнительные меры предосторожности: надёжно закоротить фазу и ноль на своей стороне.
elisoff
19.01.2022 21:25+6У электриков есть ПЭУ , 17 журналов и постоянная сдача экзамена на группу по ЭБ. Так что это жиза...
omican
19.01.2022 14:53+8Оффтоп: в вашем комментарии я впервые в жизни встретил слово "бокопорить". По контексту понятно, что это синоним "косячить", "факапить" и т.д. Интересно, каково происхождение слова? Беглый гуглеж не подсказал, а собстевнная лингвистическая чуйка молчит...
unC0Rr
19.01.2022 15:29+2Моя чуйка догадалась погуглить «пороть бока», и оказалось, что это молодёжный сленг, означает «делать плохую вещь».
drWhy
19.01.2022 15:44Портить, приводить в негодность. Жаргонизм, новодел, насколько я понимаю. Применяю впервые — как-то всплыло само собой, «косячить» было более вероятно.
По происхождению полагаю от «боком», возможно от «пороть» (чушь) — «бокопор». Но в жаргонизмах логика не всегда верный помощник.
NivER
20.01.2022 14:46+2По происхождению полагаю от «боком», возможно от «пороть» (чушь) — «бокопор». Но в жаргонизмах логика не всегда верный помощник.
Тут как раз логично, это прямое производное от "пороть бока" (как раз в значении "косячить"). Не знаю, насколько новодел, больше 20 лет точно есть этому выражению.
Upd.: вот что бывает, если не проскроллить ещё чуть ниже. Вчера это уже написали до меня.
tommyangelo27
19.01.2022 16:31+6Это от "пороть бока", смысл вы правильно указали. У нас в регионе было очень популярно в конце 90х - начале 2000х.
slonopotamus
19.01.2022 11:55+5Тут ещё и "сначала сделаю на продакшен-сервере, а потом разбираюсь".
nochkin
21.01.2022 01:23+3Есть классная шутка на эту тему:
"У всех есть среда для тестирования изменений. Но только у немногих эта среда отдельно от прода."
13werwolf13
19.01.2022 14:06+13да ладно вам коллега, все мы хоть раз в жизни но тварили чушь. иногда "по запарке" иногда потому что начальник сказал "срочно, ответственность беру на себя".. а иногда по "молодо - зелено".
гораздо важнее чтобы человек сотворив глупость мог извлечь из этого урок.
Vorber
21.01.2022 14:16Со "Срочно, ответственность беру на себя" всхохотнул до икоты. Таких начальников либо не бывает, либо он не надолго начальник.
Armann
19.01.2022 15:48+3Кто без греха - пусть первый бросит камень...
А если кто то бросит - это либо память плохая, либо пока в начале пути, либо просто супермен.
beeruser
19.01.2022 19:50"сначала делаю, а потом разбираюсь что наделал"
Ничего страшного, CEO с утра придёт и поправит.
Stas911
20.01.2022 04:36+1Один мой коллега на вопрос а кто и где тестировал это обновление платежной системы сообщил "а я залил его ночью им на прод и там потестировал" O_O
elisoff
20.01.2022 10:48Вчера с человеком общался . В кассире исчезли 3000 рублей со счета в неизвестном направлении , в другой системе в личном кабинете привязался другой номер телефона и списалось 400 баллов(рублей).Все нормально - храните деньги в сберегательной кассе)))
LevPos
21.01.2022 05:57В кассире исчезли 3000 рублей
У слова "кассир" есть какое-то другое значение?
Кассир — работник, который осуществляет прием, хранение и учет денежной наличности.
elisoff
21.01.2022 13:05Странно, но у яндекса в выдаче топ6 именно то что я имелл виду. Спасибо за уточнение , в поддержку яндекса сам напишу.
Terras
19.01.2022 10:29+47Не увидел никаких ошибок.
1) Если программист не полностью разбирается в какой-то веще, он либо спрашивает совета старших товарищей, либо тратит время на набивание шишек. Тут именно про это.
2) Ошибки программиста — это тратить время на плохие компании, работать за меньшие деньги, чем можно было. Отказаться от релокации из-за своих страхов (в том числе в рамках страны), когда релокация увеличивает качество жизни, зацикливаться на устаревшей технологии. Быть слишком строгим к себе и зацикливаться исключительно на работе. И так далее.
UdarEC
21.01.2022 00:40+1Быть слишком строгим к себе и зацикливаться исключительно на работе.Я бы это в отдельный пункт вынес, так как он частично противоречит 2му.
tyomitch
19.01.2022 11:19+13Чтобы стать хорошим спецом, не нужно бояться облажаться. Нужно бояться не вырасти после этого.
t3chn0ph0b
19.01.2022 11:26+11Спасибо за статью, прочитал на одном дыхании :)
А вот это:
если ваши данные для обучения - говно, то и вся ваша последующая работа - тоже говно
добавлю в золотой фонд цитат.
tyomitch
19.01.2022 11:30+2Оно уже там, ещё от Бэббиджа.
Sky-Fox
19.01.2022 11:27+19Сбасибо за статью!
Я люблю критику. Если вы не заметили, я, как старый дед, всё поливаю грязью и всем недоволен.
Критиковать или "поливать грязью" можно по разному. А самое главное любую критику надо воспринимать как возможность научиться чему-то не ходя по граблям. Ведь тот кто критикует возможно знает что-то что не знаешь ты...
Я подумал, что такой функционал я ещё не ломал, и согласился.
+1 !!!
olekl
19.01.2022 12:10+3Точка возврата - прямо наглядная демонстрация эволюции :) Спасибо что поделились!
darkAlert
19.01.2022 12:21+5Много лет назад мой старший коллега хотел очистить текущую директорию с данными, но опечатался и написал "rm -rf /" вместо "rm -rf *" под рутовым пользователем. И конечно же это было в пятницу, вечером...
p.s. тогда впервые узнал что удаленные данные в ext4 крайне сложно восстанавливать, в отличие от той же ntfs
13werwolf13
19.01.2022 14:02+7написал мне как-то один коллега, что-то типо "ойя случайно rm-rf'нул данные с data раздела, как восстановить?". дело было поздно вечером и я просто ответил ему одним словом "testdisk" и ушёл спать. утром меня ожидало следующее сообщение "слушай, а наверное плохая была идея ставить testdisk на тот раздел откуда удалил данные, а потом пытаться их восстановить туда-же?". таких fasepalm'ов я давненько не ловил..
а вообще на моём опыте что ext4 что ntfs.. по возможности лучше не восстанавливать, особенно большое кол-во мелких файлов. большой шанс что один из окажется битым а ты и не заметишь. благо существуют давно бэкапы, снапшоты..
goldrobot
19.01.2022 19:15Это самый сильный аргумент к тому, что бы перестать печатать ./ всегда и везде, как я это делаю.
a1111exe
20.01.2022 00:36+3p.s. тогда впервые узнал что удаленные данные в ext4 крайне сложно восстанавливать, в отличие от той же ntfs
Не знаю насчёт NTFS, но когда-то давно было дело, срочно нужно было наваять какой-то скрипт на Python, который должен был уже не помню что посчитать в несколько потоков и хозяину фирмы надо было предъявить результаты. Ну и классика жанра: когда уже почти вся логика была написана и я уже радостно предвкушал скорый поход домой после победной демонстрации чего-то там очень важного и срочного - до сих пор не понимаю, что именно я сделал, ЕМНИП, какой-то эксперимент с IronPython - но в результате файлы скрипта исчезли из файловой системы (EXT4). За полчаса до демонстрации результатов. Испытывая разные леденящие чувства, я в полупомрачении загуглил что-то, что подсказало сделать grep на девайс диска или раздела, уже толком не помню. Наверное, раздела. В общем, в процессе работы в отдельном блокноте сохранился кусочек кода, который я и грепнул по /dev/sda1 или что там у меня тогда было в /dev. Через несколько минут (спасибо за SSD!) код скрипта был полностью восстановлен. За оставшееся время он успел отработать, я - вовремя продемонстрировать результаты и в состоянии лёгкой контузии отправиться домой.
В общем, то был продуктивный в смысле морали и извлечённых уроков день, один из них - данные, потерянные EXT4, бывает очень просто восстановить за несколько минут. Впрочем, не буду, конечно, утверждать, что всегда или даже часто. Искать бинарные файлы, наверное, было бы куда сложнее.
Badimagination
20.01.2022 08:08+3Восстановление удалённых данных с SSD кажется лёгким пока не повстречаешь SSD со включенным TRIM-ом
nixtonixto
20.01.2022 08:48И даже с отключенным TRIM восстановить удалённые данные с SSD невозможно. Для HDD перед новой записью не надо стирать старые данные — можно записывать поверх, поэтому там при стирании файла физически только помечается часть заголовка, поэтому такие файлы легко и полностью восстанавливаются, если не было перезаписей пользователя. А на SSD перед новой записью нужно стирать сектор, поэтому при удалении файла в ближайшее свободное время очищаются все сектора этого файла, а фрагменты данных других файлов в этих секторах переуплотняются в свободные секторы, чтобы потом выиграть немного времени при записи новых файлов. Поэтому, или в линуксах SSD работают чуть иначе, или автор приукрасил, а по факту у него был HDD.
a1111exe
20.01.2022 09:22Поэтому, или в линуксах SSD работают чуть иначе, или автор приукрасил, а по факту у него был HDD.
Память очень уверенно сообщает мне, что SSD. Не подскажете, где можно почитать о "в ближайшее свободное время очищаются все сектора этого файла" подробнее?
nixtonixto
20.01.2022 09:47+1Да, в линуксах работает иначе, поскольку в exFat автоматический TRIM не используется. У меня только Windows+NTFS, поэтому все попытки восстановить недавно удалённые файлы всегда оканчивались фиаско.
mayorovp
20.01.2022 13:53А на SSD перед новой записью нужно стирать сектор, поэтому при удалении файла в ближайшее свободное время очищаются все сектора этого файла, а фрагменты данных других файлов в этих секторах переуплотняются в свободные секторы, чтобы потом выиграть немного времени при записи новых файлов.
Это происходит только если SSD и драйвер ФС поддерживают TRIM (либо его эмуляцию через запись ff..ff). Если трима нет совсем-совсем хотя бы с одной из сторон, то очистка секторов невозможна.
v1000
19.01.2022 12:22+11Мне запомнился фейл, который был сделан еще в школе. Урок информатики, в качестве проекта нужно было сделать простенькую программу для работы с базой данных.
Ну не совсем базой в привычном понимании, все сохранялось в файл.
И у программы было два режима - записная книжка и список контактов. Все работало, но иногда программу клинило, она зацикливалась и так далее.
В итоге, за пару недель программа обросла кучей проверок на ошибки, и достаточно простой код превратился в спагетти-монстра в попытках исправить гейзенбаг. Но все равно продолжала работать нестабильно.
В итоге, совершенно случайло заметил, что оба режима пишут в один файл. А должны были в два разных, потому что там подразумевалась разная структура хранения данных.
И если запускать только один из режимов - то все работало. А гейзенбаг был, если после первого режима запустить второй. Или наоборот.
dartraiden
20.01.2022 04:17+1В прошлом году ловил такой баг. Есть приложение, у него есть база, куда оно кладёт настройки, базу можно зашифровать. В связи с этим есть две настройки: «включить шифрование» и «задать пароль» (пароль можно установить без включения шифрования, это важно — данные останутся незашифрованы, но при вводе неверного пароля приложение будет завершаться, такая простенькая защита от любопытных).
Устанавливаю пароль, применяю настройки — всё в порядке.
Включаю шифрование, применяю настройки — всё в порядке.
А если это сделать сразу, без применения настроек между шагами — база превращается в тыкву. Разгадка проста — обе настройки из-за опечатки в коде использовали одну переменную, в итоге, пароль сохранён в памяти, но т.к. настройки не применяли, то на следующем шаге, когда дёргаем крыжик «включить шифрование», пароль перезаписывается каким-то бредом, настройки применяются и этим бредом шифруется база.
rdo
19.01.2022 13:01+2Пару лет назад я проводил миграцию SAP Hybris через 4 мажорные версии. В процессе тестирования новой версии за несколько месяцев тестировщики дважды поймали странный баг - в середине оформления заказа транзакция не полностью откатывалась и в бд отставались куски корзины, куски заказа и т.д. Все это приводило к невозможности оформить новый заказ. Я не особо обратил внимание на эту проблему, воспроизвести ее никогда не удавалось специально.
Но после выкатки на продуктив проблема стала внезапно стабильно появляться у десятка-другого пользователей в день, в результате чего задачу пришлось срочно чинить, пока техподдержка скриптами искала в базе таких заблоченных пользователей и чинила их.
Понять причину проблемы так и не удалось, что часто бывает с коробочными решениями, зато отключение валидатора, который и порождал эту ошибку и делал абсолютно непонятные проверки, помогло.
sva89
19.01.2022 13:02+13Типа если Петя работал с 10 до 12 и с 11 до 15, то в базе должна быть одна строка со временем "с 10 до 15".
Вот они, задачки с литкода.
JustDont
19.01.2022 14:47+5Впрочем, решение с литкода не помогло бы автору не облажаться так, как изложено в этой истории ^_^
Насколько я понял, он сделал что-то в районе N^2, но косяк подкрался с той стороны, что каждый шаг шел отдельным запросом в БД.
yarkov
19.01.2022 13:25+15Я подумал, что такой функционал я ещё не ломал, и согласился.
Чисто мой девиз по жизни ))
ReaderReader
19.01.2022 14:16+7Давным-давно в далекой галактике (все происходило еще во времена Source Safe)… В общем когда я был еще совсем наивным джуном, у которого энтузиазм превышал реальный опыт как минимум на 1024 порядка, у меня был похожий фейл, который раз и навсегда отучил меня от описанного в статье «фигак, фигак и в продакшен» вне зависимости от того, насколько малы вносимые изменения. Клиенту срочно потребовалось больше информации в логах. Фигня вопрос! Функция записи логов в нужном месте уже есть, надо просто добавить туда еще несколько требуемых переменных. Поскольку я был на 100% уверен, что ошибиться в настолько простом коде я нигде не мог, то просто скомпилировал модуль на своей машине и отправил наружу. Проект был на С++, а функция логирования принимала на вход обычную строку форматирования… Подозреваю, что те кто дочитал до этого момента и имеющие хотя бы минимальное представление о C / C++, начали нехорошо улыбаться. Ну разумеется — я добавил параметров форматирования больше чем переменных. Времена были еще совсем травоядные, о тестовых системах и т.п. многие если и слышали, то не более того, поэтому присланный модуль сразу добавили в боевую систему, а поскольку измененная мною функция вызывалась в самом центре проекта, то встало все. До сих пор очень благодарен всем, что меня не расстреляли и не четвертовали, а объяснили, что это печальный, но очень важный опыт, что так делать нельзя, и заодно отправили изучать, что происходит под капотом функций с переменным числом параметров.
drWhy
19.01.2022 15:51+4А ещё нередко больше логов — ближе окирпичивание при небесконечных ресурсах, т.е. почти всегда.
DMGarikk
19.01.2022 15:08+6У меня был интернет-магазин без БД-транзакций. Конец шутки.
хах, я видел одну платежную систему… без транзакций в БД… она вроде до сих пор работает ;)
помню мне мозг просто в клочья разорвало
1) начисляем клиенту на счет +1
2) списываем с отправителя -1
3) профит
…
«если межу 1 и 2 чтото случится… ничего, у них не сойдётся баланс и операция сама отменится через 30 дней силами внешней платежной системы' © объяснение менеджеров системы которая работает с начала 90х
p.s. кстати в т.ч. из этого растут ноги всяких странных длинных сроков в 3-5-180 дней в холдах средств в МПС… чтобы вручную менеджеры успели разобраться в повисших операциях которые 'потерялись'
KarazeyAndrey
19.01.2022 15:51+7От себя парочку добавлю:
1. После универа отрабатывал распределение на заводе эникеем. Надо было переставить винды на компе главного инженера (славного пожилого дядьки). Загрузившись под виндой перенес все его важные документы на диск D. Перезагрузился с загрузочной дискеткой с досом. И форматнул диск С. Потом уже разбираясь что произошло выяснил, что диск С был Ntfs, а D Fat и загрузившись с дискетки второй (с копией важных документов) он видел как единственный. Пришлось осваивать программки для восстановления данных после форматирования. К счастью восстановить удалось все. Мораль - трижды проверьте что вы собираетеь удалить/форматировать
2. Из свежего. У клиента микросервисы. Я заведую сайнапом. Есть отдельный auth service где хранятся права доступа юзера. В определенный момент из-за бага на проде создается достаточно большое количество partial accounts - они удалены в базе customers, но остались записи в auth service, препятствующие юзерам сделать новый сайнап с их емейлом. Баг пофикшен, надо удалить битые данные. Как их найти? Да проще простого - запрос с одним join, смотрим какие записи есть в таблице auth, но отсутсвуют в customers. Выгребаем их id и прогоняем через консольную команду удаляющую partials. Easy. Вот только через час начинают сыпаться сообщения в чате, что никто не может зайти в админ тулзу проекта. В ходе короткого расследования выясняется, что в таблице auth service-а помимо клиентов хранились учетки для админ тулзы (которых естественно не было в таблице customers). К счастью все удаленные данные удалось достаточно оперативно восстановить из бекапа и я отделался парой часов жгучего стыда за свой факап. Мораль - прежде чем лезть в чужую зону отвественности согласуйте свои телодвижения с теми, кто в ней хорошо разбирается.drWhy
19.01.2022 16:17+8«Мораль — прежде чем лезть… согласуйте свои телодвижения с ...»
Со сварщиком. Съездил когда-то в командировку — нужно было добавить пространства системному диску без переустановки. Решил с помощью ни разу ни подводившего Partition Magic слить вместе системный раздел и раздел с данными, на котором оставалось много места. После получаса работы компьютер вырубился — соседям устанавливали новую дверь, сварщик перегрузил сеть. После восстановления электричества все данные… оказались на своём месте, как будто процесс и не запускался. Повторный запуск прошёл успешно, спасибо правильным программистам Partition Magic'а.
И другая похожая история. Коллеге подарили звуковую карту, они были редки и относительно недёшевы. На системном диске места не хватало для установки драйверов, да и в принципе нехорошо оставлять систему с дефицитом дискового пространства. Зато есть второй почти пустой раздел, на котором всего одна папка с программой, её исходниками и большим файлом данных. Решение простое — сжать папку архиватором, временно перенести на системный раздел, второй раздел удалить и за счёт него увеличить системный. С тех пор после сжатия файлов обязательно тестирую — архив не распаковался. Программа была от диплома жены коллеги. Файл данных генерировался собственно программой и не был необходим. Поразила её стоическая реакция — однажды она уже переписывала программу, когда из лаборатории в институте украли компьютер.
И ещё — чудом не очищенная переполненная корзина на забитом до отказа системном диске. Оказывается, хозяйка — бабушка-божий одуванчик хранила в ней все свои файлы, чтобы меньше места на диске занимали.
Arioch
19.01.2022 17:18+1Хотя это и не погроммизм, но раз напомнили...
Помнится дома что-то сделал с раделами диска, кажется сжимал, чтобы втиснуть ещё одну операционку, или чтобы расширить соседний раздел. Это было давно, когда всё ещё жили - и реально различались - DOS, Win16, Win95, WinNT4 и OS/2, а диски были по 3ГБ (дорогие, ходовые вдвое меньше).
И на очередном пиратском диске был не скучный Partition Magic 5.xx - а, если память не подводит, Partition Magic 6 beta
Чем новее - тем лучше, а "наклеечки" типа beta - это же просто график продаж. В общем, запустил. Заодно и поменял размер кластеров, кажется. Саму ФС, слава богу, не менял (если правильно помню).
Запустил.....
Через несколько часов работа закончилась...
Исправленный раздел (или оба? не помню) даже не монтировался.Бэкапы? Какие бэкапы, с трудом семьёй на один компьютер накопили, ругались за объём диска и памяти. В общем, п.. привет. "Всё, накопленное непосильным трудом...".
В агонии снова запускаю PM beta, выбираю те же разделы и по памяти "все константы" забиваю обратно. Размеры кластеров, размеры разделов...
Запуск.
Несколько часов агонии...
....разделы вернулись, файлы вернулись, и даже с данными.
В чём бы ни была ошибка, она оказалось симметричной и при обратном преобразовании себя скомпенсировала.Иногда beta - это в самом деле beta.
svr_91
19.01.2022 17:18После восстановления электричества все данные… оказались на своём месте, как будто процесс и не запускался. Повторный запуск прошёл успешно, спасибо правильным программистам Partition Magic'а.
Возможно, Partition Magic просто предварительно дефрагментировал данные, что вроде более безопасно в плане отключения электричества. Поэтому просто повезло.
Это я к тому, что я как раз однажды имел счастье убить систему Partition Magic-ом. Вроде даже история похожая была, что во время слития (или разбивки) разделов электричество отрубили, или он сам завис, я уж не помню. В общем, обратно он уже не загрузился. С тех пор операции на системном разделе всегда обхожу стороной (да и вообще стараюсь не играть с разделами)
drWhy
19.01.2022 18:01+2Что бы он там ни делал — при этом не терял целостности, т.е. переносил данные и корректировал таблицы размещения файлов согласованно.
А сейчас без привычных инструментов по работе с разделами как-то грустно. Склонировать систему, перенести с hdd на ssd, прочитать данные с сыплющегося диска, восстановить удалённые файлы — ручками в Norton Disk Doctor'е за ночь — как-то уже не хочется, да и объёмы данных увеличились на несколько порядков.
Вспоминается восстановление около тридцати небыстрых компьютеров на XP после Пети — XP весит 1,5 ГБ, с обновлениями — 5,5 ГБ. Если бы устанавливал заново на каждом компьютере систему и обновлял — наверно до сих пор бы не закончил. А так рассортировал лицензии на три несовместимых типа, установил/обновил по одному экземпляру каждого, потом склонировал и активировал все экземпляры.
Так что спасибо творцам правильного ПО, благо сейчас есть качесвенное в т.ч. бесплатное.
Везение — хорошо, но лучше пусть как у белочки — забытые схроны по лесу на зиму — бекапы, чем уверенность в непогрешимости оборудования и своих действиях.
amarao
19.01.2022 16:09+8Рекорд моей ошибки - $74000. Ошибся тегом на image'е в workflow.
Jsty
19.01.2022 17:31А как рассчитали?
amarao
19.01.2022 17:49+1По объективно потерянным деньгам, по курсу на момент потери. Деньги не туда ушли и обратно их было не вернуть. Стейджинг image на продакшен, всё такое.
PATRI0T
19.01.2022 18:51+2просто вау.. бывает..
а как с деньгами? как начальство отнеслось? за чей счет праздник?
amarao
19.01.2022 21:40+6Как к сотруднику, прошедшему курс обучения за $74k. Ценный специалист и т.д. "Не тот" тег там появился не по причине небрежности, а по причине большой путаницы, с которой, оказалось, надо срочно разбираться.
juray
20.01.2022 21:24+2Я разок в прошивке одного девайса ошибся в одном флаге состояния конечного автомата, и при тестировании (довольно поверхностном, надо сказать) баг не всплыл.
Баг приводил к постоянному перезаписыванию одной страницы EEPROM (но только при определенном стечении внешних условий) и соответственно после выработки ресурса циклов — ой. Блок тупо не стартовал, обнаружив ошибку контрольной суммы памяти.
В итоге — возврат по рекламациям где-то полутыщи изделий продажной ценой около 12 тыров. В долларах по тогдашнему курсу получается в районе $50 000. Плюс разные накладные расходы — например на высылку новых в замену…
Yser
19.01.2022 16:28+5Такое в пятнице надо же публиковать, чтобы было время под пиво прочувствовать всю глубину отчаяния и вспомнить свои факапы)
В закладки, прочту на выходных!
gruzoveek
19.01.2022 16:30+4Фигак-фигак и в продакшен. За 15 минут до окончания рабочего дня. Сервис стартует и минут через пять виснет наглухо. Админ ворчит но откатывает. Проверяю - все чисто. Выкатываем, пять минут - все висит. Начальник админа нехорошо смотрит. Откатываем. Начинаю по одному вычленять изменения - все чисто. Выкатываем. Пять минут - виснет наглухо. Админ, начальник админа, мой начальник и случившийся неподалеку ДБА смотрят уже совсем нехорошо. В общем оказалось что безобидныя строчка вставки джаваскриптовой библиотечки, нужная только на проде и потому в спешке не попавшая в релиз после теста, была нужна для некоего внешнего сервиса (вроде какая то статистика для маркетинга). Внешний сервис обращался к ней в прямом эфире, и не получив ответа принимался ддосить сервис со страшной силой. Через пять минут все ноды оказывались забиты наглухо его запросами и балансировщик рапортовал что у него всё. В итоге отделался штрафом и выучил что такое переменные окружения.
DMGarikk
19.01.2022 16:34+17В итоге отделался штрафом и выучил что такое переменные окружения.
ого, а гдейто так штрафуют? (я бы сразу оттуда уволился) у вас какая должность была?
у меня в памяти есть куда более жесткие факапы (не сколько мои личные, сколько всего отдела и организации работы) когда из-за неудачного деплоя, миграции или апдейта рушился крайне чувствительный онлайн… рекорд длительности факапа который я видел — простой карточного процессинга 8 часов… вот это *опа так *опа была… в которую даже я сам влипнуть успел с пустым баком бензина на полдороги до работы и с одной банковской карточкой в кармане… которая не работает потомучто онлайн упал…
и ниче, никого не расстреляли, даже премии не лишили… с тех пор всегда или описываю или держу в уме план отката вплоть до пожара в серверной
mayorovp
20.01.2022 14:05+3То есть был ддос от внешнего сервиса, а виноват оказался программист? Отличный подход, главное есть на кого штраф повесить!
speshuric
19.01.2022 17:43+1Я не встречал такой коллекции хождения по граблям у одного человека (даже у себя), но я или мои коллеги с которыми я работал, вместе прошли, кажется, по всем таким же граблям (или очень-очень похожим). Ну и еще по другим граблям, конечно.
Stas911
19.01.2022 17:57+3Насчет "Попытался быть умней пользователей" и форматов телефонов. Как-то в бытность в банке мне пришлось покопаться с КЛАДР (кто не застал - это раньше была такая всероссийская база адресов всей страны, сейчас заменена на что-то более новое), так каких только странных адресов там не было - типа дома без улиц и улицы без городов и все такое и все это были полностью валидные адреса, где живут люди.
drWhy
19.01.2022 18:26Приснопамятная 3-я улицу Строителей, номерные микрорайоны, улицы/переулки, бульвары и проспекты, проезды/въезды, подъёмы/спуски и прочие тупики, дома/корпуса/стоения, с буквенными индексами вплоть до Ѣ и обязательными цифровыми дробями, несколько улочек Родниковых в мало-мальски крупном городе (город рос, потихоньку включая селеньица, в которых своя Родниковая), монументальные сталинки с несколькими десятками неподписанных домофонизированных подъездов коммунальных квартир — ужас доставщика горячей пиццы и навечное наследие усердных крючкотворов.
juray
20.01.2022 21:41+1habr.com/ru/company/hflabs/blog/260601
— «У семи программистов адрес без дома»
Также были похожие
«Заблуждения программистов об именах» (людей)
habr.com/ru/post/431866
«Заблуждения программистов о времени»
habr.com/ru/post/313274
habr.com/ru/post/146109
habr.com/ru/company/vk/blog/545434
Про время, географию, и опять же адреса
habr.com/ru/company/friifond/blog/271733
mixsture
19.01.2022 18:12+5А про валидацию то автор неправильно решил. Лучше бы оставил валидаторы и добавил возможность произвольных данных. 95% бы прошло через валидаторы и было бы чистыми данными, а остальные 5% в произвольной форме. А то вот потом он жалуется, что на входе ML у него мусор — как раз из таких решений он обычно и происходит.
event1
19.01.2022 18:24+3А не хотел я это удалять, потому что однажды закоммитил секретный ключ в репозиторий, и потом имел радость с BFG. Было здорово, но больше не надо.
В наше просвещённое время есть великолепный git filter-repo. Удалить коммит там проще пареной репы:
git filter-repo --commit-callback 'if commit.original_id in \ [b"<commit hash 1>", b"<commit hash 2>"]: commit.skip()'Stas911
20.01.2022 04:44+1Для секретов AWS есть git-secrets. Наверняка и для других что-то подобное уже запилили.
aleksandy
20.01.2022 11:49+2Ъ по ссылкам не ходят? :)
С главной страницы BFG.
Removes large or troublesome blobs like git-filter-branch does, but faster. And written in Scala
event1
20.01.2022 13:09+3filter-branch — это часть оригинального git. Создана была для тех же примерно целей, но плохой интерфейс и слабая производительность привели к тому, что появилось несколько проектов с теми же целями. Последний из них — git-filter-repo, видимо действительно последний, рекомендован самими разработчиками git:
git filter-branch has a plethora of pitfalls that can produce non-obvious
manglings of the intended history rewrite (and can leave you with little
time to investigate such problems since it has such abysmal performance).
These safety and performance issues cannot be backward compatibly fixed and
as such, its use is not recommended. Please use an alternative history
filtering tool such as git filter-repo.BFG — один из более старых проектов. Возможно, когда автор встретился с проблемой git-filter-repo ещё не существовал
abd2561024
19.01.2022 18:37+5Будучи на первом году работы, попала мне задачка настроить сетку на удаленном сервере (прод платежной системы). Как так вышло что новичку поручили такую задачу оставим за рамками)). Процедура настройки по классике проходила ночью, пока все клиенты спят. После успешно выполненых манипуляций нужно было применить изменения через рестар сетевых интерфейсов (командой
ifconfig eth0 down && ifconfig eth0 up). Довольный, что выполнил все по инструкциям я ввожу команду в консоль но по невнимательности ставлю один амперсанд, тем самым положив сетку и не подняв ее. Это была самая длинная ночь в моей жизни, с попытками достучатся до поддержки серверной, чтобы они с помошью клавиатуры и монитора подняли сетку (доступа по резервному каналу у меня небыло).
nanshakov
19.01.2022 22:36Как в итоге решилось?
abd2561024
20.01.2022 15:13В 5 утра смог таки разбудить сотрудника серверной, который сонный с клавиатурой, дежурным монитором и моими инструкциями о внешнем виде нашей железки пошел искать сервер, и поднял интрефейс сетки. Руководство о фейле узнала утром, после кучи обращений в техподдержку от пользователей, которые пыталсиь провести оплату ночью. Отнеслись к факапу с пониманием.
Exelent
20.01.2022 20:38+1У меня был точно такой же факап. Только я был джуном и даже не задумывался об амперсантах. Жму down, смотрю как меня отключает, в голове начинает зарождаться понимание всей ситуации.
Правда это был staging, и достучался я до сапорта только через 3 дня
kartvladek
19.01.2022 19:35+2Спасибо. Настроение в конце рабочего дня прям поднялось. Не один я такой...
Bringoff
19.01.2022 20:26+8Раз уж тут такие откровения пошли, то...
Подфрилансивал я как-то одной из своих предыдущих работ. Обнаружился баг в мобильном приложении, которое предназначено для активного фотографирования во время работы. Фотографий за день делается сотни. При отсутствии сети приложение не отправляло некоторые из фотографий на бекенд, и при появлении сети не пыталось повторить попытку отправки.
Вроде баг не очень сложный, на основной работе напряг, так что не сильно долго сидел над задачей, поправил, потестил — начало улетать. QA тоже потестили и проблем не нашли. Выкатили в релиз на 30% пользователей на выходных.
Настал понедельник. В 9:30 утра звонит начальство из того проекта. Вообще впервые, чтобы звонок, да еще и без предупреждения. Я напрягаюсь, оказывается, не зря. У них там легло вообще всё. Все сервера для всех клиентов. А ничего, кроме моего приложения, после последнего рабочего дня не менялось. Я судорожно начинаю перебирать в голове, что должно пойти не так, как я приложением умудрился такое сотворить. И тут до меня доходит.
Из-за бага, который я исправил, все зависшие когда-то фотографии вдруг ринулись выгружаться. За несколько месяцев у некоторых пользователей на устройстве их могли быть тысячи. А каждую фотографию надо не просто получить, а и обработать определенным образом, что занимает на сервере десятки секунд порой. Из-за этого нагрузка не сервера подскочила в разы, если не на порядок, и они перестали этот не прекращающийся поток фотографий вывозить. И это только при 15-20% обновившихся пользователей.
Благо, среагировали быстро, релиз не был раскатан полностью, поэтому распространение через Google Play легко остановили, на бекенде поправили тригер обработки неактуальных фотографий, а я по-быстрому запилил хотфикс с дропанием фото старше пары дней из диска и локальной БД (так как они все равно уже не нужны). Стресанул я тогда знатно, но мне ничего не предъявляли по факту, так как пропустил это не только я, а и тестирование, и бекенд не сумел заскейлиться или правильно организовать разросшуюся очередь фотографий.
Еще это, наверное, должно было порядочно высосать трафик у пользователей на рабочих устройствах, где он часто лимитирован. Но на это вроде не жаловались, или жалобы ко мне не дошли.
toxicdream
19.01.2022 20:49+3Да, серьезные факапы.
Из косяков, что сохранились в памяти:
Решил в программе почистить за собой временные файлы. С подкаталогами. Написал красивую рекурсивную функцию. Должна была начать с текущего каталога. То есть с каталога где лежит сама программа. Дело было ВУЗе в единственном на то время компьютерном зале. С вин95. В общем, удаление началось с корня диска С. После минуты ожидания запущенной в отладке программы почуял неладное и прервал выполнение. Это не спасло лаборанта от переустановки винды.
Где-то через месяц лаборанты сдались и поставили NT4.0 на все ПК :)
Ещё один обидный фейл. У друга при обновлении кажется ХамелеонКлок, потерялись все напоминалки, и в том числе самые важные - о днях рождениях многочисленных родственников.
В общем, этих случаев мне хватило чтобы думать что делаю, и что делать если не получится. Бэкапы, ещё раз пооверить бэкапы, загрузочные, установочные, разнообразные утилиты... Создание своих установочных...
Даже жаль что сейчас все почти само работает :)
Ещё один совет услышанный от умного админа: работать без корзины. Удалять всё что не нужно сразу. Тогда перед удалением подумаешь пять раз - точно это не нужно? И с лёгкостью - Shift+Del (в TC убрана галочка "запрашивать подтверждение")
SexTools
19.01.2022 21:03+1Ubuntu же ещё с бородатых времён умеет в LVM, то ли с 9ки, то с 11ой ставила её по-умолчанию при чистой установке. Даже и сейчас имеет эту опцию. Так вот там есть снапшоты и можно замораживать состояние системы перед её обновление чтобы в случае чего откатить.
dartraiden
20.01.2022 09:29Ну или более топорно — Clonezilla LiveCD. Загрузился, снял образ. Если после обновления случились ужасы — таким же образом раскатал его взад.
bankir1980
19.01.2022 22:28+4Я работал в банке и один раз попросили удалить загруженный рейс с платежами, поступившими из ЦБ. А в Мск была рейстовая система. 5 рейсов в день. В одном рейсе несколько файлов обменов с ЦБ. Удалить входящие документы и загрузить заново это просто. Но я умудрился удалить вообще все данные рейса. В том числе и отправленных платежей. Учитывая жопу с идентификаторами связки платежей в банке и ЦБ, пришлось делать откат БД на ближайшую точку восстановления и догонять всё из разных систем (банк клиент, доки из ЦБ, ручные документы, всякие системы переводов типа Контакт, вестерн Юнион и тп.). В итоге банк стоял часа 3 и не мог работать, пока всё не восстановили. А платежей в рейсе я удалил на 500 млн. рублей...
nanshakov
19.01.2022 22:32+2Решил я заархивировать старые файлы артефактов ML на Google cloud. Что то пошло не так и я сжёг 20000$. Всё было согласовано с лидом устно. С менеджерами выше говорили долго и в итоге все щамчли .Деньги гугл вернул. По мои расчётам сумма должна была быть около 2к баксов.ББыла ли это моя ошибка или ошибка биллинг а гугла я не знаю.
gecube
19.01.2022 22:42ошибка биллинг а гугла
это было бы эпично. Что интересно - мы абсолютно доверяемся честности Амазона-Гугла и прочих поставщиков и у нас как у потребителей нет возможности провести альтернативный подсчет стоимости предоставленных услуг...
nanshakov
19.01.2022 22:50Просто там кол во операций над файлами, которые тарифицирубтся было сильно больше чем файлов, вот у меня и возникли подозрения. Но процесс уже было не остановить - это смена типа бакета
saboteur_kiev
20.01.2022 01:39+3Читаю статью и про себя ухмыляюсь, потому что блин, всегда радовался что я предусматривал подобные вещи.
Наверное потому, что кроме работы у меня было в юности хобби администрировать разные игрушки (были и по 10 онлайна и по 100 и по 100.000), и наверное большинство фейлов отработал на них. Понял и смысл бэкапов и целостности бэкапов и логов и вменяемых логов с полезной информацией, и вменяемых логов с полезной информацией и стандартизированным форматом, который потом легко читать, анализировать, закидывать в разные системы (ну или банально перлом парсить).
И как-то так вышло, что на всех работах фейлы были минимальны, зачастую даже прям за день до потенциального фейла предусмотрительно готовился, и проносило.Так что опыт, неважно на чем - это опыт
krabdb
20.01.2022 04:46+5Блин, но как можно делать систему учета чего-либо без хранения истории перемещения товаров или вообще не знать об индексах БД? И при этом "работать над проектами". Мне кажется, это когда вошли в ИТ сразу мимо изучения теоретической базы. Именно такие "профи" и возмущаются потом вопросам по базовым алгоритмам на собеседованиях.
mixsture
20.01.2022 14:43+3Я с системами учета, продажи и производства товаров более 15 лет работаю. Но все равно возмущаюсь вопросам про алгоритмы :)
Потому что они реально нужны в 0,1% случаев и есть всегда более полезные по применимости технологии, которые можно выучить вместо них.
Stas911
20.01.2022 04:50На заре карьеры писали мы интерфейс POS системы с расчетной системой. Там POS генерил файлики, а расчетная система их обрабатывала и изменяла балансы счетов. Мне начальник поручил проверить апдейт интерфейса. Ну я файлики покидал, посмотрел, что в расчетке балансы меняются, сказал "ок, работает" и апдейт отправили клиенту. На следующий день выяснилось, что работать-то он работает, но при внесении средств через POS баланс клиента в расчетке уменьшался, а не увеличивался (со знаком промахнулись, ага). Меня не распяли, несколько проводок откатили, перед клиентами извинились. С тех пор не берусь тестировать то, что не понимаю, как должно работать.
svr_91
20.01.2022 08:43Интересно, а где все те ошибки от неприменения Solid, от использования ОП вместо ФП (или наоборот), от выбора неправильного ЯП, от неудачного нейминга переменных? Неужели люди зря придумывали все эти аббревиатуры?
tommyangelo27
20.01.2022 11:12+3Мои самые неприятные ошибки обе связаны с путями в CLI.
Один раз хотел изменить оунера для файлов в каталоге, рука дрогнула и полетела команда `chown -R root:root /`. Я сразу косяка не заметил и отключил свою SSH-сессию. В итоге заново подключиться не удалось никому, так как системе не хватало прав на создание временных файлов. Самое неприятное — это было в канун моей свадьбы… Сидели с лидом до 3х ночи пытались залить веб-шелл через форму для файлов на проекте :-) Но не помогло. А утром я пошёл в ЗАГС.
В итоге ничего особо страшного не произошло, приложение себе крутилось несколько дней, клиенты даже не заметили ничего. Если я правильно запомнил — админ связался с работниками датацентра с другого континента, которые имели к серверу физический доступ, и они всё исправили.
Второй косяк был гораздо неприятнее. Разрабатывали интернет-магазин для крупного магазина брендовой одежды (с сумочками по $20k и платьями по $8k). И я на прямо на проде во время апгрейда на новую версию хотел удалить логи, но забыл, что сменил текущий каталог. Удалил 12.5 Gb фотографий (общий размер был около 100 Gb). Быстро среагировал на то, что как-то слишком долго логи удаляются и нажал CTRL+C.
Сразу пошёл к админу спрашивать про бекапы. Оказалось последний бекап был в марте, а на дворе октябрь…
Пришлось идти к клиенту на поклон. Для них фотографии один из основных инструментов продаж, так как магазин — дочка очень популярного журнала мод.
Эта история научила всегда запускать `pwd` перед любыми действиями типа mv, cp, rm, chmod и т.д.Jsty
20.01.2022 22:19+1Очень помогает нормально настроенный шелл. Например, через oh-my-zsh. И на проде цвет там поменять, другое приглашение сделать, чтобы не ошибиться.
usv_usv
20.01.2022 12:59+1опрос ППА… а что это
это старый, но всеми любимый метод)gecube
20.01.2022 13:06ППА - программа поддержки авторов (с) Хабр
dartraiden
20.01.2022 21:21+2Учитывая сколько там нужно слить Хабру своих персданных (паспортные данные, снилс, скан паспорта, адрес, телефон), вывод денег по ППА это ещё тот секс.
gecube
20.01.2022 22:28+1ну, как бы это полноценный договор. Когда делаешь договор ИП - ИП, точно так же надо номер паспорта, ИНН, адрес, телефон. Разве что скан паспорта не требует. И? Знай своих контрагентов, а то вдруг это навялнята, иностранные агенты или террористы...
kesn Автор
20.01.2022 22:47+2Ну они чего-то перегнули, там даже скан свидетельства о присвоении ИНН запросили, а я понятия не имею, в каком пространстве-времени оно у меня валяется.
Отправил вместо скана картинку мужика, делающего ¯_(ツ)_/¯ - прокатило, аккаунт одобрили...
greblin
20.01.2022 23:39+4Много лет назад ещё будучи студентом пришёл в небольшую фирму. В первый же день, разбираясь в системе, случайно очистил какую-то табличку. Кажется просто условие where ещё не написал, а запрос уже отправил. Первая мысль была тихо взять вещи, убежать и никогда не возвращаться. Справившись с этим порывом, начал разбираться, как можно исправить. Пока разбирался, пришёл крон и пересчитал все очищенные данные :)
Год назад обнаружили что высоконагруженная система поиска авиабилетов из 30 golang-микросервисов стала регулярно упираться в таймлимит на 99ом перцентиле. Решили разбираться, а не тупо поднять таймауты, потому что в таких вещах сегодня 99ый , завтра 95ый, а послезавтра 90ый, а это уже очень плохо. Потратили несколько недель меня и ещё одного разработчика, обнаружили узкий сервис, перетряхнули все горутины, отпрофилировали pprof'ом, устранили перемещение данных при изменении размера слайсов, залезли в сетевое взаимодействие... Стало лучше, но не сильно. И тут я вспоминаю, что при интеграции новой клиентской по отношению к нашей системы, я забыл передать флажочек, настраивающий фильтрацию длинного хвоста из неконверсионного ассортимента.
В общем, количество ошибок обратно пропорционально опыту. Но при этом цена ошибки прямо пропорциональна ему :)
werevolff
21.01.2022 00:32+2Спасибо. В 2019 году я совершил довольно дорогую ошибку, после чего не мог собраться весь следующий год. Оказывается, я ещё не так плох. А, судя по комментам, многие специалисты просто скрывают свои ошибки. Этот пост поднял мою самооценку.
nibb13
21.01.2022 17:34+3Тоже расскажу о паре случаев. Не прям уж факапы, но около.
Первый:
Вечер пятницы, август, мы с шефом задержались на работе "подтянуть хвосты". Делаю выборки из базы и она, вдруг, ложится. Потом снова поднимается, потом опять ложится... Шеф шлёт меня в "серверную" (чулан под крышей) На месте я слышу, как винт с базой то стартует, то останавливается со случайными интервалами. Останавливаю сервер, лезу внутрь, думаю "питание отошло". Выдёргиваю Molex из HDD и в разъёме остаётся пин +12V! Треснул каким-то чудом, а я его окончательно добил.
А у нас по выходным репликация биллинговых баз с 17-ю городами.
А в отделе ни одного паяльника (программисты аппаратные проблемы не решают :))
Звоню шефу. Он говорит: "Хватай винт, беги в подвал и по дороге надейся, что КИПовцы такие же трудоголики как мы. Обещай им пива и рыбы сколько влезет." Лечу семь этажей вниз, мужики действительно ещё на месте. Пин припаяли, репликация была спасена, шеф незамедлительно обещание сдержал. Ну и мы с ним присоединились, пятница же.
Второй:
"Сердцем" нашего биллинга была хранимая процедура T-SQL размером около 1500 строк. Многие из этих строк были длиной в три-четыре экрана. Ни одного комментария. Куча копипаста. Плюс, часть бизнес-логики вообще реализовывалась в клиенте!
Каждому новому программисту в отделе в качестве "проверки на вшивость" выдавалась задача разобраться в устройстве этой хранимки. Многие "горячие головы" сразу же обнаруживали явные баги (неправильные округления, ошибки при копипасте etc.) и лезли их исправлять. Разумеется, вся база после этого ломалась, т.к. эти баги компенсировались контр-багами в клиенте и в данных. Делалось всё это, конечно, на тестовом сервере, во избежание. Над новичками незлобно посмеивались и говорили, что они прошли посвящение.
Меня сей позор миновал в силу природной лени и осторожности: перед тем, как что-то делать, я начал задавать вопросы: "А почему здесь именно так?" и "Почему именно так до сих пор?"
Моему "младшему" задачу видоизменили: не только разобраться, но и переписать на Perl. Справился "на славу". Надо было видеть глаза шефа, когда уже 300-строчная программа выдала тот же результат, причём ощутимо быстрее. А в коде оказались аккуратно перенесенные баги оригинальной хранимки, при этом педантично помеченные комментариями. Я в итоге "раскололся", кто младшего надоумил. Но уточнил, что вопросы по багам он задавал всё-таки по своей инициативе.
DMGarikk
21.01.2022 17:47Делаю выборки из базы и она, вдруг, ложится. Потом снова поднимается, потом опять ложится.
На месте я слышу, как винт с базой то стартует, то останавливается со случайными интервалами
кстати мораль — использовать серверное железо и вообще RAID для базы
rrrad
с кодировкой в MySQL - это прям по классике: работает - не трожь.
13werwolf13
у меня коллега как-то переносил легаси zabbix, что сам zabbix что его БД жили на freebsd, а переезжали как водится на линукс. внезапно оказалось что кодировка в бд utf8mb стоящая в мускуле на фре и в мускуле на линукс это ска разные кодировки...
AlexeyK77
А вот это действительно больно... Что бы на БД в пределах одной версии была такая засада, такое никто не ожидает.
nochkin
Я, кстати, переносил такое недавно и проблем не было. Я даже настолько легко к этому относился, что у меня мажорные версии БД различались и я об этом прекрасно знал. Но всё прошло нормально.
Может, в чём-то ещё был косяк или просто одно наложилось на другое?
13werwolf13
дело было прилично времени назад, да и я не сильно тогда вдавался в подробности..
но суть заключалась в том что всё на латинице осталось нормальным, а вот кирилица превратилась в кракозябры из-за чего уведомления в телеге об алертах мы пару дней разгадывали всем составом. помнится тогда никто сильно не заморачивался с тем чтобы как-то перепилить и перезалить базу, просто вручную поправили те несколько мест где была кирилица заменив её на латиницу или просто переписав на кирилице по новой я уж не помню
tyomitch
Во имя справедливости: не только в MySQL под названием UTF-8 используется нестандартная частично-совместимая самоделка, но и в Oracle DB и в Java SE. Просто потому, что все эти реализации создавались ещё до появления стандарта.
mayorovp
Что-то я не нашёл по вашей ссылке упоминания проблем с utf-8 в Java.
Да, там сломаны символы (то, что называется char и должно, по логике, отражать Unicode code point — на деле является utf-16 code unit), но именно с utf-8 проблем я не помню. Можете показать в чём проблема конкретно?
tyomitch