ноябрь    2024

Пн	Вт	Ср	Чт	Пт	Сб	Вс
				1	2	3
4	5	6	7	8	9	10
11	12	13	14	15	16	17
18	19	20	21	22	23	24
25	26	27	28	29	30

показать все 

14.11.2024

Обновление BI.ZONE Secure DNS: гибкая настройка фильтрации и максимальная скорость

Читать далее 

14.11.2024

RED Security: в октябре количество DDoS-атак на ТЭК выросло в 3 раза

Читать далее 

14.11.2024

Falcongaze представила новую версию DLP-системы — SecureTower 7 Helium

Читать далее 

14.11.2024

ИСП РАН покажет результаты 30-ти лет работы на Открытой конференции в Москве

Читать далее 

08.11.2024

Юбилейная конференция ЭОС: ЭОС: 30 лет лидерства на рынке автоматизации документооборота и обсуждение актуальных трендов

Читать далее 

показать все 

22.11.2024

Тандем технологий – драйвер инноваций.

Читать далее 

21.11.2024

ИИ: маршрут не построен, но уже проектируется

Читать далее 

18.11.2024

Глеб Шкрябин: «Надежные и масштабируемые системы — основа стабильной работы бизнеса в условиях больших нагрузок»

Читать далее 

14.10.2024

Елена Ситдикова: «На разработчиках программного обеспечения для транспорта лежит большая ответственность перед пассажирами»

Читать далее 

11.10.2024

Технологический ИИ-арсенал

Читать далее 

13.06.2024

Взгляд в перспективу: что будет двигать отрасль информационной безопасности

Читать далее 

18.04.2024

5 способов повысить безопасность электронной подписи

Читать далее 

18.04.2024

Как искусственный интеллект изменит экономику

Читать далее 

18.04.2024

Неочевидный САПР: выход ПО за рамки конструкторской деятельности

Читать далее 

18.04.2024

Скоро некому будет делать сайты и заниматься версткой

Читать далее 

показать все 

Главная / Архив номеров / 2013 / Выпуск №9 (32) / Хоть горшком назови…

Рубрика: ИТ-управление

Константин Кондаков, работает старшим директором по ИТ в сан-францисской фирме Certain Software, обеспечивает бесперебойную работу центров данных и руководит системными администраторами в США, Великобритании и Австралии

Хоть горшком назови…

Чем должны заниматься ИТ-управленцы? Из чего складывается их рабочий день? В чем заключаются особенности ключевых ИТ-управленческих позиций в организации? Нужно ли стремиться стать вице-президентом по ИТ-системам любой ценой?

Константин Кондаков, работает старшим директором по ИТ в сан-францисской фирме Certain Software, обеспечивает бесперебойную работу центров данных и руководит системными администраторами в США, Великобритании и Австралии

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

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

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

Системные администраторы

Старший системный администратор – это своего рода «сержант» или «старшина» во взводе других системных администраторов. Да, его слушают, его уважают, часто его боятся, но ИТ-политику фирмы он не определяет. Считается, чтобы стать старшим системным администратором, надо находиться на третьем или четвертом уровне международной классификации администраторов SAGE [2] . Напомним классификацию SAGE, о которой уже говорилось на страницах «Системного администратора» [1] :

