уровне приложений, например количество размещенных заказов, оказываются в собственных аналитических системах вроде Omniture, которые зачастую доступны только избранным участникам бизнес-процессов, или же попадают в те страшные хранилища данных, где им и суждено будет сгинуть. Получить отчеты из подобных систем в реальном времени зачастую невозможно, хотя ситуация начинает выправляться. В то же время такие системные показатели, как время отклика, частота появления ошибок и загруженность центрального процессора, хранятся в системах, к которым могут иметь доступ рабочие команды. Эти системы обычно доступны для составления отчетов в реальном времени, и, как правило, их суть состоит в побуждении к немедленному вызову действия.
Исторически сложилось так, что узнавать о бизнес-показателях на день или два позже было вполне приемлемо, поскольку обычно все равно быстро реагировать на эти данные и предпринимать что-нибудь в ответ мы не могли. Но теперь мы работаем в такой обстановке, когда многие из нас могут выдать и несколько выпусков в день. Теперь команды оценивают себя не по тому, сколько пунктов они могут завершить, а по тому, сколько времени будет потрачено на то, чтобы код из ноутбука ушел в производство. В такой среде, чтобы совершать правильные действия, нужно иметь все показатели под рукой. Как ни странно, в отличие от наших операционных систем, те самые системы, которые сохраняют бизнес-показатели, зачастую не настроены на незамедлительный доступ к данным.
Так зачем же обрабатывать оперативные и деловые показатели одинаково? В конечном счете оба типа показателей разбиваются на события, которые свидетельствуют о чем-то случившемся в момент времени X. Следовательно, если есть возможность унифицировать системы, используемые для сбора, объединения и хранения этих событий и открывающие к ним доступ для составления отчетов, то мы получим намного более простую архитектуру.
Частью подобного решения может стать Riemann — сервер событий, позволяющий на довольно высоком уровне выполнять объединение и маршрутизацию событий. В этой же области работает и средство Suro, являющееся конвейером данных компании Netflix. В Suro явным образом обрабатываются как показатели, связанные с пользовательским поведением, так и большинство оперативных данных, фиксируемых в журналах приложений. Затем эти данные могут быть направлены различным системам вроде системы Storm, предназначенной для выполнения анализа в реальном времени, системы Hadoop, служащей для пакетной обработки в автономном режиме, или системы Kibana, предназначенной для анализа журнальных записей.
Многие организации движутся в совершенно ином направлении: отказываются от использования цепочек специализированных инструментальных средств для разных типов показателей и склоняются к применению более универсальных систем маршрутизации событий, способных на существенное расширение. Эти системы используются для предоставления намного большей гибкости при реальном упрощении нашей архитектуры.
Итак, мы усвоили довольно большой объем информации! Я попытаюсь свести содержимое главы к нескольким легко воспринимаемым советам.
Для каждого сервиса:
• отслеживайте как минимум возвращающееся время отклика. Затем займитесь частотой появления ошибок, после чего приступайте к работе над показателями на уровне приложения;
• отслеживайте приемлемость всех ответов от нижестоящих сервисов, включая как минимум время отклика при вызовах нижестоящих сервисов, а в лучшем случае — частоту появления ошибок. Помочь в этом могут такие библиотеки, как Hystrix;
• приведите к общему стандарту способ и место сбора показателей;
• помещайте регистрационные записи в стандартном месте и по возможности используйте для них стандартный формат. Если для каждого сервиса будут применяться разные форматы, объединение будет сильно затруднено;
• отслеживайте показатели исходной операционной системы, чтобы можно было выявлять отклоняющиеся от нормы процессы и планировать использование ресурсов.
Для системы:
• объединяйте показатели на уровне хоста, например показатели загруженности центрального процессора с показателями на уровне приложения;
• выбирайте такие инструменты хранения показателей, которые позволяют выполнять их объединение на системном или сервисном уровне и извлекать их для отдельно взятых хостов;
• выбирайте такие инструменты хранения показателей, которые позволяют сохранять данные достаточно долго для того, чтобы можно было отследить тенденции в работе вашей системы;
• используйте для объединения и хранения регистрационных записей единое средство, поддерживающее обработку запросов;
• строго придерживайтесь стандартизации при использовании идентификаторов взаимосвязанности;
• разберитесь, чему для перехода к действию требуется вызов, и выстройте соответствующим образом структуру оповещения и вывода на панель отслеживания;
• исследуйте возможность унификации способов объединения всевозможных показателей, выяснив, пригодятся ли вам для этого такие средства, как Suro или Riemann.
Я также попытался обозначить направление, в котором развивается мониторинг: уход от систем, специализирующихся на выполнении какой-нибудь одной задачи, и переход к разработке типовых систем обработки событий, позволяющих составить более целостное представление о вашей системе. Это очень интересная и постоянно развивающаяся область, и хотя ее полноценное исследование не входит в задачи данной книги, я надеюсь, что для начала полученной вами информации вполне достаточно. При желании расширить познания можете обратиться к моей более ранней публикации Lightweight Systems for Realtime Monitoring (O’Reilly), где глубже рассматриваются как некоторые из этих, так и многие другие идеи.
В следующей главе мы коснемся другого целостного представления наших систем и рассмотрим ряд уникальных преимуществ, предоставляемых архитектурами с высокой степенью детализации в области решения задач обеспечения безопасности, а также ряд сложностей, с которыми при этом придется столкнуться.
9. Безопасность
Нам уже знакомы истории о пренебрежении мерами безопасности крупномасштабных систем, приведшие к выставлению наших данных на обозрение всякого рода сомнительным личностям. Но в последнее время откровения вроде тех, которыми поделился Эдвард Сноуден, повысили нашу осведомленность о ценности данных о нас, которые хранятся в различных компаниях, а также ценности данных о клиентах, которые мы сами храним в создаваемых нами системах. В этой главе будет дан краткий обзор ряда аспектов безопасности, которые следует принимать во внимание при разработке систем. Несмотря на то что предоставляемая информация не является исчерпывающей, она покажет ряд доступных вам основных вариантов и станет отправной точкой для ваших собственных дальнейших исследований.
Нам нужно подумать о том, в какой защите нуждаются наши данные при их перемещении из одной точки в другую и какая им нужна защита, когда они просто хранятся в системе. Нужно продумать вопросы обеспечения безопасности используемых операционных систем, а также сетевого оборудования. Перед нами обширное поле для размышлений и реальных действий! В какой мере нам следует обезопасить свою систему? Как определить критерии достаточности мер безопасности?
Но, кроме этого, нужно подумать и о людях. Как мы узнаем о том, кто есть кто и как следует действовать дальше? И какое отношение все это имеет к обмену данными между нашими серверами? С этого и начнем.
Когда речь заходит о людях и о том, что вступает во взаимодействие с нашей системой, основными понятиями являются аутентификация и авторизация. В контексте безопасности под аутентификацией понимается процесс подтверждения того, что сторона, заявившая о себе, таковой на самом деле и является. Для человека аутентификация обычно сводится к набору имени и пароля. Предполагается, что только этот человек имеет доступ к такой информации и потому лицо, набравшее ее, и должно быть данным человеком. Разумеется, существуют и другие, более сложные системы. Мой телефон теперь позволяет мне использовать отпечаток пальца, чтобы я мог подтвердить свою личность. В общем смысле, когда речь заходит о том, кто или что проходит аутентификацию, мы называем данную сторону принципалом.
Авторизация представляет собой механизм, с помощью которого мы переходим от принципала к действию, которое ему разрешено совершить. Зачастую, когда принципал проходит аутентификацию, нам предоставляется информация о нем, которая поможет принять решение о том, что ему будет позволено делать. Нам, к примеру, сообщат, в каком отделе или офисе он работает, то есть мы получим те части информации, которые могут использоваться нашей системой для принятия решения о том, что он может, а чего не может делать.
Если речь идет о единых, монолитных приложениях, то аутентификацией и авторизацией для вас занимается само приложение. К примеру, Django, веб-среда языка Python, поставляется с уже готовой системой управления пользователями. Что же касается распределенных систем, нам нужно подумать над созданием более совершенных схем. Мы не хотим, чтобы все регистрировались в различных системах отдельно, применяя для каждой системы разные имена пользователей и пароли. Наша цель состоит в создании единого идентификатора, позволяющего проходить аутентификацию только один раз.
Общепринятым подходом к аутентификации и авторизации является использование какого-либо из решений единого входа (SSO). Соответствующие возможности в данной области предоставляются SAML — реализации, доминирующей в области промышленных предприятий, и OpenID Connect. В них применяются более или менее одинаковые основные понятия, хотя терминология немного различается. В данной главе будут использоваться термины, применяемые в SAML.