 |
|
|
|
От админа до архитектора. План «кампании»
От админа до архитектора В статье предлагается практический поход к развитию карьеры системного администратора. Что можно сделать, с учетом ограничений, с которыми приходится сталкиваться? Цели и ограничения В предыдущей моей статье «Семь принципов Наполеона для системных администраторов» (см. №10 за 2010 год)шла речь о том, что позиция системного администратора не должна быть завершающим этапом в карьере ИТ-специалиста. Полагаю, что направления возможного движения роста относительно понятны. Тем не менее у действующего системного администратора может возникнуть ряд ограничений. Что делать, если:
Думаю, что упомянутые особенности наиболее характерны для регионов. И что, опять тупик, и ничего нельзя сделать? Придется заниматься техподдержкой и повседневными задачами администрирования, не имея возможности развития? Перспектива так себе, не правда ли? Напомню, что Наполеон говорил: «У каждого солдата в ранце лежит жезл маршала». Я попробую предложить свой план для того, чтобы выиграть «кампанию» в таких условиях… Необходимо сделать следующий шаг в карьере, однако есть ряд ограничений, препятствующих этому. Можно ли найти решение? Имеет смысл применить системный подход к своей каждодневной работе и добиться не только повышения собственного уровня знаний, но и сделать рутинную работу более интересной, продемонстрировать руководству компании, что системный администратор – не просто обслуживающий персонал. Наконец, расширить собственный кругозор, что в дальнейшем может помочь не только при работе в качестве нанятого сотрудника, но также и при построении собственного бизнеса в привычной вам сфере информационных технологий. Цели:
Ограничения:
Следует отметить, что предлагаемый в статье подход не претендует на универсальность, тем не менее мне представляется, что в ряде случаев он может быть весьма эффективным. Строим план «кампании» Итак, наша исходная диспозиция выглядит удручающе, но попробуем найти выход… Хотелось упомянуть, что работа архитектора информационных систем не сводится к настройке программно-аппаратного комплекса заказчика – напротив. Задача – построение решения для бизнеса. Следовательно, целесообразно не сводить свою работу к некоему набору стандартных действий по настройке оборудования и программного обеспечения – решается более сложный комплекс проблем. Здесь речь не идет о повышении самооценки администраторов, необходимо сформировать разумный, на мой взгляд, подход к ежедневной работе. Разумеется, не предполагается внедрение моделей ITIL, ITSM силами системного администратора. Это вряд ли стоит рассматривать серьезно. Несмотря на то что системный администратор является «внутренним» сотрудником компании, давайте представим себя на месте компании-интегратора, которую пригласили для решения какой-то важной задачи, разберемся во всем по порядку и попробуем изменить подход к работе… Как это ни странно может показаться на первый взгляд, однако работа за консолью не так важна, как думают многие. К этому виду деятельности мы перейдем позже, а пока наш главный инструмент – карандаш. Определяем цели Мы несколько забежали вперед в предыдущем разделе, упомянув, что речь идет о миграции системы, на самом деле цели проекта необходимо четко определить. Как правило, они становятся более или менее понятны при объявлении тендера, но ведь мы сейчас находимся «внутри» компании, и потребность в том или ином проекте определяется бизнес-требованиями к инфраструктуре ИТ, так что цели нам примерно понятны. Они либо поставлены CIO компании, либо, если организация небольшая, самим системным администратором. В первом варианте, как правило, речь не идет о доказательстве целесообразности того или иного проекта, поскольку решение уже принято на более высоком уровне, остается только добиться его реализации. Впрочем, на стадии выбора решения администратор также может принять участие, которое определяется политикой компании. Второй вариант представляется более интересным, т.к. здесь появляется необходимость доказательства целесообразности проекта для руководства компании. По сути, у каждого проекта есть BDM (Business Development Manager) и спонсор. Для небольшой компании часто эти роли совмещены. Определяя цели для проекта, следует четко понимать, что для бизнеса и для ИТ-подразделения они различаются. Например, для руководства компании не может являться целью миграция с Windows 2003 на Windows 2008. BDM и спонсор проекта никогда не рассуждают в таких категориях.
Это лишь несколько вопросов, которые будут заданы, если придти с предложением, приведенным выше. Таким образом, мы уже получаем негативное отношение и выглядим как источник непонятных для компании затрат. Стоит ли начинать с этого? Разумеется, нет. Основная цель проекта должна быть понятна BDM, и крайне желательно, чтобы четко формулировались критерии ее достижения. Кроме этого, если в качестве основной цели приводилось, например, сокращение расходов компании, то очевидно, что необходимо проиллюстрировать текущие расходы, затраты на проект и предполагаемую экономию при успешном завершении проекта. Подготавливается технико-экономическое обоснование проекта (ТЭО) или технико-коммерческое предложение (ТКП). Точную стоимость и сроки выполнения работ на этом этапе определить сложно, однако предварительные оценки сделать вполне возможно. Тем самым системный администратор начинает говорить на понятном бизнесу языке. Это существенный плюс. С одной стороны, руководству компании становится понятно, что сотрудник является не просто техническим персоналом, с другой стороны, системный администратор получает опыт подготовки экономических документов и оценки эффективности ИТ-проектов. Рекомендуется построить дерево целей, которое демонстрирует не только серьезность подхода к проектированию, но и позволяет не упустить важные этапы проекта. На дереве целей дополнительно можно показать и требуемые ресурсы. Следует понимать, что уровень подробностей для BDM и для ИТ различается – не стоит перегружать документ избыточными техническими деталями. На данном этапе дается предварительная оценка потребности в проекте и его экономической эффективности. Здесь вполне можно подготовить и провести презентацию проекта, что позволит упрочить собственные позиции. Следующий этап наступает, когда потребность в проекте обоснована и принято решение о реализации. Формирование проектной команды Формируется команда участников. Определяются роли, обязанности сотрудников. Формируется методика взаимодействия, строится план коммуникаций. Для небольшой компании этот этап не столь сложен, поскольку значительная часть функций сосредоточена у системного администратора, тем не менее важность этого этапа недооценивать не следует. По сути, определяются права и обязанности участников проектной группы, ее структура и механизмы взаимодействия. Члены проектной команды должны иметь представление о внедряемой технологии. В идеале проектной группой должен управлять опытный консультант. Неплохо иметь толкового генерала во главе армии. Все решения, принимаемые на совещаниях, должны фиксироваться, следует вести протокол встреч. При эффективном управлении потребность в совещаниях для принятия решений по проекту можно свести к минимуму. Как правило, к серьезным изменениям существующего положения вещей люди изначально негативно относятся, однако при личном вкладе в проектирование и изучении внедряемых технологий, осознании своей роли в этом процессе негативное отношение может измениться. В результате такого взаимодействия детали конечного состояния системы становятся понятны всем членам команды. Получаем навыки в организации работы людей, умении распределять роли, повышаем коммуникативные способности. Ну, что же, цели ясны, решение принято, команда сформирована. Переходим к следующему этапу. Аудит информационной системы Нередко мне доводилось наблюдать, как пренебрегают этой частью проекта, полагая, что о собственной системе и так все известно. Это опасный подход. Далеко не всегда системный администратор представляет, какие прикладные системы работают в его сети у пользователей, а это, несомненно, важный аспект, ведь в результате миграции серверов приложений они могут перестать работать, чего мы допустить не можем. Другой пример – наличие в сети предприятия устройств, принципиально не пропускающих определенный тип трафика, об этом администратор также может не знать. Например, департамент безопасности внедрил аппаратные средства защиты информации, передаваемой по сети. Список ограничений, накладываемых существующей инфраструктурой, требованиями компании, может быть весьма значительным. И если не учесть все особенности, то проект может окончиться неудачей. Именно потому стоит быть особенно внимательным на этом этапе. Обследование организации осуществляется как с помощью интервью и заполнения стандартных форм опросников/анкет, так и с помощью специальных программных средств. Например, для изучения структуры службы каталога и организации Exchange у Microsoft есть хорошее средство Active Directory Topology Diagrammer. С его помощью мы получим информацию о логической структуре Active Directory, распределении ролей контроллеров, структуре сайтов и много других важных данных. Формы анкет можно использовать как готовые от компании Microsoft, так и разработать собственные с учетом специфики компании. Крайне желательно использовать оба варианта сбора информации, поскольку один проверяет другой. Дополнительно имеет смысл провести ряд интервью с сотрудниками компании. В результате становится ясно, как проводить обследование организации и работать с заказчиком. Получив информацию об организации, переходим к следующему этапу. Предварительный план «кампании». Разработка концепции. Оценка рисков На этом этапе осуществляется разработка одного или нескольких вариантов решения. Рассматриваются плюсы и минусы каждого из вариантов, возможные риски и т.п. Следует иметь в виду, что на этой стадии проекта не разрабатываются сами технические решения, разговор идет исключительно о подходах, однако этот этап желателен, т.к. путей может быть несколько. И нужно определить наилучший исходя из целей бизнеса и ограничений компании. Иногда этот этап может быть пропущен, если не существует нескольких подходов в решении задачи. Подготовка концепции дает возможность научиться выбирать варианты исходя из требований и ограничений, осуществлять оценку рисков проекта. Завершены все предварительные действия, выбран вариант решения, настает следующий этап. Техническое задание Техническое задание для ИТ-проектов является важнейшей составляющей, определяющей, что мы должны выполнить и в какие сроки. При подготовке технического задания следует указывать только те пункты, которые выполнимы и проверяемы. Необходимо избегать «лозунгов». Если в процессе выясняется, что нужно расширение списка работ, то имеет смысл сделать дополнительное техническое задание и только после этого что-либо предпринимать. Разрабатывая план-график, который является неотъемлемой частью технического задания, целесообразно указать требуемые ресурсы, а не только сроки, состав и наименования задач. Разработка технического задания дает нам возможность очертить цели проекта, сделать их измеряемыми по срокам и трудозатратам, ограничивает перечень того, что предстоит выполнить, не позволяя расширять список непосредственно в процессе работ. Системный администратор учится планировать свои задачи и оценивать трудозатраты на проекте. Демонстрирует профессиональный подход для руководства. Программа и методика испытаний Программа и методика испытаний – документ, определяющий методику проверки успешности завершения работ. Он содержит серию тестов, по которым можно понять корректность работы функционала, заложенного в техническое задание. При подготовке крайне желательно использовать тестовый стенд, чтобы удостовериться в правильности выработанных проверочных примеров. Разрабатывая документ, системный администратор предоставляет заказчику возможность оценки результатов проекта, а сам вырабатывает определенный навык в анализе и мониторинге систем. Построение тестового стенда и стендовые испытания Этот этап является ключевым для повышения экспертизы администратора в технической составляющей проекта.
Стендовые испытания крайне полезны, поскольку позволяют минимизировать появление проблем при внедрении решения в рабочей среде компании. И, как следствие, сокращают риски и затраты на проект. Для системного администратора это дает великолепную возможность изучения особенностей внедряемого комплекса программных средств. Таким образом, именно на этой стадии системный администратор повышает свою квалификацию как технического специалиста. Технический проект Технический проект описывает механизмы реализации всех пунктов технического задания. Может состоять из целого комплекса документов. Например, разрабатывая проект Active Directory Domain Services, необходимо создать систему именования объектов, соответственно в технический проект добавляется вышеуказанный документ. На этой стадии делается значительная часть стендовых испытаний для проверки решений, которые принимаются в процессе проектирования. Эта стадия дает возможность провести экспертизу принятых при проектировании решений, предоставляет описание решений, соответственно при непосредственной работе «за консолью управления» позволяет избежать ошибок и неточностей. Что касается системного администратора, то данный этап также является ключевым для повышения его технической экспертизы и, кроме того, позволяет совершенствовать навык изложения своих решений на бумаге. Эксплуатационная документация Подготовка эксплуатационной документации – самый нелюбимый системныйми администраторами этап работ. Написание инструкций для выполнения тех или иных действий, которые и так очевидны, представляется рутинной и бесполезной задачей. Так ли это на самом деле? Рассмотрим простой пример. Допустим, предстоит написать инструкцию по выполнению процедур резервного копирования и восстановления данных. Казалось бы, хорошо знакомые системному администратору процедуры, тем не менее следует учесть, что, выполняя процедуру восстановления вышедшего из строя сервера, системный администратор работает в состоянии стресса, растет вероятность ошибок, которые могут оказаться весьма неприятными. Наличие инструкции, проверенной в процессе стендовых испытаний, позволяет свести работы к механическому выполнению определенного набора действий, которые приведут к восстановлению работоспособности системы без ошибок. Кроме того, наличие инструкций дает возможность делегирования полномочий менее квалифицированным сотрудникам, тем самым разгружая системного администратора от ряда задач. *** Подводя итоги, хотелось бы отметить, что предлагаемый подход к повышению квалификации не претендует на универсальность. Это один из вариантов, который может быть предложен системному администратору. Он позволит повысить его техническую квалификацию, навыки общения, даст опыт подготовки проектной документации, при этом все будет сделано без отрыва от работы, с минимальными финансовыми затратами и практически за счет работодателя. Кроме того, этот подход позволит продемонстрировать руководству компании ценность сотрудника, изменить отношение к ИТ-департаменту как к исключительно затратной части бизнеса. Дополнительно системный администратор получает опыт работы архитектором и расширяет свою сферу применения. |
| Добавить комментарий |
|
Комментарии могут оставлять только зарегистрированные пользователи |
|
