In English

Центры обработки данных: Существенные факты

26.07.2005, Басина Наталья
Издание: CIO
Центры обработки данных (ЦОД) как целостные информационные системы строятся с использованием взаимоувязанных программных и аппаратных компонентов, организационных процедур и квалифицированного персонала. Целью создания ЦОД в бизнесе является «автоматизация задач бизнеса с требуемым уровнем качества предоставляемых ИТ-сервисов» (Определение компании КРОК). Поэтому неудивительно, что ЦОД в их современном понимании появились в России всего несколько лет назад. То есть именно тогда, когда уровень развития информационных технологий, с одной стороны, и бизнеса — с другой, поставили вопрос о необходимости создания и использования таких консолидированных центров.

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

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

Простые подсчеты показывали, что содержание двух высококвалифицированных специалистов, которые постоянно обслуживают общий центр обработки данных, требует куда меньших затрат, чем необходимость содержать несколько десятков технических работников в офисах, расположенных в разных городах. Кроме того, хотя создание единого центра и оказывается дороже по стоимости начальной закупки, в эксплуатации ЦОД явно дешевле — зарубежный опыт показывает, что затраты на центр обработки данных, как правило, распределяются по классической «формуле»: 20% на создание и 80% на обслуживание.

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

Появление ЦОД в России связано как с этими, так и с иными причинами. Но, разумеется, стремление крупных компаний внедрять центры обработки данных основывается, в первую очередь, на желании сделать наконец-то доступной для обработки и анализа всю имеющуюся информацию.

Первые центры обработки данных в нашей стране стали появляться на рубеже 2000–2001 годов, а одним из пионеров их внедрения стал Сбербанк России. Сбербанк РФ — одна из самых крупных территориально-распределенных бизнес-структур в России. А в условиях, когда практически в каждом населенном пункте страны действует отделение банка, задача консолидации и централизованной обработки информации оказывается на одном из первых мест.

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

Трудности построения ЦОД


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

Принципы построения централизованных информационных систем

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

По словам заместителя директора департамента вычислительных систем компании КРОК Руслана Заединова, централизованный и распределенный подходы к созданию ЦОД вполне уживаются друг с другом, а проектная компания всегда может найти компромисс. К тому же, совмещение этих подходов для таких крупных компаний-заказчиков, как, например, Северо-Кавказский банк Сбербанка РФ или Алтайский банк Сбербанка РФ, является единственно возможным способом.

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

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

«Такие параметры, как результат, время его получения и гарантия того, что система будет работоспособной, являются единственным, что интересует клиента в этом случае, — говорит Руслан Заединов. — Эти параметры, как правило, обозначают термином SLA (service level agreement) — соглашение об уровне качества услуг. В итоге на верхнем уровне моделирования построение ЦОД предполагает формирование набора SLA, который и предоставляется заказчику. Как правило, процесс утверждения лежит на плечах ИТ-директора компании-заказчика — именно он предлагает руководству те сервисы, которые предприятие будет использовать в процессе решения тех или иных бизнес-задач. Иными словами: не вдаваясь в технические подробности, руководство предприятия знает, за какое время могут быть получены необходимые сведения или отчеты. Известно также, что время простоя системы в течение года гарантированно не будет превышать нескольких минут».

На следующем этапе реализации SLA речь идет уже о создании высокоуровневых технических решений. Здесь осуществляется выбор технической архитектуры для каждого элемента SLA. Системные архитекторы выбирают такие параметры технических средств, как производительность, емкость хранилищ, пропускная способность каналов передачи данных, а затем все SLA рассматриваются в комплексе для того, чтобы провести их инвентаризацию. Завершается эта работа оптимизацией затрат на создание ЦОД путем выбора такого решения, которое позволяло бы перегруппировывать все ИТ-ресурсы в соответствии с задачами — необходимо определить общую нагрузку на центр обработки данных, распределенную между всеми реализуемыми сервисами.

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

В зависимости от пожеланий, готовности заказчика и нужд его бизнеса выбирается тот или иной подход к построению ЦОД. Если клиента интересует исключительно удобство эксплуатации системы — можно начинать внедрение с третьего уровня. Если заказчик не может сформировать SLA, потому что бизнес пока не готов к столь тесному увязыванию с ИТ, можно начинать со второго уровня — построения архитектуры. И, наконец, компании со зрелым бизнесом начинают внедрение с самого верхнего уровня.

Сумма технологий


Существует несколько групп типовых элементов, которые используются при построении ЦОД. Это элементы консолидации вычислений (серверы), консолидации данных (системы и сети хранения данных), средства обеспечения ЦОД собственно данными (телекоммуникационная инфраструктура) и системы жизнеобеспечения, включая информационную безопасность, программные системы управления, гарантированное электропитание, а также системы климатического контроля и пожарной безопасности.

