Данная статья подготовлена Дмитрием Овчаренко, архитектором Департамента прикладных финансовых систем компании «Инфосистемы Джет»

Да будет унификация! Такое решение было принято при проектировании интеграционной архитектуры, связывающей CRM с другими внешними системами посредством шины на Oracle Service Bus. Помимо онлайн-интеграции на основе веб-сервисов, она принимает файлы, поступающие в систему, и вызывает веб-сервисы на стороне CRM, специально разработанные для каждого типа входящих данных.

Файл содержит множество записей, и по каждой требуется выполнить отдельный вызов сервиса на стороне CRM. Обработка файла производится в цикле по записям. На каждый вызов сервиса уходит по 5 секунд – это довольно много, но для выполнения поставленных требований вполне хватало. Процесс обработки вызова веб-сервиса в CRM предварительно проверяет запись на дубль, затем выполняет требуемую бизнес-логику и создает запись в БД.

Но «внезапности» могут возникнуть в непредвиденных моментах «шиномонтажа». На промышленных объемах данных в базе CRM стали появляться дубли. Мы выяснили, что источник может почему-то отправить большой файл повторно (сразу после того, как он будет подхвачен файловым proxy-сервисом и помещен в Stage-папку). Причем отставание между вызовами веб-сервисов, создающих дубли, настолько мало, что в момент второго вызова данные в первом еще не закоммичены, и проверка на стороне CRM не успевает срабатывать.

Данная статья подготовлена Николаем Ведяшкиным, экспертом Сервисного центра компании «Инфосистемы Джет».

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

Например, добавить сервер БД и перенести на него экземпляр базы данных, добавить резервных накопителей для ускорения РК, сделать апгрейд процессоров и т.д. Однако стоит помнить, что простое наращивание аппаратных мощностей наименее выгодно с точки зрения материальных и временных затрат. Намного эффективнее решать такие проблемы на уровне логики работы ИТ-решений.

Данная статья подготовлена Артемом Демариным, экспертом Отдела систем хранения данных компании «Инфосистемы Джет»

Сегодня многие отдают предпочтение услугам VoD (Video on Demand), вместо того, чтобы идти в кино. Либо вместо посещения кафе заказывают еду на дом. Потребление ресурсов в виде услуг является уже чем-то обыденным и само собой разумеющимся.
Постепенно этот подход стал применяться и к ИТ-инфраструктуре/ИТ-сервисам. Создание ресурсов по запросу стало возможным благодаря активному использованию систем серверной виртуализации, которые позволили абстрагироваться от фиксированных конфигураций. На первичном этапе это дало возможность рассматривать ИТ-инфраструктуру и ИТ-сервисы как услуги, но всё еще не обеспечивало нужной гибкости и динамичности для удовлетворения пользовательских запросов. Для решения данной задачи была разработана концепция программно-определяемого ЦОД (Software Defined Datacenter, SDDC), которая предусматривает абстрагирование от аппаратной части абсолютно всех компонентов ЦОД.

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

Данная статья подготовлена Алексеем Струченко, начальником отдела оптимизации СУБД и приложений компании «Инфосистемы Джет»

Вышедшая в июле 2014 года опция Database In-Memory является самой ожидаемой и самой обсуждаемой инновацией Oracle в семействе продуктов Oracle Database. За последние несколько месяцев сотрудники компании Oracle регулярно знакомили российское оракловое сообщество с особенностями новой опции.

На Oracle Day 2014 в Москве мне выпала честь дополнить теоретическую презентацию Игоря Мельникова (Oracle) по Database In-Memory практической демонстрацией. Эту демонстрацию в полном объеме показать не удалось – оказалось не так-то просто подключить проектор к ноутбуку, соединенному с демонстрационной базой. Поэтому я решил воспользоваться трибуной Habrahabr и все-таки донести суть демонстрации Database In-Memory до сообщества.

Приветствуем коллег и читателей. Сегодня предлагаем порассуждать на тему целесообразности аренды ИТ-ресурсов.

Представим себе ситуацию: компания задумалась о том, чтобы внедрить ERP. На месте этих 3 букв может стоять и другая аббревиатура – CRM, CAD, BI, SRM, CMS, EAM, MRM, GIS. С чего все начинается? С определения функциональности и требуемой производительности, причем нужно не только рассчитать ее на текущий момент, но и спрогнозировать перспективное развитие хотя бы на 3 года. Необходимо посмотреть на архитектуру железа, базовое и прикладное программное обеспечение, подумать над тем, как обеспечить RTO/RPO, катастрофоустойчивость, безопасность, привлечь высококвалифицированную проектную команду. Помимо этого, детально проанализировать несколько вариантов решения, предлагаемых производителями. Подумать, во сколько обойдется последующая эксплуатация. И мы еще не сделали самое главное – не убедили инвесторов или владельцев бизнеса в необходимости потратить бюджет именно на эту ИТ-систему.
А что ИТ-директор скажет бизнесу, когда спустя пару лет все поменяется настолько, что нужно будет снова проводить аналогичные мероприятия? Ведь потраченные несколько миллионов уже не вернуть. При этом средства на поддержание решения так или иначе нужно расходовать.

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

