andreymx1. Подскажите, как у кого на фирме – есть ли официальным образом утверждённый порядок решения таких ситуаций? Ну, можно потратить, скажем, один-два раза в месяц до 20 минут на восстановление работоспособности важных кусков ПО в рабочее время.
Или за любую остановку – расстрел с конфискацией?
2. Как в принципе минимизировать подобные ситуации? Эта задача, как и другие, у нас тестировалась, и тестируется относительно регулярно, но не ежедневно же… А этот комплекс и все соседние в постоянном развитии. Написать автоматизированное ПО для тестирования в настоящее время не берётся никто.

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

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

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

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

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

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

AlexTheRavenПрофессиональные тестировщики были? Сколько процентов от тестовой схемы было внесено в тестовые сценарии? ...Тогда какие вопросы?

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

Или ты считаешь, что можно написать идеальную систему? Ну-ну...

AlexTheRavenИдеальную - нельзя, но можно разработать в той или иной степени качественную, в частности - обладающую большой степенью доступности.
Так о чем и речь. Кто поставщику системы определит эту "степень доступности"? Понятно же, что повышение степени доступности увеличивает стоимость разработки и поддержки системы. И до какой степени ее повышать - до бесконечности?

В случае автора степень доступности определил шеф фирмы по понятиям.
У кого-то степень доступности - это один из KPI отдела IT.
Как вариант, можно этот параметр закрепить в договоре на поддержку.

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