Серверы

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

Реализация вычислительных ресурсов, в свою очередь, обеспечивается по двум направлениям. Во-первых, это аппаратные компоненты сервера, которые должны «уметь» делить ресурсы между задачами, перераспределяя их в зависимости от нагрузки в реальном времени. Подобные средства виртуализации вычислительных ресурсов предлагают сегодня все ведущие производители — IBM, Hewlett-Packard, Sun Microsystems.

Другое ключевое свойство, которым должны обладать серверы, — возможность обеспечить исполнение так называемого гетерогенного программного обеспечения. Речь идет о работе (в случае необходимости) различных операционных систем на одной и той же машине. Сегодня ЦОД чаще всего работают под управлением промышленных ОС UNIX. Кроме того, все большую популярность начинает завоевывать операционная система Linux, причем, как правило, и Linux, и UNIX используются в ЦОД параллельно. Самой распространенной областью использования Linux становится управление распределенными серверами прикладных программ, что позволяет упростить поддержку систем и сократить расходы. Производители многих прикладных программ обеспечивают возможность их работы в среде Linux.

Кроме того, на рынке решений для ЦОД постепенно набирает популярность и программное обеспечение Microsoft. История прорыва этой компании на рынок ЦОД во многом связана с наличием между Microsoft и Hewlett-Packard особых партнерских соглашений. В рамках этих отношений была разработана 64-разрядная версия Windows, поддерживающая совместную разработку HP и Intel — процессор Itanium 2. Очевидно, что кроме операционной системы необходима еще и прикладная часть. Microsoft активно продвигает свою СУБД SQL Server, перенесенную на 64-разрядную платформу. Однако специалисты ждут от компании появления более широкого спектра прикладных программ для ЦОД. Тем более, что многие заказчики в силу исторических причин предпочитают именно программы Microsoft.

Вот что говорит по этому поводу Руслан Заединов: «Одна известная компания долгое время эксплуатировала свои базы данных под управлением некой СУБД на 32-разрядных Intel-серверах. Оказалось, что количество серверов постоянно растет, а должной производительности, управляемости и оптимизации эксплуатационных расходов добиться не удается. После проведения необходимых подсчетов было принято решение перевести все эти базы данных на один сервер, под управлением СУБД от Microsoft. Эффективным решением стало использование 64-разрядной платформы на базе Itanium 2 и 64-разрядной версии SQL Server. И таких заказчиков немало. Это один из ответов на вопрос о том, почему „КРОК“ уделяет повышенное внимание решениям от Microsoft — в качестве „тяжелой“ базы данных во многих случаях удобно оказывается применять именно SQL Server».

Экономика ЦОД


Согласно экспертным оценкам, примерная стоимость создания полноценного ЦОД, использующего передовые технические и технологические решения и обладающего всеми необходимыми подсистемами, начинается с пяти миллионов долларов. Но это в том случае, если при внедрении не возникает проблем, подобных необходимости увеличения мощности питающих электросетей. Понятно, что такого рода «перестройки» могут существенно увеличить стоимость решения в целом. А значит, пока центры обработки данных в России доступны лишь крупным корпоративным потребителям. Тем более, что прямую окупаемость ЦОД у нас в стране никто еще не считал (что неудивительно — порой ЦОД просто не имеет альтернативы, что вносит свои поправки в методики оценки эффективности).

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

«Один из клиентов компании „КРОК“, перейдя к использованию аутсорсинга ИТ-службы, подсчитал затем экономические показатели, — приводит пример Руслан Заединов. — Так вот, в результате выяснилось, что компания благодаря аутсорсингу… ничего не выиграла по деньгам. Но зато решила такое количество административных проблем, что игра явно стоила свеч! Сотрудники, которые работают в режиме аутсорсинга, всегда на месте, и, что бы ни случилось, контракт все равно выполняется. Так что счастье далеко не всегда „в деньгах“, причем об этом все чаще говорят сами заказчики. В случае с ЦОД аргументация примерно та же: наша задача — получить централизованные данные, а уж подсчитывать возврат на инвестиции в данном случае — совершенно не нужно. И дело вовсе не в том, что такого рода подсчеты связаны с довольно серьезными затратами. Дело в том, что подсчет эффективности такого рода решения возможен лишь с использованием серьезной бизнес-аналитики, а значит, и практической пользы от скоропалительного подсчета экономической эффективности получить все равно не удастся».

