Предыстория (2008 г.)

По работе часто приходилось разбираться с производительностью серверов БД Oracle. После выхода Oracle 10g задача по мониторингу и диагностике проблем с производительностью значительно упростилась – с помощью истории активных сессий (Active Session History, ASH) стало возможно узнать, что происходило с БД в прошлом, что творится на сервере в данный момент, и даже прогнозировать, что будет происходить с нагрузкой в будущем.

Но, во-первых, процесс миграции на новую версию достаточно длительный, и некоторые заказчики продолжали использовать старые версии. А во-вторых, средства визуализации истории активных сессий от Oracle, которые имелись в наличии:

• Требовали некоторых телодвижений по их установке и настройке – это Oracle Enterprise Manager Console (DB Console) или Oracle Enterprise Manager Grid Control (сейчас Oracle Enterprise Manager Cloud Control). DB Console из моей (и не только) практики требовал для установки применения очень сильных админских заклятий. Также в целях экономии ресурсов не все хотят ставить на сервера БД дополнительные сервисы или разворачивать на своей площадке отдельную инфраструктуру для мониторинга;
• Обладали рядом архитектурных недостатков. К примеру, в случае зависания сервера БД доступ к информации из истории активных сессий посредством Oracle Enterprise Manager Console становился невозможным, и оперативно выяснить, что «что-то пошло не так» (с) было практически нереально;
• Отсутствовала функциональность в части сохранения данных мониторинга и последующего его анализа на своей площадке.

Из сторонних бесплатных средств, похожая функциональность была реализована в утилите ASHMON за авторством Kyle Hailey. Но функционал был только для просмотра, и работала она под одну платформу – Windows.

В общем, после рассмотрения всех доступных на тот момент вариантов, было принято волевое решение собирать свой «велосипед» из подручных материалов.

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

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

Приветствую всех читателей! Сегодня хотелось бы поговорить об основных принципах мониторинга бизнес-приложений, которые ежедневно используют многие компании по всему миру. Само понятие «бизнес-приложение» следует понимать как программный комплекс, который обеспечивает поддержку определенного бизнес-процесса компании.

Самый типичный пример архитектуры современного приложения — т.н. «трёхзвенка», т.е. веб-сервер, сервер приложений и сервер БД, следовательно, каждый из этих компонентов будет чуть менее чем полностью оказывает влияние на работу всего приложения. Если рассматривать именно такую конфигурацию, то со своего опыта могу сказать, что чаще всего возникает ситуация, которая в утрированном виде выглядит так:



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

Дефекты программного кода

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

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

Треугольник мнений

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

Считается, что именно от CIO исходит больше всего недоверия к аутсорсингу. Его типовая позиция вполне понятна: у меня должна быть собственная команда, с которой я смогу выполнять все поставленные руководством задачи. И чем больше эта команда, тем эффективнее работа ИТ, тем больше ответственность CIO и круче его положение среди коллег, тем больше денег проходит через его руки и оседает в бонусном фонде. О том, насколько эта позиция правильная, судить инвестору или бизнес-руководителю.

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

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

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

В этой статье мы хотим поделиться опытом внедрения системы управления программой лояльности Siebel Loyalty на базе Oracle Siebel CRM для крупной розничной сети магазинов.

Основные функциональные требования к системе:

• Расчет скидок, применение ценовых акций
• Процессинг чеков (начисление/списание баллов)
• Автоматизация процессов управления картами лояльности
• Ведение клиентской базы
• Проведение маркетинговых кампаний

И остановимся мы на одном из требований – автоматизации бизнес-процессов по управлению картами лояльности.

Поддержкой клиентов по вопросам работы с картами лояльности занимается Сервисный Центр компании. Все действия по карте, выполняемые сотрудниками, должны фиксироваться в CRM системе.

Бизнес-процессы по работе с картами делятся на следующие типы:

• Поиск клиента
• Изменение данных клиента
• Выдача карты
• Замена карты
• Изменение владельца карты
• Блокировка карты

Прилично удивился, столкнувшись с этапом Due Diligence в конкурсной документации на аутсорсинг ИТ-сервисов. Неожиданности в конкурсных процедурах всегда вызывают определённый напряг, так как они могут означать, что придётся быстро пересобрать привычную сервисно-процессную конструкцию, а это сродни тому, как ребёнку сложить гигантский пазл из мелких и трудноразличимых деталей. Раньше мне всегда казалось, что процедура Due Diligence применяется при оценке стоимости компании перед её покупкой или в рамках «айпиошного» проекта. По сути – это оценка надёжности и коммерческой привлекательности будущей сделки. Ну и выглядеть это должно было так: приходят в компанию умные консультанты-аналитики, ворошат годовую отчётность, проверяют прогнозы, оценивают риски и выносят свой вердикт. Мы, как аутсорсинговый партнёр, прошли-таки эту процедуру, правда, не при оценке компании, а в рамках конкурсной процедуры ИТ-тендера. Это был скорее технический Due Diligence.

Добрый день. Мы продолжаем серию статей «из-за кулис» Jet Security Operation Center. Когда речь идет об «облачном» сервисе, всегда встает вопрос о количестве «9 после запятой» в показателях его доступности. Мне бы хотелось рассказать о том, из чего складывается доступность SOC с точки зрения «железа» и ПО и какими средствами мы контролируем эту доступность. Статья будет гораздо более технической, поэтому попрошу читателей запастись терпением.

