Разработка информационных систем: фактор надежности

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

Если считать, что все указанное означает «работать нормально», то термин «на­дежность» будет иметь значение, грубо говоря, «продолжать работать нормально даже в случае проблем».


Оглавление статьи[Показать]


Возможные проблемы называются сбоями, а системы, созданные в расчете на них, называются устойчивыми к сбоям. Этот термин способен ввести в некоторое заблуждение: он наводит на мысль, что можно сделать систему устойчивой ко всем возможным видам сбоев. Однако на практике это неосуществимо. Если наша пла­нета (и все находящиеся на ней серверы) будет поглощена черной дырой, то для обеспечения устойчивости к такому «сбою» потребовалось бы размещение данных в космосе — удачи вам в одобрении подобной статьи бюджета. Так что имеет смысл говорить об устойчивости лишь к определенным типам сбоев.

Обратите внимание, что сбой (fault) и отказ (failure) — разные вещи. Сбой обычно определяется как отклонение одного из компонентов системы от рабочих харак­теристик, в то время как отказ — ситуация, когда вся система в целом прекращает предоставление требуемого сервиса пользователю. Снизить вероятность сбоев до нуля невозможно, следовательно, обычно лучше проектировать механизмы устойчивости к сбоям, которые бы предотвращали переход сбоев в отказы. В моем блоге мы рассмотрим несколько методов создания надежных систем из ненадеж­ных составных частей.

Парадоксально, но в подобных устойчивых к сбоям системах имеет смысл по­высить частоту сбоев с помощью их умышленной генерации — например, путем прерывания работы отдельных, выбранных случайным образом процессов без предупреждения. Многие критические ошибки фактически происходят из-за недостаточной обработки ошибок; умышленное порождение сбоев гарантирует постоянное тестирование механизмов обеспечения устойчивости к ним, что повы­шает уверенность в должной обработке сбоев при их «естественном» появлении. Пример этого подхода — сервис Chaos Monkey компании Netflix.

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

 

Аппаратные сбои

Когда речь идет о причинах отказов систем, первым делом в голову приходят аппа­ратные сбои. Фатальные сбои винчестеров, появление дефектов ОЗУ, отключение электропитания, отключение кем-то не того сетевого кабеля. Любой, кто имел дело с большими центрами обработки и хранения данных, знает, что подобное проис­ходит постоянно при наличии большого количества машин.

Считается, что среднее время наработки на отказ (mean time to failure, MTTF) винчестеров составляет от 10 до 50 лет. Таким образом, в кластере хране­ния с 10 тысячами винчестеров следует ожидать в среднем одного отказа жесткого диска в день.

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

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

Однако по мере роста объемов данных и вычислительных запросов приложений все больше программ начали использовать большее количество машин, что привело к пропорциональному росту частоты отказов оборудования. Более того, на многих облачных платформах, таких как Amazon Web Services (AWS), экземпляры вирту­альных машин достаточно часто становятся недоступными без предупреждения, поскольку платформы отдают предпочтение гибкости и способности быстро адаптироваться перед надежностью одной машины.

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

 

Программные ошибки

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

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

Программная ошибка, приводящая к фатальному сбою экземпляра сервера приложения при конкретных «плохих» входных данных. Например, возьмем секунду координации 30 июня 2012 года, вызвавшую одновременное зависание множества приложений из-за ошибки в ядре операционной системы Linux. Выходит из-под контроля процесс, полностью исчерпавший какой-либо общий ресурс: время CPU, оперативную память, пространство на диске или полосу про­пускания сети.

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

Каскадные сбои, при которых крошечный сбой в одном компоненте вызывает сбой в другом компоненте, а тот, в свою очередь, вызывает дальнейшие сбои.

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

Быстрого решения проблемы систематических ошибок в программном обеспе­чении не существует. Может оказаться полезным множество мелочей, таких как: тщательное обдумывание допущений и взаимодействий внутри системы; всесто­роннее тестирование; изоляция процессов; предоставление процессам возможно­сти перезапуска после фатального сбоя; оценка, мониторинг и анализ поведения системы при промышленной эксплуатации. Если система должна обеспечивать выполнение какого-либо условия (например, в очереди сообщений количество входящих сообщений должно быть равно количеству исходящих), то можно организовать постоянную самопроверку во время работы и выдачу предупреждения в случае обнаружения расхождения.

 

Человеческий фактор

Проектируют и создают программные системы люди; ими же являются и операто­ры, обеспечивающие их функционирование. Даже при самых благих намерениях люди ненадежны. Например, одно исследование крупных интернет-сервисов по­казало, что основной причиной перебоев в работе были допущенные операторами ошибки в конфигурации, в то время как сбои аппаратного обеспечения (серверов или сети) играли какую-либо роль лишь в 10-25 % случаев.

Как же обеспечить надежность нашей системы, несмотря на ненадежность людей? Оптимальные системы сочетают в себе несколько подходов.

Проектирование систем таким образом, который минимизировал бы возмож­ности появления ошибок. Например, грамотно спроектированные абстрак­ции, API и интерфейсы администраторов упрощают «правильные» действия и усложняют «неправильные». Однако если интерфейсы будут слишком жестко ограничены, то люди начнут искать пути обхода; это приведет к нивелированию получаемой от таких интерфейсов выгоды, так что самое сложное здесь — со­хранить равновесие.

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

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

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

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

 

Насколько важна надежность?

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

Создатели даже «некритичных» приложений несут ответственность перед поль­зователями. Возьмем, например, родителей, хранящих все фотографии и видео своих детей в вашем приложении для фото. Как они будут себя чувствовать, если база данных неожиданно окажется испорченной? Смогут ли они восстановить данные из резервной копии?

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

 

Вас заинтересует / Intresting for you:

Подходы к разработке современн...
Подходы к разработке современн... 1553 просмотров Doctor Sun, 20 Jan 2019, 11:07:45
Разработка и исследование инфо...
Разработка и исследование инфо... 1367 просмотров Денис Wed, 27 Mar 2019, 03:15:40
Разработка информационных сист...
Разработка информационных сист... 3338 просмотров Александров Попков Mon, 21 Jan 2019, 10:19:21
Средства моделирования в компь...
Средства моделирования в компь... 1181 просмотров Александров Попков Sun, 17 Mar 2019, 15:50:15
Печать
Войдите чтобы комментировать

Vovan_ST аватар
Vovan_ST ответил в теме #10061 2 года 9 мес. назад
Отлично описана "Надёжность" как фактор (требование) при разработке и проектировании информационных систем!