Страница 1 из 1

Хороша техподдержка в МТА...

СообщениеДобавлено: Четверг 01.11.2007 09:05
Алексей Чернышев
Привожу переписку с Айсином по поводу данных касс:
Айсин:
Добрый день!
В ходе проводимой проверки транзакций, в файлах, полученных от Вас за октябрь, были обнаружены следующие несоответствия:

- Нехватка данных. В этом случае Вам необходимо сформировать файлы за указанные дни и предоставить их в РЦ
ПСУ № 0950177702 - с указанного ПСУ не поступали данные с 04.10.07 по 25.10.07
ПСУ № 0650638225 - с указанного ПСУ не поступали данные с 04.10.07 по 25.10.07

- Задвоение данных. Прошу установить причину задвоений, заново сформировать файлы за указанные промежутки времени (отдельный файл за каждый день), предварительно убедившись в отсутствии задвоенных данных с вышеозначенных терминалов, и выложить их на фтп-сервер
ПСУ № 0650638225 - за 27.10.07
В ходе разборок подобных случаев, а таковые возникали неоднократно, было
установлено, что подобная ситуация возникает при нарушении технологии приема
и обработки первичных файлов.


Я:
Нехватка данных: файлы сформированы и выложены на ФТП
Задвоение данных: задвоенные данные дважды приняты с одного файла 0710270650638225.D01
Запись журнала приема
0710270650638225.D01 3 2007-10-28 09:04:00 Максимова МВ 2007-10-27 15:14:45.000
0710270650638225.D01 3 2007-10-27 16:21:00 Максимова МВ 2007-10-27 16:14:45.000
Файл с одним названием, расширением и фактическим временем создания принят дважды.
Второго файла с временем 16:14:45 не существует, ни в месте съема информации, ни в архиве принятых файлов и не могло и быть. Судя по всему ошибка связана с переходом на зимнее время.
Исходный файл с кассы прилагаю.

Айсин:
Я разве запрашивал у Вас первичку?


Я:
> Нет не запрашивали, а Вам неинтересно разобратся в чем проблема? мне тогда
> тоже, в следующий раз буду не думая запускать скрипт и удалять все дубли,
> благо база то у вас открытая...

Айсин:
В ходе разборок подобных случаев, а таковые возникали неоднократно, было
установлено, что подобная ситуация возникает при нарушении технологии приема
и обработки первичных файлов.


Я:
Ошибки будут всегда, пока в этом звене присутствует человеческий фактор... в данном случае произошел повторный прием файла с одним именем и расширением!!! чего быть не должно... возможно дата создания и переход на зимнее время сыграло какую то роль в этом. Да, проще свалить все на филиал и на нарушения неких правил, а не работать над надежностью самого програмного обеспечения, передача данных из модуля приема первичной инфромации до Каскада - это самое узкое место в программном комплексе.
Так для сведения - у меня файлы собирает скрипт, и это первый случай задвоения при его использовании. До этого задвоения возникали как раз при вмешаетельстве человека...

Re: Хороша техподдержка в МТА...

СообщениеДобавлено: Четверг 01.11.2007 09:21
Светлана Хорькова
Alex писал(а):
Айсин:
В ходе разборок подобных случаев, а таковые возникали неоднократно, было
установлено, что подобная ситуация возникает при нарушении технологии приема
и обработки первичных файлов.



Этими словами можно всегда прикрыть свою ....

Попроси их конкретизировать в чем было нарушение технологического приема и обработки файлов.

Re: Хороша техподдержка в МТА...

СообщениеДобавлено: Четверг 01.11.2007 09:30
Алексей Чернышев
Светлана Хорькова писал(а):
Этими словами можно всегда прикрыть свою ....

Попроси их конкретизировать в чем было нарушение технологического приема и обработки файлов.


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

СообщениеДобавлено: Четверг 01.11.2007 09:50
Леонид Сандал
Эх, Алексей, ну и тему вы открыли - искушаете сильно.

