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

Этот материал — не глубокий разбор технологий с погружением в архитектурные детали, а скорее обзор эволюции подходов к построению технологического контура. Давайте обратимся к истории и вспомним, чего мы ждали от ИТ-инфраструктуры на разных этапах технологического развития. И почему сегодня выигрывают не самые несокрушимые, а самые «антихрупкие» системы.

Общий вектор развития ИТ-инфраструктуры за последние 25 лет можно сравнить с путешествием в космос. Сначала мы твердо двумя ногами стояли на земле и о надежности ИТ-инфраструктуры рассуждали исключительно в физической плоскости, потом мы стали «взмывать в облака» и повышать уровень абстракции, уходя все дальше от железа в сторону виртуализации и географически распределенной инфраструктуры. Давайте разделим этот эволюционный трек на три периода: 2000-е, 2010-е и с 2020 года до сегодняшнего дня. Конечно, такое деление весьма условно. Одни тренды наметились раньше, а другие позже, но с исторической точки зрения это глобально не влияет на общую картину. 

Чем же один период отличается от другого? На самом деле ключевых отличий только два, и их можно сформулировать двумя вопросами. 

1. За счет чего мы обеспечиваем надежность ИТ-инфраструктуры?

2. Какова вероятность, что в инфраструктуре произойдет сбой?  

Давайте вспомним, как мы отвечали на эти вопросы двадцать и десять лет назад и что говорим сейчас. Итак, поехали. 

2000-е: эпоха «пяти девяток» и культа железа

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

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

Все крупные заказчики обязательно строили основной и резервный ЦОД, создавали как локальные, так и уже географически распределенные кластеры. При этом и прикладные системы научились работать в отказоустойчивых режимах: "active-active" (оба сервера обрабатывают нагрузку, при сбое одного трафик переключается на другой) и "active-passive" (работает один сервер, второй — резервный, запускается при сбое)

Если смотреть не только на модель надежности, но и на саму вычислительную базу, то в 2000-е ставка делалась на дорогие high-end RISC/UNIX-системы, специализированные серверы и тяжелые enterprise-СХД. В 2010-е на первый план вышли x86-платформы и midrange-решения, которые сделали надежность более массовой и экономически оправданной. А в 2020-е на фоне облаков, гиперскейлеров и роста требований к энергоэффективности усилился интерес к новым архитектурам, прежде всего ARM, сначала в потребительской электронике, а затем и в enterprise-среде.

Цена вопроса: CAPEX и дорогие специалисты

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

В нулевые пика своей популярности достигла так называемая концепция «пяти девяток». Чем выше процент доступности, который и измерялся количеством девяток после запятой, тем надежнее ЦОД.

В частности, пять девяток или 99,999% обозначали процентное соотношение доступности ЦОД в течение года, то есть 99,999% времени центр обработки данных должен был работать штатно, а его простой не должен был превышать 5,26 минуты в год. Конечно, мало кто мог себе позволить обеспечить доступность на таком уровне - это было слишком дорого. Но все стремились максимально приблизиться к этой цифре. 

В этот же период активно применяется классификация, введенная Uptime Institute и подразумевающая четыре уровня надежности и отказоустойчивости, которые по-английски назывались tiers (Tier I, II, III и IV). Чем выше уровень, тем надежнее объект. Причем Uptime Institute мог отдельно сертифицировать проектную документацию (Design Documents), уже построенный объект (Constructed Facility) и объект в процессе эксплуатации (Operational Sustainability). Немногие компании получали все три сертификата на свой ЦОД, часто ограничивались лишь сертификацией проектной документации. Вместе с тем, некоторые ЦОДы в Москве были сертифицированы Uptime Institute по уровню надежности Tier III, в том числе и как объект в процессе эксплуатации, что означало общий уровень доступности не менее 99,982%, то есть допустимый простой в течение года не должен был превысить 1,6 часа.

2010-е: неизбежность отказов и ставка на быстрое восстановление

