Адвокат дьявола

Альфа-банк надежен, как танк,
А Гамма-банк надежен как банк!

Виктор Пелевин, Числа

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



Если посмотреть вакансии разработчиков в банке, то вполне можно увидеть там среди требований знания Cassandra, MongoDB и других платформ, которые никак не внушают мыслей о 100% доступности. Да и такие СУБД как Oracle или Microsoft SQL Server где-то устанавливают на кластер из дорогих серверов, подключённых к самым надёжным и высокопроизводительным массивам, а где-то на обычную виртуальную машину в ферме из самого что ни на есть commodity.

Причины очевидны избыточные решения дороги. Но как найти компромисс между стоимостью платформы и её надёжностью?


Давным-давно, когда информационных систем на предприятии было немного, инфраструктура для каждой системы была произведением искусства. Со временем систем стало больше, поддерживать несколько сотен разных конфигураций оборудования и программного обеспечения стало накладно, и инфраструктурные подразделения пришли к стандартизации. Например, набор инфраструктурных решений для реляционной СУБД, которые могут использовать приложения, может выглядеть так:

• серверы класса hi-end с дисковыми массивами класса hi-end плюс синхронная репликация;
• серверы класса midrange с дисковыми массивами класса midrange плюс синхронная репликация;
• серверы класса midrange с дисковыми массивами класса midrange плюс асинхронная репликация;
• commodity-серверы с дисковыми массивами класса midrange без репликации.

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

Можно составить список самых важных приложений, которые должны работать во что бы то ни стало. При этом возникает две проблемы:

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

Некоторые приложения могут не войти в список самых важных потому, что про них не подумали. Например, все помнят про процессиниг банковских карт, но никто не помнит про проверку клиентов по чёрным спискам, которая должна работать при каждой операции. В результате отказ такой системы становится неприятной неожиданностью и приводит к серьёзным проблемам.

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

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

• Platinum;
• Gold;
• Silver;
• Bronze.

Или так:

• Mission critical;
• Business critical;
• Business operational;
• Office productivity.

Эти четыре уровня прекрасно ложатся на 4 разных конфигурации инфраструктуры. Осталось только отнести каждое приложение к нужному классу.

При оценке важно соблюдать два правила:

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

Формулировки вопросов, формирующих оценку, должны предусматривать возможность верификации ответов. Разумеется, критерии всё равно основаны на экспертной оценке, но эксперт, по крайней мере, может объяснить, почему он поставил именно такую оценку.

Что определяет уровень критичности?

• Приоритет обслуживания при массовых инцидентах. Безусловно, любую систему нужно восстанавливать после аварии, но если авария задела несколько систем, то сначала нужно восстановить наиболее критичные.
• Типовые значения SLA (service level agreement). Если простой системы приносит убытки, то правильный путь не жаловаться на администраторов, а повышать её уровень критичности.
• Стандартные инфраструктурные решения. Каждое из перечисленных выше решений обладает определёнными характеристиками надёжности, обеспечивающими скорость восстановления при сбоях, а также определённой стоимостью.

В мировой практике сложилось примерно такое распределение:



Это не значит, что на вашем предприятии распределение систем по классам должно быть именно таким. Но в любом случае если в класс Mission critical попало больше 15% эксплуатируемых систем, это повод серьёзно задуматься.

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

Давайте рассмотрим несколько банковских систем.

Расчётная система обеспечивает (сюрприз!) расчёты между клиентами юридическими лицами. Если вдруг крупный корпоративный клиент не сможет сделать платёж контрагенту, то банк потеряет весьма существенную сумму, поэтому расчётная система, без сомнения, попадёт в высший класс критичности.

Возьмём карточный процессинг. Если сотня-другая клиентов не смогут расплатиться картой, потери банка будут невелики, но такой массовый отказ в обслуживании недопустим сам по себе.

Теперь возьмём систему, которая ведёт вклады. Если остановится эта система, то убытки банка вновь будут невелики, а отказ в обслуживании не будет столь массовым, как в случае процессинга. Но нужна ли нам передовица в газете с заголовком Банк отказывается выдавать вклады? Вопрос риторический.

Наконец, возьмём главную бухгалтерскую книгу. Если вдруг с ней что-то случится, то клиенты ничего не заметят, т.к. эта система в обслуживании клиентов вообще не участвует. Но стоит задержать сдачу баланса, как санкции Центробанка не заставят себя ждать.

Итак, негативные последствия от простоя системы можно разделить на 4 класса:

• Экономические (непосредственные убытки);
• Клиентские (отказ в обслуживании);
• Репутационные (негативные реакции в средствах массовой информации);
• Юридические (от предупреждений и штрафов до судебных исков и отзыва лицензии).

Для каждого класса последствий следует сформулировать критерии тяжести и присвоить им оценки от 0 до 4. Например, таблица может выглядеть так:


Разумеется, все цифры условны, все методики подсчёта основываются исключительно на экспертной оценке, а простор для споров, что считать региональными СМИ и как относиться к негативным статьям в популярных блогах, поистине безграничен. Но в крупной корпорации наверняка найдётся и юридический отдел, и PR-служба, которые с готовностью выскажут компетентное мнение.

