Набираем только лучших
Секреты управленцев

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

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

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

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

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

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

Негативные результаты, которые обязаны быть приняты во внимание:

• Допущена масштабная атака хакеров на систему, взломаны серверы баз данных.
• Неудовлетворительная работа системы контроля версии или ее отсутствие.
• Большой процент «ручного доступа» на «боевые серверы».
• Нет управления конфигурацией (типа Puppet, Cfengine, Microsoft Management Console, etc).
• Не состоялся релиз продукта.
• Замечания по нестабильности системы не были исправлены за последние три – шесть месяцев.
• Не состоялась миграция данных, их пришлось восстанавливать из системы резервного копирования.
• Не произошло ни одной серьезной системной интеграции за последний год.

Позитивные результаты, которые должны быть приняты во внимание:

• Была совершена миграция на другую операционную систему.
• Была совершена миграция ЦОД (например, переезд в другое место).
• Была написана версия продукта под другую операционную систему.
• Произошла существенная экономия бюджетных средств.

Распределяем приоритеты в работе

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

Согласимся, что, если бы почтовая программа Gmail была недоступна 50% времени, ею бы мало кто пользовался.

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

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

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

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

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

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

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

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

В корпорации Apple подобная практика называется DRI (Directly Responsible Individual – Лицо, ответственное за исполнение). Поэтому никогда не должно возникнуть вопроса: «А кто, собственно говоря, за это отвечает?» Такой подход исключает перекладывание ответственности «с Фомы на Ерему, с Еремы на Якова, с Якова на всякого», и, таким образом, любой проект имеет четко прописанного руководителя.

И еще раз про документацию...

В который раз приходится повторять, что без правильно составленной и своевременно обновляемой документации нельзя рассчитывать на эффективную работу отдела ИТ. А что такое «правильно составленная документация»?

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

В качестве сравнения с таким подходом приводят кулинарные рецепты: «Если взять столько-то теста, столько-то крема и следовать определенной инструкции, то торт «Птичье молоко» можно приготовить не только на кухне ресторана «Прага», но и в Нью-Йорке, Бомбее или Мельбурне».Если вкус изделия отличается от того, что известен нам как «Птичье молоко», значит, не хватает какого-то компонента или что-то в приготовлении не соответствовало инструкции.

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

В самом первом приближении, чтобы обслуживать 150 миллионов запросов в час, требуется:

• 500 веб-серверов, работающих под Linux Debian (тонкости конфигурации прилагаются);
• cisco catalyst 7000;
• 25 серверов для data warehousing;
• 3 сервера Oracle Enterprise Edition, работающие на Sun Solaris M4000;
• 10 серверов для индексов

и т.д., причем детальная конфигурация – или полная (с комментариями) версия системы Puppet, Cfengine, Chef – с первого шага «вынуть сервер из коробки» до «мы имеем работающую систему» обязательно должна присутствовать.

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

Учимся считать деньги

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

Но финансовая эффективность схожих по «продукту на выходе» данных может заметно отличаться.

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

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

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

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

К счастью, сегодня появились способы запустить информационную структуру в облака, используя технологии типа Amazon EC2, Rightscale, – в этом случае можно построить действительно масштабируемую систему и платить только за ту инфраструктуру, которая в настоящее время используется. Решение такой проблемы называется Digg Effec.

Допустим, молодая компания раскручивает продукт, который использует только 10 серверов для обслуживания веб-трафика. Внезапно фирма получает хвалебные отзывы, про нее узнают на массовых новостных порталах – Google news, Digg, Reddit , Slashdot т.п., – и образуется лавинообразный наплыв пользователей, которым интересно попробовать новый продукт. Чтобы не возникло «отказа в обслуживании», которое неизменно появится при внезапно возникших запросах, требуется срочно и правильно увеличить инфраструктуру, а потом также ее «уменьшить» до нормы.

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

Держим руку на пульсе новых технологических решений

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

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

Например, если в начале 90-х годов достаточно много компаний еще использовало продукцию фирмы Netware, то к их середине гораздо эффективнее стало решать те же задачи средствами Microsoft Windows NT (плавно замененным Microsoft Active Directory в 2000-х годах) и Sun Microsystems. А крах «дот-комов» в начале 2000-х, как и развитие GNU Linux, дал огромный скачок использованию этой открытой операционной системы (Open Source) в масштабах предприятия, в высоконагруженных системах [4].

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

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

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

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

***

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

1. Adam Lashinsky. Inside Apple. How America’s Most Admired – and Secretive – Company REALLY works.
2. Jack Welch. Winning – Harper Business, 2005.
3. Кондаков К. Бизнес-составляющая ИТ. //«Системный администратор», №9, 2010 г. – http://samag.ru/archive/article/1011.
4. Кондаков К. Поддержка системы 24x7. //«Системный администратор», №9, 2011 г.
5. Кондаков К. Информационные тромбы. Десять правил для решения проблемы. // «Системный администратор», №3, 2012 г.
6. Кондаков К. Нейт Кемпи; Запуск нового продукта важнее умершего сервера. //«Системный администратор», №3, 2011 г.