Соглашения об уровне данных и уровне обслуживания

В предыдущей статье этой серии мы рассмотрели как преимущества, так и препятствия на пути внедрения многоуровневого решения для хранения ваших бизнес-данных. Преимущества многоуровневого хранения данных очевидны, а именно:

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

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

Но кого на самом деле волнуют деньги?

Табель учета рабочего времени и прочие фантазии

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

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

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

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

Но если бизнес-подразделениям действительно будет выставляться счет за объем хранилища, который они используют на каждом уровне, то они, вероятно, будут очень заинтересованы в том, чтобы их устаревшие данные были перенесены в хранилище уровня 2, а их ненужные данные — в архивное хранилище уровня 3, поскольку они могут сократить свои затраты. таким образом оплачивают счета за хранение и используют сэкономленные деньги для выполнения своей конкретной миссии.

Повышение уровня данных с помощью соглашений об уровне обслуживания и выставления счетов

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

Рис. 1. Как стимулировать принятие решения по многоуровневому хранению данных.

В следующих разделах подробно описывается каждый шаг процесса.

Шаг 1. Установите соглашения об уровне обслуживания для каждого уровня данных

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

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

• Время безотказной работы — часто выражается цифрами 9 (например, 99,999% гарантированного времени безотказной работы), но лучше указать максимальное количество минут или часов ожидаемого простоя в год.
• Производительность. Это должно включать гарантию таких вещей, как минимальная пропускная способность в Мбайт/с и максимальная задержка в миллисекундах задержки при передаче данных в хранилище или из хранилища.
• Восстановление — это включает в себя гарантию как целевой точки восстановления (RPO), так и целевого времени восстановления (RTO) для выполнения операций резервного копирования и восстановления.
• Предоставление — это включает в себя гарантию максимального времени, необходимого для ответа на запрос бизнес-подразделения о дополнительной емкости хранилища.
• Управление. Это включает в себя предоставление бизнес-подразделениям какой-либо панели управления, чтобы они могли запрашивать или самостоятельно выделять дополнительное хранилище, просматривать время безотказной работы и производительность, проверять RPO и RTO и отслеживать свои затраты на хранение.
• Владение — это включает в себя определение того, кто владеет хранимыми данными и кто может получить к ним доступ. Обычно бизнес-подразделение владеет данными, и ИТ-отдел может получить к ним доступ только при наличии разрешения, но правоохранительные органы также могут иметь доступ по распоряжению суда или повестке в суд.
• Ограничения. Это включает в себя описание того, какие формы прерывания обслуживания не покрываются соглашением об уровне обслуживания, например, сбой маршрутизатора, который соединяет серверы бизнес-подразделения с облачным хранилищем.
• Техническое обслуживание. Это включает в себя уведомление бизнес-подразделений о запланированных или незапланированных операциях по техническому обслуживанию, чтобы они могли оценить возможное влияние таких операций.
• Поддержка — это включает в себя определение того, с кем бизнес-подразделение должно связаться в случае проблемы или прерывания обслуживания, процесс выдачи и ответа на запросы в службу поддержки, процедуру эскалации и ожидаемое время ответа для различных уровней проблем.
• Стоимость — включает в себя суммирование стоимости хранения и обычно указывается в долларах (или в другой подходящей валюте) за терабайт (ТБ) в год.
• Возмещение — это включает в себя описание того, как будет корректироваться выставление счетов в случае невыполнения определенных гарантий в SLA.

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

Шаг 2. Внедрите фиктивный возврат счета

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

Шаг 3: Сравните затраты

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

Шаг 4. Внедрение многоуровневого хранения данных

Следующим шагом является внедрение вашего решения для многоуровневого хранения данных в соответствии с планом и перенос на уровень 2 данных, которые каждое бизнес-подразделение определяет как устаревшие.

Шаг 5. Опубликуйте соглашения об уровне обслуживания и внедрите выставление счетов

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

Вывод

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