Если хочется быстрого результата, получается «колхоз»

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

Эксплуатация и развитие

Управление инфраструктурой можно разделить на два больших направления. Первое — это эксплуатация, то есть обслуживание ИТ-мощностей, обеспечение работы корпоративных сервисов и их поддержки в рамках SLA. При этом приоритетность задач определяется их критичностью. Например, у сотрудника перестала работать мышка. Его заявка может подождать до завтра, если сегодня у специалистов были другие, более важные поручения. Но если в три часа ночи выходит из строя почта технической поддержки — это Business Critical сервис, и решать проблему надо здесь и сейчас.

Второе направление — стратегическое развитие. Это внедрение системных улучшений, которые сегодня кажутся второстепенными, но их отсутствие со временем может обернуться серьезными проблемами. Однако реализация таких изменений осложняется существующими ограничениями на российском ИТ-рынке как в программном обеспечении, так и в аппаратных решениях. Рассмотрим пример с серверными мощностями. Если раньше можно было использовать инфраструктуру на базе Cisco или Juniper, то теперь эти варианты недоступны. Аналогичная ситуация и с софтом: отечественные аналоги, например, офисных пакетов Microsoft, пока не могут полноценно заменить привычные инструменты.

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

Управление командой и компетенциями

Думаю, не секрет, что формирование компетентной команды позволяет избежать проблем в инфраструктуре. От квалификации специалистов напрямую зависит, насколько эффективно выполняются задачи. В то же время, чем меньше людей занимается поддержкой инфраструктуры, тем быстрее растет технический долг. У меня был опыт работы в компании, где поддержкой всей инфраструктуры занимался один человек — можно сказать, full stack специалист. В итоге такой подход приводит к деградации системы, где поддержка превращается в борьбу за выживание, а о развитии речи уже не идет. Как с этим бороться? Самый очевидный способ — увеличение штата. Но бесконечно набирать людей нельзя: смысл брать сотню человек, если они не обладают необходимыми компетенциями?

Важно нанимать специалистов, которые способны работать с разными системами и технологиями. Например, сейчас в нашей команде есть отдельные администраторы для Linux- и Windows-серверов. Кроме того, у каждого своя специализация: один занимается почтовыми сервисами, другой — Active Directory и другими критически важными системами. Таким образом, формируются зоны ответственности и повышается эффективность.

Однако важно не только, кто работает, но и как распределяются задачи. Даже самый опытный администратор не справится с большим объемом, если его рабочие часы перегружены рутинными запросами. Представьте, что необходимо настроить доступ пользователя к сервису видеоконференцсвязи (ВКС), но специалистов первой линии поддержки в этот момент нет, и задача ложится на администратора. Он вынужден тратить свои дорогие человеко-часы на выполнение очень простой, неприоритетной задачи, отвлекаясь от действительно важных. В долгосрочной перспективе это приводит к росту технического долга. Поэтому очень важно распределить роли — каждый должен заниматься своим делом.

Управление коммуникацией и расписанием

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

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

Поэтому очень важна не просто коммуникация, а грамотное управление расписанием. Вы планируете запуск новой системы или продукта? Будьте любезны заранее обратиться к инфраструктурной команде: «Мы собираемся вот это внедрять. Нам нужны такие-то объемы ресурсов. У вас они есть? Если нет, когда сможете их выделить? Сколько это займет времени и во сколько обойдется?» Потому что мало найти деньги и купить серверные мощности — их еще нужно поставить, настроить, обеспечить безопасность, наладить сетевое взаимодействие и т. д. Фактически, реализовать целый мини-проект.

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

PMI вместо Agile

Здесь стоит сделать оговорку, что у нас продуктовая компания, в которой все привыкли к гибким методологиям разработки: Agile, Kanban, Scrum. Что это значит? Что в конце двух- или трехнедельных циклов, так называемых спринтов, ты можешь получить какой-то результат. Например, посмотреть, как будет выглядеть стартовая страница сайта. Еще через спринт можно кликнуть кнопку входа, увидеть форму авторизации и т.д. Это итерационное развитие продукта, которое чаще всего не работает в инфраструктуре.

Инфраструктурные проекты требуют гораздо большего времени на реализацию — от нескольких месяцев до года, а иногда и больше. Если хочется быстрого результата, зачастую получается «колхоз». Под одну задачу закупается одно точечное решение (оборудование или ПО), под другую — другое. Все элементы пытаются интегрировать без учета системных взаимосвязей. Это приводит к созданию стихийного ИТ-зоопарка без каких-либо правил взаимодействия между собой, управляемости, защищенности и т.д. Что мы получаем в итоге? С одной стороны, проблемы с информационной безопасностью, с другой — рост операционных расходов на дополнительных специалистов, время на вникание и настройку. В какой-то момент это приведет к тому, что компания скажет: «Хватит! Так больше жить нельзя. Нужно все «взорвать» и построить заново».

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

В управлении инфраструктурой ключевую роль играет не гибкость Agile, а строгий проектный подход — PMI. Инфраструктура — это базис, это стратегическая инвестиция, требующая четкого планирования и работы в долгую. Важно заранее определять цели, задачи и ключевые характеристики: масштабируемость, отказоустойчивость, катастрофоустойчивость. То есть возможность дублирования инфраструктуры в альтернативной локации. Например, если корпоративный сервис ВКС работает на одном виртуальном сервере, то его отказ приведет к эскалации. Твой sales не сможет поговорить с клиентом, и компания не заработает несколько миллионов рублей. Чтобы этого избежать, важно запланировать отказоустойчивую конфигурацию, при которой падение одного узла не влияет на работу всей системы.

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

Если кратко…

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