Итоговая цель нашего сервиса (JSOC) − выявление и оперативный анализ возникающих у заказчиков инцидентов ИБ. Это создает три основных требования к его доступности:

1. Платформа сбора и обработки информации должна быть доступна и работоспособна. Если информации о событиях и инцидентах некуда поступать, ни о каком выявлении инцидентов речи идти не может.
   
2. Информация с источников событий ИБ должна быть максимально полной: мы должны получать все требуемые события аудита, на основании которых построены наши сценарии по выявлению инцидентов.
   
3. В момент, когда система зафиксировала инцидент, мы должны иметь возможность максимально оперативно собрать и проанализировать всю информацию, необходимую для его расследования.
   

Эти требования порождают три разных уровня мониторинга доступности сервиса JSOC.

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

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

Обобщенный вывод из проведенных тестов:

• функционал протестированного оборудования полностью соответствует заявленному;
• оборудование совместимо с устройствами других производителей.

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

В рамках корпоративного блога хотелось бы запустить цикл статей о нашем молодом (но, тем не менее, очень ярком) начинании в сфере информационной безопасности – JSOC (Jet Security Operation Center) − коммерческом центре по мониторингу и реагированию на инциденты. В статьях я постараюсь поменьше заниматься саморекламой и большее внимание уделить практике: нашему опыту и принципами построения услуги. Тем не менее, это мой первый «хабро-опыт», и потому не судите строго.

SOC − предпосылки

Рассказывать, зачем вообще крупной российской компании нужен SOC, не очень хочется (уж слишком много различных статей и исследований по этому поводу написано). А вот статистика – совсем другое дело, и о ней грех не вспомнить. Так, например:

• в компании численностью от 1 до 5 тыс. человек в течение года фиксируется:
  
  • 90 млн. событий ИБ;
  • 16 865 событий с подозрением на инцидент;
  • 109 реальных инцидентов ИБ ;
• общий объем потерь от инцидентов ИБ в 2013 году составил $ 25 млрд. ;
• в крупной компании используется не менее 15 разнородных средств защиты, не более чем в 7 из них проводится активный анализ журналов для выявления инцидентов .

Если же добавить к этому еще 3−4 новостных заголовка по соответствующей теме, то абсолютно логичной и понятной становится идея о том, что за безопасностью необходимо следить, а инциденты ИБ − выявлять и анализировать.

Те, кто уже пробовал выбрать для себя подходящее IdM-решение, знают, что это не такое простое дело, как кажется на первый взгляд. При общем рассмотрении у всех IdM-систем примерно одинаковый набор функций – одни и те же «ролевая модель», «модули интеграции» и «согласование заявок». Однако при более подробном рассмотрении IdM-решений выясняется большое количество деталей, которые, будучи не принятыми во внимание, могут серьезно испортить жизнь будущим пользователям. Например, не все IdM-решения «умеют» группировать (склеивать) заявки по согласующим лицам. И это чревато возникновением таких ситуаций, когда, скажем, для 10 сотрудников запрашиваются 10 ролей, у которых один единственный владелец, и последний при этом вместо одной заявки получает 100 – по одной на каждую запрошенную роль для каждого сотрудника. И его работа, которая, казалось бы, с внедрением IdM должна упроститься, превращается в сущий ад.

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

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

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

Разработчики мобильных приложений зачастую сталкиваются с необходимостью хранить конфиденциальные данные пользователя на пользовательском устройстве. Это могут быть, например, номер кредитной карточки или аутентификационные данные. В этой статье мы поговорим о типичных ошибках реализации хранения конфиденциальных данных с точки зрения информационной безопасности на примере мобильной платформы iOS.
Обычно настройки приложения хранятся в конфигурационных файлах. Библиотека Cocoa Touch, используемая при разработке приложений для мобильной платформы iOS, предоставляет слой абстракции для хранения настроек приложения в классе NSUserDefaults. Класс NSUserDefaults реализует нелюбимый многими шаблон проектирования «Одиночка» (более известный как Singleton), предоставляя доступ к интерфейсу над стандартным конфигурационным файлом приложения.
Стандартный файл конфигурации приложения располагается в его домашней директории по относительному адресу Library/Preferences/<your.company.name>.<app.name>.plist. Как и другие файлы, расположенные в «песочнице», он не доступен на чтение для других приложений пользовательского уровня. Исключения составляют устройства, подвергнутые модификациям политики безопасности системы (jailbroken-устройства).
Многие разработчики по достоинству оценили удобство работы с классом NSUserDefaults. Подавляющее число приложений используют его для хранения внутренних настроек и/или настроек пользователя. К сожалению, удобство использования редко коррелирует с безопасностью. Хранение конфиденциальных данных пользователя в стандартном файле настроек является типичной ошибкой разработчиков, приводящей к утечке пользовательской информации.
В результате исследования исходного кода Приложения А на наличие ошибок в контексте информационной безопасности было выявлено, что приложение сохраняет данные аутентификации пользователя в конфигурационном файле настроек. Загрузив Приложение А на iPad под управление оригинальной операционной системы iOS версии 6.1.3, мы прошли стадию аутентификации и принялись за исследование файла настроек приложения.


Рис. 1. Загрузка приложения на iPad