Когда инфраструктуру поддерживает один подрядчик, а приложение — другой, у каждого из них есть контракт, команда и чёткое понимание своей зоны ответственности. Увы, при такой модели контракты не покрывают пространство между этими зонами ответственности, где как раз и возникает большинство дорогостоящих инцидентов.
Если меняется регуляторное требование и нужно переделать часть логики приложения с учетом новых ограничений инфраструктуры, кто этим занимается? Или, например, что-то сломалось на стыке двух систем и каждый подрядчик говорит, что у него всё работает — кто разбирается с такими ситуациями?
Вот такие несостыковки владелец продукта и видит каждый день: задачи, которые непонятно кому поручить, инциденты, которые никто не воспроизводит у себя, и изменения, которые требуют участия сразу нескольких команд, но ни одна из них не берется за координацию. Всё это — издержки, которые не отражены ни в одном из контрактов, но которые неизбежно приходится нести.
Дело в том, что сама архитектура раздельной поддержки генерирует скрытые издержки, которые не видны ни в одном из контрактов, но очень хорошо ощущаются владельцем приложения. Выражаются они в потраченном времени, зависших инцидентах и задачах, которые годами висят в бэклоге, потому что непонятно, чья это вообще проблема.
Скрытые расходы при раздельной поддержке
Говоря о стоимости ИТ-поддержки, принято ориентироваться на то, что написано в контрактах: стоимость команды разработки, стоимость инфраструктуры, лицензии. Это видимая часть. Невидимая — значительно сложнее.
Издержки координации. Каждый раз, когда нужно что-то изменить или решить проблему на стыке систем, начинается процесс согласования. Владелец приложения собирает представителей разных подрядчиков, объясняет контекст каждому, пытается выработать общее понимание проблемы. И это повторяется раз за разом. Часы менеджмента, потраченные на то, чтобы просто собрать всех за одним столом и добиться согласованных действий, в контракте не значатся нигде. Но они очень дорого стоят.
Издержки дублирования контекста. Каждая команда видит систему через своё окно. Инфраструктурная команда видит серверы, сети, контейнеры. Команда разработки видит код и логику приложения. И если никто не видит систему целиком при возникновении сквозной проблемы, нужно заново вводить в контекст всех участников отдельно. Вы платите за это дважды: временем своих людей и временем подрядчиков.
Издержки серых зон. Это, пожалуй, самая коварная категория. В любой сложной системе есть слои, которые формально не принадлежат никому: мониторинг на стыке приложения и инфраструктуры, интеграции между системами. Когда там что-то ломается, начинается пинг-понг: инфраструктурная команда говорит, что сервер доступен и у них всё работает. Команда разработки говорит, что в QA всё запускается и проблема не на их стороне. Время простоя растёт. Владелец продукта мечется между подрядчиками, пытаясь самостоятельно локализовать проблему в области, где по определению нужна экспертиза с обеих сторон одновременно.
Больше подрядчиков — больше затрат на управление. Стремление разбить поддержку на множество вендоров может снизить контрактную стоимость поддержки, но при этом неизбежно спровоцирует дополнительные затраты на управление и решение инцидентов на стыке между, собственно, несколькими подрядчиками. Ведь у каждого из них так или иначе будет свой контекст, несмотря на то, что все они работают с одним заказчиком.
Когда серые зоны накапливаются, компании часто находят одно и то же решение: выделяют DevOps-инженера, который будет закрывать все, что падает между командами. DevOps — дорогой специалист, которого нанимают за техническую экспертизу, а используют в обсуждаемой ситуации как диспетчера. Итог: оплата ставки senior-инженера за работу, которая инженерной по сути не является.
Пул «нерешаемых» задач: как комплексная экспертиза закрывает старые долги
Если углубляться в проблему, мы понимаем, что оседание и повисание нерешаемых долгое время задач происходит обычно после нескольких итераций разбирательств с ними. Каждый подрядчик смотрит на симптомы в своей зоне, ничего подозрительного не находит и закрывает тикет. Но проблема, конечно, никуда не девается. Задача возвращается раз за разом и превращается со временем в мертвый груз.
Экспертная команда с широким взглядом на систему работает с такими задачами иначе: не от симптома, а от первопричины. Траблшутинг становится системным процессом, вводя как стандарт процедуру анализа того, как разные слои взаимодействуют между собой, где именно рвется цепочка и при каких условиях это воспроизводится.
Ещё один эффект, который сложно переоценить: такая команда умеет корректно описать проблему для команды архитектуры: предоставить точную формулировку с учетом всех точек зрения — инфраструктурной, прикладной, интеграционной. Это само по себе сокращает время решения проблем в разы.
Вот как это выглядело в реальном проекте. Наш заказчик — крупный производитель и дистрибьютор табачной продукции. В компании реализован полный цикл от производства до конечных продаж, два юридических лица с разной спецификой, но общей ИТ-экосистемой — сложился типичный для Enterprise зоопарк решений. Коробочные продукты от внешних вендоров, несколько внутренних платформ, на базе которых работают приложения с совершенно разными функциями, кастомные разработки. Часть систем на Windows, часть на Linux, разные стеки, разные команды, разные контракты.
Инциденты, которые возникали на стыке этих слоёв, шли по типичному сценарию: что-то перестаёт работать в интеграции между двумя системами, или приложение начинает нестабильно работать через корпоративный VPN. Инфраструктурная команда проверяет свою часть — всё в порядке. Команда разработки воспроизводит проблему в тестовой среде — не воспроизводится. Вендор коробочного решения ссылается на кастомизации. Владелец приложения остается один на один с проблемой, которую каждый видит через свое окно, но ни у кого нет ни стимула, ни контрактных обязательств смотреть шире.
Как раз в такой ситуации и проявляется реальная стоимость раздельной поддержки: сколько времени и сил тратит владелец приложения на роль, для которой его никто не нанимал: быть связующим звеном между всеми подрядчиками и в одиночку удерживать целостную картину системы.
Как работает единое окно
Единое окно поддержки — это команда, которая намеренно выстроена на стыке компетенций. Она понимает и логику приложения, и устройство инфраструктуры, и умеет работать с обеими сторонами одновременно.
Такая кросс-функциональная команда состоит из менеджера, девопс-специалиста и разработчика. Менеджер отвечает за координацию тикетов, решение и принятие решений, а также управляет базой знаний. В зоне ответственность девопс-специалиста знания об инфраструктуре, аутентификации, публикации и сетях. Разработчик должен уметь работать, например, с особенностями вычитки данных из БД, интеграций с другими системами заказчика, аналитика и т.д.
Сквозной мониторинг, который настраивает команда, учитывает слабые места продукта и инфраструктуры в целом.
Разберем, что это значит на практике:
Во-первых, серые зоны перестают быть серыми. Middleware, мониторинг, интеграции и всё что находится между контрактами подрядчиков, становится чьей-то конкретной ответственностью.
Во-вторых, инциденты на стыке решаются принципиально иначе. Когда одна команда видит систему целиком, вопроса характера «на чьей это стороне» по сути не возникает. Куда важнее и продуктивнее такой команде задаваться вопросом о том, где в системе возникла проблема. Это меняет скорость диагностики радикально. Не нужно собирать консилиум из пяти подрядчиков, каждый из которых смотрит в свою сторону.
В-третьих, появляется сквозной мониторинг. Вместо разрозненных дашбордов у каждого подрядчика — единая картина того, как запрос пользователя проходит через все слои системы. Это меняет не только скорость реакции на инциденты, но и саму способность их предотвращать.
В-четвертых — и это часто недооцениваемый момент — единое окно решает проблему знаний. В модели раздельной поддержки знания о системе распределены по нескольким командам и существуют, пока существуют эти команды. Когда кто-то уходит, уходит и контекст. А это критичный момент для любой компании, деятельность которой хоть как-то завязана на ИТ-решениях. Единый стандарт документации и общая база знаний означают, что информация о системе живет в одном месте и не зависит от ротации сотрудников у очередного подрядчика.
Есть и еще одна важная деталь. «Единое окно» отчасти выполняет функции сервис-деска, но по более технически сложным вопросам. Оно также как сервис-деск знает куда направить ту или иную историю (инцидент), может помочь со сбором диагностики и т.д.
Перестать платить за процесс и начать платить за результат
Модель раздельной поддержки — не плохое решение само по себе. Она логична, она масштабируема, она позволяет нанимать узких специалистов. Но у неё есть структурная уязвимость: она оптимизирует работу внутри зон ответственности и оставляет на периферии всё, что между ними.
В зрелых Enterprise-системах это самое «между» становится всё масштабнее — и по объёму, и по сложности. Интеграции умножаются, стеки усложняются, границы между кодом и инфраструктурой размываются. И чем сложнее система, тем дороже обходится отсутствие кого-то, кто видит ее целиком. Инциденты в серых зонах накапливаются и рано или поздно становятся критическими если не каждый по отдельности, то в сумме. Разобраться с ними в итоге придется. Но чем дальше это разбирательство отложено во времени, тем дороже оно будет стоить.
Три вопроса, которые стоит задать себе прямо сейчас: есть ли в вашем бэклоге задачи, которые зависли, потому что непонятно, чья это проблема? Сколько времени в неделю владелец приложения тратит на координацию между подрядчиками, а не на развитие продукта? Доволен ли бизнес тем, как быстро решаются проблемы, затрагивающие несколько систем сразу?
Если хотя бы на один из этих вопросов ответ неутешительный, скорее всего, скрытые расходы уже есть.
Мы можем разобрать вашу ситуацию конкретно: посмотреть, где в системе находятся серые зоны, оценить, сколько времени уходит на координацию между командами, и предложить, как это можно решить.
Напишите нам, чтобы получить бесплатную консультацию. И помните: предсказуемость ИТ начинается там, где заканчиваются границы между отделами и подрядчиками.