Смотрю регулярно "Вопросы-Ответы". Что я вижу? Бывает, конечно и так :AAA:. Но в большинстве случаев вот так :shock:

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

СообщениеДобавлено: Четверг 01.11.2007 10:10
Светлана Хорькова
Леонид Сандал писал(а): У меня дочка в этом случае показывает язык, примерно вот так :P. Вот что-то в этом роде, видимо, и происходит.


Если бы нам показывали только язык...

СообщениеДобавлено: Четверг 01.11.2007 13:33
Алексей Чернышев
Ну вот все как я и говорил:

А какие претензии ко мне, как к оператору Регионального центра? За
надежность ПО я не отвечаю. Я вам лишь указал на ошибку. Если б этого не
сделал я, к Вам предъявил бы претензии Объединенный процессинговый центр.

С уважением,
Айсин Р.Р.
ОВИТ УИ ГУП МО "Мострансавто"
тел/факс: (495) 650-07-86

СообщениеДобавлено: Четверг 01.11.2007 13:54
Леонид Сандал
Райкин:
Я говорю: ребята, кто сшил костюм? Они говорят: Мы! Их сто - я один. Все стоят так, как пуговицы, насмерть. Я сказал: привет, ребята, вы хорошо устроились!

Re: Хороша техподдержка в МТА...

СообщениеДобавлено: Четверг 01.11.2007 17:33
Леонид Сандал
Alex писал(а):Задвоение данных: задвоенные данные дважды приняты с одного файла 0710270650638225.D01
Запись журнала приема
0710270650638225.D01 3 2007-10-28 09:04:00 Максимова МВ 2007-10-27 15:14:45.000
0710270650638225.D01 3 2007-10-27 16:21:00 Максимова МВ 2007-10-27 16:14:45.000
Файл с одним названием, расширением и фактическим временем создания принят дважды.
Второго файла с временем 16:14:45 не существует, ни в месте съема информации, ни в архиве принятых файлов и не могло и быть. Судя по всему ошибка связана с переходом на зимнее время.


Судя по всему, специалисты, разработавшие и поддерживающие Каскад не в курсе того, что происходит со временем файла при смене часового пояса в Windows (например, при переходе на зимнее время). Соответственно о том, что временной штамп вкачиваемого файла следует хранить в терминах GMT тоже не ведают. И подсказки не принимают. Про защиту от повторного впучивания по иным основанием вообще молчу.
Обратите внимание, что такой казус может случиться с любым файлом, сформированном в периоде с предыдущего перехода на летнее время по минувший переход на зимнее - все эти файлы сейчас имеют иной временной штамп по сравнению с тем, который был до перехода на зимнее время (и который запомнил Каскад). Если такие файлы попробовать закачать, то пройдет на ура - в смысле закачаются и будет удвоение.

СообщениеДобавлено: Среда 07.11.2007 23:10
Мехти Ибрагимов
Вы как-то очень глубоко копаете, чем делаете незаслуженный комплимент СС. Какое, право, летнее время. Всё гораздо проще.
Мы обработали данные за 25 число - двадцать шестого. Потом, по недосмотру, те же данные обработали двадцать девятого числа. Эти данные были приняты Каскадом безоговорочно - в базе образовались полностью идентичные данные по поездкам - все отображаемые в отчётах поля совпали. Т.е. строго на каждую поездку сформировались внешне две полностью одинаковых записи. М. Грёмушкин поведал нам, что коли даты формирования файлов разные, то и данные, с точки зрения Каскада разные. А ввести проверку, с моей точки зрения, тупо, выброси из индекса дату формирования файла - и всё, - нельзя, это существенно усложнит алгоритм подкачки данных и, вообще, по техзаданию с СС не согласуется.
Вот убейте меня. Строите вы структуру таблицы в базе данных. Описали поля. Выходите из конструктора. Софт говорит вам
- "У вас не построено над таблицей ни одного уникального ключа, желательно это сделать. Сделать автоматически?"
Как правило, вы говорите
-"Давай",
и он, т.е. софт, естественно, строит индекс по всем полям таблицы. А если у тебя в таблице полсотни или больше полей, то тебе, тоже естественно, лень проверять какие из этих полей должны быть уникальны, а какие нет. И, ты, сдуру, не обращаешь внимания, что в индекс входит поле - дата, а то ещё и время (до микросекунды) приёма данных. Всё - все записи уникальны. Но кто ж в этом признается. Тем более аврал, тем более до поры до времени работает.
Да и кто посмеет требовать от СС программы защищённой "от дурака" - это ж плюс 25-30% трудозатрат, как минимум. Проще обязать все ПАТП вручную просматривать записи на предмет ошибок. И журнал приёма данных обязательно вести с росписями исполнителей. Михаил Игоревич так и сказал, что, по опыту работы, ведение рукописных журналов просто необходмо. Можно в стиле И.В. Сталина добавить, что с течением времени эта необходимость будет толко нарастать.

