Характерная черта При разработке систем, на которые будут полагаться наши предприятия, мы делаем это с учетом устойчивости.
Двадцать пять лет назад такие технологии, как RAID и зеркалирование серверов, были новыми и в некотором смысле нетривиальными в реализации; сегодня это уже не так, и приобретение нескольких серверов, коммутаторов LAN, межсетевых экранов и т. п. для создания отказоустойчивых систем является рефлексом.
Конечно, это не гарантирует нам 100-процентную безотказную работу. Время от времени применяется закон г-на Мерфи: если ваш основной межсетевой экран выйдет из строя, есть крошечный, но ненулевой шанс, что вторичный также сломается до того, как вы закончите замену основного.
Если у вас сбой в электроснабжении, существует такая же микроматериальная вероятность того, что генератор, который вы тестировали еженедельно в течение многих лет, выберет этот момент, чтобы упорно кашлять, а не рваться к жизни. Если только вы (или, точнее, характер вашего бизнеса) не склонны к риску настолько, что можете оправдать расходы на более высокие уровни устойчивости, чтобы еще больше снизить вероятность простоя (но никогда, конечно, до нуля).
Однако бывают случаи, когда трудно спланировать неудачу.
Давайте посмотрим на недавний пример. В июле 2020 года у основной телекоммуникационной компании на Джерси произошел серьезный сбой из-за проблемы с устройством, обслуживающим сеть организации. Ключевым моментом в этом случае было то, что вышедшее из строя устройство не вышло из строя так, как мы все привыкли, – из-за «хлопка» и испускания дыма; если бы это было сделано, все было бы хорошо, поскольку второстепенная единица взяла на себя управление.
Невозможно
Нет, это был более изощренный вид сервера времени, который только частично отказал. Он продолжал работать, но начал обслуживать время примерно с 20-летней давности (вовсе не случайно, что это было заводское время по умолчанию), что сбивало с толку устройства сетевой инфраструктуры и приводило к остановке трафика.
Разумеется, неудовлетворенность клиентов была ощутимой, но как ИТ-специалисту нужно что-то чувствовать к технической команде компании: многие из нас когда-либо сочли бы возможным случаем отказа то, что технический руководитель совершенно правильно охарактеризовал как ” последовательность событий, которую почти невозможно было предвидеть »?
(Между прочим, в несколько более хороших новостях, если отступить на мгновение к нашей точке зрения о дополнительных уровнях устойчивости, та же компания ранее пережила разрыв трех морских кабелей … имея четвертый).
Можно ли использовать инструменты мониторинга, чтобы видеть подобные проблемы, когда они возникают? Да, безусловно, но дело в том, что для этого сначала нужно идентифицировать сценарии как нечто, что может произойти. С точки зрения управления рисками, этот тип отказа – очень сильное, но бесконечно маловероятное – является наихудшим из возможных для риск-менеджера. Существуют теории и книги о том, как можно подумать и справиться с такими рисками, наиболее известной из которых, вероятно, является книга Нассима Николаса Талеба. Черный лебедь, в котором говорится как раз о подобном риске, но если вы хотите попытаться защититься от неожиданного, то, по крайней мере, вам нужно сесть со значительным количеством людей и сосредоточенно, желательно с экспертом в этой области. направлять и модерировать, а также работать над выявлением таких возможных событий «черного лебедя».
Хотя концепцию черного лебедя, безусловно, следует иметь в виду, на самом деле существует гораздо более распространенная проблема с системами, которые мы считаем устойчивыми, – непонимание того, как работает устойчивость.
Одна конкретная установка в компании с офисом и двумя центрами обработки данных имела двухточечные соединения в треугольнике между каждым помещением, и каждый центр обработки данных имел подключение к Интернету. Два межсетевых экрана, по одному в каждом центре обработки данных, были настроены как устойчивая пара и работали в этом качестве в течение многих лет. Однажды интернет-сервис вышел из строя, и расследование показало, что вторичный блок потерял связь с первичным и переключился на первичный. Наличие двух активных первичных адресов привело к разделению потоков трафика и, следовательно, к отключению.
Предсказуемый
Оглядываясь назад, это было полностью предсказуемо. Между устройствами поддерживалось отношение «первичный / вторичный», чтобы первичное устройство отправляло «контрольный сигнал» вторичному каждые несколько секунд; если вторичный не смог получить сердцебиение три раза, он просыпался и действовал как первичный. Поскольку устройства находились в разных центрах обработки данных, они были подключены с помощью различных технологий: патч-корд LAN в коммутатор, в оптоволоконный приемопередатчик, в оптоволокно для телефонной связи, а затем то же самое в обратном порядке на другом конце.
Неисправность любого из этих элементов может привести к тому, что сетевые устройства переконфигурируют свою топологию для переключения данных в обратном направлении по оптоволоконному треугольнику, при этом изменение приведет к тому, что сетевая вспышка будет достаточно продолжительной, чтобы пропустить три тактовых импульса. Фактически, единственной одобренной конфигурацией для первичного / вторичного межсоединения был перекрестный кабель Ethernet от одного устройства к другому: код аварийного переключения был написан с предположением, что, помимо, возможно, очень маловероятной внезапной неисправности коммутационного шнура, первичное становится невидимым. для вторичного означало, что первый умер.
Многие из нас сталкивались с подобными случаями, когда что-то, что, как мы ожидали, могло выйти из строя, этого не произошло. Столь же часто встречаются случаи, когда аварийное переключение работает нормально, но затем возникают проблемы с аварийным переключением, которые могут быть столь же проблематичными. Я вспоминаю глобальную WAN, над которой я когда-то работал, где по какой-то причине переключение с первичного на вторичный происходило так быстро, что вы не заметили никакого прерывания (единственной подсказкой было предупреждение с консоли мониторинга), но была пауза на несколько секунд при отказе назад.
В примере с брандмауэром, даже когда соединение было восстановлено, устройства не могли повторно синхронизироваться без перезагрузки: помните, что единственным поддерживаемым сценарием сбоя было полное отключение основного, а это означало, что только во время загрузки он проверял, какой роль, которую играл его партнер, чтобы он мог действовать соответственно. Пока кто-нибудь не выключил и не включил снова, проблема не могла исчезнуть.
Таким образом, чтобы сделать наши устойчивые системы действительно устойчивыми, нам нужно сделать три вещи.
Прежде всего, стоит задуматься о событиях с «черным лебедем». Возможно, мы не можем позволить себе массу времени и усилий, чтобы рассмотреть такие маловероятные риски, но, по крайней мере, мы должны принять сознательное решение о том, сколько или как мало мы будем делать в этом отношении: управление рисками – это все о рассуждениях. и принимать такие осознанные решения.
Экспертиза
Во-вторых, если у нас нет точных знаний о том, как работают наши системы и их механизмы переключения при отказе, мы должны привлекать людей, которые это делают, и извлекать пользу из их знаний и опыта … и пока мы этим занимаемся, мы должны прочтите руководство: в девяти случаях из десяти оно расскажет нам, как настраивать вещи, даже если не объяснит почему.
Однако, наконец, нам нужно что-то тестировать – тщательно и регулярно. В нашем примере с брандмауэром должны быть рассмотрены все возможные режимы отказа: если отказ одного из нескольких компонентов может вызвать сбой, почему бы не протестировать их все? И когда мы тестируем, нам нужно делать это по-настоящему: мы не просто тестируем аварийное переключение в лаборатории и затем устанавливаем комплект в производственный шкаф, мы также тестируем его, когда он уже установлен.
Это может потребовать от нас убедить бизнес в том, что нам нужен простой – или, по крайней мере, возможное время простоя из-за неудачного теста – но, если у руководства есть хоть какой-то здравый смысл, они будут убеждены, что утвержденное отключение в течение предсказуемого временного окна с технической командой стоять и наблюдать, как ястребы, гораздо лучше, чем неожиданное, но вполне предсказуемое отключение, когда что-то действительно ломается, и устойчивость оказывается неработоспособной.
Тестирование
Да, и когда вы тестируете аварийное переключение и аварийное переключение, запустите несколько дней в состоянии аварийного переключения, если можете: многие проблемы не проявляются мгновенно, и вы всегда узнаете больше в многодневном аварийном переключении, чем в том, которое длится только пара минут. Не забывайте также о слове «регулярно», которое я использовал вместе со словом «тщательно». Даже если мы знаем, что не было никаких изменений в конкретном компоненте, вполне может иметь место некоторый косвенный эффект от изменения чего-то еще. Что-то, что раньше было устойчивым, могло стать менее устойчивым или даже неустойчивым, потому что что-то изменилось, а мы не осознали последствий, поэтому регулярное тестирование устойчивости является абсолютно ключевым.
Потому что, если что-то не является устойчивым, это, как правило, не из-за некоторого скрытого потенциального режима отказа, который почти невозможно предвидеть и / или трудно или невозможно протестировать. В большинстве случаев это произойдет из-за того, что что-то пошло не так – или что-то было неправильно настроено – так, как вы могли бы эмулировать в тесте. ®