• Уровень 1. Начальный уровень. Требуется умение четко следовать инструкциям, работать под руководством более опытных администраторов, работать с пользователями. Сисадмины начального уровня могут решать самые простые задачи, уровень его знаний – эникейщик, который хочет узнать больше.
• Уровень 2. Младший системный администратор. Требуется один – три года работы системным администратором, который пишет несложные скрипты, немного знает сетевое оборудование, имеет некоторый опыт программирования. Он также неплохо знает операционные системы, может самостоятельно разобраться с программой, например, резервного копирования. Но при первой более-менее серьезной ошибке он пасует и не знает, что делать дальше.
• Уровень 3. Системный администратор среднего уровня. Прикладной опыт работы – не менее трех – пяти лет. Глубинные знания систем GNU Linux – понимание работы между процессами, свопинг, пейджинг и т.п. Знание структуры файловой системы, самостоятельная работа с протоколами типа NFS, NIS, IP, ICMP, UDP, TCP, SNMP, SMTP, LDAP и так далее. Системных администраторов третьего уровня – подавляющее большинство.
• Уровень 4. Старший системный администратор. Способен быстро и эффективно разобраться в сложной технической ситуации и решить любую системную проблему. Постоянно автоматизирует свою работу. Может самостоятельно справиться с большим количеством серверов – от 200 и выше. Старший системный администратор по одному-двум симптомам может практически безошибочно определить неисправность, что делает его очень ценным работником. Часто руководство фирмы знает своих «кулибиных» в лицо и прекрасно отдает себе отчет, кто действительно разбирается во всем, а кто лишь способен смотреть на «маленькие зеленые огоньки» в серверной комнате.

Менеджер проектов

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

Оказывается, для более-менее серьезного проекта, в котором участвуют несколько разработчиков, просто необходим менеджер проекта. Более того, для технологий экстремального программирования – Agile, Scrum – специально делается акцент на наличие так называемого scrum master, который бы управлял состоянием проекта и готовностью кода к релизу. И это является совершенно нетривиальной задачей. Тут нужно четкое понимание человекочасов, необходимых зависимостей, что можно делать параллельно, а где разработка и внедрение проекта элементарно останавливаются, потому что не готова какая-то функция в коде или не готов необходимый сервер. Подробный рассказ об экстремальном программировании требует отдельной статьи, а пока покажем (рис. 1), как продвигается проект. Что надо сделать? Что сделано? Что надо проверить? Всем этим кто-то должен управлять.

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

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

Рисунок 1. План продвижения проекта

Технический лидер – ведущий инженер

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

Типичный пример – установка системы централизованного управления серверами типа Puppet, Cfengine. Человек, который отвечает за подобный проект, должен не просто владеть вопросом SSH, DNS, host, но и понимать, как изнутри работает система типа Puppet,Cfengine, так как полноценное развертывание ее – отнюдь не тривиальная задача.

Строго говоря, технический лидер, как и старший системный администратор, скорее относится к категории «первый среди равных», чем к классу менеджеров. И, продолжая сравнение с военной субординацией, технический лидер (реже ведущий инженер) является полноценным старшиной в ИТ-структуре. В штатном расписании фирмы может и не быть официальной должности «ведущий инженер», но по мере роста и разделения полномочий системных администраторов появляется специализация «технический лидер по системам Microsoft Windows» или «специалист по массивам хранения (storage)» .

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

Системный архитектор

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

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

Более привычна ситуация, когда системный архитектор занимается «эскизами» информационной системы – мы используем только Java, и не просто Java, а Glassfish Server.

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

Системный архитектор просто обязан владеть чрезвычайно широким диапазоном знаний в самых различных ИТ-областях и грамотно парировать критику всезнаек: «А почему это мы решили использовать технологию А, а не технологию Б?» – ответами типа: «У технологии Б есть вот такие и такие ограничения, которые нашу фирму не устраивают. Я проверял – для этой задачи работать будет медленно. Нам нужно выбрать В или А, я выбрал А, и вот почему...»

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

Директор по ИТ

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

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

Не секрет, что в некоторых организациях все решения по использованию технологий проходят по принципу «лебедь, рак и щука». Например, один системный администратор в прошлом работал с Symantec Endpoint Protection – значит, ставим этот антивирусный продукт на все серверы и рабочие станции. Другой администратор неровно дышит в сторону McAfee Antivirus , а третий парирует доводы первых двух, сообщая, что надо использовать ESET Smart Security и больше ничего! Подобные разногласия встречаются на каждом шагу, и цель директора ИТ – постоянно направлять энергию системных администраторов в правильное и конструктивное русло. Критериев тут может быть несколько:

• Финансовая целесообразость. То, что отлично работает в крупной фирме, может не подходить по цене средней, совершенно не годится для маленького стартапа и наоборот.
• Бизнес-целесообразность. Нельзя слепо копировать удачное использование той или иной технологии по принципу только что прочитанной обзорной статьи или хуже того – «одна бабка сказала». На моем опыте было много примеров, когда идеально работающий в одном месте программный комплекс или даже информационная система оказались совершенно неработоспособными в других условиях. Часто различия могут быть глубоко скрыты от невооруженного глаза. Ну, например, интереснейший программный продукт с документацией, существующей только… на китайском языке. Если в фирме есть сотрудники, которые могут разобраться в этом, – очень хорошо. А что делать, если их нет?
• Технические ограничения. Что нам подходит, а что нет.

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

Оценим степень «запущенности» ИТ-организации [3] и составим список конкретных мер по наведению порядка.

Посмотрим на текущее положение вещей по наличию и (или) отсутствию вот таких элементов в списке:

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

Знакомая ситуация? К счастью, существуют проверенные пути решения перечисленных выше проблем:

• Достижение идентичности результатов.
• Обучение системных администраторов, а также поддержание текущей документации – для каждой проблемы есть четкое и всем понятное решение.
• Снижение и устранение двойной работы.
• Автоматизация всех возможных процессов.
• Мониторинг – сначала первоочередных служб, а затем и всех остальных, которые могут представлять интерес.
• Стресс-тестирование, планирование возможностей системы для роста и нагрузки.
• Совместная «работа над ошибками» с разработчиками – встречи должны быть раз в неделю, но можно и чаще по мере необходимости.
• Получение независимой сертификации по безопасности системы, например, PCI [4] или SOX. Хотя часто подобная сертификация не является «серебряной пулей» или универсальным решением ИТ-проблем по безопасности, подготовка к получению, а также получение этой сертификации говорят, что не все так плохо с точки зрения ИТ-директора. Ну, например, как сданный на отлично вступительный экзамен по математике на мехмат МГУ.

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

Рисунок 2. Совместная работа

Вице-президент по ИТ, вице-президент по разработке

Должность вице-президента – это совершенно иной управленческий уровень. Это переход из офицерского состава (уровень директора) в генералитет. Разумеется, речь идет о зрелых фирмах, а не о стартапе: «я президент, а ты у меня – вице-президент». Существуют два основных отличия этой должности от статуса директора.

Первое. В отличие от позиции директора (или старшего директора), вектор которой направлен ВНУТРЬ подразделения, вектор позиции вице-президента имеет ВНЕШНЮЮ направленность. А что это означает?

Это означает, что с назначением на должность вице-президента управленец перестает плотно заниматься текущими вопросами ИТ, работой ЦОД, а переходит на уровень КООРДИНАЦИИ РАЗНЫХ ОТДЕЛОВ – возможно, отдела системных администраторов, отдела по тестированию, инженеров и т.п. То есть требуется равновеликое понимание приоритетов в других отделах, постановка задач, расчет монетизации всей подотчетной информационной структуры и т.п. Понятно, что резко возрастает политическая составляющая – умение находить компромиссы, понимать, что такое «искусство возможного», заручаться поддержкой ключевых сотрудников, понимать закулисные процессы фирмы и многое другое – этим отличается опытный и мудрый руководитель от просто выскочки-всезнайки. Руководить системными администраторами придется в этой ситуации кому-то другому.