Иногда ИТ-ресурсы необходимы компаниям лишь на определенный срок – полгода, год, после чего они с большой долей вероятности будут висеть на балансе. Безусловно, если в подобных ситуациях идти по классическому пути наращивания инфраструктуры (свой ЦОД/colocation), в будущем это может обернуться существенными проблемами. Есть и другое решение – взять ИТ-ресурсы в аренду.

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

В первую очередь при построении SDDC стоит задуматься о технологии макровиртуализации. Она подразумевает под собой рабочий тандем системы управления виртуальными машинами (ВМ), DCIM (Data Center Infrastructure Management) и SNMP-адаптеров (Simple Network Management Protocol). DCIM с помощью адаптеров собирает и агрегирует информацию о состоянии инженерной инфраструктуры дата-центров, наличии свободных площадей, а также места в стойках. Система позволяет получать максимально полную картину того, что происходит в ЦОД компании-провайдера «здесь и сейчас». Если присовокупить к данным DCIM информацию из системы управления ВМ, это позволит определять проблемные точки в ЦОД (превышение пороговых значений температуры, нехватка электропитания и др.) и перемещать в ту или иную физическую зону дата-центра (или в другой дата-центр) нагрузку на процессорные мощности. Компания сможет осуществлять миграцию высоконагруженных виртуальных машин ближе к подходящим элементам инженерной инфраструктуры. И в зонах «накала серверных страстей» будет наиболее холодно.

Таким образом, физические дата-центры провайдера, объединенные технологией макровиртуализации, преобразуются в единую «экосистему», обладающую, помимо всего прочего, повышенной надежностью. Здесь уместна пословица «Веника не сломишь, а прутья по одному все переломаешь»: при невысоком уровне надежности инженерной инфраструктуры отдельных ЦОД все они обеспечивают полное взаимное резервирование.

Проект OpenStack возник по инициативе двух производителей и объединил их продукты – объектное хранилище Rackspace и систему управления гипервизорами NASA. «OpenStack призван помочь организациям предоставлять облачные вычислительные ресурсы, запущенные на стандартном оборудовании», – заявляют вендоры. В данном материале мы попробуем разобраться, так ли это на самом деле.

OpenStack сегодня

Первый релиз OpenStack вышел в октябре 2010 г. Так компания Rackspace стала одним из ближайших конкурентов другого облачного провайдера IaaS – Amazon Web Services (AWS), который в то время сильно терял свои позиции. По сути, OpenStack – копия AWS: многие сервисы и процессы в этих платформах одинаковы и даже совместимы между собой.

IaaS: OpenStack vs. Amazon Web Services

Коллеги, добрый день.

Мы чуть затянули с выпуском нашей очередной статьи. Но тем не менее она готова и я хочу представить статью нашего нового аналитика и автора — Алексея Павлова — avpavlov.

В этой статье мы рассмотрим наиболее важный аспект «жизнедеятельности» любого Security Operation Center – выявление и оперативный анализ возникающих угроз информационной безопасности. Мы расскажем, каким образом происходит настройка правил, а также выявление и регистрация инцидентов в нашем аутсорсинговом центре мониторинга и реагирования JSOC.

10 вопросов к российскому стандарту ГОСТ Р 53647.3–2010 «Менеджмент непрерывности бизнеса. Часть 3. Руководство по внедрению»

Несколько лет назад я сетовал на то, что в России мало нормативных документов, посвященных теме непрерывности бизнеса. Точнее, я знал о существовании национальных стандартов семейства ГОСТ Р 53647.1–2009 «Менеджмент непрерывности бизнеса. Часть 1. Практическое руководство» и ГОСТ Р 53647.2–2009 «Менеджмент непрерывности бизнеса. Часть 2. Требования». Но время идет, и оказалось, что семейство пополнилось большим количеством документов. Их рассмотрению я хочу посвятить несколько статей.
Итак, предметом рассмотрения в этот раз станет ГОСТ Р 53647.3–2010 «Менеджмент непрерывности бизнеса. Часть 3. Руководство по внедрению». Как и в случае с предыдущими документами, в его основу положен национальный документ Великобритании – BIP 2142:2007 «The Route Map to Business Continuity Management. Meeting the Requirements of BS 25999».
Наверное, как и в любой области, где возможна специализация, рекомендации этого документа будут более понятны и полезны тем, кто уже имеет практический опыт реализации процесса менеджмента непрерывности бизнеса.

Предыстория (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 новостных заголовка по соответствующей теме, то абсолютно логичной и понятной становится идея о том, что за безопасностью необходимо следить, а инциденты ИБ − выявлять и анализировать.