Максимально оперативное восстановление IT-инфраструктуры очень важно для любого бизнеса - ее простой это прямая потеря денег. Но насколько важно? Не каждый бизнес может себе позволить все самые затратные средства максимально быстрого поднятия системы. Как же вычислить точную сумму, которую целесообразно на это потратить?
Баланс между потребностями аварийного восстановления и финансовыми возможностями предприятия необходимо найти сразу после того, как мы определили возможные причины сбоя сервисов и наиболее подходящие средства их починки. Когда вы его найдете, его нужно будет закрепить в специальном соглашении - обычно его называют SLA, Service Level Agreement.
Это очень важный этап, поскольку вы сможете помочь своей системе настолько, насколько сможете согласовать аварийные меры с начальством. Итак, что нужно обсудить и как подойти к разговору?
В зависимости от размера и структуры предприятия в нем может складываться как благоприятная, так и совершенно ужасная обстановка для восстановления сервисов после отказа.
Как правило у внутренней службы получается полностью перекрывать все потребности предприятия в техподдержке несмотря на ограничение по длине рабочего дня, отгулы, отпуски, болезни. Однако что делать, если это не так? А если сбой случился ночью? Необходимо трезво взвесить возможности своей службы (тем более если она ограничивается одним сисадмином, например) и далее либо измерять время восстановления сервиса исключительно с начала рабочего дня (что может быть неприемлемо для бизнеса), либо помочь себе одним из нескольких способов:
Внешние подрядчики вообще часто воспринимаются как прекрасное решение в любом аварийном сценарии. на самом деле это далеко не всегда так.
Главное, что нас интересует во внешних специалистах - временные рамки, в которые они готовы уложиться по тем или иным задачам. Аутсорсная IT-служба может выглядеть идеальной на бумаге и превратиться в огромную неоправданную дыру в бюджете в момент, когда начнутся серьезные проблемы.
Чаще всего это связано с непониманием со стороны подрядчика уровня сервиса, который будет вам необходим, сроков, в которые его необходимо предоставлять, а также с заключенным соглашением, в котором просто не было прописано ни первое, ни второе.
Что же делать? Что ж, если вы уже в сотрудничестве, то вариантов немного -
Определившись с тем, кто будет восстанавливать систему, переходим к тому, что потребуется для восстановительных работ.
Оперативно поднять упавшую систему иногда можно просто введя в работу резервное оборудование. Восполнение резерва тогда отходит на второй план и может закрываться месяц или полтора, но, главное, инфраструктура продолжает работу! А без резерва эти "месяц-полтора" вполне возможно пришлось бы потратить на восстановление.
Но иногда предприятие не может себе позволить почти никаких резервов или же может позволить себе их лишь частично. Тут важно объяснить начальству, как оценивать "резерв": например, приобрести сразу два коммутатора может показаться дорогим удовольствием, но как соотносятся цена второго коммутатора и цена дня простоя из-за отказа первого? Наверняка дороже.
Для бизнеса также может быть более приемлемо подписать контракты на срочную замену устройств в случае поломки - обычно это контракт "на следующий рабочий день", но сколько это, опять же, будет в потерянных деньгах?
В конце концов, приемлемым может показаться даже согласование ухудшения качества работы системы через переподключение к критически важным задачам оборудования с остальных задач или же выделение резервных средств под срочное приобретение маломощных устройств чтобы восстановить систему "хоть как-то".
В зависимости от того, что получится согласовать, вы уже сможете говорить о конкретных сроках восстановления в сложившихся сценариях.
Невозможно объять необъятное - какие-то ситуации в SLA обязательно не войдут. И речь не только про форс-мажор, но, например, про одновременный отказ нескольких одинаковых элементов, чего уже никакими резервами закрыть не получится, или другие катастрофические случайности, готовится к которым просто не целесообразно. Они просто очень редко случаются - и, тем не менее, вполне могут произойти.
В таком случае частично перекрывающий потери резерв будет даже менее полезен, чем аварийный фонд, из которого можно будет закупить конкретно то, что нужно, продуманный бизнес-процесс аварийных запросов и т.п.