Следующим шагом нужно выбрать временные интервалы, на которых мы будем оценивать убытки. Например, час, 4 часа, 8 часов, 24 часа. Эти интервалы произвольны и не имеют никакого отношения к SLA, заключённым на оцениваемые системы. Хотя в дальнейшем было бы правильно привязать типовые SLA именно к этим интервалам.

Теперь владелец каждой системы заполняет матрицу из 16 клеток. В таблице ниже числа даны для примера. Единственное, что принципиально важно, оценка последствий для более длинного интервала не может быть меньше, чем оценка для более короткого интервала.


Чтобы из этой матрицы получить окончательную оценку, осталось выполнить три шага.
Шаг первый для каждого временного интервала выбираем максимальную оценку:


Шаг второй: по матрице транслируем полученные оценки в классы критичности:


Для данной системы получаем следующие оценки:


И, наконец, из всех полученных оценок выбираем максимальную в данном случае оцениваемая система должна быть отнесена к классу Business critical.

Получив эти оценки, мы вполне можем обоснованно выбирать для каждой системы то или иное инфраструктурное решение.

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

Если система обеспечивает работоспособность другой системы, то её класс критичности не может быть ниже, чем класс зависимой системы. Например, Active Directory вообще никак не относится к бизнесу. Но если вдруг она встанет, то последствия для многих бизнес-приложений будут самые печальные, и поэтому AD однозначно относится к классу Mission critical.

Убытки, понесённые в результате простоя системы, не могут быть ниже, чем убытки, нанесённые прерыванием бизнес-процесса, который эта система обеспечивает. В свете этого правила очень интересно бывает оценить корпоративную систему электронной почты, ибо внезапно оказывается, что на неё завязан обмен критичной информацией.

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

Снабдите свои системы ярлыками и да будет ваша инфраструктура не менее надёжна, чем нужно, но и не дороже, чем можно!

Это ж надо, ни к кому не обращаясь, громко сказала она. Это ж надо! Так прямо и написано главной задачей общества является извлечение прибыли винтересах акционеров. Ну вы подумайте! Ничего не боятся!

Юлий Дубов, Меньшее зло

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



Конечно, СУБД так никто не сравнивает, ибо их сильные и слабые стороны хорошо известны. Как правило, сравнению подлежат платформы, решающие какую-либо прикладную задачу. Встатье я покажу методику, которая при этом используется, на примере баз данных как предмета, не понаслышке знакомого читателям Хабра. Итак,

Мотивация

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

Естественно, хочется заплатить поменьше, а получить побольше. Однако необходимо решить, что важнее меньше заплатить или больше получить, и приписать каждому узлу вес. Допустим, что нам важнее качественное решение, чем дешёвое, и припишем узлу Стоимость вес 40%, а узлу Возможности 60%.



В крупных корпорациях обычно всё наоборот вес стоимости не опускается ниже 50%, а может быть и больше 60%. В модельном примере важно лишь то, что суммарный вес дочерних узлов любого родительского узла должен быть 100%.

Отсекающие условия

Сайту db-engines.com известно около 500 систем управления базами данных. Естественно, если выбирать целевую платформу из такого количества вариантов, то может получиться обзорная статья, но не коммерческий проект. Для того, чтобы сократить пространство выбора, формулируются отсекающие критерии, и если платформа этим критериям не удовлетворяет, то она не рассматривается.

Отсекающие критерии могут относиться к технологическим особенностям, например:

• ACID-гарантии;
• реляционная модель данных;
• поддержка языка SQL (обратите внимание, это не то же самое, что реляционная модель);
• возможность горизонтального масштабирования.

Могут быть критерии общего характера:

• наличие коммерческой поддержки в России;
• открытый исходный код;
• наличие платформы в Реестре Минкомсвязи;
• наличие платформы в каком-нибудь рейтинге (например, в первой сотне рейтинга db-engines.com);
• наличие экспертов на рынке (например, по результатам поиска названия платформы врезюме на сайте hh.ru).

В конце концов, могут быть критерии, специфичные для предприятия:

• наличие специалистов в штате;
• совместимость с системой мониторинга X или с системой резервного копирования Y, накоторую завязано всё сопровождение...

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

Оценка стоимости

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

Если системы примерно одного класса (например, MicrosoftSQLServer и PostgreSQL), то для простоты можно считать, что количество оборудования для того и другого решения будет примерно одинаковым. Это позволит не оценивать оборудование, сэкономив тем самым массу времени и сил. Если же приходится сравнивать совершенно разные системы (скажем, Oracle vs. Redis), то очевидно, что для корректной оценки необходимо сделать сайзинг (расчёт количества оборудования). Сайзинг несуществующей системы занятие весьма неблагодарное, поэтому такого сравнения всё же стараются недопускать. Сделать это просто: в отсекающих условиях пишутся нулевая потеря данных и реляционная модель или же наоборот нагрузка от 50 тысяч транзакций в секунду.