СообщениеДобавлено: Четверг 08.11.2007 12:24
Леонид Сандал
Мехти Ибрагимов писал(а):Вы как-то очень глубоко копаете, чем делаете незаслуженный комплимент СС. Какое, право, летнее время. Всё гораздо проще.
Мы обработали данные за 25 число - двадцать шестого. Потом, по недосмотру, те же данные обработали двадцать девятого числа.


Я копаю не глубоко, а ровно на штык лопаты. Алексей привел пример, из которого ясно следует, что суть проблемы заключается в том, что в качестве временного штампа файла берется так называемое локальное время, т.е. время, приведенное к часовому поясу, установленному в Windows на компьютере пользователя. Это свидетельствует о низкой квалификации разработчиков функциональности контроля повторной обработки файла, основанной на уникальности комбинации имя файла + временной штамп. Замечу, что в некоторых случаях такой контроль крайне полезен, если, конечно, правильно сделан - например, он правильно реализован в АвтоПарк - для поддержки однократного запуска автоматических конвертеров и контроля неизменности конвертера в будущем.

Но, конечно же, это цветочки и вообще не стоят внимания. Давайте воспользуемся любимым приемом М.Гремушкина, а именно - в ответ на указание очередной дыры в софте и/или в организационных вопросах, скажем, что есть еще такие (!) дыры, что то, о чем вы говорите - просто фигня. Вкратце можно сказать следующее:

а) Съем данных с валидаторов устроен безобразно. Транзакции, помогающие не дристать в данные, там, конечно, невозможны, однако, это не повод расслабиться. Наоборот, следовало применить специальные техники работы с данными, позволяющие получать информацию с высокой степенью надежности. Работа (вернее отсутствие всякой работы) со временем вообще ниже всякой критики - эти улеты в прошлое, будущее, равно как и попадание в безвременье - ужас! Видимо, авторы полагали, что в каждом валидаторе размещены идеальные атомные вечные часы? Ашипка.

б) Вкачивание в Каскад устроено чудовищно. Рассуждения о невозможности контроля повторных записей (раз уж входные данные столь замусорены) из-за каких-то невообразимых расходов на проверку уникальности записи - полный бред. Вообще-то следует стесняться говорить о таких "трудностях", особенно применительно к промышленному стандарту MS SQL. Почему-то в АвтоПарк, сделанном на коленке, такая проверка занимает две строки исходного кода + чисто умозрительное увеличение времени обработки.

На самом деле, modus operandi этих колхозников замечательно иллюстрирует очень веселящая меня ситуация - рассмотрим заезженный тезис того же автора о том, что "математика сделана под турникеты, поэтому надо спаривать записи о входе и выходе, поэтому вся эта лабуда закачивается два часа". Ексель моксель! Вот уже год почти, как нет (нет!!!) этих турникетов - почему же, блин, так трудно поставить условный оператор внутри кода и перестать спаривать записи, которые были предварительно искусственно удвоены в валидаторе?