Другой важный аспект внедрения ЦОД — оценка влияния стоимости его создания и эксплуатации на бюджет компании. Для компаний определенного масштаба построение ЦОД стоимостью в 5–6 миллионов долларов может привести к необходимости прямого учета данных расходов в себестоимости основной продукции. В этом случае встает задача организации внутреннего биллинга услуг ЦОД.

По мнению Руслана Заединова, оценка экономических параметров ЦОД в России появится. Но только тогда, когда такие решения станут явлением если не рядовым, то привычным. Сегодня же безальтернативность ЦОД чаще всего лишает смысла попытки директивной оценки их экономической эффективности.

Системы хранения


Системы хранения данных — другая ключевая составляющая ЦОД. А значит, и требования, которым они должны удовлетворять, максимально высоки.

Первое и важнейшее свойство систем хранения данных, применяемых в составе ЦОД, — это высокая степень масштабируемости. Проще говоря, заказчик не должен испытывать опасений, что данные вдруг «не поместятся».

Второе требование — полная управляемость. Здесь следует иметь в виду, что современные системы, как правило, эксплуатируются в трех режимах. Есть «боевой режим» — то, что видит пользователь. Режим резервирования обеспечивает сохранность данных и отказоустойчивость системы. А вот о третьем — режиме разработки — говорится несправедливо мало. А ведь тем временем, как подчеркивает Руслан Заединов, практически всегда системы, эксплуатируемые заказчиками, «живут своей жизнью и развиваются».

«Довольно часто у крупных заказчиков имеется своя служба разработки и доработки информационных систем. А значит, все копии прикладных систем, которые не являются „боевыми“ и которые „не видит“ заказчик, все равно должны присутствовать в составе ЦОД. Хотя бы для того, чтобы избежать огромных затрат на тестирование при их переносе в ЦОД из систем разработки. Наиболее дальновидные заказчики внедряют именно такие системы, уже на уровне проекта закладывая в вычислительные мощности все три режима», — говорит Руслан Заединов.

И вот что важно. Именно эта особенность ЦОД оказывает серьезное влияние на функционал системы хранения данных, поскольку и второй, и третий режим эксплуатации предполагают работу с «боевыми» данными! А значит, необходимо так сконфигурировать всю систему, чтобы непродуктивные копии прикладных систем не искажали продуктивные, «боевые» данные. Какие бы эксперименты ни проводились «за кадром», пользователи не должны ничего замечать.

В связи с появлением непродуктивных копий данных становится важным еще одно качество систем хранения данных в составе ЦОД — возможность проведения оптимизации расходов на поддержание этих копий.

Нередко у заказчиков возникает иллюзия, что речь в данном случае идет лишь о физических копиях, дублирующих объем баз данных. Однако это не совсем так. За то время, пока существует копия с базы данных, в среднем изменяется всего 5–10% информации. А значит, можно хранить только изменения. Именно поэтому производители систем хранения данных, использовавшие такой подход, получили явное конкурентное преимущество. Среди них — один из признанных лидеров, компания EMC, и другие ведущие поставщики систем хранения.

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

«К сожалению, в России это условие резервирования не всегда соблюдается. Зачастую резервные системы устанавливаются в одной комнате с основной из-за временной неготовности другого помещения, оснащение которого может затянуться в связи с особенностями планирования бюджетов на российских предприятиях».

Системы жизнеобеспечения


Сегодня уже никому не придет в голову создавать центр обработки данных без предварительного проектирования систем жизнеобеспечения. Обычно в стоимость этих систем (так же, как и в основные элементы ЦОД) закладывается не только цена приобретения, но и цена подготовки к эксплуатации. Как правило, по соображениям информационной безопасности системы жизнеобеспечения располагаются в другом помещении, так как их обслуживает отдельный персонал, зачастую не входящий в штат компании. Это означает, что если заказчик сам, без консультаций системного интегратора, подготовил помещение для ЦОД, то может оказаться, что оно не отвечает всем необходимым требованиям безопасности. Тем более, что коммерческая тайна во многих учреждениях охраняется на самом высоком уровне. Чуть ли не строже, чем тайна государственная. А значит, стоимость оборудования отдельного помещения для систем жизнеобеспечения следует учитывать с самого начала. Кстати, одна из основных ошибок при проектировании систем жизнеобеспечения — неверные подходы в части безопасности и эксплуатации.

Ошибки


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

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

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

Проекты


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

В банковской сфере несомненным лидером в деле построения ЦОД, по мнению Руслана Заединова, является Сбербанк РФ. Компании КРОК работать со Сбербанком особенно интересно благодаря высокой территориальной распределенности как самих ЦОД, так и их пользователей.

