DRP, который никто не проверял: почему план восстановления может не сработать в самый нужный момент

[StjarnornasFred]

Но длительная недоступность информационной системы, а тут целых её компонент, для бизнеса означает потерянные заказы, сорванные платежи и звонки злых клиентов в поддержку. Именно этого DRP и должен был помочь избежать.

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

Вот просто сравните:

• По нашему дата-центру произошла атака украинских БПЛА, которую не удалось отразить силами ПВО, что привело к разрушениям и пожару.

• У нас в дата-центре произошёл инцидент, вызвавший отключение электричества, из-за чего сервисы временно недоступны. Приносим свои извинения.

Какое из этих сообщений вызывает больше понимания у клиентов, а какое выставляет Яндекс лохом? (Особенно в ситуации, когда все всё знают).

[GrayHoax]

Думаю, что сотрудники Яндекс увидят Ваш комментарий и исправятся :)

[itGuevara]

Есть ли ссылочки на методику составления и примеры реальных DRP?

[GrayHoax]

Могу поделиться вот такой ссылкой: https://github.com/nullday/drp-plan

По реальным DRP выслать не смогу - действует NDA. Но давайте спишемся в личке, если есть вопросы.