В конце нулевых наметился фундаментальный сдвиг в парадигме обеспечения надежности ИТ-инфраструктуры. Появились массовые версии систем виртуализации VMware и Hyper-V, которые позволяли эффективнее использовать аппаратные мощности, обеспечивать базовую отказоустойчивость и миграцию виртуальных машин при выходе из строя физического оборудования или целой площадки. Кроме того, началась эпоха облачных вычислений. Компания Amazon запустила свое коммерческое публичное облако AWS EC2 в 2006 году, а через пять лет «облачный» тренд захватил весь рынок.

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

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

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

Вместо того, чтобы покупать самое дорогое железо и складировать его в одном месте, дешевле и эффективнее оказалось использовать распределенную инфраструктуру с резервированием не на аппаратном, а на программном уровне. Благодаря тренду на гиперконвергенцию и программно-определяемые решения вместо пары сверхнадежных и сверхдорогих ЦОД отказоустойчивость стала обеспечиваться за счет большого количества гораздо более дешевых, но при этом менее надежных узлов, распределенных по разным площадкам. Вопрос уже стоял не в том, какой процент времени система работает без сбоев (например, доступность в 99,982% в случае Tier III), а в том, какой процент запросов был успешно отработан в срок.

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

Вместо несокрушимости дата-центров бизнес стал больше ценить упругость и устойчивость инфраструктуры, ее способность к быстрому восстановлению и в конечном счете ее гибкость. Динамическое выделение вычислительных ресурсов из облака помогало заказчикам легко справляться с пиковыми нагрузками, а автоматическое горизонтальное масштабирование позволяло как наращивать мощности, так и уменьшать их в зависимости от реальных потребностей бизнеса. Компании стали платить за фактическое потребление ресурсов (pay as you go) и обращаться к подрядчикам за запчастями и сервисами, вместо того, чтобы закупаться впрок и нести довольно обременительные капитальные затраты. Компании смогли размещать рабочие нагрузки у облачных провайдеров в разных зонах доступности под гарантии работоспособности и скорости реакции, прописанные в SLA.

Новые риски распределенной инфраструктуры

С выводом части инфраструктуры за пределы внутреннего контура возникли и новые риски. 

Зависимость от провайдера

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

Обеспечение ИБ 

Вторая проблема, непосредственно связанная с выходом за пределы внутреннего контура (буквально огороженной забором и тщательно охраняемой внутренней территории) – это обеспечение информационной безопасности (ИБ). Конечно, хакеры могут просочиться и во внутренний контур, но с переходом на географически распределенные инфраструктуры, сочетающие on-premise со сторонними облачными ресурсами, риски ИБ выросли в разы и до сих пор этот вопрос остается критичным для бизнеса. Поэтому в какую бы сторону ни качнулся российский, да и глобальный рынок труда, специалисты по информационной безопасности в ближайшие десятилетия, скорее всего, будут обеспечены работой. 

2020-е: антихрупкость и управление черными лебедями

В начале 2020 года вряд ли кто-то мог предсказать то, что ждало Россию в самое ближайшее время. Почти сразу разразилась пандемия коронавируса COVID-19, которая быстро захватила весь мир и отправила нас на удаленку. Через пару лет с российского рынка ушли западные вендоры, привычные технологические цепочки начали перестраиваться, усилилась нагрузка на ИТ-инфраструктуру, а число кибератак выросло в несколько раз. Все эти непредсказуемые и экстраординарные события, или попросту форс-мажор, обрушились на российский бизнес практически одновременно. В своей одноименной книге Нассим Талеб назвал такие события «черными лебедями». Если говорить инфраструктурным языком, то это сбои/проблемы, которых нельзя избежать (в 2000-е гг. мы как раз их тщательно избегали) и к которым невозможно подготовиться (в 2010-е мы как раз к ним тщательно готовились). Ты просто не можешь подготовиться к тому, чего не ждешь.

Отказ как точка роста

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

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

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

Концепция «изящной деградации»

