Всем привет! Это Гриша Капцов. Я работаю в Отделе координации и поддержки продуктовых команд в МТС Web Services. А еще — умею повелевать хаосом (вместе с коллегами, конечно же).
В мире ИТ-эксплуатации хаос — привычное состояние. Представьте: утро, вы приступаете к работе — и тут внезапно падает ключевой сервис. Пока инженеры устраняют инцидент, поступает эскалация от бизнеса — критическая система тоже работает с перебоями. Тем временем в календаре стоит запланированное обновление инфраструктуры, которое нельзя откладывать. Ну и о какой предсказуемости тут может идти речь? В таких условиях традиционные подходы к управлению задачами часто дают сбой: приоритеты меняются на лету, задачи теряются, нагрузка распределяется неравномерно.
Дальше будем разбираться, как структурировать процессы, снизить перегрузку и повысить прозрачность работы. Покажу, как адаптировать ключевые принципы Kanban и Scrum под эксплуатационные реалии. Думаю, этот пост будет полезен инженерам эксплуатации, DevOps-командам, специалистам службы поддержки и всем, кто сталкивается с динамичными задачами в ИТ.
Работа в условиях хаоса
Эта фраза идеально описывает работу эксплуатационных команд в ИТ. Вот несколько примеров задач, которые для нас — серые будни:
срочное устранение инцидентов. Например, внезапно ломается сервер, поддерживающий работу клиентского приложения. Тогда команда должна оперативно найти и устранить причину сбоя;
управление эскалированными проблемами. Если на первом уровне поддержки решить задачу не удается, ее передают нам. Например, если клиент не может провести операцию, а причина — в сложном системном сбое, задача моментально становится критической;
внедрение изменений. Переход на новую версию базы данных или развертывание обновленного микросервиса требуют тщательной координации, иначе начнутся сбои;
обслуживание инфраструктуры и сервисов. Мониторинг нагрузки, резервное копирование, настройка серверов и другие регулярные меры, которые позволяют ИТ-системе стабильно работать.
Все эти задачи поступают из разных источников, часто конфликтуют по приоритетам и требуют немедленного реагирования. Если нет четкой и понятной системы управления, команда рискует столкнуться с такими неприятностями:
работа будет невидимой. Вот инженер всю смену тушит пожары: устраняет инциденты, консультирует коллег, отвечает на экстренные запросы. Но в отчетах его работа не фиксируется, ведь задачи приходили хаотично и не были отражены в системе. В итоге создается впечатление, что он «ничего не делает»;
вы потеряете эффективность, потому что множество задач придется отрабатывать параллельно. Допустим, специалист начинает разбираться с падением базы данных, но тут же поступает срочный запрос на устранение сетевого сбоя. В попытках разорваться между задачами он теряет концентрацию, переключается туда-сюда. В итоге не успевает качественно решить ни одну из проблем;
незавершенные работы будут накапливаться и замедлять поток. Из-за постоянных переключений команда может не успеть закончить даже простые задачи. В бэклоге набираются недоделанные обновления, отложенные тикеты, долгие расследования инцидентов. Все это тянет работу вниз, замедляя процесс и повышая уровень стресса в команде.
Теперь главный вопрос: как не терять эффективность и спасти сотрудников от выгорания? Конечно, нужно найти метод, который поможет структурировать процессы и сохранить продуктивность. Вариантов тут несколько.
Классический Scrum подходит для работы с четко спланированными задачами в фиксированных итерациях. Но, как вы уже поняли, эксплуатационные команды сталкиваются с другой реальностью: иногда запросы решаются за минуту, а иногда — за месяцы. Жесткие рамки спринта не позволяют учитывать эту вариативность. К тому же решение и обработка запросов широко декомпозируются. Каждую подзадачу можно оформить как отдельную, и она прекрасно ляжет в итерационный процесс.
Получается, тут нужен баланс между гибкостью и структурой. Именно поэтому мы решили замиксовать Scrum и Kanban. Это позволило нам взять преимущества обоих методов и эффективно справляться с нагрузкой. Подробнее об этом еще скажу ниже, а пока — о втором методе.
Kanban в эксплуатационных командах
Коротко о базе. Kanban — это метод управления работой, который основывается на визуализации процессов и ограничении незавершенных задач (WIP-лимиты). Представьте доску, где все задачи команды распределены по колонкам: «В работе», «Ожидание» и «Готово». Если в колонке «В работе» уже висит максимальное количество задач, новые брать нельзя, пока не завершены текущие. Такой подход предотвращает перегрузку, помогает сфокусироваться на выполнении задач до конца и обеспечивает прозрачность процессов.
Теперь о том, как адаптировать его для эксплуатационных команд.
Шаг 1. Разделить поток на типы работ. Для повышения управляемости и прозрачности Kanban-доска должна отражать разные типы задач:
инциденты — высокий приоритет, требует немедленного решения. Например, падение сервиса;
плановые изменения — запросы, связанные с обновлением систем, внедрением новых функций;
обслуживание — например, мониторинг или резервное копирование;
улучшения — долгосрочные инициативы по повышению качества сервисов или автоматизации.
Каждый тип работ можно отобразить отдельными потоками или колонками на доске, чтобы не смешивать задачи с разным приоритетом и временем исполнения.
Шаг 2. Ограничить незавершенные задачи (WIP-лимиты). Для каждого типа задач устанавливаются WIP-лимиты. Например:
не более пяти инцидентов в активной обработке;
не более трех параллельных изменений;
не более двух задач на улучшения.
Это защищает сотрудников от перегрузки и помогает сконцентрироваться на том, чтобы вовремя завершить текущую работу.
Шаг 3. Учесть SLA. В эксплуатационных командах важно соблюдать сроки выполнения задач, особенно если это инциденты. В Kanban-доске можно добавить индикаторы времени — например, SLA-метки или оставшийся период до дедлайна.
Шаг 4. Расставить приоритеты. Инциденты, не решенные в установленный срок, автоматически эскалируются. На доске можно выделить зону для задач, требующих вмешательства руководителя или другой команды.
Шаг 5. Обеспечить прозрачность и координацию. Kanban-доска позволяет всем заинтересованным видеть текущий статус задач. Это особенно важно при взаимодействии между группами (например, сетевой отдел, DevOps, служба мониторинга), когда над одним проектом работают несколько специалистов.
Kanban-каденции
Kanban-каденции — это регулярные встречи команды эксплуатации. Тут можно выделить:
ежедневные Kanban-митинги — обсуждаются статусы задач, собирается обратная связь от коллег и анализируются возможные проблемы;
встречи по пополнению доски — определение приоритетных задач для добавления в работу;
обзор сервиса поставки — анализ эффективности процесса и поиск возможностей для улучшения.
Благодаря регулярным встречам мы видим, где возникают задержки, как распределяется нагрузка и как меняется производительность. Объективно оценивать эти показатели помогают метрики. Дальше — как раз о них.
О метриках
А вот что важно для нас:
Cycle Time, или время выполнения. Помогает анализировать, сколько времени нужно для завершения задачи от начала до конца;
процент выполнения SLA. Показывает, насколько команда соответствует ожиданиям клиентов;
среднее количество WIP. Эта метрика помогает выявить узкие места. Например, если команда эксплуатации регулярно упирается в лимит незавершенных задач, это может указывать на недостаток ресурсов, слишком долгие согласования или зависимость от других команд;
частота инцидентов. Позволяет анализировать и прогнозировать нагрузку.
Отслеживать эти показатели можно с помощью Jira Service Management, ServiceNow, Kanbanize и других инструментов.
Наш опыт внедрения Scrum и Kanban
Как я уже сказал выше, мы комбинируем подходы Scrum и Kanban. Так у нас лучше получается сбалансировать долгосрочное планирование и оперативное выполнение задач.
Kanban-доска отражает эпики — крупные блоки без привязки к датам. Они помогают видеть общие направления работы. В классическом понимании Kanban обычно не подразумевает работу с эпиками, это больше характерно для Scrum и гибридных методологий. Но в эксплуатационной команде использование эпиков как крупных блоков работ — допустимый подход.
Доска с элементами Scrum — без жестких итераций. В ней собраны конкретные задачи, которые берутся в недельные спринты и прорабатываются командой.
Для аналитики каждая задача помечается двумя хештегами из заранее определенного каталога. Хештег первого уровня указывает на сервис или систему. Второго — уточняет тип запроса.
Чего мы добились с таким подходом:
обеспечили прозрачность работы. Теперь у нас есть четкое разделение стратегических (эпики) и тактических (задачи) активностей;
контролируем нагрузку. Спринты помогают ограничивать объем задач, а Kanban-доска дает обзор долгосрочных целей;
анализируем обращения и эффективно используем ресурсы. С хештегами мы видим, на каких сервисах максимум нагрузки и какие работы требуют больше внимания. Это помогает распределять ресурсы и планировать улучшения.
Структурируя поток задач и используя WIP-лимиты, мы научились справляться с непредсказуемой работой, концентрироваться на важном и избегать перегрузок. Хаос, конечно, никуда не делся, но нам удалось его приручить.