Ставка на Open Source
Автор
Григорий Рудницкий
Но как ею воспользоваться? В ЦОДе Республики Мордовия, находящемся в ведении государственного автономного учреждения «Госинформ», широко используется программное обеспечение с открытым исходным кодом
Но как ею воспользоваться? В ЦОДе Республики Мордовия, находящемся в ведении государственного автономного учреждения «Госинформ», широко используется программное обеспечение с открытым исходным кодом. В конце прошлого года там была запущена в промышленную эксплуатацию система Service Desk, представляющая собой интеграционное решение на базе продуктов Atlassian JIRА и Confluenсe. Кроме того, в проектировании решения использовано несколько систем из класса свободного программного обеспечения, а именно Zimbra и Backup PC. Алексей Романов, генеральный директор ГАУ «Госинформ», уверен, что ставка, сделанная на СПО, в дальнейшем позволит компании самостоятельно развивать систему, что в целом даст существенную экономию расходов на содержание ЦОДа.
В чем состоит специфика вашего Центра обработки данных?
Прежде всего в том, что наш ЦОД является многофункциональным. У нас выделены классы программного обеспечения, с которыми мы можем работать. Первый кластер обрабатывает те или иные расчетные задачи, связанные с высокой нагрузкой на процессор, другой кластер служит для обработки больших баз данных, третий кластер отвечает за работу маленьких виртуальных машин наших клиентов и при этом умеет взаимодействовать с другими системами. Подобная структура позволяет нам решать практически любую задачу. Таким образом, резиденты нашего технопарка могут не закупать собственные информационные системы, а получать терминальный доступ к любым системам по модели SaaS. Второе направление нашей деятельности — это хостинг информационных систем Электронного правительства Республики Мордовия. А сегодня мы занимаемся анализом решений по дата-центру технопарка «Жигулевская долина», и одним из предложений здесь является объединение наших дата-центров в единое облако. При этом в «Жигулевской долине» будет дата-центр, сертифицированный по Tier 3, у нас же — по Tier 4, самому высокому уровню. Соответственно, у нас будет реализован хостинг жизненно важных систем постоянной доступности, а в «Жигулевской долине» — менее важных. Все это позволит нам максимально рационально использовать мощности наших вычислительных центров.
Мы также ведем работу и на муниципальном уровне. Для решения задач, связанных с муниципальными услугами, мы намерены отдельные части нашего дата-центра объединить в облако, а затем разместить их на районных узлах связи компании «Ростелеком». Даже если произойдет сбой на таком муниципальном узле, мы легко сможем «перехватить» клиентов и продолжить их обслуживание в региональном дата-центре.
Таким образом, основные свойства нашего ЦОДа — мультизадачность, организация терминального доступа через систему виртуальных машин, а также возможность гибкого объединения в облачную инфраструктуру. Мы виртуализировали как серверы и машины, так и системы хранения данных, причем не только на блочном, но и на файловом уровне. И если говорить коротко, то основная наша особенность — объединение с помощью облачных технологий разнородных дата-центров и перераспределение задач.
Почему принято решение внедрять систему Service Desk? Как прежде была реализована работа с обращениями клиентов?
Вы же понимаете, дата-центр не может быть запущен для коллективного доступа, пока в нем не будет внедрена система Service Desk. Соответствующие работы начались одновременно с запуском. Как я уже говорил, специфика нашего дата-центра достаточно разнородна — это и виртуальные машины, и различные сервисы. Поэтому и обращения носят самый разнообразный характер. Если неправильно организовать работу персонала и недостаточно контролировать ее, то клиенты будут получать ответы: «Обратитесь недельки через две, возможно, мы решим вашу проблему». Как вы понимаете, это никуда не годится. Что дает нам Service Desk? Прежде всего, нормализует работу и равномерно распределяет нагрузку между всеми сотрудниками службы поддержки. Кроме того, с помощью Service Desk можно контролировать действия персонала и выявлять узкие места. Если где-то у нас происходит регулярный завал — увеличение числа обращений и сроков реагирования на них, то мы должны усилить такое направление.
Как проходил выбор поставщика Service Desk? Рассматривались ли проприетарные решения?
Изначально наша позиция состояла в том, что если компания маленькая и у нее недостаточно, а то и вовсе нет своих программистов, тогда решения Open Source — не для нее, ей их покупать не нужно. Все-таки СПО требует наличия специалистов на стороне заказчика, которые потом могли бы осуществлять настройку и доработку. У нас был такой персонал, поэтому наличие открытого кода позволяет нам в дальнейшем своими силами модернизировать и менять все, что необходимо. С коммерческим «коробочным» ПО мы бы такой возможности, конечно, не имели. Вот почему мы сейчас идем по пути максимального использования программных продуктов с открытым кодом. Если бы у нас была не ИТ-компания, а какая-то другая, мы бы вряд ли перешли на Open Source, а предпочли бы что-то проприетарное.
Что касается выбора поставщика уже в сегменте СПО, здесь все довольно просто. У нас есть некая задача, мы всех разработчиков на рынке знаем, поэтому приглашаем их и спрашиваем, как бы они смогли решить данную проблему. Иными словами, идет обычный поиск решения, удовлетворяющего требованиям и ценовому диапазону. На самом деле, система Service Desk у нас не очень простая. Она не только обрабатывает запросы, но и интегрирована с нашими системами диспетчеризации технологических процессов. Соответственно, требовалось организовать стык между информационной системой дата-цента и Service Desk. Решение, предложенное компанией «ПингВин Софтвер», показалось нам наиболее приемлемым во всех отношениях.
На какие этапы можно разделить ваш проект?
На первом этапе наши сотрудники совместно со специалистами «ПингВин Софтвер» провели анализ объекта информатизации, составили ТЗ, в котором уточнили все необходимые параметры. Вопросы состыковки с системами диспетчеризации мы обсуждали с компанией-разработчиком «Техносерв». Далее начался процесс разработки, затем мы инсталлировали систему, после чего начался самый сложный этап, связанный с вводом Open Source. Объясню подробнее. Когда вы купили «коробку», настройка может занимать максимум несколько часов. Но в случае с Open Source нам потребовался достаточно заметный период времени, связанный с донастройкой системы, ее адаптацией, отработкой регламентов и т. д. То есть внедрять решение Open Source —действительно сложнее и дольше.
Оправданны ли такие жертвы?
Безусловно. Поскольку в результате мы получили более компактную систему, которая заточена исключительно под наш функционал и при этом учитывает все наши регламенты. Во-первых, мы выиграли в быстродействии, а во-вторых — в удобстве и функционале.
Можно ли сравнить сроки внедрения коммерческого «коробочного» ПО и аналогичного решения на базе Open Source?
Это было бы не совсем корректно. Если бы мы выбрали решение «из коробки», то не получили бы тех свойств, того функционала, который есть у Open Source. Поэтому и времени ушло существенно больше.
С какими рисками, характерными для проектов, связанных с СПО, вы столкнулись?
Риски, которые связаны с Open Source, понятны и известны. Первый риск заключается в том, что нельзя быть уверенными в том, что мы получим конечный результат именно в таком виде, в каком мы его ожидаем. Почему? Дело в том, что адаптация СПО частично лежит в плоскости разработки. Риски здесь точно такие же, как и при проведении НИОКР. Они заключаются в недостижении ожидаемых результатов, на которые мы рассчитывали. В случае с коммерческим «коробочным» ПО такого, конечно, нет. Там все предсказуемо. Как преодолеть этот риск? При внедрении должна присутствовать профессиональная команда, умеющая взаимодействовать с разработчиком для достижения нужного результата. Разработчик, разумеется, может полностью взять на свои плечи сопровождение вашей системы, но тогда теряется то преимущество, когда вы в любой момент можете что-то быстро «подкрутить» в соответствии с текущими задачами и потребностями. Второй риск связан с потерями преимуществ СПО, это связано с доработками. Решение здесь аналогичное — ваши сотрудники должны принимать самое активное участие в процессе разработки, знать все детали и специфику.
Вы поддерживаете систему собственными силами?
Не совсем так. Вопросы мелкой доработки решают наши сотрудники. Если требуется фундаментальное изменение функционала, мы обращаемся к разработчику. Ведь для того, чтобы осуществлять глобальные изменения самостоятельно, необходим большой штат профессиональных программистов, знакомых с данной системой. Но для нас это нецелесообразно.
Сопоставима ли стоимость поддержки коммерческого и СПО-продукта?
Наши сотрудники, занимающиеся мелкой настройкой Service Desk, обслуживают и другие системы. Поскольку мы — специализированная ИТ-компания, для нас это вполне доступно и несложно. Если бы у меня не было таких сотрудников, я бы задумался.
Не сложнее ли найти специалистов по СПО-решениям, чем по продукции известных вендоров — Microsoft, HP, SAP, «1С» и других?
Вы затронули самый больной вопрос. Как только собираются несколько руководителей, пусть даже не связанных с ИТ, то у одного из них обязательно возникает вопрос: а нет ли у тебя такого-то или такого-то специалиста? Кадровый голод не только в ИТ, он везде. Юристов, экономистов, регионоведов очень много, а вот тех, кто действительно нужен, днем с огнем не найти. Как мы решили проблему? Воспользовались административным ресурсом, поскольку являемся оператором республиканского Электронного правительства. Мы договорились с университетом и Минобразования. Нам выделили пилотные учебные заведения, и мы сейчас занимаемся формированием учебных программ и методик, по которым будем готовить специалистов для себя. Да и вообще, молодежь надо активнее привлекать. Текучка кадров существует, поскольку зарплаты у нас невысокие, однако ядро сотрудников должно сохраняться.
Говоря о СПО, нельзя не затронуть и такую проблему, как возможное прекращение разработки и обновлений того или иного программного продукта. Разработчик разорился, его кто-то купил, либо просто он потерял интерес к своему детищу. Готовы ли вы к такому повороту событий?
Любое техническое изделие имеет свой жизненный срок и когда-нибудь умирает. Даже если умрут разработчики, я за счет того, что у меня есть специалисты, свободно проживу год-полтора на имеющемся программном продукте. Что-то докрутить мы можем, а глобальные изменения нам уже не будут доступны. Однако за этот год мы перенесем задачи, требующие глобальных изменений, на плечи других информационных систем. А уже затем данное решение постепенно выведем из эксплуатации.
Источник: IT Manager №2, 2012
Опубликовано 25.02.2013