Вопрос, конечно, риторический, но всё же.
Обратился франч ко мне знакомый. На заводе внедряют дописки в УПП.
У завода есть админ (начальник ИТ-отдела, штат прогеров и т.д.), франчовые орлы вносят изменения в конфу по ТЗ.
Рухнула база. Ну как рухнула - в один день начала сыпаться с ошибками. Ошибки диагностируются и лечатся через ТиИ.
Завод обвиняет франча.
Франч божится, что ничего криминального не делали, только дописали пару отчетов и обновили.
И у меня есть склонность франчу верить. Тем более, что в этой ситуации на одном/нескольких компах ничего не сыпалось. Кэш ни при чем.
Вопрос - есть ли у завода веские основания забодать франч? Или как франчу отвести претензии завода?

виноват админ

(0) Лучше абстрагируйся, а то сделают тебя виноватым

(1) Я вот тоже думаю, хотя бы потому, что у базы есть хозяин и он должен за ней сделать.

(2) абстрагировался)

(0) Если всё лечится банальным ТиИ в чём вопрос? Если у админа нет бэкапа, ему клизму с патефонными иголками литров на 10.

(3) Хозяин базы не админ, а владелец завода

простите я сразу концовку скажу- убийца садовник

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

(0) Если нет прямого указания франчу делать бэкап, виноват админ.
Но лично я вне зависимости от указания, по возможности делаю бэкап. Часто помогает, т.к. у админов бекапа часто нет.

А если база начала сыпаться от отчетов, виноват админ.

(8), (9) спасибо!

База рухнула вчера - это Путина вина.

(0) Если для исправления ошибок надо делать ТиИ, то проблема либо в железе, либо в платформе 1С. У них, кстати, 1С не ломанная? В любом случае франч не при делах.

ответ в вопросе =) читаю название темы - "Рухнула база. Кто виноват?)  / Админ"

А может обновление платформы накатили удачное?

(0) Если ошибки лечатся, в чем проблема?

Мне вот это не понятно: <<Тем более, что в этой ситуации на одном/нескольких компах ничего не сыпалось. Кэш ни при чем.>>
По мне так если одном/нескольких компах ничего не сыпалось - то с большой вероятностью динамическое обновление и кэш как раз причем...

база может "сыпаться" по разному...

null в регистре бухгалтерии и т.п. - тут франь не причем

или кэш посыпался...

(0) Фраза завода "А че это у нас база сыпется?" должна быть направлена своему админу, а не франчу ессно.
При адресации же франчу необходимо нечто более предметное, чем "А что это у нас начала база сыпаться?", "Почему у нас инет пропал?" или "Как так получилось, что у меня дома кот сожрал всех аквариумных рыбок?".

(18) Не так. Нам вчера диск ИТС принесли, после этого база стала сыпаться...

(19) Ну да, так тоже бывает :))

(19) Не ИТС. А мышку заменили.

(20) Угу, помнится, было дело - ключи сгорали после того как диск ИТС привезли...

(22) и принтеры перестают печатать как надо очень часто.

(0) Франчи скорее всего не причем. Из за франчей только программные, логические, ошибки прав могут быть. Если база сыпется то тут что то внешнее.

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

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

1. Админ отвечает за бекапы и доступы
2. Заказчик отвечает за тестирование

при правельной постановки процесса на заводе франч ФИЗИЧЕСКИ не должен иметь доступ к рабочей базе....

значит франч не виноват :)

(25) купили какое-нибудь отраслевое уг в котором без вендора не разобраться...

(28) там всё сложно. И не совсем связано с профессиональными качествами ИТ -отдела

(24), (27) спс

(11) А бэкап 3 дня назад - это Путин виноват

(28) > в цивилизованном айти автоматизацией занимается вендор, то есть профессионал, а не кулибины.

(0) Админ при любом раскладе. Или он грамотно управляет резервированием и архивами, или разграничивает зоны ответственности и управляет резервированием / архивами.

ну и конечно #blameputin

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

ТИИ это ошибки всего скорее железа и проблема админа. А точнее рейда/винтов.

база гниет с головы

(0) ну и запросы у вас, - сказала база даных.... И упала.

(15) Никогда не работал на крупных предприятиях? Есть время простоя, оно стоит денег. Кто будет отвечать? Наказывать своих сотрудников невыгодно. Поиметь денег с франча? Отличный выход...  Только ничего им не светит.

(0) >>Вопрос - есть ли у завода веские основания забодать франч? Или как франчу отвести претензии завода?
виноваты админы завода, если конечно франчи в договоре не взяли всю ответственность за вашу базу на себя)), что почти невероятно)...
отвести претензии можно довольно просто - установить причину (раз сыплется не сильно то подозреваю железо) и выставить счет ИТ-отделу завода  за работы))