Помимо постоянного процесса адаптации, в 2020-е годы по отношению к ИТ-инфраструктуре в целом и отдельным приложениям в частности стали активно применять концепцию «изящной деградации» (graceful degradation), которая зародилась еще в середине XX века в военной и авиационной промышленности и так или иначе пробивала себе путь в ИТ еще в 1990-2000-е годы. В применении к авиации суть концепции сводилась к следующему: летательный аппарат должен быть спроектирован так, чтобы в случае сбоя и отказа ряда компонентов и служб он все равно был бы в состоянии выполнять свою основную функцию. Иными словами, самолет должен быть в состоянии продолжать полет и оставаться управляемым даже при возгорании и выходе из строя одного из двигателей. Всем известны случаи, когда пилоты успешно завершают рейс и сажают самолет на взлетную полосу при одном работающем двигателе, а это как раз результат внедрения концепции «изящной деградации». 

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

Зарождение AIOps

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

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

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

Усиление ИБ и концепция «нулевого доверия»

Еще одним фактором, заметно влияющим на развитие современной ИТ-инфраструктуры, остается информационная безопасность. Еще в 2010-е гг. с активным освоением виртуализации и облачных вычислений и, как следствие, переходом на географически распределенные среды многие компании стали воспринимать ИБ как один из ключевых компонентов своей ИТ-стратегии. В 2020-е гг. этот тренд только усиливается по ряду причин. Во-первых, с каждым днем растет как количество атак на инфраструктуру и приложения, так и ущерб от этих атак, исчисляемый уже в триллионах долларов США. Во-вторых, сами риски ИБ претерпели существенные изменения: теперь это умышленный взлом инфраструктур и уничтожение резервных копий. В результате растет тренд на создание неизменяемых/неудаляемых копий, а также на создание холодных изолированных контуров, к которым в обычной ситуации не достучаться извне. В-третьих, из-за роста числа атак ужесточаются требования регуляторов в отношении информационной безопасности.

В начале 2020-х гг. был принят ряд законов и регламентов, обязывающих организации обеспечить информационную безопасность и защиту своей инфраструктуры. Прежде всего требования коснулись операторов платежных систем и прочих организаций из финансового сектора. Например, в 2022 году вышла обновленная редакция стандарта безопасности данных индустрии платежных карт – PCI DSS 4.0. Так, надежность инфраструктуры – это уже не только критичный для бизнеса вопрос, но регуляторное требование со всеми вытекающими, вплоть до наложения штрафов в виде процента от годового оборота компании.

С усилением количества и интенсивности атак на инфраструктуру все большую популярность набирает концепция «нулевого доверия» (zero trust), разработанная аналитиком Forrester Research Джоном Киндервагом уже в таком для нас далеком 2010 году. Сейчас «zero trust» –обязательная парадигма защиты инфраструктуры. Если раньше после авторизации в системе любое устройство или пользователь считались доверенными, то суть концепции «нулевого доверия» в том, что по умолчанию никому доверять нельзя и любое действие в системе должно сопровождаться проверкой и авторизацией. Это создает дополнительные барьеры для злоумышленников, потому что теперь даже после взлома варианты их действий в системе довольно ограничены благодаря подходу «zero trust». 

Заключение

Из этого экскурса в историю развития ИТ-инфраструктуры можно сделать очевидный вывод, что с 2000 года много воды утекло и все очень сильно изменилось. В случае инфраструктуры изменения носят не столько количественный, сколько качественный характер. Представление о надежности инфраструктуры стало просто другим, что легко понять из ответов на один из вопросов, заданных в начале статьи: Какова вероятность, что в инфраструктуре произойдет сбой? В 2000-е такая вероятность стремилась к нулю, сбой воспринимался как исключительная ситуация и все силы были направлены на то, чтобы ее избежать, то есть предотвратить отказ. В 2010-е стало понятно, что сбой точно будет и это нормально, и все силы были направлены на то, чтобы быстро восстановиться после него. А в 2020-е сбой стал не просто нормой, а обычным элементом повседневности и, более того, источником для дальнейшего совершенствования инфраструктуры, а все силы уже направляются на то, чтобы организация в целом и инфраструктура в частности могли непрерывно адаптироваться к меняющемуся миру и сохранять работоспособность в условиях полной неопределенности.