Комментарии 204
с кодировкой в MySQL - это прям по классике: работает - не трожь.
у меня коллега как-то переносил легаси zabbix, что сам zabbix что его БД жили на freebsd, а переезжали как водится на линукс. внезапно оказалось что кодировка в бд utf8mb стоящая в мускуле на фре и в мускуле на линукс это ска разные кодировки...
А вот это действительно больно... Что бы на БД в пределах одной версии была такая засада, такое никто не ожидает.
Я, кстати, переносил такое недавно и проблем не было. Я даже настолько легко к этому относился, что у меня мажорные версии БД различались и я об этом прекрасно знал. Но всё прошло нормально.
Может, в чём-то ещё был косяк или просто одно наложилось на другое?
дело было прилично времени назад, да и я не сильно тогда вдавался в подробности..
но суть заключалась в том что всё на латинице осталось нормальным, а вот кирилица превратилась в кракозябры из-за чего уведомления в телеге об алертах мы пару дней разгадывали всем составом. помнится тогда никто сильно не заморачивался с тем чтобы как-то перепилить и перезалить базу, просто вручную поправили те несколько мест где была кирилица заменив её на латиницу или просто переписав на кирилице по новой я уж не помню
Что-то я не нашёл по вашей ссылке упоминания проблем с utf-8 в Java.
Да, там сломаны символы (то, что называется char и должно, по логике, отражать Unicode code point — на деле является utf-16 code unit), но именно с utf-8 проблем я не помню. Можете показать в чём проблема конкретно?
Modified UTF-8 is not new to the Java platform, but it's something that application developers need to be more aware of when converting text that might contain supplementary characters to and from UTF-8. The main thing to remember is that some J2SE interfaces use an encoding that's similar to UTF-8 but incompatible with it. This encoding has in the past sometimes been called «Java modified UTF-8» or (incorrectly) just «UTF-8». For J2SE 5.0, the documentation is being updated to uniformly call it «modified UTF-8.»
The incompatibility between modified UTF-8 and standard UTF-8 stems from two differences. First, modified UTF-8 represents the character U+0000 as the two-byte sequence 0xC0 0x80, whereas standard UTF-8 uses the single byte value 0x0. Second, modified UTF-8 represents supplementary characters by separately encoding the two surrogate code units of their UTF-16 representation. Each of the surrogate code units is represented by three bytes, for a total of six bytes. Standard UTF-8, on the other hand, uses a single four byte sequence for the complete character.
Modified UTF-8 is used by the Java Virtual Machine and the interfaces attached to it (such as the Java Native Interface, the various tool interfaces, or Java class files), in thejava.io.DataInputandDataOutputinterfaces and classes implementing or using them, and for serialization. The Java Native Interface provides routines that convert to and from modified UTF-8. Standard UTF-8, on the other hand, is supported by theStringclass, by thejava.io.InputStreamReaderandOutputStreamWriterclasses, thejava.nio.charsetfacilities, and many APIs layered on top of them.
Поправьте markup пожалуйста, отображается некорректно в тизере.
А где в опросе пыщь-Бэтмен? Или за него Алёшка дежурит?
Так было уже, [object Object] называется.
Я на своем опыте прекрасно знаю что существует немалая категория специалистов "сначала делаю, а потом разбираюсь что наделал" . Но чтобы вот так хвалится таким талантом , это новенькое.
Задним умом все крепки
Так то да, но у автора есть уж совсем спорные решения. Например с кодировкой, можно было бы все таки и погуглить, прежде чем менять.
Всякое бывает, но простое беспричинное изменение ключевых параметров без обсуждения это явно не норма. Хотя на хабре своеобразная своя атмосфера.
Вспомнился лайфхак от старых электриков: после того, как выключил в щитке рубильник, повесил на него табличку "Не включать! Работают люди!", запер щиток на ключ, надо еще принять дополнительные меры предосторожности: надёжно закоротить фазу и ноль на своей стороне.
У электриков есть ПЭУ , 17 журналов и постоянная сдача экзамена на группу по ЭБ. Так что это жиза...
И в случае чего менять старый секционник, который теперь не взводится переразделывать концы кабеля и чистить щит/секцию от того, что налетело из дугогасительных камер? :)
Сомнительное удовольствие. Таки организационные проблемы техническими мерами не решаются.
Лучше заменить секционник чем электрика.
Вы лично хоть раз устраивали замыкание так, что приходилось вызывать дежурного на подстанцию включать все взад? Видели что происходит рядом с этой закороткой происходит?
И как потом стоит обесточенная промка, а автомат можно поменять только с КНТПшкой, он комплектный, их просто больше нет.
Судя по всему - нет. Поэтому прочитали то, что я написал как предложение расходовать оперативно-ремонтный персонал в угоду электроснабжению.
Хотя, один случай когда да - у меня был. Когда "электрики" запитали операционную и свет в ней с одного ввода. И под один АВ. А снабжение нашло светильник подешевле. Который долго не могли продать и он сгнил внутри. И вот интубированный под наркозом больной, светит бестеневая лампа, в которой доживает свои последние минуты изоляция, идёт операция. Хлопок, треск, темнота, обесточенная операционная. Всё обошлось, но помереть тут должен не пациент.
Оффтоп: в вашем комментарии я впервые в жизни встретил слово "бокопорить". По контексту понятно, что это синоним "косячить", "факапить" и т.д. Интересно, каково происхождение слова? Беглый гуглеж не подсказал, а собстевнная лингвистическая чуйка молчит...
По происхождению полагаю от «боком», возможно от «пороть» (чушь) — «бокопор». Но в жаргонизмах логика не всегда верный помощник.
По происхождению полагаю от «боком», возможно от «пороть» (чушь) — «бокопор». Но в жаргонизмах логика не всегда верный помощник.
Тут как раз логично, это прямое производное от "пороть бока" (как раз в значении "косячить"). Не знаю, насколько новодел, больше 20 лет точно есть этому выражению.
Upd.: вот что бывает, если не проскроллить ещё чуть ниже. Вчера это уже написали до меня.
Это от "пороть бока", смысл вы правильно указали. У нас в регионе было очень популярно в конце 90х - начале 2000х.
Тут ещё и "сначала сделаю на продакшен-сервере, а потом разбираюсь".
да ладно вам коллега, все мы хоть раз в жизни но тварили чушь. иногда "по запарке" иногда потому что начальник сказал "срочно, ответственность беру на себя".. а иногда по "молодо - зелено".
гораздо важнее чтобы человек сотворив глупость мог извлечь из этого урок.
Кто без греха - пусть первый бросит камень...
А если кто то бросит - это либо память плохая, либо пока в начале пути, либо просто супермен.
"сначала делаю, а потом разбираюсь что наделал"
Ничего страшного, CEO с утра придёт и поправит.
Один мой коллега на вопрос а кто и где тестировал это обновление платежной системы сообщил "а я залил его ночью им на прод и там потестировал" O_O
Вчера с человеком общался . В кассире исчезли 3000 рублей со счета в неизвестном направлении , в другой системе в личном кабинете привязался другой номер телефона и списалось 400 баллов(рублей).Все нормально - храните деньги в сберегательной кассе)))
В кассире исчезли 3000 рублей
У слова "кассир" есть какое-то другое значение?
Кассир — работник, который осуществляет прием, хранение и учет денежной наличности.
1) Если программист не полностью разбирается в какой-то веще, он либо спрашивает совета старших товарищей, либо тратит время на набивание шишек. Тут именно про это.
2) Ошибки программиста — это тратить время на плохие компании, работать за меньшие деньги, чем можно было. Отказаться от релокации из-за своих страхов (в том числе в рамках страны), когда релокация увеличивает качество жизни, зацикливаться на устаревшей технологии. Быть слишком строгим к себе и зацикливаться исключительно на работе. И так далее.
Быть слишком строгим к себе и зацикливаться исключительно на работе.
Я бы это в отдельный пункт вынес, так как он частично противоречит 2му.
При использовании абстрагирования, главное - не уйти в рекурсию. Окажется, что в масштабах вселенной проблем не существует. И главное - оказаться на обитаемой планете )
Чтобы стать хорошим спецом, не нужно бояться облажаться. Нужно бояться не вырасти после этого.
Спасибо за статью, прочитал на одном дыхании :)
А вот это:
если ваши данные для обучения - говно, то и вся ваша последующая работа - тоже говно
добавлю в золотой фонд цитат.
Сбасибо за статью!
Я люблю критику. Если вы не заметили, я, как старый дед, всё поливаю грязью и всем недоволен.
Критиковать или "поливать грязью" можно по разному. А самое главное любую критику надо воспринимать как возможность научиться чему-то не ходя по граблям. Ведь тот кто критикует возможно знает что-то что не знаешь ты...
Я подумал, что такой функционал я ещё не ломал, и согласился.
+1 !!!
Точка возврата - прямо наглядная демонстрация эволюции :) Спасибо что поделились!
Много лет назад мой старший коллега хотел очистить текущую директорию с данными, но опечатался и написал "rm -rf /" вместо "rm -rf *" под рутовым пользователем. И конечно же это было в пятницу, вечером...
p.s. тогда впервые узнал что удаленные данные в ext4 крайне сложно восстанавливать, в отличие от той же ntfs
написал мне как-то один коллега, что-то типо "ойя случайно rm-rf'нул данные с data раздела, как восстановить?". дело было поздно вечером и я просто ответил ему одним словом "testdisk" и ушёл спать. утром меня ожидало следующее сообщение "слушай, а наверное плохая была идея ставить testdisk на тот раздел откуда удалил данные, а потом пытаться их восстановить туда-же?". таких fasepalm'ов я давненько не ловил..
а вообще на моём опыте что ext4 что ntfs.. по возможности лучше не восстанавливать, особенно большое кол-во мелких файлов. большой шанс что один из окажется битым а ты и не заметишь. благо существуют давно бэкапы, снапшоты..
Это самый сильный аргумент к тому, что бы перестать печатать ./ всегда и везде, как я это делаю.
p.s. тогда впервые узнал что удаленные данные в ext4 крайне сложно восстанавливать, в отличие от той же ntfs
Не знаю насчёт NTFS, но когда-то давно было дело, срочно нужно было наваять какой-то скрипт на Python, который должен был уже не помню что посчитать в несколько потоков и хозяину фирмы надо было предъявить результаты. Ну и классика жанра: когда уже почти вся логика была написана и я уже радостно предвкушал скорый поход домой после победной демонстрации чего-то там очень важного и срочного - до сих пор не понимаю, что именно я сделал, ЕМНИП, какой-то эксперимент с IronPython - но в результате файлы скрипта исчезли из файловой системы (EXT4). За полчаса до демонстрации результатов. Испытывая разные леденящие чувства, я в полупомрачении загуглил что-то, что подсказало сделать grep на девайс диска или раздела, уже толком не помню. Наверное, раздела. В общем, в процессе работы в отдельном блокноте сохранился кусочек кода, который я и грепнул по /dev/sda1 или что там у меня тогда было в /dev. Через несколько минут (спасибо за SSD!) код скрипта был полностью восстановлен. За оставшееся время он успел отработать, я - вовремя продемонстрировать результаты и в состоянии лёгкой контузии отправиться домой.
В общем, то был продуктивный в смысле морали и извлечённых уроков день, один из них - данные, потерянные EXT4, бывает очень просто восстановить за несколько минут. Впрочем, не буду, конечно, утверждать, что всегда или даже часто. Искать бинарные файлы, наверное, было бы куда сложнее.
Восстановление удалённых данных с SSD кажется лёгким пока не повстречаешь SSD со включенным TRIM-ом
Поэтому, или в линуксах SSD работают чуть иначе, или автор приукрасил, а по факту у него был HDD.
Память очень уверенно сообщает мне, что SSD. Не подскажете, где можно почитать о "в ближайшее свободное время очищаются все сектора этого файла" подробнее?
А на SSD перед новой записью нужно стирать сектор, поэтому при удалении файла в ближайшее свободное время очищаются все сектора этого файла, а фрагменты данных других файлов в этих секторах переуплотняются в свободные секторы, чтобы потом выиграть немного времени при записи новых файлов.
Это происходит только если SSD и драйвер ФС поддерживают TRIM (либо его эмуляцию через запись ff..ff). Если трима нет совсем-совсем хотя бы с одной из сторон, то очистка секторов невозможна.
Кто б знал, что это плохая примета - использовать numpad клавиатуру для ввода /
Мне запомнился фейл, который был сделан еще в школе. Урок информатики, в качестве проекта нужно было сделать простенькую программу для работы с базой данных.
Ну не совсем базой в привычном понимании, все сохранялось в файл.
И у программы было два режима - записная книжка и список контактов. Все работало, но иногда программу клинило, она зацикливалась и так далее.
В итоге, за пару недель программа обросла кучей проверок на ошибки, и достаточно простой код превратился в спагетти-монстра в попытках исправить гейзенбаг. Но все равно продолжала работать нестабильно.
В итоге, совершенно случайло заметил, что оба режима пишут в один файл. А должны были в два разных, потому что там подразумевалась разная структура хранения данных.
И если запускать только один из режимов - то все работало. А гейзенбаг был, если после первого режима запустить второй. Или наоборот.
Устанавливаю пароль, применяю настройки — всё в порядке.
Включаю шифрование, применяю настройки — всё в порядке.
А если это сделать сразу, без применения настроек между шагами — база превращается в тыкву. Разгадка проста — обе настройки из-за опечатки в коде использовали одну переменную, в итоге, пароль сохранён в памяти, но т.к. настройки не применяли, то на следующем шаге, когда дёргаем крыжик «включить шифрование», пароль перезаписывается каким-то бредом, настройки применяются и этим бредом шифруется база.
Пару лет назад я проводил миграцию SAP Hybris через 4 мажорные версии. В процессе тестирования новой версии за несколько месяцев тестировщики дважды поймали странный баг - в середине оформления заказа транзакция не полностью откатывалась и в бд отставались куски корзины, куски заказа и т.д. Все это приводило к невозможности оформить новый заказ. Я не особо обратил внимание на эту проблему, воспроизвести ее никогда не удавалось специально.
Но после выкатки на продуктив проблема стала внезапно стабильно появляться у десятка-другого пользователей в день, в результате чего задачу пришлось срочно чинить, пока техподдержка скриптами искала в базе таких заблоченных пользователей и чинила их.
Понять причину проблемы так и не удалось, что часто бывает с коробочными решениями, зато отключение валидатора, который и порождал эту ошибку и делал абсолютно непонятные проверки, помогло.
Типа если Петя работал с 10 до 12 и с 11 до 15, то в базе должна быть одна строка со временем "с 10 до 15".
Вот они, задачки с литкода.
Я подумал, что такой функционал я ещё не ломал, и согласился.
Чисто мой девиз по жизни ))
Про пересорт прямо в точку! Вообще проблема количественного учета vs поэкземплярный до сих пор актуальна.
У меня был интернет-магазин без БД-транзакций. Конец шутки.
хах, я видел одну платежную систему… без транзакций в БД… она вроде до сих пор работает ;)
помню мне мозг просто в клочья разорвало
1) начисляем клиенту на счет +1
2) списываем с отправителя -1
3) профит
…
«если межу 1 и 2 чтото случится… ничего, у них не сойдётся баланс и операция сама отменится через 30 дней силами внешней платежной системы' © объяснение менеджеров системы которая работает с начала 90х
p.s. кстати в т.ч. из этого растут ноги всяких странных длинных сроков в 3-5-180 дней в холдах средств в МПС… чтобы вручную менеджеры успели разобраться в повисших операциях которые 'потерялись'
От себя парочку добавлю:
1. После универа отрабатывал распределение на заводе эникеем. Надо было переставить винды на компе главного инженера (славного пожилого дядьки). Загрузившись под виндой перенес все его важные документы на диск D. Перезагрузился с загрузочной дискеткой с досом. И форматнул диск С. Потом уже разбираясь что произошло выяснил, что диск С был Ntfs, а D Fat и загрузившись с дискетки второй (с копией важных документов) он видел как единственный. Пришлось осваивать программки для восстановления данных после форматирования. К счастью восстановить удалось все. Мораль - трижды проверьте что вы собираетеь удалить/форматировать
2. Из свежего. У клиента микросервисы. Я заведую сайнапом. Есть отдельный auth service где хранятся права доступа юзера. В определенный момент из-за бага на проде создается достаточно большое количество partial accounts - они удалены в базе customers, но остались записи в auth service, препятствующие юзерам сделать новый сайнап с их емейлом. Баг пофикшен, надо удалить битые данные. Как их найти? Да проще простого - запрос с одним join, смотрим какие записи есть в таблице auth, но отсутсвуют в customers. Выгребаем их id и прогоняем через консольную команду удаляющую partials. Easy. Вот только через час начинают сыпаться сообщения в чате, что никто не может зайти в админ тулзу проекта. В ходе короткого расследования выясняется, что в таблице auth service-а помимо клиентов хранились учетки для админ тулзы (которых естественно не было в таблице customers). К счастью все удаленные данные удалось достаточно оперативно восстановить из бекапа и я отделался парой часов жгучего стыда за свой факап. Мораль - прежде чем лезть в чужую зону отвественности согласуйте свои телодвижения с теми, кто в ней хорошо разбирается.
Со сварщиком. Съездил когда-то в командировку — нужно было добавить пространства системному диску без переустановки. Решил с помощью ни разу ни подводившего Partition Magic слить вместе системный раздел и раздел с данными, на котором оставалось много места. После получаса работы компьютер вырубился — соседям устанавливали новую дверь, сварщик перегрузил сеть. После восстановления электричества все данные… оказались на своём месте, как будто процесс и не запускался. Повторный запуск прошёл успешно, спасибо правильным программистам Partition Magic'а.
И другая похожая история. Коллеге подарили звуковую карту, они были редки и относительно недёшевы. На системном диске места не хватало для установки драйверов, да и в принципе нехорошо оставлять систему с дефицитом дискового пространства. Зато есть второй почти пустой раздел, на котором всего одна папка с программой, её исходниками и большим файлом данных. Решение простое — сжать папку архиватором, временно перенести на системный раздел, второй раздел удалить и за счёт него увеличить системный. С тех пор после сжатия файлов обязательно тестирую — архив не распаковался. Программа была от диплома жены коллеги. Файл данных генерировался собственно программой и не был необходим. Поразила её стоическая реакция — однажды она уже переписывала программу, когда из лаборатории в институте украли компьютер.
И ещё — чудом не очищенная переполненная корзина на забитом до отказа системном диске. Оказывается, хозяйка — бабушка-божий одуванчик хранила в ней все свои файлы, чтобы меньше места на диске занимали.
Хотя это и не погроммизм, но раз напомнили...
Помнится дома что-то сделал с раделами диска, кажется сжимал, чтобы втиснуть ещё одну операционку, или чтобы расширить соседний раздел. Это было давно, когда всё ещё жили - и реально различались - DOS, Win16, Win95, WinNT4 и OS/2, а диски были по 3ГБ (дорогие, ходовые вдвое меньше).
И на очередном пиратском диске был не скучный Partition Magic 5.xx - а, если память не подводит, Partition Magic 6 beta
Чем новее - тем лучше, а "наклеечки" типа beta - это же просто график продаж. В общем, запустил. Заодно и поменял размер кластеров, кажется. Саму ФС, слава богу, не менял (если правильно помню).
Запустил.....
Через несколько часов работа закончилась...
Исправленный раздел (или оба? не помню) даже не монтировался.
Бэкапы? Какие бэкапы, с трудом семьёй на один компьютер накопили, ругались за объём диска и памяти. В общем, п.. привет. "Всё, накопленное непосильным трудом...".
В агонии снова запускаю PM beta, выбираю те же разделы и по памяти "все константы" забиваю обратно. Размеры кластеров, размеры разделов...
Запуск.
Несколько часов агонии...
....разделы вернулись, файлы вернулись, и даже с данными.
В чём бы ни была ошибка, она оказалось симметричной и при обратном преобразовании себя скомпенсировала.
Иногда beta - это в самом деле beta.
Как говорится, зашел написать этот комментарий, а тут уже. Только в моем случае был не скучный Partition Magic 4.xx, а модный 5 beta. И конечно же он завис посередине работы. Далее, все точно так же, как у тебя. "Бэкапы? Какие бэкапы, с трудом семьёй на один компьютер накопили". И конечно же послезавтра надо было сдавать курсовую.
Но твоя история менее драматична. Мне пришлось курсовую переписывать с нуля. Может быть восстановить разделы и можно было, но моего тогдашнего опыта не хватило.
Но вот пришло NTFS.
Давно использую полочники под бэкапы и файлпомойки. Одно время использовал салазки, вещь удобная. Но в какой-то момент у меня оказалось два типа салазок с различающейся распайкой разъёмов. Как-то в запарке перепутал салазки, да ещё и воткнул, не выключив комп. Точнее, выключАл, но он как раз был выключен — так что включился. Именно диск с бэкапами.
Далее обращение в контору по восстановлению, поиски донора, перепайка головки с донора и перенос на третий винт силами этой конторы.
Результат: вся информация чуть-чуть съехала по сравнению с оригиналами. Файлы начинаются где-то с середины и продолжаются на следующих. Причём сдвиг этот плавающий.
С тех пор первым делом выключить комп, и проверить, что он выключен — вколотилось намертво. И делать два бэкапа минимум.
После восстановления электричества все данные… оказались на своём месте, как будто процесс и не запускался. Повторный запуск прошёл успешно, спасибо правильным программистам Partition Magic'а.
Возможно, Partition Magic просто предварительно дефрагментировал данные, что вроде более безопасно в плане отключения электричества. Поэтому просто повезло.
Это я к тому, что я как раз однажды имел счастье убить систему Partition Magic-ом. Вроде даже история похожая была, что во время слития (или разбивки) разделов электричество отрубили, или он сам завис, я уж не помню. В общем, обратно он уже не загрузился. С тех пор операции на системном разделе всегда обхожу стороной (да и вообще стараюсь не играть с разделами)
А сейчас без привычных инструментов по работе с разделами как-то грустно. Склонировать систему, перенести с hdd на ssd, прочитать данные с сыплющегося диска, восстановить удалённые файлы — ручками в Norton Disk Doctor'е за ночь — как-то уже не хочется, да и объёмы данных увеличились на несколько порядков.
Вспоминается восстановление около тридцати небыстрых компьютеров на XP после Пети — XP весит 1,5 ГБ, с обновлениями — 5,5 ГБ. Если бы устанавливал заново на каждом компьютере систему и обновлял — наверно до сих пор бы не закончил. А так рассортировал лицензии на три несовместимых типа, установил/обновил по одному экземпляру каждого, потом склонировал и активировал все экземпляры.
Так что спасибо творцам правильного ПО, благо сейчас есть качесвенное в т.ч. бесплатное.
Везение — хорошо, но лучше пусть как у белочки — забытые схроны по лесу на зиму — бекапы, чем уверенность в непогрешимости оборудования и своих действиях.
в Norton Disk Doctor
Вы хотели сказать "в Norton Disk Destuctor"? Если есть русскоязычные файлы/папки, и NDD стартует с загрузочной дискетки без указания 866-й локали через coutry.sys (весьма нередкий случай), то потом придётся долго разгребать кашу.
Ну и ради занудства: ndd файлы не восстанавливал - для этого был или de (Disk Editor, для очень запущенных случаев), или unerase (для более традиционных).
Вспоминается восстановление около тридцати небыстрых компьютеров на XP
Ну, я в этой ситуации использовал unattended install с внедрением обновлений, и просто ставил на всю толпу одновременно - по времени не сильно дольше, чем восстановление после клонирования. Хотя XP вполне неплохо переносила и клонирование (главное - до введения в домен копию снять, чтобы ID машины сменился, ну и активация - в самом конце).
QU и UD тоже активно использовал.
Клонированием активно пользуюсь, особенно выручило во время восстановления после Пети, ~30 компьютеров с XP устанавливать систему и вручную обновлять было бы весьма уныло.
Рекорд моей ошибки - $74000. Ошибся тегом на image'е в workflow.
солидно
А как рассчитали?
Баг приводил к постоянному перезаписыванию одной страницы EEPROM (но только при определенном стечении внешних условий) и соответственно после выработки ресурса циклов — ой. Блок тупо не стартовал, обнаружив ошибку контрольной суммы памяти.
В итоге — возврат по рекламациям где-то полутыщи изделий продажной ценой около 12 тыров. В долларах по тогдашнему курсу получается в районе $50 000. Плюс разные накладные расходы — например на высылку новых в замену…
Фигак-фигак и в продакшен. За 15 минут до окончания рабочего дня. Сервис стартует и минут через пять виснет наглухо. Админ ворчит но откатывает. Проверяю - все чисто. Выкатываем, пять минут - все висит. Начальник админа нехорошо смотрит. Откатываем. Начинаю по одному вычленять изменения - все чисто. Выкатываем. Пять минут - виснет наглухо. Админ, начальник админа, мой начальник и случившийся неподалеку ДБА смотрят уже совсем нехорошо. В общем оказалось что безобидныя строчка вставки джаваскриптовой библиотечки, нужная только на проде и потому в спешке не попавшая в релиз после теста, была нужна для некоего внешнего сервиса (вроде какая то статистика для маркетинга). Внешний сервис обращался к ней в прямом эфире, и не получив ответа принимался ддосить сервис со страшной силой. Через пять минут все ноды оказывались забиты наглухо его запросами и балансировщик рапортовал что у него всё. В итоге отделался штрафом и выучил что такое переменные окружения.
В итоге отделался штрафом и выучил что такое переменные окружения.
ого, а гдейто так штрафуют? (я бы сразу оттуда уволился) у вас какая должность была?
у меня в памяти есть куда более жесткие факапы (не сколько мои личные, сколько всего отдела и организации работы) когда из-за неудачного деплоя, миграции или апдейта рушился крайне чувствительный онлайн… рекорд длительности факапа который я видел — простой карточного процессинга 8 часов… вот это *опа так *опа была… в которую даже я сам влипнуть успел с пустым баком бензина на полдороги до работы и с одной банковской карточкой в кармане… которая не работает потомучто онлайн упал…
и ниче, никого не расстреляли, даже премии не лишили… с тех пор всегда или описываю или держу в уме план отката вплоть до пожара в серверной
То есть был ддос от внешнего сервиса, а виноват оказался программист? Отличный подход, главное есть на кого штраф повесить!
Я не встречал такой коллекции хождения по граблям у одного человека (даже у себя), но я или мои коллеги с которыми я работал, вместе прошли, кажется, по всем таким же граблям (или очень-очень похожим). Ну и еще по другим граблям, конечно.
Насчет "Попытался быть умней пользователей" и форматов телефонов. Как-то в бытность в банке мне пришлось покопаться с КЛАДР (кто не застал - это раньше была такая всероссийская база адресов всей страны, сейчас заменена на что-то более новое), так каких только странных адресов там не было - типа дома без улиц и улицы без городов и все такое и все это были полностью валидные адреса, где живут люди.
У нас в промзоне был адрес типа такого: "Московская обл., Ленинский район, близ дер. Рубцово, тер. 2475, д.9-11/3, корп.15, стр.2, лит.Б, п.4, эт.2", без кабинетов. И это был юридический адрес фирмы, реально совпадающий с фактическим, но вот ни один навигатор нас не находил - всем доставщикам приходилось объяснять, куда ехать по ориентирам на местности, из серии "едете по обводному шоссе до плаката ЛДПР, сразу за ним - направо, после водоёма слева увидите съезд в лес, направо - по этому съезду до проходной, затем держась правой стороны до здания с большой надписью "47" на торце, ..."
Судя по тому, что на этом плакате кроме четырёх букв больше ничего не было, и висел он, постепенно ветшая, пару лет, похоже, он был бесхозным, да и наши мимо него постоянно ездили, в итоге, когда стойку плаката демонтировали, пришлось придумывать другие приметы - "полтора километра после строительного рынка", "метров 100 недоезжая магазина Пятёрочка" и т.п.
Я к чему - подобные адреса - совсем не единичные примеры, ломающие логику любого геокодера или валидатора.
— «У семи программистов адрес без дома»
Также были похожие
«Заблуждения программистов об именах» (людей)
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
А не хотел я это удалять, потому что однажды закоммитил секретный ключ в репозиторий, и потом имел радость с BFG. Было здорово, но больше не надо.
В наше просвещённое время есть великолепный git filter-repo. Удалить коммит там проще пареной репы:
git filter-repo --commit-callback 'if commit.original_id in \
[b"<commit hash 1>", b"<commit hash 2>"]: commit.skip()' Для секретов AWS есть git-secrets. Наверняка и для других что-то подобное уже запилили.
Ъ по ссылкам не ходят? :)
С главной страницы BFG.
Removes large or troublesome blobs like git-filter-branch does, but faster. And written in Scala
filter-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 ещё не существовал
Будучи на первом году работы, попала мне задачка настроить сетку на удаленном сервере (прод платежной системы). Как так вышло что новичку поручили такую задачу оставим за рамками)). Процедура настройки по классике проходила ночью, пока все клиенты спят. После успешно выполненых манипуляций нужно было применить изменения через рестар сетевых интерфейсов (командой ifconfig eth0 down && ifconfig eth0 up). Довольный, что выполнил все по инструкциям я ввожу команду в консоль но по невнимательности ставлю один амперсанд, тем самым положив сетку и не подняв ее. Это была самая длинная ночь в моей жизни, с попытками достучатся до поддержки серверной, чтобы они с помошью клавиатуры и монитора подняли сетку (доступа по резервному каналу у меня небыло).
Как в итоге решилось?
В 5 утра смог таки разбудить сотрудника серверной, который сонный с клавиатурой, дежурным монитором и моими инструкциями о внешнем виде нашей железки пошел искать сервер, и поднял интрефейс сетки. Руководство о фейле узнала утром, после кучи обращений в техподдержку от пользователей, которые пыталсиь провести оплату ночью. Отнеслись к факапу с пониманием.
У меня был точно такой же факап. Только я был джуном и даже не задумывался об амперсантах. Жму down, смотрю как меня отключает, в голове начинает зарождаться понимание всей ситуации.
Правда это был staging, и достучался я до сапорта только через 3 дня
ifconfig eth0 down && ifconfig eth0 up
Как показал мой собственный (печальный) опыт, решение так себе. Если во время работы первой команды или сразу после неё интерпретатор словит SIGHUP, то будет так же больно. Защищённый от этого вариант --
nohup sh -c "ifconfig eth0 down; ifconfig eth0 up" &Точка с запятой тут для перестраховки. Амперсанд в конце, на самом деле, и не нужен, ставлю по инерции.
Спасибо. Настроение в конце рабочего дня прям поднялось. Не один я такой...
Орнул в голос)
Раз уж тут такие откровения пошли, то...
Подфрилансивал я как-то одной из своих предыдущих работ. Обнаружился баг в мобильном приложении, которое предназначено для активного фотографирования во время работы. Фотографий за день делается сотни. При отсутствии сети приложение не отправляло некоторые из фотографий на бекенд, и при появлении сети не пыталось повторить попытку отправки.
Вроде баг не очень сложный, на основной работе напряг, так что не сильно долго сидел над задачей, поправил, потестил — начало улетать. QA тоже потестили и проблем не нашли. Выкатили в релиз на 30% пользователей на выходных.
Настал понедельник. В 9:30 утра звонит начальство из того проекта. Вообще впервые, чтобы звонок, да еще и без предупреждения. Я напрягаюсь, оказывается, не зря. У них там легло вообще всё. Все сервера для всех клиентов. А ничего, кроме моего приложения, после последнего рабочего дня не менялось. Я судорожно начинаю перебирать в голове, что должно пойти не так, как я приложением умудрился такое сотворить. И тут до меня доходит.
Из-за бага, который я исправил, все зависшие когда-то фотографии вдруг ринулись выгружаться. За несколько месяцев у некоторых пользователей на устройстве их могли быть тысячи. А каждую фотографию надо не просто получить, а и обработать определенным образом, что занимает на сервере десятки секунд порой. Из-за этого нагрузка не сервера подскочила в разы, если не на порядок, и они перестали этот не прекращающийся поток фотографий вывозить. И это только при 15-20% обновившихся пользователей.
Благо, среагировали быстро, релиз не был раскатан полностью, поэтому распространение через Google Play легко остановили, на бекенде поправили тригер обработки неактуальных фотографий, а я по-быстрому запилил хотфикс с дропанием фото старше пары дней из диска и локальной БД (так как они все равно уже не нужны). Стресанул я тогда знатно, но мне ничего не предъявляли по факту, так как пропустил это не только я, а и тестирование, и бекенд не сумел заскейлиться или правильно организовать разросшуюся очередь фотографий.
Еще это, наверное, должно было порядочно высосать трафик у пользователей на рабочих устройствах, где он часто лимитирован. Но на это вроде не жаловались, или жалобы ко мне не дошли.
Да, серьезные факапы.
Из косяков, что сохранились в памяти:
Решил в программе почистить за собой временные файлы. С подкаталогами. Написал красивую рекурсивную функцию. Должна была начать с текущего каталога. То есть с каталога где лежит сама программа. Дело было ВУЗе в единственном на то время компьютерном зале. С вин95. В общем, удаление началось с корня диска С. После минуты ожидания запущенной в отладке программы почуял неладное и прервал выполнение. Это не спасло лаборанта от переустановки винды.
Где-то через месяц лаборанты сдались и поставили NT4.0 на все ПК :)
Ещё один обидный фейл. У друга при обновлении кажется ХамелеонКлок, потерялись все напоминалки, и в том числе самые важные - о днях рождениях многочисленных родственников.
В общем, этих случаев мне хватило чтобы думать что делаю, и что делать если не получится. Бэкапы, ещё раз пооверить бэкапы, загрузочные, установочные, разнообразные утилиты... Создание своих установочных...
Даже жаль что сейчас все почти само работает :)
Ещё один совет услышанный от умного админа: работать без корзины. Удалять всё что не нужно сразу. Тогда перед удалением подумаешь пять раз - точно это не нужно? И с лёгкостью - Shift+Del (в TC убрана галочка "запрашивать подтверждение")
Насчёт последнего как-то спорно.. добровольно лишать себя права на ошибку. Ради чего?
Вообще, такие, слегка снобские "советы" вызывают двойственное чувство относительно их дающих - с одной стороны, "я такой суровый самурай, пять раз думаю прежде, чем удалить, и вас поучаю этому." С другой стороны - а без топора, занесенного над головой, в виде отключенной корзины, был бы я таким же самураем? Или только это, мной же созданное ограничение, и заставляет меня думать?
Напоминает добровольный отказ от каких-то благ цивилизации, ради мнимой крутости или "трушности" или ещё каких-то своих идеалов (типа как писать код в блокноте, а не в IDE, пользоваться кнопочным телефонном вместо смартфона и тому подобное)
Ubuntu же ещё с бородатых времён умеет в LVM, то ли с 9ки, то с 11ой ставила её по-умолчанию при чистой установке. Даже и сейчас имеет эту опцию. Так вот там есть снапшоты и можно замораживать состояние системы перед её обновление чтобы в случае чего откатить.
Я работал в банке и один раз попросили удалить загруженный рейс с платежами, поступившими из ЦБ. А в Мск была рейстовая система. 5 рейсов в день. В одном рейсе несколько файлов обменов с ЦБ. Удалить входящие документы и загрузить заново это просто. Но я умудрился удалить вообще все данные рейса. В том числе и отправленных платежей. Учитывая жопу с идентификаторами связки платежей в банке и ЦБ, пришлось делать откат БД на ближайшую точку восстановления и догонять всё из разных систем (банк клиент, доки из ЦБ, ручные документы, всякие системы переводов типа Контакт, вестерн Юнион и тп.). В итоге банк стоял часа 3 и не мог работать, пока всё не восстановили. А платежей в рейсе я удалил на 500 млн. рублей...
Решил я заархивировать старые файлы артефактов ML на Google cloud. Что то пошло не так и я сжёг 20000$. Всё было согласовано с лидом устно. С менеджерами выше говорили долго и в итоге все щамчли .Деньги гугл вернул. По мои расчётам сумма должна была быть около 2к баксов.ББыла ли это моя ошибка или ошибка биллинг а гугла я не знаю.
Читаю статью и про себя ухмыляюсь, потому что блин, всегда радовался что я предусматривал подобные вещи.
Наверное потому, что кроме работы у меня было в юности хобби администрировать разные игрушки (были и по 10 онлайна и по 100 и по 100.000), и наверное большинство фейлов отработал на них. Понял и смысл бэкапов и целостности бэкапов и логов и вменяемых логов с полезной информацией, и вменяемых логов с полезной информацией и стандартизированным форматом, который потом легко читать, анализировать, закидывать в разные системы (ну или банально перлом парсить).
И как-то так вышло, что на всех работах фейлы были минимальны, зачастую даже прям за день до потенциального фейла предусмотрительно готовился, и проносило.
Так что опыт, неважно на чем - это опыт
5 вхождений слова "говно".
Блин, но как можно делать систему учета чего-либо без хранения истории перемещения товаров или вообще не знать об индексах БД? И при этом "работать над проектами". Мне кажется, это когда вошли в ИТ сразу мимо изучения теоретической базы. Именно такие "профи" и возмущаются потом вопросам по базовым алгоритмам на собеседованиях.
Потому что они реально нужны в 0,1% случаев и есть всегда более полезные по применимости технологии, которые можно выучить вместо них.
Обратился ко мне знакомый знакомого, очень просил помочь, типа у него бизнесс стоит и т.д. Короче -- у него был хитрый калькулятор зарплат по ЕС, огромная база данных, все дела. Думаю ладно, самому интересно, гляну что у него там. А проблема простая -- всё очень медленно и чем больше данных (клиентов, стран и т.д.) тем медленнее. Получаю доступы смотрю а там -- php и $всем_известный_фрэим_ворк. Я, какбэ, сразу говорю человеку -- с этим г. не работаю, но он не отстаёт, просит. Короче почитал я исходники модуля, ничего не понял и полез структуру базы смотреть... А там.... короче накинул я 2 индекса и всё заработало в 120 раз быстрее. Клиент доволен, я решил вопрос за 30 минут и тоже доволен. Но! Кто-то написал реально сложный модуль, с кучей формул, с кастомной админкой, но не знал про foreign key...
Но! Кто-то написал реально сложный модуль, с кучей формул, с кастомной админкой, но не знал про foreign key
«да они тут по всюду!!» (с)
по опытам собеседований других людей пару лет назад, я уж незнаю из-за курсов это или вайтишников, SQL сейчас знает всё меньше и меньше народа… фразу 'а зачем это знать если есть ORM?' я все чаще и чаще слышу… и это печально
а вы тут про индексы
Мдя, печально всё это...
В бородатые (2005 примерно) годы работал я в одном Медиа агентстве, пилили сайтики для клиентов. Руководство наняло нам в отдел DBA менеджера, я недоумевал -- зачем, мол, я и сам на сиквеле любой запрос накатаю... Так и работали, я пилил сайты, парень что-то там с базами шаманил. И вот случился у нас завал -- паралельно 2 проекта, ничего прям сильно сложного, но срочно и оба сразу. Я погряз в работе, уходил из офиса в 10 вечера. И тут мне этот парень говорит -- а давай ты один проект сам закнчивай, а я всю логику второго на себя возьму. Я говорю -- как так, ты что програмить умеешь? Он отвечает -- я всё на хранимых процедурах в БД сделаю, тебе только функции дёргать надо будет. Так и сделали, всё успели, всё работало как часы. Я с тех пор зауважал этих ребят :)
Он отвечает — я всё на хранимых процедурах в БД сделаю, тебе только функции дёргать надо будет. Так и сделали, всё успели, всё работало как часы.
я видел одну банковскую систему так написанную, был тоже крайне впечатлен.
потом это правда превращается в дичайший ад с поддержкой, потому что найти такого супермена сложновато еще в те времена было
На заре карьеры писали мы интерфейс POS системы с расчетной системой. Там POS генерил файлики, а расчетная система их обрабатывала и изменяла балансы счетов. Мне начальник поручил проверить апдейт интерфейса. Ну я файлики покидал, посмотрел, что в расчетке балансы меняются, сказал "ок, работает" и апдейт отправили клиенту. На следующий день выяснилось, что работать-то он работает, но при внесении средств через POS баланс клиента в расчетке уменьшался, а не увеличивался (со знаком промахнулись, ага). Меня не распяли, несколько проводок откатили, перед клиентами извинились. С тех пор не берусь тестировать то, что не понимаю, как должно работать.
Интересно, а где все те ошибки от неприменения Solid, от использования ОП вместо ФП (или наоборот), от выбора неправильного ЯП, от неудачного нейминга переменных? Неужели люди зря придумывали все эти аббревиатуры?
Один раз хотел изменить оунера для файлов в каталоге, рука дрогнула и полетела команда `chown -R root:root /`. Я сразу косяка не заметил и отключил свою SSH-сессию. В итоге заново подключиться не удалось никому, так как системе не хватало прав на создание временных файлов. Самое неприятное — это было в канун моей свадьбы… Сидели с лидом до 3х ночи пытались залить веб-шелл через форму для файлов на проекте :-) Но не помогло. А утром я пошёл в ЗАГС.
В итоге ничего особо страшного не произошло, приложение себе крутилось несколько дней, клиенты даже не заметили ничего. Если я правильно запомнил — админ связался с работниками датацентра с другого континента, которые имели к серверу физический доступ, и они всё исправили.
Второй косяк был гораздо неприятнее. Разрабатывали интернет-магазин для крупного магазина брендовой одежды (с сумочками по $20k и платьями по $8k). И я на прямо на проде во время апгрейда на новую версию хотел удалить логи, но забыл, что сменил текущий каталог. Удалил 12.5 Gb фотографий (общий размер был около 100 Gb). Быстро среагировал на то, что как-то слишком долго логи удаляются и нажал CTRL+C.
Сразу пошёл к админу спрашивать про бекапы. Оказалось последний бекап был в марте, а на дворе октябрь…
Пришлось идти к клиенту на поклон. Для них фотографии один из основных инструментов продаж, так как магазин — дочка очень популярного журнала мод.
Эта история научила всегда запускать `pwd` перед любыми действиями типа mv, cp, rm, chmod и т.д.
Очень помогает нормально настроенный шелл. Например, через oh-my-zsh. И на проде цвет там поменять, другое приглашение сделать, чтобы не ошибиться.
Удалил 12.5 Gb фотографий (общий размер был около 100 Gb).
Вообще-то не звучит как критическая ошибка, делаем снепшот виртуалки или диска, или даже тупо dd диска куда-нибудь. Можно для надёжности перевести ФС в read only, если это не сломает ничего для клиентов. И потом разудаляем файлы в клоне или дампе. Потом заливаем обратно. Конечно, многое зависит от используемой ФС, и возможности быстро сделать снепшот или дамп.
Мы о разных вещах говорим. Удаление файлов с помощью rm, как правило, не означает их полное удаление (если только звёзды особо неудачно не сошлись), и при наличии прав чтения блочного устройства их можно попытаться прочитать.
Насколько помню — им пришлось убирать товары из продажи, а потом искать во внутренних источниках. А для тех что не нашлось — писать поставщикам или заново фотографировать.
это старый, но всеми любимый метод)
ППА - программа поддержки авторов (с) Хабр
Много лет назад ещё будучи студентом пришёл в небольшую фирму. В первый же день, разбираясь в системе, случайно очистил какую-то табличку. Кажется просто условие where ещё не написал, а запрос уже отправил. Первая мысль была тихо взять вещи, убежать и никогда не возвращаться. Справившись с этим порывом, начал разбираться, как можно исправить. Пока разбирался, пришёл крон и пересчитал все очищенные данные :)
Год назад обнаружили что высоконагруженная система поиска авиабилетов из 30 golang-микросервисов стала регулярно упираться в таймлимит на 99ом перцентиле. Решили разбираться, а не тупо поднять таймауты, потому что в таких вещах сегодня 99ый , завтра 95ый, а послезавтра 90ый, а это уже очень плохо. Потратили несколько недель меня и ещё одного разработчика, обнаружили узкий сервис, перетряхнули все горутины, отпрофилировали pprof'ом, устранили перемещение данных при изменении размера слайсов, залезли в сетевое взаимодействие... Стало лучше, но не сильно. И тут я вспоминаю, что при интеграции новой клиентской по отношению к нашей системы, я забыл передать флажочек, настраивающий фильтрацию длинного хвоста из неконверсионного ассортимента.
В общем, количество ошибок обратно пропорционально опыту. Но при этом цена ошибки прямо пропорциональна ему :)
Спасибо. В 2019 году я совершил довольно дорогую ошибку, после чего не мог собраться весь следующий год. Оказывается, я ещё не так плох. А, судя по комментам, многие специалисты просто скрывают свои ошибки. Этот пост поднял мою самооценку.
Тоже расскажу о паре случаев. Не прям уж факапы, но около.
Первый:
Вечер пятницы, август, мы с шефом задержались на работе "подтянуть хвосты". Делаю выборки из базы и она, вдруг, ложится. Потом снова поднимается, потом опять ложится... Шеф шлёт меня в "серверную" (чулан под крышей) На месте я слышу, как винт с базой то стартует, то останавливается со случайными интервалами. Останавливаю сервер, лезу внутрь, думаю "питание отошло". Выдёргиваю Molex из HDD и в разъёме остаётся пин +12V! Треснул каким-то чудом, а я его окончательно добил.
А у нас по выходным репликация биллинговых баз с 17-ю городами.
А в отделе ни одного паяльника (программисты аппаратные проблемы не решают :))
Звоню шефу. Он говорит: "Хватай винт, беги в подвал и по дороге надейся, что КИПовцы такие же трудоголики как мы. Обещай им пива и рыбы сколько влезет." Лечу семь этажей вниз, мужики действительно ещё на месте. Пин припаяли, репликация была спасена, шеф незамедлительно обещание сдержал. Ну и мы с ним присоединились, пятница же.
Второй:
"Сердцем" нашего биллинга была хранимая процедура T-SQL размером около 1500 строк. Многие из этих строк были длиной в три-четыре экрана. Ни одного комментария. Куча копипаста. Плюс, часть бизнес-логики вообще реализовывалась в клиенте!
Каждому новому программисту в отделе в качестве "проверки на вшивость" выдавалась задача разобраться в устройстве этой хранимки. Многие "горячие головы" сразу же обнаруживали явные баги (неправильные округления, ошибки при копипасте etc.) и лезли их исправлять. Разумеется, вся база после этого ломалась, т.к. эти баги компенсировались контр-багами в клиенте и в данных. Делалось всё это, конечно, на тестовом сервере, во избежание. Над новичками незлобно посмеивались и говорили, что они прошли посвящение.
Меня сей позор миновал в силу природной лени и осторожности: перед тем, как что-то делать, я начал задавать вопросы: "А почему здесь именно так?" и "Почему именно так до сих пор?"
Моему "младшему" задачу видоизменили: не только разобраться, но и переписать на Perl. Справился "на славу". Надо было видеть глаза шефа, когда уже 300-строчная программа выдала тот же результат, причём ощутимо быстрее. А в коде оказались аккуратно перенесенные баги оригинальной хранимки, при этом педантично помеченные комментариями. Я в итоге "раскололся", кто младшего надоумил. Но уточнил, что вопросы по багам он задавал всё-таки по своей инициативе.
Делаю выборки из базы и она, вдруг, ложится. Потом снова поднимается, потом опять ложится.
На месте я слышу, как винт с базой то стартует, то останавливается со случайными интервалами
кстати мораль — использовать серверное железо и вообще RAID для базы
кстати мораль — использовать серверное железо и вообще RAID для базы
Хорошо бы, но вместо бюджета отдел АСУ обычно получал бесплатные билеты в "пешее эротическое".
"Зачем вам вообще сервера? Вон 10 лет назад база в FoxPro на рабочей машине программиста стояла — и ничего!.."
Начало 2000-х, контора с пост-советским стилем управления во всей красе. Выкручивались как могли.
хранимая процедура T-SQL размером около 1500 строк
…
Ни одного комментария. Куча копипаста
…
Над новичками незлобно посмеивались и говорили, что они прошли посвящение.
И что, после вот этого никто из «горячих голов» так и не удосужился пометить сомнительные места комментариями, да хотя бы отрефакторить код, чтобы избавиться от копипасты (ладно-ладно, ну хоть банально нормально отформатировать код, чтобы не было ужаса со строками на три экрана в длину)? Уверен, ту хранимку тоже можно было бы ужать до 300-х строк (возможно, вынеся часть логики в хранимки поменьше). Ведь здесь же в конечном итоге всё получилось:
300-строчная программа выдала тот же результат … в коде оказались аккуратно перенесенные баги оригинальной хранимки, при этом педантично помеченные комментариями
Как запал проходил, в эту хранимку по собственному желанию лезть уже никто не хотел. И в режиме постоянного цейтнота выбить рабочее время на рефакторинг было практически нереально. "Работает — не трогай", так оно и тянулось пока не начало совсем сильно мешать. Почему и сделали в итоге. И то "с боем", шефу постоянно сверху задавали вопросы вроде: "Чем там у тебя твои программисты занимаются? Какой ещё рефакторинг? Пусть работать идут!"
Но ведь в процессе разборок наверняка же не в один присест это всё делалось. Сначала форматирование, потом простое переупорядочивание кода для более комфортной с ним работы, добавление комментариев к непонятным частям кода, выделение общих кусков в отдельные хранимки, аккуратное исправление первой ошибки, второй, третьей… с фиксацией каждого шага в mercurial, разумеется (так бы поступил я). В результате даже если в итоге всё сломалось, первые три-четыре шага всё равно можно оставить, так как логику работы они не меняют. Или там головы были настолько горячими, что даже про систему контроля версий не слышали и на живую всё правили?
Ни Mercurial, ни Git тогда ещё не существовали. Subversion и багтрекер (Mantis) ввёл я, под общее: "Зачем нам это усложнение? Всё ж нормально работает!"
Дикие времена были, как вспомню — так вздрогну.
На мой вопрос: "А где у вас хоть какая-нибудь проектная документация?" мне ответили: "А нет такой и не надо. Если что непонятно — спрашивай". :)
Так что совершенно не удивительно, что новоприбывшие бросали бесплодные попытки разобраться в коде самостоятельно и включались сами в порочную систему.
Самый эпичный провал был месяц назад с Django, настраивая фоновую задачу в селери без указания времени только лишь с днём. В итоге за час запустилась прорва задач и упал прод. Сознался без проблем, санкций не было. Профит в том, что добавили метрики к менеджеру очередей.
Однажды удалил базу данных. Дело было так: попросил админов сделать тестовый стенд по образу и подобию существующего. Проверяю - все так, только зачем-то скопировали и тестовую базу на новый хост. Перед тем как дропать, проверяю заголовок ssh-сессии: я на новой тачке, база в localhost. Жму Enter и понимаю, что внутри ssh сессии - другая сессия, на старый сервер. База хоть и тестовая, но никаких миграций и пр. не было (дело было давно). Синьор сказал: "ну значит сейчас будешь выковыривать SQL по вызовам из кода и восстанавливать схему". Вроде, обошлось.
А в другой раз решил последовать безобидному совету IDEA. IDE подстветила два статических поля-pid файл и pid порт, как "convert to local variable". Я и предположить не мог, что это кончится тем, что оба объекта (предусмотренно задублированные, т.к. это было критично) будут собраны GC. И конечно уехал в отпуск на следующий день. Хорошо, что сеньор вовремя заметил задублированные инстансы, последствия не катастрофические (это была платежная система).
Вечер после ДР, разошлись гости по домам. И тут я навеселе вспоминаю, что офисные машины перевели в виртуалку, но бэкапы то не сделаны ни разу (квм, линух, вирш и все такое).
Захожу на сервер, останавливаю виртуалку босса. Пишу в строке для файла образа его машины, но не помню что за чем - файл архива сначала или что паковать. Ну, думаю, как в командах копирования - сначала что, а потом куда. Ну а если не так, то оно ж напишет, что файла то нету такого и ничего не сделает. Ввожу:
# tar czf ./boss.qcow2 ./boss.qcow2.tar.gz
Проходит несколько секунд и выводится ошибка - нету файла boss.qw2.tar.gz. Ага! Думаю я - надо местами поменять имена файликов в команде. А потом глядь - а файл с имеджем виртуалки занимает несколько байт вместо 100ГБ положенных ему! Ну кто ж знал, что тар сначала подготавливает себе будущий архив, а только затем проверяет - а есть ли обьект для архивирования!! И даже не спрашивает, а не перезаписать ли архив, а то файлик то уже есть такой.
Итого:
1) Посылаю лучи поноса авторам tar
2) После спиртного к сервера не лезу.совсем. ни за какие коврижки
зы данные у боса были некритичные, все заново нашли и сделали снова виртуалку.
Ну кто ж знал, что тар сначала подготавливает себе будущий архив, а только затем проверяет — а есть ли обьект для архивирования!
Однако, стандартное поведение для программ, которые принимают список аргументов.
Кстати, то что список аргументов произвольной длины идёт всегда в конце — тоже стандартно...
Но мне другое интересно — почему tar.gz, а не просто gz?
# Зачем вообще помнить все эти ключи и порядок аргументов?
< ./boss.qcow2 gzip > ./boss.qcow2.gz
# Или если всё-таки хочется зачем-то tar
tar c ./boss.qcow2 | gzip > ./boss.qcow2.tar.gz
# Хотя, я обычно что-то такое делаю (башизм):
< ./boss.qcow2 gzip |
tee >(
sha1sum |
awk -vV="boss.qcow2.gz" '$2=V' > ./boss.qcow2.gz.sha1
) > ./boss.qcow2.gz
# ибо бывали случаи с НЖМД, тихо жевавшими данные.
# Впрочем, в xz и zstd вшитая контрольная сумма уже не такая убогая, как в gzipЗачем вообще помнить все эти ключи и порядок аргументов
а потом удивляемся почему все не любят легаси
башизм это круто конечно, но крайне увеличивает эффект автобуса
я вот попал однажду в комманду (будучи админом еще) у нас лид был с многолетним стажем админста netware и на каждый чих писал километровые bat/sh файлы с крайне извращенным синтаксисом и функционалом
и разбираться в упражнениях программирования другого аднина потом было крааайне увлекательным занятием (нет)
особенно я прифигел когда пришлось дебажить sh файл на 20 страниц который как оказалось падал потому что внезапно (для меня тогда и админа того) оказалось что shell в солярисе и в линуксе совсем не одно и тоже и unix tools не полностью совместимы с линуквыми, хотя и tar какбы 'одинаковый' (нет) и прочие мелочи…
было прикольно видить совет для tar что для поддержки unicode имен надо 'всеголишт добавить ключ… помоему -u'… а его тупо нет версии тара для солярки… и мы спешно переписывали это портянку по новой
Я не погромист, но при моём участии EUR 38k контора в прошлом году потеряла. Есть у нас HPC-кластер на ~200 нод, но несколько лет в определённые моменты времени, пару раз в год, его стало не хватать инженерам, которые почему-то время от времени начинают желать считать намного больше. Для управления инфраструктурой кластера есть купленная софтина с удобным графическим интерфейсом, при помощи которой и сделали отдельный кластер на сотню нод в AWS (ну, как "при помощи"... с жуткими матюгами подняли всё, что нужно, вручную, и просто внесли правильные идентификаторы в софтину, потому что предлагаемый производителем визард настройки не работал сразу в нескольких местах). И вот весной, при очередном запросе от инженеров-проектировщиков, пытаюсь запустить эту сотню нод. Через несколько минут софтина говорит "Не шмогла!", не уточняя причину. В логах вызовов API AWS -- нехватка нод нужного типа (c5.9xlarge) в нужном нам датацентре. Плюясь, начнаю запускать их маленькими порциями по 20 штук, чтобы выяснить, сколько же имеется в наличии. К своему удивлению, запусаются все сто. Передаю всё это дело, и месяц эти страшные люди гоняют там свои LS-Dyna, Ansys и прочие магические вещи. Через месяц всё это с помощью той же системы управления выключается, но через пару дней обнаруживается, что мы продолжаем потреблять больше килоевро в день. Оказалось, что при первой попытке запуска нод месяц назад десяток-другой всё-таки запустились, но система управления этого не заметила. Они так и стояли запущенные без нагрузки в нашем аккаунте. Зато теперь есть лямбда, которая ежесуточно по почте сообщает о количестве запущенных нод.
Типичный Алёша
Была весёлая история -- пилил с коллегой в 4-е руки всю IT часть сервиса по доставке (сайт, админка, срм, пос-терминалы, боты, приложухи для клиентов и для персонала и т.д.). Ну и в пятницу вечером, маркетинг решает запустить рекламную акцию, запилили в админке, согласовали с нами и запустили рассылку push уведомлений для клиентов. А ана у нас jobam-и была, типа 50 воркеров и один главный, который всё это дело разруливает (sideqik, если что). Короче мы по логам посмотрели что всё идёт хорошо, воркеры отрабатываю, пуши падают, мы собрали манатки и пошли праздновать окончание пятницы... Через 10 минут мы, сидя в машине получаем те самые пуши, радуемся и едем дальше... Через 30 минут, мы, стоя в пробке получаем пуши ещё раз... Через 40 минут начинают разрываться телефоны -- звонит весь офис и спрашивает почему пуши не прекращаются... А мы стоим в пробке, ключи от сервера только у нас а мы без ноутов -- мы-ж тусить едем... Короче до компа я смог добраться только через 1,5 часа, за это время все 50k клиентов получили по 10-12 одинаковых уведомлений о нашей акции. По факту выяснилось что что-то заглючило в упровляющем воркере, а в базе телефонов был какой-то один глючный, на нём падал имполняющий воркер... И, управляющий вокер перезапускал всю задасу с начала :))) Пришлось его убить. А сы выжили, хоть и стыдно было цжасно. Но в тот вечер был даже превышен ожидаемый объём продаж, у нас очень лояльные клиенты :)))
Работаю в сфере e-commerce, и каждый год в Black Friday у нас весёлые истории случаются.
Расскажу про не свой косяк, но самый дорогой с финансовой точки зрения из тех, с которыми сталкивался.
Клиент на Black Friday попросил добавить в 5 уже существующих промо-акций купон «blackfriday», дающий скидку в 50% от цены.
Первые 4 правила имели вид:
if ALL conditions are TRUE {
- категория=X
- sku=1,2,3,4
}Девелопер зашел и дописал
if ALL conditions are TRUE {
- категория=X
- sku=1,2,3,4
- coupon=blackfriday
}А пятое правило отличалось. Там было что-то вроде
if ANY of conditions are TRUE {
- категория=X
- sku=5
}Дев с почему-то выключенным мозгом зашёл и дописал строчку
if ANY of conditions are TRUE {
- категория=X
- sku=5
- coupon=blackfriday
}Что сделало купон валидным вне зависимости от других условий.
Дальше задание пошло тестировщику, который в тексте задачи прочитал «Добавить скидочный купон для 5 продуктов». Ну он и проверил happy path, т.е. подтвердил, что купон действительно работает для 5 продуктов. Но при этом не догадался проверить, что купон НЕ работает для других продуктов.
После проверки happy path тестировщик написал клиенту, что всё готово, всё работает.
Владелец магазина со своей стороны запустил промо рассылку с описанием скидки на 5 товаров, а потом отключился (День Благодарения же, он в другом штате с родителями и семьёй сидел отдыхал).
А дальше… Кто-то из покупателей обнаружил, что добавление купона «blackfriday» даёт скидку не только на 5 товаров, как было в рекламной рассылке описано, но и вообще на все товары в магазине. Он зашёл на форум любителей оружия (магазин продавал оружие и различные аксессуары для него, вроде фонариков, прицелов и т.п.) и создал топик «В магазине XXX супер акция — 50% на всё!».
Короче говоря, скидка просуществовала с утра пятницы по середину воскресенья и принесла клиенту (по его словам) около $400 000 потери, которые он потом пытался через суд повесить на нашу компанию. Я точно не знаю, как они потом урегулировали вопрос. Девелопера уволили (говорят, что он в принципе косячил постоянно), с тестировщиком просто повогорили на повышенных тонах, он потом ещё года 4 у нас работал. Финансово ни девелопера, ни тестировщика не наказывали.
Было так много энтузиазма и рвения в 2008, на заре ИТ, что решил на нычку от начальства выйти в выходные и смигрировать эксч и ад. Думал все придут в понедельник, а я такой - нате, видите как я умею. Предвкушал, аж ладошки потели. В итоге легло очень большое и серьёзное ведомство. На неделю. Правда серьёзное. Тогда я узнал слова дизастер рекавери. Никто не ругал кстати. Намерения и мотив были типа хорошие)
Поставили задачу сделать уникальными коды магазинов в API крупной торговой сети. Проще пареной репы, но чтобы база данных не упала после миграции, нужно было удалить всё дубли на проде, о чем я заранее попросил бизнес-аналитика заказчика, а тот - контент-менеджера (у меня доступа в админку прода не было). Они отписали что всё ок, дубли удалены. На тестовом стенде код был протестирован, я будучи джуном ничтоже сумняшеся задеплоил правки на прод. Примерно через полчаса, занимаясь другими задачами, начал получать сообщения в чатах (до этого обратил внимание что подозрительно долго идёт деплой, но не придал значения в силу неопытности). API магазинов упало, контент-менеджер конечно удалил не все дубли. Хорошо что знакомый тестировщик, у которого был доступ на прод, всё быстро поправил, и я передеплоил правки. Ну и наш тимлид сразу поддержал, после начала паники просто перезалил предыдущий тег, а после удаления дублей залили актуальный.
Погромист. Мои самые эпичные провалы за всю карьеру