Из серии — Был у нас такой случай... IT-байка

упс

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
sleep(1000) в код обработки
Напомнило как при энтом перепрохождении фоллаута уже на новом компе приходилось его искусственно замедлять чтоб случайные встречи попадались.

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

лечение оказалось простым — sleep(1000) в код обработки и всех делов!
исходя из производительности приложений — так поступают все разработчики
многократно и регулярно

Если бы... Судя по потреблению ресурсов CPU, они даже про Sleep не знают, пустые циклы крутят.

for (int i = time(); i>RELEASE_TIMESTAMP; i—) {}; /* don’t forget to buy newer faster version */

Поддержу коллег. Виноваты в данном инциденте полностью Вы. Не важно почему произошла миграция. Было это из за устаревания оборудования и его не надежности, планового апгрейда или еще чего. В любом случае должно было быть проведено тестирование работы системы перед миграцией, особенно если эта система критически важна для работы бизнес подразделений. Так же должен был быть составлен план миграции в котором бы присутствовало какое то время тестовой эксплуатации во время которого принимается решение об откате,а так же должен быть план отката на случай внештатных ситуаций. Вы же, смигрировали систему и пошли домой спать, а когда оказывается что кто то проверил работу системы и она не работала Вы просто выключили телефон и сели решать проблему оставив все остальные подразделения в неведении сколько им еще ждать начала работы и когда все заработает. Хорошо что проблему Вы решили за час , а если бы нет. Если бы поиск и решение проблемы заняло 6 −8 часов, а это целый рабочий день ?

да это был не идеальный день в моей жизни, но я получил урок, может в этом и есть смысл ошибок?

С Вашей точки зрения возможно это так. С точки зрения бизнеса,простой системы — это потеря денег.

я им гораздо больше заработал, проглотили

если бы я не починил за час то министр юстиции уже бы вставил шефу, так что 6-8 часов это вы мне льстите

ты разве не читал — это была гос контора. чувак на 1000 гривен опыта набирался

это начало 2000, специалистов не было и задорого

Вы просто выключили телефон и сели решать проблему оставив все остальные подразделения в неведении сколько им еще ждать начала работы и когда все заработает.