(39) Угу, поставив новое железо, закупленное по цене втрое дороже реальной.

(0) Есть элементарный способ определить. Перенести базу на резервное железо и дать пользователям погонять в рабочем режиме.

Да и вообще, какое отношение франч может иметь к рассыпанию базы?

(0)
чистосердечное признание облегчает душу и удлиняет срок

(40) =)))),
ну как минимум некомпетентный ИТ-отдел разогнать или оштрафовать;
"база сыплется" - это не диагноз (это как к врачу придти и сказать я болею))), документы пропадают? итоги слетают?сеансы пользователей завершаются? - надо анализировать и искать причины а дальше разбираться...иначе можно например и повышенной геомагнитной обстановкой объяснить))))

Виноваты франчи, ибо работали на живой базе, не делая бэкапов.
Нормальная работа франча - сделал на копии, оттестировал, включил в рабочую.

В заголовке ответ - нужно Тире поставить.

А база-то поди ж файловая ?
Есть мнение, что если это так, то виноват тот, кто сказал, что это будет работать.
Потому что, SQL-база и необходимость ТИИ - это очень неправдоподобно.

(46) база скульная)

(44) божатся, что так и поступали.

Кто должен копии делать ? Если он их не делал и не следил он и виноват. Можно кстати посмотреть кто последний вносил изменения. Обновлять без копии не хорошо, или через хранилище. Короче если этого нет то кто предлагала такой метод обновления и почему франч прям на боевую лил ? Франчи вообще отдельная тема у них не лучшие спецы работают.

(47) А что может быть в скульной версии такого "фатального" ? Если ошибки регистров, то это быстро лечится, причём, на рабочей базе это нужно делать периодически.
Если что-то работает "не так" - то это вообще вопрос к 1С - там иногда после обновления некоторые модули работают по старому коду только из-за того, что кто-то придумал всякое кеширование.

(49) Конечно! УПП падаваны курочат..

(49) копии делаются dt (!) ежедневно. Подняли одну - а там то же самое)

Вообще в ИТ мне кажется вопрос типа кто виноват ни к чему не приведет. Ну скажем даже если вы уволите этого сотрудника, что дальше? В целом это просто рабочая ситуация. Вам ещё ему медаль нужно дать будет. Самый главный вопрос который нужно решить, почему это стало возможным ? Затем решить какими методами от этого можно застраховаться. База должна крутиться как положено. с копиями причем если большая то даже не на одном винте хранится а использовать raid.

(52) Как так тоже самое ?  Дело видимо не в 1С. Как вариант почистите кэш 1С.

Динамическое обновление штука такая. Там всякие разрушительные ошибки возникают. Особенно если база распределенная.

(52) копии чего-чего ? dt ?
Это при наличии скуля то ?
Завод говоришь ?
Может гараж частный заводом обозвали ?
:))
Не верю.

(56) Кстати да. С какого dt.

Задача местных админов - делать копии по расписанию, и по требованию.
Франч перед выкатыванием обнов должен озадачить админов чтобы те сделали копию, либо сделать самостоятельно, если права позволяют.
(52)Копии в dt не делают даже на файловых, это не копия а выгрузка.
В dt можно выгружать как дополнение к резервному копированию, но никак не в качестве замены оному.

(55) Особенно, если вести отладку в боевой базе.
Несколько раз "демонически" обновил - и все работают с разными конфигурациями.

Есть мнение, что перед обновлением нужно было не копию делать, а ТИИ.

(58) Уже почти 10 лет делаю dt файлы ниразу небыло проблем с загрузкой

(60) И сервер перегрузить 3 раза и антивирус и скандиск запустить, а то мало ли чего. Да еше и тест памяти не забыть

Кстати как вариант, если база скульная, можно прям в скуле переиндексировать базу, должно помочь. Но не факт что доки верную последовательность будут иметь.

(61) А зачем если сделать mdf и mdl меньше гемора и восстановить можно прям в скуле.

(61)Если проблем в базе нет то чего им взяться проблемам при загрузке?
А учитывая что резервные копии требуются когда проблемы - тут и можно нарваться.

виноваты франчеры. долбить их

(65) Ну хз, из копии постоянно восстанавливать приходится. Баз куча. ТО кому то поиграться, то кто-то задом что-то поправил и нужно посмотреть как было, то еще какая проблема...

(58) +100
Виноват тот, кто вносил изменения, не сделав перед этим копию

(68) И чем эта копия поможет? Времени наверняка уже вагон прошло, и пользователи вагон новых документов вбили в базу.

(69) доколотить что-то в рабочую копию всяко проще, чем подымать неработающую базу.
Тем более, всякими переносами делается это не так и долго

(70) Дык и какая разница - в утренний бэкап доколачивать, или в дневной, если уже неделя прошла?

(0) Перекрёстный допрос устроить. Админ и Ко супротив франча.