Настоящий CTO: думай как технический директор - Алан Уильямсон

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

Разработайте систему инвентаризации: важно отслеживать все оборудование любым способом – от подписывания корпусов маркером до наклеивания распечатанных штрихкодов. Необходимо указывать следующую информацию:

• Дата покупки/установки – когда было приобретено и подключено оборудование?

• Источник покупки – где было приобретено оборудование (включая полные контактные данные продавца)?

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

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

• Способы доступа – есть ли на устройстве консоль? Если да, то как настроена сеть и где хранится имя пользователя/пароль?

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

Заметки с полей

Часть мебели

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

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

Обслуживать само оборудование сложнее. Трудно обосновать замену компонента, который еще не вышел из строя, но заменять детали заранее – это полезная привычка. Как минимум вы должны знать, где их достать, чтобы в случае отказа иметь возможность быстрой замены. Аппаратное обеспечение быстро устаревает и не имеет такой степени обратной совместимости, как нам хотелось бы. Это вынуждает организации искать б/у запчасти на eBay.

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

8.4. Аварийное восстановление

Определим, что такое аварийное восстановление (disaster recovery). Поскольку сбой в работе вашей системы (независимо от его причин) нанесет значительный ущерб вашим клиентам, необходимо подготовить план, в соответствии с которым когда (а не «если») такой сбой произойдет, предприятие сможет восстановить свою работу. Обычно подобный план предусматривает перевод нагрузки в место, географически отличающееся от основного, чтобы учесть такие ситуации, как пожар, наводнение или кража.

Заметки с полей

Годзилла атакует

Еще в начале карьеры, когда я впервые услышал термин «аварийное восстановление», я сразу же представил себе Годзиллу, шагающего по городу и разрушающего все здания на своем пути. Как деревенский житель, еще не привыкший к жизни в городе, я задавался вопросом: неужели подобное случается так часто, что обязательно иметь план действий? Со временем я понял, что немного увлекся и нужно думать о более приземленных ситуациях, таких как пожар, наводнение или кража. На самом деле наиболее вероятной проблемой будет сбой питания, сети или оборудования (ничего общего с Годзиллой, но до сих пор я не могу слышать слова «аварийное восстановление» без улыбки, потому что это первое, что приходит мне на ум).

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

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

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

• Каково допустимое время простоя?

• Допускается ли частичное предоставление услуг на время восстановления?

• После отказа вы полностью перейдете на новый основной комплекс или вернетесь к прежнему?

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

8.4.1. Допустимое время простоя

Генеральному директору легко требовать нулевого простоя. Хотя такое возможно, это очень дорого и очень сложно, особенно если в инфраструктуре существуют компоненты, которые нельзя запустить в нескольких экземплярах. Яркий пример – обычная база данных: в большинстве организаций таблицы не спроектированы для легкой реализации резервирования в реальном времени (если вы полагаетесь на сгенерированные базой данных автоинкрементные первичные ключи, а не на GUID, то вам придется несладко). Старые системы или плохая архитектура просто не позволяют иметь дублирующую систему, на которую можно быстро переключиться.

При использовании для вашей системы двух географически разнесенных зон сложность (и стоимость) решения для аварийного восстановления будут определять два фактора:

• Технология синхронизации данных в обеих зонах.

• Способ перенаправления трафика (пользователей) на новую основную зону.

Синхронизация данных между двумя разнесенными в пространстве зонами требует времени – буквально. Для передачи данных по сети требуется время, и даже небольшая задержка в 50–100 мс может иметь огромное значение, когда речь идет о синхронизации баз данных. Даже если сеть в рабочем состоянии и не перегружена, вы будете ограничены временем, которое требуется для пересылки байтов. При выборе места для размещения резервной системы учитывайте схему пиринга между ЦОД (они должны быть связаны друг с другом напрямую, чтобы избежать влияния общей перегрузки каналов связи).

Хотя современные БД (такие как SQL Server и Oracle) имеют мощные функции синхронизации (из-за чего лицензия на них стоит дороже), скорость передачи данных по-прежнему ограничена физическими возможностями сети.

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

Существует два подхода к аварийному восстановлению: горячий и холодный резерв. Горячий – более дорогой, он предполагает малое время простоя, и для него необходимо поддерживать серверы в рабочем состоянии и постоянно синхронизированными, готовыми начать обслуживание пользователей, как только на них начнет поступать трафик. При горячем резервировании постоянно потребляется электроэнергия и загружается сеть, а также сокращается срок службы резервного оборудования.

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