Якщо не перекривати канали зв`язку, то час вирішення проблеми можна сміливо потроїти.

Хорошо что проблему Вы решили за час , а если бы нет. Если бы поиск и решение проблемы заняло 6 −8 часов, а это целый рабочий день ?

А якщо цілий день, то що?

Утроить или удвоить, это не важно. Важно то что человек привел к проблеме, героически ее решил и считает что так и должно быть и это смешная история. Я же скажу что это по меньшей мере не профессионально и вообще смахивает на то что я называю синдромом админа. Когда админ думает что его работа самая важная и все остальные подождут. На самом деле в компаниях которые потребляют ИТ услуги, ит подразделения — это сервисные подразделения которые работают для того что бы бизнес мог нормально функционировать и зарабатывать деньги. И любой простой приводит к убыткам , прямым или не прямым.
Из этого и ответ на Ваш вопрос, что произошло бы если бы система лежала день — компания получила бы убытки и эти убытки могут быть прямыми и не прямыми. Так вот прямые убытки еще можно посчитать , а вот не прямые посчитать сложно, потому что это могут быть миллионы долларов не дополученной прибыли. Тут конечно фигурирует гос предприятие и возможно простой системы был не столь критичным, но если брать в пример какую то финансовую компанию как например банк, то выводы о проделанной работе были бы не очень хорошие.

мы не обслуживали , мы зарабатывали на айти,
но там отложенные деньги, то есть простой не так важен финансово как морально был

я писал это не для того чтобы вас насмешить,
история просто поучительна

То что поучительна, полностью согласен.

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

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

Когда-то давно постил на ithappens.me, как саттелит башорга, но со временем даже собственные байки становились нудные и унылые, поэтому прекратил.

Вообще-то всё правильно сделали. Идиотизмом было парсить это поле в авторежиме в другие типы данных. Вот тех кто это делал — и надо было иметь чтобы как минимум исправили регулярку парсинга, а по-хорошему пользовали соответствующие поля базы.

Как решалась проблема: просто добавить счётчик. Изначально ставить счётчик двухразрядный было глупостью.

Как решалась проблема «шоб по быстрому»: тупо поменять генератор, разрешив в этих разрядах буквенные символы. Тогда это минимум увеличивает разрядность со 100 до 1236. Ну или действительно вписать правку скрипту чтобы подтупил при достижении счётчиком лимита. Это решение потом так же просто прищучить, когда нормальное решение оттестят на полигоне.

ЗЫ. Я так понял, это было в 2007. Только я почему-то уверен, алгоритм с лёгкими правками и по сей день работает в том же банке. Равно как и то, что такой банк не один и не два :)

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

у меня так и было, 13 лет жизни вложил и пшел на...

год н помню, это не в банке было, а во всех банках, это база была госреестра

иметь было некого, иных уж нет а те далече, знаете такое?

перекинул все ночью на новый сервер и поехал домой спать
Ржал вголос)
И почему не Sleep(10). Ну пусть 11, для надёжности?
Вообще топик с байками было бы интересно почитать, думаю и самому есть что рассказать.

как-то вот во всей байке слова «тестирование», «тест» не прозвучало :(

тестировать нечего, файлы базы скопировал и все

Один чувак сэкономил на нормализации, другой на тестировании )) оба два веселых гуся.
«А че такова?» © неизвестный гений ))))))))))

вы хоть DBA-шникам такого не говорите...

тестировать нечего, файлы базы скопировал и все
И ушел домой на всю ночь. А шо?

спать то надо, утром же обычно все вылазит

это мой первый опыт в написании баек, не судите строго, у меня еще есть историй...:)

А нельзя было этот счётчик увеличить до, например, 100 000? И сервак бы работал в полную силу и осталось бы что-то на следующий апгрейд.

мы потом рефакторинг полный провели

Да ладно, и деньги выделили? Это точно госреестр?
Оффтоп, кто-то знает какое-нибудь государственное некоммерческое решение, которое работало бы вменяемо?

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

Компилятор ТурбоПаскаля этим грешил.
Если не ошибаюсь, счетчик прерываний для функции Random() моментально переполнялся.
В свое время целая история была при переходе барьера 300MHz.

я так и думал что это системная ошибка

Ну и вообще, это не очень круто, считать дураками людей, которые написали работающую систему.

они сделали немасштабируемое решение, это дурость

Они сделали приложение которое работало. Поскольку его никто не переделывал, то работа приложения всех устоаивала. А вы сллмали его работу, это ваша вина.

мы его потом еще и переписали , перегнали данные в новую базу и тд

С таким подходом, лет через 10, прийдут другие ребята, скажут что вы неправильную базу использовали и не на том ЯП переписали.

Я это к тому, что не вижу реальной проблемы, у вас программирование ради процесса.

у вас программирование ради процесса.
Почему ради процесса? — больше работы — можно больше денег зарядить, а на фрилансе это важно.

Ну я хз, думаю что даже на фрилансе заниматься бесполезной работой долго не получится, пусть даже за деньги. Лично мне хочется чтоб моя работала была нужна и имела смысл.

вы читать умеете? говно было, мы его исправили, все

Вы сами написали что «говно» работало годами. Если оно как-то неправильно работало, то это один момент, и большой вопрос почему это не было исправлено раньше. Если все работало и всех устраивало (а мне кажется что именно так все и было), то зачем лезть и что-то менять?

план работ, смета, график, бухгалтерия, госпредприятие, какие из этих слов не понятны

ну ваще то это очевидно — проект не масштабируется, его надо переделать пока он новых сюрпризов не принес

Тут не в этом вопрос. Вы просто отключили старую систему, включили новую, но при этом ничего не проверим, и когда случилась проблема, героически ее решали, забил на пользователей. Хотя в этом случае, нужно было предусмотреть механизм отката, откатиться, включить старую систему, убедиться что у всех все работает и уже тогда дальше идти думать что могло пойти не так. У вас не тот подход. Сегодня сломалось это, виноваты «папередники», завтра еще что-то сломается, опять будут виноваты или «папередники», или соседний отдел, или заказчик, или фаза луны, хотя проблема возникает исключительно от ваших действий.

Ну и то что вы заказчика раскрутили на переписать все, тоже не очень круто. Я понимаю если бы вам нужно было раз в неделю лазить в систему и что-то править,а правки генерировали бы другие правки. Либо сильно изменилась бизнес-логика. Вы же решили просто переписать работающий продукт, просто потому что вы так захотели, при этом еще этим хвастаетесь.

Я бы прошел мимо, если бы у вас не было плашки «CTO», но вы типа руководитель, и такие нюансы у вас возникать не должны.

вы погодите фантазировать, сколько понавыдумал

да, не проверил на стейджинге, это первый раз такое было, я же софт не менял... не расчитывал на такое

откатывать дольше было бы, я за час управился

заказчик там был я, вы не поняли что ли? это мои базы, там делалось то что я считал нужным но согласно закона

откатывать дольше было бы, я за час управился
Из вашего описания могу предположить что достаточно было переткнуть сетевой кабель в старый сервер. Думаю это можно организовать несколько быстрее чем за час.
заказчик там был я, вы не поняли что ли? это мои базы, там делалось то что я считал нужным но согласно закона
Заказчик тот кто платит деньги. Вы сами себе платили деньги за то что переписывали свою собственную систему?

То что вы сейчас пишете, генерирует еще больше вопросов...

не проверил на стейджинге
Так кто у нас здесь буратино?

я перенес базу, она начала писать данные, и что мне делать было?

получить две разные базы и потом их синхронизировать с багами в сервисе обработки?

я перенес базу, она начала писать данные, и что мне делать было?

Реплікацію.

я дам совет — когда вы видите что система неадекватна то ее лучше выключить, ибо можно запороть данные в базе, тогда проблема из неприятной превращается в катастрофу

Если система работала 10 лет (условно), а тут приходит дядя Дима и говорит что система неадекватна, то лично у меня вывод однозначный.

Пока я услышал только одну причину почему систему нужно было менять

план есть план
и это полная херня.

Enterprise системы они такие)

это знает кто прохавал, а не тимбилдил в кюбикле

первое легко если умеючи
второе, это была система которую писали в 90-х, но судя по дизайну базы это элементарное невежество

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

скромность хороша для посредственностей ©

А разве в 90е годы не было известно проблем с запуском софта, написанного например в конце 80х?
По-моему тогда люди уже в курсе были, что завязывать функциональность на скорость работы компьютера — плохая идея.

он не думал про это, считал что «64к достаточно каждому», это искривление масштаба мышления

в масштабах страны мне удавалось

sleep(1000)
А зачем сервер меняли?

А если бы сервак просто сломался (мамка/проц/бп) и замены ему нет, а не «зачем»?

А если отопление прорвет и затопит новый сервер на ксеонах? Если стояла проблема резервирования, то в данный момент эта проблема не решена. Но в любом случае, эта проблема решается несколько иначе чем «переписать все нафиг».

резервирование там на уровне бекапа ежедневного было

это не резервирование — это резервное копирование
не называйте теплое — мягким

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