К примеру, для Северо-Кавказского банка Сбербанка РФ специалистами КРОК был разработан и внедрен ЦОД на базе серверов IBM xSeries, Sun Fire и двух систем хранения EMC Clariion с репликацией данных между ними. Центр консолидировал ресурсы региональных подразделений банка и обеспечивал работу автоматизированной банковской системы. В Алтайском банке Сбербанка РФ в рамках создания катастрофоустойчивого ЦОД была создана центральная банковская система, телекоммуникационная система, а также системы связи.

Яркие примеры продуманной реализации ЦОД можно найти среди операторов сотовой связи — пионеров по внедрению современных информационных технологий на российском рынке.

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

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

Системы хранения


По мнению специалистов компании «АйТи», основные трудности в процессе создания центров обработки данных связаны с недооценкойроли систем хранения данных как в рамках ЦОД, так и в системе обеспечения непрерывности и доступности информации в целом. Руководитель направления ЦОД Департамента сетевых технологий компании «АйТи» Григорий Коньков отмечает: «Очень часто заказчики воспринимают системы хранения как „придаток“ к серверу. Между тем, сервер — это, по сути, просто большой калькулятор. Если выйдет из строя сервер, последствия этого для организации в большинстве случаев несоизмеримо меньше, по сравнению с теми проблемами, которые повлечет за собой потеря информации. Мы нередко сталкиваемся с ситуациями, когда заказчики просто не готовы тратить деньги на организацию современных систем хранения данных. Пожалуй, исключение составляют предприятия отраслей, в которых непрерывность информации является критичной для развития бизнеса, — банки, телекоммуникационные компании и ряд других. Меняется отношение к данной проблеме и со стороны предприятий, внедряющих управленческие системы класса ERP, что вполне логично, поскольку непрерывность и доступность данных в этом случае переходит на более высокий уровень качества».

Другая типичная проблема: зачастую заказчику бывает довольно сложно оценить перспективы развития создаваемого ЦОД. «В последнее время, в связи с переходом на современные системы электронного документооборота, все чаще возникают задачи по хранению неструктурированной информации, — говорит Григорий Коньков. — А сюда, помимо типовых документов, можно отнести различные карты, чертежи, фотографии, рисунки. Соответственно, если потенциал роста структурированной информации, хранимой, например, в базе данных ERP-системы, более или менее предсказуем, то с перспективами роста неструктурированной информации дело обстоит гораздо сложнее. На момент построения ЦОД заказчик может и не подозревать о том, что через год перед ним встанет задача хранения, например, рентгеновских снимков сотрудников в течение 20 лет. А задачи такого порядка возникают сегодня все чаще и чаще».

Пути развития


«Наиболее перспективной сегодня является поэтапная многоуровневая концепция организации ЦОД, — считает руководитель направления ЦОД Департамента сетевых технологий компании „АйТи“ Григорий Коньков. — Эта концепция предполагает поступательное развитие ЦОД в соответствии с ростом потребностей заказчика: наращивание производительности и мощности систем хранения и обработки данных происходит только тогда, когда возможности существующей „конфигурации“ уже исчерпаны. Иными словами, стоимость хранения и обработки информации всегда соответствует текущим потребностям. Такой подход позволяет сократить как первоначальные инвестиции, так и в целом стоимость эксплуатации ЦОД. Собственно говоря, именно этой концепции мы и придерживаемся при построении ЦОД для наших заказчиков».

По мнению Руслана Заединова, в настоящее время все технические элементы ЦОД настолько «притерты» друг к другу, все настолько продумано «вплоть до бит и байт», что проектирование центров обработки данных на самом нижнем уровне — технических решений — порой напоминает собирание головоломки-«паззла». «Что-то принципиально новое в создании ЦОД придумать сложно. Надо просто ждать революционных преобразований в области информационных технологий, — говорит Руслан Заединов. — Правда, революционным может стать принципиальное изменение в самом местоположении центров обработки данных. Например, если аутсорсинг ЦОД получит широкое распространение, то, возможно, устоявшиеся конструкции ЦОД претерпят изменения. Во-первых, сузится рынок элементов ЦОД, а компания-интегратор сама будет решать, технику каких производителей ей устанавливать, и вряд ли захочет „разнообразия“. А во-вторых, могут исчезнуть все проблемы, связанные с вниманием всякого рода ведомств — пожарных, коммунальных служб. Кроме того, кардинально изменится и маркетинг. Вместо того чтобы устраивать презентации, посвященные преимуществам различных устройств, появится маркетинг сервисов.Ну и, наконец, изменится вся система подготовки кадров в области информационных технологий. Это неизбежно, но для этого нужно сменить менталитет и выйти на принципиально новый уровень обеспечения информационной безопасности».

Центральный федеральный округ