Предлагаемая публикация является фрагментом из книги There's No Such Thing as an IT Project: A Handbook for Intentional Business Change.
В цифровую эпоху успех ИТ-проектов означает изменение бизнеса, а не просто внедрение новых систем. Но в основе такой перемены лежит еще более фундаментальный сдвиг: эксплуатация ИТ-систем должна настолько же стать неотъемлемой частью бизнес-операций, насколько приложения должны быть задействованы в процессе изменения бизнеса.
Во многих организациях ИТ-служба работает как если бы она была отдельным бизнесом — поставщиком услуг для своих внутренних заказчиков. Однако сегодня подобная структура препятствует нормальному функционированию отделов ИТ-службы, отвечающих и за приложения, и за эксплуатацию систем.
Отчасти это связано с тем, что принцип «ИТ как бизнес» привел к странной практике — заключению соглашений об уровне обслуживания между отделом по эксплуатации ИТ и его внутренними клиентами.
|
Приглашаем на конференцию «Корпоративный DevOps 2019». DevOps с погружением: лучшие эксперты — о DevOps как управленческом подходе и его роли в цифровой трансформации.
|
При реальном аутсорсинге ИТ уровень обслуживания, закрепляемый в SLA, — показатель, состоящий из двух частей. Первая — минимальный допустимый стандарт сервиса, а вторая указывает, как часто его провайдер должен достигать этого уровня.
Задать первую часть обычно легко, со второй дело обстоит сложнее. Например, в SLA может быть указано, что длительность перебоя в работе до восстановления обслуживания может составлять не более часа. При этом, согласно второй части, это правило должно соблюдаться для 99% всех перебоев.
Для случаев, когда провайдер не выполняет SLA, в соглашении предусматриваются средства возмещения, заранее согласованные путем переговоров. Если предполагается, что ИТ-служба должна действовать как независимый бизнес, заключение SLA с внутренними заказчиками кажется вполне логичным. Однако как показывает реальность, трудно придумать что-то менее логичное.
Стопор инноваций
Заключение внутренних SLA — порочная практика по нескольким причинам. Первая — такие SLA усиливают неверную модель взаимоотношений ИТ и бизнеса, когда ИТ-служба действует в форме самостоятельного предприятия, продающего услуги внутренним заказчикам.
Вторая причина — следствие первой: когда ИТ-служба не выполняет SLA, заказчики с этим ничего поделать не могут, не в суд же подавать. А SLA без штрафов за невыполнение не имеют смысла и лишь способствуют созданию атмосферы недоверия между подразделениями.
Третья причина — вы получаете только то, что измеряете. А в большинстве случаев отдел ИТ контролирует уровни обслуживания, но мерок инновации не имеет. Между тем, правильное управление ИТ-службой — это постоянное балансирование между надежностью и инновацией, а последняя подразумевает риск. Но поскольку отчеты по SLA — ретроспективные, в них включаются только негативные последствия инновации, но не достигнутые преимущества.
В пример можно привести переход на накопители SSD, когда они только появились. Их надежность и долговечность первое время были под вопросом, но миграция с лихвой окупилась для тех, кто решился на внедрение и получил преимущества по производительности при аналитике и работе с большими данными.
Чтобы сохранять лидерство, нужно рисковать и проявлять дальновидность, а соглашения об уровне обслуживания не поощряют ни то, ни другое.
Доводы против SLA
ИТ-служба обычно отвечает за технические услуги и за услуги поддержки. SLA для технических услуг касаются доступности, производительности систем и т. п. Но проблема в том, что архитектуры высокой доступности когда-то были исключением, а сегодня — уже нет.
Нужно ли ИТ-службе продолжать контролировать уровень качества технических услуг? Да, если он не слишком высокий, но — только для того, чтобы придти к тому моменту, когда дальнейшее отслеживание станет бесполезной тратой времени.
То, что какой-то компонент оборудования может выйти из строя, больше не оправдание для простоев системы. В этом — суть архитектур высокой доступности. Если система когда-либо становится недоступной, это должно быть настолько редким событием, чтобы вести его статистический учет было бессмысленно.
При этом точно не будет растратой времени анализ первопричин, ведь каждый отказ означает, что в вашей архитектуре высокой доступности имеется конструктивный дефект, который нужно устранить. Также не является напрасной тратой времени анализ инцидентов с целью раннего обнаружения и устранения возникающих проблем — до того, как они повлияют на бизнес в целом.
Услуги поддержки, в свою очередь, оказываются ИТ-специалистами тем, кто занимается бизнес-операциями. SLA для услуг поддержки могут регулировать, например, длительность ожидания ответа на вопрос пользователя и максимальное время разрешения проблемы. Службе поддержки удается соблюдать эти требования, когда численности ее сотрудников хватает, чтобы справиться с объемом поступающих заявок, а если обращений слишком много, результативность падает. Таким образом, SLA не имеют никакого отношения к результативности — они просто «плетка», которой можно отхлестать руководителя службы поддержки.
Единственное, когда SLA имеет значение, это период составления бюджета, когда показатели результативности службы поддержки можно использовать, чтобы обосновать необходимость найма дополнительных сотрудников. Это, конечно, важно, но это оправдывает лишь практику контроля уровня обслуживания, а не заключения SLA.
Единственная характеристика ИТ-отдела, имеющая смысл
Успешная работа руководителей всегда делает их более заметными, способствуя продвижению по службе и росту оплаты. А о службе ИТ вспоминают только когда что-то идет не так.
Лучшие показатели — те, которые количественно выражают характеристики качества. Показатель результативности эксплуатации ИТ-систем, который наилучшим образом демонстрирует, насколько хорошо справляется ИТ-служба, — это степень ее невидимости. Этот «индекс невидимости» должен быть составным, учитывающим доступность и производительность приложений, число обращений в службу поддержки, а также частоту случаев, когда проблемы с эксплуатацией ИТ-систем создают узкие места в других бизнес-процессах и практиках.
В ИТ-дирекциях обычно есть отделы, отвечающие за разработку и за эксплуатацию ИТ-систем, и они друг друга исторически недолюбливают — по двум причинам. Во-первых, успех нового приложения обусловлен изменениями, которые оно приносит, но каждое изменение создает риск увеличения заметности для эксплуатационного отдела. Во-вторых, приложения нуждаются в услугах последнего по созданию и сопровождению сред разработки и тестирования. Таким образом, для отдела приложений эксплуатационный становится «бутылочным горлышком». А первый создает для эксплуатационного дополнительную, часто незапланированную работу.
Исправить ситуацию помогает DevOps. С переходом на DevOps в группе разработки появляется как минимум один выразитель мнений отдела эксплуатации ИТ-систем, что помогает решать соответствующие задачи по в соответствии с нуждами проекта разработки, а не в порядке поступления запросов в ИТ-отдел.
Это все к тому, что при наличии трений или недоверия между двумя группировками, которым для нормальной работы необходимо взаимодействовать, создание мостов между их сотрудниками и процессами независимо от изначальной специализации этих групп будет полезным решением.
Цифровая трансформация и BusOps
Сегодня во многих компаниях руководители только и твердят, что о цифровой трансформации, и вряд ли когда-нибудь был менее непонятный и неоднозначный предмет «корпоративной моды». Но, если отбросить ажиотаж, — существуют конкретные цифровые технологии, которые дают новые возможности. Компании могут воспользоваться ими, чтобы получить конкурентное преимущество или они могут проигноировать их, уступив преимущество соперникам.
Независимо от специфики, реальность цифровой эпохи такова, что выбор фокусироваться на информационных технологиях или нет больше не стоит. Они глубоко вплетены во все процессы и практики, применяемые в компании для ведения ее повседневной деятельности. Таким образом, концептуально эксплуатация ИТ-систем — лишь одна из многих подвижных частей, обеспечивающих бизнес-операции, которая, как следствие, относится к сфере ответственности директора по операциям не меньше, чем к сфере ответственности ИТ-директора.
И все же, независимо от того, в чьем подчинении находится отдел эксплуатации ИТ, сам он должен остаться без изменений. Эффективность его работы (и, соответственно, невидимость) зависит от постоянного взаимодействия группы технических специалистов, хорошо знающих свое дело.
Управление процессами, за которые они отвечают, в свою очередь, должно происходить под контролем руководителей, досконально понимающих устройство этих процессов, знающих потребности подчиненных и особенности их обязанностей.
Кроме того стоит помнить, что реорганизации редко способствует устранению каких-либо проблем. Они могут устранять барьеры, когда группы, не ладившие друг с другом, попадают в подчинение к общему руководителю. Или наоборот, могут возникнуть новые барьеры между группами, у которых раньше было общее руководство, а после реогранизации — нет.
Перенос отдела эксплуатации ИТ на организационной диаграмме под начало директора по операциям не будет ни более, ни менее логичным по сравнению с сохранением его на прежнем месте. А что касается реструктуризации самого эксплуатационного отдела, разделить его и распределить обязанности по разным подразделениям просто не выйдет — технические проблемы, как и всегда, должна сообща решать отдельная группа специалистов соответствующего профиля.
Что же должно измениться? Ответ снова дает DevOps. Культуру взаимодействия DevOps нужно распространить на отношения между отделом эксплуатации ИТ и другими операционными отделами компании — аналогично тому, как бизнес-руководители, стремясь преуспеть, налаживают взаимодействие с ИТ-специалистами, отвечающими за бизнес-приложения.
Персонал службы технической поддержки нужно избавить от «цепей» SLA, удерживающих их за рабочими столами, — нужно побуждать их самим приходить к пользователям, интересоваться сутью их проблем и давать советы о том, как можно воспользоваться преимуществами технологий, находящихся в их распоряжении.
Тем временем эксплуатационному отделу ИТ-службы нужно исправить ситуацию с Agile, в том числе и потому, что понятия «ИТ-проект» больше не существует: Agile в практикуемой ныне форме по-прежнему используется для выпуска конкретных продуктов, а не как основа взаимодействия, направленного на изменение бизнеса в лучшую сторону. «Исправляя» Agile, лучше усилить эффект, введя элементы DevOps и включив в проектную группу по изменению бизнеса системных администраторов и администраторов безопасности. Тем самым вы улучшите результативность проектов, а дополнительные знания по важным для бизнеса вопросам помогут повысить эффективность повседневных решений, принимаемых специалистами по эксплуатации ИТ.
Чтобы придать описываемой концепции официальный статус, предложим для нее новый термин. По аналогии с тем, как DevOps означает взаимодействие разработчиков и специалистов по эксплуатации ИТ, назовем словом BusOps взаимодействие последних с теми, кто отвечает за бизнес-операции.
Бой, согласно Сунь Цзы, «всегда идет за сердца и умы», так что начнем с согласования терминологии. Добавив новое слово в свой лексикон, вы, возможно, приятно удивитесь результатам.
