Определённо, в последнее время требования к высоким уровням доступности становятся всё более распространёнными. Сервисы, что ранее предоставлялись лишь "внутри" компании, становятся внешними, будучи предоставляемыми непосредственно клиентам. Соответственно, как отмечает Стюарт Рэнс в своей заметке, и простои сервисов, когда они возникают, становятся сразу видны многим: от клиентов до прессы и конкурентов. Довольно часто можно прочитать в заголовках новостей, что в такой-то компании произошёл серъёзный сбой в ИТ. В свою очередь, это выливается в потерю огромных сумм денег, потерю репутации на рынке. Что предпринять, чтобы не оказаться в подобной ситуации?
Крепость
Данный подход "старой школы" предполагал титанические усилия, направленные на проектирование сервисов, которые никогда "не падают". Название получил за счёт сходства с принципами строительства средневековых каменных замков. Крепость должна была отражать атаки и оставаться неприступной. Жёсткая и надёжная конструкция. ИТ-решения, использующие данный подход, конечно же, могут быть очень надёжными. Но проблема в том, что если крепость пала, то последствия для защищаемых ею объектов обычно катастрофические. Мы не можем предусмотреть всех возможных обстоятельств и выработать меры противодействия. Что-то из непредсмотренного через какое-то время обязательно случится, и наша "крепость" падёт. А восстановление её займёт длительное время.
Антихрупкость
Как ни парадоксально, но ставя целью "никогда не падать", мы обязательно рано или поздно упадём. Альтернативой подходу "строительства крепости" является принятие того факта, что сбои случаются, и сосредоточение усилий на том, чтобы они не приводили к критическим последствиям, раз уж произошли. Обычный одуванчик довольно мягок, не твёрд, как дерево. Можно легко сорвать его цветы и листья. Но это мало повлияет на само растение. Даже если вы срежете листья под корень, через очень короткое время они появятся вновь. Выдерете с корнем – летучие семена-парашютики попадут на разрытую вами землю, и вновь растение пойдёт в рост.
На этом примере виден принцип, лежащий в основе антихрупкости. ИТ-решение проектируется так, чтобы сбои не влияли серьёзным образом на его работоспособность. В терминах ИТ это означает, что мы проектируем и эксплуатируем наши ИТ-сервисы с полным пониманием, что они могут быть недоступными по причине сбоев. Наша задача – сделать так, чтобы, когда сбой произошёл, мы тотчас же узнавали об этом и начинали быстро восстанавливать работоспособность. Фактически, у нас должны быть ресурсы, которые можно использовать для подмены сбойных компонентов и чёткие и актуальные планы, как это делать и делать быстро. Самое важное: мы должны постоянно проверять наши способности по восстановлению после сбоев различных видов. Подобное тестирование – это абсоблютно необходимый компонент, поскольку стратегия восстановления, которая не была протестирована, вряд ли сработает, когда это потребуется.
А как обстоят дела с вашими сервисами? Что произойдёт, если какой-либо из компонентов выйдет из строя? Как сбой будет обнаружен? Кто обнаружит сбой: человек или система мониторинга? Каков план восстановления?
Если вы придерживаетесь стратегии построения "крепости", может быть, настало время задуматься о том, что нужно "падать" почаще?