Для оценки лицензий достаточно запросить увендора или его партнёров стоимость лицензии нафиксированное количество ядер и поддержки на фиксированный срок. Как правило, укомпаний уже выстроены прочные отношения с вендорами программного обеспечения, и если отдел эксплуатации БД не может ответить на вопрос о стоимости самостоятельно, то для получения этой информации достаточно одного письма.

У разных вендоров могут быть разные метрики лицензирования: по количеству ядер, объёму данных или количеству узлов. Standby-база может быть бесплатной, а может лицензироваться так же, как и основная. Если только обнаружились какие-то различия в метриках, придётся детально описывать модельный стенд и считать стоимость лицензий для стенда.

Важный момент для корректного сравнения одинаковые условия поддержки. Скажем, поддержка Oracle стоит 22% от стоимости лицензии вгод, а за поддержку PostgreSQL можно неплатить. Корректно ли так сравнивать? Нет, потому что у ошибки, которая не может быть устранена собственными силами, совершенно разные последствия: в первом случае специалисты поддержки быстро помогут её устранить, а во втором случае есть риск задержки проекта или простоя готовой системы втечение неопределённого срока.

Уравнять условия расчёта можно тремя способами:

1. Использовать Oracle без поддержки (в реальности такого не бывает).
2. Купить поддержку на PostgreSQL например, у компании Postgres Professional.
3. Заложить в расчёт риски, связанные с отсутствием поддержки.

Например, расчёт рисков может выглядеть так: в случае неустранимого сбоя базы данных простой системы составит 1 рабочий день. Планируемая прибыль от использования системы 40млрд монгольских тугриков в год, частота аварий оценивается как 1/400, таким образом, риск отсутствия сопровождения оценивается примерно в 100 млн монгольских тугриков в год. Очевидно, что планируемая прибыль и оценочная частота аварий величины виртуальные, но гораздо лучше иметь такую модель, чем не иметь никакой.

В действительности система может быть слишком важна, и репутационные потери отдлительного простоя окажутся недопустимыми, поэтому поддержка потребуется. Если же простой допускается, то отказ от поддержки иногда может быть неплохим способом сэкономить.

Допустим, что после всех расчётов стоимость эксплуатации платформы A в течение 5 лет оказалась 800 млн монгольских тугриков, стоимость эксплуатации платформы B 650млн тугриков, а стоимость эксплуатации платформы C 600млн тугриков. Платформа C как победитель получает за стоимость полновесный балл, а платформы A и B чуть меньше, пропорционально тому, во сколько раз они дороже. В данном случае 0.75и 0.92баллов соответственно.

Оценка возможностей

Оценка возможностей делится на множество групп, количество которых ограничено лишь фантазией того, кто делает оценку. Оптимальным вариантом кажется деление возможностей покомандам, которые этими возможностями будут пользоваться; в нашем примере это разработчики, администраторы и офицеры информационной безопасности. Допустим, что веса этих функций распределяются как 40:40:20.

К функциям разработки можно отнести:

• удобство манипуляции данными;
• масштабирование;
• наличие вторичных индексов.

Список критериев, как и их веса, очень субъективны. Даже при решении одной и той же задачи эти списки, веса пунктов и ответы будут существенно отличаться в зависимости от состава вашей команды. Так, например, Facebook для хранения данных использует MySQL, а Instagram построен на базе Cassandra. Вряд ли разработчики этих приложений заполняли такие таблицы. Можно лишь догадываться, что Марк Цукерберг выбрал полноценную реляционную модель, заплатив за это необходимостью прикладного шардирования, в то время как Кевин Систром заложил масштабирование средствами платформы, пожертвовав удобством доступа к данным.

К функциям администрирования относятся:

• возможности системы резервного копирования;
• удобство мониторинга;
• удобство управления мощностями дисками и узлами;
• возможности репликации данных.

Обратите внимание, что формулировки вопросов должны допускать количественную оценку. Можно даже договориться, как оценивать ту или иную функцию. Давайте, например, попробуем поставить оценки инструментам резервного копирования на примере инструментов, поставляемых с СУБД Oracle:


Если чёткие критерии оценки отсутствуют, имеет смысл попросить нескольких экспертов выставить оценки, а затем их усреднить.

Наконец, просто перечислим функции информационной безопасности:

• наличие политик управления паролями;
• возможность подключения внешних средств аутентификации (LDAP, Kerberos);
• ролевая модель доступа;
• возможности аудита;
• шифрование данных на диске;
• шифрование при передаче по сети (TLS);
• защита данных от администратора.

Тестирование производительности

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

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

Во-вторых, производительность системы достаточно сильно зависит от того, под какую платформу изначально написан код и на каком оборудовании проводился тест. Мне приходилось видеть множество тестов, где Oracle сравнивали сPostgreSQL. Результаты от безоговорочного превосходства одной системы до столь же безоговорочного превосходства другой.

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

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

Результат

Наконец, результатом всей проделанной работы должна стать электронная таблица, где все оценки сведены, перемножены и просуммированы:



Как вы понимаете, изменением весов и корректировкой оценок можно добиться любого требуемого результата, но это уже совсем другая история