Сегодня еще одна поучительная история о том, как из-за экономии на инфраструктуре можно попасть на приличные деньги.
Недавно к нам пришел заказчик с проблемой: 1С: УНФ выдает неверные финансовые результаты по итогам года.
Копнули глубже и увидели, что у одной части документов отсутствуют движения, а у другой — движения неверные. Еще копнули: полгода назад (видимо, во время очередного аварийного выключения сервера) повредились таблицы настроек движений документов. СУБД восстановила целостность таблиц и сделала вид, что все нормально. Но движения выполнялись неверно, потому что физически таблицы целые, а вот данные в них либо неверны, либо отсутствуют.
И вот полгода такой работы привели к тому, что в базе непонятно сколько, чего и куда. Полгода, Карл!
Решение. Было 2 варианта: кропотливо восстанавливать движения документов за полгода, или, раз уж начало года — перенести остатки в новую базу и начать с нуля. Первый вариант дороже, поэтому заказчик выбрал второй, хотя и он обошелся недешево — 500К.
А потрать он 50-100К на бесперебойник и корректное завершение работы, ничего этого не было бы. Обратись он с проблемой в августе — восстановиться было бы тоже сильно дешевле. По итогу сэкономил бы время, деньги и нервы.
Вывод: не экономьте на инфраструктуре, обращайтесь с проблемами своевременно. А еще лучше — купите поддержку у нас,и вообще не будете знать никаких проблем
Недавно к нам пришел заказчик с проблемой: 1С: УНФ выдает неверные финансовые результаты по итогам года.
Дано: сервер без бесперебойника, стоит в подсобке. Электричество отключают регулярно и внезапно, иногда надолго. На сервере — 1С:УНФ с базой данных в PostgreSQL.
Что мы сделали: начали разбираться — оказалось, что неверные результаты программа показывает аж с августа 2024 года Однако заказчик забил на проблему, пока не пришло время сдавать отчетность.
Копнули глубже и увидели, что у одной части документов отсутствуют движения, а у другой — движения неверные. Еще копнули: полгода назад (видимо, во время очередного аварийного выключения сервера) повредились таблицы настроек движений документов. СУБД восстановила целостность таблиц и сделала вид, что все нормально. Но движения выполнялись неверно, потому что физически таблицы целые, а вот данные в них либо неверны, либо отсутствуют.
И вот полгода такой работы привели к тому, что в базе непонятно сколько, чего и куда. Полгода, Карл!
А потрать он 50-100К на бесперебойник и корректное завершение работы, ничего этого не было бы. Обратись он с проблемой в августе — восстановиться было бы тоже сильно дешевле. По итогу сэкономил бы время, деньги и нервы.
