 |
|
|
|
Кошмар, который закончится. Как выбраться из лабиринтов проблем
Кошмар, который закончится Данная статья посвящена некоторым нюансам ИТ-менеджмента, знание которых позволяет заметно облегчить жизнь ИТ-подразделений ...Еще один день сплошного аврала. Кажется, что телефон техподдержки раскален добела. Осатаневшие от усталости саппорт-инженеры уже не знают, за что хвататься, а пользователи не в состоянии ждать, когда подойдет очередь решения их проблем. И не верится, что хоть когда-нибудь придет конец этому техногенному аду. И возникает вопрос: а почему так? Вы думаете, что такое возможно только в мелких компаниях, где жадное руководство привыкло экономить на спичках? Вовсе нет. Это довольно распространенный сценарий для многих организаций вне зависимости от размера или финансового состояния. Мало того, подобные ситуации часто возникают в системных интеграторах и аутсорсинговых компаниях, особенно находящихся на начальном уровне. Но есть ли способ избежать подобных проблем? Решение есть. Для начала нужно остановить свой бег по кругу. Осмотреться. Провести аудит. Проанализировать временные и финансовые затраты. Обсудить ситуацию с коллегами по ИТ. И выработать совместное решение. (Для единственного ИТ-специалиста в компании ситуация выглядит немного проще и сложнее: вроде и советоваться ни с кем не нужно, а с другой стороны, независимое мнение коллег по отделу и справедливая критика бывают очень кстати). В этой статье вы встретите нужные рекомендации, но окончательное решение так или иначе останется за вами. «Архитекторы» и «шаманы» Есть два различных подхода к обеспечению работы ИТ-инфраструктуры. Несмотря на противоречия, они часто сосуществуют вместе и успешно дополняют друг друга. Мало того, само деление очень условное. В разные моменты жизни в различных ситуациях человек может выступать поочередно в той или иной роли. «Архитекторы» В этом случае главенствует принцип некой основательности. Когда система с самого начала проектируется с учетом надежности, отказоустойчивости, высокой степени безопасности. Например:
Само обозначение «архитекторы» появилось по аналогии со строительством зданий. Нужно, чтобы здание было не просто построено, а служило долгие годы и было надежным и безопасным. «Архитекторов» вне зависимости от типов темперамента и других психологических качеств объединяет одна важная черта: основательность и некая неторопливость. И очень стойкое отвращение к работе «быстрей-быстрей». Еще одна забавная черта, которую иногда встречал, – их раздражает избыточный контроль. Характер у людей такой – думать о вечном. Даже если строится тестовая система сроком жизни в полчаса. «Шаманы» Если смысл подхода «архитекторов» заключается в том, чтобы не допустить сбои, заранее убрав причины возникновения, то подход «шаманов» – в быстром их устранении. «Неважно, сколько проблем возникло за данный период, важно, что все они были устранены». Данный подход весьма популярен у определенного круга ИТ-специалистов. Обозначение «шаманы» произошло именно благодаря умению чудесным образом решать всевозможные проблемы, подчас прибегая к нетрадиционным средствам. Например, в случае проблем с доступом к определенному ресурсу в Интернете можно проанализировать список правил на файерволе, а можно посоветовать пользователю внешний прокси-сервер. Широкий кругозор вместе с неплохими практическими навыками позволяет специалистам этой категории поддерживать на плаву ИТ-инфраструктуру даже во время таких жестоких потрясений, как массовое заражение компьютерным вирусом или сбой основных систем и сервисов при неправильно установленном обновлении. Только он один знает, как подправить ключик в реестре, чтобы самодельная программа документооборота перестала забирать непомерное количество ресурсов, или что при подключении МФУ к принтсерверу нужно использовать не штатные драйверы, а более поздние модели. Шаман, да и только! Несмотря на большую загруженность из-за такой специфичной организации работы, «шаманы» часто довольны своим положением. Благодаря уникальным знаниям они превращаются в некий дефицитный ресурс. Такой вот «человек-оркестр», который всегда нарасхват и всем нужен. И на самом деле каждый «шаман» поистине уникален. Если «архитектор» в своей работе может опереться на типовые решения и предыдущий опыт коллег и построить свою «непотопляемую систему», то «шаман» должен уметь решать проблемы «по ходу пьесы». Помимо навыков владения поисковыми системами, он должен обладать широким кругозором и профессиональной интуицией. Ни в коем случае нельзя путать «шамана» с простым низкоквалифицированным бездельником. В отличие от лентяев, просто не желающих учиться и профессионально развиваться, «шаман» очень трепетно относится к процессу чтения технической литературы и изучению своей предметной области. Мало того, многие из них держат целые библиотеки печатных и электронных книг, а также имеют сайты и блоги в Интернете, где они обмениваются информацией и обучают новичков на добровольной основе. Еще одна интересная деталь – многие специалисты данной группы не любят подробно документировать систему, которую обслуживают. Обвинять их в лени или недальновидности бессмысленно. Дело в том, что человек ориентируется на свои подчас действительно уникальные навыки и способности и не представляет, как что-то с его точки зрения совсем очевидное может быть кому-то непонятно. Нет сомнения, «шаман» – очень полезный человек. Это своего рода «спецназ», умеющий решать максимум задач в кратчайшие сроки. Получить в команду такого человека – значит, надежно прикрыть свой тыл и получить дополнительный резерв для решения многих задач. Но есть один нюанс. Казалось бы, все здорово, и ИТ-инфраструктура в надежных руках. Пока наш кудесник быстро все устраняет, особых проблем нет. Беда начинается, когда он что-то внедряет или тем более проектирует. Одно из кажущихся преимуществ такого подхода – некоторая экономия средств на начальном этапе. Например, вместо внедрения антивирусной системы корпоративного уровня можно подобрать антивирус, бесплатный даже для коммерческого применения. Потери наступят позже, когда число объектов в сети возрастет и управлять ими станет все труднее и труднее. Придется в спешном порядке переходить на защиту от вирусов уровня предприятия, не прерывая бизнес-процессов. А это гораздо сложнее, чем внедрять сразу подходящую систему с учетом роста. К сожалению, малый и даже средний бизнес, до того как вырасти в крупную компанию, на этапе своего становления нуждается в первую очередь именно в «шаманах», способных экономить средства компании. Получается, что именно они закладывают фундамент для дальнейшего развития бизнес-процессов в ИТ. Таким образом, работа ИТ может быть ориентирована не на повышение устойчивости путем введения избыточности, а на сиюминутную экономию средств и быстрое устранение возможных сбоев. Рекомендации Это было бы бесполезной тратой времени – диагностировать проблему и ни дать ни одного метода ее устранения. Самое важное и наипервейшее – умейте поставить себя на место другого человека. «Шаману» нужно отрешиться от своих супервозможностей и представить, что будет чувствовать человек, который вольно или невольно окажется на его месте. Как станут решаться вопросы при его отсутствии на рабочем месте, например, во время отпуска или больничного? Есть ли шанс у всей остальной команды разобраться с проблемой? Что можно посоветовать, если вы столкнулись с «шаманским наследием»? Самое главное – провести аудит и составить документацию. Бессмысленно конфликтовать с ее невольным разработчиком. Лучше войти с ним в контакт и постараться получить максимум информации, которая позволит в дальнейшем залатать все найденные прорехи. У «архитекторов» при работе таких проблем, как правило, не возникает. Но и у них есть свое слабое место. Дело в том, что построение системы «на века» требует времени, а его, как правило, не хватает. В итоге, когда прижмет начальство или заказчик, приходится завершать проект, как говорится, в «темпе вальса». Как следствие, у надежной и хорошо спроектированной системы возникает некая ахиллесова пята, на полное устранение которой как раз и не хватило времени в конце срока. Помочь в недопущении таких ошибок поможет тщательное планирование, а также своевременная заявка на перенос сроков окончания проектов (если такое возможно). Поэтому и здесь срабатывает принцип «поставь себя на место другого», в данном случае на место своего руководства или заказчика. Остановка роста Это интересная проблема, с которой так или иначе сталкиваются все ИТ-специалисты вне зависимости от их специализации и уровня иерархии. Представьте себе такую ситуацию: вы работаете в компании продолжительное время, в развитие ИТ-структуры, что называется, вложили всю душу. Вам знаком и лично симпатичен каждый винтик в серверной стойке. Вы знаете все нюансы, с которыми пришлось столкнуться во время построения данной структуры. Вроде все прекрасно, и будущее выглядит вполне безоблачным. Но время не стоит на месте, и от вас как от ИТ-специалиста требуется решение других задач, да и технологии развиваются, и модернизация уже не за горами. И тут вы понимаете, что уже не в состоянии изучать что-то новое или переделывать старое. Все ваши усилия уходят на поддержание этой стабильной и стремительно устаревающей системы. Что произошло? Дело в том, что, когда вы породили и растили свое техногенное детище, вы развивались вместе с ним. Но ваше творение выросло и на данном этапе достигло своего потолка. Появились новые технологии, новые направления в ИТ. А вы не можете снова начать развиваться, поскольку обязаны заботиться о своем «питомце». И что делать в такой ситуации? Ответ прост: учить других. Необходимо подготовить себе достойного преемника, а лучше целый коллектив. Только в этом случае вы сможете снять с себя груз ответственности и обязанности по эксплуатации и со спокойной душой заняться вопросами развития и модернизации. В том числе и вопросами самообразования. К сожалению, идеологические установки, царящие в обществе последнее время, и череда экономических кризисов подталкивает людей, в том числе ИТ-cпециалистов, к некоему «социал-дарвинизму», который отрицает взаимопомощь и подготовку младших кадров. А жаль. Потому что это сдерживает развитие и просто мешает плодотворно работать. В итоге в силу смены обстоятельств рано или поздно даже суперспециалист может оказаться один на один с целым рядом проблем, которые невозможно решить в одиночку. И тогда вполне может явиться тот самый техногенный ад, о котором упоминалось в начале статьи. Учите других. Вовремя готовьте смену. Составляйте подробную документацию, и тогда непредвиденных случаев в работе станет меньше. Это даст шанс на дальнейшее развитие. «Надкусывание» Интересное явление, имеющее место в ситуациях, когда не хватает времени. Допустим, необходимо решить четыре задачи примерно одной степени важности, и на каждую требуется один час. Но «на всё про всё» отведено примерно два часа. Что пытается сделать обычный айтишник, неискушенный в ИТ-менеджменте? Во всех ситуациях, которые мне приходилось наблюдать, человек брался выполнять все четыре задачи одновременно, периодически по очереди переключаясь с одной на другую (см. рис. 1).
Рисунок 1. Стандартный вариант «надкусывания» Результат такого подхода вполне предсказуем. К концу срока все четыре задачи будут выполнены в лучшем случае наполовину. Следует также учесть, что на переключение между выполнением задач уходит время. Таким образом, даже 50% выполнения каждой задачи – это практически недостижимый результат. Придется отчитываться за четыре невыполненные задачи. Этот ошибочный путь и получил название «надкусывание», когда исполнитель пытается решить ряд задач одновременно, в итоге проваливает для всех них все сроки исполнения. Гораздо лучше сразу взяться за исполнение одной задачи, довести ее решение до конца и перейти к другой. В этом случае есть большой шанс довести до конца решение двух задач из четырех (см. рис. 2). Тогда придется отчитываться только за две невыполненные задачи из четырех.
Рисунок 2. Две законченные задачи лучше, чем «надкусанные» четыре Разумеется, речь не идет о классических «окнах», когда, например, в одном случае необходимо запустить резервное в автоматическом режиме на длительный срок, а пока оно выполняется, заняться другими проблемами. Такой ситуации не возникает, когда четко удается определить разные приоритеты для каждой из задач и то, чем можно пожертвовать. «Дожигание» Это явление также возникает в условиях сжатых сроков. Допустим, на нормальное завершение некоторого проекта требуется 10 рабочих дней. Но работу требуется выполнить за восемь дней и к концу восьмого представить готовый результат. Перенос сроков не предусмотрен. Что происходит в этом случае? Чаще всего исполнитель попытается судорожно выполнить задачу в установленный сжатый срок без каких-либо ограничений. В итоге часть проекта все равно останется невыполненной, причем какой частью данного проекта придется пожертвовать, решается на самом последнем «скоростном» этапе. К сожалению, чаще всего жертвуют такими вещами, как отказоустойчивость, безопасность и экономия ресурсов. И что в итоге? Порожденный таким образом монстр начинает время от времени подбрасывать «сюрпризы» в виде отказов системы, утечек информации, а и то и просто полного выхода из строя. В итоге время, потраченное на ликвидацию последствий, не перекрывает «экономию» на этапе проектирования (см. рис. 3).
Рисунок 3. Нормальный вариант и вариант с «дожиганием» Что делать, чтобы избежать подобных ситуаций? Разумеется, необходимо сосредоточить максимум усилий для получения реальных сроков исполнения задачи. Все остальные рекомендации, которые будут приведены ниже, не являются решением проблемы, а только средством для ее минимизации. Очень важное место занимает честный и правдивый подход. Руководитель, отвечающий за проект, обязательно должен быть проинформирован в устной и письменной форме о возможных последствиях такого подхода и в свою очередь сам должен донести эти сведения до руководства. Да, при таком подходе велик шанс вызвать недовольство, но когда в процессе эксплуатации всплывут недоделки или выстроенная система начнет рушиться от случайных факторов, будет гораздо хуже. Но если не удалось отодвинуть сроки исполнения проекта? Можно попробовать реализовать следующий подход. Очень часто работает правило 80/20. 80% – это необходимый функционал, а также первичные меры по безопасности и отказоустойчивости – без них не обойтись. Этот объем работы, как правило, составляет не самую большую часть проекта. А 20% – это дополнительные функции, так сказать, желательные, но не обязательные вещи. Скептики приводят формулу 80/20 – 20/80, то есть 80% необходимых работ занимают 20% времени, а на 20% дополнительных работ уходят оставшиеся 80%. В реальности дела обстоят не так жестоко, но смысл такого подхода вполне очевиден. Этот принцип позволяет еще на начальном этапе выбрать, чем можно пожертвовать. Если какие-то функции не особенно важны и роль их не так очевидна, имеет смысл отложить их реализацию на более поздний срок, а может, и вовсе отказаться от них. Это позволит выиграть время для построения надежной отказоустойчивой системы, которую в дальнейшем можно будет развивать и модернизировать. Приведу пример. При подготовке фермы терминальных серверов на «строительство» самой фермы, включая монтаж оборудования, настройку дисковой подсистемы, установку программного обеспечения системным администратором было затрачено около двух недель. И столько же времени было потрачено на создание возможности тонкой настройки совсем необязательных программ в автоматическом режиме. В результате сроки исполнения проекта были сорваны. Понятно, что в данном случае человек хотел сделать как лучше и оградить себя от дополнительной работы в дальнейшем. Но необходимость использования подобного программного обеспечения не очевидна, тем более не очевидна необходимость изменять настройки по умолчанию. Еще один хороший способ снизить сроки исполнения проекта – распараллеливание процессов путем отработки решений сложных и необычных задач в тестовой среде. Возвращаясь к нашему примеру, вполне можно было завершить работу с основным функционалом, впоследствии подготовить отдельное решение по тонкой настройке. Даже если потребуется кратковременная остановка системы при внедрении на рабочей ферме, это может быть куда меньшее зло, чем срыв сроков исполнения. Тестовая система – очень хорошее подспорье при реализации проектов в сжатые сроки. Можно неделями искать в Интернете подтверждение или опровержение имеющейся информации, а можно проверить в экспериментальной среде в течение нескольких минут. Можно отработать все действия, заранее проанализировать все варианты и после просто автоматически перенести полученные наработки на «боевую» систему. Все рассуждения на тему «Времени мало, нам некогда этим заниматься» – чаще всего не более чем ленивые отговорки. Но опять же стоит напомнить: «Самый надежный способ избежать «дожигания» – установить реальные сроки». В противном случае все равно придется чем-то жертвовать. А что делать, если такая система досталась в наследство? Вначале необходимо тщательно изучить всю имеющуюся документацию по проекту. Хотя если создателем данного «чуда инженерной мысли» был «шаман», документации в необходимом объеме скорее всего не существует. Далее в любом случае необходимо провести тщательный аудит как в целях устранения пробелов в документации, так и выявления узких и слабых мест системы. Дальше идет выработка решений тестирования в экспериментальной среде. При положительных результатах тестов можно начинать вносить коррективы. Главное в реализации работ по устранению подобных недочетов – не скатиться к новой схеме «дожигания». В противном случае получится невообразимый бардак, для устранения которого потребуется полная переделка с нуля существующей инфраструктуры. *** В своей статье я не ставил основной задачей дать набор универсальных советов на все случаи жизни. Наоборот, будет просто чудесно, если у моих читателей найдется собственный выход из подобного лабиринта. Жизнь настолько многообразна и удивительна, что вряд ли получится вот так взять и решить все проблемы скопом. Но все же я надеюсь, что материал, изложенный в статье, кому-то поможет преодолеть некоторые затруднения. В заключение мне бы хотелось поблагодарить Евгения Калинина за замечательную лекцию [1], которую он прочел в 2009 году на конференции Rootconf. Термин «надкусывание» я впервые услышал из его уст.
|
АЛЕКСЕЙ БЕРЕЖНОЙ, системный архитектор. Главные направления деятельности: виртуализация и гетерогенные сети. Еще одно увлечение, помимо написания статей, – популяризация бесплатного ПО
Комментарии отсутствуют
| Добавить комментарий |
|
Комментарии могут оставлять только зарегистрированные пользователи |
|
