Привет! Сегодня рассмотрим управление IT-инфраструктурой с точки зрения руководителя отдела IT, для которого бюджетирование и расчёт времени простоя — неотъемлемая часть работы.
Говорить будем о том, как выстраивать отказоустойчивую и катастрофоустойчивую IT-систему, чтобы избежать убытков при сбоях. Сразу заметим, что эти изыскания актуальны на определённом уровне развития компании. То есть ларьку с шаурмой они явно не нужны, а вот для сети шаурмичных из 200 объектов уже актуальны.
Типичная ситуация: сбой в филиале
Представьте не очень большую, но гордую компанию «Копыта и шкура», торговую сеть с филиалами по России, централизованной IT-системой и регулярными отгрузками. Наступает суббота, склад в Новосибирске готовится к отправке, но неожиданно зависает сервер учётной системы. Возможно, уборщица отключила кабель питания, мешавший ей мыть пол. Или что-то вышло из строя в оборудовании — сути это не меняет.
Теперь склад не может отгружать товар, а покупатели требуют заказанную продукцию. На компанию начинают давить штрафы за срыв сроков поставки, которые достигают десятков и сотен тысяч рублей за каждый просроченный заказ.
И неважно, что случилось, питание пропало или просто завис сервер, складу в Новосибирске от этого не легче, у него фуры стоят, ему отгружать товары надо. Ситуация забавная, все бегают, всем весело. Наконец дозваниваются до админа и предлагают как можно быстрее проследовать в место дислокации сервера и немедленно что-то сделать, грозя разными карами, которые в Европе за норму считаются.
И вот админ, чувствуя фантомные боли в европейской части своей тушки, несётся к серверу, аки быстроходная лань. И если бежать недалеко, а с железом всё в порядке, то он восстановит работу за полчаса-час. В ином случае сбой может затянуться, что приведёт к цепочке нарушений и штрафам от филиалов и основного склада в Москве. В это время ко всеобщему веселью подключаются филиалы. Им тоже надо отгрузить товар, у них тоже штрафы за неотгрузку, а скоро уже надо отгружать основному складу в Москве... И вот уже разнообразные меры наказания маячат и над начальником ИТ отдела, потому что это он не предугадал и допустил.
Убытки и подсчёт последствий
Многим из тех, кто работал в активно развивающихся компаниях, когда ИТ откровенно не успевает за темпами развития бизнеса, такая ситуация знакома, а кому незнакома, то явно не хотели бы оказаться в такой ситуации. Но давайте посмотрим на последствия инцидента.
Сколько компания потеряет от такого простоя? Допустим, отгрузки сорвались в четырёх филиалах и частично на основном складе, где было запланировано 80 отгрузок. В каждом филиале планировалось по 15 отгрузок, итого 140. Если штраф за каждый срыв составляет 60 тысяч рублей, то прямые потери составят 6 миллионов рублей. Вопрос: что мог сделать IT-отдел, чтобы предотвратить такие убытки?
Концепции отказоустойчивости и катастрофоустойчивости
IT-инфраструктура требует двух основных подходов для снижения рисков:
Первый подход: отказоустойчивость. Это способность системы автоматически переключаться на резервное оборудование в случае сбоя. Самый дешёвый и простой метод — это репликация виртуальных машин. Например, два сервера с Windows Server 2019 могут реплицировать данные, что снизит риск потери информации. Решение ли это? Для небольших компаний — да. Здесь нет, конечно, автоматического переключения, но вы застрахованы от сгорания первого сервера, и того, что бэкапы вчерашние, а информация за весь день исчезла.
Более продвинутый вариант — отказоустойчивый кластер с централизованным хранилищем данных, который позволяет сохранять работоспособность при выходе из строя одного из серверов. Тут всё замечательно. Если отвалился один сервер, всё автоматом запустилось на втором, знай себе соблюдай кворум серверов (нужно в запасе иметь ровно столько ресурсов, чтобы пережить падение одного сервера — это будет кворум 1, два сервера — кворум 2 и так далее). Минусы этого решения: оно дороже, требует знания систем хранения и всё равно у вас остаётся единая точка отказа: сама хранилка.
Второй подход: катастрофоустойчивость. Подразумевает создание резервной площадки для восстановления работы системы в случае глобальной аварии, например, пожара или полного отключения ЦОДа. В этом случае важны мощные каналы связи между площадками, обеспечивающие передачу данных в реальном времени.
Сами площадки должны быть географически удалены друг от друга (разные концы одного большого города либо разные города, страны) и на каждой нужно держать столько оборудования, чтобы в случае выхода из строя одной площадки можно было всё (или только жизненно необходимое) запустить на второй. Для обмена данными между площадками в реальном времени используется множество разных технологий, начиная от репликации виртуальных машин и заканчивая MetroCluster на СХД.
Бэкапы — основа любой защиты
Возникает закономерный вопрос: что важнее и может ли быть катастрофоустойчивость без отказоустойчивости? Ответ на первую часть вопроса может быть не очевиден, но важнее всего бекапы. Причём бэкапы на несколько разных площадок с разным интервалом. И бэкапный сервер должен находиться в отдельной защищённой сети. В этом, к своему сожалению, не так давно убедился один из российских поставщиков облачных услуг.
На вторую часть вопроса ответ положительный. Да, может (как ни странно). Когда риски потерять первую площадку превышают последствия простого падения, то имеет смысл вложиться в катастрофоустойчивость. Хороший вариант: два отказоустойчивых кластера в двух разных площадках и синхронизация на уровне хранилищ данных (если вы хотите такую систему — добро пожаловать в Cloud4Y, у нас есть).
Появляется ещё один нюанс: подсчёт затрат. IT-руководителям приходится взвешивать расходы на внедрение отказо- и катастрофоустойчивых систем. Они считают косвенные и прямые убытки. Просчитывают, какие убытки компания понесёт за 8 часов простоя, за день или за несколько дней, сколько будет стоить перенос отгрузок, а также время простоя сотрудников и оборудования. Прикидывают, не проще ли делать бэкапы на вторую площадку, и в случае инцидента взять сервера и развернуться на них (а также сколько это займёт времени).
Именно такими задачами заняты IT-руководители крупных компаний. Они не просто работают с циферками в Excel, как считают рядовые сотрудники компаний и некоторые системные администраторы, а анализируют риски и планируют стабильную работу систем.
Пожалуй, для первого раза и для входа в весёлый мир планирования информации достаточно. Все, кто прочёл этот текст — живите теперь с этим. :))
Спасибо за внимание!
