`

СПЕЦИАЛЬНЫЕ
ПАРТНЕРЫ
ПРОЕКТА

Архив номеров

Как изменилось финансирование ИТ-направления в вашей организации?

Best CIO

Определение наиболее профессиональных ИТ-управленцев, лидеров и экспертов в своих отраслях

Человек года

Кто внес наибольший вклад в развитие украинского ИТ-рынка.

Продукт года

Награды «Продукт года» еженедельника «Компьютерное обозрение» за наиболее выдающиеся ИТ-товары

 

9 иллюзий ИТ-директора

Обманывая себя, руководители ИТ-служб закладывают мину замедленного действия и создают предпосылки для грядущих катастроф.

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

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

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

Иллюзия № 1. Мы ориентируем ИТ на бизнес.

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

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

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

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

Иллюзия № 2. Единственная причина обновления программного обеспечения обусловлена реализацией в новой версии важных ценностей бизнеса.

Это не просто звучит убедительно, а принимается как руководство к действию. Явно, что ИТ-директор, проводящий такую политику, ориентирован на бизнес (и соответствие его целям) и его никак нельзя обвинить в тратах на технологии ради самих технологий.

Более того, при таком раскладе ИТ-бюджет можно сокращать, поскольку нет необходимости в средствах на поддержание актуальных версий.

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

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

Иллюзия № 3. Реализация большого и важного проекта не укладывается в сроки? Перейдем сразу к следующему этапу и завершим его, как было намечено по графику.

Вот как обычно развиваются события.

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

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

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

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

А во-вторых, начинают подыскивать себе работу, пока проваленный проект еще не погубил их репутацию.

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

Тестирование второго уровня. Вы всегда проводите тестирование, и причем весьма тщательно. Единственный вопрос, выполняется ли тщательное тестирование до или после того, как программное обеспечение уйдет в производство.

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

Иллюзия № 4. Мы придерживаемся методологии ITIL.

Это может показаться придиркой, но «придерживаться» ITIL невозможно. ITIL — это библиотека инфраструктуры ИТ, как терпеливо объясняют ее сторонники всем, кто готов слушать.

В ITIL перечислены направления, в которых применение ИТ целесообразно. Там не описано, как добиться этой целесообразности, равно как нет рекомендаций ITIL на все случаи жизни.

Между тем есть много ИТ-директоров, для которых «соблюдение ITIL» эквивалентно созданию приличной сервисной службы (или, по крайней мере, переименованию службы поддержки в «сервисную службу») и формированию консультативного совета по изменениям, который будет располагаться между разработчиками приложений и обслуживающим персоналом. В этом случае и те и другие будут апеллировать к консультативному совету, а не друг к другу.

Иллюзия № 5. Мы исповедуем agile-разработку.

В мире есть много ИТ-организаций, уже перешедших от разработки приложений методом водопада к одному или нескольким вариантам agile-проектирования либо находящихся в процессе такого перехода.

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

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

Иллюзия № 6. Мы придерживаемся DevOps.

Ничего подобного. Вы не придерживаетесь даже agile-проектирования. И удосужились ли прочесть все то, что было написано ранее?

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

Вот что DevOps добавляет в гибкое проектирование.

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

Третий момент связан с DevOps, а не с другими вариантами гибкого проектирования и уж, конечно, не с водопадной методологией. Дело в том, что программное обеспечение находится в состоянии постоянного развертывания (deployable). Нет, нет, не deplorable (в плачевном виде), а deployable. Наряду с многочисленными неудобствами для большинства сторонников гибкой разработки это означает, что DevOps и Scrum не являются полностью совместимыми. Kanban работает лучше.

Иллюзия № 7. У нас есть культура обслуживания клиентов.

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

Впрочем, это неважно, ведь когда культура есть, ИТ-директор считает, что весь бизнес является его клиентом.

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

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

ИТ-директор должен воспитывать в ИТ-службе культуру обслуживания.

Как узнать, есть ли у вас эта культура или нет? Если вы по-прежнему слышите рассказы об идиотах-пользователях, значит, ее нет.

Иллюзия № 8. Наша информационная безопасность на высоте

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

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

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

Иллюзия № 9. Наш процесс управления ИТ гарантирует реализацию только тех проектов, которые имеют высокую ценность для бизнеса

Давайте опять вернемся к соответствию целям бизнеса.

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

Таким образом окончательные решения становятся еще и предметом торга и выстраивания личных взаимоотношений.

Сюда следует добавить и еще одну неприятную деталь: проекты, цель которых заключается в сокращении расходов, будут приоритетнее, чем проекты, направленные на увеличение доходов. Почему? Сокращение расходов бизнес может контролировать. Если все идет по плану, расходы будут сокращаться.

Увеличение же доходов требует от клиентов того, чего вы хотите. А они зачастую этого не делают. И вы не можете им приказывать, а вынуждены пытаться убеждать.

Какой же вывод можно сделать? Если вы в чем-либо уверены, то почти наверняка ваша уверенность ошибочна. И если, будучи ИТ-директором, вы готовы записать в свой актив девять перечисленных пунктов (или каких-то других), задайте себе простой вопрос: почему? И постарайтесь на него ответить.

Отмена сетевого нейтралитета в США. Что изменилось и чем это нам грозит?

Прошло уже почти два месяца с принятия в США скандального решения об отмене сетевого нейтралитета. Но мир не рухнул. И кроме волны публикаций, никаких видимых изменений не произошло. Может еще рано? Давайте разберемся, что же такое сетевой нейтралитет, и как это решение затронет нас.

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

Что изменилось? После отмены сетевой нейтральности, провайдеры США могут любым способом регулировать или ограничивать любое движение трафика по своим сетям.

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

Противники сетевого нейтралитета основным аргументом приводят недопустимость вмешательства государства в конкуренцию. Что рынок сам урегулирует все вопросы.

Чем это может грозить другим странам?

Мы все пользуемся сервисами, родина которых находится в США — Google, YouTube, Facebook, и так далее. Соответственно, нам не безразлично, как эти сайты будут работать. Пока отложим в сторону момент, что у всех этих крупных компаний есть датацентры и в других регионах. Следовательно, на нас это решение вообще никак не повлияет. Допустим, мы пользуемся каким-то сайтом, который находится только в Штатах.

Начнем с того, что у большинства европейских стран нет прямых каналов на США. Эту связь обеспечивают крупные магистральные провайдеры из нескольких узловых точек. Если посмотреть карту подводных кабелей то можно увидеть, что этих линий — множество. Соответственно, чтобы ограничить доступ из европейского континента, нужно чтобы все эти провайдеры установили ограничения. Что, согласитесь, звучит маловероятно.

Отмена сетевого нейтралитета в США. Что изменилось и чем это нам грозит?

Минутку, а что сейчас у нас происходит?

Сетевой нейтралитет — это исключительно особенность США. Ни в одной другой стране такой нормы в законах нет.

В Украине этот принцип также не соблюдается.

  • Есть блокировки доступа к определенным сайтам.

  • Крупные сотовые провайдеры предлагают бесплатный трафик к различным сервисам, в том числе и своего производства.

  • Провайдеры кабельных сетей настраивают приоритеты внутри своих сетей для экономии каналов или предоставления приоритетов крупным клиентам.

Блокировку сайтов в данном случае логичнее вынести за скобки, так как даже в США есть ряд законов, определяющих цензуру в Сети. В остальном же мы видим обычную конкуренцию на рынке, когда клиент может выбрать провайдера, предлагающего наилучшие условия или дополнительные услуги. И никому в голову не приходит обвинить какого-то сотового оператора в лоббировании интересов Facebook, предоставляя бесплатный трафик.

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

Группы ресурсов в Microsoft Azure. Что это такое?

Вместе с новым порталом управления облаком Microsoft Azure появилось и множество других изменений. Многие из которых кардинально изменяют подход к работе с облачными сервисами. Естественно, в лучшую сторону. Но любые изменения – это новый принцип работы, новые правила. А это не всегда удобно. Давайте попробуем разобраться, что же у нас добавилось, и стоило ли оно того?

Основное изменение, которое произошло в Azure – это появился новый подход к управлению всеми элементами облака. И называется он – управление ресурсами. Соответственно, старый подход называется – классический. Старый портал управления позволяет работать только по классическому методу. Новый же портал предлагает выбор. И в панели управления теперь есть две иконки – одна для виртуальных машин старого типа, другая – нового.

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

Группы ресурсов в Microsoft Azure. Что это такое?

У нас есть виртуальная машина, учетная запись хранения данных и виртуальная сеть. Каждая виртуальная машина должна относиться к какому-то облачному сервису, который имеет реальный IP адрес. Все. Никаких более параметров у вас нет. Сетевой интерфейс и сетевой адрес жестко привязаны к виртуальной машине. Если вы удаляете машину – все правила безопасности, настройки портов и так далее, удаляются.

Теперь посмотрим, как выглядит аналогичная конфигурация уже в ресурсном подходе:

Группы ресурсов в Microsoft Azure. Что это такое?

Как видно, сетевые параметры выделены как отдельные ресурсы. Плюс к ресурсам относится и виртуальный диск, и параметры доступности, и опции безопасности. Что же это нам дает? При ресурсном походе, мы получаем дополнительную гибкость в управлении. А именно:

  • Удаление виртуальной машины не удаляет сразу ее сетевые настройки и опции безопасности. Вы можете перенести уже настроенные параметры на другую машину.
  • К каждой ресурсной группе можно предоставлять отдельные права доступа. Таким образом, вы можете создать для каждой группы администраторов свои группы ресурсов, которыми они будут управлять. При этом все эти виртуальные машины по прежнему будут работать в одной общей сети.
  • Azure позволяет управлять ресурсами с помощью новых инструментов PowerShell на основе шаблонов. Имеется множество преднастроенных шаблонов для создания как отдельных виртуальных машин, так и целых инфраструктур просто путем запуска нескольких скриптов. Такое конечно же можно было делать и ранее, но новый подход на базе шаблонов намного удобнее.

Также хочется добавить, что Microsoft добавил кроме PowerShell, еще и отдельную консоль командной строки для управления облаком. Консоль кросс-платформенная, и может устанавливаться и на Mac и на Linux. Если бы мне кто-то сказал такое еще несколько лет назад – я бы точно не поверил!

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

Рецензия на книгу «Remote. Офис не обязателен»

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

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

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

Рецензия на книгу «Remote. Офис не обязателен»

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

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

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

Нужно ли системному администратору высшее образование?

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

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

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

Итак, на первом этапе обучения у молодого сисадмина еще нет понимания, на чем он будет специализироваться. Да, и общие базовые знания по различным системам получить просто обязательно. Поэтому, минимум, который я выделил, это:

  • Основы сетей (топологии, основные протоколы, маршрутизация).
  • Основы Windows систем (AD, DNS, файловые сервера, терминальные сервера).
  • Основы Linux (web-серверы, почтовые серверы, серверы для файловых хранилищ, прокси и контроль доступа в Интернет).

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

Теперь рассмотрим, как же можно приобрести данные знания. А главное – где и как получить практический опыт. Ведь теоретизирующий сисадмин без малейшего опыта вряд ли заинтересует большинство работодателей.

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

Для тех, кто владеет английским (а если хотите стать хорошим ИТ-специалистом – то без этого никак), есть также и зарубежные курсы. В том числе и бесплатные. Например, на портале www.udemy.com есть ряд бесплатных материалов для начинающих. Такие курсы как Introduction to networking for complete beginners конечно не научат вас чему-то серьезному, но основы дадут. Также есть профильные обучающие порталы от вендоров. Один из вариантов – виртуальная академия «Майкрософт». И естественно, сейчас вы легко можете найти массу форумов, сообществ и групп в социальных сетях, где общаются специалисты по выбранному вами направлению.

Так что с теорией, на мой взгляд, у будущего системного администратора, проблем не должно возникнуть. Теперь посмотрим на вторую составляющую.

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

В случае, если хочется изучить сеть более подробно, можно найти онлайновые тестовые лаборатории с доступом к оборудованию Cisco. Например, тут можно получить доступ по Telnet к коммутаторам, и попробовать выполнить различные настройки.

С практикой по технологиям «Майкрософт» вообще, на мой взгляд, нет никаких проблем. Начать можно с виртуальных лабораторий, в которых по приложенным описаниям можно изучить самые различные продукты и решения. Далее можно взять три месяца тестового периода на Microsoft Azure и развернуть уже свои виртуальные машины под необходимые задачи. А на них можно изучать хоть Linux, хоть Windows. Опять же, если у вас дома маршрутизатор поддерживает VPN, то можно поднять канал с облаком и настроить гибридную инфраструктуру между облачной и домашней сетями.

Таким образом, будущий системный администратор может получить реальные практические навыки по очень большому количеству различных технологий. Желательно, чтобы итогом такого обучения стало получение фирменных сертификатов от «Майкрософт» или Cisco. Это будет весьма неплохим аналогом диплома вуза.

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

От себя же могу сказать, что если ко мне придет на собеседование кандидат без университетского диплома, но обучавшийся по подобной методике (при условии конечно, что он приобрел все нужные навыки и знания), то для меня этого будет достаточно, чтобы принять его на работу. А как вы думаете? Насколько необходимо современному ИТ-инженеру именно классическое высшее образование?

ИТ-департамент как стартап

ИТ-руководители крупных предприятий с некоторой долей иронии смотрят на феномен стапртапов. Дескать, попробовали бы вы поработать на настоящем предприятии!

Термин «стартап» сегодня, вероятно, имеет самую высокую частоту упоминания. Миллионы восхищаются молодыми предпринимателями, буквально «на коленках» создавших быстро растущие и прибыльные компании.

Согласно википедии, у стартапа есть несколько определений:

Стивен Бланк определил стартапы как временные структуры, существующие для поиска воспроизводимой и масштабируемой бизнес-модели.

Автор книги «Бережливый стартап» и идеолог итеративного подхода в предпринимательстве Эрик Рис отмечает, что стартапом может быть названа организация, создающая новый продукт или услугу в условиях высокой неопределённости.

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

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

Так что, по сути, стартап и работа ИТ-департамента имеют много общего. Но есть и еще одна характеристика стартапа:

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

Конечно же, любой ИТ-директор сразу возразит, что мы говорим о культуре организации. Что формирование сплоченности в коллективе – обычное дело для корпоративного HR-департамента. И что разница есть только в масштабе предприятия и его возрасте.

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

Насколько применимы подходы, характерные стартапам, в работе ИТ-директора и его отдела? Может ли CIO рассматривать свой департамент именно как внутреннюю стартап-команду?

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

Azure Machine Learning. Создание простого эксперимента

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

Компания «Майкрософт» недавно выпустила в стадии «preview» свой сервис Azure Machine Learning. В Интернете есть статьи по этому поводу, но на мой взгляд, они не совсем полные. Я же хочу показать, как на базе данного сервиса получить полностью рабочий сервис, с которым вы сможете работать из своего приложения.

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

Для начало очень кратко, немного теории. Машинное обучение может применять следующие технологии:

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

Azure Machine Learning. Создание простого эксперимента

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

Azure Machine Learning. Создание простого эксперимента

– Кластеризация – когда у нас есть только исходный набор данных без результирующих значений. Задача кластеризации – выявить закономерность в неструктурированных данных.

Azure Machine Learning. Создание простого эксперимента

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

Итак, как же это делается в системе машинного обучения Azure?

Если у вас есть подписка на облако Майкрософт, вам нужно активировать машинное обучение по ссылке: http://azure.microsoft.com/en-us/services/preview/

Вы также можете совершенно бесплатно протестировать машинное обучение, войдя под Microsoft ID в Azure ML Studio: https://studio.azureml.net/Home

В качестве исходных данных берем вот такую таблицу:

Azure Machine Learning. Создание простого эксперимента

– Year – год продаж
– Month – месяц продаж
– DayOfWeek – день недели продаж
– Hour – час продаж
– Category – категория товара
– Price – диапазон цен (для примера, берем диапазоны 50 – 60, 60 – 70 и т.п.)
– Sales – объем продаж.

Мы хотим сделать отчет для руководителя, который будет показывать прогноз продаж товаров по категориям на следующую неделю с разбивкой по времени и ценам. Т.е. я хочу знать, как у меня будут продаваться товары 1 и 2 в понедельник, и какие цены будут наиболее востребованы.

Первое, что нужно сделать – это загрузить данные в студию машинного обучения.

Azure Machine Learning. Создание простого эксперимента

Azure Machine Learning. Создание простого эксперимента

Студия умеет работать с csv и tsv файлами с заголовком или без заголовка. Можно также загружать plain text, но тогда могут возникнуть вопросы с типами данных. Кроме этого, можно подключаться и к базам данных, веб сайтам, хранилищам Azure, но это уже более сложные варианты.

Теперь создаем новый эксперимент:

Azure Machine Learning. Создание простого эксперимента

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

В первую очередь, добавляем наш сохраненный набор данных. Для этого раскрываем группу «Saved datasets», находим наш набор данных, и перетаскиваем его на рабочую область.

Далее, для правильной работы системы обучения, нам нужно разбить набор данных на две группы – одну для обучения, вторую для тестов. Для этого используется модуль «Split». Удобнее всего в окне поиска над списком элементов ввести его название, чтобы не искать по всему дереву компонент. Перетащив этот модуль на рабочую область, соединяем выход нашего набора данных со входом модуля «Split». Кликнув на этом модуле, справа откроется окно параметров. Выставляем значение 0,8 в поле «Fraction of rows». Это означает, что мы 80% данных будем использовать для обучения, а 20% – для тренировки.

Следующим этапом выбираем модель, которая будет использоваться для обучения. Azure предлагает большой набор моделей. Для наших целей очень удобной является модель, сочетающая классификцацию и регрессию. Это decision forest regression. Эта модель разбивает все данные на группы по категориям, и затем для каждой категории применяет алгоритм регрессии. Как раз то, что нам нужно.

Теперь нужно обучить нашу собственную модель. Для этого добавляем компоненту «Train Model». Кликнув на модуль, нужно выбрать столбец, по которому мы будем делать прогноз. В нашем случае это столбец «Sales». Чтобы его выбрать, кликаем на поле «Column selector» и выбираем «Sales».

Осталось только оценить, насколько наша модель хорошо работает. Для этого служит модуль «Score model», у которого два входа – один от обученной модели, а второй – от тестового набора данных. В итоге, наш проект должен выглядеть вот так:

Azure Machine Learning. Создание простого эксперимента

Запустив модель, и убедившись, что ошибок нет, мы можем оценить качество ее работы. Кликнув по выходному узлу элемента «Score model», выбираем «Visialize». Откроется результирующий набор данных, прошедший через процесс проверки. По нему мы сможем сравнить, насколько точно наша модель предсказывает значения.

Azure Machine Learning. Создание простого эксперимента

В данном наборе данных мы видим наши исходные числа, а также два новых столбца – прогнозируемое значение и прогнозируемое отклонение. Как можно увидеть, прогнозируемое значение конечно отличается от исходного, но отклонение не всегда очень больше. Естественно, что для данных без какой либо закономерности, предсказать со 100% точностью будет попросту невозможно.

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

Для того, чтобы использовать полученные результаты в какой-то внешней системе (например, ваша внутренняя система отчетов, или корпоративный портал), нужно опубликовать эту модель как сервис. Для этого нужно создать второй проект, который и будет обрабатывать внешние данные. На нижней панели инструментов нажимаем кнопку «Create scoring experiment». Система создаст новый проект, где наша обученная модель будет использоваться уже как источник обученных данных.

Azure Machine Learning. Создание простого эксперимента

Вот так должна выглядеть ваша новая модель. Изначально в ней нет одного элемента – «Project column». Вам нужно самостоятельно вставить его между вашим источником данных и модулем оценки модели. И кликнув на этот элемент, выбрать все столбцы кроме нашего «Sales».

Azure Machine Learning. Создание простого эксперимента

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

Наш набор данных в данной модели используется исключительно для предоставления структуры данных для модели. Сами данные будут поступать через модуль «Web service input».

Все, осталось запустить модель, и по итогу, нажать кнопку «Publish web service».

Вот так выглядит страница с API созданной нами модели:

Azure Machine Learning. Создание простого эксперимента

С этой страницы вы можете выполнить тестовый запрос по кнопке «test». Введя нужные параметры, вы получите прогнозируемое значение от модели. А страницы помощи по API содержат готовые примеры программного кода и ключи доступа, с помощью которых вы на программном уровне можете обращаться к модели и использовать прогнозы в любых ваших системах.

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

Azure Machine Learning. Создание простого эксперимента

Azure RemoteApp. Обзор основных возможностей

Недавно компания Microsoft анонсировала, что в ближайшем будущем облачный сервис опубликованных приложений RemoteApp выйдет из стадии Preview и будет доступен всем подписчикам Microsoft Azure. На сегодня этот сервис также доступен, но требует предварительной активации. Я решил разобраться, какие же особенности предоставляет это решение.

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

Облако Microsoft предлагает типовой набор опубликованных приложений из коробки. Он включает в себя набор офисных программ из комплекта Microsoft Office 2013 Pro Plus. Если вы оформили подписку на услугу Office 365, то можете уже сейчас использовать данный продукт. Если нет – у вас есть 30 дней чтобы протестировать работу опубликованных приложений.

Итак, как же это все выглядет. Создание приложений осуществляется в прямом смысле в два клика мышкой:

Azure RemoteApp. Обзор основных возможностей

Выбрав в портале сервис RemoteApp, вы вводите его название и выбираете шаблон. Все. Далее ждем около получаса пока система подготовит для вас нужный набор приложений.

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

Azure RemoteApp. Обзор основных возможностей

Опубликовав нужные сервисы, нужно предоставить к ним доступ пользователям. По умолчанию, облачная система умеет работать только с пользователями, локально созданными в Azure. Точнее, у пользователя должен быть Microsoft ID (ранее известный как Live ID), и по этому ID администратор портала может предоставить доступ к опубликованным приложениям.

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

На моменте добавления пользователей появляется первое неудобство. Вы не можете выбрать пользователей из списка. Вам нужно будет вручную вводить всех сотрудников. Либо вы можете создать текстовый документ, и загрузить его на портал. Но такой опции, как например, модуль администрирования в Office 365, я пока не обнаружил.

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

Azure RemoteApp. Обзор основных возможностей

Даже если у меня работает только 15 человек с системой, счет мне будет выставляться за 20. Так что, имейте это в виду при планировании, а также при тестировании системы.

Максимальное количество одновременных сеансов для плана «Стандарт» составляет 400. Что соответственно, накладывает ограничение верхнего плана для крупных компаний.

Итак, мы опубликовали приложение, предоставили доступ. Пора попробовать поработать с ним. Для этого нам понадобится клиент удаленного рабочего стола, который к нашей радости, имеется под все платформы. Я например, попробую подключиться к приложениям с платформы Mac OS:

Azure RemoteApp. Обзор основных возможностей

Аналогичный клиент, который выглядит точно также, есть под Android и iOS.

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

Вторым неудобным моментом является отсутствие доступа к локальным ресурсам компьютера. Когда я запустил Word, в меню «Открыть» или «Сохранить», я могу работать либо с облачными хранилищами, либо с локальным диском сервера, содержащего опубликованные приложения.

Azure RemoteApp. Обзор основных возможностей

Административных прав на этот сервер у меня нет, поэтому никаких настроек с ним сделать нельзя. Но можно создавать свои образы, и публиковать свои собственные приложения. Для этого необходимо создать виртуальную машину со всем необходимым набором программ, и загрузить ее в облако. Далее на основании этого шаблона вы можете создать свой собственный набор сервисов. Также RemoteApp позволяет публиковать приложения, размещенные в вашей корпоративной сети. Так что, набор услуг, предлагаемых данным сервисом, довольно интересен.

Microsoft Azure: cравнение скорости накопителей

В продолжение темы прошлой заметки, представляется интересным сравнение производительности накопителей, используемых в различных классах виртуальных машин Microsoft Azure. Что ж, давайте проведем еще одно тестирование.

Для него воспользуемся бесплатной утилитой HD Speed.

Поскольку при тестировании на запись она уничтожает все содержимое диска, то системный накопитель можем проверить только на чтение, зато временный (D:) — по полной программе.

Напомню, что Microsoft для машин D типа заявляет использование для временных накопителей именно SSD. Цель — хранение журналов баз данных, кэшей и других данных, требующих высокой скорости дисковых операций, но сохранность которых не критична.

В качестве исходных машин берем машины классов А2 и D2 с операционной системой Windows Server 2012 R2 Datacenter.

Машина класса А2

Системный диск, чтение.

 cравнение скорости накопителей

Временный диск (D:), чтение:

 cравнение скорости накопителей

Временный диск (D:), чтение и запись:

 cравнение скорости накопителей

Временный диск (D:), запись:

 cравнение скорости накопителей

Виртуальная машина класса D2

Системный диск, чтение:

 cравнение скорости накопителей

Временный диск (D:), чтение:

 cравнение скорости накопителей

Временный диск (D:), запись:

 cравнение скорости накопителей

Временный диск (D:), чтение и запись:

 cравнение скорости накопителей

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

Что интересно, радикального отличия в производительности накопителей у машин разных типов не наблюдается. Конечно же, D2 демонстрирует лучшие показатели, но, вероятно, не настолько, чтобы оправдать практически двукратный рост цены. Основное преимущество заключается в скорости чтения с временных накопителей. То есть, для хранения кэша или других временных оперативных данных, когда этот показатель играет действительно важную роль, использование машин D типа имеет смысл. В остальных же случаях, если исходить исключительно из дисковой производительности, переплата скорее всего не будет оправдана.

Microsoft Azure: cравнение производительности виртуальных машин типа А и D

Недавно Microsoft представила новый тип виртуальных машин Azure — D. Такие ВМ отличаются более быстрыми процессорами и наличием SSD. Но интересно понять, насколько в реальности возросла производительность, и в каких случаях их использование оправдано.

Для сравнения, я создал две виртуальные машины с одинаковой системой — Windows Server 2012 R2 Datacenter. Остальные параметры были оставлены по умолчанию. В качестве теста использовалась довольно простая операция — архивирование 3 ГБ AVI-файла с помощью 7zip (тип архива — zip, уровень сжатия — normal). При этом можно оценить производительность как процессора, так и накопителя.

Архивация выполнялась дважды: 1) и видео файл, и архив размещались на системном диске; 2) видео — на системном, а архив — на временном, который автоматически создается в каждой виртуальной машине.

 cравнение производительности виртуальных машин типа А и D

Итак, что же получилось:

Виртуальная машина А1 (1 ядро, 1.75 ГБ памяти), тип — Basic, цена — $56 в месяц:

  • архивация на системный диск — 13 мин 30 сек;
  • архивация на временный диск — 13 мин 10 сек.

Виртуальная машина А1 (1 ядро, 1.75 ГБ памяти), тип — Standard, цена — $67 в месяц:

  • архивация на системный диск — 9 мин 20 сек;
  • архивация на временный диск — 9 мин 3 сек.

 cравнение производительности виртуальных машин типа А и D

Виртуальная машина D1 (1 ядро, 3.5 ГБ памяти), тип — Standard (для машин класса D пока уровень Basic недоступен), цена — $118 в месяц:

  • архивация на системный диск — 6 мин 12 сек;
  • архивация на временный диск — 6 мин 8 сек.

 cравнение производительности виртуальных машин типа А и D

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

 
 
IDC
Реклама

  •  Home  •  Рынок  •  ИТ-директор  •  CloudComputing  •  Hard  •  Soft  •  Сети  •  Безопасность  •  Наука  •  IoT