Второе отличие – это резкое поднятие горизонта принятия решений. Вице-президент подчиняется СЕО, в крупной фирме, возможно, CIO, но от масштаба задач уровня «наладить резервное копирование» придется переходить к «снизить уровень расходов ЦОД до 10% от прибыли фирмы» или «обеспечить монетизацию нового продукта до конца года». А как это сделать? Страховки больше нет, за плечами вице-президента стоит только САМОЕ большое начальство, которое мыслит еще более абстрактными категориями – «поднять прибыль фирмы на 20%» или «проникнуть на рынок Юго-Восточной Азии»

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

СТО – Chief Technical Officer

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

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

• Фирма уделяет очень большое внимание своей технологии и показывает, что во главе технологического ареопага стоит не случайный человек.
• Человек, занимающий эту позицию, наверняка обладает очень высоким авторитетом для принятия решений. Более того, что касается конкретно прикладных задач, используемых методов и технологий, – СТО сам себе указ, ни кому не подчиняется и не обязан ни перед кем отчитываться.

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

Часто на должность СТО завлекают талантливых инженеров или ИТ-управленцев из более солидных фирм – чтобы предложение было заманчивым, от которого невозможно было бы отказаться, звучать оно может примерно так: «Ты будешь вторым (третьим) человеком у нас на фирме, вот максимальная зарплата, которую мы можем тебе платить. Делай, что хочешь. Найди любых людей. Любой ЦОД. Любую технологию. Но, главное, сделай так, как на фирме XYZ. Уровень СТО тебя устроит?» Оборотная сторона такой должности состоит в том, что придется очень и очень много работать. Это характерно для стартапов, для фирм, меняющих профильный продукт, испытывающих «болезни внезапного роста», и т.п.

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

Рисунок 3. Визуальный мониторинг ИТ-системы

CIO – Chief Information Officer

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

CIO как высший управленец наряду с финансовым директором (CFO – Chief Financial Officer) определяет все самые важные информационные приоритеты фирмы. Главное отличие этой должности от CTO, а часто и от позиции вице-президента – это прямое участие во всех бюджетно-доходно-расходных позициях ИТ-отдела, распределение бюджета и окончательное принятие решений по финансовым вопросам. Например, если вице-президента по разработке может не интересовать, сколько стоит ЦОД или сколько и каких облаков придется арендовать в Amazon EC2, то все эти вопросы окончательно замыкаются на уровень CIO. За ним последнее слово в вопросе – нанять ли супер-разработчика за 200 долларов в час или «оффшорную бригаду» или использовать Go Daddy, или остаться в линейке продуктов Microsoft, или купить CISCO Nexus.

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

Добавим еще и то, что CIO – это 100% политическая должность. Если вице-президент по ИТ – это, возможно, генерал-майор или генерал-лейтенант, то CIO – это, наверное, генерал-армии или даже маршал.

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

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

Поэтому и CIO надо быть в десять раз более осмотрительным, недаром эта аббревиатура часто шутливо расшифровывается как Career is Over («карьера закончена»). Ну да. Если вы работаете CIO в корпорации типа Boeing или Exxon, то куда двигаться дальше?

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

Хотя не исключено, что с должности CIO можно попасть куда-нибудь в Совет директоров, а то и стать Председателем Правления. Но на таких должностях CIO оказывается не из-за знания ИТ, а по политическим причинам – устраивающая всех кандидатура, нужные связи «наверху», показал себя «человеком дела» и т.п. Все эти личностные и деловые качества ИТ-специалисту, твердо намеренному идти наверх, надо постоянно развивать.

1. Кондаков К. Админы всякие нужны. //«Системный администратор», №3, 2011. – С. 82-85 (http://samag.ru/archive/article/1206).
2. http://www.sage.org/field/jobs-descriptions.html .
3. http://everythingsysadmin.com/2013/09/devops-lookfors.html .
4. Кондаков К. PCI – стандарт надежности ИБ при работе с кредитными картами. //«Системный администратор», №10, 2011. – С. 106-112 ( http://bit.samag.ru/archive/article/1127).

В начало⇑

Комментарии отсутствуют

Комментарии могут отставлять только зарегистрированные пользователи