Как я сеял ITIL и выращивал ITSM, или Театр абсурда
Автор
Вадим Коноваленко
Заявок нет, но системные администраторы в мыле и в бегах с отвертками и проводами — классика хаоса.
Хаос (греч. Cháos), в греческой мифологии беспредельная
первобытная масса, из которой образовалось впоследствии
все существующее. Переносн. — беспорядок, неразбериха.
Советский энциклопедический словарь, М., 1981
Абсурд (лат. Absurdus — нелепый) — бессмыслица, глупость.
Советский энциклопедический словарь, М., 1981
Преамбула
Весна, как известно, время перемен, поэтому я не очень удивился, когда меня пригласили поработать в одну частную компанию, занимающуюся игровым бизнесом.
Причем пригласили со словами: «У нас тут проблемы с ИТ, вроде бы все работает, но как-то не так, ИТ вечно не успевает. А тут конкуренты, нам развиваться надо, расти... надо как-то все наладить, поменять что-то».
Наводим справки: компания немаленькая, на рынке не первый и не третий год, действительно растет и очень быстро, не менее 30–40% в год; несколько сотен точек присутствия по всей России.
Хорошо. Наладить так наладить, поменять так поменять — будем работать.
Для тех, кто, может быть, не в курсе, — игровой бизнес на 100% зависит от ИТ, здесь все on-line, а в масштабах нашей страны еще и круглосуточно, поэтому простоев серверов, зависания ПО, отказов в обслуживании на сайте просто не должно быть. В таком бизнесе, по крайней мере в теории, все должно быть дублировано, резервировано и отказоустойчиво.
Действие первое
Первичный осмотр показал, что это не просто компания, а нечто вроде холдинга, объединяющего различные ОАО, причем ИТ вынесено на уровень холдинга — уже неплохо. Есть отдел разработки ПО, есть горячая линия поддержки внешних клиентов, есть круглосуточные дежурные на первой линии поддержки, есть отдел системных администраторов. Есть серверы, за которыми следят администраторы, есть прикладное ПО, написанное внутри компании отделом разработки. Есть резервные серверы на географически удаленной площадке. Как будто бы все хорошо...
Правда, никто точно не знает, что произойдет, если откажет основная площадка, и есть довольно обоснованные предположения, что на удаленном резерве развернуть все сервисы не удастся — учений-то никто не проводил...
Но уже на третий день «верхние люди» вдруг спрашивают:
«Ну как? Разобрались? Через две недели расскажете, что у нас не в порядке и как с этим бороться?»
«Нет, через две недели не расскажу, в лучшем случае через месяц...»
«Месяц... месяц это долго, это много...»
«Ну, быстрее никак, чудес на свете не бывает».
«Да? Ну ладно, месяц...»
Продолжаем наблюдение. С каждым днем все интереснее и интереснее... Довольно много директоров: есть генеральный и его первый заместитель (второго при этом нет), есть исполнительный (точнее, даже два), есть и технический, и ИТ-директор, есть и по развитию и так далее, потому что это не весь список. И все эти директора и другие начальники (всего человек 20) каждое (!) утро собираются на совещание — слушают доклады, решают вопросы. Но как-то странно решают: серьезные вопросы с совещания переносятся в кабинеты, мол, здесь не место «при всех», а вот порассуждать об установке железной двери или переезде столовой — это пожалуйста! Уходит на это примерно час. И вот так по утрам день за днем два десятка человек занимаются по большей части рутиной, которую можно решить в рабочем порядке — называется это «ручное управление да еще с педальным приводом».
А при чем здесь ИТ? А при том, что на этих «утренниках» ИТ может получить задачу, про которую ИТ-директор знать не знал и слышать не слышал и которую надо сделать срочно, а лучше вообще вчера! Например, срочно, к понедельнику, собрать за выходные из россыпи комплектующих (все отдельно, процессор, кулер, видео, винчестеры...) несколько десятков машин. Неважно, что они потом будут недельку-другую лежать на складе — надо, и срочно!
В общем, если у бизнеса и есть какие-то планы, то он, бизнес, категорически с ИТ делиться ими не желает. Теперь понятно, почему ИТ, как было сказано в начале, «вечно не успевает»...
Дальше — больше: на «утренниках» раз или два в неделю звучит: «Ночью выполнено обновление программы».
Обновление? Это уже серьезно, наверное, есть Регламент обновлений, внесения изменений в код, контроль версий и другие полезные вещи...
Да, Регламент обновлений есть, на одну страничку, полгода как утвердили — это все, что удалось ИТ-директору добиться от разработчиков и руководства компании.
Пишем новый? Пишем. Лучшие практики знаем? Знаем. Вот и пишем.
И продолжаем разбираться с процессами в ИТ в целом — как ИТ взаимодействует с бизнесом, чем недовольны пользователи и внутренние заказчики.
Оказывается, есть система регистрации заявок пользователей, она установлена, развернута, всем доступна. Можно по электронной почте послать заявку, а можно через «личный кабинет», все регистрируется, присваиваются номера, заявки попадают системным администраторам и ими исполняются. Все как положено. Вот только заявок в системе нет, ну почти нет — десяток в неделю на такую компанию все равно, что ноль.
Заявок нет, но системные администраторы в мыле и в бегах с отвертками и проводами — классика хаоса. Кто первый поймал (или у кого голос громче) сисадмина в коридоре, та заявка и выполняется. И сисадмины классические — говорим быстро, неразборчиво, себе под нос, все знаю, но никому не скажу; пользователь — он же «юзверь», вечно все портит и мешает работать; дружественный интерфейс — ничуть не бывало, это не здесь, это в другом месте. До сих пор подозреваю, что где-то в шкафу стоит знаменитый «свитер с оленями». Мысленно попытался оценить ситуации по Cobit — до ноля даже не дотянул, застрял где-то глубоко в минусе. Вот такой вот ITSM местного разлива в 100% ИТ-зависимой компании.
Тем временем месяц прошел — документ о текущем состоянии дел и о планах реорганизации написан и разослан заинтересованным лицам.
Первый звонок.
Действие второе
Докладываем, рисуем на доске, говорим правильные слова: «Единая точка входа, приоритеты выполнения, сервисный подход, регистрация изменений, согласование, регламенты, проектный подход»... НО быстрый шорох страниц за спиной, вопросы, на которые есть ответы в тексте... то есть документ никто не читал, в лучшем случае кто-нибудь пролистал...
Что-то обсуждаем, замечания, предложения — что-то есть дельное, попутно узнаем, что технический директор будет создавать проектный офис, который, видимо, и будет формировать ТЗ, ну или хотя бы приоритетные задачи для ИТ. До среднесрочных перспектив дело так и не дошло, что уж там говорить про долгосрочные планы развития... Хотя ИТ-директор и пытался привлечь внимание к этим вопросам, но...
Ну хотя бы так... Делаем план работ до конца года. План никто не то что не утверждает, его особо и не читают. Ну ладно, есть план — работаем по плану. Пишем регламенты взаимодействия, ищем людей...
Вот, кстати, и Регламент обновлений ПО готов для обсуждения.
Надо сказать, что прикладное ПО в данном случае определяет само существование компании, так как весь игровой бизнес завязан на эту программу. Даже не так: не на программу, а на Программу или еще точнее — ПРОГРАММУ, ибо это, как говорится, «наше все». Здесь и игровые коэффициенты, и ставки, и выплаты, но здесь же и договоры с провайдерами услуг, здесь и спорт-бары (кажется, даже меню столовой и спорт-баров запихнуто сюда же) — и все это крутится в памяти сервера, да еще в однопотоковом режиме... Как будто на дворе конец 80-х...
Переходим все-таки к Регламенту обновлений.
Отдел разработки категорически против: «Зачем уведомлять пользователей, что у них что-то изменится — придут и утром все увидят», — «А если не заработает», — «Ну, подумаешь — исправим или права переназначим, дадим 215 право кому надо и, вообще, не нужен этот Регламент и так все у нас отлично работает!»
«Неужели так трудно из текста программы просто собрать комментарии и выкатить как уведомление или взять последнюю часть из документации и разослать ее пользователям, так можно?»
«Нет».
«Почему?»
«Нет документации и комментариев в тексте программы тоже нет».
«Ну а все-таки, если обновления не встанут как надо, можно сделать откат на предыдущую версию? Восстановить, так сказать, вчерашнее состояние?»
«Нет».
Попутно выясняется, что задачи для отдела разработки возникают как бы ниоткуда и отовсюду одновременно. Часть ставит ИТ-директор в соответствии с уловленными им требованиями бизнеса, часть придумывают себе программист, еще часть — это «хотелки» пользователей, которые просто приходят и говорят: «А нам надо...»
А что проектный офис? Может быть, он будет фильтровать задачи, формировать проекты, ставить некие, хотя бы предварительные, приоритеты, изыскивать ресурсы...
Нет, не будет проектный офис этим заниматься просто потому, что нет такого офиса, он так и не появился...
То есть отдел разработки сам себе ставит задачу (по совместительству они же и архитекторы), сам ее решает, сам тестирует, сам себе сдает, а потом изумленная публика утром узнает об очередных изменениях в ПРОГРАММЕ.
Второй звонок.
Действие третье
Подбираем персонал для усиления первой линии технической поддержки, подыскиваем приличных системных администраторов, пытаемся изменить отношения и характер взаимодействия пользователей и ИТ.
Надо сказать, что на петербургском рынке труда все очень непросто: если на позицию системного администратора есть хотя бы отклики, из которых хотя бы кого-то можно пригласить на собеседование, то «барышню» на первую линию поддержки найти просто невозможно.
Приходят системные администраторы на собеседование: квалификация низкая, но требования на зарплату завышены раза в два. После долгих поисков нашли одного; и нас его квалификация и требования устраивают, и мы ему тоже подходим. Но исполнительный директор, оказывается, имеет совершенно противоположное мнение. Ведь нельзя допустить постороннего нового человека с правами системного администратора к базе данных и ПРОГРАММЕ, он ведь может увидеть, что там внутри... То есть вот те, которые работают, — они проверенные, а те, кто новые, — нет. Приехали, как говорится.
Планы по реорганизации уходят в песок — вроде бы никто не против, но, как дело доходит до конкретных действий и лиц, все куда-то испаряются, тут же находятся более важные дела.
Проектный офис так и не появился, заявки по-прежнему не регистрируются и, как следствие, теряются, все запросы срочные, зоны ответственности размыты, задачи валятся со всех сторон, расплывчаты и сиюминутны — планов развития нет.
Многочисленные директора не считают возможным согласовывать свои планы с ИТ — постоянный аврал, ИТ-отдел по-прежнему крайний и виноват во всем (даже в том, что до сих пор не на всех дверях установлены доводчики). Обращения к руководству компании уходят в никуда, владелец, судя по всему, спасает деньги на Кипре. При этом не стоит думать, что сам бизнес имеет четкие, проработанные планы или модели развития, в которых просчитаны прибыль, сроки окупаемости, издержки и тому подобное. Попытка выхода в ближнее зарубежье показала, что это отнюдь не так. Потенциальный рынок не изучается, его ёмкость и потребности никому неизвестны, просто принимается волевое решение – идём туда и все пошли.
Два месяца работы впустую просто потому, что у руководства компании так и не хватило духа провести изменения, которые были задекларированы в начале пути, хотя все было написано в соответствии с лучшими практиками и опытом применительно к конкретным условиям и особенностям.
Наличие согласованной политической воли руководства компании к преобразованиям — главный элемент в технологии проведения посевной ITIL и выращивания ITSM на каменистой почве и в кислотной среде. А если этой политической воли нет, то:
Третий звонок и занавес.
Эпилог
Когда статья готовилась к печати, мне позвонил ИТ-директор этой компании, теперь уже бывший, и сказал, что он тоже там больше не работает. Он с облегчением и довольно громко хлопнул дверью после очередного и, как там принято, внезапного изменения правил игры.
Таким образом, можно сделать вполне вероятное допущение, что «верхних людей» компании устраивает ситуация хаоса и «мутной воды» и более того, они в ней заинтересованы.
Опубликовано 28.06.2013